is a CloudFront native feature (code is managed entirely within CloudFront) and visible only on the CloudFront dashboard.
supports lightweight functions written only in JavaScript language
supports two JavaScript runtimes:
Runtime 1.0 – ECMAScript 5.1 compliant with some ES 6-9 features
Runtime 2.0 – Adds async/await, Promises, ES modules, WebCrypto, Buffer module, and ES 6-12 features. Required for KeyValueStore and origin modification.
runs in 700+ Edge Locations (closer to viewers than Lambda@Edge)
has process-based isolation
supports Viewer Request, Viewer Response trigger events only
Viewer Request: after CloudFront receives the request from the Viewer
Viewer Response: before CloudFront forwards the response to the Viewer
supports sub-millisecond execution time
maximum function code size: 10 KB
maximum function memory: 2 MB
scales to millions of requests/second
pricing: $0.10 per million invocations (1/6th the cost of Lambda@Edge)
as they are built to be more scalable, performant, and cost-effective, they have the following limitations
no network access
no file system access
no access to environment variables (use KeyValueStore instead)
no dynamic code evaluation (eval() not supported)
no timers (setTimeout, setImmediate not supported)
cannot access the request body
supports Amazon CloudFront KeyValueStore for low-latency data lookups at the edge without network calls (requires Runtime 2.0)
supports origin modification (Nov 2024) – dynamically change or update origin servers on each request from the viewer request event, previously only possible via Lambda@Edge
supports access to geolocation and device data headers
can be built and tested entirely within CloudFront console
ideal use cases:
Cache-key manipulations and normalization
URL rewrites and redirects
HTTP header manipulation
Request authorization (JWT validation via hashed tokens)
Dynamic origin selection and modification
A/B testing and feature flags (using KeyValueStore)
allows conditionally changing or updating origin servers on each request from the viewer request event.
previously, origin modification was only possible using Lambda@Edge on the origin request event.
supports updating all existing origin capabilities such as setting custom headers, adjusting timeouts, setting Origin Shield, or changing the primary origin in origin groups.
uses helper methods: updateRequestOrigin(), selectRequestOriginById(), and createRequestOriginGroup().
VPC Origin modification support added in April 2025, enabling routing to private VPC origins.
requires JavaScript runtime 2.0.
CloudFront Functions – New Capabilities (Nov 2025)
Edge Location Metadata – Access the three-letter airport code of the serving edge location and expected Regional Edge Cache (REC). Enables geo-specific content routing or compliance requirements.
Raw Query String Retrieval – Access the complete, unprocessed query string as received from the viewer, preserving special characters and encoding.
Advanced Origin Overrides – Customize SSL/TLS handshake parameters including Server Name Indication (SNI), useful for multi-tenant setups. Parameters include hostHeader, sni, allowedCertificateNames, and originOverrides.
Lambda@Edge
are Lambda functions and visible on the Lambda dashboard.
supports Node.js and Python languages (currently supports Node.js 18, 20, 22, 24 and Python 3.9-3.13)
runs in Regional Edge Caches (13 locations globally)
JSON Structured Logs – Function logs can now be output in structured JSON format, making it easier to search, filter, and analyze log entries without custom logging libraries.
Custom CloudWatch Log Group Selection – Choose which CloudWatch log group Lambda@Edge sends logs to, simplifying log aggregation and management at scale.
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
You’ve been given the requirement to customize the content which is distributed to users via a CloudFront Distribution. The content origin is an S3 bucket and the customization attribute exists in the request body. How could you achieve this?
Add an event to the S3 bucket. Make the event invoke a Lambda function to customize the content before rendering
Use CloudFront Functions
Use Lambda@Edge
Use a separate application on an EC2 Instance for this purpose.
A company uses CloudFront to serve a multi-region application. They need to route users to the nearest origin based on the viewer’s geographic location with sub-millisecond latency impact. Which approach should they use?
Use Lambda@Edge with origin request trigger
Use CloudFront Functions with origin modification helper methods
Use Route 53 latency-based routing
Use CloudFront geographic restrictions
A SaaS company wants to dynamically route tenant requests to different backend servers based on a tenant ID in the request header. The routing table changes frequently. Which solution provides the lowest latency?
Use Lambda@Edge to query DynamoDB for the routing table
Use CloudFront Functions with hard-coded routing logic
Use CloudFront Functions with KeyValueStore to look up the tenant routing
Use an Application Load Balancer with path-based routing
An application requires JWT token validation at the edge and, if valid, needs to call an external authorization service to check permissions before serving content. Which combination should be used?
Use CloudFront Functions for both JWT validation and the external call
Use Lambda@Edge for both JWT validation and the external call
Use CloudFront Functions for JWT validation on viewer request, and Lambda@Edge on origin request for the external authorization call
Use API Gateway with a Lambda authorizer
Which of the following is NOT a limitation of CloudFront Functions compared to Lambda@Edge? (Select TWO)
Cannot access the request body
Cannot modify the origin
Cannot make network calls
Cannot access geolocation data
Cannot use KeyValueStore
Show Answer
Answer: B and E are NOT limitations (they are incorrect statements). CloudFront Functions CAN modify origins (since Nov 2024) and CAN use KeyValueStore –
Both services integrate with AWS Shield for DDoS protection.
Both services operate from AWS edge locations (Points of Presence), but with different scale:
CloudFront uses 750+ PoPs in 100+ cities across 50+ countries, plus 1,140+ Embedded PoPs in 300+ cities.
Global Accelerator uses 130 PoPs in 95 cities across 53 countries.
Performance
CloudFront improves performance for both cacheable content (such as images and videos) and dynamic content (such as API acceleration and dynamic site delivery).
Global Accelerator improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in one or more AWS Regions.
Use Cases
CloudFront is a good fit for HTTP use cases, including web content delivery, API acceleration, video streaming, and serverless edge compute.
Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or VoIP, as well as for HTTP use cases that require static IP addresses or deterministic, fast regional failover.
Caching
CloudFront supports Edge caching with Regional Edge Caches (RECs) and Origin Shield for optimized cache-hit ratios.
Global Accelerator does not support Edge Caching. It routes traffic over the AWS backbone to the optimal regional endpoint.
Static IP Addresses
CloudFront now supports Anycast Static IPs (launched Nov 2024), providing a dedicated set of static IP addresses for allowlisting, zero-rating, and apex domain support.
Global Accelerator provides two static anycast IPv4 addresses (and optionally two IPv6 addresses with dual-stack) per accelerator, serviced by independent network zones for fault tolerance.
Protocol Support
CloudFront supports HTTP and HTTPS (with TLSv1.3), WebSocket, and gRPC.
Global Accelerator supports TCP and UDP at the transport layer, enabling broader protocol coverage including non-HTTP workloads.
Failover
CloudFront supports origin failover for GET and HEAD requests using origin groups with primary and secondary origins.
Global Accelerator provides instant, deterministic failover across AWS Regions based on continuous health monitoring (TCP, HTTP, HTTPS health checks).
Edge Compute
CloudFront offers edge compute via CloudFront Functions (lightweight, sub-millisecond execution at all edge locations) and Lambda@Edge (general-purpose serverless compute).
Global Accelerator does not provide edge compute capabilities.
IP Address Management
CloudFront supports Bring Your Own IP (BYOIP) through VPC IPAM integration for both IPv4 (/24) and IPv6 (/48) address ranges (launched Nov 2025).
Global Accelerator supports BYOIP allowing up to two /24 IPv4 address ranges per accelerator.
Security
CloudFront integrates with AWS WAF, AWS Shield (Standard and Advanced), and supports field-level encryption, signed URLs/cookies, and Origin Access Control (OAC).
Global Accelerator integrates with AWS Shield (Standard and Advanced) for DDoS protection but does not support WAF integration.
Key Feature Differences (Summary Table)
Feature
CloudFront
Global Accelerator
Type
Content Delivery Network (CDN)
Network layer traffic accelerator
Caching
Yes (Edge + Regional Edge Caches + Origin Shield)
No
Protocols
HTTP, HTTPS, WebSocket, gRPC
TCP, UDP
Static IPs
Yes (Anycast Static IPs – Nov 2024)
Yes (2 IPv4 + 2 IPv6 with dual-stack)
Edge Compute
CloudFront Functions + Lambda@Edge
No
WAF Integration
Yes
No
VPC Origins
Yes (private ALB/NLB/EC2)
No
Custom Routing
No
Yes (deterministic EC2 routing)
Health Checks
Origin failover (GET/HEAD only)
TCP, HTTP, HTTPS (instant regional failover)
Dual-Stack (IPv6)
Yes
Yes (dual-stack accelerators with NLB endpoints)
BYOIP
Yes (via VPC IPAM, IPv4 + IPv6)
Yes (up to two /24 IPv4 ranges)
Kubernetes Integration
No native integration
Yes (AWS Load Balancer Controller CRDs)
Recent Feature Updates (2024-2026)
CloudFront Updates
Anycast Static IPs (Nov 2024) – Dedicated static IP addresses for allowlisting, zero-rating traffic with ISPs, and apex domain support. IPv6 support added Nov 2025.
VPC Origins (Nov 2024) – Connect CloudFront directly to private ALBs, NLBs, or EC2 instances in private subnets without public internet exposure. Cross-account support added Nov 2025.
Embedded Points of Presence (Feb 2024) – PoPs deployed directly within ISP networks for large-scale video streaming and game downloads, with 1,140+ Embedded PoPs in 300+ cities.
Flat-Rate Pricing Plans (Nov 2025) – Bundled CDN, WAF, DDoS protection, bot management, Route 53, CloudWatch Logs, edge compute, and S3 storage into predictable monthly pricing with no overage charges.
Tag-Based Cache Invalidation (May 2026) – Native support to tag cached objects and invalidate by tag directly through the CloudFront API.
BYOIP via VPC IPAM (Nov 2025) – Bring your own IPv4 and IPv6 addresses to CloudFront using IPAM’s BYOIP for global services.
CloudFront KeyValueStore (Nov 2023) – Low-latency global data store for CloudFront Functions enabling dynamic edge decisions without code redeployment.
Simplified Console Experience (Jun 2025) – New user-friendly interface with automated certificate provisioning and DNS configuration.
Global Accelerator Updates
Kubernetes Integration (Jan 2026) – AWS Load Balancer Controller now supports Global Accelerator through declarative Kubernetes CRDs for managing accelerators, listeners, and endpoint groups.
Expanded Region Support – Now supports 33 AWS Regions including Mexico (Central), Asia Pacific (Malaysia, Thailand, Taipei) as of Oct 2025.
Dual-Stack NLB Endpoints (Nov 2023) – IPv6 traffic routing directly to dual-stack NLB endpoints for end-to-end IPv6 connectivity.
Client IP Preservation for NLB (Aug 2023) – Maintains source IP address for packets arriving at NLB endpoints configured behind Global Accelerator.
Dual-Stack NLB Support for Standard Accelerators (Mar 2024) – Adding dual-stack NLBs to standard accelerators.
When to Use Which
Choose CloudFront when:
Delivering cacheable web content (images, videos, static files)
Accelerating APIs and dynamic HTTP/HTTPS content
Needing edge compute (CloudFront Functions or Lambda@Edge)
Requiring WAF integration for application-layer security
Serving content from private origins via VPC Origins
Requiring static IP addresses as fixed entry points (since its inception)
Using custom routing to deterministically route users to specific EC2 instances (e.g., multiplayer gaming matchmaking)
Needing Kubernetes-native management of global traffic acceleration
Running multi-region S3 workloads via S3 Multi-Region Access Points
Use both together when:
Needing CDN caching for web content AND fast failover for backend APIs
Building multi-tier applications with both HTTP and non-HTTP components
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
A company wants to improve the availability and performance of its stateless UDP-based workload. The workload is deployed on Amazon EC2 instances in multiple AWS Regions. What should a solutions architect recommend to accomplish this?
Place the EC2 instances behind Network Load Balancers (NLBs) in each Region. Create an accelerator using AWS Global Accelerator. Use the NLBs as endpoints for the accelerator.
Place the EC2 instances behind Application Load Balancers (ALBs) in each Region. Create an accelerator using AWS Global Accelerator. Use the ALBs as endpoints for the accelerator.
Place the EC2 instances behind Network Load Balancers (NLBs) in each Region. Create a CloudFront distribution with an origin that uses Route 53 latency-based routing to route requests to the NLBs.
Place the EC2 instances behind Application Load Balancers (ALBs) in each Region. Create a CloudFront distribution with an origin that uses Route 53 latency-based routing to route requests to the ALBs.
A media company delivers live streaming video to millions of global viewers. They need to reduce buffering during peak events while keeping origin infrastructure costs low. Which AWS service is the best fit?
AWS Global Accelerator with NLB endpoints in each Region
Amazon CloudFront with Origin Shield enabled and Embedded Points of Presence for large-scale delivery
Amazon CloudFront with Global Accelerator as the origin
AWS Global Accelerator with custom routing to direct viewers to specific EC2 instances
A gaming company wants to route players to specific EC2 game server instances based on matchmaking logic. The application uses UDP and players are distributed globally. Which solution provides the lowest latency and deterministic routing?
Amazon CloudFront with Lambda@Edge for routing logic
AWS Global Accelerator with standard routing and NLB endpoints
AWS Global Accelerator with custom routing accelerator mapping ports to specific EC2 instances
Amazon Route 53 latency-based routing with health checks
A company requires its web application origin servers to remain in private subnets with no public internet access, while still serving global users with low latency. Which solution meets these requirements?
AWS Global Accelerator with private NLB endpoints
Amazon CloudFront with VPC Origins pointing to private ALB/NLB/EC2 instances
Amazon CloudFront with an origin in a public subnet protected by Security Groups
AWS Global Accelerator with EC2 instances using Elastic IP addresses
A company needs static IP addresses for their content delivery to satisfy partner allowlisting requirements. Previously this was only available with Global Accelerator. Which CloudFront feature now addresses this requirement?
CloudFront Origin Access Control (OAC)
CloudFront Anycast Static IPs
CloudFront Dedicated IP Custom SSL
CloudFront BYOIP via VPC IPAM
A company running a multi-region application on Kubernetes (EKS) wants to add global traffic acceleration with automatic failover. They prefer managing infrastructure declaratively through Kubernetes resources. Which approach is most operationally efficient?
Create Global Accelerator manually via AWS Console and add EKS NLB endpoints
Use the AWS Load Balancer Controller with Global Accelerator CRDs to declaratively manage accelerators through Kubernetes
Use Amazon CloudFront with Route 53 failover routing
Use Amazon Route 53 with latency-based routing and health checks
AWS CloudFront helps write your own code to customize how the CloudFront distributions process HTTP requests and responses.
The code runs close to the viewers (users) to minimize latency, and without having to manage servers or other infrastructure.
Custom code can manipulate the requests and responses that flow through CloudFront, perform basic authentication and authorization, generate HTTP responses at the edge, and more.
CloudFront Edge Functions currently supports three types
CloudFront Functions now supports origin modification, allowing you to conditionally change or update origin servers on each request from the viewer request event.
Previously, origin modification was only possible using Lambda@Edge on the origin request event.
Supports updating all existing origin capabilities such as setting custom headers, adjusting timeouts, setting Origin Shield, or changing the primary origin in origin groups.
Uses helper methods from the cloudfront module: updateRequestOrigin(), selectRequestOriginById(), and createRequestOriginGroup().
Requires JavaScript runtime 2.0.
In April 2025, VPC Origin modification was also added, enabling routing to private VPC origins from CloudFront Functions.
Available at no additional charge.
CloudFront Functions – New Capabilities (Nov 2025)
Edge Location Metadata – Access the three-letter airport code of the serving edge location and expected Regional Edge Cache (REC). Enables geo-specific content routing or compliance requirements (e.g., directing European users to GDPR-compliant origins).
Raw Query String Retrieval – Access the complete, unprocessed query string as received from the viewer, preserving special characters and encoding that may be altered during standard parsing.
Advanced Origin Overrides – Customize SSL/TLS handshake parameters including Server Name Indication (SNI). Useful for multi-tenant setups where CloudFront connects through CNAME chains resolving to servers with different certificate domains. Parameters include hostHeader, sni, allowedCertificateNames, and originOverrides.
Available at no additional charge in all CloudFront edge locations.
Amazon CloudFront KeyValueStore
is a low-latency, globally distributed datastore for CloudFront Functions (launched Nov 2023).
allows storing key-value pairs that can be read by CloudFront Functions at the edge without making a network call.
enables dynamic updates to configuration data without deploying code changes.
requires CloudFront Functions using JavaScript runtime 2.0.
eliminates the need for environment variables (which are not supported in CloudFront Functions).
use cases:
URL redirects and rewrites based on dynamic mappings
A/B testing configuration
Feature flags
Access control lists
SaaS tenant routing at the edge
Geo-based routing configuration
supports operations via CloudFront API using Signature Version 4A (SigV4A):
GetKey – retrieve a single key
PutKey – add or update a key
DeleteKey – remove a key
ListKeys – list all keys
data is eventually consistent across all edge locations.
Lambda@Edge
are Lambda functions and visible on the Lambda dashboard.
supports Node.js and Python languages (currently supports Node.js 18, 20, 22, 24 and Python 3.9-3.13)
runs in Regional Edge Caches (13 locations globally)
JSON Structured Logs – Function logs can now be output in structured JSON format, making it easier to search, filter, and analyze large volumes of log entries without custom logging libraries.
Log Level Granularity – Switch log levels (ERROR, DEBUG, INFO) instantly without code changes, useful for real-time issue investigation.
Custom CloudWatch Log Group Selection – Choose which CloudWatch log group Lambda@Edge sends logs to, simplifying log aggregation and management at scale.
Configurable via Lambda APIs, Lambda console, AWS CLI, AWS SAM, and AWS CloudFormation.
CloudFront Connection Functions
is a newer type of edge function specifically designed for mutual TLS (mTLS) validation at the edge (launched 2025).
executes during the TLS handshake, before HTTP request processing begins.
Each event type (viewer request, origin request, origin response, and viewer response) can have only one edge function association.
CloudFront Functions and Lambda@Edge in viewer events (viewer request and viewer response) cannot be combined on the same cache behavior.
CloudFront does not invoke edge functions for viewer response events when the origin returns an HTTP status code 400 or higher.
Edge functions for viewer response events cannot modify the HTTP status code of the response, regardless of whether the response came from the origin or the CloudFront cache.
Lambda@Edge functions must be created in US East (N. Virginia) region and must use a numbered version (not $LATEST or aliases).
CloudFront Functions cannot access the request body, make network calls, or use timers.
Origin modification in CloudFront Functions runs on every request (viewer request event), whereas Lambda@Edge origin modification only runs on cache misses (origin request event).
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
You’ve been given the requirement to customize the content which is distributed to users via a CloudFront Distribution. The content origin is an S3 bucket. How could you achieve this?
Add an event to the S3 bucket. Make the event invoke a Lambda function to customize the content before rendering
Add a Step Function. Add a step with a Lambda function just before the content gets delivered to the users.
Use Lambda@Edge
Use a separate application on an EC2 Instance for this purpose.
A company’s packaged application dynamically creates and returns single-use text files in response to user requests. The company is using Amazon CloudFront for distribution but wants to further reduce data transfer costs. The company cannot modify the application’s source code. What should a solutions architect do to reduce costs?
Use Lambda@Edge to compress the files as they are sent to users.
Enable Amazon S3 Transfer Acceleration to reduce the response times.
Enable caching on the CloudFront distribution to store generated files at the edge.
Use Amazon S3 multipart uploads to move the files to Amazon S3 before returning them to users.
A company needs to dynamically route CloudFront requests to different origin servers based on the viewer’s geographic location with sub-millisecond latency. The routing configuration changes frequently. Which solution meets these requirements with the LEAST operational overhead?
Use Lambda@Edge with a DynamoDB table for routing rules
Use CloudFront Functions with KeyValueStore for routing configuration
Use multiple CloudFront distributions with Route 53 geolocation routing
Use CloudFront cache behaviors with path-based routing
A development team needs to implement URL redirects for a website served through CloudFront. The redirect mappings change weekly and currently contain 500 entries. They need sub-millisecond performance. Which approach is MOST efficient?
Use Lambda@Edge to query a database for redirect mappings
Configure CloudFront cache behaviors for each redirect
Use CloudFront Functions with KeyValueStore to store redirect mappings
Use an Application Load Balancer with listener rules for redirects
A company wants to dynamically route requests to different backend origins based on customer subscription tier. Requests include the tier as a header. The company wants this logic executed on every request with the lowest possible latency. Which edge function approach should they use?
Lambda@Edge on origin request event
Lambda@Edge on viewer request event
CloudFront Functions with origin modification on viewer request event
CloudFront Functions on viewer response event
A solutions architect needs to implement custom mutual TLS certificate validation that checks client certificates against a revocation list at CloudFront edge locations. The revocation list is updated hourly. Which solution is MOST appropriate?
Use Lambda@Edge to validate certificates on viewer request
Use CloudFront Connection Functions with KeyValueStore for the revocation list
Use CloudFront Functions to check certificate headers
CloudFront Security has multiple features, including
Support for Encryption at Rest and Transit.
Prevent users in specific geographic locations from accessing content
Configure HTTPS connections.
Use signed URLs or cookies to restrict access for selected users.
Restrict access to content in S3 buckets using Origin Access Control (OAC), to prevent users from using the direct URL of the file.
Set up field-level encryption for specific content fields
Use AWS WAF web ACLs to create a web access control list (web ACL) to restrict access to your content.
Use geo-restriction, also known as geoblocking, to prevent users in specific geographic locations from accessing content served through a CloudFront distribution.
Integration with AWS Shield to protect from DDoS attacks.
Support for Mutual TLS (mTLS) authentication for both viewer and origin connections.
VPC Origins to deliver content from applications in private subnets without exposing them to the public internet.
Data Protection
CloudFront supports both Encryption at Rest and in Transit.
CloudFront provides Encryption in Transit and can be configured
to require viewers to use HTTPS to request the files so that connections are encrypted when CloudFront communicates with viewers.
to use HTTPS to get files from the origin, so that connections are encrypted when CloudFront communicates with the origin.
HTTPS can be enforced using the Viewer Protocol Policy and Origin Protocol Policy.
CloudFront supports TLS 1.3 for origin connections (launched November 2025), providing stronger encryption algorithms, reduced handshake latency (up to 30% improvement), and better security posture for data transmission between edge locations and origin servers. TLS 1.3 is automatically enabled for all origin types including custom origins, S3, and ALBs.
CloudFront supports Post-Quantum TLS (launched September 2025) with the TLS1.3_2025 security policy, providing quantum-resistant key exchange to protect against “harvest now, decrypt later” threats.
CloudFront provides Encryption at Rest
using SSDs which are encrypted for edge location points of presence (POPs), and encrypted EBS volumes for Regional Edge Caches (RECs).
Function code and configuration are always stored in an encrypted format on the encrypted SSDs on the edge location POPs, and in other storage locations used by CloudFront.
Mutual TLS (mTLS) Authentication
Mutual TLS (mTLS) extends standard TLS by requiring bidirectional certificate-based authentication, where both client and server must prove their identity before establishing a secure connection.
CloudFront supports mTLS in two configurations:
Viewer mTLS (launched November 2025) – Authenticates end users/clients connecting to CloudFront using client certificates. Requires HTTPS connections.
Origin mTLS (launched January 2026) – CloudFront authenticates itself to origin servers using client certificates, ensuring only authorized CloudFront distributions can connect to application servers.
Together, viewer and origin mTLS enable true end-to-end zero-trust authentication from viewers through CloudFront to origin servers.
Origin mTLS supports per-origin configuration, allowing different client certificates for different origins within the same distribution.
mTLS Passthrough mode (launched May 2026) allows CloudFront to forward client certificates to the origin without verifying them at CloudFront, enabling custom validation at the origin.
mTLS is available at no additional cost and can be configured via Console, CLI, SDK, CDK, and CloudFormation.
Restrict Viewer Access
Serving Private Content
To securely serve private content using CloudFront
Require the users to access the private content by using special CloudFront signed URLs or signed cookies with the following restrictions
end date and time, after which the URL is no longer valid
start date-time, when the URL becomes valid
IP address or range of addresses to access the URLs
Require that users access the S3 content only using CloudFront URLs, not S3 URLs. Requiring CloudFront URLs isn’t required, but recommended to prevent users from bypassing the restrictions specified in signed URLs or signed cookies.
Signed URLs or Signed Cookies can be used with CloudFront using an HTTP server as an origin. It requires the content to be publicly accessible and care should be taken to not share the direct URL of the content
Restriction for Origin can be applied by
For S3, using Origin Access Control (OAC) to grant only CloudFront access to the content and removing any other access permissions. (OAI is legacy; see OAC section below)
For a Load balancer OR HTTP server, custom headers can be added by CloudFront which can be used at Origin to verify the request has come from CloudFront.
Custom origins can also be configured to allow traffic from CloudFront IPs only. CloudFront managed prefix list can be used to allow inbound traffic to the origin only from CloudFront’s origin-facing servers, preventing any non-CloudFront traffic from reaching your origin
For origins in private subnets, VPC Origins can be used to restrict access so that only CloudFront can reach the ALB, NLB, or EC2 instances directly.
Trusted Key Groups (Recommended)
AWS recommends using trusted key groups instead of trusted signers (CloudFront key pairs) for creating signed URLs and signed cookies.
Trusted key groups use public keys that you manage in CloudFront, associated with IAM-managed key pairs.
Benefits over legacy trusted signers:
No need for the AWS account root user to manage CloudFront key pairs.
Can use IAM policies and API to manage keys.
Can have more key groups per distribution (not limited to 5 trusted signers).
Supports key rotation without disrupting viewers.
A key group contains one or more public keys that CloudFront uses to verify signed URLs or signed cookies.
Trusted Signer (Legacy)
To create signed URLs or signed cookies, at least one AWS account (trusted signer) is needed that has an active CloudFront key pair
Once the AWS account is added as a trusted signer to the distribution, CloudFront starts to require that users use signed URLs or signed cookies to access the objects.
Private key from the trusted signer’s key pair to sign a portion of the URL or the cookie. When someone requests a restricted object, CloudFront compares the signed portion of the URL or cookie with the unsigned portion to verify that the URL or cookie hasn’t been tampered with. CloudFront also validates the URL or cookie is valid for e.g, that the expiration date and time hasn’t passed.
Each Trusted signer AWS account used to create CloudFront signed URLs or signed cookies must have its own active CloudFront key pair, which should be frequently rotated
A maximum of 5 trusted signers can be assigned for each cache behavior
Note: AWS recommends migrating to trusted key groups for better security and management flexibility.
Signed URLs vs Signed Cookies
CloudFront signed URLs and signed cookies help to secure the content and provide control to decide who can access the content.
Use signed URLs in the following cases:
to restrict access to individual files, for e.g., an installation download for the application.
users using a client, for e.g. a custom HTTP client, that doesn’t support cookies
Use signed cookies in the following cases:
provide access to multiple restricted files, e.g., all of the video files in HLS format or all of the files in the subscribers’ area of a website.
don’t want to change the current URLs.
Signed URLs take precedence over signed cookies, if both signed URLs and signed cookies are used to control access to the same files and a viewer uses a signed URL to request a file, CloudFront determines whether to return the file to the viewer based only on the signed URL.
Canned Policy vs Custom Policy
Canned policy or a custom policy is a policy statement, used by the Signed URLs, that helps define the restrictions for e.g. expiration date and time
CloudFront validates the expiration time at the start of the event.
If the user is downloading a large object, and the URL expires the download would still continue.
However, if the user is using range GET requests, or while streaming video skips to another position which might trigger another event, the request would fail.
Origin Access Control (OAC)
✅ OAC is the recommended method for restricting origin access. AWS deprecated Origin Access Identity (OAI) creation in 2024, and as of March 2026, new distributions can only use OAC. Existing OAI configurations continue to work but should be migrated to OAC.
Origin Access Control (OAC) restricts access so that only designated CloudFront distributions can access your origin.
OAC uses AWS Signature Version 4 (SigV4) to sign requests to the origin, providing enhanced security over legacy OAI.
OAC supports multiple origin types:
Amazon S3 bucket origins – primary use case for restricting S3 access
AWS Lambda function URL origins (April 2024) – secure Lambda function URLs
AWS Elemental MediaStore origins – secure media storage
OAC advantages over legacy OAI:
Supports all AWS regions including opt-in regions
Supports SSE-KMS encrypted S3 objects
Supports HTTP and HTTPS requests using POST method in all regions
Supports granular policy configurations with IAM resource policies
Supports S3 Object Ownership set to bucket owner enforced (default for new buckets)
For S3 origins, OAC works with bucket policies to allow only the CloudFront service principal (cloudfront.amazonaws.com) access, scoped to the specific distribution ID.
Users accessing S3 objects directly would
bypass the controls provided by CloudFront signed URLs or signed cookies
make CloudFront access logs less useful because they’re incomplete.
Migrating from OAI to OAC
Existing OAI configurations continue to work but should be migrated to OAC.
Migration steps:
Create an OAC in the CloudFront console or via API
Update the S3 bucket policy to allow the CloudFront service principal
Update the distribution origin to use OAC instead of OAI
Remove the OAI from the bucket policy after verifying OAC works
Both OAI and OAC can coexist during migration to avoid downtime.
Legacy: Origin Access Identity (OAI)
⚠️ OAI is legacy. AWS deprecated new OAI creation in 2024 and recommends migrating to Origin Access Control (OAC). As of March 2026, OAI cannot be attached to new distributions.
Origin Access Identity (OAI) was the original method to prevent users from directly accessing objects from S3.
OAI is a special CloudFront user that can be created and associated with the distribution.
S3 bucket/object permissions are configured to only provide access to the OAI.
OAI limitations (addressed by OAC):
Does not support SSE-KMS
Does not support POST method in regions requiring SigV4
Limited to S3 origins only
Does not support granular IAM policies
VPC Origins
CloudFront VPC Origins (launched November 2024) allows delivering content from applications hosted in VPC private subnets, preventing direct public internet access to origins.
Supported origin types within private subnets:
Application Load Balancers (ALB)
Network Load Balancers (NLB)
EC2 Instances
Key benefits:
Origins remain completely private – accessible only through CloudFront
No need for public IPs, NAT gateways, or complex security group rules
Eliminates the need for custom header verification or IP allowlisting for origin protection
Available at no additional cost
Cross-account support (November 2025) allows CloudFront distributions in one account to access VPC origins in another account.
WebSocket support (May 2026) enables real-time applications hosted in private subnets to use WebSockets through CloudFront VPC origins.
VPC Origins is the recommended approach for securing non-S3 custom origins, replacing the legacy pattern of custom headers or IP allowlisting.
Custom Headers
Custom headers can be added by CloudFront which can be used at Origin to verify the request has come from CloudFront.
A viewer accesses the website or application and requests one or more files, such as an image file and an HTML file.
DNS routes the request to the CloudFront edge location that can best serve the request – typically the nearest edge location in terms of latency.
At the edge location, AWS WAF inspects the incoming request according to configured web ACL rules.
At the edge location, CloudFront checks its cache for the requested content.
If the content is in the cache, CloudFront returns it to the user.
If the content isn’t in the cache, CloudFront adds the custom header, X-Origin-Verify , with the value of the secret from Secrets Manager, and forwards the request to the origin.
At the origin ALB, ALB rules or AWS WAF inspects the incoming request header, X-Origin-Verify, and allows the request if the string value is valid. If the header isn’t valid, AWS WAF blocks the request.
At the configured interval, Secrets Manager automatically rotates the custom header value and updates the origin AWS WAF and CloudFront configurations.
Note: For stronger origin protection, consider using VPC Origins (for ALB/NLB/EC2) or Origin mTLS instead of shared secret headers, as these provide cryptographic authentication rather than shared secrets.
CloudFront Security Dashboard
CloudFront Security Dashboard (launched November 2023) provides a unified CDN and security experience within the CloudFront console.
Key features:
One-click WAF protection – creates an AWS WAF web ACL, configures rules to protect against common web threats (OWASP Top 10, known threat IPs, scanner detection), and attaches it to the distribution automatically.
Security metrics – displays allowed/blocked requests, challenge and CAPTCHA requests, top attack types, and traffic ratios over time.
Geo-restriction management – block countries directly from the dashboard with metrics visibility.
Built-in pricing calculators – estimate WAF and CloudWatch costs when enabling protections.
Standard pricing for AWS WAF and Amazon CloudWatch apply when security protections are enabled.
Geo-Restriction – Geoblocking
Geo restriction can help allow or prevent users in selected countries from accessing the content.
CloudFront distribution can be configured either to allow users in
an allowlist of specified countries to access the content or to
deny users in a denylist of specified countries to access the content
Geo restriction can be used to restrict access to all of the files that are
associated with distribution and to restrict access at the country level.
CloudFront responds to a request from a viewer in a restricted country with an HTTP status code 403 (Forbidden).
Use a third-party geolocation service, if access is to be restricted to a subset of the files that are associated with a distribution or to restrict access at a finer granularity than the country level.
CloudFront geographic restrictions are provided for free, but metrics for blocked country requests are only visible through AWS WAF geographic restrictions in the security dashboard.
Geo-restriction is also critical for reducing attack surface by limiting traffic to expected geographic regions.
Field Level Encryption Config
CloudFront can enforce secure end-to-end connections to origin servers by using HTTPS.
Field-level encryption adds an additional layer of security that helps protect specific data throughout system processing so that only certain applications can see it.
Field-level encryption can be used to securely upload user-submitted sensitive information. The sensitive information provided by the clients is encrypted at the edge closer to the user and remains encrypted throughout the entire application stack, ensuring that only applications that need the data – and have the credentials to decrypt it – are able to do so.
Up to 10 data fields can be encrypted in a request.
Uses asymmetric encryption (public key at edge, private key at application) for protection.
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
You are building a system to distribute confidential training videos to employees. Using CloudFront, what method could be used to serve content that is stored in S3, but not publically accessible from S3 directly?
Create an Origin Access Control (OAC) for CloudFront and grant access to the objects in your S3 bucket to that OAC. (Note: OAI is legacy; OAC is the current recommended approach)
Add the CloudFront account security group “amazon-cf/amazon-cf-sg” to the appropriate S3 bucket policy.
Create an Identity and Access Management (IAM) User for CloudFront and grant access to the objects in your S3 bucket to that IAM User.
Create a S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).
A media production company wants to deliver high-definition raw video for preproduction and dubbing to customer all around the world. They would like to use Amazon CloudFront for their scenario, and they require the ability to limit downloads per customer and video file to a configurable number. A CloudFront download distribution with TTL=0 was already setup to make sure all client HTTP requests hit an authentication backend on Amazon Elastic Compute Cloud (EC2)/Amazon RDS first, which is responsible for restricting the number of downloads. Content is stored in S3 and configured to be accessible only via CloudFront. What else needs to be done to achieve an architecture that meets the requirements? Choose 2 answers
Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in RDS, and return the content S3 URL unless the download limit is reached.
Enable CloudFront logging into an S3 bucket, leverage EMR to analyze CloudFront logs to determine the number of downloads per customer, and return the content S3 URL unless the download limit is reached. (CloudFront logs are logged periodically and EMR not being real time, hence not suitable)
Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in RDS, and invalidate the CloudFront distribution as soon as the download limit is reached. (Distribution are not invalidated but Objects)
Enable CloudFront logging into the S3 bucket, let the authentication backend determine the number of downloads per customer by parsing those logs, and return the content S3 URL unless the download limit is reached. (CloudFront logs are logged periodically and EMR not being real time, hence not suitable)
Configure a list of trusted signers, let the authentication backend count the number of download requests per customer in RDS, and return a dynamically signed URL unless the download limit is reached.
To enable end-to-end HTTPS connections from the user’s browser to the origin via CloudFront, which of the following options are valid? Choose 2 answers
Use self-signed certificate in the origin and CloudFront default certificate in CloudFront. (Origin cannot be self-signed)
Use the CloudFront default certificate in both origin and CloudFront (CloudFront cert cannot be applied to origin)
Use a 3rd-party CA certificate in the origin and CloudFront default certificate in CloudFront
Use 3rd-party CA certificate in both origin and CloudFront
Use a self-signed certificate in both the origin and CloudFront (Origin cannot be self-signed)
A company needs to ensure that only authenticated IoT devices can access their API through CloudFront. The devices have client certificates issued by the company’s internal CA. Which CloudFront feature should they use?
An organization wants to ensure that requests reaching their origin servers are exclusively from their authorized CloudFront distributions, using cryptographic identity verification rather than shared secrets. Which approach provides the strongest origin protection?
Custom headers with X-Origin-Verify and Secrets Manager rotation
CloudFront managed prefix list with security group rules
CloudFront Origin mTLS authentication with client certificates
Origin Access Control (OAC) with S3 bucket policies
A company wants to serve their web application through CloudFront, but their backend ALB must not be accessible from the public internet. The ALB is in a private subnet. Which CloudFront feature enables this?
Origin Access Control (OAC) with ALB
Custom headers with Secrets Manager rotation
CloudFront VPC Origins
CloudFront managed prefix list with security groups
A company is currently using Origin Access Identity (OAI) to restrict S3 access through CloudFront. They need to serve SSE-KMS encrypted objects. What should they do?
Add the OAI to the KMS key policy
Migrate from OAI to Origin Access Control (OAC), which supports SSE-KMS
Use CloudFront field-level encryption instead of SSE-KMS
Create a Lambda@Edge function to decrypt the objects
CloudFront can be used to distribute the content from an S3 bucket.
For an RTMP distribution, the S3 bucket is the only supported origin, and custom origins cannot be used
Using CloudFront over S3 has the following benefits
can be more cost-effective if the objects are frequently accessed as at higher usage, and the price for CloudFront data transfer is much lower than the price for S3 data transfer.
downloads are faster with CloudFront than with S3 alone because the objects are stored closer to the users
CloudFront provides two ways to send authenticated requests to an S3 origin: Origin Access Control (OAC) and Origin Access Identity (OAI).
OAC is the recommended and preferred method. OAI is legacy and deprecated — new CloudFront distributions (as of March 2026) can only use OAC.
When using S3 as the origin for distribution and the bucket is moved to a different region, CloudFront can take up to an hour to update its records to include the change of region when both of the following are true:
Origin Access Control (OAC) or Origin Access Identity (OAI) are used to restrict access to the bucket.
Bucket is moved to an S3 region that requires Signature Version 4 for authentication
CloudFront does not currently support S3 directory buckets (S3 Express One Zone) as origins directly.
Origin Access Control – OAC
Origin Access Control (OAC) is the recommended method to restrict direct S3 access and should be used for all new distributions.
OAC supports:
Enhanced security practices like short-term credentials, frequent credential rotations, and resource-based policies
All S3 buckets in all AWS Regions, including opt-in Regions launched after December 2022
S3 server-side encryption with AWS KMS (SSE-KMS)
Dynamic requests (PUT, POST, DELETE) to Amazon S3
Comprehensive HTTP methods support — OAC supports GET, PUT, POST, PATCH, DELETE, OPTIONS, and HEAD.
OAC is based on IAM service principals to authenticate with S3 origins using AWS Signature Version 4 (SigV4).
CloudFront OAC needs to be set up with permissions to access the S3 bucket origin using an S3 bucket policy that grants the CloudFront service principal (cloudfront.amazonaws.com) access, scoped to the specific distribution ARN.
For buckets with objects encrypted using server-side encryption with AWS Key Management Service (SSE-KMS), the OAC must be provided with permission to use the AWS KMS key via the KMS key policy.
When using CloudFront OAC with Amazon S3 bucket origins, Amazon S3 Object Ownership must be set to Bucket owner enforced (the default for new S3 buckets). If ACLs are required, use the Bucket owner preferred setting.
OAC does not work with S3 buckets configured as website endpoints — these must be set up as custom origins.
OAC Signing Behavior options:
Always sign requests (recommended) — CloudFront always signs requests to the S3 origin.
Never sign requests — Turns off OAC; bucket must be publicly accessible.
Do not override authorization header — CloudFront signs only when the viewer request doesn’t include an Authorization header.
OAC Extended Origin Support (2024)
CloudFront OAC is not limited to S3 origins. It now also supports:
AWS Lambda function URL origins (April 2024) — Secures Lambda function URLs by permitting access only from designated CloudFront distributions using SigV4.
To migrate, first update the S3 bucket policy to allow both the OAI and the distribution with OAC enabled to access the bucket’s content.
This ensures CloudFront never loses access during the transition.
After the distribution is fully deployed with OAC, remove the OAI statement from the bucket policy.
Origin Access Identity – OAI (Legacy, Not Recommended)
⚠️ OAI DEPRECATED
Origin Access Identity (OAI) is a legacy feature. AWS deprecated OAI creation in 2024. As of March 2026, new CloudFront distributions can only use Origin Access Control (OAC). Existing OAI-based distributions continue to function but cannot be attached to new distributions.
Action Required: Migrate to Origin Access Control (OAC) for enhanced security and feature support.
OAI doesn’t support:
Amazon S3 buckets in opt-in Regions (launched after January 2023)
Amazon S3 server-side encryption with AWS KMS (SSE-KMS)
Dynamic requests (PUT, POST, or DELETE) to Amazon S3
S3 origin objects must be granted public read permissions and hence the objects are accessible from both S3 as well as CloudFront.
Even though CloudFront does not expose the underlying S3 URL, it can be known to the user if shared directly or used by applications.
For using CloudFront signed URLs or signed cookies to provide access to the objects, it would be necessary to prevent users from having direct access to the S3 objects.
Users accessing S3 objects directly would
bypass the controls provided by CloudFront signed URLs or signed cookies, for e.g., control over the date-time that a user can no longer access the content and the IP addresses can be used to access content
CloudFront access logs are less useful because they’re incomplete.
Origin Access Identity (OAI) can be used to prevent users from directly accessing objects from S3.
Origin access identity, which is a special CloudFront user, can be created and associated with the distribution.
S3 bucket/object permissions need to be configured to only provide access to the Origin Access Identity.
When users access the object from CloudFront, it uses the OAI to fetch the content on the user’s behalf, while the S3 object’s direct access is restricted
CloudFront with S3 Objects
CloudFront can be configured to include custom headers or modify existing headers whenever it forwards a request to the origin, to
validate the user is not accessing the origin directly, bypassing CDN
identify the CDN from which the request was forwarded, if more than one CloudFront distribution is configured to use the same origin
if users use viewers that don’t support CORS, configure CloudFront to forward the Origin header to the origin. That will cause the origin to return the Access-Control-Allow-Origin header for every request
Adding & Updating Objects
Objects just need to be added to the Origin and CloudFront would start distributing them when accessed.
For objects served by CloudFront, the Origin can be updated either by
Overwriting the original object
Create a different version and update the links exposed to the user.
For updating objects, it is recommended to use versioning e.g. have files or the entire folders with versions, so links can be changed when the objects are updated forcing a refresh.
With versioning,
there is no wait time for an object to expire before CloudFront begins to serve a new version of it.
there is no difference in consistency in the object served from the edge
no cost is involved to pay for object invalidation.
Removing/Invalidating Objects
Objects, by default, would be removed upon expiry (TTL) and the latest object would be fetched from the Origin
Objects can also be removed from the edge cache before it expires
File or Object Versioning to serve a different version of the object that has a different name.
Invalidate the object from edge caches. For the next request, CloudFront returns to the Origin to fetch the object
Object or File Versioning is recommended over Invalidating objects
if the objects need to be updated frequently.
enables to control which object a request returns even when the user has a version cached either locally or behind a corporate caching proxy.
makes it easier to analyze the results of object changes as CloudFront access logs include the names of the objects
provides a way to serve different versions to different users.
simplifies rolling forward & back between object revisions.
is less expensive, as no charges for invalidating objects.
for e.g. change header-v1.jpg to header-v2.jpg
Invalidating objects from the cache
objects in the cache can be invalidated explicitly before they expire to force a refresh
allows to invalidate selected objects
allows to invalidate multiple objects for e.g. objects in a directory or all of the objects whose names begin with the same characters, you can include the * wildcard at the end of the invalidation path.
the user might continue to see the old version until it expires from those caches.
A specified number of invalidation paths can be submitted each month for free. Any invalidation requests more than the allotted no. per month, a fee is charged for each submitted invalidation path
The First 1,000 invalidation paths requests submitted per month are free; charges apply for each invalidation path over 1,000 in a month.
Invalidation path can be for a single object for e.g. /js/ab.js or for multiple objects for e.g. /js/* and is counted as a single request even if the * wildcard request may invalidate thousands of objects.
For RTMP distribution, objects served cannot be invalidated
Invalidation by Cache Tag (2026)
CloudFront now supports tag-based cache invalidation (announced April 2026), enabling invalidation of cached objects based on semantic tags rather than URL paths.
How it works:
Configure a CacheTagConfig on the distribution specifying the HTTP header name for cache tags.
The origin returns a cache tag header (e.g., x-amz-meta-cache-tag) with comma-separated tag values in HTTP responses.
Use the CreateInvalidation API with a # prefix to invalidate all objects matching a tag (e.g., #product:electronics).
For S3 origins, cache tags can be attached as S3 object metadata. A metadata key of cache-tag is returned by S3 as an x-amz-meta-cache-tag header.
Alternatively, a Lambda@Edge origin response function can add cache tag headers.
Tag format requirements:
ASCII visible characters (33–126), no spaces or commas
Case-insensitive, maximum 256 characters per tag
Maximum 50 tags per object
Path and tag invalidations can be mixed in a single request.
Tag invalidation is opt-in — distributions without CacheTagConfig ignore cache tag headers.
Backward compatible — existing path and wildcard invalidations continue to work unchanged.
Partial Requests (Range GETs)
Partial requests using Range headers in a GET request help to download the object in smaller units, improving the efficiency of partial downloads and the recovery from partially failed transfers.
For a partial GET range request, CloudFront
checks the cache in the edge location for the requested range or the entire object and if exists, serves it immediately
if the requested range does not exist, it forwards the request to the origin and may request a larger range than the client requested to optimize performance
if the origin supports range header, it returns the requested object range and CloudFront returns the same to the viewer
if the origin does not support range header, it returns the complete object and CloudFront serves the entire object and caches it for future.
CloudFront uses the cached entire object to serve any future range GET header requests
CloudFront VPC Origins (2024)
CloudFront VPC Origins (launched November 2024) allows CloudFront to deliver content from applications hosted in VPC private subnets.
Eliminates the need for applications to be exposed on the public internet by restricting access solely through CloudFront distributions.
Supports Application Load Balancers (ALBs), Network Load Balancers (NLBs), or EC2 instances in private subnets as origins.
For S3 origins, OAC remains the managed solution. VPC Origins is designed for compute-based origins (ALB, NLB, EC2).
Origin servers remain hidden from the internet, reducing the attack surface.
VPC Origin modification via CloudFront Functions is also supported (April 2025).
CloudFront Origin Modification via CloudFront Functions (2024)
CloudFront supports origin modification within CloudFront Functions (announced November 2024), enabling conditional origin changes on each request.
Allows dynamically routing requests to different S3 buckets or other origins based on request attributes (headers, path, query strings).
Use cases include A/B testing, failover, geographic routing, and multi-tenant architectures.
Additional capabilities added (November 2025): edge location and Regional Edge Cache (REC) metadata, raw query string retrieval, and advanced origin overrides.
CloudFront Mutual TLS for Origins (2026)
CloudFront now supports mutual TLS (mTLS) authentication for origins (announced January 2026), enabling end-to-end certificate-based authentication from viewers to origins.
Ensures that only authorized CloudFront distributions can establish connections with origin servers.
Supports per-origin configuration with different client certificates for different origins within the same distribution.
Stronger than custom headers or IP allowlists for origin authentication.
Works with AWS, on-premises, and third-party backends.
CloudFront also supports mTLS Passthrough Mode for viewers (May 2026), forwarding client certificates to the origin without verification at CloudFront.
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
You are building a system to distribute confidential training videos to employees. Using CloudFront, what method could be used to serve content that is stored in S3, but not publically accessible from S3 directly?
Create an Origin Access Identity (OAI) for CloudFront and grant access to the objects in your S3 bucket to that OAI. [Note: While this answer remains technically correct for the question, OAI is now legacy. The recommended approach for new implementations is Origin Access Control (OAC).]
Add the CloudFront account security group “amazon-cf/amazon-cf-sg” to the appropriate S3 bucket policy.
Create an Identity and Access Management (IAM) User for CloudFront and grant access to the objects in your S3 bucket to that IAM User.
Create an S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).
A company wants to restrict access to its S3 bucket origin so that content is only accessible through their CloudFront distribution. They also need to support uploading files via CloudFront and use SSE-KMS encryption. Which approach should they use?
Configure Origin Access Identity (OAI) with a bucket policy granting s3:GetObject and s3:PutObject.
Configure Origin Access Control (OAC) with a bucket policy granting the CloudFront service principal s3:GetObject and s3:PutObject, and update the KMS key policy to allow CloudFront.
Make the S3 bucket public and use CloudFront signed URLs to restrict viewer access.
Use a Lambda@Edge function to sign all requests to S3 using IAM credentials.
A development team needs to invalidate all cached product images across their CloudFront distribution whenever a product category is updated, regardless of URL path structure. What is the most efficient approach?
Create a wildcard invalidation for /* to clear all cached content.
Maintain a list of all product image URLs and submit individual invalidation paths.
Configure cache tag invalidation on the distribution and tag objects with category metadata, then invalidate by cache tag.
Reduce the TTL to 0 for all product images so they are never cached.
An organization uses CloudFront to serve a web application from an ALB in a private subnet. They want to ensure the ALB is never directly accessible from the internet. Which CloudFront feature should they use?
Origin Access Control (OAC)
AWS WAF with IP restriction rules
CloudFront VPC Origins
CloudFront signed URLs with a custom policy
A company needs to verify that requests to their origin server come exclusively from their authorized CloudFront distribution, using certificate-based authentication instead of shared secrets or IP allowlists. Which feature should they implement?
Flow logs – Capture information about the IP traffic going to and from network interfaces in your VPC
Tenancy option for instances
shared, by default, allows instances to be launched on shared tenancy
dedicated allows instances to be launched on a dedicated hardware
Route Tables
defines rules, termed as routes, which determine where network traffic from the subnet would be routed
Each VPC has a Main Route table and can have multiple custom route tables created
Every route table contains a local route that enables communication within a VPC which cannot be modified or deleted
Route priority is decided by matching the most specific route in the route table that matches the traffic
Subnets
map to AZs and do not span across AZs
have a CIDR range that is a portion of the whole VPC.
CIDR ranges cannot overlap between subnets within the VPC.
AWS reserves 5 IP addresses in each subnet – first 4 and last one
Each subnet is associated with a route table which define its behavior
Public subnets – inbound/outbound Internet connectivity via IGW
Private subnets – outbound Internet connectivity via an NAT or VGW
Protected subnets – no outbound connectivity and used for regulated workloads
Elastic Network Interface (ENI)
a default ENI, eth0, is attached to an instance which cannot be detached with one or more secondary detachable ENIs (eth1-ethn)
has primary private, one or more secondary private, public, Elastic IP address, security groups, MAC address and source/destination check flag attributes associated
AN ENI in one subnet can be attached to an instance in the same or another subnet, in the same AZ and the same VPC
Security group membership of an ENI can be changed
with pre-allocated Mac Address can be used for applications with special licensing requirements
allows internet access to instances in the private subnets.
performs the function of both address translation and port address translation (PAT)
needs source/destination check flag to be disabled as it is not the actual destination of the traffic for NAT Instance.
NAT gateway is an AWS managed NAT service that provides better availability, higher bandwidth, and requires less administrative effort
are not supported for IPv6 traffic
NAT Gateway supports private NAT with fixed private IPs.
Regional NAT Gateway (announced Nov 2025) automatically expands across Availability Zones based on workload footprint, providing simplified setup, enhanced security, and automatic high availability without manual multi-AZ configuration.
Egress-Only Internet Gateways
outbound communication over IPv6 from instances in the VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with your instances
supports IPv6 traffic only
Shared VPCs
allows multiple AWS accounts to create their application resources, such as EC2 instances, RDS databases, Redshift clusters, and AWS Lambda functions, into shared, centrally-managed VPCs
VPC Encryption Controls (announced Nov 2025)
allows enforcing encryption in transit for network traffic within the VPC
provides centralized encryption policy enforcement and monitoring capabilities
supports monitor and enforce modes to audit and enforce encryption compliance
enables private connectivity from VPC to supported AWS services and VPC endpoint services powered by PrivateLink
does not require a public IP address, access over the Internet, NAT device, a VPN connection, or Direct Connect
traffic between VPC & AWS service does not leave the Amazon network
are virtual devices.
are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and services without imposing availability risks or bandwidth constraints on the network traffic.
Gateway Endpoints
is a gateway that is a target for a specified route in the route table, used for traffic destined to a supported AWS service.
only S3 and DynamoDB are currently supported
Interface Endpoints OR Private Links
is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service
supports services include AWS services, services hosted by other AWS customers and partners in their own VPCs (referred to as endpoint services), and supported AWS Marketplace partner services.
Private Links
provide fine-grained access control
provides a point-to-point integration.
supports overlapping CIDR blocks.
supports transitive routing
Access to VPC Resources over PrivateLink (announced Dec 2024) – allows sharing any VPC resource using AWS RAM and accessing them privately using VPC endpoints, without requiring the resource to sit behind a NLB.
provides low latency and high data transfer speeds for the distribution of static, dynamic web, or streaming content to web users.
delivers the content through a worldwide network of data centers called Edge Locations or Point of Presence (PoPs)
keeps persistent connections with the origin servers so that the files can be fetched from the origin servers as quickly as possible.
dramatically reduces the number of network hops that users’ requests must pass through
supports multiple origin server options, like AWS hosted service for e.g. S3, EC2, ELB, or an on-premise server, which stores the original, definitive version of the objects
single distribution can have multiple origins and Path pattern in a cache behavior determines which requests are routed to the origin
Web distribution supports static, dynamic web content, on-demand using progressive download & HLS, and live streaming video content
RTMP distributions were deprecated and removed on December 31, 2020. Use Web distributions with HTTP-based streaming protocols (HLS, DASH) instead.
supports HTTPS using either
dedicated IP address, which is expensive as a dedicated IP address is assigned to each CloudFront edge location
Server Name Indication (SNI), which is free but supported by modern browsers only with the domain name available in the request header
For E2E HTTPS connection,
Viewers -> CloudFront needs either a certificate issued by CA or ACM
CloudFront -> Origin needs a certificate issued by ACM for ELB and by CA for other origins
Security
Origin Access Control (OAC) is the recommended method to restrict content from S3 origin to be accessible from CloudFront only. OAC supports SSE-KMS, all HTTP methods, and all AWS Regions.
Origin Access Identity (OAI) is the legacy method. OAI creation was deprecated in 2024 and new distributions (as of March 2026) can only use OAC. Existing OAI configurations continue to work but migration to OAC is recommended.
supports Geo restriction (Geo-Blocking) to whitelist or blacklist countries that can access the content
Signed URLs
to restrict access to individual files, for e.g., an installation download for your application.
users using a client, for e.g. a custom HTTP client, that doesn’t support cookies
Signed Cookies
provide access to multiple restricted files, for e.g., video part files in HLS format or all of the files in the subscribers’ area of a website.
don’t want to change the current URLs
integrates with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing rules configured based on IP addresses, HTTP headers, and custom URI strings
supports GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE to get object & object headers, add, update, and delete objects
only caches responses to GET and HEAD requests and, optionally, OPTIONS requests
does not cache responses to PUT, POST, PATCH, DELETE request methods and these requests are proxied back to the origin
object removal from the cache
would be removed upon expiry (TTL) from the cache, by default 24 hrs
can be invalidated explicitly, but has a cost associated, however, might continue to see the old version until it expires from those caches
objects can be invalidated only for Web distribution
use versioning or change object name, to serve a different version
Tag-based cache invalidation (announced May 2026) – allows tagging cached objects via origin response headers or S3 metadata and invalidating them by tag directly through the CloudFront API.
supports adding or modifying custom headers before the request is sent to origin which can be used to
validate if a user is accessing the content from CDN
identifying CDN from which the request was forwarded, in case of multiple CloudFront distributions
for viewers not supporting CORS to return the Access-Control-Allow-Origin header for every request
supports Partial GET requests using range header to download objects in smaller units improving the efficiency of partial downloads and recovery from partially failed transfers
supports compression to compress and serve compressed files when viewer requests include Accept-Encoding: gzip in the request header
supports different price classes to include all regions, or only the least expensive regions and other regions without the most expensive regions
supports access logs which contain detailed information about every user request for both web distribution
Edge Compute
CloudFront Functions – lightweight JavaScript functions for simple request/response transformations (URL rewrites, header manipulation, redirects) executed at viewer request/response events with sub-millisecond latency
Lambda@Edge – more powerful compute for complex processing at origin request/response and viewer request/response events
CloudFront KeyValueStore (launched 2023) – a globally distributed, low-latency data store that CloudFront Functions can read at runtime for dynamic routing, A/B testing, feature flags, and geo-routing without redeploying function code
CloudFront Flat-Rate Pricing Plans – combine CDN, AWS WAF, DDoS protection, bot management, Route 53 DNS, CloudWatch Logs ingestion, serverless edge compute, and S3 storage credits into a single monthly price
is a network service that uses a private dedicated network connection to connect to AWS services.
helps reduce costs (long term), increases bandwidth, and provides a more consistent network experience than internet-based connections.
supports Dedicated and Hosted connections
Dedicated connection is made through a 1 Gbps, 10 Gbps, or 100 Gbps Ethernet port dedicated to a single customer.
Hosted connections are sourced from an AWS Direct Connect Partner that has a network link between themselves and AWS.
provides Virtual Interfaces
Private VIF to access instances within a VPC via VGW
Public VIF to access non VPC services
Transit VIF to access one or more Amazon VPC Transit Gateways associated with Direct Connect gateways, enabling connectivity to multiple VPCs through a single VIF
requires time to setup probably months, and should not be considered as an option if the turnaround time is less
does not provide redundancy, use either second direct connection or IPSec VPN connection
Virtual Private Gateway is on the AWS side and Customer Gateway is on the Customer side
route propagation is enabled on VGW and not on CGW
A link aggregation group (LAG) is a logical interface that uses the link aggregation control protocol (LACP) to aggregate multiple dedicated connections at a single AWS Direct Connect endpoint and treat them as a single, managed connection
VIF Rate Limiters (announced June 2026) on dedicated connections help prevent network congestion caused by unexpected traffic spikes on a VIF that could consume all available bandwidth impacting other VIFs on the same connection.
Direct Connect vs VPN IPSec
Expensive to Setup and Takes time vs Cheap & Immediate
Dedicated private connections vs Internet
Reduced data transfer rate vs Internet data transfer cost
Consistent performance vs Internet inherent variability
It’s similar to a CNAME resource record set, but supports both for root domain – zone apex e.g. example.com, and for subdomains for e.g. www.example.com.
supports ELB load balancers, CloudFront distributions, Elastic Beanstalk environments, API Gateways, VPC interface endpoints, and S3 buckets that are configured as websites.
CNAME resource record sets can be created only for subdomains and cannot be mapped to the zone apex record
supports Private DNS to provide an authoritative DNS within the VPCs without exposing the DNS records (including the name of the resource and its IP address(es) to the Internet.
Split-view (Split-horizon) DNS enables mapping the same domain publicly and privately. Requests are routed as per the origin.
Weighted routing – assign weights to resource records sets to specify the proportion for e.g. 80%:20%
Latency based routing – helps improve global applications as requests are sent to the server from the location with minimal latency, is based on the latency and cannot guarantee users from the same geography will be served from the same location for any compliance reasons
Geolocation routing – Specify geographic locations by continent, country, the state limited to the US, is based on IP accuracy
Geoproximity routing policy – Use to route traffic based on the location of the resources and, optionally, shift traffic from resources in one location to resources in another.
Multivalue answer routing policy – Use to respond to DNS queries with up to eight healthy records selected at random.
Failover routing – failover to a backup site if the primary site fails and becomes unreachable
IP-based routing – route traffic based on the IP address of the client making the DNS query
Weighted, Latency and Geolocation can be used for Active-Active while Failover routing can be used for Active-Passive multi-region architecture
Traffic Flow is an easy-to-use and cost-effective global traffic management service. Traffic Flow supports versioning and helps create policies that route traffic based on the constraints they care most about, including latency, endpoint health, load, geoproximity, and geography.
Route 53 Resolver is a regional DNS service that helps with hybrid DNS
Inbound Endpoints are used to resolve DNS queries from an on-premises network to AWS
Outbound Endpoints are used to resolve DNS queries from AWS to an on-premises network
Resolver endpoints now support DNS delegation for private hosted zones (June 2025)
Route 53 Profiles – enables sharing DNS configurations (private hosted zone associations, Resolver rules, and Resolver DNS Firewall rule group associations) across VPCs and accounts using AWS RAM
Accelerated Recovery (announced Nov 2025) – provides a 60-minute recovery time objective (RTO) for regaining the ability to make DNS changes to public hosted zones during regional disruptions in US East (N. Virginia)
PrivateLink Support (announced Nov 2025) – allows making changes to DNS infrastructure (hosted zones, records, health checks) without using the public internet
is a networking service that helps you improve the availability and performance of the applications to global users.
utilizes the Amazon global backbone network, improving the performance of the applications by lowering first-byte latency, and jitter, and increasing throughput as compared to the public internet.
provides two static IP addresses serviced by independent network zones that provide a fixed entry point to the applications and eliminate the complexity of managing specific IP addresses for different AWS Regions and AZs.
always routes user traffic to the optimal endpoint based on performance, reacting instantly to changes in application health, the user’s location, and configured policies
improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in one or more AWS Regions.
is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic, fast regional failover.
integrates with AWS Shield for DDoS protection
uses a global network of 130+ Points of Presence in 95+ cities across 53+ countries
supports dual-stack Network Load Balancers as endpoints
supports endpoints in 33 AWS Regions (as of 2025)
integrates with AWS Load Balancer Controller for Kubernetes (announced 2025)
is a highly available and scalable service to consolidate the AWS VPC routing configuration for a region with a hub-and-spoke architecture.
acts as a Regional virtual router and is a network transit hub that can be used to interconnect VPCs and on-premises networks.
traffic always stays on the global AWS backbone, data is automatically encrypted, and never traverses the public internet, thereby reducing threat vectors, such as common exploits and DDoS attacks.
is a Regional resource and can connect VPCs within the same AWS Region.
TGWs across the same or different regions can peer with each other.
provides simpler VPC-to-VPC communication management over VPC Peering with a large number of VPCs.
scales elastically based on the volume of network traffic.
supports security group referencing (announced Sept 2024) – allows creating inbound security rules that reference security groups defined in other VPCs attached to the same Transit Gateway within the same Region.
supports per-AZ metrics delivered to CloudWatch and Path MTU Discovery (PMTUD) for both IPv4 and IPv6 (announced Nov 2024).
supports Transit Gateway Flow Logs for monitoring and logging network traffic between transit gateways.
supports Flexible Cost Allocation (announced Nov 2025) – provides versatile cost allocation options through a central metering policy beyond the default sender-pay model.
Amazon VPC Lattice
is a fully managed application networking service that connects, monitors, and secures communications between services and resources across VPCs and accounts.
simplifies service-to-service connectivity without requiring VPC peering, Transit Gateway, or PrivateLink NLBs.
automatically manages network connectivity and application-layer routing between services across different VPCs and AWS accounts.
supports connectivity to TCP resources, such as databases, domain names, and IP addresses across VPCs and accounts.
integrates with AWS IAM for service-to-service authentication and authorization using Auth policies.
removes the NLB requirement that PrivateLink imposes on providers and supports cross-VPC/cross-account connectivity without CIDR coordination.
terminates TLS at the data plane so callers do not need to manage certificates.
provides built-in observability with access logs, connection logs, and traffic metrics.
Key concepts:
Service Network – a logical boundary for a collection of services that can communicate with each other
Service – represents an application unit that is independently deployable
Target Groups – collection of resources (instances, IPs, Lambda, ALB) for routing
Microservices connectivity across multiple VPCs/accounts
Secure service-to-service communication with zero trust
Alternative to VPC Peering and Transit Gateway for application-layer connectivity
Replacement for AWS App Mesh (which reached EOL on September 30, 2026)
Amazon VPC IP Address Manager (IPAM)
is a VPC feature that allows you to plan, track, and monitor IP addresses for AWS workloads.
organizes IP addresses by routing and security requirements while automating allocation to VPCs, replacing manual spreadsheet-based tracking.
tracks AWS accounts and VPCs, eliminating IP bookkeeping overhead.
supports management at both VPC and subnet CIDR levels.
integrates with AWS Organizations for cross-account IP address management.
supports provisioning Amazon-provided contiguous IPv4 blocks into publicly scoped regional pools for use with EIPs, NLBs, and NAT Gateways.
Public IP Insights – free feature that simplifies monitoring, analysis, and auditing of public IPv4 addresses.
IPAM Policies – define public IPv4 allocation strategies and automate prefix lists.
integrates with ALB for predictable IP address blocks for internet-facing ALBs (March 2025).
IPAM Advanced Tier – includes Infoblox integration (Nov 2025) for managing AWS IP addresses through existing Infoblox workflows.
AWS Network Firewall
is a managed, stateful network firewall and intrusion detection and prevention service for all Amazon VPCs.
scales automatically with network traffic, requiring no infrastructure management.
provides Layer 7 firewall capabilities with deep packet inspection.
supports flexible rules engine for fine-grained control of VPC network traffic.
provides active threat defense using AWS managed rules to block evasive C2 channels, malicious URLs, and other threat vectors.
supports Suricata-compatible IPS rules for known bad signatures and traffic patterns.
includes Network Firewall Proxy for granular security controls to inspect and filter VPC outbound connections, preventing data exfiltration and malware intrusion.
integrates with AWS Firewall Manager for centralized policy management across accounts.
can be combined with VPC Lattice for comprehensive security (VPC Lattice for HTTP/S with identity-based controls, Network Firewall for other traffic types).
AWS Cloud WAN
is a managed WAN service that provides a central dashboard to connect and manage branch offices, data centers, VPN connections, SD-WAN, VPCs, and Transit Gateways.
uses network policies to create a global network spanning multiple locations and networks, removing the need for different technologies.
provides a single console and set of APIs to manage networks across AWS Regions.
supports direct Direct Connect gateway attachments without requiring an intermediate Transit Gateway (announced Nov 2024).
supports Routing Policy for advanced traffic control (announced Nov 2025) – enables controlled routing environments, minimizing route reachability blast radius.
supports Service Insertion for inspection and security appliance integration.
supports PMTUD for both IPv4 and IPv6 (announced Nov 2024).
supports AWS PrivateLink and IPv6 for management endpoint connectivity (announced March 2025).
available in AWS GovCloud (US) Regions.
AWS Verified Access
provides secure access to corporate applications and resources without requiring a VPN.
implements zero trust principles by evaluating each access request based on user identity and device security posture rather than network location.
uses the Cedar policy language for defining fine-grained access policies.
supports secure access to resources over non-HTTP(S) protocols (announced Feb 2025) – enables VPN-less access to TCP-based resources like SSH, RDP, and databases.
continuously monitors active connections and terminates connections when security requirements aren’t met.
integrates with third-party identity providers and device management solutions.
can be used with PrivateLink-backed services to provide authorized internet-based access while maintaining security boundaries.
CloudFront is a fully managed, fast content delivery network (CDN) service that speeds up the distribution of static, dynamic web, or streaming content to end-users.
CloudFront delivers the content through a worldwide network of over 600 Points of Presence (POPs), including 400+ Edge Locations, 13 Regional Edge Caches, and Embedded POPs within ISP networks.
CloudFront securely delivers data, videos, applications, and APIs to customers globally with low latency, and high transfer speeds, all within a developer-friendly environment.
CloudFront gives businesses and web application developers an easy and cost-effective way to distribute content with low latency and high data transfer speeds.
CloudFront speeds up the distribution of the content by routing each user request to the edge location that can best serve the content thus providing the lowest latency (time delay).
CloudFront uses the AWS backbone network that dramatically reduces the number of network hops that users’ requests must pass through and helps improve performance, provide lower latency and higher data transfer rate
CloudFront is a good choice for the distribution of frequently accessed static content that benefits from edge delivery – like popular website images, videos, media files, or software downloads
CloudFront supports HTTP/3 powered by QUIC protocol for improved performance, with up to 10% improvement in time to first byte and 15% improvement in page load times.
CloudFront supports gRPC delivery (launched Nov 2024), enabling bidirectional communication between clients and servers over HTTP/2 connections for modern microservices architectures.
CloudFront Benefits
CloudFront eliminates the expense and complexity of operating a network of cache servers in multiple sites across the internet and eliminates the need to over-provision capacity in order to serve potential spikes in traffic.
CloudFront also provides increased reliability and availability because copies of objects are held in multiple edge locations around the world.
CloudFront keeps persistent connections with the origin servers so that those files can be fetched from the origin servers as quickly as possible.
CloudFront also uses techniques such as collapsing simultaneous viewer requests at an edge location for the same file into a single request to the origin server reducing the load on the origin.
CloudFront offers the most advanced security capabilities, including field-level encryption, HTTPS support, and mutual TLS (mTLS) authentication.
CloudFront provides one-click WAF security protections and a unified Security Dashboard for observability, investigation, and contextual configuration.
CloudFront offers flat-rate pricing plans (Free, Pro at $15/month, Business at $200/month, Premium at $1,000/month) that bundle CDN, WAF, DDoS protection, bot management, Route 53 DNS, CloudWatch Logs, and edge compute into a single monthly price with no overage charges.
Edge Locations & Regional Edge Caches
CloudFront Edge Locations or POPs make sure that popular content can be served quickly to the viewers.
CloudFront also has Regional Edge Caches that help bring more content closer to the viewers, even when the content is not popular enough to stay at a POP, to help improve performance for that content.
Regional Edge Caches are deployed globally, close to the viewers, and are located between the origin servers and the Edge Locations.
Regional edge caches support multiple Edge Locations and support a larger cache size so objects remain in the cache longer at the nearest regional edge cache location.
Regional edge caches help with all types of content, particularly content that tends to become less popular over time.
CloudFront Embedded POPs (launched 2024) are deployed within Internet Service Provider (ISP) networks to bring content even closer to end users, reducing latency for high-demand cacheable content like large file downloads and video streaming.
Configuration & Content Delivery
Configuration
Origin servers need to be configured to get the files for distribution. An origin server stores the original, definitive version of the objects and can be an AWS hosted service for e.g. S3, EC2, or an on-premise server
Files or objects can be added/uploaded to the Origin servers with public read permissions or permissions restricted to Origin Access Control (OAC).
Create a CloudFront distribution, which tells CloudFront which origin servers to get the files from when users request the files.
CloudFront sends the distribution configuration to all the edge locations.
The website can be used with the CloudFront provided domain name or a custom alternate domain name.
An origin server can be configured to limit access protocols, caching behaviour, add headers to the files to add TTL, or the expiration time.
Content delivery to Users
When a user accesses the website, file, or object – the DNS routes the request to the CloudFront edge location that can best serve the user’s request with the lowest latency.
CloudFront returns the object immediately if the requested object is present in the cache at the Edge location.
If the requested object does not exist in the cache at the edge location, the POP typically goes to the nearest regional edge cache to fetch it.
If the object is in the regional edge cache, CloudFront forwards it to the POP that requested it.
For objects not cached at either the POP or the regional edge cache location, the objects are requested from the origin server and returned it to the user via the regional edge cache and POP
CloudFront begins to forward the object to the user as soon as the first byte arrives from the regional edge cache location.
CloudFront also adds the object to the cache in the regional edge cache location in addition to the POP for the next time a viewer requests it.
When the object reaches its expiration time, for any new request CloudFront checks with the Origin server for any latest versions, if it has the latest it uses the same object. If the Origin server has the latest version the same is retrieved, served to the user, and cached as well
CloudFront Origins
Each origin is either an S3 bucket, a MediaStore container, a MediaPackage channel, an AWS Lambda function URL, a VPC origin, or a custom origin like an EC2 instance or an HTTP server
For the S3 bucket, use the bucket URL or the static website endpoint URL, and the files either need to be publicly readable or secured using Origin Access Control (OAC).
Origin restrict access, for S3, Lambda function URLs, and MediaPackage origins, can be configured using Origin Access Control (OAC) to prevent direct access to the origin.
For the HTTP server as the origin, the domain name of the resource needs to be mapped and files must be publicly readable.
Distribution can have multiple origins for each bucket with one or more cache behaviors that route requests to each origin. Path pattern in a cache behavior determines which requests are routed to the origin (S3 bucket) that is associated with that cache behavior.
Origin Access Control (OAC)
⚠️ Origin Access Identity (OAI) Deprecated: AWS deprecated OAI creation in 2024. As of March 2026, new distributions can only use Origin Access Control (OAC). Existing OAI-based policies still work but cannot be attached to new distributions. AWS recommends migrating to OAC.
Origin Access Control (OAC) is the recommended method to restrict access to origins from CloudFront distributions, replacing the legacy Origin Access Identity (OAI).
OAC uses AWS Signature Version 4 (SigV4) for robust cryptographic authentication.
OAC supports granular policy configurations, HTTP/HTTPS POST method requests in all regions, and integration with SSE-KMS encrypted S3 objects.
OAC supports multiple origin types:
Amazon S3 – restricts bucket access to designated CloudFront distributions
Lambda Function URLs (April 2024) – blocks unintended users from directly accessing function URLs
AWS Elemental MediaPackage (April 2024) – permits origin access only from designated distributions
AWS Elemental MediaStore – secures media container access
When using OAC with S3, Amazon S3 Object Ownership must be set to “Bucket owner enforced” (default for new buckets).
OAC cannot be used with S3 buckets configured as website endpoints; use custom origin configuration instead.
CloudFront VPC Origins
CloudFront VPC Origins (launched November 2024) allows CloudFront to deliver content from applications hosted in private VPC subnets without requiring public internet access.
VPC Origins removes the need for complex security configurations like security groups, AWS WAF on origin, or custom header validation to restrict origin access.
Applications can be made fully private with CloudFront as the single entry point, preventing direct internet access to origin infrastructure.
Cross-account support (launched 2025) allows VPC Origins to work with resources in different AWS accounts.
VPC Origins is available at no additional cost.
CloudFront Origin Groups
Origin Groups can be used to specify two origins to configure origin failover for high availability.
Origin failover can be used to designate a primary origin plus a second origin that CloudFront automatically switches to when the primary origin returns specific HTTP status code failure responses.
An origin group includes two origins (a primary origin and a second origin to failover to) and specified failover criteria.
CloudFront routes all incoming requests to the primary origin, even when a previous request has failed over to the secondary origin. CloudFront only sends requests to the secondary origin after a request fails to the primary origin.
CloudFront fails over to a secondary origin only when the HTTP method of the consumer request is GET, HEAD, or OPTIONS and does not fail over when the consumer sends a different HTTP method (for example POST, PUT, etc.).
CloudFront Delivery Methods
Web distributions
supports both static and dynamic content for e.g. HTML, CSS, js, images, etc using HTTP or HTTPS.
supports multimedia content on-demand using progressive download and Apple HTTP Live Streaming (HLS).
supports a live event, such as a meeting, conference, or concert, in real-time. For live streaming, distribution can be created automatically using an AWS CloudFormation stack.
origin servers can be either an S3 bucket or an HTTP server, for e.g., a web server or an AWS ELB, etc.
supports gRPC delivery for modern microservices communication over HTTP/2 connections.
RTMP distributions (Discontinued)
RTMP distribution support was fully discontinued by AWS. CloudFront no longer supports Adobe RTMP protocol.
For streaming use cases, use Web distributions with HLS, DASH, or CMAF protocols instead.
Cache Behavior Settings
Path Patterns
Path Patterns help define which path the Cache behaviour would apply to.
A default (*) pattern is created and multiple cache distributions can be added with patterns to take priority over the default path.
Viewer Protocol Policy (Viewer -> CloudFront)
Viewer Protocol policy can be configured to define the allowed access protocol.
Between CloudFront & Viewers, cache distribution can be configured to either allow
HTTPS only – supports HTTPS only
HTTP and HTTPS – supports both
HTTP redirected to HTTPS – HTTP is automatically redirected to HTTPS
Origin Protocol Policy (CloudFront -> Origin)
Between CloudFront & Origin, cache distribution can be configured with
HTTP only (for S3 static website).
HTTPS only – CloudFront fetches objects from the origin by using HTTPS.
Match Viewer – CloudFront uses the protocol that the viewer used to request the objects.
For S3 as origin,
For the website, the protocol has to be HTTP as HTTPS is not supported.
For the S3 bucket, the default Origin protocol policy is Match Viewer and cannot be changed. So When CloudFront is configured to require HTTPS between the viewer and CloudFront, it automatically uses HTTPS to communicate with S3.
HTTPS Connection
CloudFront can also be configured to work with HTTPS for alternate domain names by using:-
Serving HTTPS Requests Using Dedicated IP Addresses
CloudFront associates the alternate domain name with a dedicated IP address, and the certificate is associated with the IP address when a request is received from a DNS server for the IP address.
This method works for every HTTPS request, regardless of the browser or other viewer that the user is using.
An additional monthly charge (of about $600/month) is incurred for using a dedicated IP address.
Serving HTTPS Requests Using Server Name Indication – SNI (Recommended)
SNI Custom SSL relies on the SNI extension of the TLS protocol, which allows multiple domains to be served over the same IP address by including the hostname, viewers are trying to connect to
SNI Custom SSL is available at no additional cost beyond standard CloudFront data transfer and request fees
Most modern browsers support SNI.
For End-to-End HTTPS connections certificate needs to be applied both between the Viewers and CloudFront & CloudFront and Origin, with the following requirements
HTTPS between viewers and CloudFront
A certificate issued by a trusted certificate authority (CA);
If the origin is not an ELB load balancer, the certificate must be issued by a trusted CA.
For load balancer, a certificate provided by ACM can be used
Self-signed certificates CAN NOT be used.
ACM certificate for CloudFront must be requested or imported in the US East (N. Virginia) region. ACM certificates in this region that are associated with a CloudFront distribution are distributed to all the geographic locations configured for that distribution.
Mutual TLS (mTLS) Authentication
CloudFront supports viewer mutual TLS (mTLS) authentication, requiring both client and server to present and verify digital certificates for two-way authentication.
Viewer mTLS provides strong client authentication at the edge before traffic reaches the origin infrastructure.
CloudFront also supports mTLS authentication to origins (launched 2025), preserving cryptographic identity and trust across the full request path from viewer to CloudFront to origin.
CloudFront Connection Functions can be used to write lightweight JavaScript functions for custom mTLS certificate validation and authentication logic at edge locations.
mTLS requires HTTPS connections; it cannot be enabled on distributions with HTTP-supporting cache behaviors.
Allowed HTTP methods
CloudFront supports GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE to get, add, update, and delete objects, and to get object headers.
GET, HEAD methods to use to get objects, object headers
GET, HEAD, OPTIONS methods to use to get objects, object headers or retrieve a list of the options supported from the origin
GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE operations can also be performed for e.g. submitting data from a web form, which are directly proxied back to the Origin server
CloudFront only caches responses to GET and HEAD requests and, optionally, OPTIONS requests. CloudFront does not cache responses to PUT, POST, PATCH, DELETE request methods and these requests are directed to the origin.
PUT, POST HTTP methods also help for accelerated content uploads, as these operations will be sent to the origin e.g. S3 via the CloudFront edge location, improving efficiency, reducing latency, and allowing the application to benefit from the monitored, persistent connections that CloudFront maintains from the edge locations to the origin servers.
CloudFront Edge Caches
Control the cache max-age
To increase the cache hit ratio, the origin can be configured to add a Cache-Control: max-age directive to the objects.
Longer the interval less frequently it would be retrieved from the origin
Caching Based on Query String Parameters
CloudFront can be configured to cache based on the query parameters
None (Improves Caching) – if the origin returns the same version of an object regardless of the values of query string parameters.
Forward all, cache based on whitelist – if the origin server returns different versions of the objects based on one or more query string parameters.
Forward all, cache based on all – if the origin server returns different versions of the objects for all query string parameters.
Caching performance can be improved by
Configure CloudFront to forward only the query strings for which the origin will return unique objects.
Using the same case for the parameters’ values for e.g. parameter value A or a, CloudFront would cache the same request twice even if the response or object returned is identical
Using the same parameter order for e.g. for request a=x&b=y and b=y&a=x, CloudFront would cache the same request twice even though the response or object returned is identical
Caching Based on Cookie Values
CloudFront can be configured to cache based on cookie values.
By default, it doesn’t consider cookies while caching on edge locations
Caching performance can be improved by
Configure CloudFront to forward only specified cookies instead of forwarding all cookies
Cookie names and values are both case sensitive so better to stick with the same case
Create separate cache behaviors for static and dynamic content, and configure CloudFront to forward cookies to the origin only for dynamic content
If possible, create separate cache behaviors for dynamic content for which cookie values are unique for each user (such as a user ID) and dynamic content that varies based on a smaller number of unique values
Caching Based on Request Headers
CloudFront can be configured to cache based on request headers
By default, CloudFront doesn’t consider headers when caching the objects in edge locations.
Caching performance can be improved by
Configure CloudFront to forward and cache based only on specified headers instead of forwarding and caching based on all headers.
Try to avoid caching based on request headers that have large numbers of unique values.
CloudFront configured to forward all headers to the origin doesn’t cache the objects associated with this cache behaviour. Instead, it sends every request to the origin
CloudFront caches based on header values, it doesn’t consider the case of the header name but considers the case of the header value
Object Caching & Expiration
Object expiration determines how long the objects stay in a CloudFront cache before it fetches it again from Origin.
Low expiration time helps serve content that changes frequently and high expiration time helps improve performance and reduce the origin load.
By default, each object automatically expires after 24 hours
After expiration time, CloudFront checks if it still has the latest version
If the cache already has the latest version, the origin returns a 304 status code (Not Modified).
If the CloudFront cache does not have the latest version, the origin returns a 200 status code (OK), and the latest version of the object
If an object in an edge location isn’t frequently requested, CloudFront might evict the object before its expiration date to make room for objects that have been requested more recently.
The default behaviour can be changed by
for the entire path pattern, cache behaviour can be configured by the setting Minimum TTL, Maximum TTL, and Default TTL values
for individual objects, the origin can be configured to add a Cache-Control max-age or Cache-Control s-maxage directive, or an Expires header field to the object.
AWS recommends using Cache-Control max-age directive over Expires header to control object caching behaviour.
CloudFront uses only the value of Cache-Control max-age , if both the Cache-Control max-age directive and Expires header is specified
HTTP Cache-Control or Pragma header fields in a GET request from a viewer can’t be used to force CloudFront to go back to the origin server for the object
By default, when the origin returns an HTTP 4xx or 5xx status code, CloudFront caches these error responses for five minutes and then submits the next request for the object to the origin
Cache Invalidation
CloudFront supports URL path-based invalidation to remove cached objects from edge locations before they expire.
Invalidation by Cache Tag (launched April 2026) – allows invalidating groups of related cached objects using a single request based on semantic tags rather than URL paths.
Origins include cache tags via a response header with comma-separated tag values when objects are cached.
Objects can be invalidated by tag directly through the CloudFront API.
Useful for updating product catalogs, managing compliance requirements, and refreshing multi-tenant content.
Tag invalidation paths count toward the same 1,000 free invalidation paths per month allowance.
AWS recommends using file versioning (versioned file names) over invalidation for content updates when possible.
CloudFront Origin Shield
CloudFront Origin Shield provides an additional layer in the CloudFront caching infrastructure that helps to minimize the origin’s load, improve its availability, and reduce its operating costs.
Origin Shield provides a centralized caching layer that helps increase the cache hit ratio to reduce the load on your origin.
Origin Shield decreases the origin operating costs by collapsing requests across regions so as few as one request goes to the origin per object.
Origin Shield can be configured by choosing the Regional Edge Cache closest to the origin to become the Origin Shield Region
CloudFront Origin Shield is beneficial for many use cases like
Viewers that are spread across different geographical regions
Origins that provide just-in-time packaging for live streaming or on-the-fly image processing
On-premises origins with capacity or bandwidth constraints
Workloads that use multiple content delivery networks (CDNs)
Serving Compressed Files
CloudFront can be configured to automatically compress files of certain types and serve the compressed files when viewer requests include Accept-Encoding in the request header
Compressing content, downloads are faster because the files are smaller as well as less expensive as the cost of CloudFront data transfer is based on the total amount of data served.
CloudFront can compress objects using the Gzip and Brotli compression formats.
If serving from a custom origin, it can be used to
configure to compress files with or without CloudFront compression
compress file types that CloudFront doesn’t compress.
If the origin returns a compressed file, CloudFront detects compression by the Content-Encoding header value and doesn’t compress the file again.
CloudFront compresses files between 1,000 and 10,000,000 bytes in size, and the response must include a Content-Length header.
Distribution Details
Price Class
CloudFront has edge locations all over the world and the cost for each edge location varies and the price charged for serving the requests also varies
CloudFront edge locations are grouped into geographic regions, and regions have been grouped into price classes
Price Class All – includes all the regions
Price Class 200 – Includes All regions except South America and Australia and New Zealand.
Price Class 100 – Includes only the least-expensive regions (North America and Europe regions)
Price class can be selected to lower the cost but this would come only at the expense of performance (higher latency), as CloudFront would serve requests only from the selected price class edge locations
CloudFront may, sometimes, service requests from a region not included within the price class, however, you would be charged the rate for the least-expensive region in your selected price class
WAF Web ACL
AWS WAF can be used to allow or block requests based on specified criteria, choose the web ACL to associate with this distribution.
One-click WAF security protection is available directly from the CloudFront console to quickly enable common protections including bot control.
CloudFront Security Dashboard provides a unified view for monitoring, investigating, and configuring WAF security protections.
Alternate Domain Names (CNAMEs)
CloudFront by default assigns a domain name for the distribution for e.g. d111111abcdef8.cloudfront.net
An alternate domain name, also known as a CNAME, can be used to use own custom domain name for links to objects
Web distributions support alternate domain names.
CloudFront supports * wildcard at the beginning of a domain name instead of specifying subdomains individually.
However, a wildcard cannot replace part of a subdomain name for e.g. *domain.example.com, or cannot replace a subdomain in the middle of a domain name for e.g. subdomain.*.example.com.
Anycast Static IPs
CloudFront Anycast Static IPs (launched November 2024) provides a dedicated list of static IP addresses for CloudFront distributions.
Useful for allowlisting in network firewalls, zero-rating traffic with network carriers, and simplifying IP address management.
Supports apex domains (April 2025), allowing A records for apex domains without requiring Route 53 alias records.
Integrates with VPC IPAM for Bring Your Own IP (BYOIP) support, allowing use of both IPv4 and IPv6 addresses.
Distribution State
Distribution state indicates whether you want the distribution to be enabled or disabled once it’s deployed.
CloudFront Continuous Deployment
CloudFront Continuous Deployment allows safely testing and validating configuration changes using a portion of production traffic before committing the entire workload.
Creates a staging distribution linked to the primary distribution to test changes with real traffic.
Supports blue/green and canary deployment strategies for CDN configuration changes.
Enables zero-downtime deployments with easy rollback if issues are detected.
Can be integrated with CI/CD pipelines for automated testing and promotion of changes.
Geo-Restriction – Geoblocking
Geo restriction can help allow or prevent users in selected countries from accessing the content,
CloudFront distribution can be configured either to allow users in
whitelist of specified countries to access the content or to
deny users in a blacklist of specified countries to access the content
Geo restriction can be used to restrict access to all of the files that are associated with distribution and to restrict access at the country level
CloudFront responds to a request from a viewer in a restricted country with an HTTP status code 403 (Forbidden)
Use a third-party geolocation service, if access is to be restricted to a subset of the files that are associated with a distribution or to restrict access at a finer granularity than the country level.
CloudFront Functions execute in 700+ Edge Locations with sub-millisecond execution times.
Suitable for lightweight, high-scale request/response transformations such as URL rewrites, header manipulation, and access control.
CloudFront KeyValueStore (launched November 2023) – a low-latency edge datastore for CloudFront Functions, enabling data updates without redeploying function code.
New capabilities (2025): edge location metadata, raw query string retrieval, and advanced origin overrides.
Supports CBOR Web Tokens (CWT) and Common Access Tokens (CAT) for token validation, generation, and refresh logic.
CloudFront Connection Functions
CloudFront Connection Functions enable lightweight JavaScript functions for mTLS certificate validation and custom authentication logic at the TLS connection layer.
Can validate client certificates, implement device-specific authentication rules, and handle certificate revocation scenarios.
Execute at CloudFront edge locations worldwide for low-latency connection-time decisions.
Lambda@Edge
Lambda@Edge executes at 13 Regional Edge Cache locations for more complex compute operations.
Suitable for operations requiring external network calls, longer execution times, or larger function packages.
CloudFront SaaS Manager
CloudFront SaaS Manager (launched May 2025) simplifies scaling and managing multi-tenant web applications that deliver content to end users.
Introduces multi-tenant distributions that serve content across multiple domains while sharing configuration and infrastructure.
Reduces operational overhead with reusable configuration templates and parameters for tenant onboarding.
Each tenant can have custom domain names, TLS certificates, and cache behaviors while sharing the underlying distribution infrastructure.
Ideal for SaaS providers needing to manage hundreds or thousands of customer domains efficiently.
CloudFront provides Encryption in Transit and can be configured to require that viewers use HTTPS to request the files so that connections are encrypted when CloudFront communicates with viewers.
CloudFront provides Encryption at Rest
uses SSDs which are encrypted for edge location points of presence (POPs), and encrypted EBS volumes for Regional Edge Caches (RECs).
Function code and configuration are always stored in an encrypted format on the encrypted SSDs on the edge location POPs, and in other storage locations used by CloudFront.
Restricting access to content
Configure HTTPS connections
Use signed URLs or cookies to restrict access for selected users
Restrict access to content in S3 buckets using Origin Access Control (OAC) to prevent users from using the direct URL of the file.
Restrict access to Lambda function URLs using OAC.
Restrict direct access to load balancer using custom headers or VPC Origins.
Set up field-level encryption for specific content fields
Use AWS WAF web ACLs to create a web access control list (web ACL) to restrict access to your content.
Use geo-restriction, also known as geoblocking, to prevent users in specific geographic locations from accessing content served through a CloudFront distribution.
Use mutual TLS (mTLS) for strong two-way client/server authentication at the edge.
CloudFront can be configured to create log files that contain detailed information about every user request that CloudFront receives.
With logging enabled, an S3 bucket can be specified where CloudFront would save the files
CloudFront delivers access logs for a distribution periodically, up to several times an hour
CloudFront usually delivers the log file for that time period to the S3 bucket within an hour of the events that appear in the log. Note, however, that some or all log file entries for a time period can sometimes be delayed by up to 24 hours
CloudFront also supports real-time logs delivery to Amazon Kinesis Data Streams for immediate processing and analysis.
CloudFront Cost
CloudFront charges are based on actual usage of the service in four areas:
Data Transfer Out to Internet
charges are applied for the volume of data transferred out of the CloudFront edge locations, measured in GB
Data transfer out from AWS origin (e.g., S3, EC2, etc.) to CloudFront are no longer charged. This applies to data transfer from all AWS regions to all global CloudFront edge locations
HTTP/HTTPS Requests
number of HTTP/HTTPS requests made for the content
Invalidation Requests
per path in the invalidation request (first 1,000 paths free per month)
Tag-based invalidation paths count toward the same free allowance
Dedicated IP Custom SSL certificates associated with a CloudFront distribution
$600 per month for each custom SSL certificate using the Dedicated IP version (SNI is free)
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
Your company Is moving towards tracking web page users with a small tracking Image loaded on each page Currently you are serving this image out of US-East, but are starting to get concerned about the time It takes to load the image for users on the west coast. What are the two best ways to speed up serving this image? Choose 2 answers
Use Route 53’s Latency Based Routing and serve the image out of US-West-2 as well as US-East-1
Serve the image out through CloudFront
Serve the image out of S3 so that it isn’t being served oft of your web application tier
Use EBS PIOPs to serve the image faster out of your EC2 instances
You deployed your company website using Elastic Beanstalk and you enabled log file rotation to S3. An Elastic Map Reduce job is periodically analyzing the logs on S3 to build a usage dashboard that you share with your CIO. You recently improved overall performance of the website using Cloud Front for dynamic content delivery and your website as the origin. After this architectural change, the usage dashboard shows that the traffic on your website dropped by an order of magnitude. How do you fix your usage dashboard’? [PROFESSIONAL]
Enable CloudFront to deliver access logs to S3 and use them as input of the Elastic Map Reduce job
Turn on Cloud Trail and use trail log tiles on S3 as input of the Elastic Map Reduce job
Change your log collection process to use Cloud Watch ELB metrics as input of the Elastic Map Reduce job
Use Elastic Beanstalk “Rebuild Environment” option to update log delivery to the Elastic Map Reduce job.
Use Elastic Beanstalk ‘Restart App server(s)” option to update log delivery to the Elastic Map Reduce job.
An AWS customer runs a public blogging website. The site users upload two million blog entries a month. The average blog entry size is 200 KB. The access rate to blog entries drops to negligible 6 months after publication and users rarely access a blog entry 1 year after publication. Additionally, blog entries have a high update rate during the first 3 months following publication; this drops to no updates after 6 months. The customer wants to use CloudFront to improve his user’s load times. Which of the following recommendations would you make to the customer? [PROFESSIONAL]
Duplicate entries into two different buckets and create two separate CloudFront distributions where S3 access is restricted only to Cloud Front identity
Create a CloudFront distribution with “US & Europe” price class for US/Europe users and a different CloudFront distribution with All Edge Locations for the remaining users.
Create a CloudFront distribution with S3 access restricted only to the CloudFront identity and partition the blog entry’s location in S3 according to the month it was uploaded to be used with CloudFront behaviors
Create a CloudFront distribution with Restrict Viewer Access Forward Query string set to true and minimum TTL of 0.
Your company has on-premises multi-tier PHP web application, which recently experienced downtime due to a large burst in web traffic due to a company announcement. Over the coming days, you are expecting similar announcements to drive similar unpredictable bursts, and are looking to find ways to quickly improve your infrastructures ability to handle unexpected increases in traffic. The application currently consists of 2 tiers a web tier, which consists of a load balancer, and several Linux Apache web servers as well as a database tier which hosts a Linux server hosting a MySQL database. Which scenario below will provide full site functionality, while helping to improve the ability of your application in the short timeframe required? [PROFESSIONAL]
Offload traffic from on-premises environment Setup a CloudFront distribution and configure CloudFront to cache objects from a custom origin Choose to customize your object cache behavior, and select a TTL that objects should exist in cache.
Migrate to AWS Use VM Import/Export to quickly convert an on-premises web server to an AMI create an Auto Scaling group, which uses the imported AMI to scale the web tier based on incoming traffic Create an RDS read replica and setup replication between the RDS instance and on-premises MySQL server to migrate the database.
Failover environment: Create an S3 bucket and configure it tor website hosting Migrate your DNS to Route53 using zone (lie import and leverage Route53 DNS failover to failover to the S3 hosted website.
Hybrid environment Create an AMI which can be used of launch web serfers in EC2 Create an Auto Scaling group which uses the * AMI to scale the web tier based on incoming traffic Leverage Elastic Load Balancing to balance traffic between on-premises web servers and those hosted in AWS.
You are building a system to distribute confidential training videos to employees. Using CloudFront, what method could be used to serve content that is stored in S3, but not publically accessible from S3 directly?
Create an Origin Access Control (OAC) for CloudFront and grant access to the objects in your S3 bucket to that OAC.(Note: Previously this was Origin Access Identity/OAI which is now deprecated. OAC is the current recommended approach.)
Add the CloudFront account security group “amazon-cf/amazon-cf-sg” to the appropriate S3 bucket policy.
Create an Identity and Access Management (IAM) User for CloudFront and grant access to the objects in your S3 bucket to that IAM User.
Create a S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).
A media production company wants to deliver high-definition raw video for preproduction and dubbing to customer all around the world. They would like to use Amazon CloudFront for their scenario, and they require the ability to limit downloads per customer and video file to a configurable number. A CloudFront download distribution with TTL=0 was already setup to make sure all client HTTP requests hit an authentication backend on Amazon Elastic Compute Cloud (EC2)/Amazon RDS first, which is responsible for restricting the number of downloads. Content is stored in S3 and configured to be accessible only via CloudFront. What else needs to be done to achieve an architecture that meets the requirements? Choose 2 answers [PROFESSIONAL]
Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in RDS, and return the content S3 URL unless the download limit is reached.
Enable CloudFront logging into an S3 bucket, leverage EMR to analyze CloudFront logs to determine the number of downloads per customer, and return the content S3 URL unless the download limit is reached. (CloudFront logs are logged periodically and EMR not being real time, hence not suitable)
Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in RDS, and invalidate the CloudFront distribution as soon as the download limit is reached. (Distribution are not invalidated but Objects)
Enable CloudFront logging into the S3 bucket, let the authentication backend determine the number of downloads per customer by parsing those logs, and return the content S3 URL unless the download limit is reached. (CloudFront logs are logged periodically and EMR not being real time, hence not suitable)
Configure a list of trusted signers, let the authentication backend count the number of download requests per customer in RDS, and return a dynamically signed URL unless the download limit is reached.
Your customer is implementing a video on-demand streaming platform on AWS. The requirements are to support for multiple devices such as iOS, Android, and PC as client devices, using a standard client player, using streaming technology (not download) and scalable architecture with cost effectiveness [PROFESSIONAL]
Store the video contents to Amazon Simple Storage Service (S3) as an origin server. Configure the Amazon CloudFront distribution with a streaming option to stream the video contents
Store the video contents to Amazon S3 as an origin server. Configure the Amazon CloudFront distribution with a download option to stream the video contents (Refer link)
Launch a streaming server on Amazon Elastic Compute Cloud (EC2) (for example, Adobe Media Server), and store the video contents as an origin server. Configure the Amazon CloudFront distribution with a download option to stream the video contents
Launch a streaming server on Amazon Elastic Compute Cloud (EC2) (for example, Adobe Media Server), and store the video contents as an origin server. Launch and configure the required amount of streaming servers on Amazon EC2 as an edge server to stream the video contents
You are an architect for a news -sharing mobile application. Anywhere in the world, your users can see local news on of topics they choose. They can post pictures and videos from inside the application. Since the application is being used on a mobile phone, connection stability is required for uploading content, and delivery should be quick. Content is accessed a lot in the first minutes after it has been posted, but is quickly replaced by new content before disappearing. The local nature of the news means that 90 percent of the uploaded content is then read locally (less than a hundred kilometers from where it was posted). What solution will optimize the user experience when users upload and view content (by minimizing page load times and minimizing upload times)? [PROFESSIONAL]
Upload and store the content in a central Amazon Simple Storage Service (S3) bucket, and use an Amazon Cloud Front Distribution for content delivery.
Upload and store the content in an Amazon Simple Storage Service (S3) bucket in the region closest to the user, and use multiple Amazon Cloud Front distributions for content delivery.
Upload the content to an Amazon Elastic Compute Cloud (EC2) instance in the region closest to the user, send the content to a central Amazon Simple Storage Service (S3) bucket, and use an Amazon Cloud Front distribution for content delivery.
Use an Amazon Cloud Front distribution for uploading the content to a central Amazon Simple Storage Service (S3) bucket and for content delivery.
To enable end-to-end HTTPS connections from the user’s browser to the origin via CloudFront, which of the following options are valid? Choose 2 answers [PROFESSIONAL]
Use self signed certificate in the origin and CloudFront default certificate in CloudFront. (Origin cannot be self signed)
Use the CloudFront default certificate in both origin and CloudFront (CloudFront cert cannot be applied to origin)
Use 3rd-party CA certificate in the origin and CloudFront default certificate in CloudFront
Use 3rd-party CA certificate in both origin and CloudFront
Use a self signed certificate in both the origin and CloudFront (Origin cannot be self signed)
Your application consists of 10% writes and 90% reads. You currently service all requests through a Route53 Alias Record directed towards an AWS ELB, which sits in front of an EC2 Auto Scaling Group. Your system is getting very expensive when there are large traffic spikes during certain news events, during which many more people request to read similar data all at the same time. What is the simplest and cheapest way to reduce costs and scale with spikes like this? [PROFESSIONAL]
Create an S3 bucket and asynchronously replicate common requests responses into S3 objects. When a request comes in for a precomputed response, redirect to AWS S3
Create another ELB and Auto Scaling Group layer mounted on top of the other system, adding a tier to the system. Serve most read requests out of the top layer
Create a CloudFront Distribution and direct Route53 to the Distribution. Use the ELB as an Origin and specify Cache Behaviors to proxy cache requests, which can be served late. (CloudFront can server request from cache and multiple cache behavior can be defined based on rules for a given URL pattern based on file extensions, file names, or any portion of a URL. Each cache behavior can include the CloudFront configuration values: origin server name, viewer connection protocol, minimum expiration period, query string parameters, cookies, and trusted signers for private content.)
Create a Memcached cluster in AWS ElastiCache. Create cache logic to serve requests, which can be served late from the in-memory cache for increased performance.
You are designing a service that aggregates clickstream data in batch and delivers reports to subscribers via email only once per week. Data is extremely spikey, geographically distributed, high-scale, and unpredictable. How should you design this system?
Use a large RedShift cluster to perform the analysis, and a fleet of Lambdas to perform record inserts into the RedShift tables. Lambda will scale rapidly enough for the traffic spikes.
Use a CloudFront distribution with access log delivery to S3. Clicks should be recorded as query string GETs to the distribution. Reports are built and sent by periodically running EMR jobs over the access logs in S3. (CloudFront is a Gigabit-Scale HTTP(S) global request distribution service and works fine with peaks higher than 10 Gbps or 15,000 RPS. It can handle scale, geo-spread, spikes, and unpredictability. Access Logs will contain the GET data and work just fine for batch analysis and email using EMR. Other streaming options are expensive as not required as the need is to batch analyze)
Use API Gateway invoking Lambdas which PutRecords into Kinesis, and EMR running Spark performing GetRecords on Kinesis to scale with spikes. Spark on EMR outputs the analysis to S3, which are sent out via email.
Use AWS Elasticsearch service and EC2 Auto Scaling groups. The Autoscaling groups scale based on click throughput and stream into the Elasticsearch domain, which is also scalable. Use Kibana to generate reports periodically.
Your website is serving on-demand training videos to your workforce. Videos are uploaded monthly in high resolution MP4 format. Your workforce is distributed globally often on the move and using company-provided tablets that require the HTTP Live Streaming (HLS) protocol to watch a video. Your company has no video transcoding expertise and it required you might need to pay for a consultant. How do you implement the most cost-efficient architecture without compromising high availability and quality of video delivery? [PROFESSIONAL]
Elastic Transcoder to transcode original high-resolution MP4 videos to HLS. S3 to host videos with lifecycle Management to archive original flies to Glacier after a few days. CloudFront to serve HLS transcoded videos from S3
A video transcoding pipeline running on EC2 using SQS to distribute tasks and Auto Scaling to adjust the number or nodes depending on the length of the queue S3 to host videos with Lifecycle Management to archive all files to Glacier after a few days CloudFront to serve HLS transcoding videos from Glacier
Elastic Transcoder to transcode original high-resolution MP4 videos to HLS EBS volumes to host videos and EBS snapshots to incrementally backup original rues after a few days. CloudFront to serve HLS transcoded videos from EC2.
A video transcoding pipeline running on EC2 using SQS to distribute tasks and Auto Scaling to adjust the number of nodes depending on the length of the queue. EBS volumes to host videos and EBS snapshots to incrementally backup original files after a few days. CloudFront to serve HLS transcoded videos from EC2
A company wants to restrict access to its CloudFront-distributed content to only authenticated IoT devices using certificate-based authentication. Which CloudFront feature should they use?
CloudFront signed URLs with custom policy
AWS WAF with IP-based rules
CloudFront viewer mutual TLS (mTLS) with Connection Functions for certificate validation
Origin Access Control with IAM authentication
A SaaS company needs to deliver content for 500+ customer domains through CloudFront while sharing infrastructure configuration. Which feature best addresses this requirement?
Create 500 separate CloudFront distributions with identical configurations
Use a single distribution with 500 alternate domain names (CNAMEs)
Use CloudFront SaaS Manager with multi-tenant distributions and distribution tenants
Use CloudFront Functions with KeyValueStore for tenant routing
An organization wants to ensure their application load balancer is only accessible through CloudFront and not directly from the internet. Which is the recommended approach?
Add CloudFront IP ranges to the ALB security group
Use a custom HTTP header shared between CloudFront and ALB
Use CloudFront VPC Origins to place the ALB in a private subnet accessible only via CloudFront
Configure AWS WAF on the ALB to block non-CloudFront traffic
provides low latency by caching and delivering content from a global network of 750+ Points of Presence (PoPs) across 100+ cities in 50+ countries
supports HTTP/HTTPS for static and dynamic content delivery
optimized to work with Amazon services like S3, ELB, MediaConvert etc. as well as works seamlessly with any non-AWS origin server
⚠️ Note: CloudFront RTMP distributions were discontinued on December 31, 2020. For streaming, use HTTP-based streaming protocols (HLS, DASH) with CloudFront web distributions and AWS Elemental MediaConvert.
Ideal Usage Patterns
is ideal for distribution of frequently accessed static content, or dynamic content or for streaming audio or video that benefits from edge delivery
API acceleration and real-time content personalization at the edge
security at the edge with integrated WAF, DDoS protection, and bot management
Anti-Pattern
Infrequently accessed data
If the data is infrequently accessed, it would be better to serve the data from the Origin server
Programmatic cache invalidation
CloudFront supports cache invalidation, however AWS recommends using object versioning rather than programmatic cache invalidation.
Performance
is designed for low latency and high bandwidth delivery of content by redirecting the user to the nearest edge location in terms of latency and caching the content preventing the round trip to the origin server
supports HTTP/2 and HTTP/3 (QUIC) for improved connection performance
Durability & Availability
provides high Availability by delivering content from a distributed global network of edge locations. Amazon also constantly monitors the network paths connecting Origin servers to CloudFront
does not provide durable storage, which is more of the responsibility of the underlying Origin server providing the content for e.g. S3
Cost Model
has pay-as-you-go pricing with two main components:
regional data transfer out (per GB) and
requests (per 10,000)
Flat-Rate Pricing Plans (launched Nov 2025) — combine CloudFront CDN, AWS WAF, DDoS protection, bot management, Route 53 DNS, CloudWatch Logs, edge compute, and S3 storage credits into one monthly price with no overage charges
Scalability & Elasticity
provides seamless scalability & elasticity by automatically responding to the increase or the decrease in the demand
Edge Compute
CloudFront Functions — lightweight functions for high-scale, latency-sensitive request/response transformations (URL rewrites, header manipulation, redirects) executed at 750+ PoPs
Lambda@Edge — more powerful compute triggered at regional edge caches for complex logic (authentication, dynamic origin selection, content generation)
CloudFront KeyValueStore (launched 2023) — globally distributed, low-latency data store for CloudFront Functions enabling dynamic configuration (A/B testing, feature flags, geo-routing) without code redeployment
Security
Origin Access Control (OAC) — recommended method to restrict S3 origin access to CloudFront only, replacing the legacy Origin Access Identity (OAI). OAI creation was deprecated in 2024; new distributions since March 2026 can only use OAC.
AWS Shield Standard — included automatically with every CloudFront distribution for DDoS protection at no extra cost
AWS WAF integration — protect against web exploits and bots at the edge
Field-Level Encryption — encrypt sensitive data fields at the edge before forwarding to origin
is a fully managed, serverless caching service that makes it easy to deploy, operate, and scale distributed in-memory caches in the cloud
helps improves performance of the applications by allowing retrieval of data from fast, managed, in-memory caching system with microsecond latency and up to 99.99% availability SLA
supports three open-source caching engines:
Valkey (recommended for new workloads) — open-source fork of Redis OSS 7.2, stewarded by the Linux Foundation (BSD-3 licensed)
Memcached — simple object caching engine
Redis OSS — key-value store (note: Redis OSS 7.2 is the last fully open-source Redis version)
🆕 Valkey Engine (Oct 2024): AWS recommends Valkey for new workloads. It provides 33% lower Serverless pricing and 20% lower node-based pricing compared to Redis OSS, with better performance and active open-source development. Valkey is a drop-in replacement for Redis OSS 7.2 and can be upgraded in-place.
Deployment Modes
ElastiCache Serverless (launched Nov 2023)
zero infrastructure management with instant auto-scaling
pay-per-use pricing based on data stored (GB-hour) and ElastiCache Processing Units (ECPUs)
creates a cache in under a minute; starts as low as $6/month with Valkey
zero downtime maintenance
Node-based (self-designed clusters)
fine-grained control over node type, count, and placement
supports Reserved Nodes for cost savings
Graviton3-based nodes available for better price-performance
Ideal Usage Patterns
improving application performance by storing critical data in-memory for low latency access
use cases involve usage as a database front end for read heavy applications, improving performance and reducing load on databases, or managing user session data, cache dynamically generated pages, or compute intensive calculations etc.
Real-time search (2026) — full-text, exact-match, numeric range, and hybrid search with microsecond latency
Vector similarity search — AI-driven semantic retrieval for RAG and recommendation systems
Anti-Patterns
Persistent Data
If the application needs fast access to data coupled with strong data durability, Amazon DynamoDB would be a better option
Note: ElastiCache for Valkey now supports durability with Multi-AZ transactional log (June 2026), enabling fast failover and data recovery without data loss
Performance
provides microsecond read latency and single-digit millisecond write latency with throughput up to millions of requests per second
Valkey 9.0 (May 2026) introduces enhanced search capabilities with full-text, hybrid, and aggregation queries directly in the cache
Durability & Availability
provides up to 99.99% availability SLA with Multi-AZ deployments
With the Memcached engine
all ElastiCache nodes in a single cache cluster are provisioned in a single Availability Zone.
ElastiCache automatically monitors the health of your cache nodes and replaces them in the event of network partitioning, host hardware, or software failure.
In the event of cache node failure, the cluster remains available, but performance may be reduced due to time needed to repopulate the cache in the new “cold” cache nodes.
To provide enhanced fault-tolerance for Availability Zone failures or cold-cache effects, you can run redundant cache clusters in different Availability Zones.
With the Valkey/Redis OSS engine,
ElastiCache supports replication to up to five read replicas for scaling. To improve availability, you can place read replicas in other Availability Zones.
ElastiCache monitors the primary node, and if the node becomes unavailable, ElastiCache will repair or replace the primary node if possible, using the same DNS name.
If the primary cache node recovery fails or its Availability Zone is unavailable, primary node can be failed over to one of the read replicas with an API call.
Durability support (June 2026): Multi-AZ transactional log enables data persistence across AZs, preventing data loss during failover, recovery, and node restarts.
Cost Model
offers two pricing models:
Serverless: pay-per-use based on data stored (GB-hour) and ECPUs consumed. Valkey Serverless is 33% cheaper than Redis OSS Serverless.
Node-based: pricing per cache node-hour consumed. Supports Reserved Nodes for up to 55% savings.
Scalability & Elasticity
ElastiCache is highly scalable and elastic.
Serverless: instantly auto-scales to match application demand with no capacity planning
Node-based: Cache nodes can be added or deleted from the cache cluster. Auto Discovery enables automatic discovery of Memcached cache nodes by ElastiCache Clients when the nodes are added to or removed from an ElastiCache cluster.
