SYSTEM Cited by 1 source
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-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.