The last three months have seen a large number of IPv6 announcements from AWS. I’ll recount some of them here:
- Organisations support IPv6 (link)
- IPv6 for EC2 public DNS names (link)
- Transfer family supports IPv6 (link)
- Managed Service for Apache Fink adds IPv6 (link)
- Resource Groups adds IPv6 support (link)
- EFS supports IPv6 (link)
- EFS supports IPv6 (link)
- Private CA supports IPv6 (link)
- Site-to-Site VPN supports IPv6 on outter tunnel endpoints (link)
- DataSync supports IPv6 (link)
- SNS expands IPv6 support to include VPC endpoints (link)
- SQS expands IPv6 support to include VPC endpoints (link)
- CloudWatch adds IPv6 support (link)
- EventBridge supports IPv6 (link)
Much of the public (Internet) facing endpoints for these services are now dual-stack, supporting both IPv4 and IPv6 (for now).
But have a think about the VPC endpoints that are now either dual stack, or IPv6 only: this increases the direct integrations for potential IPv6 only subnets, or massive sizes, to integration endpoints such as SQS and SNS. These scale-out VM farms can now have these loosely coupled integrations that can support the sale of millions of virtual machines; the rest of the VPC may be on traditional IPv4 only allocations, but having that layer of messaging is now highly valuable.
We’re at a point now where it is almost commonplace for dual-stack endpoints for most AWS cloud services; and it should be the same for endpoints that customers make on the AWS cloud. There’s very little holding you back – certainly not cost, and in some cases, cost is (or will likely be) the driving factor for the rapid uptake of IPv6, for those that are ready.