AWS now charges for public IPv4 — how do I redesign to avoid it?
Choose whether to redesign networking around IPv4 charges, NAT, ALB/NLB placement, and private connectivity now that public IPv4 billing meaningfully affects small and medium deployments.
Blockers
- Clients must connect to an ALB using dualstack-without-public-ipv4 over IPv6.
- ALB authentication to an external IdP or Amazon Cognito only supports IPv4.
- Internet-facing load balancer nodes use public IPv4 addresses unless using the dualstack-without-public-ipv4 mode.
Who this is for
- cost-sensitive
- small-team
- low-ops
- enterprise
- compliance
- microservices
Candidates
Keep one public edge load balancer and move all backends private
As of 2026-03-15, AWS charges "$0.005" per hour for both in-use and idle public IPv4 addresses. Internet-facing load balancer nodes use public IP addresses, but AWS documents that both internet-facing and internal load balancers send traffic to targets over private IPs, so the practical cost-avoidance move is usually to remove public IPv4 from EC2, ECS, EKS worker nodes, and databases first and keep only the public edge.
When to choose
Best for small-team + low-ops + cost-sensitive deployments that must remain reachable by normal IPv4 clients, want minimal migration risk, and can accept paying for the public IPv4 addresses consumed by the edge load balancer while making app and data tiers private.
Tradeoffs
This is the least disruptive redesign and usually captures the biggest savings fast because it removes per-instance public IPv4 usage without changing the public entry pattern. The tradeoff is that the load balancer still incurs public IPv4 charges and normal ELB hourly plus LCU or NLCU pricing.
Cautions
Do not assume the public-IP bill is only Elastic IPs you allocated manually. AWS Public IP Insights lists service-managed IPs too, including ALB, NLB, and public NAT gateways. Internet-facing NLBs have one IP address per enabled Availability Zone; ALB public IPv4 addresses are service-managed by AWS.
Sources
- aws.amazon.com/vpc/pricing/
- aws.amazon.com/elasticloadbalancing/pricing/
- docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html
- docs.aws.amazon.com/vpc/latest/ipam/view-public-ip-insights.html
- docs.aws.amazon.com/elasticloadbalancing/latest/network/availability-zones.html
Use an internet-facing ALB with "dualstack-without-public-ipv4"
As of 2026-03-15, Application Load Balancer supports the `dualstack-without-public-ipv4` IP address type. AWS documents that clients must connect to that ALB over IPv6, which lets you remove the ALB's public IPv4 addresses while still using private IPv4 or IPv6 toward targets.
When to choose
Best for cost-sensitive + small-team or enterprise deployments where the public edge can be IPv6-first, your clients or upstream network path are known to support IPv6, and you want to cut public IPv4 charges at the load balancer itself rather than only behind it.
Tradeoffs
This can remove the public IPv4 charge for the ALB while keeping managed Layer 7 routing, TLS termination, and private targets. The tradeoff is compatibility: IPv4-only clients cannot connect directly, and this option is not available for the `internal` load balancer scheme.
Cautions
AWS documents a hard caveat for ALB authentication: when the ALB needs to connect to an external IdP or Amazon Cognito, authentication only supports IPv4. Without a public IPv4 address, the ALB can return HTTP 500 errors. Validate DNS, client networks, and auth flows before adopting this.
Minimize or remove NAT by using gateway endpoints, selective interface endpoints, and IPv6 egress where possible
As of 2026-03-15, AWS still charges NAT gateways by the hour and per gigabyte processed. AWS also documents that gateway endpoints for S3 and DynamoDB require no internet gateway or NAT device and have no additional charge, while interface endpoints are billed per hour per Availability Zone and per gigabyte processed.
When to choose
Best for cost-sensitive + enterprise or microservices environments where most private-subnet traffic goes to AWS services, you want to reduce both NAT spend and public IPv4 usage, and the team can manage endpoint routing and per-service private DNS intentionally. This is especially attractive when S3 and DynamoDB traffic is large and general internet egress is small.
Tradeoffs
Gateway endpoints are the highest-leverage replacement because they are free and bypass NAT for S3 and DynamoDB. Interface endpoints improve private connectivity to many AWS and SaaS services, but enough per-AZ endpoints can become a meaningful fixed monthly cost. IPv6 plus an egress-only internet gateway can remove the need for NAT for outbound IPv6 traffic, but it does not solve IPv4-only destinations.
Cautions
Do not blindly replace one NAT gateway with many interface endpoints without checking the exact regional bill. AWS recommends keeping resources in the same Availability Zone as the NAT gateway or creating one per AZ when traffic volume is high to avoid extra cross-AZ data transfer. Check current regional PrivateLink pricing before expanding endpoint coverage.
Use internal ALB or NLB for private consumers and expose services through private connectivity instead of the public internet
As of 2026-03-15, AWS documents that internal load balancer nodes have only private IP addresses, and that Network Load Balancers support clients over VPC peering, VPN, Direct Connect, and similar private paths. AWS PrivateLink lets consumers create interface endpoints for private connectivity, billed per endpoint-hour in each Availability Zone and per gigabyte processed.
When to choose
Best for enterprise + compliance or microservices deployments where callers are other VPCs, accounts, on-prem networks, or partner environments, and you want to eliminate public internet exposure rather than just optimize public IPv4 count. This is the right pattern when public access is not a requirement and private-network reachability is.
Tradeoffs
This removes public IPv4 from the service entry path and can simplify security review by keeping traffic on private paths. The tradeoff is more network coordination, more DNS and routing work, and recurring endpoint costs for consumers when PrivateLink is used.
Cautions
Internal load balancers are not public entry points. AWS notes their DNS names resolve to private IP addresses, so consumers need VPC or connected-network access. For NLB specifically, each enabled Availability Zone has one load balancer IP address, and internal dualstack access through an internet gateway is blocked.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "AWS now charges for public IPv4 — how do I redesign to avoid it?"