Amazon CloudFront Patterns

Contents

keyboard_tab
Amazon CloudFront Design Patterns
1
Introduction
PREVIEW2m 28s
4
Summary
1m 1s
Start course
Overview
Difficulty
Intermediate
Duration
16m
Students
22
Ratings
5/5
starstarstarstarstar
Description

In this course, we will be looking at Amazon CloudFront design patterns. We will begin by discussing some of CloudFront's key features before discussing two patterns:

  • Pattern 1 – Using CloudFront to cache and secure content when an Application Load Balancer is the origin
  • Pattern 2 – Using CloudFront to cache and secure content when an S3 bucket is the origin

Learning Objectives

By the end of this course, you will have a greater understanding of:

  • Amazon CloudFront's role in performance and security
  • Common CloudFront design patterns

Intended Audience

Anyone working with AWS Networking will benefit from this course, as well as those who are:

  • Studying for the AWS Networking Specialty certification
  • Studying for the AWS Solutions Architect certifications

If you want to increase your AWS knowledge, this course is for you.

Prerequisites 

Before attending this course, you should be familiar with Amazon Networking features such as VPCs and Elastic Load Balancers and have a basic understanding of Amazon CloudFront. Experience using Amazon S3 to store static website content would be an advantage.

Transcript

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.

About the Author

Mike has worked in IT since 1997, specializing in networking, storage, and architecture. He's been in cloud computing for the last 8 years, working across several cloud platforms but specializing in AWS. He's been involved in many cloud projects over the years covering migrations, hybrid connectivity, security optimization, networking, and storage architecture.

He gained his first training qualification in 1998 and, about 3 years ago, became an AWS Authorized Champion Instructor. He's delivered AWS cloud courses across Europe for a range of clients, with a focus on Architecture, Security, and Networking. He currently holds certifications for the four biggest cloud vendors, including the AWS Solutions Architect Professional, AWS DevOps Engineer, and AWS Advanced Networking specialty certifications.

He lives in the North of England with his wife Frances and their dog Inca.