// the find
terraform-aws-modules/terraform-aws-vpc
Terraform module to create AWS VPC resources 🇺🇦
The de-facto standard Terraform module for AWS VPC — if you're standing up a VPC on AWS with Terraform, you're probably using this or copying from it. It covers the full surface area: public/private/database/elasticache/redshift/intra subnets, NAT gateway topologies, NACLs, flow logs, IPAM integration, IPv6 dual-stack, Outposts, and VPN/transit gateway hooks. Maintained by the terraform-aws-modules org, which also maintains the EKS, RDS, and ECS modules.
The three NAT gateway modes (one-per-subnet, single, one-per-AZ) with clear boolean flags is a well-thought-out design — most teams start with single_nat_gateway=true for dev and flip it for prod without changing anything else. The intra subnet type (no internet route, no NAT) is genuinely useful for Lambda VPC placement where you'd otherwise burn NAT bandwidth on ENI churn. IPAM integration with the cidrsubnets() preview workaround is a real solution to a real Terraform limitation, not a hack. The flow-log module was split into a standalone submodule before most users asked for it, which is the right call.
The module has ~300 input variables — the blast radius of a misconfigured flag is hard to reason about without reading the source, and the README's variable table is generated output, not guidance. The IPAM integration explicitly cannot use ipv4_netmask_length due to a plan-time race condition that's a known Terraform limitation with no clean fix; the workaround requires a data source preview step that breaks the expected workflow. Flow log creation in the root module is deprecated heading into v7, which means anyone who enabled it via the root module now has a migration on their hands. The default database subnet ACL rules (allow all inbound from 0.0.0.0/0) are a footgun — they're there for usability but it's the kind of default that gets cargo-culted into production unchanged.