AWS::EC2::VPCEndpoint - Tags

[farski]

Add support for tags on AWS::EC2::VPCEndpoint resources

[opera443399]

I know this issue via aws support center

[konkerama]

Do we have an update/ETA for this request?

[githubnoobieme]

I can't believe that this issue still exists in 2021... no support for tags via cloudformation, seriously? No wonder Terraform is more popular

[chase1124]

Roadmap update? Consistent tagging is a critical capability of CloudFormation for I would guess a huge number of your users. Thanks

[NickTheSecurityDude]

Any resources that support tagging through the console, should support tagging via CloudFormation.

[alkayahan]

+1

[gepo01]

+1

[kierancanny]

+1

[dannosaur]

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.

[farski]

@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.

[dannosaur]

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.

[farski]

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.

[hperera-jd]

Still no...

[landisj]

sigh...

[smith0228]

+1 Any progress on this issue?

[mobilesuitzero]

• any progress on this?

[spullara]

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.

[mtszkw]

The person who resolves this issue after all these years should get promoted instantly, just saying

[smarinade]

+1

[mike-mosher]

+1

[derek-ikhokha]

+1

[MattJaccino]

+1 to allow IAM policies with VPCE actions that condition on resource tag

[ghost]

+1

[coreylane]

+1

[gomibushi]

Its funny and sad to read the argument from 9 months ago about how long this issue has been open. Sigh

[zrashwani]

+1

[ghost]

+1

[TsimpDim]

+1

[otomikesuy]

+1

[takeda1411123]

+1

[mcarson9]

+1

[takeda]

Ehh, not only it doesn't allow to set tags, it doesn't even inherit tags from cloudformation template. And it's been almost 3 years...

[ekadas]

+1

[michaeldrey]

+1

[S3ky]

+1

[2underscores]

+1

[BourgoisMickael]

As it might never be fixed, here is a workaround.

You can setup the custom resource and macro from https://github.com/awslabs/aws-cloudformation-templates/tree/55ebf9f7129e87530e68c242d7e46167e6a798b8/aws/services/CloudFormation/MacrosExamples/Boto3 The code is 4 years old, so it needs to be updated:

• Use python3.9
• Move lambda code to InlineCode in template to replace urllib2 with cfnresponse
• Remove calls to json.dumps
• Remove property case lowering

---

Then you should be able to add a tag using CloudFormation like this:

VpceTagName:
  Type: Boto3::ec2.create_tags
  Properties:
    Resources:
      - !Ref VpcEndpoint
    Tags:
      - Key: Name
        Value: My VPCE

[oze10t]

+1

[Tsoyuzhu]

+1

[ryanwilliams83]

If you happen to be using CDK; this might be helpful.

// import { AwsCustomResource, AwsCustomResourcePolicy, PhysicalResourceId } from 'aws-cdk-lib/custom-resources';
  new AwsCustomResource(this, 'VpcEndpointTags', {
            installLatestAwsSdk: false,
            onUpdate: {
                action: 'createTags',
                parameters: {
                    Resources: [
                        vpcEndpoint.vpcEndpointId
                    ],
                    Tags: [
                        {
                            Key: 'Name',
                            Value: 'Cookie Monster'
                        }
                    ]
                },
                physicalResourceId: PhysicalResourceId.of(Date.now().toString()),
                service: 'EC2'
            },
            policy: AwsCustomResourcePolicy.fromSdkCalls({
                resources: AwsCustomResourcePolicy.ANY_RESOURCE,
            })
        });

[Beast12]

2019... No solution in cfn 2020... No Solution in cfn 2021... No Solution in cfn 2022.. No Solution in cfn 2023... Let's hope, because this is getting quite ridiculous

[spullara]

I almost feel like it is on purpose because it so expensive relative to every other thing.

On Sun, Jan 8, 2023 at 11:19 PM Beast12 @.***> wrote:

2019... No solution in cfn 2020... No Solution in cfn 2021... No Solution in cfn 2022.. No Solution in cfn 2023... Let's hope, because this is getting quite ridiculous

— Reply to this email directly, view it on GitHub https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/196#issuecomment-1375198021, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIFEDYREPJ2WMNT6XCTBDWRO3W5ANCNFSM4I3GZECQ . You are receiving this because you commented.Message ID: <aws-cloudformation/cloudformation-coverage-roadmap/issues/196/1375198021@ github.com>

[dhilpkumarbalraj]

All VPC endpoint looks like headless chicken. Please have a name tag

[donggiangthai]

Did anybody from the Cloud Formation dev team notice this thread? I would add a comment to push them up. hopefully, we will have the tag for the VPCEndpoint as soon as possible.

[Paco-lo]

All VPC endpoint looks like headless chicken. Please have a name tag

Same as the costs of them!! A good business!!

[Njk00]

Please add this feature

[michft-v]

Ditto please add this to CF, it is frustration to have to open AWSCLI to tag the VPCE as a EC2 network resource as a separate step.

Terraform has it.

resource "aws_vpc_endpoint" "s3" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.us-west-2.s3"

tags = { Environment = "test" } }

AWSCLI has it

aws ec2 create-tags --profile 123456789012 --resources vpce-1234567890abcedf1 --tags Key=Name,Value=Test

Even Boto3! response = client.create_vpc_endpoint( DryRun=True|False, VpcEndpointType='Interface'|'Gateway'|'GatewayLoadBalancer', VpcId='string', ServiceName='string', PolicyDocument='string', RouteTableIds=[ 'string', ], SubnetIds=[ 'string', ], SecurityGroupIds=[ 'string', ], IpAddressType='ipv4'|'dualstack'|'ipv6', DnsOptions={ 'DnsRecordIpType': 'ipv4'|'dualstack'|'ipv6'|'service-defined', 'PrivateDnsOnlyForInboundResolverEndpoint': True|False }, ClientToken='string', PrivateDnsEnabled=True|False, TagSpecifications=[ { 'ResourceType': 'client-vpn-endpoint'|'vpc-endpoint', 'Tags': [ { 'Key': 'string', 'Value': 'string' }, ] }, ] )

Why not CF?

[Risae]

https://aws.amazon.com/blogs/devops/cloudformation-coverage/

on 04 MAY 2023

As we continue to strive towards our ultimate goal of achieving full feature coverage and a complete migration away from the legacy resource model, we are constantly identifying opportunities for improvement. We are currently addressing feature gaps in supported resources, such as tagging support for EC2 VPC Endpoints and boosting coverage for resource types to support drift detection, resource import, and Cloud Control API.

[MikePeckOneValley]

Please add this functionality.

This really feels like a low-hanging fruit, quick and easy to implement since tags are supported on most resources and the code should be easy to copy onto vpcendoint.

[mjkubba]

+1