aws_ec2 : new Instance() with requireImdsv2:true creates name conflicting LaunchTemplate
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 83
Description
### Describe the bug
When creating a new ec2 Instance in the CDK v2 with `requireImdsv2` as `true`:
```typescript
new ec2.Instance(this, 'Instance', {
// ... other required params
requireImdsv2: true,
})
```
Creates a LaunchTemplate underneath to enforce this configuration. The name of this launch configuration though is just the constructId + 'LaunchTemplate' appended to it in the synthesised Cloudformation template :
```yaml
InstanceLaunchTemplateFB1C3D8B:
Type: 'AWS::EC2::LaunchTemplate'
Properties:
LaunchTemplateData:
MetadataOptions:
HttpTokens: required
LaunchTemplateName: InstanceLaunchTemplate
```
This causes a conflict when wanting to deploy multiple of these CF templates in the same AWS account as there are multiple LaunchTemplates then being created, but with the same name.
The bug also causes more headaches as there is not (or i have not been able to find) a way to access the launch template and update it manually with an escape hatch. `CfnLaunchTemplate` (https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.CfnLaunchTemplate.html) contains options to specify a `launchTemplateName`, but there does not appear to be a way from the `ec2.Instance` class to get to it, nor is there a way to assign one to the other ?
### Expected Behavior
I expected the CDK to generate unique names for its underlying LaunchTemplate construct or provide some way to let me control the naming so that I can ensure its uniqueness.
### Current Behavior
The `launchTemplateName` is set to the `Instance()` classes constructid + `LaunchTemplate` :
```yaml
InstanceLaunchTemplateFB1C3D8B:
Type: 'AWS::EC2::LaunchTemplate'
Properties:
LaunchTemplateData:
MetadataOptions:
HttpTokens: required
LaunchTemplateName: InstanceLaunchTemplate
```
This causes name conflict issues when wanting to deploy multiple Cloudformation templates generated from the CDK synthesis
### Reproduction Steps
1. Create a new ec2.Instance with `requireImdsv2` as `true`:
```typescript
new ec2.Instance(this, 'Instance', {
// ... other required params
requireImdsv2: true,
})
```
2. Run cdk synth
3. Review output you will find the LaunchTemplate produced will look something like this
```yaml
InstanceLaunchTemplateFB1C3D8B:
Type: 'AWS::EC2::LaunchTemplate'
Properties:
LaunchTemplateData:
MetadataOptions:
HttpTokens: required
LaunchTemplateName: InstanceLaunchTemplate
```
### Possible Solution
LaunchTemplate naming when `requireImdsv2` is `true` should produce a more unique name OR provide a way for developers to set the `launchTemplateName` that is generated from this setting being enabled
In my case, having access to the `launchTemplateName` would allow me to pass a `CfnParameter` result to the launchTemplateName to make it unique
### Additional Information/Context
We currently use the CDK to generate our Cloudformation templates and this is running into specifically our deployment of development EC2 machines. We generate Cloudformation templates as we need to integrate with existing infrastructure and Service Catalog and this most commonly has us working with CfnParameter and like constructs as we have parameters that can only be resolved at deploy time
### CDK CLI Version
v2.5.0, v2.38.1
### Framework Version
v2.5.0, v2.38.1
### Node.js Version
v14 , v16
### OS
MacOS, CentOS7
### Language
Typescript
### Language Version
4
### Other information
_No response_
Contributor guide
Research direction
Start by tracing how ec2.Instance handles requireImdsv2 and produces the synthesized AWS::EC2::LaunchTemplate, then compare that behavior with the naming options exposed by CfnLaunchTemplate. Reproduce the example with cdk synth and verify that the generated launch template name is unique or controllable so multiple templates can deploy without conflicts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100