In addition to the 450+ edge POPs that AWS maintains around the world, there are additional dedicated POPs positioned inside the networks of many ISPs/broadband providers around the world. These are known as Amazon CloudFront Embedded POPs, and they are based on AWS Outposts Rack or AWS Outposts Server (depending on the circumstances).

Figure 8.8 – Amazon CloudFront Embedded POPs

Large content providers such as NetFlix, HBO Max, and Amazon Prime use Amazon CloudFront to stream video to homes around the globe. These entities often negotiate with large ISPs to install these dedicated POPs into their networks for the explicit purpose of servicing, say, HBO Max viewers who are also Comcast customers. This preserves the ISP’s bandwidth at their peering points and ensures a good user experience for the customers of the content provider. Over 220 of these were deployed in 2022 alone.

HTTP/3 and QUIC

Recall Chapter 2, when we covered the benefits of HTTP/3 and QUIC over TCP-based HTTP/2 and HTTP/1.1. Those benefits can be realized at the click of a button in an Amazon CloudFront distribution:

Figure 8.9 – Enabling HTTP/3 for an Amazon CloudFront distribution

AWS has implemented HTTP/3 and QUIC on the Amazon CloudFront servers found in all edge POPs. Because those servers are full proxies between the viewer and the origin, no changes need to be made to the origin for this to work. Take a look at the following figure for an illustration of this:

Figure 8.10 – HTTP/3 – QUIC distribution with no application changes

AWS Lambda@Edge

As we discussed earlier, there are times when the request headers Amazon CloudFront passes to the origin don’t include enough information to make an appropriate decision about which object to return – or if we should respond at all. Sometimes, we need additional logic to make those determinations.

Let’s imagine we have a type of content subject to legal restrictions that say we can only serve it to requesters not located in a certain country. We can easily geo-restrict this object based on the Amazon CloudFront geolocation headers – per the documentation, these are 99.8% accurate. However, they don’t tell us if someone is using a VPN provider to appear as an IP in the correct location. As part of a mitigation strategy for this, we could cross-check the IP against a list of known VPN provider network prefixes.

An AWS Lambda function is ideal for something like this. AWS Lambda@Edge is just a version of AWS Lambda that runs in the RECs to be closer to the edge:

Figure 8.11 – Using AWS Lambda@Edge to alter HTTP response when errors occur

The preceding figure shows an example of using AWS Lambda@Edge to intercept an HTTP status code 500 error that an application behind an ALB generated. Instead of forwarding this raw error message to the viewer, this function is rewriting a new HTTP request for a specific object in an S3 bucket, and returning that to the user instead. This is commonly done to provide more elegant feedback to the end user. This is an example of an AWS Lambda@Edge function that is tied to the origin’s response. That means it is triggered by, and works with, the response data from the ALB – as opposed to the inbound request data heading toward the origin.

The following figure shows the four different stages an AWS Lambda@Edge function can be associated with:

Figure 8.12 – Association types available for AWS Lambda@Edge

Note that AWS Lambda@Edge functions are somewhat limited compared to their counterparts running in the core regions. For instance, while an AWS Lambda function in a region can run for 15 minutes, those tied to the origin request/response have a maximum duration of 30 seconds, while those tied to the viewer request/response top out at 5 seconds. They also support a much more limited set of runtimes than those in regions. Check the Amazon CloudFront Developer Guide for more details.