Time to Live

Time to Live, usually abbreviated TTL, defines a lifetime for a piece of data. In caching, it commonly specifies how long a stored response can be reused without checking its source. Other systems express TTL as an expiration timestamp rather than a duration. Always identify what expires, when the lifetime begins, and what the system does after expiration. Expiration might trigger revalidation, make an entry unavailable, or schedule asynchronous deletion; these are different behaviors.

For cloud content delivery, TTL determines how long an edge cache can consider an object fresh. A long TTL reduces origin requests, improves response latency, and helps absorb traffic spikes. A short TTL makes updates visible sooner but increases origin traffic and can expose backend capacity problems. Content-addressed static files, such as application.a81f.js, can usually tolerate long cache lifetimes because a changed file receives a new URL. Frequently updated HTML or configuration documents generally need shorter lifetimes or explicit revalidation.

HTTP origins communicate freshness through response headers. Cache-Control: max-age=300 specifies a freshness lifetime of 300 seconds. Cache-Control: s-maxage=3600 gives shared caches, such as a CDN, a separate lifetime and takes precedence over max-age for those caches. Expires provides an absolute expiration time when an applicable Cache-Control freshness directive is absent. For example, max-age=60, s-maxage=600 allows a browser freshness lifetime of one minute while a shared cache can use ten minutes, subject to its configured policies.

Amazon CloudFront applies minimum, default, and maximum TTL settings through cache policies. The default applies when the origin supplies no applicable freshness information; the minimum and maximum constrain the lifetime CloudFront derives from origin headers. A critical troubleshooting detail is that a minimum TTL greater than zero causes CloudFront to cache content for at least that interval even when the origin sends no-cache, no-store, or private. For sensitive or user-specific responses, use a configuration that actually prevents inappropriate caching rather than assuming an origin header alone is sufficient.

Expiration does not necessarily mean that cached bytes are immediately deleted or that the next request downloads the entire object. A cache can revalidate a stale response using ETag or Last-Modified validators. If the origin returns 304 Not Modified, the existing representation can be reused with refreshed freshness information. Explicit stale-serving directives can also permit reuse after freshness expires. Conversely, a cache can evict an object before its TTL ends because of capacity management, so TTL is not a guaranteed residency period.

When troubleshooting stale content, inspect the viewer response and the origin response, including Cache-Control, Expires, Age, and CloudFront's X-Cache header. Verify which cache behavior and cache policy match the request. Check whether the cache key distinguishes required query strings, headers, or cookies: a short TTL cannot correct a key that combines different representations. Cached error responses also have expiration controls, so a fixed origin can still appear broken while an earlier error remains cached.

Updating an origin object does not automatically replace copies already cached at the edge or in browsers. For an urgent correction, use CDN invalidation or publish a new versioned URL. CloudFront invalidation does not clear browser caches, and lowering a configured TTL should not be treated as an immediate purge. Also distinguish freshness problems from connectivity failures: changing an object TTL does not repair routing, TLS, or origin access permissions.

The same lifetime principle appears in DNS caching, application caches, and database record expiration, but their guarantees differ. DNS TTL controls resolver reuse, whereas a database TTL feature may delete expired records asynchronously. The IP packet field also called TTL is different: in modern IP forwarding, it effectively limits router hops rather than defining a cache freshness duration.