Busca en todas las páginas de la documentación
CloudFront is not a server you deploy code to. It is a globally distributed cache that sits in front of an origin you already have - an S3 bucket, an Application Load Balancer, an API Gateway, or any HTTP server - and answers requests from whichever edge location is closest to the viewer.
Understanding where CloudFront sits in the request path, and what decides whether a request is answered at the edge or forwarded to your origin, is the foundation for everything you do with the SDK. This page maps the objects, the cache key, and the request lifecycle before later pages show the API calls that create them.
The top-level object is a distribution. It has a domain name (like d111111abcdef8.cloudfront.net), a set of origins it can pull from, and a list of cache behaviors that route requests. When you create a distribution with the SDK you pass a DistributionConfig, and every concept below is a field inside it.
An origin is where the real content lives. A distribution can have several, and each is identified by an Id you choose. Common origins are an S3 bucket (locked down so only CloudFront can read it via an Origin Access Control), an ALB or EC2 host (a custom origin), or an API endpoint.
A cache behavior connects a URL path pattern to an origin and a set of rules. The DefaultCacheBehavior matches everything; additional CacheBehaviors match specific patterns like /images/* or /api/* and are evaluated most-specific-first. Each behavior decides which HTTP methods are allowed, whether the viewer is redirected to HTTPS, and - crucially - which cache policy and origin request policy apply.
The edge location is the physical point of presence that terminates the viewer's connection. There are hundreds worldwide. A smaller set of regional edge caches sit between the edges and your origin as a second cache tier, so a miss at one edge can still be a hit at the regional layer instead of reaching your origin.
When a request arrives, the edge location runs a fixed lifecycle.
Cache-Control (or the behavior's TTL settings) decides how long the edge may store it.The cache key is the heart of the model. By default it is just the request path, but a cache policy can add specific query-string parameters, headers, and cookies to it. This is the trade-off you tune constantly: a narrow key (path only) maximizes hits but cannot vary responses; a wide key (path plus Accept-Language plus a ?v= parameter) varies responses correctly but splits one object into many cached copies.
A subtle but important distinction: the cache key controls what makes an object unique at the edge, while the origin request policy controls what is forwarded to the origin. A value can be forwarded without being in the cache key (so the origin sees it but it does not fragment the cache) or be in the key without changing routing. Keeping these two ideas separate prevents most caching bugs.
Managed policies replaced ForwardedValues. Older distributions controlled the cache key and forwarded fields inline through a ForwardedValues block on the cache behavior. That approach is legacy. Modern behaviors reference a cache policy (CachePolicyId) and an origin request policy (OriginRequestPolicyId) by id. AWS ships managed ones - for example CachingOptimized and CachingDisabled - that you can attach without defining your own. When you create a distribution via the SDK today, you set these policy ids rather than a ForwardedValues object; mixing the two on one behavior is invalid.
TTLs and Cache-Control interact. A behavior has MinTTL, DefaultTTL, and MaxTTL. If the origin sends Cache-Control: max-age=..., CloudFront honors it, clamped between MinTTL and MaxTTL. If the origin sends no cache directives, DefaultTTL applies. Setting MinTTL and MaxTTL to 0 effectively disables edge caching - which is what the managed CachingDisabled policy does for dynamic, per-user responses.
Freshness is not the same as invalidation. When a TTL expires the object is not deleted; it becomes stale and the edge revalidates with the origin on the next request. To force removal before the TTL expires you issue an invalidation (covered in its own page), or - better for versioned assets - you change the URL so the new content has a new cache key.
Distributions are eventually consistent. Creating or updating a distribution returns quickly, but the change propagates to every edge over some minutes; the distribution reports InProgress until Deployed. Automation should not assume a config change is live the instant the API call returns.
The practical mental model: picture one distribution fanning requests across hundreds of edges, each edge keying objects by a cache key you design, pulling from origins through a policy you choose, and holding responses for a TTL the origin negotiates. Every SDK call in this section either creates one of those objects or changes how the key is built.
CachePolicyId and OriginRequestPolicyId; new work should use managed or custom policies.InProgress until Deployed.The top-level object that has a domain name, one or more origins, and the cache behaviors that route requests. You create it by passing a DistributionConfig to the SDK.
The real source of content behind CloudFront - an S3 bucket, an ALB, an EC2 host, or any HTTP endpoint. A distribution can have several origins, each with an id you reference from cache behaviors.
A rule that maps a URL path pattern to an origin plus caching settings. The default behavior matches everything; additional behaviors match patterns like /api/* and are evaluated most-specific-first.
The value CloudFront uses to decide whether two requests are for the same cached object. By default it is the path; a cache policy can add specific query strings, headers, and cookies.
A cache policy controls what goes into the cache key (what makes an object unique at the edge). An origin request policy controls what is forwarded to the origin. A field can be forwarded without being in the key.
Because each distinct key is a separate cached object. Adding a header or query parameter to the key multiplies the number of copies the edge must store and fill, so fewer requests find an existing copy.
Managed and custom cache policies (CachePolicyId) and origin request policies (OriginRequestPolicyId). ForwardedValues is legacy and cannot be combined with a policy id on the same behavior.
The origin's Cache-Control: max-age is honored, clamped between the behavior's MinTTL and MaxTTL. With no origin directive, DefaultTTL applies. Zero min and max effectively disable edge caching.
No. The object becomes stale and is revalidated with the origin on the next request. To remove it early, issue an invalidation or change the object's URL.
A create or update call returns quickly, but the change propagates to all edges over several minutes. The distribution reports InProgress until it becomes Deployed.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 23 jul 2026