Skip to content

CONCEPT Cited by 1 source

Static IP allowlisting

Static IP allowlisting is the common enterprise-integration requirement that an external caller can only reach a target at a fixed, stable, IP-addressable endpoint which the caller's firewall (or SaaS vendor config) can encode.

DNS-based endpoints and most cloud service endpoints resolve to IP addresses that change — elastic load balancers rotate IPs, databases change IPs on failover, auto-scaling fleets add/remove instances. That's fine when the caller can follow DNS; it's not fine when the caller is a managed SaaS whose egress firewall requires a pre-approved IP list.

The requirement in practice

Two common shapes generate static-IP-allowlist requirements:

  • External SaaS → private VPC resource. A managed SaaS (e.g. Infor Cloud ERP, Salesforce, Workday) needs to push events into a customer's private VPC. The customer can't expose the target service directly; the SaaS can't follow DNS updates through the customer's firewall.
  • Regulated outbound traffic. Corporate firewalls often allow-list only specific external IPs for compliance; reaching any dynamic-IP cloud service through such a firewall requires a known-static front door.

How AWS offers static IPs

  • Network Load Balancer with Elastic IP per AZ — the canonical mechanism. Bind an Elastic IP to each AZ's NLB listener; the IPs survive NLB scaling + instance replacement.
  • AWS Global Accelerator — two anycast static IPs that route to ALBs, NLBs, or EC2 instances in any region.
  • EC2 Elastic IP on a NAT router — direct binding of an EIP to an EC2 instance; used in hand-rolled NAT-routing patterns.

The NAT-router pattern

When the resource itself has dynamic IPs (e.g. an Aurora cluster that might fail over to a different node, changing its private IP), static-IP allowlisting is solved by putting a NAT-routing tier between the NLB and the dynamic-IP target. See patterns/nat-router-for-static-ip-ingress.

Seen in

Last updated · 476 distilled / 1,218 read