[AWS - DA] CloudFront
Origins
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
Origin Access Identity
When create distribution:
It will update S3 bucket policy that only allow CloudFront to access the objects inside bucket.
CloudFront Caching
- 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)
CloudFront Signed URL / Singed Cookies
- 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
CloudFront - Origin Groups
- 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).
