AWS 167: Amazon CloudFront
Why this lesson matters
Design edge caching around distributions, origins, behaviors, cache keys, origin requests, TLS, signed access, invalidations, logs, and origin protection.
CloudFront is a global HTTP content-delivery network and reverse proxy. It terminates viewer connections at edge locations, applies behavior/security logic, serves a cache hit or sends an origin request. Correct design separates viewer request, cache key and origin request; forwarding a value does not always mean varying the cache by it.
What you will be able to do
By the end, you can:
- explain amazon cloudfront in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Design edge caching around distributions, origins, behaviors, cache keys, origin requests, TLS, signed access, invalidations, logs, and origin protection. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon CloudFront. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon CloudFront. |
| Cost model | Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design. |
| Safe rejection rule | Avoid forwarding every cookie, query, and header by default or making an S3 origin public when OAC can authorize it. |
How the request flows
+----------------------+
| Viewer request |
+----------------------+
|
v
+-------------------------------+
| Edge behavior and cache key |
+-------------------------------+
|
v
+---------------------------------+
| Cache hit or protected origin |
+---------------------------------+
|
v
+---------------------------------------------+
| Response headers, logs, and cache metrics |
+---------------------------------------------+For Amazon CloudFront, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon CloudFront. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon CloudFront. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use CloudFront for global HTTP delivery, caching, edge security, and origin protection. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid forwarding every cookie, query, and header by default or making an S3 origin public when OAC can authorize it. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
Distribution request path
viewer DNS -> nearest CloudFront edge -> TLS/SNI and alternate-domain validation -> WAF/viewer function -> ordered cache behavior match -> cache-key lookup -> regional/edge cache -> origin request policy/function -> origin/OAC/VPC origin -> response -> response-headers policy -> cache/viewer. Behaviors match path patterns in priority order, then define origin, viewer protocol, allowed/cached methods, cache/origin policies, compression, functions, signed access and logging.
A cache policy chooses TTL bounds and which headers/cookies/query strings vary the cache key. High-cardinality or user-specific values destroy hit ratio and can leak data if omitted when response truly varies. An origin request policy forwards additional values without adding them to the key. Values in the cache key are also forwarded. Normalize or reject equivalent query/cookie forms before lookup where safe. Never cache authenticated/private responses until Cache-Control, key and tenant/session variation are proven.
CloudFront uses freshness headers within behavior limits, conditional requests and stale/error behavior according to configuration. Age measures cached response age; X-Cache/cache status supports hit/miss/error interpretation. Invalidations remove cached paths at cost/limits but do not fix browser caches and wildcard invalidation can be expensive; prefer versioned asset names. Origin Shield can reduce multi-edge origin load at additional cost. Origin groups can fail over for supported status/method behavior but do not replicate origin data.
Origins and access
For private S3 origins, use Origin Access Control with SigV4 and a bucket policy scoped to the distribution; block public access remains enabled. Website endpoints are custom origins and do not support OAC like the S3 REST endpoint. Existing OAI estates require planned migration. ALB/API/custom origins should restrict direct bypass using VPC origins where currently supported or secret headers/security controls plus network policy; rotate secrets and understand unsupported origin types/features.
Viewer certificates for alternate names come from ACM in us-east-1 (or uploaded IAM certificate legacy paths) and must cover every alias. Origin TLS is separate and validates the configured origin hostname/certificate. Choose minimum viewer TLS/security policy and HTTP versions from client requirements. Signed URLs/cookies use trusted key groups for private content and must handle expiry/key rotation; they do not encrypt content beyond HTTPS.
CloudFront Functions run lightweight JavaScript at viewer request/response with strict limits and very low latency. Lambda@Edge supports heavier request/response logic at viewer/origin phases with Region/version/deployment restrictions. CloudFront KeyValueStore can support current function use cases. Select from required runtime, network/body access, execution phase and cost; edge code must be versioned, tested and fail-safe.
Standard logs and real-time logs differ in latency, fields and cost. Monitor requests/bytes, hit ratio, origin latency, 4xx/5xx, function errors, WAF and origin health. Continuous deployment can split selected traffic to a staging distribution; primary and staging caches are separate, so compare enough warmed traffic and rollback policy.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open CloudFront, Distributions; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws cloudfront list-distributions --query 'DistributionList.Items[].{Id:Id,Status:Status,Enabled:Enabled,Domain:DomainName,Origins:Origins.Quantity,PriceClass:PriceClass}' --output table
aws cloudfront list-cache-policies --type managed --query 'CachePolicyList.Items[].CachePolicy.CachePolicyConfig.Name' --output tableExpected interpretation
Deployed means configuration reached the edge. It does not prove cache-hit behavior, correct cache key, origin authorization, viewer TLS, or content correctness.
Practical work
Design CloudFront for static assets and /api/*. Define origins, OAC, behaviors, methods, cache and origin-request policies, cookies and headers, TTLs, compression, TLS, WAF, logs, invalidation, and error handling.
Build a cache-key truth table for language, device, auth, query and cookies; mark forward/key/drop. Test two users for cache isolation, query reordering, stale versioned asset, OAC direct-S3 denial, direct-origin bypass, origin TLS hostname failure, 403 from signed access versus S3/WAF, origin timeout, origin failover method, function error and continuous-deployment rollback. Calculate request, regional transfer, egress, invalidation, Origin Shield, function and log costs.
Diagnose this topic from its own evidence
Capture viewer request ID, DNS, certificate, behavior, cache status/Age, WAF action, origin request ID/log and object/version. A CloudFront 403 can be alternate domain, WAF, signed URL, geographic restriction or origin access; 502 often means origin DNS/TLS/protocol; 504 means origin connection/response timeout; stale/wrong content requires cache key/TTL/invalidation and origin version. Compare from two viewers and direct origin only when authorized - never make S3 public to diagnose OAC.
Cost and cleanup
Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Design edge caching around distributions, origins, behaviors, cache keys, origin requests, TLS, signed access, invalidations, logs, and origin protection.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon CloudFront.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon CloudFront.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid forwarding every cookie, query, and header by default or making an S3 origin public when OAC can authorize it.
- Which cost dimensions and retained resources need an owner?
Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Lesson acceptance
Pass when the learner traces viewer/cache/origin paths, designs safe keys and forwarding, secures S3/custom/VPC origins, handles TLS/private content/edge code, and proves hit/miss/error/rollback from logs. Fail if every header enters the cache key, authenticated responses share cache unsafely, invalidation replaces versioning, or CloudFront is confused with DNS or TCP acceleration.