You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .header.md
+79Lines changed: 79 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -247,6 +247,63 @@ Terraform Plan:
247
247
...
248
248
```
249
249
250
+
# BYOIP (Bring Your Own IP) for NAT Gateway EIPs
251
+
252
+
You can control how Elastic IPs are sourced for NAT Gateways using the `nat_gateway_eip_configuration` variable. Three modes are available:
253
+
254
+
## Default (create)
255
+
256
+
When `nat_gateway_eip_configuration` is not set (or `mode = "create"`), EIPs are allocated from Amazon's default pool. This is the existing behaviour — no changes required for current users.
257
+
258
+
## BYOIP Pool
259
+
260
+
Allocate EIPs from a customer-owned public IPv4 address pool:
Use pre-allocated EIP allocation IDs (e.g., managed outside this module):
292
+
293
+
```hcl
294
+
nat_gateway_eip_configuration = {
295
+
mode = "existing"
296
+
allocation_ids = {
297
+
"us-east-1a" = "eipalloc-0123456789abcdef0"
298
+
"us-east-1b" = "eipalloc-0123456789abcdef1"
299
+
}
300
+
}
301
+
```
302
+
303
+
When `mode = "existing"`, the module does **not** create `aws_eip` resources — it attaches the provided allocation IDs directly to the NAT Gateways. Keys must match the AZ names where NAT Gateways will be deployed.
304
+
305
+
Credit: Inspired by community PR#179 ([@hminaee-tc](https://github.com/hminaee-tc)).
306
+
250
307
# Common Errors and their Fixes
251
308
252
309
## Error creating routes to Core Network
@@ -297,6 +354,28 @@ subnets = {
297
354
298
355
* Alternatively, you can also not configure any subnet route (`var.core_network_routes`) to the Core Network until the attachment gets accepted.
299
356
357
+
## Production Recommendation: Explicit `cidrs` over `netmask`
358
+
359
+
For production deployments, prefer explicit `cidrs` over calculated `netmask` to avoid subnet replacement on changes.
360
+
361
+
When using `netmask`, CIDRs are calculated positionally based on lexicographic ordering of subnet key names. Adding or removing a subnet type (e.g., adding `database = { netmask = 26 }`) can shift CIDRs assigned to existing subnets — causing Terraform to destroy and recreate them, resulting in downtime.
362
+
363
+
```hcl
364
+
# ⚠️ Development only — CIDRs shift if you add/remove subnet types
365
+
subnets = {
366
+
private = { netmask = 24 }
367
+
public = { netmask = 24 }
368
+
}
369
+
370
+
# ✅ Production-safe — CIDRs are pinned regardless of key changes
public = { cidrs = ["10.0.3.0/24", "10.0.4.0/24", "10.0.5.0/24"] }
374
+
}
375
+
```
376
+
377
+
This is particularly important when using multiple private subnet roles (e.g., `private`, `isolated`, `database`) since alphabetical ordering determines CIDR allocation.
378
+
300
379
# Contributing
301
380
302
381
Please see our [developer documentation](https://github.com/aws-ia/terraform-aws-vpc/blob/main/contributing.md) for guidance on contributing to this module.
0 commit comments