aws-amplify / aws-amplify/amplify-hosting
On demand Cloudfront Cache Invalidation
- 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
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