• Add ability to configure different numbers of public and private subnets per Availability Zone independently
• Add controlled NAT Gateway placement by subnet index to reduce costs
• Add intuitive NAT Gateway placement by subnet name for better usability
• Fix critical NAT Gateway placement bug causing wrong AZ distribution
• Fix cross-AZ routing issue where private subnets routed to NATs in different AZs
• Add comprehensive examples demonstrating cost-optimized and high-availability configurations
• Add full test coverage with Terratest for all new features
• Maintain 100% backward compatibility with existing configurations

why

User Pain Points:

• Users were forced to create equal numbers of public and private subnets, even when workloads didn't require it
• NAT Gateways were created in every public subnet, resulting in unnecessarily high AWS costs (~$32/month per NAT)
• No control over which public subnets received NAT Gateways
• Index-based configuration was not intuitive for users who assigned names to subnets
• Critical bugs caused NAT Gateways to be placed in wrong AZs and private subnets to route across AZ boundaries

Business Impact:

• Cost Optimization: Reducing from 6 NATs to 3 NATs saves $96/month (50% reduction)
• Flexibility: Users can now match subnet configuration to their actual workload requirements
• Reliability: Fixes ensure NAT Gateways are correctly distributed across AZs and routing stays within same AZ
• Usability: Name-based placement is more intuitive and maintainable than index-based placement

Key Features:

1. Separate Public/Private Subnet Counts: New variables public_subnets_per_az_count, public_subnets_per_az_names, private_subnets_per_az_count, private_subnets_per_az_names allow independent control while falling back to original variables for backward compatibility

2. Controlled NAT Placement by Index: Variable nat_gateway_public_subnet_indices (default [0]) specifies which subnet position(s) in each AZ receive NAT Gateways, enabling cost optimization

3. Named NAT Placement: Variable nat_gateway_public_subnet_names allows intuitive placement like ["loadbalancer"] instead of remembering indices

4. Bug Fixes: Corrected NAT Gateway global index calculation and route table mapping to ensure proper AZ distribution and same-AZ routing

Examples Included:

• examples/separate-public-private-subnets/: Cost-optimized with 1 NAT per AZ (~$110/month)
• examples/redundant-nat-gateways/: High-availability with 2 NATs per AZ (~$140/month)

Test Coverage:

• Full Terratest coverage for both examples
• Tests for name-based and index-based NAT placement
• Tests for disabled state (no resources created)
• Verification of all outputs, subnet counts, NAT counts, and route table mappings

references

• Comprehensive PRD: docs/prd/separate-public-private-subnets-and-nat-placement.md

why

• Error loading shared library libresolv.so.2 in Go 1.20

References

• https://sweetops.slack.com/archives/G014YEKDH4K/p1746672149263629
• golang/go#59305 (comment)
• cloudposse/terraform-aws-cloudfront-s3-cdn#294

why

• Replace build-harness with atmos for readme genration

References

• DEV-3229 Migrate from build-harness to atmos

why

• Re-apply .github/settings.yml from org level to get terratest environment
• Migrate to new test account

References

• DEV-388 Automate clean up of test account in new organization
• DEV-387 Update terratest to work on a shared workflow instead of a dispatch action
• DEV-386 Update terratest to use new testing account with GitHub OIDC

why

• Re-apply .github/settings.yml from org level
• Use organization level auto-release settings

references

• DEV-1242 Add protected tags with Repository Rulesets on GitHub

why

• So we can support commenting on PRs with a link to the release

why

• Reduce nested levels of reusable workflows

why

• The ReviewDog action will comment with line-level suggestions based on linting failures

why

• Support new readme generation workflow.
• Generate banners

• Install latest GitHub Action Workflows

why

• Use shared workflows from cldouposse/.github repository
• Simplify management of workflows from centralized hub of configuration

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

why

• Programmatically manage GitHub repo settings

why

To have most recent changes of README.md and doc from origin templates

why

• Upstream template changed in the .github repo
• Work better with repository rulesets
• Modernize look & feel