In this section, we will discuss two examples of using CloudFront to cache and secure access to content.

Pattern 1 – Using CloudFront to cache and secure content when an Application Load Balancer is the Origin.

In this pattern we have an Application Load Balancer, load balancing HTTP port 80 and HTTPS port 443 traffic to a set of EC2 instances hosting a website. To integrate with CloudFront we would create a CloudFront distribution with the application load balancer as the origin. It is worth remembering that CloudFront can work with any public endpoint whether AWS or external. This Load Balancer will be an internet-facing load balancer.

For this pattern to work, we will need to do a couple of things.

1. Work with Route 53

2. Secure connections to the application load balancer

Originally the nice friendly name for your website will be mapped to the name of the application load balancer, but now we want the friendly name of your website to route people through CloudFront. For this to work, we need to edit the Alias record in Route53 to map the friendly name to the DNS name that CloudFront has provided you when you created your distribution. Remember we are using an internet-facing load balancer, so if someone knows the DNS name of the load balancer or its IP addresses then they might be able to connect to load balancer directly, bypassing your CloudFront distribution and the performance and security benefits it provides. To secure the connection between our CloudFront distribution and the Application Load Balancer we can do the following:

Firstly, Configure CloudFront to add a custom HTTP header to requests. When creating or editing your CloudFront distribution add a custom header. The custom header will be included in each request sent to the origin. Next. Configure an Application Load Balancer to only forward requests that contain a specific header. To do this we need to select the listeners configured on the load balancer and edit its rules. We then adjust the rules:

Rule 1: if the custom header is included in the request forward traffic to the target group. 

Rule last: If the request does not include the custom header then return a 403 error.

With everything saved, if someone tries to access your website using the Application Load Balancers hostname or IP Addresses they should see a 403 error similar to the error below. By using HTTPS for origin requests we are configuring an encrypted connection between our distribution and the Load Balancer. This will help keep your custom header secret. This setting is configured on your CloudFront distribution and requires the appropriate secure listener to be configured on your Application Load Balancer. It is important you rotate the custom header in your distribution and on the load balancer. If you do not rotate the custom header then over time there is a greater chance that the header name and value will be discovered undermining your security.

To do this:

1. Add a second custom header to the CloudFront distribution

2. Add a new rule to the load balancer listener that uses the new custom header as the condition and forwards traffic to the target group

3. Remove the old custom header and rule from the cloudfront distribution and the load balancer listener

Pattern 2 – Using CloudFront to cache and secure content when an S3 bucket is the origin

Using S3 to deliver content is a common feature of many AWS Architectures, in S3 content is stored in buckets and buckets are in a single region. Because of this your applications can suffer from latency issues if you have customers globally who need to access content from a centralized bucket. CloudFront can help solve this problem by allowing content to be cached closer to the users who need to access it. We can also use S3 to host a website, this has lots of advantages, one of which is we no longer need compute resources such as EC2 to host our static content. When using S3 to host static content we:

• Create a bucket and enable it for static website hosting
• Then Enable public read access on the bucket

You will be given a URL that can be used to access your index document, S3 only supports HTTP access when using static website hosting. We have several problems here.

1. What if you wish to use HTTPS instead of HTTP?

2. What if you don’t or can’t allow public access to content?

3. What about latency? Our website is still stored in a bucket in a single region

CloudFront can solve these issues.

• CloudFront can distribute your content globally reducing latency for your customers.
• When we create a CloudFront distribution we can add an alternate domain name and a certificate allowing us to use or even enforce HTTPS.  
• We can also remove public access to the S3 bucket and secure access so that only the CloudFront distribution can access content.

To enable HTTPS you will need a digital certificate. AWS provides the AWS Certificate Manager service (ACM), through which we can request digital certificates for free. Using ACM we can request internal certificates or trusted public certificates. If you are planning on integrating your CloudFront distribution with AWS Certificate Manager  (ACM) please keep in mind that CloudFront works with ACM in the North Virginia region. It is from here that you should create your certificate requests.

To make sure that only your distribution can request content from your S3 bucket and to allow you to remove the public access that static website hosting needs, we use Origin Access Identity (OAI) and S3 Bucket Policies. This process is important, without it users could still use the bucket's URL to access your content, by passing the security and performance benefits of CloudFront.

Begin by creating an Origin Access Identity (OAI) in cloudfront and then associate it with your CloudFront distribution. Here you can see an OAI that has been created in the CloudFront console, notice the Name and ID. Next, you can see that we have associated the newly created OAI with our distribution

You can then select the option to automatically update the bucket policy of the S3 bucket or you can edit the bucket policy yourself. Here we can see the bucket policy that would be created on the S3 bucket that contains our content. We can see that the principal is the ARN of the OAI and that the effect is set to allow. You can adjust the actions as required, here we are allowing the S3.GetObject action on the bucket. 

Finally, notice that public access is blocked. If someone was to obtain the bucket url and tried to access content using the url they would receive an access denied message. But if they use your friendly name mapped to the CloudFront distribution DNS name then access will be allowed. Here is an example of how that record might look in Route 53, we use an alias record mapped to the distribution DNS name.