-
Notifications
You must be signed in to change notification settings - Fork 248
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
How to safely deploy stacks using AlbToFargate into the same VPC #918
Comments
Thanks for the note! Have you seen behavior where two identical endpoints are added to the same VPC? When we run the code below only 1 endpoint is created:
If you've got an example that creates two endpoints of the same type, please share it. |
Ah - is your point that if I obtain a pre-existing VPC from another stack using something like fromVpcAttributes, then a subsequent construct could add a second endpoint? That could be - it could be the CDK that is preventing the redundancy in my example. |
Right. If the two constructs shares the same VPC construct, the invocation of the first construct would place some markers in the VPC construct so the invocation of the second construct would avoid attaching the endpoints again. But if the second construct does a fromVpcAttributes to import the same VPC, the second construct can't detect the endpoints are already attached and would attempt to attach again and fail. |
I'm not sure that an answer to this exists in the CDK world. fromVpcAttributes only populates the existing resources defined in VpcAttributes - and the interface has no entry to include endpoints. It would appear that CDK cannot learn about the endpoints of existing VPCs getting pulled into the stack. .fromLookup might have different behavior, I have never experimented with it. |
To the best of our knowledge, this cannot be accomplished in the CDK at this time. We'll put it on our backlog on the possibility that this changes in the future. |
This is not necessarily a bug but it is not clear to me what the best practices are.
Because AlbToFargate (and other constructs) attaches service endpoint (e.g., ecr, ddb) into the VPC it uses, if you have multiple stacks all using AlbToFargate and share the same vpc only the first stack would succeed because of the endpoints can't be attached again.
What one would have done is to perform the service endpoint attachment in where the VPC is defined, and when importing the VPC into a stack one also places the
interfaceTag
marker into the VPC construct so the service endpoints are not attached again. This gets around the problem but it does not seem to be a general solution.Reproduction Steps
Error Log
Environment
Other
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: