AWS: Ingress Traffic: Avoiding Public IPv4 Address Charges

2023-10-24

This is part of a blog series:

Part One: Cannot Escape IPv4
Part Two: Ingress Traffic: Avoiding Public IPv4 Address Charges (this part)
Part Three: Egress traffic and using the AWS APIs over IPv6 (not published yet)

Something that vaguely resembles a gloomy ingress construct

Introduction

AWS will soon start to charge customers for public IPv4 addresses. I recommend reading my ~~rant~~ analysis of the AWS announcement first: Cannot Escape IPv4.

This post will take a quick look at available options specifically for ingress traffic – how to get requests from end users to an application built on AWS.

The first goal is providing access to end users on both IPv4 and IPv6. Global IPv6 adoption is around 50% for end users¹, so it’s imperative to provide the best connectivity. At the same time, it’s still necessary to serve end users that are limited to IPv4.

The second goal is avoiding the AWS public IPv4 address charges – for reasons outlined in my previous post, I want to show that there is often no good way to avoid those charges. And because it helps IPv4 address conservation, of course. To be clear, I do not recommend actually doing this, as these charges will have a very small effect on the AWS bill; it would be silly to change architecture for a few bucks. For most customers.

Dedicated and Shared IPv4 Addresses

The new AWS IPv4 charges only apply to public IPv4 addresses that are dedicated, meaning that they are used exclusively by a single AWS customer.

For web (HTTP-based) applications, it’s common to use shared IP addresses, meaning many customers can be hosted on the same IP address (using HTTP Virtual Hosting and TLS SNI). Some AWS services provide centralized ingress using shared IP addresses – consequently, there are no IPv4 address charges with those services.

Ingress Services in Detail

The following table lists common AWS services used for ingress and their capabilities regarding the two goals.

Service	IPv4 ingress	IPv6 ingress	IPv6 to origin / VPC
Cloudfront (CDN)	✅	✅	❌
EC2 instances	❌	✅	✅
ECS (Fargate and EC2)	❌	✅	✅
Elastic Load Balancing	❌	✅	✅
Elastic Beanstalk	❌	❌	❌
App Runner	✅	❌	❌
API Gateway	✅	❌	❌
Amplify Hosting	✅	❌	n/a
AppSync	✅	❌	n/a
Global Accelerator	❌	✅	✅
Lambda Function URLs	✅	✅	✅
S3 Website Hosting²	✅	❌	n/a

All services support IPv4 ingress; the first column shows whether the service uses a shared IPv4 address (no charge) or a dedicated IPv4 address (incurs public IPv4 charges).

The last column is included for completeness; it’s not relevant to the two goals.

Elastic Load Balancer and Global Accelerator

Probably the most popular choice of ingress is Application Load Balancer, which routes HTTP requests to backend applications. For other non-HTTP applications, Network Load Balancer is a common choice. Global Accelerator can be used to provide public ingress IPs for (internal) Load Balancers and EC2 instances.

Fortunately, these AWS services do support IPv6 for ingress. Unfortunately, they do not allow to opt out of IPv4, so even if an application would only need IPv6, charges for multiple IPv4 addresses will apply. For a Load Balancer in three Availability Zones, this will be a base price increase of more than 50%.

As Load Balancers and Global Accelerator violate the second goal, we need to look at other AWS services to provide ingress.

API Gateway

API Gateway supports VPC Links on HTTP APIs. Together with proxy integrations, this allows some interesting combinations.

API Gateway can be combined with the Cloud Map service discovery to provide ingress for ECS Services. See this description on the AWS blog (2020) or the entry on “Containers on AWS” (2023, with SAM / Cloudformation).

API Gateway can also be the entry point for an internal Load Balancer which doesn’t use public IPv4 addresses.

API Gateway has some noteworthy limitations, like a maximum request duration of 30 seconds and no support for unencrypted HTTP. And no IPv6 support.

Elastic Beanstalk

Elastic Beanstalk orchestrates Elastic Load Balancer and compute resources. While the underlying resources do support IPv6, Elastic Beanstalk offers no way of configuring it. There are Github issues on the EB Roadmap that have been open and unanswered since 2021 for both ingress and VPC connectivity.

Elastic Beanstalk seemed somewhat abandoned for years, and this shows in its IPv6 support as well.

Others

For simple container-based applications, migrating to App Runner could be an interesting option. It does not support IPv6 though, and has its own set of limitations.

EC2 instances can run in IPv6-only subnets, so if no additional AWS services are required, this would be a good option.

Lambda Function URLs are a nice surprise, as they support IPv6 not only for ingress, but now also for egress (to VPC and to internet) – a feature added just a few days ago. Many existing applications are not easily migrated to Lambda though³.

Content Delivery Networks

When an AWS service has missing IPv6 support, this can usually be fixed by adding a Content Delivery Network (CDN) with support for IPv6 at the edge, like Cloudfront; many applications already use Cloudfront anyway. Cloudfront can serve IPv4 and IPv6 to end users, while talking to origin services over IPv4.

Cloudfront does not support IPv6 to origins though, so it would not help with IPv6-only EC2 instances. CDN competitor Cloudflare seized the opportunity to ~~make fun of AWS~~ help AWS customers out by offering a discount⁴ for using IPv6 origins on AWS. This allows to serve IPv4 and IPv6 end users while running IPv6-only EC2 instances. In many cases, a CDN can even be used for simple load balancing between EC2 instances.

One big drawback of not using Application Load Balancer in front of EC2 instances is the overhead for installing and managing TLS certificates.

Conclusion

When avoiding Elastic Load Balancers, which incur IPv4 address charges, the support for both IP protocols can usually be achieved by using a CDN. On the other hand, most workarounds to avoid Elastic Load Balancers are neither technically nor financially good ideas. If anything, this serves to show the weird state of IPv6 support on AWS.

I would love to see Elastic Load Balancing add the option to run without IPv4 addresses, combined with Cloudfront support for IPv6 origins. This combination would be a relatively easy fix for many setups, and it would be a big step towards making IPv6-only setups feasible.

But until AWS IPv6 support improves, the only sensible option for customers using Elastic Load Balancers is to just accept the upcoming IPv4 charges.