Internet users are always impressed with websites’ high speed & loading capacities. Why not have a website that loads the content quickly and delivers fast with AWS CloudFront?
In this tutorial, you learn What AWS CloudFront is which enables users to retrieve content quickly by utilizing the concept of caching.
Let’s get started.
Table of Content
- What is AWS CloudFront?
- What are use cases for CloudFront?
- What is CloudFront Managed Prefix List
- How AWS CloudFront delivers content to your users
- Amazon CloudFront caching with regional edge caches
- AWS Global Accelerator
- CloudFront vs Global Accelerator
- Alternate domain names (CNAMEs)
- SSL Certificates in CloudFront
- SSL connectivity from Client Side
- CloudFront Policies
- AWS WAF and AWS CloudFront
- HTTPS connectivity with AWS CloudFront
- Using Amazon EC2 as the Origins in the AWS CloudFront
- How CloudFront access content of AWS S3 Bucket.
- How CloudFront access content of AWS ELB.
- Functions at Edge
- CloudFront Functions
- Lambda@Edge
- Security in CloudFront
- Allow users to access CloudFront programmatically
- Using Amazon EC2 as the Origins in the AWS CloudFront
- Conclusion
What is AWS CloudFront?
AWS Cloud front is an Amazon web service also known as Content delivery network ( CDN ) that speeds up the distribution of static and dynamic content such as .html, .css, .js, images, live streaming of video to users. Cloud front delivers the content quickly using edge locations when the request is requested by users as the content is cached at the edge location.
CDN is content delivery network which improves the performance of the application by caching the data at edge. There are 216 points of present available as of now and are also known as Edge location.
- If the content is not available in edge locations, Cloud front requests from the origin configured such as AWS S3 bucket, HTTP server or Load Balancer, etc. Also, the use of Lambda at edge location with Cloud Front adds more ways to customize Cloud Front.
- Cloud front can be used as an ingress to upload files in AWS S3 when AWS S3 bucket is set as origin. If the Origin is AWS S3 bucket then you also need Origin access control policy and AWS S3 bucket policy. OAC allows access to Cloud Front.
- ALB or EC2 as an origin: If EC2 is origin then allows Public IP of Edge location in security groups attached to EC2 instance. However if you have ALB as public load balancer then it must be public and allow security group of load balancer which is attached to EC2 instance.
- Note: If case you update backend data but TTL is not expired then Cloud Front will deliver old data but in order to get refreshed data you may force an entire or partial cache refresh by performing CloudFront Invalidation. You may invalidate using * or by special path ( /images/*) just like akamai caching.
- Whether you want CloudFront to log information about each request for an object and store the log files in an Amazon S3 bucket.
When CloudFront receives a request, CloudFront attempts to match the URI path to the correct cache behavior based on the path pattern and priority you defined. Every CloudFront distribution includes a default cache behavior that matches when no other cache behaviors match the request. For example, you can configure a cache behavior for the /api/* path that routes to API Gateway and disables caching, while your default cache behavior routes to your static website in an S3 bucket where all content is cached.
What are use cases for CloudFront?
Some of the use cases of Cloud front are:
- It accelerate static website content delivery.
- Serve video on demand or live streaming video.
- Encrypt specific fields through system processing.
- Customise the edge. Using Lambda@Edge can help you configure your CloudFront distribution to serve private content from your own custom origin, in addition to using signed URLs or signed cookies.
What is CloudFront Managed Prefix List
CloudFront managed prefix list contains the IP address ranges of all of CloudFront’ s globally distributed origin-facing servers. If your origin is hosted on AWS and protected by an Amazon VPC security group, you can use the CloudFront managed prefix list to allow inbound traffic to your origin only from CloudFront’ s origin-facing servers, preventing any non-CloudFront traffic from reaching your origin.
How AWS CloudFront delivers content to your users
Now that you have a basic idea of CloudFront knowing how AWS CloudFront delivers content to users is also important.
Initially, when users request a website or application such as example.com/mypage.html, the DNS server routes the request to AWS CloudFront edge locations.
Next CloudFront checks if the request can be fulfilled with edge location; else, CloudFront queries to the origin server. The Origin server sends the files back to the edge location, and further Cloudfront sends them back to the user.
Amazon CloudFront caching with regional edge caches
Delivering the content from the edge location is fine. Still, if you to further improve the performance and latency of content, there is a further caching mechanism based on region, known as regional edge cache.
Regional edge caches help with all types of content, particularly content that becomes less popular over time, such as user-generated content, videos, photos, e-commerce assets such as product photos and videos, etc.
Regional edge cache sits in between the origin server and edge locations. The Edge location stores the content and cache, but when the content is too old it removes it from its cache and forwards it to the regional cache, which has wide coverage to store lots of content.
- Proxy HTTP methods (
PUT,POST,PATCH,OPTIONS, andDELETE) go directly to the origin from the POPs and do not proxy through the regional edge caches. - Dynamic requests, as determined at request time, do not flow through regional edge caches, but go directly to the origin.
- A cache invalidation request removes an object from both POP caches and regional edge caches before it expires.
Cloud Front vs S3 Cross Region replication: Cloud Front is Global edge network and files are cached for TTL and S3 cross region replication must be setup for each region you want replication to happen and great for dynamic content that needs to be available at low latency in few regions.
AWS Global Accelerator
Without Global accelerator: The Network has to travel through lots of hops such as Local ISP, Network, A—-B—-C and then it reaches the AWS Region.
With Global accelerator: You are directly from local ISP to Edge location which quickly redirectors to the correct AWS Regions.
Global accelerator has no caching involved and improves the performance for a wide range of applications over TCP or UDP. Here content is not served from the edge whereas in case of CloudFront the content is served from the cache.
If you deploy your application in any specific region and users across the globe wants to access it then you need AWS Global accelerators. Global accelerator will leverage AWS internal network to route to your application.
The Global accelerator allows all servers to hold the same IP address and client is routed to the nearest one. Global accelerator works on anycast IP concept where all servers to hold the same IP address.
- AWS Global accelerator works with EC2 , ALB, NLB, public or private, Elastic IP.
- It also performs the health check of the applications.
- Intelligent routing to lowest latency and fast regional failover.
- Only 2 external IP needs to be whitelisted.
- Helps make the application global.
Once the Global accelerator will be created then you will have same number of Static IP address as that of endpoints and the DNS name .
CloudFront vs Global Accelerator
Cloud front improves performance for both cache content and it has dynamic content. The content is served at the edge.
- However for global accelerator improves performance for wide range of applications over TCP or UDP.
- It uses static IP addresses improves performance for wide range of applications ,
- proxying packets at edge to applications running in one or more AWS regions.
Alternate domain names (CNAMEs)
Specify one or more domain names that you want to use for URLs for your objects instead of the domain name that CloudFront assigns when you create your distribution.
If you add a CNAME for www.example.com to your distribution, you also must do the following:
- Create (or update) a CNAME record with your DNS service to route queries for
www.example.comtod111111abcdef8.cloudfront.net. - Add a certificate to CloudFront from a trusted certificate authority (CA) that covers the domain name (CNAME) that you add to your distribution, to validate your authorization to use the domain name.
SSL Certificates in CloudFront
If you specified an alternate domain name to use with your distribution, choose custom SSL certificate, and then, to validate your authorization to use the alternate domain name, choose a certificate that covers it.
Default CloudFront Certificate (*.cloudfront.net) – Choose this option if you want to use the CloudFront domain name in the URLs for your objects
SSL connectivity from Client Side
If you specified one or more alternate domain names and a custom SSL certificate for the distribution, choose how you want CloudFront to serve HTTPS requests:
- Clients that Support Server Name Indication (SNI) – (Recommended) – With this setting, virtually all modern web browsers and clients can connect to the distribution, because they support SNI & others can’t connect to the distribution. To apply this setting using the CloudFront API, specify
sni-onlyin theSSLSupportMethodfield. - Legacy Clients Support – With this setting, older web browsers and clients that don’t support SNI can connect to the distribution. However, this setting incurs additional monthly charges. To apply this setting using the CloudFront API, specify
vipin theSSLSupportMethodfield - Using Dedicated IP address to server https requests. When you configure CloudFront to serve HTTPS requests using dedicated IP addresses, CloudFront associates your alternate domain name with a dedicated IP address in each CloudFront edge location.
- DNS routes the request to the IP address for your distribution in the applicable edge location.
- CloudFront uses the IP address to identify your distribution and to determine which SSL/TLS certificate to return to the viewer.
- The viewer and CloudFront perform SSL/TLS negotiation using your SSL/TLS certificate.
- CloudFront returns the requested content to the viewer.
CloudFront Policies
There are mainly three policies that CloudFront offers.
- CloudFront cache policy: Specify the HTTP headers, cookies, and query strings that CloudFront includes in the cache key. The cache key determines whether a viewer’s HTTP request results in a cache hit.
- CloudFront origin request policy: Specify the HTTP headers, cookies, and query strings that CloudFront includes in the origin requests. These are the requests that CloudFront sends to the origin when there’s a cache miss. Like S3 ORP.
- CloudFront response headers policy: you can control the HTTP headers that CloudFront includes in HTTP responses that it sends to viewers (web browsers or other clients). You can remove headers from the origin’s HTTP response, or add HTTP headers to the responses that CloudFront sends to viewers
AWS WAF and AWS CloudFront
Publicly accessible web applications and APIs are exposed to threats such as commonly occurring vulnerabilities described in the OWASP Top 10, SQL injection, automated requests, and HTTP floods (Denial of Service (DoS)) that can affect availability, compromise security, or consume excessive resources.
You can use AWS WAF to protect your CloudFront distributions and origin servers. AWS WAF is a web application firewall that helps secure your web applications and APIs by blocking requests before they reach your servers.
AWS WAF, a web application firewall, analyzes incoming requests and blocks the aforementioned threats before they reach your servers.
HTTPS connectivity with AWS CloudFront
Below is the high level diagram which explains how https connectivity takes places with encryption and decryption.
- Change the Viewer Protocol Policy setting for one or more cache behaviors to require HTTPS communication. In that configuration, CloudFront provides the SSL/TLS certificate.
- In your distribution, change the Origin Protocol Policy setting for the origin. Install an SSL/TLS certificate on your origin server (this isn’t required when you use an Amazon S3 origin or certain other AWS origins).
- Note: If you’re using certificates provided by AWS Certificate Manager (ACM), you don’t need to rotate SSL/TLS certificates. ACM manages certificate renewals for you.
Using Amazon EC2 as the Origins in the AWS CloudFront
A custom Origin can be an Amazon Elastic Compute Cloud (AWS EC2), for example, an http server. You need to provide the DNS name of the AWS EC2 instance as the custom origin, but while setting the custom origin as AWS EC2, make sure to follow some basic guidelines.
- Host the same content and synchronize the clocks on all servers in the same way.
- Restrict access requests to the HTTP and HTTPS ports that your custom origin listens on that is AWS EC2.
- Use an Elastic Load Balancing load balancer to handle traffic across multiple Amazon EC2 instances and when you create your CloudFront distribution, specify the URL of the load balancer for the domain name of your origin server.
How CloudFront access content of AWS S3 Bucket.
CloudFront provides two ways to send authenticated requests to an Amazon S3 origin: origin access control (OAC) and origin access identity (OAI). OAC helps you secure your origins, such as for Amazon S3.
- S3 bucket policy that allows CloudFront to retrieve and put objects in AWS S3 bucket.
{
"Version": "2012-10-17",
"Statement": {
"Sid":"AllowCloudFrontServicePrincipalReadOnly",
"Effect":"Allow",
"Resource": "arn:aws:s3:::<S3 bucket name>/*",
"Action": "s3:GetObject",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
}
}
}
}
- KMS key policy that allows CloudFront to allow to put encrypted objects in AWS S3.
{
"Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/Alice",
"Service": "cloudfront.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
}
}
}
How CloudFront access content of AWS ELB.
For a web application or other content that’s served by an Application Load Balancer in Elastic Load Balancing, CloudFront can cache objects and serve them directly to users (viewers), reducing the load on your Application Load Balancer.
- Configure CloudFront to add a custom HTTP header to requests that it sends to the Application Load Balancer.
AWSTemplateFormatVersion: '2010-09-09'
Resources:
TestDistribution:
Type: 'AWS::CloudFront::Distribution'
Properties:
DistributionConfig:
Origins:
- DomainName: app-load-balancer.example.com
Id: Example-ALB
CustomOriginConfig:
OriginProtocolPolicy: https-only
OriginSSLProtocols:
- TLSv1.2
OriginCustomHeaders:
- HeaderName: X-Custom-Header
HeaderValue: random-value-1234567890
- Configure the Application Load Balancer to only forward requests that contain the custom HTTP header.
- Make sure that your Application Load Balancer has an HTTPS listener
Functions at Edge
With Amazon CloudFront, you can write your own code to customize how your CloudFront distributions process HTTP requests and responses. The code runs close to your viewers (users) to minimize latency, and you don’t have to manage servers or other infrastructure. You can write code to manipulate the requests and responses that flow through CloudFront, perform basic authentication and authorization, generate HTTP responses at the edge, and more.
CloudFront Functions
You can write lightweight functions in JavaScript for high-scale, latency-sensitive CDN customizations. The runtime environment offers submillisecond startup times, scales immediately to handle millions of requests per second, and is highly secure.
function handler(event) {
// NOTE: This example function is for a viewer request event trigger.
// Choose viewer request for event trigger when you associate this function with a distribution.
var response = {
statusCode: 302,
statusDescription: 'Found',
headers: {
'cloudfront-functions': { value: 'generated-by-CloudFront-Functions' },
'location': { value: 'https://aws.amazon.com/cloudfront/' }
}
};
return response;
}
Lambda@Edge
Lambda@Edge is an extension of AWS Lambda that offers powerful and flexible computing for complex functions and full application logic closer to your viewers, and is highly secure. Lambda@Edge functions run in a Node.js or Python runtime environment. You publish them to a single AWS Region, but when you associate the function with a CloudFront distribution, Lambda@Edge automatically replicates your code around the world. You can execute lambda functions when following CloudFront event occurs:
- When CloudFront receives a request from a viewer (viewer request)
- Before CloudFront forwards a request to the origin (origin request)
- When CloudFront receives a response from the origin (origin response)
- Before CloudFront returns the response to the viewer (viewer response)
IAM permissions to work with Lamda@Edge and CloudFront Distributions
{
"Sid": "sid1",
"Effect": "Allow",
"Action": [
"lambda:GetFunction",
"iam:CreateServiceLinkedRole",
"lambda:EnableReplication*",
"cloudfront:UpdateDistribution",
"cloudfront:CreateDistribution",
],
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:TestFunction:2"
}
Lambda Function Execution Role
You also need trust relationship policy for above role that will be assumed by Lambda.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com",
"edgelambda.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
Lambda@Edge uses the following IAM service-linked role:
- AWSServiceRoleForLambdaReplicator – Lambda@Edge uses this role to allow Lambda@Edge to replicate functions to AWS Regions.
- AWSServiceRoleForCloudFrontLogger – CloudFront uses this role to push log files into your CloudWatch account, to help you to debug Lambda@Edge validation errors.
Security in CloudFront
To encrypt your data during transit, you configure Amazon CloudFront to require that viewers use HTTPS to request your files, so that connections are encrypted when CloudFront communicates with viewers. You also can configure CloudFront to use HTTPS to get files from your origin, so that connections are encrypted when CloudFront communicates with your origin.
Function code and configuration in CloudFront Functions is always stored in an encrypted format on the edge location POPs, and in other storage locations used by CloudFront.
You can restrict access to content using signed URLs or cookies, Restrict access to content in Amazon S3 buckets, Restrict access to content served by an Application Load Balancer, Use AWS WAF web ACLs, Use geo restriction.
Allow users to access CloudFront programmatically
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAllCloudFrontPermissions",
"Effect": "Allow",
"Action": ["cloudfront:*"],
"Resource": "*"
}
]
}
Allow users to use the CloudFront console
{
"Version": "2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"acm:ListCertificates",
"cloudfront:*",
"cloudwatch:DescribeAlarms",
"cloudwatch:PutMetricAlarm",
"cloudwatch:GetMetricStatistics",
"elasticloadbalancing:DescribeLoadBalancers",
"iam:ListServerCertificates",
"sns:ListSubscriptionsByTopic",
"sns:ListTopics",
"waf:GetWebACL",
"waf:ListWebACLs"
],
"Resource":"*"
},
{
"Effect":"Allow",
"Action":[
"s3:ListAllMyBuckets",
"s3:PutBucketPolicy"
],
"Resource":"arn:aws:s3:::*"
}
]
}
Conclusion
In this huge tutorial we learnt everything related to What is AWS CloudFront, how it works with different origins and how to best secure your AWS CloudFront in AWS cloud.
DevOps Automateinfra Learning 