AWS Quick Notes — AWS CloudFront
if you have already been using Akamai or any other content delivery network you are already familiar with what they are.
Content Delivery Networks allow for caching content with a given TTL(Time To Live) at the edge to provide for fast data access, particularly for reads.There are hundreds of edge locations around the world provided by various providers.
Amazon Cloudfront provides >200 edge locations worldwide.In addition to caching content to improve performance, there are various secucity features provided as well.
Cloudfront is used for static content delivery, globally.Access to content can be restricted by IP Address restrictions as well.
DDoS protection is provided by Cloudfront out of the box.
Integration with other AWS services such as AWS WAP(Web Application Firewall) and Shield are available as well.
Both HTTP and HTTPS endpoints are available.
Types of origins for content.
The most common origin supported is S3.
A S3 bucket can be securely shared using CloudFront Origin Access Identity.
CloudFront Origin Access Identity(OAI) allows restricting access to some or all Amazon S3 content.
Cloudfront can also be used to upload files from anywhere in the world.
The bucket policy for S3 is automatically updated for Cloudfront to be able to access S3 when you create an OAI and select that option.
To ensure that your users access your files using only CloudFront URLs, regardless of whether the URLs are signed, do the following:
1. Create an origin access identity, which is a special CloudFront user, and associate the origin access identity with your distribution
2. Change the permissions either on your Amazon S3 bucket or on the files in your bucket so that only the origin access identity has read permission.
Custom Origin
Cloudfront can support custom origins which have an http endpoint associated with them.
EC2 instances, Application load balancers, or S3 websites are examples.
In the case of an EC2 instance, the instance must be allow the security group of the edge location so Cloudfront’s edge location can access it.
A public IP list of all edge locations is available.
In case of an ALB, it would be the same.
The public IP list of edge locations would have to be allowed by the ALB.
Restrictions
Geo-restriction can restrict through a whitelist or blacklist , who can access or not access the content.
Cloudfront Signed URLs
These can be used to distribute restricted content globally.
Choices we make : S3 Signed URLs can be used to restrict content for simple use cases, nut when global access is in question, Cloudfront signed URLs may be a better choice.
In this case the client application uses the AWS SDK to generate a signed URL that us returned to the user.The signed URL allows for restricted access to the resource.
Cloudfront signed URLs work for any origin, S3 or other custom origins.
You can add filtering by IP, path, date or expiration. All the caching features of cloudfront can be used when using these.
Pricing and Price Classes
Egress cost is different for different regions
The more data is transferred out, the lesser the cost,
Price class ALL — Includes all regions
Price class 100— 100 North America and Europe
Price class 200 — adds a few other regions.
Routing to different origins
Cloudfront can route to different origins.
Path Pattern routing
In this case a the path dictates what origin to retrieve content from.
For example
/images/* may go to the S3 origin
/pages/* may go to the ALB which pulls content from EC2.
High Availability
Origin groups allow Cloudfront to failover to a secondary origin in case there is a failure with the primary origin.
The origins can be in the same or different regions.
For S3 , S3 Cross Region Replication may be used to keep a primary and secondary S3 origin available for failover.
Encryption
For applications that deal with highly sensitive data, Cloudfront supports asymmetric encryption of sensitive information at the edge.
For example. If user is sending some sensitive information such as Social Security No. in a POST request, client can specify that the SSN should be encrypted using a Public Key.The SSN is then passed encrypted all the way to the processing application server which then decrypts it using a private key.
