How to Use IPv6 With AWS Services That Don't Support It

How to Use IPv6 With AWS Services That Don't Support It

Build an IPv6-to-IPv4 proxy using CloudFront to enable connectivity with IPv4-only AWS services.

By Michael Barney

IPv6 adoption is one of those industry changes that’s taking forever, but will eventually be everywhere. In AWS, support for IPv6 is still a hit or miss, making adoption tough. It can be a little frustrating when you’re trying to adopt IPv6 but a given service you’re integrating with doesn’t support it yet. Fortunately, we have a solution that enables you to make IPv6 requests but proxy them to an IPv4-only service. But first, some background.

There's a few reasons you may want to adopt IPv6 in your workloads. A common one is having a VPC-bound AWS Lambda function that needs to communicate with the internet, but the subnets your Lambda function is associated with do not route to a NAT Gateway. This is an issue because the Elastic Network Interfaces the Lambda service creates do not have an associated public IPv4 address, so they can't make their own internet-bound requests through the internet gateway. With IPv6 however, your Lambda function's network interfaces do receive a public IPv6 address, so your Lambda functions can communicate with the internet over IPv6 via an internet gateway or an egress-only internet gateway.

Another big reason to adopt IPv6 is that AWS has started to charge for public IPv4 addresses. That was announced in 2023, and that charge went into effect in February of 2024. This can be especially frustrating since at the time they started charging for IPv4 addresses, 88% of AWS service endpoints didn't support IPv6 at all. At the time of this writing, it's gotten a lot better (down to 58% of services that don’t support IPv6), but there's still a long way to go with popular services like Amazon DynamoDB still not supporting it.

It can be pretty frustrating if you're trying to adopt IPv6 in your workloads but the AWS service you need to call doesn't have an IPv6-enabled endpoint. Luckily, there's a way to work around this limitation for most services.



Maximize Your AWS Investment with Trek10 24/7 Monitoring



Amazon CloudFront to the Rescue

Amazon CloudFront, while typically meant to be a CDN for cached assets, can also be used as a generic HTTP proxy. You can use a custom origin to route requests to any HTTP endpoint, and CloudFront will handle the request and response. CloudFront distributions can be called over IPv6, and they can make requests to your origin over IPv4. So you can create a CloudFront distribution, use the regional DynamoDB endpoint as the origin, and have your workload call the CloudFront distribution over IPv6. This is a pretty simple pattern, but there are some caveats you should know about.

CachePolicyId

Be sure to configure the default cache behavior with the CachingDisabled cache policy. Without this, you may be caching requests that need to actually hit the AWS service.

AllowedMethods

You'll also need to support all HTTP methods in the AllowedMethods property. Some AWS API calls might be done over HTTP methods other than GET or HEAD, so your proxy must support those.

OriginRequestPolicyId

You'll need to specify the AllViewer origin request policy. Otherwise, as a request travels from caller to distribution, to origin, the CloudFront distribution will strip the Host header, replacing it with the domain of the origin. This default behavior will cause issues with AWS SigV4 though, as the host header is part of the signature, so a mismatched host header will cause signature verification to fail. The caller that signs the request will specify the Host header as the domain of your proxy, not the actual service endpoint itself. By specifying the AllViewer origin request policy, CloudFront will pass the Host header from the viewer request to the origin request, which will allow the signature verification to pass.

Once that's deployed, you'll have a proxy! You can call the CloudFront distribution from your workload:



Continue reading this post on Trek10.com


Reach out to our Brand Manager, Scott Sawaya awaya to learn more about Trek10 and ways we can help you reach your goals.



要查看或添加评论,请登录

Trek10, Inc.的更多文章

社区洞察