feat: Adding support for regional nat gateway

[Balvinder-1995]

Description

Adding support for regional NAT Gateway which is introduced in aws provider version 6.24.0

Motivation and Context

Fixes: #1269

Breaking Changes

No breaking changes.

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects

• I have executed pre-commit run -a on my pull request
• I provisioned the VPC and NAT Gateway using the latest published module version, then switched to the code in this PR. I confirmed that there is no impact on existing infrastructure unless the new boolean variables are explicitly enabled.

[Balvinder-1995]

@antonbabenko @bryantbiggs can you please help review this PR to add support for regional NAT gateway.

[jeenadeepak]

@antonbabenko / @bryantbiggs : any update on this?

[aruetten]

Hi,

really looking forward to have this merged. Thanks a lot for all your work.

There is just one thing I would like to mention:

The docu states:

4. Cost Considerations: Regional NAT Gateways are charged per hour and per GB processed, similar to zonal NAT Gateways, but you only pay for one NAT Gateway instead of multiple.

Based on my understanding of this feature, this can be misleading.
While it's true that you would only pay for "one NAT Gateway instead of multiple", still the number is multiplied by the number of AZs the regional NAT GW is attached to.

See:

Regional NAT Gateway Pricing
If you choose to create a NAT gateway with regional availability in your VPC, you are charged for each hour that the NAT Gateway is configured in each availability zone. For example, if your regional NAT is running across three Availability Zones(AZs) for one hour, you'll be billed for three 'NAT Gateway-hours'.
From: https://aws.amazon.com/vpc/pricing/

To my understanding this makes the pricing comparable to a classic NAT GW with the same amount of AZs configured.

[hongyiweiwu01]

Hi! Just bumping this and see if it could be merged? Thank you!

[leonardocaylent]

@Balvinder-1995 Did you test how the changes affect moving from a normal zonal NAT Gateway deployment in 2 azs with the version 6.6.0 to your changes with a regional NAT gateway in this 2 scenarios?
1)Normal mode (Static EIPs)
2)Automatic mode

I think it would be great to look how those 2 terraform plans look like to understand better the impact.

Also, is the intention to let the normal deployment to always use ZNATs instead of RNATs? ( I see the default variable is set as availability_mode = null but I'm asking because maybe we need to also update the other examples to have consistency)

[edechime-bryan]

Looking forward for this to be merged

[mazenkhalil]

Excited to see this make it into the upcoming release!

[Balvinder-1995]

@leonardocaylent , The changes won't impact the existing way to managing NAT gateways until the new variable nat_gateway_connectivity_type isn't used.

1. For NAT in multi-AZ - Once you start using this variable, this will destroy the existing NATs and EIPs and will spin up the new NAT gateways based on the nat_gateway_connectivity_type.availability_mode and nat_gateway_connectivity_type.eip_allocation you have chosen. But if you don't want your NAT gateways and EIPs to be impacted, you don't have to use this variable and it won't impact anything.
2. For NAT gateway in single AZ - You can choose nat_gateway_connectivity_type.availability_mode as zonal and it won't destroy the existing NAT and EIP.

yes, the intention is to always use ZNAT instead of RNAT so that the existing NAT gateways are not impacted. If someone wants to use RNAT, they can start using nat_gateway_connectivity_type variable.

[phivid]

Any update here on this topic ? @Balvinder-1995 @antonbabenko @bryantbiggs 🙏
I'm thrilled to test it on my new project.