This chapter covers Amazon CloudFront, AWS's content delivery network (CDN) service, which is a core topic for the SOA-C02 exam under Domain 5: Networking. CloudFront is used to deliver content with low latency and high transfer speeds by caching at edge locations worldwide. Approximately 10-15% of exam questions touch on CloudFront, covering distributions, origins, caching behaviors, security (including signed URLs/cookies and field-level encryption), and integration with other AWS services like S3, ALB, and Lambda@Edge. A SysOps administrator must understand how to configure, monitor, and troubleshoot CloudFront distributions to ensure optimal performance and security.
Jump to a section
Imagine a large pizza chain with a central kitchen in Chicago. Customers across the US call in orders, but the kitchen can only handle so many calls and deliveries take hours. To solve this, the chain opens dozens of local 'edge kitchens' in cities like New York, Los Angeles, and Dallas. Each edge kitchen stores pre-baked pizza crusts and common toppings. When a customer in New York orders a pepperoni pizza, the call is automatically routed to the New York edge kitchen. The edge kitchen checks if it has a pepperoni pizza ready (cache hit). If yes, it delivers immediately. If not (cache miss), it requests a fresh pizza from the Chicago central kitchen, which sends the pizza to the edge kitchen first, then to the customer. The edge kitchen keeps a copy for future orders. The chain also allows the central kitchen to invalidate old recipes (cache invalidation). The edge kitchens can handle many more orders simultaneously because they distribute the load. This is exactly how CloudFront works: edge locations cache content from an origin (like S3 or a web server), reducing latency and load on the origin. The pizza chain's routing system is like CloudFront's DNS-based routing, and the pre-baked crusts are like static assets.
What is Amazon CloudFront?
Amazon CloudFront is a global content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers with low latency and high transfer speeds. CloudFront integrates with AWS services such as Amazon S3, Elastic Load Balancing, and AWS Shield for DDoS protection. The service operates through a network of edge locations (points of presence, PoPs) that cache copies of your content close to your users.
How CloudFront Works Internally
When a user requests content served by CloudFront, the following occurs:
DNS Resolution: The user's DNS resolver queries for the CloudFront distribution domain name (e.g., d123.cloudfront.net). CloudFront's DNS returns the IP address of the edge location that is most likely to provide the best performance (usually the nearest edge).
Edge Request: The user's request is forwarded to that edge location. The edge location checks its cache for the requested object.
Cache Hit: If the object is in the cache and not expired, the edge returns it directly to the user. This is a cache hit.
Cache Miss: If the object is not in cache (or is expired), the edge forwards the request to the origin server (e.g., an S3 bucket or HTTP server). This is a cache miss. The edge fetches the object from the origin, stores it in cache according to the cache policy, and then returns it to the user.
Cache Behavior: CloudFront uses a cache behavior to determine how to handle requests for a given URL path pattern. Each cache behavior specifies the origin, viewer protocol policy (HTTP or HTTPS), allowed HTTP methods, and TTL (time to live) settings.
Key Components, Values, Defaults, and Timers
Distribution: The core entity. Two types: web distribution (for static and dynamic content, like HTTP/HTTPS) and RTMP distribution (for streaming media, deprecated).
Origin: The source of the content. Can be an S3 bucket, an Elastic Load Balancer, an EC2 instance, or any HTTP server. For S3 origins, you can configure Origin Access Control (OAC) to restrict access to only CloudFront.
Edge Location: Over 450 points of presence globally. Each edge can cache objects.
Cache Behavior: Defines how requests are processed. Key settings:
- Path pattern (e.g., /images/*) - Viewer protocol policy (HTTP and HTTPS, Redirect HTTP to HTTPS, or HTTPS only) - Allowed HTTP methods (GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE) - Cache key: Determines what values to include in the cache key (e.g., query strings, headers, cookies). Default is to use only the URL path. - TTL: Minimum TTL (default 0 seconds), Maximum TTL (default 31536000 seconds, or 365 days), and Default TTL (default 86400 seconds, or 1 day). - Origin request policy: Controls what headers, cookies, and query strings are forwarded to the origin. - Response headers policy: Adds headers to responses (e.g., CORS headers).
Price Class: Controls which edge locations are used. Price Class All (all regions, highest cost), Price Class 200 (most regions, except the most expensive), Price Class 100 (only North America and Europe, lowest cost).
Signed URLs and Signed Cookies: Used to restrict access to content. Signed URLs provide access to a single file; signed cookies provide access to multiple files. Both use a key pair (private key on CloudFront, public key on your side) to generate a signature that expires.
Field-Level Encryption: Encrypts sensitive data (e.g., credit card numbers) at the edge before forwarding to the origin. You specify fields to encrypt using a public key stored in CloudFront.
Lambda@Edge: Allows you to run code at edge locations in response to CloudFront events (viewer request, origin request, origin response, viewer response). Useful for custom authentication, A/B testing, or URL rewrites.
Invalidation: Removes objects from cache before they expire. You can invalidate by path (e.g., /images/*). The first 1000 paths per month are free; after that, $0.005 per path.
Origin Shield: An additional caching layer in a central region that reduces load on the origin and improves cache hit ratio. It is optional and incurs extra cost.
Configuration and Verification Commands
You can manage CloudFront distributions via AWS Management Console, AWS CLI, or SDKs. Key CLI commands:
# Create a distribution
aws cloudfront create-distribution --distribution-config file://config.json
# List distributions
aws cloudfront list-distributions
# Get a distribution config
aws cloudfront get-distribution --id E1A2B3C4D5E6F7
# Update a distribution
aws cloudfront update-distribution --id E1A2B3C4D5E6F7 --distribution-config file://config.json
# Create an invalidation
aws cloudfront create-invalidation --distribution-id E1A2B3C4D5E6F7 --paths /images/*
# List invalidations
aws cloudfront list-invalidations --distribution-id E1A2B3C4D5E6F7To verify distribution is working, you can use curl or wget to fetch a URL and check the X-Cache header:
curl -I https://d123.cloudfront.net/image.jpgThe response will include X-Cache: Hit from cloudfront or X-Cache: Miss from cloudfront.
Integration with Related Technologies
S3: Use Origin Access Control (OAC) to restrict S3 bucket access to CloudFront only. OAC replaces the older Origin Access Identity (OAI). For static website hosting, ensure the S3 bucket endpoint is configured as origin.
ALB: Use an Application Load Balancer as origin for dynamic content. CloudFront can cache responses from ALB based on cache headers.
AWS WAF: Associate a Web ACL with your CloudFront distribution to filter malicious requests. WAF can block IP addresses, SQL injection, XSS, etc.
AWS Shield: CloudFront comes with AWS Shield Standard automatically. For enhanced protection, subscribe to Shield Advanced.
Lambda@Edge: Trigger Lambda functions at edge events for custom logic.
ACM (AWS Certificate Manager): Use ACM to provision SSL/TLS certificates for your custom domain names. CloudFront supports dedicated IP (deprecated) and SNI (Server Name Indication).
Defaults and Limits
Default TTL: 86400 seconds (1 day)
Maximum TTL: 31536000 seconds (365 days)
Minimum TTL: 0 seconds
Maximum distribution per account: 200 (soft limit, can be increased)
Maximum cache behaviors per distribution: 25
Maximum origins per distribution: 25
Maximum file size for GET requests: 20 GB (if you enable chunked transfer encoding for PUT/POST, the limit is 5 GB)
Invalidation: Up to 3000 paths per invalidation request, up to 3000 active invalidations at a time.
Monitoring and Logging
CloudWatch Metrics: Include requests, bytes downloaded, 4xx/5xx error rates, cache hit ratio. Metrics are sent to CloudWatch every minute.
Access Logs: Optionally, CloudFront can deliver access logs to an S3 bucket. Each log entry contains details like timestamp, edge location, request URI, status code, and cache hit/miss.
Real-time Logs: You can configure real-time logs to Kinesis Data Streams for near-real-time analysis.
Security Features
HTTPS: CloudFront supports HTTPS for both viewer-to-edge and edge-to-origin connections. You can enforce HTTPS-only viewer protocol.
Signed URLs/Cookies: For content that requires authentication, generate signed URLs or cookies using a key pair. The signature includes an expiration date.
Field-Level Encryption: Encrypt specific data fields before forwarding to origin.
Origin Access Control (OAC): Restrict access to S3 origins so that only CloudFront can read objects.
AWS WAF: Integrate with WAF to block common web exploits.
Create a CloudFront distribution
In the AWS Management Console, navigate to CloudFront and click 'Create Distribution'. Choose a web distribution. Define the origin: for S3, select the bucket; for custom origin, enter the domain name (e.g., ALB DNS name). Configure cache behavior settings such as path pattern (default is /*), viewer protocol policy (recommend redirect HTTP to HTTPS), allowed HTTP methods, and cache policy (choose managed or custom). Optionally, set default TTL, maximum TTL, and minimum TTL. Under 'Distribution Settings', enter any alternate domain names (CNAMEs) and select a custom SSL certificate from ACM. Choose the default root object (e.g., index.html). Click 'Create Distribution'. Note: It takes about 5-10 minutes for the distribution to deploy globally.
Configure origin access control
If the origin is an S3 bucket, you should restrict access so that only CloudFront can read objects. In the distribution's origin settings, enable 'Origin Access Control' (OAC). Create a new OAC or use an existing one. Then, update the S3 bucket policy to allow the OAC's principal to get objects. The policy will look like: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"cloudfront.amazonaws.com"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::bucket-name/*","Condition":{"StringEquals":{"AWS:SourceArn":"arn:aws:cloudfront::account-id:distribution/distribution-id"}}}]}. This ensures that direct S3 access is blocked, and only CloudFront can retrieve objects.
Set up custom domain and SSL
To use your own domain (e.g., www.example.com) with CloudFront, add the domain as an alternate domain name in the distribution settings. You must also request or import an SSL/TLS certificate in AWS Certificate Manager (ACM) in the us-east-1 region (required for CloudFront). After the certificate is issued, select it in the distribution settings. Update your DNS provider to create a CNAME record pointing your domain to the CloudFront distribution domain name (e.g., d123.cloudfront.net). For the root domain (example.com), use an ALIAS record if your DNS provider supports it (e.g., Route 53). Ensure the viewer protocol policy is set to redirect HTTP to HTTPS or HTTPS only.
Configure caching behavior
You can customize caching per path pattern. For example, you might want images to be cached for a long time (e.g., 1 year) while HTML files are cached for a shorter period. Create a cache behavior with a path pattern like /images/*, and set TTLs accordingly. You can also choose a cache policy (managed or custom) that defines the cache key (e.g., include query strings, headers, cookies). For dynamic content, you might set the TTL to 0 and forward all query strings to the origin. Use origin request policies to forward specific headers (e.g., Authorization) to the origin. Response headers policies add headers like CORS. To invalidate cached objects after a change, create an invalidation (e.g., /images/*) to force CloudFront to fetch fresh content from the origin.
Enable logging and monitoring
In the distribution settings, under 'Standard logging', you can enable access logs by specifying an S3 bucket and an optional prefix. Access logs contain details about every request and are delivered within a few hours. For real-time monitoring, enable real-time logs to Kinesis Data Streams. CloudFront also publishes metrics to CloudWatch automatically (e.g., Requests, BytesDownloaded, 4xxErrorRate, CacheHitRate). You can set CloudWatch alarms to notify you if error rates exceed thresholds. Additionally, you can use AWS WAF to monitor and block malicious requests. For deeper analysis, you can query access logs using Amazon Athena.
Enterprise Scenario 1: Global Media Streaming
A video streaming service with users worldwide needs to deliver high-definition video content with low buffering. They use CloudFront with S3 as the origin for video files. They configure multiple cache behaviors: one for video segments (e.g., /videos/*) with a long TTL (1 year) and another for manifest files (e.g., /manifests/*) with a shorter TTL (5 minutes) to support dynamic bitrate switching. They enable Origin Shield in the US East region to reduce load on S3 and improve cache hit ratio. They use signed cookies for premium content, generating tokens with a 24-hour expiration. They also integrate AWS WAF to block requests from known malicious IPs. Monitoring shows a 95% cache hit ratio, reducing origin load by 90%. When misconfigured (e.g., TTL too short for static videos), the origin experiences spikes and users see buffering. The team uses CloudFront real-time logs to detect cache misses and adjust TTLs.
Enterprise Scenario 2: E-commerce Website with Dynamic Content
An e-commerce platform uses CloudFront to accelerate both static assets (CSS, JS, images) and dynamic API responses. They set up two origins: an S3 bucket for static files and an ALB for the backend application. For the static origin, they use OAC to restrict access. For the dynamic origin, they configure a cache behavior with TTL=0 and forward all query strings and the Authorization header to the ALB. They use Lambda@Edge to rewrite URLs for A/B testing and to add security headers (e.g., Content-Security-Policy). They also enable field-level encryption for credit card numbers submitted via forms. The distribution handles millions of requests per day. A common issue is forgetting to invalidate the cache after updating CSS files, causing users to see old styles. They automate invalidations via CI/CD pipelines. The team monitors cache hit ratio and error rates; a sudden drop in cache hit ratio often indicates a misconfiguration in the cache key (e.g., including a session cookie that changes per request).
Enterprise Scenario 3: Global API Acceleration
A SaaS company with customers worldwide uses CloudFront to accelerate REST API calls. They configure CloudFront with an ALB origin, setting the cache behavior to forward all headers (including Authorization) and set TTL=0 to ensure real-time responses. They use Lambda@Edge to add a custom header for authentication. They enable AWS WAF to block SQL injection and cross-site scripting. They also use CloudFront's Origin Shield to reduce the number of requests to the ALB. The distribution is configured with Price Class All to ensure low latency globally. A common misconfiguration is setting a positive TTL for API responses, causing stale data to be served. The team sets CloudWatch alarms on 5XX error rate; an increase often indicates the origin is overloaded or the ALB is misconfigured. They use access logs to debug specific requests and verify that Lambda@Edge functions are executing correctly.
What the SOA-C02 Exam Tests on CloudFront
The SOA-C02 exam covers CloudFront under Domain 5: Networking. Questions typically focus on: - Distribution configuration: Creating and updating distributions, cache behaviors, origins, and error pages. - Security: Origin Access Control (OAC) vs OAI, signed URLs and signed cookies, field-level encryption, and integration with AWS WAF. - Caching: TTL settings, cache hit ratio, cache invalidation, and cache key configuration (query strings, headers, cookies). - Performance: Price classes, Origin Shield, and Lambda@Edge. - Monitoring: CloudWatch metrics, access logs, real-time logs, and common error codes (4xx, 5xx). - Integration: S3, ALB, ACM, Route 53, and AWS Shield.
Common Wrong Answers and Why Candidates Choose Them
Using OAI instead of OAC: Many candidates choose OAI because it was the older method. But the exam now emphasizes OAC as the preferred method for S3 origin access. OAC uses IAM service principals and supports cross-account access, while OAI is legacy. If a question mentions 'restrict S3 bucket access to CloudFront only' and offers both OAI and OAC, OAC is the correct answer.
Setting TTL to 0 for all content: Candidates might think that setting TTL to 0 ensures freshness, but it disables caching and eliminates the benefit of CloudFront. The exam expects you to set appropriate TTLs based on content type.
Using signed URLs for entire site access: Signed URLs are for individual files; signed cookies are for multiple files. A question might ask for a solution that allows access to a set of files without changing URLs — the answer is signed cookies, not signed URLs.
Forgetting that CloudFront requires ACM certificate in us-east-1: Candidates may create the certificate in the same region as the origin (e.g., eu-west-1) and wonder why it doesn't appear in CloudFront. The exam tests that CloudFront only uses certificates from us-east-1.
Specific Numbers and Values to Memorize
Default TTL: 86400 seconds (1 day)
Maximum TTL: 31536000 seconds (365 days)
Minimum TTL: 0 seconds
Maximum file size for GET: 20 GB (with chunked transfer encoding for PUT/POST: 5 GB)
Invalidation pricing: first 1000 paths per month free, then $0.005 per path
Maximum cache behaviors per distribution: 25
Maximum origins per distribution: 25
Price Class All: all edge locations; Price Class 200: most regions except most expensive; Price Class 100: only US and Europe.
Edge Cases and Exceptions
Custom origin with HTTPS: If the origin uses a self-signed certificate, CloudFront will reject it. The origin must present a certificate signed by a trusted CA.
Cross-origin resource sharing (CORS): If your S3 bucket is configured for static website hosting, CloudFront must forward the Origin header to S3 to return proper CORS headers. This requires a custom cache policy that includes the Origin header in the cache key.
Lambda@Edge limits: Lambda@Edge functions must be in us-east-1, and have a maximum execution time of 5 seconds for viewer events and 30 seconds for origin events.
Invalidation propagation: Invalidations propagate to all edge locations within minutes, but some edges may serve stale content until the invalidation fully propagates.
How to Eliminate Wrong Answers
If a question asks about restricting S3 access, look for OAC (not OAI). If both appear, OAC is more secure and newer.
For caching, if the question mentions 'dynamic content that changes frequently', the answer should involve TTL=0 or forwarding specific headers to the origin.
For authentication, signed cookies are for multiple files; signed URLs for single files.
For SSL, always choose ACM certificate in us-east-1.
For performance, Origin Shield reduces origin load and improves cache hit ratio, but adds cost.
CloudFront is a global CDN that caches content at edge locations to reduce latency and origin load.
Default TTL is 86400 seconds (24 hours) if no Cache-Control headers from origin.
Use Origin Access Control (OAC) to restrict S3 bucket access to CloudFront only.
Signed URLs are for single files; signed cookies are for multiple files.
SSL certificates for CloudFront must be in us-east-1 (ACM).
Invalidation is used to remove cached objects before TTL expires; first 1000 paths/month free.
Lambda@Edge allows code execution at edge locations for custom logic.
CloudFront integrates with AWS WAF, Shield, and ACM for security and SSL.
Price classes control which edge locations are used; Price Class 100 (US/Europe) is cheapest.
Origin Shield is an optional caching layer that improves cache hit ratio and reduces origin load.
These come up on the exam all the time. Here's how to tell them apart.
Origin Access Control (OAC)
Uses IAM service principal: cloudfront.amazonaws.com
Supports cross-account access to S3 buckets
Works with S3 and other origins (e.g., ALB) via custom headers
Recommended by AWS for new distributions
More secure because it uses condition keys like AWS:SourceArn
Origin Access Identity (OAI)
Uses a special CloudFront user (e.g., E3...), not IAM
Only works with S3 origins
Does not support cross-account access
Legacy method, still supported but not recommended
Less secure because it relies on a static identity that can be shared
Signed URLs
Grants access to a single file
Requires changing the URL for each file
Useful for sharing individual files with expiration
Can be generated for any file path
Supports IP address restrictions
Signed Cookies
Grants access to multiple files (e.g., all files in a directory)
No need to change URLs; the cookie is sent automatically
Useful for protecting a set of files (e.g., a video streaming site)
Can be set for a specific domain and path
Supports IP address restrictions and session-based access
Mistake
CloudFront caches all content by default for 24 hours.
Correct
The default TTL is 86400 seconds (24 hours) only if no Cache-Control or Expires headers are present. If the origin provides Cache-Control headers, CloudFront respects them. The default TTL can be overridden in the cache behavior.
Mistake
CloudFront can only serve static content from S3.
Correct
CloudFront can serve both static and dynamic content from any origin, including ALB, EC2, or on-premises HTTP servers. It can cache dynamic content by setting TTL appropriately.
Mistake
Signed URLs and signed cookies are the same thing.
Correct
Signed URLs grant access to a single file, while signed cookies grant access to multiple files. Signed cookies are useful for protecting a set of files without changing URLs for each file.
Mistake
CloudFront automatically updates cached content when the origin changes.
Correct
CloudFront does not automatically invalidate cache when origin content changes. You must either wait for TTL expiration or manually create an invalidation to remove cached objects.
Mistake
You can use any ACM certificate for CloudFront regardless of region.
Correct
CloudFront only uses SSL/TLS certificates from AWS Certificate Manager (ACM) in the US East (N. Virginia) region (us-east-1). Certificates from other regions are not available for CloudFront.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use Origin Access Control (OAC). In your CloudFront distribution's origin settings, enable OAC and create a new control. Then update your S3 bucket policy to allow the OAC's principal (cloudfront.amazonaws.com) with a condition that restricts to your distribution's ARN. This ensures that direct S3 access is blocked. Note: OAC is the recommended method over the legacy OAI.
Signed URLs grant access to a single file; you must generate a URL for each file. Signed cookies grant access to multiple files; you set a cookie that the browser sends automatically. Use signed URLs for individual file sharing, and signed cookies for protecting a set of files (e.g., all videos in a directory). Both require a key pair and an expiration time.
You must add the custom domain as an alternate domain name (CNAME) in the distribution settings. Also, you need an SSL certificate from ACM in us-east-1 for HTTPS. Finally, update your DNS to point your domain (e.g., www.example.com) to the CloudFront distribution domain name (d123.cloudfront.net) using a CNAME record. For the root domain, use an ALIAS record in Route 53.
Create an invalidation. In the CloudFront console, go to your distribution, select the 'Invalidations' tab, and create a new invalidation with the paths you want to clear (e.g., /images/*). You can also use the AWS CLI: `aws cloudfront create-invalidation --distribution-id E1A2B3C4D5E6F7 --paths /images/*`. The first 1000 paths per month are free.
Origin Shield is an additional caching layer that sits between CloudFront edge locations and your origin. It consolidates requests from multiple edges, reducing the number of requests to the origin and improving cache hit ratio. Use it when you have many edge locations and want to reduce origin load. It adds an extra cost per request.
Yes, CloudFront can serve dynamic content by setting the TTL to 0 or a low value. You can configure cache behaviors to forward specific headers, query strings, or cookies to the origin. For example, you can forward the Authorization header for API requests. CloudFront still provides benefits like DDoS protection and SSL termination even for dynamic content.
CloudFront publishes metrics to CloudWatch automatically, including Requests, BytesDownloaded, 4xxErrorRate, 5xxErrorRate, and CacheHitRate. You can set alarms on these metrics. Additionally, enable access logs to an S3 bucket for detailed request-level analysis. Use real-time logs to Kinesis for near-real-time monitoring.
You've just covered CloudFront Distributions for SysOps — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?