aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap
AWS::CloudFront::Distribution DefaultCacheBehavior cache policy should use name identifiers
- Dominant language
- No language data
- Stars
- 1.1k
- Forks
- 62
- PR merge metrics
- No merged PRs in 30d
Description
### Name of the resource
AWS::CloudFront::Distribution
### Resource name
_No response_
### Description
For a CloudFront distribution, I have to specify the `DefaultCacheBehavior`. The recommended way it so specify an existing cache policy using [`CachePolicyId`](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-defaultcachebehavior.html#cfn-cloudfront-distribution-defaultcachebehavior-cachepolicyid). There is a [list of managed cache policies](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-cache-policies.html#managed-cache-policies-list) such as `CachingDisabled` or `CachingOptimized`.
So how do I specify for example [`CachingOptimized`](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-cache-policies.html#managed-cache-caching-optimized) in my CloudFormation template? Do I simply indicate the name of the cache policy from a restricted vocabulary?
```yaml
DefaultCacheBehavior:
CachePolicyId: CachingOptimized
```
No! That would be too simple. And it would be consistent with 99.9% of the rest of CloudFormation. And it would be easy to read. And it would be easy to verify. And it would be hard to make mistakes.
Instead (if I'm reading the docs correctly), we have to go find some opaque, error-prone string such as `658327ea-f89d-4fab-a63d-7e88639e58f6` and use that value:
```yaml
DefaultCacheBehavior:
CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6 #CachingOptimized
```
Why? Why? Why? 🤦♂️
Most other CloudFormation values use name tokens. For example:
```yaml
ViewerCertificate:
AcmCertificateArn: !Ref DomainCertificate
MinimumProtocolVersion: TLSv1.2_2021
SslSupportMethod: sni-only
```
Can you imagine if we had to go look up some opaque ID string for `TLSv1.2_2021`? Or for `sni-only`?
As a developer, if I'm reviewing someone's code (maybe even my own code) and I see `658327ea-f89d-4fab-a63d-7e88639e58f6 #CachingOptimized`, how do I know that's really the unique ID for `CachingOptimized`? Maybe someone (maybe me!) accidentally copied the ID string from the wrong section of the documentation. Or maybe it was correct to begin with, but someone updated it and forgot to the change the comment. What's the actual cache behavior? Who knows? Only a computer.
As I mentioned 99.9% (a rhetorical value) of CloudFormation uses named IDs. Why, why, why did someone decide, "oh, let's do it different in this case, just to throw people off".
I highly recommend that you deprecate `CachePolicyId` and introduce a `CachePolicyName` that accepts one of the names you _already have documented_ at [Available managed cache policies](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-cache-policies.html#managed-cache-policies-list). They are even already in token form. I expect there is no downside on the AWS side (surely it's not hard to do a lookup), but there are multiple big downsides for the developer for doing it they way it's being done now.
### Other Details
_No response_
Contributor guide
Research direction
The issue identifies no repository files, tests, or implementation entry points. Start with the linked CloudFront DefaultCacheBehavior and managed cache policy documentation; done would require an AWS-supported name-based cache-policy option or a maintainer decision on the request.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 25/100