Cloudfront
-
global CDN catching static & dynamic at edge location near the user
-
reduce latency of data transfer across the globe
-
more frequent ache HITS= lower origin load
-
Terms
- Origin - the source location of your content (S3/ custom origin)
- Distribution - ‘configuration’ unit of cloudfront, including the behavior
- Edge location - local cache of your data, widely distributed
- Regional Edge cache - larger version of edge location, in a global cloud deployment with huge volume
- catch hit: requested data found in edge location
- catch miss: requested data is not found in edge location
-
Architecture
- catching for download operation only, no uploading
- integrates with AWS cert. management for HTTPS
-
Behavior
- can be partly public and partly private
- can have path pattern match against the incoming request to have different access
- allow to select the viewer HTTP/HTTPS protocol and HTTP method
- catching control (cookie, strings, headers) & restrict viewer access
- TTL
- invoke lambda function
-
TTL & invalidations
- how long objects are stored in edge location & when to reject
- Even the object in origin is updated, the viewer will still see the old version from the catch
- the catch will be expired after TTL and removed after a timeout (good if the objects will be updated)
- Default TTL to be 24 hr
- can set min TTL and Max TTL (even set for each object)
- Origin Header:
- Cache-Control max-age (in s)
- Cache-Control s-maxage (in s)
- Expires (specific date time)
-
Cache invalidation
- is a process in a computer system whereby entries in a cache are updated or removed
- performed on a distribution applies to all edge locations, which takes time
- the path that doesn’t match the pattern
- need to pay the cost
- versioned file names without need for invalidation
- old version won’t be used because new name is used → need a new cache
- easier logging and references
- keep all version and all objects
- no cost needed
-
CloudFront and SSL
-
each distribution receives a default domain name (CNAME) when it’s created
-
default https://xxxxxx.coudfront.net/, SSL supported by default
-
alternate domain names (CNAMES) can be used
- but you need prove that you own and control the domain/ use HTTPS → SSL is needed
- use ACM to generate/ import cert in ‘US-east-1’, even CF is a global service
-
there would be 2 SSL connection, both need valid public cert (private will not work)
- viewer - cloudfront (viewer protocol)
- cloudfront - Origin (origin protocol)
-
SNI allows multiple certs using a share IP, but CF charges extra for dedicated IP because old browser don’t support SNI
-
-
securing the CF content delivery path
- avoid customer by passing cloudfront and access origin directly
- For S3 origin
- secure their S3 origins by permitting only designated CloudFront distributions to access their S3 buckets
- use Origin access identity (OAI)
- an identity associated with cloudfront distribution
- CF become OAI → can be used in bucket policies = S3 only accessible by CF
- deny all but OAI
- use Origin access control (OAC)
- new version of OAI, recommended
- set in distribution and added CF ARN into bucket policies
- For custom origin
- set custom header generated by CF is required, or
- use firewall in custom origin, deny all but IP from cloudfront
-
Private distribution
- requests require signed cookie or URL
- signed URLs provides access to 1 object
- use when client doesn’t support cookies/ maintaining URL is important
- cookies provides access to groups of objects
- signed URLs provides access to 1 object
- old method: create cloundfront key by root user and acc is added as a trusted signer
- new method: Trusted key groups added (no need for key management)
- requests require signed cookie or URL
-
Lambda@edge
- can run lightweight Lambda at edge location
- adjust data between the viewer & origin
- only supports node.js & python
- run in AWS public
- use case:
- A/B testing - viewer request
- Migration users from old to new S3 origins - origin request
- content by country - origin request