Skip to content

SYSTEM Cited by 2 sources

AWS Network Load Balancer (NLB)

AWS Network Load Balancer is the Layer-4 TCP/UDP member of Elastic Load Balancing: a fleet-scaled TCP proxy that routes connections from one or more front-end listeners (on Elastic IPs in public subnets or internal IPs in private subnets) to back-end targets registered in target groups (EC2 instances, IPs, or ALBs). NLB preserves source IP and supports millions of connections at ultra-low latency.

Why the wiki has this page

NLB shows up in cross-boundary ingress architectures where an external system must reach a resource inside a private VPC and needs a stable, allowlistable IP on the public side. Classic ALBs don't offer static IPs; NLBs do — a single NLB can be bound to per-AZ Elastic IPs that an external SaaS can encode in its firewall rules.

See concepts/static-ip-allowlisting for the general requirement and patterns/nat-router-for-static-ip-ingress for the composite pattern that pairs NLB with an EC2 NAT router + RDS Proxy + private Aurora.

Architectural primitives (from ingested sources)

  • Elastic IP on public subnet listener — the static address bound to the NLB is an EC2 Elastic IP. External SaaS vendors allowlist it; the NLB's own address never changes.
  • Security-group chaining — the NLB's security group can restrict inbound traffic to a specific CIDR (e.g. the SaaS vendor's IP range). Downstream targets' security groups in turn restrict inbound traffic to the NLB's security group. Three-hop chain: external IPs → NLB → routers → Aurora.
  • Target types — NLB targets can be EC2 instances (used as NAT routers in the ingress pattern), IPs, or ALBs.

Seen in

  • sources/2026-05-13-aws-streaming-cloudwatch-metrics-to-vpc-based-opentelemetry-collectors-using-lambda — canonical wiki instance of internal-subnet NLB as VPC- private ingress for an OpenTelemetry collector fleet on EC2. AWS Architecture Blog (2026-05-13) — customer architecture pushes CloudWatch Metric Streams via Firehose into a Lambda transform; the Lambda's HTTP target inside the VPC is an internal NLB that "distributes TCP traffic to the OpenTelemetry collectors running on EC2 Instances in the internal subnet within the VPC." Different side of the public/ private boundary from the Oldcastle ingress pattern: same NLB primitive (Layer-4 TCP, source-IP preserving, fleet-scaled), but here used internally to fan out to a horizontally- scaled collector fleet from a Lambda-driven push pipeline. Pairs with patterns/firehose-lambda-transform-as-vpc-bridge as the Lambda-egress target inside the VPC.

  • sources/2026-04-21-aws-oldcastle-infor-aurora-quicksight-real-time-analytics — canonical wiki instance. Oldcastle APG uses an NLB with static Elastic IPs in public subnets as the stable ingress address for Infor Cloud ERP's outbound Data Fabric Stream Pipelines connections. Traffic flows NLB → EC2 RDS routers (iptables NAT) → RDS Proxy → Aurora.

Source

Last updated · 542 distilled / 1,571 read