This chapter dives deep into Amazon CloudFront, AWS's content delivery network (CDN) service. CloudFront is a core topic for the CLF-C02 exam under Domain 3: Cloud Technology Services, Objective 3.4 (Identify AWS services for content delivery). This objective carries approximately 8-10% of the exam weight. Understanding CloudFront's architecture, caching behavior, and integration with other AWS services is essential for answering scenario-based questions about low-latency content delivery, DDoS protection, and global application acceleration.
Jump to a section
Imagine you own a pizza restaurant in New York, but customers are calling from Tokyo, London, and Sydney. If you bake and deliver each pizza from New York, the Tokyo customer waits 30 minutes for their pizza to travel across the ocean, and it arrives cold. That's like serving web content from a single origin server. CloudFront is like building a network of local pizza kitchens (edge locations) around the world. You bake the pizzas (origin files) once in New York (the origin server), then freeze them (cache) and ship them overnight to each local kitchen. Now when a Tokyo customer orders, the local kitchen reheats the pizza (serves from cache) and delivers it in under 2 minutes — hot and fresh. If a customer wants a custom topping not in the freezer (a cache miss), the kitchen calls New York, bakes a fresh pizza, and serves it, but also stores a copy for the next order. The frozen pizzas have a 'use by' date (TTL) — after that, the kitchen checks with New York for a fresh batch. CloudFront also lets you block bad customers (geo-restriction) and encrypt the pizza box (HTTPS). This is exactly how CloudFront accelerates content delivery: static files are cached at edge locations close to users, reducing latency and load on the origin.
What is CloudFront and the Problem It Solves
Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds. The fundamental problem CloudFront solves is the latency caused by geographic distance. When a user in Australia requests content from a server in the US, the data must travel thousands of miles across the internet, passing through multiple routers and undersea cables. This results in high latency (often 200-300 ms) and potential packet loss. CloudFront mitigates this by caching copies of content at edge locations — over 600 points of presence (PoPs) in more than 90 cities across 50+ countries. When a user requests content, CloudFront routes the request to the nearest edge location, which serves the cached copy if available, dramatically reducing latency to under 50 ms in many cases.
How CloudFront Works — The Mechanism
CloudFront operates on a pull-through caching model. Here's the step-by-step mechanism:
Distribution Creation: An administrator creates a CloudFront distribution, specifying the origin (e.g., an S3 bucket, an HTTP/HTTPS server like an ALB, or an AWS MediaPackage endpoint). The distribution is assigned a domain name like d123.cloudfront.net.
Edge Location Selection: When a user requests a file (e.g., https://d123.cloudfront.net/image.jpg), DNS resolves the CloudFront domain to the IP of the nearest edge location based on latency or geographic proximity. CloudFront uses its own global network of edge locations, not public DNS, to route traffic optimally.
Cache Hit: If the edge location has a valid cached copy of the file (within its Time-to-Live or TTL), it serves the file directly to the user. This is a cache hit. The user gets low latency, and the origin server is not accessed.
Cache Miss: If the edge location does not have the file (first request or TTL expired), it forwards the request to the origin server. The origin returns the file to the edge location, which then caches it according to the configured TTL and serves it to the user. Subsequent requests for the same file from users in the same region will be cache hits.
TTL and Cache Invalidation: TTL is set via Cache-Control and Expires headers from the origin, or via CloudFront default TTL settings (24 hours default, minimum 0 seconds, maximum 365 days). To force removal of cached content before TTL expires, you can create an invalidation request, which charges per path.
Origin Shield: An optional layer that adds a regional caching tier between edge locations and the origin, reducing load on the origin by aggregating requests from multiple edge locations.
Key Configurations and Pricing
CloudFront offers several configuration options that impact performance and cost:
Price Class: Controls which edge locations serve your content. Price Class All (all edge locations) is most expensive but provides global coverage. Price Class 200 excludes the most expensive regions. Price Class 100 uses only North America and Europe. Choosing a lower price class reduces cost but may increase latency for users outside those regions.
Origin: Can be S3 bucket (static content), Elastic Load Balancer (dynamic content), AWS Elemental MediaStore/MediaPackage (video streaming), or custom HTTP/HTTPS server.
Cache Behavior: Allows different caching rules for different URL path patterns. For example, /images/* can have a longer TTL than /api/*.
Signed URLs and Signed Cookies: For restricting access to premium content. Signed URLs grant access to individual files; signed cookies grant access to groups of files.
Geo-Restriction: Whitelist or blacklist countries from accessing content.
SSL/TLS: Supports custom SSL certificates via AWS Certificate Manager (ACM) or IAM, enabling HTTPS. CloudFront provides a default domain name (*.cloudfront.net) with a shared certificate.
Lambda@Edge: Run serverless code at edge locations to customize content based on viewer request/response. For example, rewrite URLs, modify headers, or A/B test.
Pricing includes data transfer out (from edge to internet) and HTTP/HTTPS requests. Data transfer out from edge to origin (origin fetch) is free. There is no upfront cost; you pay per request and per GB transferred. Invalidation costs $0.005 per path.
Comparison to On-Premises CDN or No CDN
Without a CDN, you would serve all content from a single data center. Users far from that data center experience high latency. You would also need to scale the origin server to handle global traffic spikes, leading to overprovisioning. An on-premises CDN would require deploying servers in multiple locations globally, which is expensive and operationally complex. CloudFront eliminates this by providing a managed, pay-as-you-go CDN with integrated security features like AWS Shield (DDoS protection) and AWS WAF (web application firewall).
When to Use CloudFront vs Alternatives
- Use CloudFront when: You need low-latency delivery of static or dynamic content to a global audience; you want to offload origin servers; you need DDoS protection and SSL termination at the edge; you are serving video on demand or live streaming; you need to protect content with signed URLs. - Alternatives: - S3 Transfer Acceleration: Speeds up uploads to S3, but only for uploads, not downloads. Not a full CDN. - AWS Global Accelerator: Improves availability and performance for TCP/UDP applications using AWS global network, but does not cache content. It's for dynamic content (APIs, gaming) where caching doesn't help. - Third-party CDNs (e.g., Cloudflare, Akamai): Can be used with AWS, but CloudFront integrates natively with other AWS services (S3, Lambda@Edge, Shield) and offers consistent pricing within the AWS ecosystem.
Create an S3 bucket as origin
First, create an S3 bucket to store your static content (e.g., images, CSS, JavaScript). Enable 'Block all public access' because CloudFront will access the bucket via an Origin Access Control (OAC) — a new feature replacing Origin Access Identity (OAI). OAC ensures that content is only accessible through CloudFront, not directly via S3 URL. Upload your files (e.g., index.html, error.html) to the bucket. Note: If you want to use custom error pages, you can configure CloudFront to return a specific object (like error.html) for 4xx/5xx errors.
Create a CloudFront distribution
In the CloudFront console, click 'Create Distribution'. Select 'Web' for HTTP/HTTPS delivery. Under 'Origin', choose the S3 bucket you created. For 'Origin access', select 'Origin access control settings' and create a new OAC. CloudFront will generate a policy that you must attach to the S3 bucket (the console provides a button to copy the policy). Under 'Default cache behavior', set 'Viewer protocol policy' to 'Redirect HTTP to HTTPS' for security. Set 'Allowed HTTP methods' to GET, HEAD (for static content). For 'Cache key and origin requests', you can use the default or customize. Click 'Create Distribution'.
Configure cache behavior settings
After creation, you can add additional cache behaviors for different path patterns. For example, if you have an `/api/` path that should not be cached, create a cache behavior with path pattern `/api/*`, set 'Minimum TTL' to 0 and 'Maximum TTL' to 0, and 'Default TTL' to 0. For static assets like images, you can set a longer TTL (e.g., 1 year) by configuring the origin to send `Cache-Control: max-age=31536000` header. You can also set custom error responses (e.g., 403 -> /error.html). CloudFront allows up to 25 cache behaviors per distribution.
Set up custom domain and SSL
By default, your distribution has a CloudFront domain (e.g., d123.cloudfront.net). To use your own domain (e.g., www.example.com), add an alternate domain name (CNAME) in the distribution settings. Then, request an SSL certificate from AWS Certificate Manager (ACM) in the US East (N. Virginia) region (required for CloudFront). After validation, select the certificate in the distribution. Update your DNS provider to point your domain to the CloudFront distribution's domain name using a CNAME or A record (Alias if using Route 53).
Test and monitor the distribution
After deployment (which takes 5-10 minutes), access your content via the CloudFront URL. Check that HTTPS works and that the correct content is served. Use CloudFront's monitoring tools: CloudFront metrics in CloudWatch (e.g., Requests, Bytes Downloaded, Error Rate, Cache Hit Rate). Enable access logs to capture detailed request logs stored in an S3 bucket. Monitor cache hit rate – a low rate may indicate misconfigured TTLs or cache key settings. Use the 'Origin Shield' feature to improve cache hit rate if you have many edge locations hitting the same origin.
Scenario 1: E-commerce Website with Global Audience
A fashion retailer based in London serves customers worldwide. Their website includes static assets (product images, CSS, JavaScript) and dynamic content (prices, inventory). They use CloudFront to cache static assets at edge locations with a TTL of 7 days. For dynamic content, they set TTL to 0 and use CloudFront as a reverse proxy with Lambda@Edge to add security headers. The origin is an Application Load Balancer (ALB) behind an Auto Scaling group. Cost: They pay for data transfer out from edge to users (~$0.085/GB for most regions) and request fees ($0.0075 per 10,000 requests). They save on ALB data transfer costs because CloudFront reduces origin load by 80%. Misconfiguration: If they set TTL too high for dynamic content, users see stale prices. If they disable geo-restriction, they might violate export laws.
Scenario 2: Video Streaming Platform
A media company streams live events and on-demand videos. They use AWS Elemental MediaLive for live encoding and MediaPackage for packaging, with CloudFront as the delivery layer. CloudFront supports both HLS and DASH streaming protocols. They use signed URLs to protect premium content. For live events, they use Origin Shield to reduce load on MediaPackage. Cost: Data transfer out for video is high (e.g., 10 TB/month could cost $850). They optimize by using reserved capacity pricing or negotiating with AWS. Misconfiguration: If they forget to enable signed URLs, content can be downloaded by anyone. If they set TTL too low for manifest files, players re-fetch frequently, increasing origin load.
Scenario 3: Software Update Distribution
A software company distributes large binary updates (1 GB) to millions of devices worldwide. They use CloudFront with S3 as origin. They enable S3 Transfer Acceleration for uploads from developers. CloudFront caches the update files at edge locations. They use invalidation to immediately remove old versions. Cost: Data transfer out is the main cost; they use Price Class 100 to limit distribution to North America and Europe if updates are not needed elsewhere. Misconfiguration: If they do not set proper Cache-Control headers, the same file may be cached with different versions across edge locations. They use versioned filenames (e.g., setup-v2.exe) to avoid cache issues.
What CLF-C02 Tests on CloudFront
The exam focuses on understanding CloudFront as a global content delivery service that improves performance and security. Specific areas: - Latency reduction: CloudFront caches content at edge locations to reduce latency for end users. - DDoS protection: CloudFront integrates with AWS Shield Standard (free) and Shield Advanced (paid) to protect against DDoS attacks. - Origin types: S3, ALB, EC2, custom HTTP server. - Cache behavior: TTL, cache key, and cache hit vs miss. - Security features: Signed URLs/cookies, geo-restriction, HTTPS, OAC. - Pricing: Data transfer out, request fees, invalidation costs. - Integration: Works with Lambda@Edge, WAF, Route 53.
Common Wrong Answers and Why Candidates Choose Them
'CloudFront can only cache static content.' → Wrong. CloudFront can cache both static and dynamic content. Dynamic content can be served with TTL=0, effectively acting as a reverse proxy. Candidates confuse CloudFront with simple CDNs that only cache static files.
'CloudFront is only for content stored in S3.' → Wrong. CloudFront supports any HTTP/HTTPS origin, including on-premises servers, as long as they are publicly accessible or accessible via VPC (using CloudFront's origin access control). Candidates often associate CloudFront only with S3 because it's the most common use case.
'CloudFront improves performance by compressing data.' → Partially correct but not the primary mechanism. CloudFront does support compression, but its main value is caching at edge locations. Candidates may choose this answer if they don't understand the caching mechanism.
'CloudFront acts as a global load balancer.' → Wrong. Global Accelerator is the global load balancer. CloudFront is a CDN. Candidates mix up the two services because both use edge locations.
Tricky Distinctions
CloudFront vs Global Accelerator: CloudFront caches content (static/dynamic), uses HTTP/HTTPS, and provides DDoS protection. Global Accelerator does not cache; it optimizes TCP/UDP traffic routing via AWS global network for any application (HTTP, gaming, VoIP).
CloudFront vs S3 Transfer Acceleration: TA accelerates uploads to S3, not downloads. CloudFront accelerates both uploads (via PUT/POST) and downloads, but for uploads, TA is simpler and cheaper.
OAC vs OAI: The exam may mention OAI (older) or OAC (newer). OAC is now the recommended way to restrict S3 bucket access to CloudFront. Both serve the same purpose.
Decision Rule
If a question asks about 'low latency', 'global audience', 'caching', or 'DDoS protection for web content', the answer is likely CloudFront. If it asks about 'dynamic content that cannot be cached' or 'TCP/UDP optimization', think Global Accelerator. If it asks about 'upload acceleration to S3', think S3 Transfer Acceleration.
CloudFront is a global CDN that caches content at over 600 edge locations to reduce latency for end users.
It supports origins including S3, ALB, EC2, and any HTTP/HTTPS server.
TTL is controlled by Cache-Control headers; default TTL is 24 hours.
Cache hit vs miss: hit serves from edge, miss fetches from origin and caches.
CloudFront integrates with AWS Shield (DDoS protection) and AWS WAF (web ACLs).
Signed URLs and signed cookies restrict access to content.
Price Class limits which edge locations serve content to reduce cost.
Invalidation costs $0.005 per path after first 1,000 free per month.
Use Origin Shield to improve cache hit rate and reduce origin load.
CloudFront supports HTTP/HTTPS, WebSocket, and RTMP (for Adobe Flash) — but RTMP is deprecated.
Lambda@Edge allows running code at edge locations for custom logic.
CloudFront is different from Global Accelerator: CloudFront caches, Global Accelerator does not.
These come up on the exam all the time. Here's how to tell them apart.
Amazon CloudFront
Content delivery network (CDN) that caches content at edge locations
Works at HTTP/HTTPS layer (Layer 7)
Reduces latency by serving cached content from nearest edge
Integrates with Lambda@Edge for custom logic at the edge
Supports SSL termination, geo-restriction, signed URLs
AWS Global Accelerator
Network service that improves availability and performance for TCP/UDP traffic
Works at TCP/UDP layer (Layer 4) with any application protocol
Reduces latency by routing traffic over AWS global network, no caching
Provides static IP addresses (anycast) for fixed endpoints
Integrates with AWS Shield for DDoS protection, no content-level features
CloudFront with S3 Origin
Accelerates both uploads and downloads
Caches content at edge locations for repeated downloads
Provides DDoS protection, SSL, and custom domain
Supports dynamic content and Lambda@Edge
Priced per request and data transfer out
S3 Transfer Acceleration
Accelerates only uploads to S3
No caching; uses edge locations for optimized network path
No DDoS protection or custom domain (uses S3 endpoint)
Only for PUT/POST/GET uploads to S3
Priced per GB transferred (premium over standard S3 transfer)
Mistake
CloudFront only works with AWS origins like S3 and ALB.
Correct
CloudFront can use any HTTP/HTTPS server as an origin, including on-premises servers, as long as they are accessible from the internet or via a VPC using CloudFront's origin access control with a custom header.
Mistake
CloudFront automatically caches all files for the same TTL.
Correct
TTL is determined by Cache-Control and Expires headers from the origin. If no headers are set, CloudFront uses a default TTL of 24 hours. You can override this with minimum, maximum, and default TTL settings in the cache behavior.
Mistake
CloudFront guarantees 100% cache hit rate.
Correct
Cache hit rate depends on traffic patterns, TTL settings, and cache key configuration. First requests always miss. Low TTL reduces hit rate. Using Origin Shield can improve hit rate by aggregating requests.
Mistake
CloudFront pricing is based on the number of edge locations used.
Correct
Pricing is based on data transfer out and request count. Price Class controls which edge locations serve content, but you pay the same per-GB rate regardless of which edge location serves the request (except for region-specific data transfer out rates).
Mistake
CloudFront invalidation is free.
Correct
Invalidation costs $0.005 per path. The first 1,000 paths per month are free. To avoid costs, use versioned filenames instead of invalidating.
The main purpose of CloudFront is to deliver content to users with low latency and high transfer speeds by caching copies at edge locations around the world. It acts as a content delivery network (CDN) that reduces load on origin servers and improves user experience. For the exam, remember that CloudFront is the go-to service for global content delivery and DDoS protection for web applications.
CloudFront uses a DNS-based routing system that directs each user request to the edge location that provides the lowest latency for that user. The system continuously monitors network conditions and routes traffic accordingly. This is automatic and requires no configuration. For the exam, know that CloudFront selects the nearest edge location based on latency, not geographic distance.
A cache hit occurs when the requested content is already stored at the edge location and is served directly to the user. A cache miss occurs when the content is not cached, so CloudFront fetches it from the origin, caches it, and then serves it. Cache hits reduce latency and origin load. The cache hit rate is a key metric. For the exam, understand that the first request for a file is always a cache miss.
You can secure content using signed URLs or signed cookies to restrict access to authorized users. Additionally, you can use geo-restriction to block or allow requests from specific countries. CloudFront also supports HTTPS with custom SSL certificates. For S3 origins, use Origin Access Control (OAC) to ensure content is only accessible via CloudFront. The exam may ask which feature to use for different security requirements.
CloudFront charges based on data transfer out to the internet (per GB) and the number of HTTP/HTTPS requests. There are different rates for different regions (e.g., US/Europe is cheaper than South America or Asia). You also pay for invalidation requests ($0.005 per path after 1,000 free). There is no upfront cost. The exam may ask about cost optimization using Price Class or invalidations.
Yes, CloudFront can handle dynamic content by setting TTL to 0, meaning it does not cache the content but still provides benefits like SSL termination, DDoS protection, and a global network of edge locations that route requests to the origin. You can also use Lambda@Edge to modify content at the edge. For the exam, remember that CloudFront is not just for static content.
Origin Shield is an optional regional caching layer that sits between edge locations and the origin. It aggregates requests from multiple edge locations in a region, reducing the number of requests to the origin. This improves cache hit rates and reduces origin load. It incurs additional costs. The exam may test your understanding of Origin Shield as a feature to optimize performance and cost.
You've just covered CloudFront Deep Dive — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?