CloudFront

1. Overview

• Content Delivery Network(CDN)
• Improves read performance, content is cached at the edge
• 216 Point of Presence globally (edge locations)
• DDoS protection, integration with Shield, AWS Web Application Firewall
• Can expose external HTTPS and can talk to internal HTTPS backends

2. Origins

2.1 S3 bucket

• For distributing files and caching them at the edge
• Enhanced security with CloudFront Origin Access Identity (OAI)
• CloudFront can be used as an ingress (to upload files to S3)

2.2 Custom Origin  (HTTP)

• Application Load Balancer
• EC2 Instance
• S3 website (must first enable the bucket as a static S3 website)
• Any HTTP backend you want

3. Work Scenario

4. Example

4.1 S3 as an Origin

4.2 ALB or EC2 as an Origin

5. Geo Restriction

The country is determined using a 3rd party Geo-IP database. Use cases: Copyright Laws to control access to content

5.1 Whitelist

Allow your uses to access your content only if they're in one of the countries on a list of approved countries

5.2 Blacklist

Prevent your users from accessing your content if they're in one of the countries on a blacklist of banned countries

6. CloudFront vs. S3 Cross-Region Replication

6.1 CloudFront

• Global Edge Network
• Files are cached for a TTL (maybe a day)
• Great for static content that must e available everywhere And maybe you are okay with if that content is outdated a little bit

6.2 S3 Cross-Region Replication

• Must be set up for each region you want replication to happen
• Files are updated in near real-time
• Read-only
• Great for dynamic content that needs to be available at low-latency in few regions

7. Issues

S3 updates the DNS for the global REST endpoint hierarchy *.s3.amazonaws.com with a record sending requests to the right region for the bucket within a short time after bucket creation, and CloudFront appears rely on this for sending the requests to the right place. Before that initial update is complete, S3 will return a redirect and CloudFront returns that redirect to the browser. ~ michael-sqlbot

8. Signed URL

• You want to distribute paid shared content to premium users over the world
• We can use CloudFront Signed URL / Cookie. We attach a policy with:
  • Includes URL expiration
  • Includes IP ranges to access the data from
  • Trusted signers (which AWS accounts can create signed URLs)
• How long should the URL be valid for?
  • Shared content (movie, music): make it short (a few minutes)
  • Private content (private to the user): you can make it last for years
• Signed URL: access to individual files (one signed URL per file)
• Signed Cookies: access to multiple files (one signed cookie for many files)

8.1 Example

8.2 CloudFront Signed URL vs. S3 Pre-Signed URL

8.2.1 CloudFront Signed URL

• Allow access to a path, no matter the origin
• Account-wide key-pair, only the root can manage it
• Can filter by IP, path, data, expiration
• Can leverage caching features

8.2.2 S3 Pre-Signed URL

• Issue a request as the person who pre-signed the URL
• Uses the IAM key of the signing IAM principal
• Limited lifetime

9. Reference

aws.amazon.com/cloudfront/features/?nc=sn&loc=2

stackoverflow.com/questions/38735306/aws-cloudfront-redirecting-to-s3-bucket

web.archive.org/web/20190129041349/www.michaelgallego.fr/blog/2013/08/27/static-website-on-s3-cloudfront-and-route-53-the-right-way/