Cloudfront Flashcards
Cloudfront Overview:
Origins
- S3
distribute files on edge
Enhanced security via OAI
Ingress portal for upload
2. Custom origin HTTP ALB (Cookie foward for auth for Cognito) EC2 instance S3 website HTTP backend custom
Cloudfront overview:
Sending items to origin
how its forwarded
how its cached.
- Client sends HTTP request to cloudfront
[URL
Query String
Header] - Cloudfront forwards entire request to origin including Query strings and request header
Origin can be S3/Http
- Origin will cache response and return client a response
- NEW REQUESTS THAT MATCH THIS PREVIOUS REQUEST WILL BE BROUGHT OUT OF CACHE
Cloudfront overview: S3 Origin
SECurity considerations
- Public will be able to request a file from an edge location
- Edge location traverses through private network to S3 bucket
- in Private network:
S3 bucket has a OAI connection
OAI: Origin access identity + S3 Bucket policy will determine if this requester/OAI is allows to take files. - cached content served.
Cloudfront overview: HTTP: ALB / EC2 origin
SECurity considerations
EC2:
Cloudfront is going to be part of a group of IP addresses, Ec2 security groups that need to be able to allow traffic from this list of IP addresses.
*allow all cloudfront IP’s
ALB:
Cloudfront IP addresses must be enabled on the ALB security group configuration. Also ALB will need to be public.
The EC2 instances will allow traffic from the ALB, but they themselves can be on a private security Group.
Cloudfront : Geo restriction
Restrict / enable
Whitelist or blacklist of users from specific countries
Countries are done via thirdparty GEO ip database
Copyright laws to restrict content.
Cloudfront vs Cross region replication
read vs write
latency
TTL and cache
Cloudfront:
Global edge
TTL cache
Great for static content needed EVERYWHERE
S3 CRR: Read only updated REAL TIME Must be setup in EACH region Great for read-only dynamic content to be available LOW LATENCY
Cloudfront Caching:
Based on what?
where it lives
invalidation API
TTL time min / max
Cached based ON:
Header
Session Cookie
Query String Parameter
Lives at EDGE LOCATION: checked based on above. will have expiration
*goal , min requests on origin, max CACHE hits
TTL : 0 seconds to 1 year
invalidation: API Createvalidation
Cloudfront Caching:
MAX CACHE HITS
dynamic and static separation how?
*separate static and dynamic distributions
Static requests: No header/ session caching rules required, just place all content on cloudfront to max cache hits.
dynamic : Items go through cloudfront with origin which has a backend (ex ALB with Ec2)
Dynamic items should cache based on:
HEADERS
COOKIES
Cloudfront Security: HTTPS
two types protocol policy
How to USE BOTH!
Client talk to edge which talks to origin: two security items
- Viewer protocol policy: between client to edge location
A. Direct HTTP to HTTPS
B. Use HTTPS only
Ensures all traffic to be encrypted. - ORIGIN PROTOCOL POLICY:
Http or s3 origin
A. HTTPS ONLY
B. Match viewer (good when viewer protocol policy makes all requests HTTPS)
S3 BUCKET “websites” dont do https
Cloudfront Signed URL/ Signed Cookie
what policy is attached
where is policy
private vs shared content TTL
URL vs Cookie use cases
what do they unlock and how many each?
Distribute content to premium users NEED TO ATTACH POLICY (internal) 1. URL expiration 2. IP ranges to access data from 3. Trusted Signers (which AWS accounts can create it)
How long should it be valid for
Shared content: minutes
Private content: years
SIGNED URL: ONE FILE, ONE URL PER FILE (item access)
SIGNED COOKIE: MULTIPLE FILES (session access)
Cloudfront Signed URL DIAGRAM
Diagram
Cloudfront hosts edge zones, it has a relationship with the Origin S3 that hosting the file, OAI maintains a trust relationship between access of the S3 file and cloudfront as being the only allowed access
A client is able to AUTHORIZE and AUTHENTICATE through a Application, this application sends a AWS SDK command to GENERATE SIGNED URL which is sent to CLOUDFRONT
Cloudfront sends a url back, now the client can access this file using the SIGNED URL and Cloudfront. Cloudfront will proxy the request via OAI to S3.
Cloudfront SIGNED URL
VS
S3 PRE SIGNED URL
Cloudfront Signed URL: Allow access to path , despite the origin (ec2 or S3) ACCOUNT WIDE, only root can manage it Filter by IP/path/expiration Can be CACHED
S3 presigned URL:
Limited lifetime,
USES SAME IAM KEY AS PERSON SIGNING THE REQUEST.
is isolated to s3, is isolated to IAM key of person signing, so this can be revoked if they lose permissions
IAM KEY matches the IAM key of SIGING PRINCIPAL (service or person who made the URL)
