-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Too many NAT gateways created #117
Comments
As a follow-up, I went through the instructions titled External NAT Gateway IPs on the page https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/1.30.0 as well. The module still creates 6 NAT gateways, only now 3 of them have the following error in the AWS console:
I also see in the
Is the only option to either have one NAT gateway, or |
#83 Looks to have switched to use the max_subnet_length, IMHO that's incorrect. You'd either create a single NGW or if your thinking about AZ failure you would create a NGW per AZ within that region. Again there's some assumptions made with subnets and AZs. Irrespective of how many private subnets you have as this shouldn't influence the number of NGWs created. |
@robh007 Yes I agree. Basically, the maximum number of NAT gateways created would be the number of availability zones in that region. @antonbabenko Thoughts? |
I remember we've had some discussion about this in the past. It has been evolving, and I tend to agree that after #83 is merged it is a good time to reconsider a number of NAT gateways created. I see that there are these options:
The solution with one NAT per subnet can still be helpful for situations when EIP of NAT gateway should be whitelisted on corp firewall and, at the same time, not all subnets in that AZ should have access to corp network. So, this module needs to maintain all 3 scenarios. Can somebody come up with a PR to support these scenarios? |
@antonbabenko Yes, I'll come up with a PR. Thanks for the input! |
#129 created |
* Initial commit for issue #117 * Adding documentation for NAT Gateway creation * Adding `enable_nat_gateway` to the documentation * Updating README.md with `one_nat_gateway_per_az` to be 'true' by default * Reverted changes back to `one_nat_gateway_per_az` as 'false'
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
…ality (terraform-aws-modules#129) * Initial commit for issue terraform-aws-modules#117 * Adding documentation for NAT Gateway creation * Adding `enable_nat_gateway` to the documentation * Updating README.md with `one_nat_gateway_per_az` to be 'true' by default * Reverted changes back to `one_nat_gateway_per_az` as 'false'
…ality (terraform-aws-modules#129) * Initial commit for issue terraform-aws-modules#117 * Adding documentation for NAT Gateway creation * Adding `enable_nat_gateway` to the documentation * Updating README.md with `one_nat_gateway_per_az` to be 'true' by default * Reverted changes back to `one_nat_gateway_per_az` as 'false'
Not sure whether to file this under "feature", or "bug"; I suppose it depends on how a person views subnetting in AWS VPC.
Basically, I have 6 private subnets calculated from a base /16 prefix, and being created in the
eu-west-1
region as follows:In the module definition, I have also specified to use all 3 availability zones
eu-west-1a
,eu-west-1b
, andeu-west-1c
. The module then generates 6 NAT gateways that look like this:My question: isn't one NAT gateway per private subnet a bit excessive? If the number of availability zones is defined by
${length(var.azs)}
, then shouldn't only${length(var.azs)}
number of NAT gateways be created, and added to the route tables?This is especially true as a person's user account is charged per hour that each NAT gateway instance is running: https://aws.amazon.com/vpc/pricing/#natgatewaypricing
My info:
Terraform v0.11.7
Provider.aws v1.14.0
Module version: 1.30.0
The text was updated successfully, but these errors were encountered: