CloudFront
What is a CDN?
- System of distributed servers (network) that deliver webpages and other web content to a user based on the geographic locations of the user, the origin of the web page, and a content delivery server
- Speeds up dynamic and static dynamic content
- More efficient way for geographically spaced out users to access content
- Being far away geographically can have a negative effect on performance
- Cloud front is focused on content delivery
- Allowing more efficient reads and downloads
- Transfer acceleration is all about enabling faster uploads into S3
- CloudFront introduces edge locations
- Collection of servers in geographically dispersed data centers
- Used by cloud front to keep a cache of the web content
- HTML, images, etc
- Instead of requesting content from a london server, they request it from a data center closer to them
- Once the request is made, the edge location forwards the request to london
- Downloads file and caches them so that users after can also access through the edge location
- Dramatically reduces the number of network hops, lower latency
- Cached for a period of time (time to live)
- After TLL is up, objects are cleared from cache
- If you have a new version, you can clear the cache yourself
- Charged for doing so
- If you have a new version, you can clear the cache yourself
CloudFront - key terminology
- Edge Location
- Location where content is cached and can also be written.
- Separate to an AWS Region/AZ
- A lot more edge locations than Region/AZ
- Origin
- This is the origin of all the files that the CDN will distribute.
- Origins can be an S3 Bucket, an EC2 Instance, and elastic load balancer, or Route 53
- More often than not its an S3 bucket or EC2 instance running a website
- Distribution
- This is the name given to the CDN, which consists of a collection of Edge Locations
- Web Distribution
- Typically used for websites
- RTMP
- Real time messaging protocol
- Used for media streaming
What is cloudfront?
- Can be used to deliver your entire website, including dynamic, static, streaming, and interactive content using a global network of edge locations
- Requests for your content are automatically routed to the nearest edge location, so content is delivered with the best possible performance
- E.g. can be used to optimize performance for users accessing a website backend by S3
- Optimized to work with other services, like S3, EC2, Elastic Load balancers, and route 53
- CloudFront also works seamlessly with any non-AWS origin server, which stores the original, definitive versions of your files
Distribution Types
- Web Distribution
- Websites
- HTTP/HTTPS
- Origin can be S3 bucket or HTTP/HTTPS server
- Cannot server adobe flash multimedia from a web distribution
- RTMP
- Adobe real time messaging protocol
- Used for Media Streaming / Flash multimedia content
CloudFront and S3 Transfer Acceleration
- Amazon S3 transfer acceleration enables fast, easy and secure transfers of files over long distances between your end users and an S3 Bucket
- Transfer Acceleration takes advantage of Amazon CloudFront’s globally distributed edge locations
- As the data arrives at an edge location, data is routed to Amazon S3 over an optimized network path
- Upload file to edge location, then the edge location sends it to the S3 bucket
Exam tips
- Edge location
- Where the content will be cached
- Separate from AWS region and AZ
- Many more Edge locations than regions or AZ
- Origin
- Origin of all the files that the CDN will distribute
- Can be an S3 Bucket, an EC2 instance, an Elastic Load Balancer, or Route 53
- Distribution
- Name given tot he CDN
- Consists of edge locations
- Web Distribution
- Used for websites
- RTMP
- Media streaming
- Edge locations are not just Read only, you can write to them too
- I.E. PUT an object on to them
- CloudFront edge locations are utilised by S3 Transfer Acceleration to reduce latency for S3 uploads
- Objects are cached for the life of the TTL (time to live)
- Object is wiped when TTL expires
- You can clear cached objects at any time, but you will be charged
- UDP is not a supported protocol
- HTTPS is supported between clients and cloudfront as well as cloudfront and the backend
- For web distributions, you can configure CloudFront to require that viewers use HTTPS to request your objects, so connections are encrypted when CloudFront communicates with viewers.
- You also can configure CloudFront to use HTTPS to get objects from your origin, so connections are encrypted when CloudFront communicates with your origin.
Lambda@Edge
- Lambda@Edge is a feature of Amazon CloudFront that lets you run code closer to users of your application, which improves performance and reduces latency.
- With Lambda@Edge, you don't have to provision or manage infrastructure in multiple locations around the world.
- You pay only for the compute time you consume - there is no charge when your code is not running.
With Lambda@Edge, you can enrich your web applications by making them globally distributed and improving their performance - all with zero server administration. Lambda@Edge runs your code in response to events generated by the Amazon CloudFront content delivery network (CDN). Just upload your code to AWS Lambda, which takes care of everything required to run and scale your code with high availability at an AWS location closest to your end user.
You can use Lambda@Edge to help authenticate and authorize users for the premium pay-wall content on your website, filtering out unauthorized requests before they reach your origin infrastructure. For example, you can trigger a Lambda function to authorize each viewer request by calling authentication user management service such as Amazon Cognito.
HTTPS Communication Between viewers and CloudFront
You can configure one or more cache behaviors in your CloudFront distribution to require HTTPS for communication between viewers and CloudFront. You can also configure one or more cache behaviors to allow both HTTP and HTTPS, so that CloudFront requires HTTPS for some objects but not for others.
If you're using the domain name that CloudFront assigned to your distribution, such as dtut0ria1sd0jo.cloudfront.net, you can change the viewer protocol policy setting for one or more cache behaviors to require HTTPS communication by setting it as either Redirect HTTP to HTTPS or HTTPS only.
If your origin is an Elastic Load Balancer, you can use a certificate provided by AWS Certificate Manager (ACM). You can also use a certificate that is signed by a trusted third-party certificate authority and imported into ACM. Note that you can't use a self-signed certificate for HTTPS communication between CloudFront and your origin.
Requiring HTTPS for communication between viewers and CloudFront
HTTPS Communication Between Origin and CloudFront
You can use an SSL/TLS certificate from the following sources on your custom origin:
- If your origin is an ELB, you can use a certificate provided by AWS Certificate Manager (ACM). You can also use a certificate that is signed by a trusted third-party certificate authority and imported into ACM.
- For origins other then ELB, you must use a certificate that is signed by a trusted third-party Certificate Authority (CA), for example, Comodo, Digicert, or Symantec.
When CloudFront uses HTTPS to communicate with your origin, CloudFront verifies that the certificate was issued by a trusted certificate authority. CloudFront supports the same certificate authorities that Mozilla does. You can't use a self-signed certificate for HTTPS communication between CloudFront and your Origin
NOTE: If the origin server returns an expired certificate, an invalid certificate, or a self-signed certificate, or if the origin server returns the certificate chain in the wrong order, CloudFront drops the TCP connection, returns HTTP status code 502 (Bad Gateway), or sets the X-Cache header to "Error from cloudfront". Also, if the full chain of certificates, including the intermediate certificate, is not present, CloudFront drops the TCP connection.