cloudformation-coverage-roadmap
cloudformation-coverage-roadmap copied to clipboard
aws-cloudformation
AWS::EC2::VPCEndpoint - Tags
I can't believe that this issue still exists in 2021... no support for tags via cloudformation, seriously? No wonder Terraform is more popular
Roadmap update? Consistent tagging is a critical capability of CloudFormation for I would guess a huge number of your users. Thanks
Any resources that support tagging through the console, should support tagging via CloudFormation.
Yet another core, critical feature that's just been completely omitted from CloudFormation. How can anyone rely on CFN to do their work and build consistent infrastructure if CFN itself is not consistent? The console has it. The API has it. Why doesn't CloudFormation? This is absurd. AND, to make matters worse, this issue has been open for nearly ~THREE~ TWO YEARS with no action. Is anyone even monitoring this issue tracker anymore?
Edit: math isn't my strong point today.
@dannosaur This issue hasn't even been open for two years yet, so "nearly three years" feels like a bit of stretch. And while I feel your frustration around these sorts of feature requests, thankfully CloudFormation is flexible enough that when something is missing, it can be added it a robust, native way with custom resources. See here for how I've approached this for other types of resources that lack tagging support in CFN.
I think if CloudFormation is going to be the tool you use, it's only fair to ask it to do the things it claims to do. Currently, it does not claim to offer endpoint tagging. If that's a critical need for your workload, and adding your own support for it is not an option, CFN is not the right tool. Just like CFN doesn't support a region in Antarctica, it doesn't support endpoint tags. There are many things that CFN supports natively, reliably, and consistently, and if those things overlap with your needs it's an appropriate choice of tool, and taking that approach allows many people to use CFN to do their work and build very solid infrastructures.
That being said, I do wish I could peek behind the curtains to see what holds up these sorts of features, simply out of curiosity. If I can build this feature in 60 lines of code, I do wonder why resource tagging in particular seems to take so much longer to support than other aspects of many resource types. I don't really know what CFN looks like behind the scenes, but I'd be pretty surprised if the code needed to support tags for VPC Endpoints is that different than some other resource. Seems like someone should be able to do some copy-and-pasting and get these squared away pretty quickly.
Ugh, it's still early(ish), and for some reason math isn't my strong point today. 2019 somehow appeared to be 3 years ago, not 2. My bad.
I've augmented CFN in the past to get it to do things that it doesn't do, or doesn't make sense to do (for example, a have a Lambda function my stacks invoke to issue a RunTask command on an ECS cluster). In some cases, this is fine and warranted, as there's no way CFN could ever be expected to behave in a way that everyone agrees with.
But your point about asking CFN to do something it doesn't claim to do doesn't quite make sense. I'm not asking CFN to do something AWS themselves don't do - launch instances in Antarctica. They don't have a region there, so it's nonsensical to ask CFN to launch resources where AWS physically doesn't have a presence. What I am asking CFN to do is something that every other part of AWS's ecosystem already does - tag a resource. And given that the rest of the AWS ecosystem already support this, I don't think it's fair to ask each and every person maintaining infrastructure to write their own Lambda function to augment their CFN stack to do something that's fundamental to AWS.
Over the last few years as their billing systems have gotten more advanced, they put an emphasis on tagging resources for cost allocation, or at least being able to identify resources from one another through the console, API, or however you ingest your resource lists. I use these features heavily. And IAM has gotten more advanced by allowing permission boundaries based on resource tags. How in the world are we expected to be able to follow "best practices", and make use of these features, when one of the fundamental portions of AWS, their IaC platform, doesn't support everything the API does without spending time writing our own code that will likely be duplicated thousands of times by developers all over the world?
Like yourself, I have no idea what happens behind the scenes at CFN. In my head at least, I see it as just calling API's (whether they're the official API's that things like boto3 uses, or internal API's), much like how Terraform does. But even if not, the functionality that's being asked for here (and very likely in a multitude of other places where folk have been asking for tagging support in CFN) already exists. All we're asking here is for CFN to support something that the rest of the AWS ecosystem already does, and to keep up with the API. CFN's had a parity issue for as long as I can remember, and it's frustrating when I keep stumbling across parts that are lacking because the team behind a certain service or resource has added a new feature or API call, and CFN doesn't get that same functionality for years.
What I am asking CFN to do is something that every other part of AWS's ecosystem already does
My main point is that I've found myself to be a lot happier with CFN when I don't think about it this way.
I definitely used to, and would make decisions based on what AWS offered, and get frustrated when I ran into things that were lacking in CFN. But now the feature set that I use to make decisions primarily is what CFN offers.
I completely agree that it shouldn't have to be this way, and that AWS evangelizes things like IaC/CFN, tags for billing, and tags for security, and doesn't actually have a solution that can do all of those things consistently. I wish they did, and missing CFN features is always one of the first things I bring up with our account rep. It's very strange when they put up blog posts on the same day talking about IaC best practices, and announcing a new service that has no CFN support.
I think we should continue to expect CFN to have day-one parity with Console and CLI, and all these gaps should be filled in. I also think AWS should make an actual commitment to CFN parity, so that the promise does exist. But in the currently reality, if only for my own sanity, my thought process will be "this is what we've got to work with, and it will be great when we have X, Y, and Z too". I'll keep opening these tickets until everything is supported, but I'm also trying not to let these gaps slow me down too much.
Just noticed that Cost Explorer wasn't including my VPC Endpoints when I filtered by CF stack tag and was led to this issue. Pretty unfortunate that they aren't included.
The person who resolves this issue after all these years should get promoted instantly, just saying
+1 to allow IAM policies with VPCE actions that condition on resource tag
Its funny and sad to read the argument from 9 months ago about how long this issue has been open. Sigh
