aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap

AWS::CloudFront::Distribution DefaultCacheBehavior cache policy should use name identifiers

Open
#1,602 3 comments 1 reaction 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.