What this prompt does
This prompt casts the model as a senior cloud infrastructure engineer writing a reusable Terraform VPC module -- working HCL with sane defaults and documented inputs, not pseudocode. You set [terraform_version], [vpc_cidr], [az_count], and [nat_strategy], and it produces a VPC with public/private subnets, gateways, flow logs, tagging, typed variables, outputs, a README, and a runnable example.
The structure works because a hand-rolled VPC is where subtle subnet and route mistakes hide for months. [vpc_cidr] and [az_count] drive how subnets are carved and spread across availability zones. [nat_strategy] becomes a flag toggling single NAT versus one-per-AZ -- a real cost-versus-availability tradeoff the module exposes rather than hard-codes. [terraform_version] pins the module so syntax matches your toolchain. Flow logs to S3 and a secure default security-group posture come baked in, so the baseline is tagged and observable from the first apply rather than retrofitted later.
When to use it
- You're standing up AWS networking and want a clean, tagged, flow-logged VPC baseline.
- You'd rather use a reusable module than copy-paste console clicks into HCL.
- You need public and private subnets spread correctly across multiple AZs.
- You want NAT strategy as a toggle so dev can run single and prod one-per-AZ.
- You need VPC flow logs to S3 and a sane default security-group posture.
- You want typed variables, meaningful outputs, a README, and an example call.
- You want a consistent tagging strategy with an input to merge your org's extra tags.
Example output
You get the full file tree of the module: the VPC, subnets, internet gateway, NAT gateways behind the [nat_strategy] flag, route tables, flow-log config, tagging, typed input variables with descriptions and defaults, outputs (vpc_id, subnet IDs, route table IDs), a README, and a runnable example module call. It's pinned to your Terraform version and meant to pass terraform fmt and validate, so it behaves like a module you can reuse rather than a one-off snippet.
Pro tips
- Set
[vpc_cidr]and[az_count]together so the subnet carving leaves enough room per AZ. - Flip
[nat_strategy]to one NAT per AZ before production -- single-NAT saves money but is a real availability risk. - Pin
[terraform_version]to your actual toolchain so the generated HCL matches what you run. - Run
terraform fmtandvalidateon the output immediately; the prompt asks for it, so leftover issues surface fast. - Use the merge-extra-tags input so the module's tagging strategy composes with your org's required tags.
- Check the default security-group posture matches your policy before applying; defaults should be tightened, not loosened.
- Carve
[vpc_cidr]with future subnets in mind so adding an AZ later doesn't force a re-CIDR.
