Getting started with IPv6 on AWS

Michael WittigUpdated 14 Nov 2020

In mid-2019, AWS paid ~$108M to access 4 million IPv4 addresses from Amateur Radio Digital Communications - $27 per IP address. The reason why AWS spends so much money on IPv4 addresses is simple: There are no free IPv4 addresses that regional internet registries (such as ICANN) can assign anymore. IPv4 addresses, such as, have become a scarce resource. That’s one motivation to move on to the successor: IPv6. The notable difference for many of us is that IPv6 addresses are much longer. Instead of the 32-bit IPv4 addresses, IPv6 uses 128-bit addresses.

With 32 bits, the IP address space contains 232 or 4.3 billion possible addresses. Given that 7.5 billion people live on earth, you get the problem. The mind-blowing fact is that going to 128 bit expands the IP address space to 2128 or 340 sextillions. The number is too big to imagine it. The bottom line is, IPv6 overcomes the problem of IPv4 address scarcity. But that’s not the only benefit.


Do you prefer listening to a podcast episode over reading a blog post? Here you go!

Much of the improvements of IPv6 will never be noticed by most of us - including myself. And that’s fine. Isn’t it great that AWS solves all those challenges for us, and we can just make use of IPv6? The rest of this post outlines your IPv6 on AWS journey.

Public services first

Before you think about designing your IPv6 network, you should enable IPv6 alongside IPv4 on endpoints accessed by end-users. Around 30% of Internet traffic is already IPv6 traffic. The IPv6 deployment progress is mainly driven by mobile devices and varies heavily between countries.

Service Ipv6 support? Implementation Detail
Route53 yes, by default -
CloudFront yes, optional Don't forget to add a DNS AAAA Alias record.
S3 yes, optional Use dual-stack endpoints
API Gateway REST EDGE no -
API Gateway REST REGIONAL no, workaround available Put an IPv6 enabled CloudFront distribution in front of the regional API Gateway
AppSync no -
IoT Core yes, by default -
Global Accelerator no -

CloudFront will always communicate to the origin in IPv4!

You might ask yourself why load balancers are missing on this list. The reason is that load balancers run in a VPC. You need an IPv6 enabled VPC before you can enable IPv6 on a load balancer. The next section will cover this.

Enable IPv6 in your VPC

First of all, there is no IPv6-only VPC on AWS. A VPC is always IPv4 enabled, but you can optionally enable IPv6 (dual-stack). When you do so, AWS assigns a /56 block of IPv6 Global Unicast Addresses (GUA) to your VPC - you can bring your own block as well. A GUA is like a public IPv4 address. You can assign each subnet in your VPC a /64 sub-block. There is no VPC/subnet size planing anymore!

To connect to the Internet, you have two options:

  • Internet Gateway: Resources can send and receive packets from the Internet.
  • Egress-only internet gateways: Resources can send packets to the Internet.

There are no NAT Gateways/Instances anymore! If you want to talk to the Internet over IPv6, you need an IPv6 GUA. End-to-end connectivity is the goal of IPv6.

There are no private IPv6 addresses in an IPv6 VPC. You could use Link Local Addresses to talk to other ENIs on the same subnet. Link Local IPv6 traffic is only allowed if the ENI has an IPv6 GUA.

A typical Public/Private VPC setup with IPv6 support can look like this:

Topology of VPC with IPv6

After the VPC is IPv6 ready, ENIs can get an IPv6 GUA assigned besides the IPv4 private (and public) address. By default, DHCPv6 is used to allocated IPv6 addresses. You can manually specify IPv6 addresses as well (not recommended). Security Groups are still used to protect ENIs inbound and outbound and are the way to implement “defense in depth”.

Want to learn more about IPv6 on AWS? The following video shows how to configure a VPC and EC2 for the use with IPv6.

Load balancers

As soon as your VPC is IPv6 enabled, you can deploy your public ALBs with IPv6 support as well.

Load Balancer Type Scheme Ipv6 support? Implementation Detail
Application internet-facing yes, optional Don’t forget to add an DNS AAAA Alias record.
Application internal no
Network internet-facing yes, optional Don’t forget to add an DNS AAAA Alias record.
Network internal no
Classic internet-facing no
Classic internet no

ALB will always communicate to the target in IPv4!


IPv6 is supported on all current generation EC2 instance types and the C3, R3, and I2 previous generation instance types. Depending on your subnet configuration (Auto-assign IPv6), an EC2 instance will automatically receive an IPv6 GUA, or you have to request one explicitly.

Unfortunately, CloudFormation does not allow us to configure a subnet with Auto-assign IPv4 and Auto-assign IPv6). But it is possible with the CLI, UI, and SDKs.

RDS does not support IPv6.

Fargate does support IPv6.

Lambda does not support IPv6.


The AWS API is IPv4-only. is IPv4-only as well :)


IPv6 is coming. At some point in time, you have to start your journey towards IPv6. For now, I recommend enabling IPv6 for the endpoints that are used by your end-users.

There is not much benefit in enabling IPv6 in your VPC yet. The only exception is if you want IPv6 support for your ALB. As a workaround, you can front the IPv4 ALB with CloudFront to offer IPv6 to your end-users.

Learn more

I recommend a re:Invent talk from 2017: IPv6 in the Cloud: Protocol and AWS Service Overview (NET202). Besides that, I read IPv6 Essentials from Silvia Hagen (O’Reilly), which goes into the details (far beyond what you need to get IPv6 working on AWS).

Thanks to Thorsten Höger for reviewing this article.

Michael Wittig

Michael Wittig

I’ve been building on AWS since 2012 together with my brother Andreas. We are sharing our insights into all things AWS on cloudonaut and have written the book AWS in Action. Besides that, we’re currently working on bucketAV, HyperEnv for GitHub Actions, and marbot.

Here are the contact options for feedback and questions.