CDN

Why CDN?

A CDN (Content Delivery Network) is like a global network of super-fast storage lockers for your website content (images, videos, scripts, etc.).

Instead of your users always fetching content from one central server (which might be far away), they get it from a nearby server, so pages load much faster.

In AWS, the CDN service is called CloudFront.

AWS CDN (CloudFront) Components

1. Origin

   • The main source of your content.

   • Could be an S3 bucket, an EC2 server, an Elastic Load Balancer, or even another HTTP server.

   • Think: “This is where the original copy lives.”

2. Edge Locations

   • Small data centers around the world where CloudFront caches your content.

   • Users connect to the nearest edge location, not the origin.

   • Think: “These are the fast local lockers.”

3. Distribution

   • A configuration in CloudFront that tells AWS:

     • Which origin to use

     • How to cache content

     • Which edge locations to serve from

   • Think: “This is the instruction sheet for CloudFront.”

4. Cache

   • Temporarily stores content at edge locations.

   • Speeds up repeat requests.

   • Think: “Grab it once, then serve it super fast next time.”

5. Behaviors & Policies

   • Define rules like:

     • Which files to cache

     • How long to keep them cached

     • Security settings (HTTPS, access control)

   • Think: “These are the rules for your locker.”

6. Distribution (the basic idea)

   • Think of a distribution as a plan for delivering your content.

   • It tells CloudFront:

     • Where your content lives (origin)

     • How to deliver it (cache rules, security, etc.)

     • Which edge locations to use

   Analogy:

   • If the CDN is like libraries with book copies, a distribution is the instruction sheet that tells all the libraries:

     • “Get the book from this home”

     • “Keep it for 24 hours”

     • “Only allow people with library cards to read it”

7. Configuration of a Distribution

   • This is how you set up the distribution in CloudFront.

   • It includes:

     1. Origin → Where the content comes from (S3, EC2, etc.)

     2. Cache behavior → How long content stays in edge locations, which files to cache

     3. Security settings → HTTPS, signed URLs, access restrictions

     4. Price class & performance → Which edge locations to use globally

   Analogy:

   • Going back to the library example, configuration is like:

     • Choosing which libraries get your books

     • How long books stay on the shelves

     • Who can borrow them

Why it is the way it is

• Speed: Users get content from the closest edge location → faster page load.

• Reliability: Even if one server goes down, edge locations around the world can serve content.

• Scalability: Can handle millions of requests globally without your origin server breaking.

• Security: Integration with AWS WAF and Shield protects against attacks.

Basically, CloudFront is designed to move content closer to users and reduce load on your main server while keeping things secure and scalable.

Analogy: Library and Book Copies

• Imagine you wrote a book (your website content).

• You only have one copy stored in your home (the origin server).

• People all over the world want to read it. If everyone comes to your home, it will be slow and crowded.

Solution: Make copies in local libraries (edge locations)

• You send copies of your book to libraries in major cities.

• Now, when someone wants to read it, they go to the nearest library instead of traveling to your home.

• If you update the book, the libraries get new copies (cache updates).

Why it works:

• Fast access → No long travel

• Reliable → If one library is closed, another nearby has a copy

• Scalable → Thousands of people can read it at the same time

In AWS terms:

• Your home → Origin (S3, EC2, etc.)

• Libraries → Edge Locations

• Copies of the book → Cached content

What is Cache?

• A cache is a temporary storage for data that you access frequently.

• Its purpose: make things faster by storing a copy closer to where it’s needed.

Cache in CloudFront

• CloudFront stores your website content (like images, videos, HTML files) in edge locations temporarily.

• When a user requests the content:

  1. CloudFront checks the edge cache first.

  2. If the content is there → serves it instantly (cache hit).

  3. If not → fetches from the origin, then stores it in the cache for next time (cache miss).

AWS CloudFront Architecture

1. Origin

   • The source of your content.

   • Examples: S3 bucket, EC2 server, Elastic Load Balancer, or any web server.

   • Think: “This is where the master copy lives.”

2. CloudFront Distribution

   • A plan/configuration that tells CloudFront:

     • Which origin to use

     • Cache behavior (how long to keep content)

     • Security rules

     • Which edge locations to serve from

3. Edge Locations

   • Data centers all over the world.

   • They cache content to serve users faster.

   • Users automatically get content from the nearest edge location.

4. Regional Edge Caches (optional)

   • Intermediate layer between origin and edge locations.

   • Keeps content that isn’t accessed frequently but still speeds up delivery.

   • Think: “A mini library between the main home and local libraries.”

5. Users

   • End users requesting content (websites, videos, APIs).

   • Requests go to the closest edge location.

How It Works (Step by Step)

1. User requests a file (like an image or video).

2. CloudFront checks the nearest edge location:

   • If the file is cached → serve instantly

   • If not → fetch from origin or regional cache, then store it at the edge

3. Next time, users near that edge get it immediately.

Super Simple Analogy

• Origin → Your home (where the original book is)

• Distribution → Instruction sheet for libraries

• Edge Locations → Local libraries around the world

• Regional Edge Cache → Bigger regional library storing less popular books

• Users → People reading your book

CloudFront Behaviours

A behavior in CloudFront defines how CloudFront should handle requests for certain content.

• It’s basically a set of rules for specific types of files or URL paths.

• Example: You might want images to be cached for 1 day but videos for 1 hour.

Components of a Behavior

1. Path Pattern

   • Defines which URLs this behavior applies to.

   • Example: /images/* or /videos/*

2. Origin

   • Tells CloudFront which origin to get content from for this behavior.

3. Cache Settings

   • How long to store content in edge locations (TTL – time to live)

   • Whether to forward headers, cookies, or query strings to the origin

4. Viewer Protocol Policy

   • Should users access via HTTP or HTTPS?

5. Other Settings

   • Compression (gzip/ Brotli for faster delivery)

   • Access restrictions (signed URLs or signed cookies)

Analogy: Traffic Rules

• Imagine CloudFront as a traffic manager at a library.

• Different types of books have different rules:

  • Magazines → lend for 1 week

  • Rare books → only read in the library

  • Kids’ books → only certain people can borrow

• Behavior = the rule for that type of content

CloudFront expiry and invalidation

TTL (Time to Live)

• What it is: The amount of time CloudFront keeps a cached copy of your content at the edge before checking back with the origin.

• Purpose: Controls how long cached content stays “fresh.”

Example:

• TTL = 3600 seconds (1 hour)

• CloudFront caches an image for 1 hour at the edge.

• During that hour, users get the cached version.

• After 1 hour, CloudFront checks the origin for a new version.

Analogy:

• Think of TTL like a snack on your desk:

  • You leave it there for 1 hour (TTL)

  • After 1 hour, you check the kitchen (origin) for a fresh snack

Invalidation

• What it is: A way to force CloudFront to remove cached content immediately from edge locations.

• Purpose: When you update or delete content, users should see the new version immediately instead of waiting for TTL to expire.

Example:

• You update your website logo.

• Old logo is still cached at edges.

• You create an invalidation request for /images/logo.png.

• CloudFront removes it from all edge locations → next user gets the new logo.

Analogy:

• Your desk snack (cached content) has gone bad.

• Instead of waiting for the TTL to expire, you throw it away immediately and grab a fresh snack from the kitchen (origin).

TTL

Cache Invalidation

• Cache Invalidation is the process of removing outdated content from CloudFront edge locations before its TTL expires.

• Purpose: Ensure users get the latest version of your content immediately.

How it Works

1. You update content at the origin (S3, EC2, etc.).

2. The old version is still stored at edge caches.

3. You create an invalidation request for the specific file or path.

4. CloudFront removes that file from all edge locations.

5. Next user request → CloudFront fetches the fresh content from the origin.

Example

• Original logo: /images/logo.png

• You upload a new logo to S3.

• TTL = 24 hours → normally, users would see the old logo until TTL expires.

• Invalidation: Remove /images/logo.png from all edge locations.

• Users now see the new logo immediately.

Analogy: Library Books

• Edge caches = local libraries with copies of your books.

• You update a book at the main library (origin).

• Cache invalidation = recall all old copies from the local libraries.

• Readers now get the latest edition.

AWS certificate Manager

• ACM is a service that manages SSL/TLS certificates for your websites and applications in AWS.

• Purpose: Encrypt data between users and your website so it’s secure.

• You don’t have to manually create, install, or renew certificates—it’s automated.

Why SSL/TLS Certificates Matter

• They make your website HTTPS (secure).

• Encrypts data so hackers can’t read sensitive information.

• Shows a lock icon in the browser → users trust your site.

Key Features of ACM

1. Automatic Certificate Provisioning

   • Creates SSL/TLS certificates for your domain.

2. Automatic Renewal

   • Certificates are renewed before they expire.

3. Integration with AWS Services

   • Works with CloudFront, ELB (Elastic Load Balancer), API Gateway, etc.

   • You don’t need to manually attach certificates.

4. Free Public Certificates

   • You can get trusted SSL/TLS certificates at no cost for public domains.

ACM Regional vs Global Certificates

1. Regional Certificates

• Applied in a specific AWS region (e.g., us-east-1, eu-west-1).

• Can be used with regional services like:

  • Elastic Load Balancer (ELB)

  • API Gateway regional endpoints

• Not automatically usable globally.

1. CloudFront Certificates

• CloudFront is a global service.

• Certificates for CloudFront must be in us-east-1 (N. Virginia), even if your origin server is elsewhere.

• Why? CloudFront uses us-east-1 as the central place to issue and manage certificates for distribution worldwide.

Why CloudFront Requires us-east-1

• CloudFront is globally distributed.

• By using one central region (us-east-1) for certificates:

  • AWS simplifies management

  • Ensures the certificate is trusted everywhere in the world

How It Works in Practice

1. You request a public SSL/TLS certificate in ACM.

2. If you want to use it with CloudFront, you must select us-east-1.

3. Attach the certificate to the CloudFront distribution.

4. Users worldwide access your site securely via HTTPS, served from the nearest edge location.

Regional services (like an ELB in us-west-2) use regional ACM certificates, not the us-east-1 certificate.

ACM Analogy

1. Your website = a store

   • Visitors come in and expect security and trust.

2. SSL/TLS certificate = a security guard

   • Ensures all communication is safe and encrypted.

   • Shows visitors that your store is legitimate.

3. ACM = the manager

   • Hires, trains, and automatically replaces guards when needed.

   • You don’t have to worry about manual setup or renewals.

Type	Analogy	Purpose
Regional ACM certificate	Local guard for a single store	Protects one AWS region (e.g., ELB or API Gateway in us-west-2)
CloudFront ACM certificate	Super guard trained in N. Virginia (us-east-1)	Deployed globally to all edge locations, ensuring secure delivery worldwide

ACM - Architecture

Core Components

1. Origin

   • Source of content (S3, EC2, or Load Balancer).

2. CloudFront Distribution

   • Global delivery system (the “plan” to deliver content).

3. Edge Locations

   • Local caching servers around the world.

4. ACM (AWS Certificate Manager)

   • Issues SSL/TLS certificates to enable HTTPS encryption.

How It Works

1. User requests your website (e.g., https://example.com).

2. The request hits the nearest CloudFront edge location.

3. CloudFront uses an ACM certificate to establish a secure HTTPS connection.

   • If it’s CloudFront → certificate must be in us-east-1.

   • If it’s a regional service (like ELB) → certificate is regional.

4. CloudFront serves content from the edge cache.

   • If not cached → fetches from origin.

5. Response goes back to the user encrypted and secure.

CloudFront SSL

What is SSL/TLS in CloudFront?

• SSL (Secure Sockets Layer) / TLS (Transport Layer Security) are encryption protocols.

• They make sure data between your users and CloudFront (and optionally, your origin) is private and secure.

• In practice: this is what makes your site use HTTPS instead of HTTP.

How CloudFront Uses SSL/TLS

When someone visits https://example.com:

1. The user’s browser connects to the nearest CloudFront edge location.

2. CloudFront presents an SSL/TLS certificate (from ACM).

3. A secure encrypted connection is established (lock icon in browser).

4. CloudFront fetches content from the origin (securely if configured).

5. The user gets the content over HTTPS.

Certificate Management

• CloudFront requires an ACM certificate in us-east-1 (N. Virginia).

• You can:

  • Use AWS Certificate Manager (ACM) to get free public certs.

  • Import your own cert from a third-party provider.

Key SSL/TLS Options in CloudFront

• Viewer Protocol Policy → Decide if users must use HTTPS only.

• Origin Protocol Policy → Decide if CloudFront connects to your origin with HTTP or HTTPS.

• Custom SSL Certificates → For your domain (example.com), not just CloudFront default (*.cloudfront.net).

Analogy

• Imagine CloudFront as a shipping company delivering packages (your content).

• SSL/TLS = tamper-proof lockbox used to ship those packages.

• ACM = the key manager who automatically creates and updates the lockbox keys so you don’t worry about safety.

SNI in CF

Origin in CloudFront

What is an Origin in CloudFront?

• An origin = the source of your content.

• CloudFront fetches content from the origin if it’s not already cached at an edge location.

Types of Origins in CloudFront

S3 Origin

• Origin is an Amazon S3 bucket.

• Best for: static content (images, CSS, JavaScript, videos, etc.).

• CloudFront directly integrates with S3, easy setup, highly scalable.

• Example: mybucket.s3.amazonaws.com

Custom Origin

• Origin is anything else — like:

  • EC2 instance (web server)

  • Elastic Load Balancer (ALB/NLB)

  • On-premises server (via public internet)

  • Any HTTP/HTTPS endpoint

• Best for: dynamic content (APIs, personalized web apps, backend services).

Analogy

• S3 origin = warehouse full of books (static content, easy access).

• Custom origin = a workshop where new books are printed on-demand (dynamic responses, API calls).

• CloudFront = delivery service with local warehouses (edge caches).

CloudFront Security

CloudFront isn’t just about speed. It also acts as a first line of defense for your apps/websites. It sits in front of your origin → so attacks hit CloudFront first, not your servers.

CloudFront Security Features

Encryption

• HTTPS with SSL/TLS → All traffic between users and CloudFront is encrypted.

• Origin HTTPS → CloudFront can also use HTTPS to talk securely to your backend/origin.

Access Control

• Signed URLs / Signed Cookies → Control who can access private content (e.g., paid videos).

• Geo-Restriction → Block or allow traffic by country.

• Field-Level Encryption → Encrypt only sensitive parts of requests (like credit card numbers).

Integration with AWS Security Services

• AWS WAF (Web Application Firewall) → Protects against SQL injection, XSS, bot traffic, etc.

• AWS Shield (DDoS Protection) → Built-in standard DDoS protection at no cost.

• AWS Shield Advanced → Extra protection + real-time attack visibility.

Logging & Monitoring

• CloudFront Access Logs → Who is accessing your content.

• CloudWatch Metrics → Monitor traffic, errors, security events.

Analogy

• Think of CloudFront as a castle gate:

  • Moat & guards (WAF + Shield) stop attackers before they reach the castle.

  • Secure lock (SSL/TLS) ensures messages passed in/out are private.

  • Tickets (Signed URLs/Cookies) only let authorized visitors in.

OIA

• OAI (Origin Access Identity) is a special identity CloudFront uses to securely access S3 buckets.

• Main purpose:

  • Stop users from bypassing CloudFront and directly hitting the S3 bucket URL.

  • Ensures all traffic to your origin must go through CloudFront.

OAI with S3 Origins

• Works directly with S3 buckets.

• You grant the OAI permission to access your bucket.

• Users → CloudFront → S3 (not directly S3).

Custom Origins

Custom Origins

• Custom origin = any HTTP server (EC2, ALB, on-prem).

• OAI does not apply to custom origins, because it’s only for S3 bucket access control.

👉 For custom origins, you use different methods to restrict direct access:

• Security groups / firewall rules → Only allow CloudFront IP ranges.

• Custom headers → CloudFront sends a secret header, and the origin verifies it.

• Private VPC setup (with ALB + CloudFront) → Origin not directly exposed to the internet.

Analogy

• OAI = a VIP pass that lets CloudFront enter the warehouse (S3) while blocking everyone else.

• For custom origins, instead of a pass, you use guards (firewall rules) or a secret handshake (custom headers).

CloudFront - Private Distribution & Behaviours

CloudFront Private Distribution

A private distribution means your content on CloudFront is not publicly accessible to everyone. Only authorized users can access it.

How to Secure a Private Distribution

1. Signed URLs → A temporary, special link that only certain users can use.

   • Example: a movie streaming site gives a link that expires in 1 hour.

2. Signed Cookies → Give a user access to multiple restricted files without creating many signed URLs.

   • Example: once logged in, user can watch many videos without new links each time.

3. OAI/OAC for S3 → Prevents users from bypassing CloudFront and going directly to S3.

✅ Use case: Premium video streaming, paid downloads, or internal company content.

CloudFront Behaviors

A behavior tells CloudFront how to handle different types of requests in a distribution.

Examples of Behaviors

• Path-based rules:

  • /images/* → Serve from S3 with long cache time

  • /api/* → Forward to EC2/ALB with short cache time

• Viewer protocol:

  • Redirect HTTP → HTTPS

• Caching rules:

  • Videos cached for 1 day

  • API responses cached for 1 minute

• Restrict access:

  • /premium/* → Only accessible with signed URLs/cookies

✅ Behaviors let you mix static + dynamic content under one CloudFront distribution.

How They Work Together

• Private Distribution → Controls who can access content.

• Behaviors → Controls how CloudFront serves different types of content.

Analogy

• CloudFront Distribution = A theme park 🎢

• Behaviors = Rules for different rides

  • Kids’ ride → shorter wait, different rules

  • VIP ride → only for people with a VIP pass

• Private Distribution = VIP section of the park

  • Only people with special tickets (signed URLs/cookies) get access

Lambda@Edge

What is Lambda@Edge?

• Lambda@Edge = AWS Lambda functions that run at CloudFront edge locations.

• Instead of running code only in one AWS Region, your function runs closer to the user.

• Used to customize how CloudFront delivers content.

Where It Runs (Triggers)

Lambda@Edge can run at 4 points in the request/response flow:

Viewer Request   → (User request hits CloudFront)
Origin Request   → (Before CloudFront fetches from origin)
Origin Response  → (After origin responds to CloudFront)
Viewer Response  → (Before CloudFront sends response to user)

What You Can Do With Lambda@Edge

Security

• Check auth tokens before serving content.

• Block certain IPs or user agents.

Personalization

• Show different content depending on user location, cookies, or headers.

• Example: Redirect users from UK → /uk/homepage, US → /us/homepage.

Content Transformation

• Modify HTTP headers (add security headers like HSTS, CSP).

• Rewrite URLs (/old-path → /new-path).

• Resize images or change format dynamically.

Analogy

Think of CloudFront as a delivery company 🚚 bringing packages (content) to customers.

• Normally, delivery is the same for everyone.

• Lambda@Edge = a smart helper at each local warehouse who:

  • Checks the package (security) 🔒

  • Adds stickers/labels (headers) 🏷️

  • Redirects delivery if needed (rewrite URL) ↪️

  • Chooses a different product if customer rules apply (personalization).

Examples

• Redirect all HTTP to HTTPS (security).

• Add Strict-Transport-Security header (security).

• Serve different images based on device type (mobile vs desktop).

• Block users from restricted countries.

Lambda@Edge example functions - Amazon CloudFrontdocs.aws.amazon.com

AWS Global Accelerator

What is AWS Global Accelerator?

• A networking service that improves the performance and availability of your applications for users across the globe.

• It gives users a static anycast IP address that routes them to the nearest AWS edge location, and from there traffic travels on the AWS global backbone network instead of the public internet.

👉 Think of it as a fast lane on the internet for your application.

How It Works

1. User connects to a static IP (provided by GA).

2. GA routes traffic to the closest AWS edge location using Anycast routing.

3. From there, traffic travels securely and quickly over the AWS private backbone to your application (EC2, ALB, NLB, etc.).

4. If one region is unhealthy, GA automatically fails over to another region.

Benefits

• Performance: Traffic avoids congested public internet, using AWS’s optimized network.

• High availability: Automatic failover between AWS Regions.

• Static IPs: Apps keep the same IPs even if backend changes.

• Multi-region routing: You can have active-active or active-passive setups across multiple regions.

Without Global Accelerator

With Global Accelerator

Analogy

Imagine your app is a chain of restaurants 🍔 spread across the world:

• Without GA → Customers (users) take local streets (public internet), sometimes traffic is slow or jammed.

• With GA → Customers enter a special expressway (AWS global network) from the nearest entrance, and get routed to the closest open restaurant.

  • If one restaurant is closed (region down), they’re redirected automatically to the next nearest one.

Global Accelerator vs CloudFront

• CloudFront → Optimized for content delivery (CDN), static + dynamic content.

• Global Accelerator → Optimized for improving network performance for non-HTTP apps too (TCP/UDP, gaming, VoIP, APIs).