Add NAT gateway scope parameter to control the vpc/az deployment scope the CFN #97
Conversation
| If set to 'az', only one NAT Gateway will be deployed per VPC/AZ. This | ||
| results in intra-AZ traffic, but increases the number of NAT gateways. |
There was a problem hiding this comment.
| If set to 'az', only one NAT Gateway will be deployed per VPC/AZ. This | |
| results in intra-AZ traffic, but increases the number of NAT gateways. | |
| If set to 'az', only one NAT Gateway will be deployed per VPC/AZ. This | |
| reduces cross-AZ traffic, but increases the number of NAT gateways. |
There was a problem hiding this comment.
The docs are correct. az scope means there will be one NAT per AZ, and there will be intra-AZ traffic
| - Key: elastio:resource | ||
| Value: 'true' |
There was a problem hiding this comment.
Is it the right call to put our tag on these? That means aws-gc will delete the lambdas. That seems like it would not be expected behavior...
There was a problem hiding this comment.
Yeah, it will. We discussed that the Cloudwatch groups should have elastio:resource tag https://github.com/elastio/elastio/issues/6694#issuecomment-2261039044, for us to be able to read. I decided to add this tag for all resources anyway. If we do aws-gc we'll definitely want to start everything from scratch, likely including the NAT stack as well, because if we need to do aws-gc it's probably the case that something in the user's env deletes resources and it already broke both the NAT stack and Connector stack
Closes https://github.com/elastio/elastio/issues/9476
I didn't remove the existing logic that deploys NAT gateways per AZ (maybe it will be useful in the future). Instead I added an input parameter to the stack to control the deployment scope. The default value is "vpc" scope, meaning there will be just one NAT gateway per VPC.
Another change. Added
elastio:resourcetags to all resources that support tags.