Amazon CloudFront Design Patterns
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
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
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.
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.
In this section, we will review the purpose of Amazon CloudFront and its key features. The main role of CloudFront is caching of content. Caching allows us to store our content closer to the users that need it. If you have a website hosted in the EU-West-2 region, but a lot of your customers are in the US or Australia, they will have higher latency when compared to the users in the UK. But if we cache content closer to them, on 8-west edge locations in the US and Australia, their latency will be reduced. Amazon CloudFront allows customers to distribute content with low latency and high speed. Amazon CloudFront is a pay-as-you-use service. And when using CloudFront, files are delivered to end-users via a global network of edge locations.
CloudFront works with both static and dynamic content. For example, static content stored in Amazon S3 buckets. These static stores hold the definitive version of files. Dynamic content stored on Amazon EC2 or served up using Lambda functions. This content is generated on the compute resource and distributed through Amazon CloudFront. When working with CloudFront, you first create a CloudFront distribution. During this process, you identify one or more origins for the content that this distribution will serve the clients. You also configure options that control protocols that can be used such as HTTP or HTTPS; cache time to lives; custom headers; a price class, where its use all edge locations or a subset of locations; AWS WAF web ACL associations; alternate domain names; custom SSL certificates, and more. When creating a CloudFront distribution, you're assigned a domain name.
For example, 1234.cloudfront.net. Although you can use this domain name, most customers of Amazon CloudFront will add an alternate domain name to their distribution. A name such as cloudacademy.com is the mat to the CloudFront assigned name using DNS. In the following demonstration, we already have an Internet application load balancer load balancing traffic to our website. We will create a CloudFront distribution to cache our website content globally. We are in the CloudFront distribution center dashboard. To create a distribution, we select Create distribution. We then select our origin domain. The origin can be an AWS origin or we just type in the domain name of the origin that we wish CloudFront into cache. If I click in the 'Choose origin' domain box, we can see a list of valid ADS origins, including S3 buckets and our application load balancer.
I'm going to select the application load balancer. With the load balancer selected, you then get to choose protocol information and port information that the distribution will use when connecting to the load balancer. If I scroll down a little bit, we get to choose an origin name. We can accept the default name for the origin or choose a name that's more meaningful for us. There is a lot of optional information we can select. A lot of these settings are discussed later on in this course. If I scroll down a little bit, we can find settings that allow us to configure cache behavior. If I scroll down a little bit more, we find the pricing class. The pricing class allows us to choose groupings of edge locations that our distribution will use to cache content. We can choose to associate our WAF ACL with our distribution, and we can select an alternate domain name for our distribution.
Most deployments will use an alternate domain name, so that we can use our own nice friendly DNS names instead of having to rely on the CloudFront DNS name. If you choose to use an alternate domain name, you'll also need to select a digital certificate. The digital certificate can be imported from your own certificate stars, or we can search certificate from Amazon certificate manager. If I scroll down a bit more, we can enable standard logging file distribution, so that we can log viewer requests into an S3 bucket. You can also turn on or off support for IPv6. If you're happy with our choices, select Create distribution. Once you've selected distribution, you should see a message saying that your distribution is being deployed.
Although we often discuss CloudFront as a single cache, actually CloudFront has three cache in layers. Cloudfront distributions, these exist over 300 Amazon edge locations globally. Regional edge caches, and at the time of writing there are 13 regional edge caches. And AWS Origin shield, an additional cache in layer between your regional edge caches and the origins. Origin shield is not enabled by default. You must enable it for each origin in the distributions you create. By having multiple cache layers, you can cache more content for longer. Using regional caches and origin shield, you get better cache hit ratios. Because more of your content is cached, there is a much better chance that the content your customers need will be retrieved from cache. Reduced origin load: With more content being served from cache, less requests are sent to origins.
And when using origin shield, requests for the same object not in cache are consolidated, so only a single request is sent to the origin. Better network performance: Using multiple layers, content can stay on the AWS Lola into network for longer. CloudFront has a long list of security features. These include CloudFront use of SSDs, which are encrypted protecting your data at rest. We can use signed URLs and cookies to restrict access to content that is intended for specific users. We can use AWS WAF to create web ACLs to restrict access to content, and we can use geo restrictions to prevent users in certain regions from accessing content. For more information on AWS WAF, please refer to our existing class content here. Amazon CloudFront itself integrates with identity and access management, which we can use to control administrative access to CloudFront. And CloudFront can be monitored through integration with: Amazon CloudWatch alarms, AWS CloudTrail Logs, and CloudFront real-time IAM standard logs.
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.