This chapter covers Amazon CloudFront, AWS's content delivery network (CDN), and Lambda@Edge, which allows running code at CloudFront edge locations in response to events. For the DVA-C02 exam, these topics are tested in Domain 1 (Development), Objective 1.4 (Implementing CDN and edge computing), and typically appear in 5-10% of questions. You will need to understand CloudFront distribution types, cache behaviors, TTLs, origins, and how Lambda@Edge can manipulate requests and responses. Mastery of these concepts is critical for designing low-latency, globally distributed applications.
Jump to a section
Imagine a global library chain with hundreds of branches worldwide. Each branch stores copies of popular books (cached content) so readers don't have to travel to the central archive (origin server) every time. When a reader requests a book, the nearest branch serves it instantly if available. If not, the branch fetches a copy from the central archive, keeps one for future requests, and hands it to the reader. Now, imagine each branch also has a small team of editors (Lambda@Edge) that can modify the book on the fly before giving it to the reader—for example, translating the title into the local language, adding a personalized cover, or checking the reader's membership status. These editors work at the branch level, not at the central archive, so the changes happen quickly and close to the reader. The central archive remains unchanged. The library chain's operations team configures which branches exist, which books are pre-stocked (cache behaviors), and what editing tasks each branch performs. This mirrors how CloudFront uses edge locations to cache and serve content, and Lambda@Edge functions execute code at those edges to customize requests and responses without modifying the origin.
What is Amazon CloudFront?
Amazon CloudFront is a fast content delivery network (CDN) that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds. It integrates with AWS services like S3, Elastic Load Balancing, EC2, and Lambda@Edge. CloudFront uses a global network of edge locations to cache content and serve it to users from the nearest edge, reducing load on origin servers and improving user experience.
Key Concepts: Distributions, Origins, and Cache Behaviors
A CloudFront distribution is a configuration unit that defines how content is delivered. Each distribution has an origin (e.g., S3 bucket, HTTP server) and cache behaviors that specify URL path patterns, TTLs, and allowed HTTP methods. You can have multiple origins per distribution, each associated with specific path patterns. For example, /api/* can route to an Application Load Balancer, while /images/* routes to an S3 bucket.
How CloudFront Works Internally
When a user requests content, DNS resolves the CloudFront distribution's domain name to the nearest edge location. The edge checks its cache for the requested object. If cached and not expired (based on TTL), it returns the object immediately. If not cached, the edge forwards the request to the origin, caches the response (according to cache control headers or default TTL), and returns it to the user. CloudFront supports both GET/HEAD requests for caching and POST/PUT/DELETE that are forwarded to origin without caching.
Cache Behaviors and TTLs
Cache behaviors determine how long objects stay in edge caches. You can set Minimum TTL, Maximum TTL, and Default TTL (seconds). CloudFront uses the Cache-Control max-age and Expires headers from the origin. If headers are present, CloudFront uses the longest of max-age (within Min/Max TTL bounds). If no headers, it uses Default TTL. The default Default TTL is 86400 seconds (24 hours). You can also use origin response headers like s-maxage to override. Invalidating cache removes objects from all edge locations; you can invalidate by path or use versioned filenames.
Origins and Origin Groups
Origins can be S3 buckets (with or without OAI), EC2 instances, ELBs, or any HTTP(S) server. For high availability, you can configure origin groups with primary and secondary origins. If the primary fails (e.g., 5xx errors), CloudFront fails over to the secondary. Origin failover is configured per cache behavior.
Lambda@Edge Overview
Lambda@Edge allows you to run Lambda functions at CloudFront edge locations to customize content. You can trigger functions on four events: Viewer Request (when CloudFront receives a request from a viewer), Origin Request (before forwarding request to origin), Origin Response (after receiving response from origin), and Viewer Response (before returning response to viewer). Functions can modify requests/responses, generate new responses, or perform authentication/authorization.
Lambda@Edge Execution and Limitations
Lambda@Edge functions are replicated to all edge locations. They have a maximum execution time of 5 seconds for viewer events and 30 seconds for origin events. Memory can be up to 3008 MB. Environment variables and layers are not supported. Functions must be in us-east-1 region. They cannot access VPC resources (no VPC networking). The function code and all dependencies must be under 1 MB (zipped).
Use Cases for Lambda@Edge
A/B testing: Serve different versions of content based on cookies or headers.
User authentication: Redirect unauthenticated users to a login page.
Header manipulation: Add security headers (e.g., HSTS) or remove sensitive headers.
URL rewriting: Redirect /old-path to /new-path.
Image optimization: Resize or convert images on the fly (though this is better suited for CloudFront Functions or dedicated services).
CloudFront Functions vs. Lambda@Edge
CloudFront Functions are lightweight, sub-1ms execution, for simple manipulations like URL rewrites or header modifications. Lambda@Edge is more powerful (longer execution, access to external services) but slower to invoke. For the exam, know: CloudFront Functions run only on viewer events, have no network access, and cost less. Lambda@Edge can access external resources (e.g., DynamoDB, S3) but cannot access VPC.
Security: Origin Access Identity (OAI) and Signed URLs/Cookies
To restrict access to S3 origins, you can create an Origin Access Identity (OAI) that only CloudFront can use to access the bucket. For private content, you can use signed URLs or signed cookies to restrict access to specific users. Signed URLs give access to one file; signed cookies give access to multiple files. You can also use AWS WAF with CloudFront for web application firewall protection.
Geo-Restrictions and Price Class
CloudFront allows geo-restriction: you can block or allow countries. Price Class determines which edge locations are used: Price Class All (all locations), Price Class 200 (most regions, excluding expensive ones), Price Class 100 (only North America and Europe). This affects delivery latency and cost.
Real-Time Logs and Monitoring
CloudFront can deliver real-time logs to Kinesis Data Streams for monitoring. You can also access standard access logs in S3. Metrics like requests, bytes downloaded, error rates are available in CloudWatch.
Interactions with Other AWS Services
CloudFront + S3: Static website hosting with caching.
CloudFront + ELB: Dynamic content with global distribution.
CloudFront + Lambda@Edge: Serverless edge computing.
CloudFront + AWS WAF: Web application firewall.
CloudFront + ACM: Custom SSL/TLS certificates (must be in us-east-1).
CloudFront + Route 53: DNS routing to distribution.
Default Values and Limits
Default TTL: 86400 seconds (24 hours)
Minimum TTL: 0 seconds
Maximum TTL: 31536000 seconds (365 days)
Lambda@Edge timeout: 5 seconds (viewer events), 30 seconds (origin events)
Lambda@Edge memory: 128 MB to 3008 MB
Distribution limit: 200 distributions per account (soft limit, can be increased)
Maximum cache behavior per distribution: 25
Maximum origin per distribution: 25
Maximum file size for PUT/POST: 20 GB via CloudFront (with chunked upload)
CLI Commands and Verification
To create a CloudFront distribution: aws cloudfront create-distribution --origin-domain-name example.s3.amazonaws.com --default-root-object index.html
To list distributions: aws cloudfront list-distributions
To update a distribution (using ETag): aws cloudfront update-distribution --id E1A2B3C4D5E6 --distribution-config file://config.json --if-match E123...
To invalidate cache: aws cloudfront create-invalidation --distribution-id E1A2B3C4D5E6 --paths /images/*
To publish a Lambda@Edge function (must be in us-east-1): aws lambda publish-version --function-name my-edge-function Then associate with CloudFront via the distribution's cache behavior.
Step-by-Step: How a Request Flows with Lambda@Edge
User requests https://d123.cloudfront.net/photo.jpg
DNS resolves to nearest edge location.
Viewer Request event triggers Lambda@Edge function (if configured). The function can inspect/modify headers, cookies, or even generate a response (e.g., redirect).
If the request is allowed to proceed, CloudFront checks cache for /photo.jpg.
If cached and not expired, CloudFront returns the object directly (skipping origin).
If not cached, Origin Request event triggers another Lambda@Edge function (if configured). The function can modify the request before it goes to origin (e.g., add authentication headers).
CloudFront forwards the request to the origin (e.g., S3 bucket).
Origin returns response. Origin Response event triggers Lambda@Edge function (if configured). The function can modify the response (e.g., add headers, compress, or even replace content).
CloudFront caches the response according to TTL.
Viewer Response event triggers Lambda@Edge function (if configured) before sending response to user. The function can modify final response headers or body.
User receives the response.
Note: Viewer Request and Viewer Response are triggered for every request, even cache hits. Origin Request and Origin Response are only triggered on cache misses (when CloudFront must go to origin).
Common Pitfalls and Exam Traps
Lambda@Edge functions must be in us-east-1. If you create them in another region, they won't appear.
Lambda@Edge cannot access VPC resources. If you need to access RDS, use a different approach.
CloudFront Functions are for lightweight tasks; Lambda@Edge for heavy lifting.
Signed URLs vs. Signed Cookies: URLs for single file access, cookies for multiple files.
OAI only works with S3 origins; for custom origins, use headers or WAF.
Invalidations are not free; you pay per path. Use versioned filenames to avoid invalidation costs.
Default TTL of 24 hours can cause stale content if not set properly.
Lambda@Edge functions are replicated globally; updates can take time to propagate.
Viewer Request functions cannot access the request body (only headers). Origin Request can access body.
Lambda@Edge execution limits: 5 seconds for viewer events, 30 seconds for origin events. If exceeded, function fails.
The function's response must match CloudFront's expected format; otherwise, errors occur.
Verification Commands
Check Lambda@Edge function association: aws cloudfront get-distribution --id E1A2B3C4D5E6 --query 'Distribution.DistributionConfig.CacheBehaviors.Items[*].LambdaFunctionAssociations'
Test a distribution: curl -I https://d123.cloudfront.net/photo.jpg
Check cache hits via headers: Look for X-Cache: Hit from cloudfront or Miss from cloudfront in response headers.
Integration with AWS Certificate Manager (ACM)
To use HTTPS with CloudFront, you must request or import a certificate in ACM in us-east-1. CloudFront cannot use certificates from other regions. You can use default CloudFront domain name (*.cloudfront.net) with SSL, but for custom domain, you need ACM certificate.
Summary of Key Exam Points
CloudFront is a CDN for low-latency content delivery.
Lambda@Edge runs code at edge locations on four events.
Viewer events fire on every request; origin events fire only on cache misses.
Lambda@Edge functions must be in us-east-1 and cannot access VPC.
CloudFront Functions are simpler and cheaper for lightweight tasks.
OAI restricts S3 bucket access to CloudFront only.
Signed URLs/cookies for private content.
TTLs control caching; invalidations remove cached objects.
Origin groups provide failover.
Price Class limits edge locations for cost control.
Geo-restriction allows country-level blocking.
Real-time logs to Kinesis for monitoring.
Default limits: 200 distributions, 25 cache behaviors, 25 origins per distribution.
Maximum file size: 20 GB for PUT/POST.
Lambda@Edge limits: 5/30 sec timeout, 3008 MB memory, 1 MB zipped code.
This comprehensive understanding will prepare you for DVA-C02 exam questions on CloudFront and Lambda@Edge.
User requests content via CloudFront URL
A user enters a URL like https://d123.cloudfront.net/photo.jpg into their browser. DNS resolves the CloudFront distribution's domain name to the IP address of the nearest edge location based on latency. The browser sends an HTTP GET request to that edge location. This step is transparent to the user; they only see the final content. The request includes headers like Host, User-Agent, and possibly cookies. The edge location is one of over 450 Points of Presence globally.
Viewer Request Lambda@Edge triggers
If a Lambda@Edge function is associated with the Viewer Request event for the matching cache behavior, CloudFront invokes the function before checking cache. The function receives the request object and can modify headers, cookies, query strings, or even generate a response (e.g., redirect to HTTPS). The function must return a valid request or response within 5 seconds. If it returns a response, CloudFront sends that directly to the user, skipping cache and origin. This is often used for authentication or A/B testing.
CloudFront checks edge cache for object
CloudFront examines its local cache at the edge location for the requested object (e.g., /photo.jpg). It uses the cache key, which includes the URL and optionally query strings, headers, and cookies based on cache behavior settings. If the object is present and has not expired (based on TTL), it is a cache hit. CloudFront returns the object immediately with an X-Cache: Hit from cloudfront header. If not present or expired, it is a cache miss, and CloudFront proceeds to the origin.
Origin Request Lambda@Edge triggers (if cache miss)
On a cache miss, CloudFront invokes any Lambda@Edge function associated with the Origin Request event. This function can modify the request before it is sent to the origin. For example, it can add authentication headers, normalize URLs, or rewrite paths. The function has up to 30 seconds to execute. It must return a request object or a response. If it returns a response, CloudFront caches and returns that response without contacting the origin. This is useful for generating custom error pages or serving stale content.
CloudFront forwards request to origin
CloudFront sends the (possibly modified) request to the origin server. The origin can be an S3 bucket, an HTTP server, or an AWS service like ELB. CloudFront uses the origin's domain name and port (80 or 443). For S3 origins, CloudFront can use an OAI to authenticate. The origin processes the request and returns a response. CloudFront waits for the response; if the origin fails (e.g., 5xx error), CloudFront may retry or fail over to a secondary origin if configured.
Origin Response Lambda@Edge triggers
After receiving the response from the origin, CloudFront invokes any Lambda@Edge function associated with the Origin Response event. This function can modify the response headers or body before caching. For example, it can compress content, add security headers, or transform the body (e.g., inject JavaScript). The function has up to 30 seconds. It must return a response object. If the function throws an error, CloudFront returns the original response or an error depending on configuration.
CloudFront caches the response
CloudFront caches the response from the origin (or from the Origin Response function) in the edge location. The cache duration is determined by the Cache-Control max-age header, the Expires header, or the default TTL (24 hours), bounded by Minimum TTL and Maximum TTL settings. CloudFront also respects the s-maxage header for shared caches. The response is stored with the cache key. Subsequent requests for the same object from this edge will be cache hits until TTL expires.
Viewer Response Lambda@Edge triggers
Before sending the response to the user, CloudFront invokes any Lambda@Edge function associated with the Viewer Response event. This function can modify the response headers or body. It has up to 5 seconds. Common uses include adding CORS headers, setting cookies, or modifying the status code. The function must return a valid response. After this step, CloudFront sends the final response to the user's browser.
User receives the response
The user's browser receives the HTTP response, which includes headers like X-Cache (Hit/Miss), Age (seconds since cached), and any custom headers added by Lambda@Edge. The browser renders the content. If the response was a redirect, the browser follows it. This step completes the request lifecycle. For subsequent requests, steps 1-3 and 8-9 repeat, but cache hits skip steps 4-7.
Enterprise Scenario 1: Global E-commerce Platform
A large e-commerce company uses CloudFront to serve static assets (images, CSS, JavaScript) and dynamic API responses. They have an S3 bucket for images and an Application Load Balancer for API calls. They configure a single distribution with two origins: one S3 for /static/* and one ALB for /api/*. Cache behaviors are set with TTL of 1 day for static assets and 0 seconds for API responses (no caching). To handle user authentication, they use Lambda@Edge at Viewer Request to check for a session cookie. If missing, the function redirects to a login page. For A/B testing, they use Viewer Request to modify the request URL based on a cookie. In production, they serve millions of requests per day. They monitor cache hit ratio (target >90%) and use real-time logs to Kinesis for analytics. Misconfiguration: setting TTL too high for dynamic content leads to stale data; setting it too low for static assets increases origin load. They use CloudFront Functions for simple header modifications to reduce cost.
Enterprise Scenario 2: Media Streaming Platform
A video streaming service uses CloudFront to deliver video files (MP4, HLS) from S3. They use signed URLs to restrict access to paying users. Lambda@Edge at Viewer Request validates the signed URL by checking a custom header with a token. If invalid, it returns a 403 response. They also use Origin Response Lambda@Edge to add custom headers for DRM. They have origin groups for failover: primary S3 bucket in us-east-1, secondary in us-west-2. Cache TTL is set to 1 year for video files (since they are immutable). They invalidate cache only when re-uploading corrected versions. They use Price Class 200 to save costs, limiting edge locations to North America and Europe where most users are. They monitor CloudFront metrics for error rates and use CloudWatch alarms for origin failures. Misconfiguration: forgetting to update Lambda@Edge function version after code change leads to stale logic. They version their functions and use aliases to rollback.
Enterprise Scenario 3: SaaS Application with Global Users
A SaaS company provides a web application with both static and dynamic content. They use CloudFront with Lambda@Edge to perform URL rewriting for SEO-friendly URLs. For example, /product/123 is rewritten to /product?id=123 before reaching the origin. They use Viewer Request for rewriting, which is efficient because it runs on every request. They also add security headers (CSP, HSTS) via Viewer Response Lambda@Edge. They use CloudFront Functions for simple redirects (e.g., /home to /) to reduce cost. They have geo-restriction to block traffic from certain countries due to licensing. They use AWS WAF integrated with CloudFront to block SQL injection and XSS attacks. They set Minimum TTL to 0 and Default TTL to 3600 seconds for dynamic content that changes hourly. They use origin failover with a static error page on S3 if the primary origin fails. They test deployments using a staging distribution with a different domain. Misconfiguration: not enabling compression on CloudFront leads to higher bandwidth costs. They enable Automatic Compression for text files.
The DVA-C02 exam tests CloudFront and Lambda@Edge under Domain 1: Development, Objective 1.4: Implement CDN and edge computing. Expect 5-10 questions covering: distribution types, cache behaviors, TTLs, origins, Lambda@Edge triggers, limitations, and security features.
Common Wrong Answers and Why Candidates Choose Them
Lambda@Edge functions can be created in any region. Wrong. They must be in us-east-1. Candidates often assume regional flexibility, but CloudFront requires this.
Lambda@Edge can access VPC resources. Wrong. Lambda@Edge runs at edge locations, not in VPC. Candidates may think it's like regular Lambda.
CloudFront Functions can modify origin requests. Wrong. CloudFront Functions only run on viewer events (request/response). Origin events require Lambda@Edge.
Signed cookies are used for single file access. Wrong. Signed URLs are for single files; signed cookies for multiple files. Candidates confuse the two.
Default TTL is 0 seconds. Wrong. Default is 86400 seconds (24 hours). Candidates may assume no caching by default.
Invalidations are free. Wrong. You pay per path invalidated. Candidates may not know costs.
OAI works with any origin. Wrong. OAI only works with S3 origins. For custom origins, use custom headers or WAF.
Specific Numbers and Terms That Appear on the Exam
Lambda@Edge timeout: 5 seconds (viewer), 30 seconds (origin)
Lambda@Edge memory: up to 3008 MB
Lambda@Edge code size: 1 MB (zipped)
CloudFront Functions timeout: 5 milliseconds
Default TTL: 86400 seconds
Minimum TTL: 0
Maximum TTL: 31536000 seconds (1 year)
Maximum file size: 20 GB (for PUT/POST)
Maximum distributions: 200 (soft limit)
Maximum cache behaviors per distribution: 25
Maximum origins per distribution: 25
Price Class: All, 200, 100
Events: Viewer Request, Viewer Response, Origin Request, Origin Response
Edge Cases and Exceptions
If a Lambda@Edge function fails (timeout or error), CloudFront returns the original response (for origin events) or a 502 error (for viewer events).
Lambda@Edge functions cannot be associated with a distribution that uses CloudFront Functions on the same event.
You cannot use Lambda@Edge with CloudFront's real-time logs directly; you must use Kinesis.
For custom origins, CloudFront does not support OAI; you must use custom headers or IP whitelisting.
CloudFront supports WebSockets, but Lambda@Edge cannot be used with WebSocket events.
If you update a Lambda@Edge function, you must create a new version and update the distribution; the old version continues until propagation.
How to Eliminate Wrong Answers
If the question involves modifying requests or responses at edge, check whether it's viewer or origin event. Viewer events fire on every request; origin events only on cache misses.
If the question mentions low latency, simple manipulation, and cost savings, think CloudFront Functions.
If the question mentions complex logic, external service calls, or longer execution, think Lambda@Edge.
For private content, signed URLs vs. cookies: one file vs. multiple files.
For S3 origin security, use OAI.
For custom origin security, use custom headers or AWS WAF.
Always check region requirement for Lambda@Edge (us-east-1).
Remember that Lambda@Edge cannot access VPC.
By focusing on these points, you can confidently answer CloudFront and Lambda@Edge questions on the DVA-C02 exam.
CloudFront is a global CDN that caches content at edge locations to reduce latency and origin load.
Lambda@Edge runs code at edge locations on four events: Viewer Request, Viewer Response, Origin Request, Origin Response.
Viewer events trigger on every request; origin events trigger only on cache misses.
Lambda@Edge functions must be created in us-east-1 and cannot access VPC resources.
Default TTL is 86400 seconds (24 hours); can be overridden by Cache-Control headers.
CloudFront Functions are for simple, high-performance manipulations; Lambda@Edge for complex logic.
Origin Access Identity (OAI) restricts S3 bucket access to CloudFront only.
Signed URLs provide access to a single file; signed cookies provide access to multiple files.
Invalidations are charged per path; use versioned filenames to avoid costs.
CloudFront supports custom SSL certificates only from ACM in us-east-1.
Maximum file size for PUT/POST via CloudFront is 20 GB.
Lambda@Edge timeout: 5 seconds for viewer events, 30 seconds for origin events.
Lambda@Edge memory range: 128 MB to 3008 MB.
CloudFront distributions can have up to 25 cache behaviors and 25 origins.
Price Class options: All, 200 (most regions), 100 (North America and Europe only).
These come up on the exam all the time. Here's how to tell them apart.
CloudFront Functions
Lightweight, sub-1ms execution
Only runs on Viewer Request and Viewer Response events
No network access, cannot call external services
Maximum memory is 2 MB, code size 10 KB
Cost is much lower per invocation
Lambda@Edge
Up to 5 seconds (viewer) or 30 seconds (origin) execution
Runs on all four event types: Viewer Request/Response, Origin Request/Response
Can access external services like DynamoDB, S3 via public internet
Maximum memory 3008 MB, code size 1 MB (zipped)
Higher cost per invocation but more powerful
Mistake
Lambda@Edge functions can be written in any programming language supported by Lambda.
Correct
Lambda@Edge supports Node.js, Python, and Java only. Other runtimes like .NET or Go are not supported at edge locations.
Mistake
CloudFront caches all HTTP methods including POST.
Correct
CloudFront only caches responses to GET and HEAD requests. POST, PUT, DELETE, PATCH requests are forwarded to the origin and never cached.
Mistake
You can use the same Lambda@Edge function for both viewer and origin events.
Correct
A single function can be associated with multiple events, but the code must handle each event type appropriately. The event object structure differs between viewer and origin events.
Mistake
CloudFront automatically supports custom SSL certificates from any region.
Correct
Custom SSL certificates must be in AWS Certificate Manager (ACM) in us-east-1 only. Certificates from other regions cannot be used with CloudFront.
Mistake
Lambda@Edge functions can access DynamoDB or S3 without restrictions.
Correct
Lambda@Edge functions can access DynamoDB and S3 via the public internet, but they cannot access resources in a VPC (e.g., RDS, ElastiCache). They have no VPC networking.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CloudFront Functions are lightweight, sub-millisecond execution functions that run only on Viewer Request and Viewer Response events. They have no network access and are intended for simple manipulations like URL rewrites or header modifications. Lambda@Edge is more powerful, with up to 5 seconds (viewer) or 30 seconds (origin) execution, and can access external services like DynamoDB. Lambda@Edge runs on all four event types. CloudFront Functions are cheaper and faster, while Lambda@Edge is for complex logic.
No. Lambda@Edge functions run at CloudFront edge locations, which are outside of any VPC. They cannot access resources inside a VPC, such as RDS or ElastiCache. If you need to access VPC resources, you must use a different approach, such as a regular Lambda function behind an API Gateway or ALB.
Use an Origin Access Identity (OAI). Create an OAI in CloudFront and associate it with your distribution. Then configure the S3 bucket policy to allow only that OAI to access the bucket. This ensures that users can only access the bucket through CloudFront, not directly via S3 URLs.
The default TTL is 86400 seconds (24 hours). If the origin does not provide Cache-Control or Expires headers, CloudFront uses the default TTL. You can set Minimum TTL and Maximum TTL to override the origin's headers. The actual TTL is the value from Cache-Control max-age, clamped between Minimum and Maximum TTL.
You can create an invalidation request specifying paths (e.g., /images/*). CloudFront will remove those objects from all edge locations. Invalidations are charged per path. To avoid invalidation costs, use versioned filenames (e.g., image-v2.jpg) so that new requests fetch the new object automatically.
Yes, Lambda@Edge works with any origin type, including S3, EC2, ELB, and any HTTP server. The function runs at the edge location and can modify requests to or responses from any origin.
If a Viewer Request or Viewer Response function fails, CloudFront returns a 502 error to the user. If an Origin Request or Origin Response function fails, CloudFront returns the original response from the origin (or a 502 if the origin didn't respond). You can configure CloudFront to return a custom error page in case of failures.
You've just covered CloudFront and Lambda@Edge — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?