New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ec2): network interface definitions for launch templates #29875
base: main
Are you sure you want to change the base?
feat(ec2): network interface definitions for launch templates #29875
Conversation
…ations as part of Launch Template definitions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
I do not know what the failing check is about. |
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
This PR implements basic functionality for defining network interfaces as part of Launch Template.
Issue # (if applicable)
Fixes #14494
Reason for this change
Current Launch Template L2 is missing the ability to define multiple interfaces, their subnets etc. This functionality is required in advanced scenarios where instances need multiple public IP addresses or need to be multi-homed etc.
Description of changes
Multiple new types have been introduced in
packages/aws-cdk-lib/aws-ec2/lib/launch-template.ts
. Many of them are just renamedextends
of theec2-generated
types. This made sense as the Cloudformation type definition is suitable, but I'm a bit uncertain if this violates the design requirement Do not “leak” the details or types of the CFN layer when defining your construct API.Main type is
NetworkInterface
which defines the attributes for the interfaces. Additional changes are inLaunchTemplate
constructor to accommodate the new functionality.README has been updated to include a simple usage example.
Description of how you validated changes
A single test has been added. I have also verified the implementation by creating stacks in different configurations and deployed them. There too many combinations to check them all, so only a subset has been tested, unfortunately.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license