Network configuration

An OBSESC node lives in a private subnet of your VPC. Shippers, operators and the optional load balancer reach it on its private IP address. This page lists every port, the security group rules the stack creates, and how to lock them down further.

Topology

The stack places a single node in the SubnetId you choose. There is no load balancer in front of the ingest protocols. Shippers connect straight to the node’s private IP, which the stack reports in its IngestEndpointOtlp and IngestEndpointEs outputs. You can add an internal Application Load Balancer for the console. It is never internet-facing.

The console and the query API share one port, 18080. The stack’s UiUrl output is the address to open.

Contact us about multi-node deployments.

Ports

Port	Protocol	Purpose	Enabled by default	Opened by the stack’s security group
4317	TCP (gRPC)	OTLP/gRPC ingest	Yes	Yes, from AllowedIngestCidr
4318	TCP (HTTP)	OTLP/HTTP ingest	Yes	Yes, from AllowedIngestCidr
9200	TCP (HTTP)	Elasticsearch _bulk ingest	Yes	Yes, from AllowedIngestCidr
8088	TCP (HTTP)	Splunk HEC ingest	Yes	No: add a rule
24224	TCP	Fluent Forward ingest	Yes	No: add a rule
9000	TCP (gRPC)	Vector native ingest	Yes	No: add a rule
8555	TCP (HTTP)	Firehose HTTP endpoint	No	No
3100	TCP (HTTP)	Loki push	No	No
12201	UDP and TCP	GELF	No	No
18080	TCP (HTTP/S)	Console, query API, /metrics, /ready	Yes	Yes, from AllowedIngestCidr, and from the load balancer’s security group when you use one
9100	TCP	Reserved for multi-node deployments	No	Only from the node security group itself

The listeners bind to all interfaces on the node, so the security group is your network boundary.

There is no SSH rule. Use AWS Systems Manager Session Manager for shell access.

Tightening the default rules

The stack uses one parameter, AllowedIngestCidr (default 10.0.0.0/8), for the ingest ports and for port 18080. Before production, make three changes.

Narrow the ingest range

Set AllowedIngestCidr to the smallest range that covers your shippers.

Restrict the console and API port

Limit port 18080 to the operator networks that need it. If you use the console load balancer, the load balancer reaches the node through its own security group rule, so you can remove the CIDR rule for 18080 entirely, or keep it only for the networks that call the API directly. This matters because /metrics is unauthenticated, and without AuthSecretArn the console and API are too (see Security model). For example:

SG=sg-0123456789abcdef0
aws ec2 revoke-security-group-ingress  --group-id "$SG" --protocol tcp --port 18080 --cidr 10.0.0.0/8
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 18080 --cidr 10.20.30.0/24

A later stack update can overwrite changes you make outside CloudFormation, so record them in your own infrastructure code.

Open only the extra ingest ports you use

For example, to allow Splunk HEC from one network:

aws ec2 authorize-security-group-ingress --group-id "$SG" \
  --ip-permissions 'IpProtocol=tcp,FromPort=8088,ToPort=8088,IpRanges=[{CidrIp=10.20.0.0/16,Description="Splunk HEC"}]'

The GELF protocol has no authentication, so if you enable it, allow port 12201 only from the exact sources that send GELF.

The console load balancer

Set EnableUiLoadBalancer=true with at least two UiAlbSubnetIds in different Availability Zones. The stack then creates:

• an internal ALB whose security group accepts 80 and 443 from UiAllowedCidr (and 8443 when EnableNodeApiOidc=true)
• egress only to the node security group on 18080, plus a matching node ingress rule that names the ALB’s security group rather than a CIDR range
• a health check on GET /ready, so a node that isn’t ready leaves rotation
• optionally, a Route 53 alias in your private hosted zone (UiPrivateZoneId, UiHostname) such as obsesc.your-domain.internal

With UiCertificateArn set, the ALB serves HTTPS on 443 and redirects port 80 to it. Without a certificate, it serves plain HTTP on port 80, and you can’t turn on sign-in.

With EnableUiPerUserRbac or EnableNodeApiOidc turned on (see IAM and permissions), the ALB security group also allows outbound HTTPS (443) to 0.0.0.0/0 so the ALB can reach your identity provider’s token and userInfo endpoints. If your identity provider publishes a prefix list, scope that rule to it. Because the ALB is internal, its subnets also need a route to the identity provider, such as a NAT gateway.

Outbound access from the node

The node needs to reach these endpoints over HTTPS:

Service	Why
Amazon S3	Raw events, catalog, audit trail, holds
AWS KMS	Encrypting and decrypting data keys
AWS STS	Resolving the bucket owner; assuming a cross-account role
AWS Secrets Manager	Auth secret
AWS Systems Manager (SSM)	TLS parameters, Session Manager
Elastic Load Balancing	Registering the node with the console load balancer (only if you use one)
AWS Marketplace Metering	Usage reporting (only with a product code)
Your Alertmanager, webhooks, identity provider	Only if you configure them

You can provide this through a NAT gateway, or through VPC endpoints (a gateway endpoint for S3 and interface endpoints for the others).

Shippers in other VPCs or accounts

One OBSESC deployment can receive logs from several AWS accounts. Nothing is installed in those spoke accounts except the shipper configuration and a network path. The template doesn’t create these network paths, so build them with standard AWS networking:

Option	How	Good fit
VPC peering	Peer each spoke VPC with the OBSESC VPC, route the node subnet, and add the spoke CIDRs to the node security group	A few spokes in one region, with no overlapping CIDR ranges
AWS PrivateLink	In the OBSESC account, put an internal Network Load Balancer (TCP passthrough) in front of the node and expose it as an endpoint service allow-listed to spoke accounts. In each spoke, create an interface endpoint	Many spokes, overlapping CIDR ranges, or a policy against routing between accounts
Transit Gateway	Attach the OBSESC and spoke VPCs to a transit gateway (it can be one you already have)	Estates that already use a transit gateway

Two tips:

• Keep traffic in one Availability Zone. Place shipper subnets in the same AZ ID as the node (for example use1-az1). AZ names such as us-east-1a map to different physical zones in different accounts. To find the IDs, run aws ec2 describe-availability-zones.
• Tag each spoke’s traffic. Set a distinguishable service name on each spoke’s shippers so you can tell sources apart. See Supported sources.

Related

• Encryption for TLS on these ports
• IAM and permissions
• Deploying from AWS Marketplace