aws-cloudformation
AWS::CloudFront::Distribution DefaultCacheBehavior cache policy should use name identifiers
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. There is a list of managed cache policies such as CachingDisabled or CachingOptimized.
So how do I specify for example CachingOptimized in my CloudFormation template? Do I simply indicate the name of the cache policy from a restricted vocabulary?
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:
DefaultCacheBehavior:
CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6 #CachingOptimized
Why? Why? Why? 🤦♂️
Most other CloudFormation values use name tokens. For example:
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. 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
Part of what is frustrating about this thing is that apparently nobody at Amazon realized the need for a "conventions" document to guide those implementing CloudFormation at AWS. I understand there are a lot of teams working on AWS. There should be a document indicating best practices and conventions, if nothing else just to promote consistency.
Instead CloudFormation is full of one-off decisions. Sometimes we reference resources using their ARN. Sometimes we reference resources by their ID. Sometimes we reference things by their name. (See related issues #1584 and #1591.)
Could you please pass feedback to the team that guides AWS as a whole that they should provide some conventions guidance to all the rest of the teams to try to bring more consistency to CloudFormation?
To add insult to injury, we can't even fully use mappings to the token names provides.
If we attempt to "patch" CloudFormation and provide a canonical mapping for use across the team:
Mappings:
CloudFront:
ManagedCachedPolicyIds:
Amplify: 2e54312d-136d-493c-8eb9-b001f22f67d2
CachingDisabled: 4135ea2d-6df8-44a3-9df3-4b5a84be39ad
CachingOptimized: 658327ea-f89d-4fab-a63d-7e88639e58f6
CachingOptimizedForUncompressedObjects: b2884449-e4de-46a7-ac36-70bc7f1ddd6d
Elemental-MediaPackage: 08627262-05a9-4f76-9ded-b50ca2e3a84f
ManagedOriginRequestPolicyIds:
AllViewer: 216adef6-5c7f-47e4-b989-5492eafa07d3
AllViewerAndCloudFrontHeaders-2022-06: 33f36d7e-f396-46d9-90e0-52428a34d9dc
AllViewerExceptHostHeader: b689b0a8-53d0-40ab-baf2-68738e2966ac
CORS-CustomOrigin: 59781a5b-3903-41f3-afcb-af62929ccde1
CORS-S3Origin: 88a5eaf4-2fd4-4709-b370-b4c650ea3fcf
Elemental-MediaTailor-PersonalizedManifests: 775133bc-15f2-49f9-abea-afb2e0bf67d2
UserAgentRefererHeaders: acba4595-bd28-49b8-b9fe-13317c0390fa
Then we get errors like this:
An error occurred (ValidationError) when calling the CreateChangeSet operation: Template format error: Mappings attribute name 'Elemental-MediaPackage' must contain only alphanumeric characters.
Sure, I know how to work around that by switching to e.g. ElementalMediaPackage, but that defeats the purpose of having a canonical mapping that exactly matches the documentation (providing yet another opportunity for error, raising the learning curve, slowing down development, etc.). Moreover it's adding workarounds to workarounds.
Has there been any resolution/alternative to this? or an official response from AWS Support.
