aws-amplify / aws-amplify/amplify-hosting

On demand Cloudfront Cache Invalidation

Open
#3,967 6 comments 25 reactions 0 assignees View on GitHub
feature-request
Dominant language
Dockerfile
Stars
481
Forks
123
PR merge metrics
No merged PRs in 30d

Description

### Before opening, please confirm:

- [X] I have checked to see if my question is addressed in the [FAQ](https://github.com/aws-amplify/amplify-hosting/blob/master/FAQ.md).
- [X] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-hosting/issues?q=is%3Aissue+).
- [X] I have removed any sensitive information from my code snippets and submission.

### Amplify Hosting feature

Build settings, Frontend builds

### Is your feature request related to a problem? Please describe:

In an AWS Amplify Generation 2 environment, Amplify uses CloudFront under the hood for content delivery. There is an option within Amplify called "Keep cookies in cache key" which the development team has disabled.

The primary reason for disabling this option is that on every page load, cookies like Google Tag Manager (GTM) and Datadog generate different values. Including these cookies in the cache key would prevent effective caching, as CloudFront would treat each unique cookie value as a separate cache entry.

When a new build is generated in Amplify, CloudFront's cache is automatically invalidated, ensuring that users receive the most recent content. However, when content is updated within the Content Management System (CMS), there is no mechanism to invalidate the CloudFront cache without running a new build. This limitation exists because Amplify Generation 2 does not provide direct access to the underlying CloudFront distribution, making it impossible to programmatically invalidate the cache in response to CMS changes.

### Describe how you'd like this feature to work

Is it possible within AWS Amplify Generation 2 to specify specific cookie names to include in the CloudFront cache key, similar to native CloudFront configurations?

Are there alternative methods to invalidate the CloudFront cache upon CMS content changes without initiating a new build?

What best practices can be employed to manage cache invalidation in this scenario to balance performance and content freshness?

Contributor guide

Open the contributing guide

Research direction

The issue names no files, tests, or entry points. Start by reviewing AWS Amplify Generation 2 hosting configuration and the described CloudFront cache behavior; done would require a decided, implementable way to configure cookie cache keys or trigger invalidation after CMS changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.