A CloudFront invalidation removes cached objects from every Amazon CloudFront cache layer before their TTL expires. As of 2026, AWS includes the first 1,000 invalidation paths per AWS account each month and charges $0.005 for each additional path. A wildcard path such as /images/product-42* counts as one path, no matter how many objects it matches.
The invoice line is rarely the real problem. An invalidation is a deliberate cache miss across the distribution, subject to in-progress limits and with no published completion SLA. This guide covers the exact path and wildcard rules, realistic completion times, a worked cost model for four deploy patterns, a decision matrix for invalidation versus versioned URLs, and a failure-mode table you can use during an incident.
An invalidation is an asynchronous request scoped to one distribution. You submit a batch of paths with a unique CallerReference through the CreateInvalidation API, the console, or infrastructure tooling. CloudFront returns an invalidation ID with status InProgress, which later changes to Completed. After that, the next request for a matching object misses at the edge, the regional edge cache and Origin Shield, and is fetched from origin.
Three behaviors catch experienced teams. First, invalidating a path removes every header and cookie variant stored under it by your cache policy. Query string variants are different: they are matched only through the path you submit. Second, invalidation has no effect on browser caches or downstream proxies, so an unversioned file served with a long max-age stays stale on clients regardless of the edge. Third, a CallerReference must be unique per request. Reusing one with a different path list returns an InvalidationBatchAlreadyExists error, so a Git SHA alone fails when a deploy is retried with changes.
The asterisk must be the last character of the path, paths are case-sensitive, and each wildcard path counts as one billable path. A distribution can have at most 15 wildcard paths and 3,000 individual file paths in progress at the same time. The table below shows how common path shapes behave.
| Path submitted | What it matches | Billed as |
|---|---|---|
| /index.html | That object, all header and cookie variants | 1 path |
| A single slash | The root URL served through the default root object; a separate cache entry from /index.html | 1 path |
| /search.json* | The object and every query string variant | 1 path |
| /products/SKU-123* | Everything starting with that string, including SKU-1234 and SKU-12399 | 1 path |
| /products/SKU-123/ followed by an asterisk | Only objects inside that directory prefix | 1 path |
| A single slash followed by an asterisk | The entire distribution | 1 path |
| /img/hero*.png | Rejected: the asterisk is not the last character | n/a |
A prefix wildcard without a trailing slash over-matches, so always end directory-scoped wildcards with the slash before the asterisk.
CloudFront has not offered native cache-tag or surrogate-key purging, so check current AWS documentation before planning around it. The only scoping tool is the path itself. If you need to purge one product, one tenant or one release, put that identifier in a directory segment (tenant, then product, then asset) so one wildcard covers it exactly. Retrofitting this after launch means a URL migration, which is why it belongs in the initial design review.
AWS publishes no completion SLA for invalidations. In recent years, most invalidations have completed in roughly one to a few minutes; treat that as an estimate rather than a guarantee. Older guidance quoted 10 to 15 minutes, and long tails still happen. Pipelines should poll the invalidation status rather than sleep for a fixed time.
Two behaviors influence timing. Objects become fresh at different edges at different moments while a request is InProgress, so for a short window some users see new content and some see old content. Queueing also adds delay: when the distribution already has wildcard paths in flight, new requests wait or fail with TooManyInvalidationsInProgress. Treat Completed as the only reliable signal, and gate cache-dependent smoke tests on it.
CloudFront invalidation cost is $0.005 per path after the first 1,000 paths each month, and that allowance is shared across every distribution in the AWS account, as of 2026. A path is billed when submitted, whether it matches one object, a million objects or none. The model below applies that rate to four deploy patterns, assuming 300 deploys a month (about 10 a day).
| Pattern | Paths per month | Billable paths | Monthly cost |
|---|---|---|---|
| A: every changed file listed, 400 per deploy | 120,000 | 119,000 | $595.00 |
| B: one directory wildcard per deploy | 300 | 0 | $0.00 |
| C: hashed assets, 5 HTML and manifest paths per deploy | 1,500 | 500 | $2.50 |
| D: 40 tenant distributions, 25 deploys each, 20 paths per deploy | 20,000 | 19,000 | $95.00 |
Listing files individually costs about 240 times as much as the hashed-asset hybrid in this model, while the per-account allowance is what makes multi-tenant setups more expensive than expected.
Pattern B looks cheapest, but it shifts the cost to origin. A wildcard purge forces every hot object to be fetched again. If the hot working set is 2 TB on a non-AWS origin with egress priced near $0.05 to $0.09 per GB (an estimate), each full purge costs roughly $100 to $185 in origin egress, plus a spike in origin requests. For scale, AWS WAF list pricing of $5 per web ACL, $1 per rule and $0.60 per million inspected requests puts 500 million monthly requests across 15 rules near $320. That makes invalidation fees small by comparison. Optimize invalidations mainly for hit ratio, not for the path fee.
| Factor | Invalidation | Versioned URLs |
|---|---|---|
| Best for | HTML entry points, robots.txt, sitemap.xml, manifest.json, API responses | JS, CSS, images, fonts, binaries, video segments |
| Time to fresh | Minutes, no SLA, inconsistent while InProgress | Immediate once the referencing HTML updates |
| Browser caches | Unaffected | Bypassed by the new URL |
| Cache impact | Hit ratio dip and origin spike | Old version stays warm |
| Rollback | Another purge | Point HTML back to the previous hash |
| Cost | $0.005 per path after 1,000 a month | No invalidation charge; extra storage for old builds |
Versioned URLs should handle every asset that HTML references, while invalidation should be limited to the small set of URLs that must keep a stable name.
| Symptom | Cause | Confirm | Fix |
|---|---|---|---|
| Deploy fails with TooManyInvalidationsInProgress | More than 3,000 file paths or 15 wildcard paths in flight, common in monorepos | ListInvalidations shows several InProgress | Batch by service, use scoped wildcards, serialize requests |
| Users see old JS after Completed | Unversioned file with long browser max-age | Edge returns a Miss and a low Age, but the client still serves from cache | Hash filenames |
| Root URL stale, /index.html fresh | Separate cache entries | Compare Age on both URLs | Invalidate both paths |
| Unrelated products miss after a purge | Prefix wildcard without a trailing slash | Origin logs show refetches on neighboring IDs | Add the trailing slash |
| Maintenance page persists after recovery | Failover or error response cached under the normal key | X-Cache shows a Hit with a rising Age | Send no-store on maintenance responses, lower the error caching TTL, purge on recovery |
| Origin saturates after deploy | Root wildcard on a large hot set | CacheHitRate dips and origin latency rises | Scope purges and enable Origin Shield |
Most invalidation incidents are path-design problems, not CloudFront faults, and the response headers usually show which one you are dealing with.
The hybrid pattern suits any team with a build step and a front end that references hashed assets. It is a poor fit for CMS-driven sites with stable URLs and frequent editorial changes. Those sites need short TTLs and stale-while-revalidate, or a CDN with tag-based purge.
Teams whose invalidation volume comes from large static files (installers, game patches, video libraries) can move that traffic to a separate delivery layer. BlazingCDN includes purge and cache warm-up through its REST API on every plan, with no request fees. It can run behind DNS next to an existing CloudFront distribution, as outlined in the BlazingCDN and Amazon CloudFront comparison. It is a delivery layer only: keep AWS WAF and Shield in front of dynamic traffic.
A CloudFront invalidation costs nothing for the first 1,000 paths each month and $0.005 per path after that, as of 2026. The allowance applies per AWS account, not per distribution. A deploy that lists 400 files 300 times a month pays about $595, while a hashed-asset pipeline that purges five paths per deploy pays about $2.50.
Yes, a CloudFront invalidation wildcard is billed as one path, whether it matches one object or the whole distribution. The asterisk must be the last character, and only 15 wildcard paths can be in progress per distribution at once. Because a prefix without a trailing slash also matches neighboring names, scope wildcards to directory prefixes.
CloudFront cache invalidation usually completes within roughly one to a few minutes, but AWS publishes no completion SLA. While a request is InProgress, some edges serve new content and others serve old content. Deploy pipelines should poll the invalidation status until it reads Completed before running cache-dependent smoke tests, rather than sleeping for a fixed interval.
No, a CloudFront invalidation clears only CloudFront caches, including regional edge caches and Origin Shield. Browsers and corporate proxies keep their copies until their own max-age expires. For this reason, assets with long browser TTLs need versioned filenames: only a new URL reliably forces clients to fetch the updated file after a deploy.
CloudFront has not offered native cache-tag or surrogate-key purging, so invalidation works by path only. Check current AWS documentation before designing around it. The practical workaround is to put the purge scope (tenant, product or release) in a directory segment of the URL, so that one wildcard path removes exactly that group of objects.
This week, export the last 30 days of invalidation requests for each distribution. Count paths per deploy and sort each path into one of three groups: HTML entry point, unversioned config file, or an asset that should have been hashed. Then compare CacheHitRate in the 15 minutes after each deploy with the daily baseline. The third group, together with the hit ratio dip, tells you what your current pattern really costs.
If the audit shows that most of the purge and refill churn comes from large static files, BlazingCDN offers a 14-day testing period on real production traffic at $5 per TB, with the monthly minimum waived. You can start a BlazingCDN testing period for your static assets and compare the results side by side.