As we enter 2022, Google’s IPv6 Adoption statistics are showing 35% of their worldwide traffic coming from IPv6-ready users, and within the United States this figure is just passing 50%. (If you want to know where you fall, try a quick IPv6 Test today!)
Out of the several huge cloud providers, Amazon Web Services has added good support for building IPv6 networks, hosting IPv6 services, and configuring ‘dual-stack’ DNS names with the AAAA records that advertise IPv6 capability. But the AWS APIs themselves are still only reachable using IPv4 networking. That’s because AWS hasn’t added AAAA records to any of their existing API endpoints. Some customers may have their own special configurations such as IPv4-based VPNs or access control, and breaking API access isn’t ideal.
Amazon knows that IPv6 support is desired, though, and several important AWS services have gained additional dual-stack endpoints which can be used by anyone who wants to leverage IPv6 connectivity whenever possible. Unfortunately, these new endpoints are not default and so the programmer must make a conscious decision to use them.
So which services have IPv6-ready endpoints? First let’s check out the blog posts 😄
| Date | Blog post |
|---|---|
| 2016-08-11 | Now Available – IPv6 Support for Amazon S3 |
| 2016-10-06 | IPv6 Support Update – [...] S3 Transfer Acceleration |
| 2020-05-26 | Amazon S3 adds support for IPv6 protocol in AWS China [...] |
| 2021-01-11 | Amazon EC2 API now supports Internet Protocol Version 6 (IPv6) |
| 2021-12-21 | AWS Lambda now supports Internet Protocol Version 6 (IPv6) [...] |
Additionally, Reddit user SureElk6 pointed out that several services support IPv6 at their normal endpoints without any fanfare. There’s no relevant blog post for these:
That’s ~10 services ready to go as of the end of 2021 depending on how you count. This is a far cry from the 250+ APIs that are on offer overall, and it’ll be another while before key services - such as DynamoDB, STS, and SQS - are all accessible from an IPv6-only network.
Now let's look at each service more closely and see how they differ:
s3.dualstack.$REGION.amazonaws.com
s3-accelerate.dualstack.amazonaws.com (global endpoint)
s3.dualstack.$REGION.amazonaws.com.cn
AAAA records.
api.ec2.$REGION.aws
us-east-1, us-east-2, us-west-2, ap-south-1, eu-west-1, sa-east-1
lambda.$REGION.api.aws
lambda.$REGION.api.amazonwebservices.com.cn
cognito-identity.$REGION.amazonaws.com
AAAA records seen in ISO or China regions.
secretsmanager.$REGION.amazonaws.com (the default)
secretsmanager.$REGION.amazonaws.com.cn
AAAA recordset I see in cn-north-1.
IoT is comprised of about a dozen “services”, and only two of them have AAAA records:
I don’t fully understand how AWS IoT works, but when you look up your account-specific Data Plane endpoint as per the documentation it should have IPv6 support. The main control plane APIs remain IPv4-only.
Ok, I know consistency is hard, but both different services launched so far underneath the new .aws gTLD are using a different pattern. Check it out:
api.ec2.$REGION.aws
lambda.$REGION.api.aws
AWS already blew their chance at keeping their own gTLD consistent! Keeping support for existing, working code means that changing either one would be a whole ordeal. So I look forward to seeing SDKs handle this weirdness for the next decade. The Javascript SDK already refers to EC2’s dualstack as “legacy”!
In general, it’s pretty cool to see shorter AWS API endpoints via their Brand gTLD. I hope to see more services launch under this new name over time. And for AWS China users it’s good to know that .amazonwebservices.com.cn will be standing in for the .aws gTLD as services relaunch.
Most importantly, if you are using an API which I’ve discussed here, and want to show Amazon your support for IPv6, make sure to configure your SDK to use dual-stack endpoints when available. How this is done will depend on the specific SDK, so if in doubt, go ahead and consult the documentation 😅