Editorial illustration.
Originally published 16 June 2023; rewritten and reviewed on 15 October 2026.
A deployment completes, but visitors still receive an older asset. The immediate temptation is to invalidate everything. I would first establish which object changed, which distribution serves it and whether versioned asset names would make the next deployment simpler.
Choose versioning or invalidation deliberately
Versioned filenames let a new deployment reference a new object while older pages can still use their existing asset. Invalidation is useful when a stable path must stop serving its cached representation. The two approaches solve related but different problems.
Keep requested paths as narrow as the deployment permits. A folder wildcard and one file are different scopes; review the path before submitting a broad request.
Give the request an operation identity
A C# AWS SDK fragment using a configured client might be:
var request = new CreateInvalidationRequest
{
DistributionId = distributionId,
InvalidationBatch = new InvalidationBatch
{
CallerReference = deploymentOperationId,
Paths = new Paths
{
Quantity = 1,
Items = new List<string> { "/assets/app.js" }
}
}
};
var result = await cloudFront.CreateInvalidationAsync(request);
The caller supplies the correct distribution and a stable unique reference for this operation. Reuse that reference deliberately for the same request when applying the provider’s retry semantics. Configure credentials through the deployment environment rather than embedding them in the snippet.
Verify completion and the served object
Record the invalidation identifier and inspect its status through the supported API. An accepted invalidation is not the same as immediate completion at every edge location.
Then request the expected asset and verify its version. Keep the deployment record linked to the invalidation so a future investigation can explain why a cache change was made. Returning a boolean without the operation reference makes the next failure harder to diagnose.