This course covers the core learning objective to meet the requirements of the 'Designing Network & Data Transfer solutions in AWS - Level 2' skill
- Understand the most appropriate AWS connectivity options to meet performance demands
- Understand the appropriate features and services to enhance and optimize connectivity to AWS public services such as Amazon S3 or Amazon DynamoDB.
- Understand the appropriate AWS data transfer service for migration and/or ingestion
- Apply an edge caching strategy to provide performance benefits for AWS solutions
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.
Work with Route 53
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:
Add a second custom header to the CloudFront distribution
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
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.
What if you wish to use HTTPS instead of HTTP?
What if you don’t or can’t allow public access to content?
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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.