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 18.104.22.168, 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.
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|
|IoT Core||yes, by default||–|
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.
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:
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”.
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.|
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 not support IPv6.
Lambda does not support IPv6.
The AWS API is IPv4-only. amazon.com 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.
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.