[[TOC]]
CloudFront Architecture
CloudFront is a content delivery network.
- Origin - the source location of your content.
- S3 origin or Custom Origin
- Distribution - the configuration unit of CloudFront
- Edge Location - the local cache of your data.
- Regional edge cache - larger version of an edge location that provides another layer of caching. Only custom origins can use the Regional Edge cache
- Reduces the fetch from the origin, improving times.
- No WRITE caching. Uploads go directly to the origin.
- Origins are linked to Cache Behaviors, not directly to the CloudFront distributions.
Distributions
- A distribution can have many behaviors which are configured with a path pattern. If requests match a path pattern, that behavior is used, otherwise it defaults.
- TTL, Origins, Origin groups, and restricted access are configured via behaviors.
Cloudfront Behaviors
- Can select the security policies and TLS protocols
- Need to upload certificate if you use a custom domain.
- Can encrypt via behaviors
- Can cache based on headers
- Can set TTL
- Can restrict viewer access to a behavior. You will need to set up a trusted signer for this.
- Can set Lambda@Edge on your behaviors.
TTL and Invalidations
If the data between the source origin is changed and the cached version is still valid, we can have a problem with displaying accurate data.
TTL is the time to live - this is a period of time that the data is valid. If you're uploading new data every 100s, and you have your TTL set for 300 seconds, you can quickly see the problem.
- more frequent cache hits = lower origin load.
- default TTL (behavior) = 24 hours (validity period)
- you can set Minimum and Maximum TTL
- Origin Header: Cache-Control max-age (seconds)
- Origin Header: Cache-Controle s-maxage (seconds)
- Origin Header: Expires (Date and time)
Cache Invalidations
Cache invalidation is performed on a distribution and applies to all edge locations, but it takes time to replicate.
- /images/dog.jpg
- /images/dog*
- /images/*
- /*
Might want to think about versioned filenames instead of using heavy cache invalidations.
- logging is more effective
- this is not S3 versioning
AWS Certificate Manager (ACM)
- HTTP is simple and insecure
- HTTPS - SSL/TLS Layer of encryption is added to HTTP and is secure
- Data is encrypted in transit
- Certificates prove identity
- Signed by a trusted authority
- ACM allows you to create, renew, and deploy certificates on...
- Supported AWS services only (CloudFront and ALBs, not EC2)
CloudFront and SSL/TLS
- CloudFront has a default domain name (CNAME) that looks like this: https://128kbd83ks.cloudfront.net
- SSL is supported by default *.cloudfront.net certificate
- if you want to use alternate domain names, you need to add a cert and verify the ownership of the domain name using ACM in us-east-1.
- Remember - CloudFront Certificates are us-east-1
- Can set the protocol HTTP or HTTPS or both.
Important. There are two SSL connections made here
- Viewer -> Cloudfront and CloudFront -> origin
- Both need valid public certificates AND intermediate certs.
CloudFront and SNI
Encryption starts at the TCP connection
- multiple sites can be hosted by the same domain on the same webserver
- host headers are used after the TCP connection on Layer 7 - application layer. This tells the webserver to serve one site vs another. SNI (Server Name Indication) was added in 2003 allowing a host to be included.
- Old browsers don't support SNI - CF charges extra for dedicated IP ($600/mo)
Architecture
- DNS name needs to match
- us-east-1 only.
- no self signed certs
- Viewer Protocol
- Origin Protocol
Origin Types and Origin Architecture
- Origin groups provide resiliency
Categories of origins
- S3
- Media Store
- Everything else - Webservers
S3 is integrated with special features when you use it as an origin.
- Origin access identity.
- protocol policy matched at both sides
- able to pass through custom headers
Custom Origins
- SSL protocol
- origin protocol policy
- custom ports
- custom headers
Securing CF and S3 using OAI
This secures the origin from being accessed directly.
- OAI is a type of identity that can be associated with CloudFront distributions
- CloudFront becoms that OAI
- OAI can be used in S3 Bucket policies
Basically what we do is implicitly deny all access to the S3 bucket except for this OAI.
Note: Cannot use OAI on custom domains Basically what we do here is require a custom header on the origin to ensure that the header comes from the CloudFront edge locations or Set up a firewall to blacklist everything except the IP address of CloudFront.
Demo - Using OAIs
Demo
Lambda@Edge
Allows you to run lightweight Lambda at edge locations
- currently supports Node.js and Python
- Public Space - no VPC
- Layers are not supported
- Different limits vs normal Lambda functions.
Common When to Use
A/B testing - viewer requests Migration between S3 origins - origin requests Different Objects based on device - origin requests Content by country - origin requests
AWS Global Accelerator
The problem: You have an application that is super popular in the US. It becomes so popular that it goes global. The global experience vs local US experience is much worse the farther away from the US you get. Hops :)
This is similar to CloudFront, but not the same thing. CloudWatch moves the content closer to their location while AWS leaves the data where it is and provides an AWS backbone for the traffic to travel on.
AWS Global Accelerator introduces Anycast IP's that will resolve to the closest edge location. So, Australia will type in the IP address, it will resolve to the route closest to Australia. These edge locations are connected via AWS's own global network.
Basically you connect to a website via the closest AWS edge location, and then the traffic is served to the datacenter via the AWS backbone and not across the public internet. This allows very fast transfer between regions.
Global Accelerator also doesn't cache anything. that's CloudFront.