s3 bucket
for distributing files and caching them at the edge
enhanced security with cloudfront origin access identity (oai: s3 only allow traffic from cloudfront)
cloudfront can be used as an ingress (to upload files to s3)
custom origin (http)
alb
ec2
s3 static website
any http backend you want
if edge location direct connect to ec2 with security group, then ec2 must be public
or if edge location direct connect ot alb with security group, then ec2 behind alb, those ec2 can be private, but alb must be public.
clondfront's content might not be latest; s3 crr will be updated to latest
cloudfront for static content; s3 crr for dynamic content
when create distribution:
it will update s3 bucket policy that only allow cloudfront to access the objects inside bucket.
cache based on
the cache lives at each cloudfront edge location
you want to maximize the cache hit rate to minimize request on the orgin
control the ttl (0 second to 1 year), can be set by the origin using the cache-control header, expire header...
you can invalidate part of the cache usign the createinvalidation api
when doing cloudfront caching, we can divide two types of cache
static resource cache: max the cache hit rate (javascript...css, images... fonts, for web)
dynamimc resource cache: reduce the cache hit rate (api)
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:
include url expiration
include ip ranges to access the data from
trusted signers (which aws accounts can create singed 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)
if you use cloudfront in front of s3, you have to use cloudfront signed url because origin access identity restrict s3 access only by cloudfront
s3 signed url use iam principal will get the same rights as owner does.
two way to singed the url
using root account (not recommended)
using cloudfront key pair
to increase high-availability and do failover
origin group; one primary and one secondary origin (same idea as dynamodb multi-az)
if the primary origin fails, the second one is ued
two protocols: viewer protocol policy & origin protocol policy
s3 static website only use http
on edge location should have a public key to encrypt the sensitive data
on web server using decrypt the data by using private key
when you create a signer, the public key is with cloudfront and private key is used to sign a portion of url - each signer that you use to create cloudfront signed urls or signed cookies must have a public–private key pair. the signer uses its private key to sign the url or cookies, and cloudfront uses the public key to verify the signature. when you create signed urls or signed cookies, you use the private key from the signer’s key pair to sign a portion of the url or the cookie. when someone requests a restricted file, cloudfront compares the signature in the url or cookie with the unsigned url or cookie, to verify that it hasn’t been tampered with. cloudfront also verifies that the url or cookie is valid, meaning, for example, that the expiration date and time haven’t passed. when you use the root user to manage cloudfront key pairs, you can only have up to two active cloudfront key pairs per aws account - when you use the root user to manage cloudfront key pairs, you can only have up to two active cloudfront key pairs per aws account. whereas, with cloudfront key groups, you can associate a higher number of public keys with your cloudfront distribution, giving you more flexibility in how you use and manage the public keys. by default, you can associate up to four key groups with a single distribution, and you can have up to five public keys in a key group.
high dynamic is not suitable for cloudfront caching
cloudfront routes all incoming requests to the primayr origin, even when a previous request failed over to the secondary orgin. cloudfront only sends requests to the secondary origin after a request to the primary origin fails. cloudfront fails over to the secondary origin only when the http method of the viewer request is get, head, or options. cloudfront does not failover when the viewer sends a different http method (for example post; put, and so on).