This week I’ll focus a bit on some changes in the networking stack. Today there was a wonderful announcement about a managed Prefix List for CloudFront and lately there have been a lot of IPv6 related announcements.

CloudFront Managed Prefix List

From a networking perspective, one of my favourite announcements in the past couple of years was customer managed Prefix Lists. These are lists of CIDR ranges that you can create (and share across accounts) for IP ranges that are used across your applications and attach them to a security group or route table. An example I’ve used it for is the IPs of a VPN so that these could easily be whitelisted in the applications that were used.

The clear advantage of using these is that you can then manage these in a single place and if you make a change to your infrastructure it can be updated everywhere at once¹. Of course, these prefix lists didn’t come out of nowhere and AWS had been using them already for the VPC Gateway Endpoints for S3 and DynamoDB but that’s all they had until today.

Because when I did my daily check of AWS announcements² I noticed we got a wonderful little surprise. AWS created another managed prefix list, and this time for their CloudFront IP ranges. In case you’re not immediately aware of what this means, imagine a common network setup. You have your EC2 instances in a private subnet, in front of that an ALB in a public subnet, and on top of that you’ve got CloudFront. At this point while your ALB is public, you only want it to be accessed from CloudFront³.

One of the most common steps here is then to limit the ingress on your ALB to CloudFront IPs only. Unfortunately, this is a big list of IPs that tends to change frequently. So, for a long time the not very great solution to this problem was to have a Lambda function run frequently and update the security group with the latest IPs. There were a number of Lambda functions floating around for this, or people designed them themselves, and AWS even wrote a blogpost containing their Lambda function for this.

This means that every day there were many thousands of Lambda functions running to update security groups across the world. And now, none of them are needed anymore. Instead, you can add the prefix list com.amazonaws.global.cloudfront.origin-facing to your security group and get rid of all these Lambda functions.

One thing to note here is that while prefix lists only look like a single line in your security group, they have an actual “weight” attached to them. This weight represents how many CIDR ranges there are, and it is these ranges that count against your security group size limits. Currently this weight for the CloudFront Prefix List is at 55, which means that it barely fits into the default limit of 60 rules, but I recommend that you increase this limit to be certain that you don’t have to worry about an update to the prefix list breaks your setup.

IPv6 All The Things

AWS has had some support for IPv6⁴ inside VPCs for quite a while now, but it was fairly limited as it was still coupled to IPv4 which they call dual-stack. And well, the use of an IPv6 address range is far more limited when you also have to use an IPv4 range. Luckily for proponents of IPv6, the US government decided they are going to require IPv6, putting it higher on AWS' todo list.

So, right before re:Invent, AWS introduced the ability to have IPv6-only subnets and EC2 instances⁵. Which means that while the VPC itself still has to be dual-stack, you don’t actually have to use the IPv4 range for anything if you don’t want to. At the same time they also updated the IPv6 support for ALBs and NLBs, so these can actually address IPv6-only instances and can work internally-facing as well, and introduced support in NAT Gateways and Route53 Resolver for accessing IPv4-only networks from IPv6 instances.

All of this combined made for a good start with IPv6 networking, but it didn’t stop there either. A couple of weeks after re:Invent, AWS announced new dual-stack service endpoints for Lambda. This means that if you access your Lambda’s from within a VPC using these endpoints, the traffic can be fully IPv6. And again a couple weeks later AWS then released IPv6-only support for EKS. Which means that you can now run your EKS clusters in IPv6-only mode.

IPv6 for EKS has some caveats, like only being able to decide on cluster creation (you can’t have both IPv4 and IPv6 either) and no support for Windows containers. But it obviously makes it a lot easier to run a lot of pods when you don’t have to worry about the number of IPs you can assign to a node. And best of all, it works with Fargate too⁶! That said, if you think it sounds interesting for you, I recommend reading this more technical blog post from AWS that describes everything that’s needed as well as how traffic flows work.

Of course, one question that comes to mind with the earlier announcement is whether and when AWS will update CloudFront to use IPv6 to connect to your backend. As at the moment load balancers are still at best dual-stack, IPv4 will work if you serve your content through these load balancers, but I suspect it doesn’t work as well with IPv6-only EC2 instances. Having a prefix list to manage CloudFront IPs seems like a necessary step to enable this as it will likely require a lot of CIDR ranges, so I suspect this is part of the move to IPv6. But then, they better update the default limits for those security groups as well.