AWS VPC Deployment

---
name: aws-vpc-deployment
description: Guides authorized users through creating and validating a four-tier AWS VPC using the AWS Console or CLI. Use for parameterized VPC setup, 12 subnets across three Availability Zones, internet and NAT gateways, and route tables.
when_to_use: User says "create an AWS VPC", "deploy a VPC", "configure VPC subnets", or "set up AWS networking with Console or CLI".
argument-hint: "[region] [vpc-cidr] [vpc-name]"
arguments:
  - region
  - vpc_cidr
  - vpc_name
allowed-tools:
  - Read
  - Grep
  - Bash(aws sts get-caller-identity:*)
  - Bash(aws ec2:*)
  - Bash(bash -n:*)
  - Bash(./scripts/create-vpc.sh:*)
disallowed-tools:
  - Edit
model: openai/gpt-oss-20b
license: MIT
metadata:
  version: "1.0.0"
  author: Issac Lee
  updated_date: "2026-11-13"
---

Operating rules

• Guide the user through the AWS Management Console only. Never claim to have created AWS resources unless an authorized browser/connector action actually completed.
• Before starting, confirm AWS account, region, permitted CIDR, budget, naming prefix, and whether the user has permission to create VPC/network resources. Default to us-east-1, 10.0.0.0/16, and prefix prod only when the user has no conflicting requirements.
• Warn that NAT gateways, public IPv4 addresses, endpoints, and traffic processing incur ongoing charges. Require user confirmation before any cost-incurring creation when acting on their behalf.
• Treat the design as a production baseline, not a guarantee of production readiness. Review organizational controls, overlapping CIDRs, AZ availability, quotas, IPv6, DNS, logging, connectivity, and disaster recovery requirements.
• AWS Console labels change. If a field differs, inspect current console help or AWS documentation; do not guess. Note that AZ letters can map to different physical AZs in different AWS accounts.
• Keep database/data subnets isolated: no default route to an Internet Gateway or NAT Gateway. For needed AWS service access, add approved VPC endpoints or carefully designed egress alternatives.
• Use least-privilege security groups, no unrestricted inbound SSH/RDP, no public database exposure, and human approval for destructive changes.

Target design

Subnet allocation

Names: prod-subnet-pub-1a, prod-subnet-app-1a, prod-subnet-data-1a, and corresponding 1b/1c suffixes. Use actual AZ identifiers where letters are not available.

Routing matrix

All route tables retain the automatically created 10.0.0.0/16 -> local route. Do not delete it. For service endpoints, gateway endpoint routes are automatically inserted into selected route tables. Never add an IGW route to app or data tables.

Step-by-step AWS Console workflow

1. Prepare and inspect

1. Sign in to the AWS Management Console.
2. Select US East (N. Virginia) / us-east-1 in the region picker, or the approved region.
3. Open VPC via the search bar; go to Your VPCs, Subnets, Route tables, Internet gateways, NAT gateways, and Elastic IPs to check for existing resources and collisions.
4. Verify the proposed 10.0.0.0/16 does not overlap with on-premises, peered, transit gateway, VPN, or future networks. Check service quotas, IAM permissions, and budgets.
5. Prefer VPC only rather than VPC and more to follow the exact manual procedure below; do not accidentally create duplicate subnets or NAT gateways with a wizard.

Checkpoint: Region, CIDR, cost approval, and resource naming are agreed.

2. Create the VPC

1. In VPC > Your VPCs, select Create VPC.
2. Select VPC only.
3. Name tag: prod-vpc.
4. IPv4 CIDR: IPv4 CIDR manual input -> 10.0.0.0/16.
5. IPv6 CIDR: No IPv6 CIDR block (unless requirements say otherwise).
6. Tenancy: Default.
7. Add tags such as Environment=production, ManagedBy=console, Owner=<team>, CostCenter=<value> as applicable; select Create VPC.
8. Select the new VPC, choose Actions > Edit VPC settings (or equivalent), enable DNS resolution and DNS hostnames, and save.

Checkpoint: VPC state is Available; both DNS options are enabled.

3. Create nine subnets

1. Go to VPC > Subnets > Create subnet.
2. Choose prod-vpc.
3. For each row in the subnet allocation table, enter the subnet name, matching AZ, and IPv4 CIDR. Add subnet rows with Add new subnet where offered; otherwise create in batches.
4. Create all nine subnets and verify each is in the correct AZ and VPC.
5. Select each public subnet -> Actions > Edit subnet settings -> enable Auto-assign public IPv4 address only if required by the public workload policy; NAT gateways use explicit Elastic IPs and do not require blanket public IP auto-assignment. Prefer leaving automatic public IPv4 assignment disabled by default and assigning addresses explicitly to approved public workloads.
6. Confirm auto-assign public IPv4 is disabled for app and data subnets.

Checkpoint: Exactly 9 intended subnets, with non-overlapping CIDRs; no private subnet auto-assigns public IPs.

4. Create and attach Internet Gateway

1. Go to Internet gateways > Create internet gateway.
2. Name prod-igw, create it, select it, and choose Actions > Attach to VPC.
3. Select prod-vpc and attach.

Checkpoint: IGW is attached to the intended VPC. Do not confuse IGW attachment with routing; routes come later.

5. Create the public route table

1. Go to Route tables > Create route table; name prod-rt-public, choose prod-vpc, and create.
2. Select the route table -> Routes > Edit routes > Add route.
3. Destination 0.0.0.0/0, target Internet Gateway -> prod-igw; save.
4. Open Subnet associations > Edit subnet associations; explicitly associate prod-subnet-pub-1a, prod-subnet-pub-1b, prod-subnet-pub-1c; save.

Checkpoint: All public subnets have the IGW default route and none of the private subnets are associated with this route table.

6. Allocate three Elastic IPs and create three NAT gateways

1. Open Elastic IPs > Allocate Elastic IP address. Allocate three AWS-provided public IPv4 addresses (or approved BYOIP addresses), and tag them prod-eip-nat-1a, -1b, -1c.
2. Go to NAT gateways > Create NAT gateway.
3. Create prod-nat-1a in prod-subnet-pub-1a, connectivity type Public, using the 1a Elastic IP.
4. Repeat for prod-nat-1b in public subnet 1b and prod-nat-1c in public subnet 1c, each with its own Elastic IP.
5. Wait for all NAT gateways to show Available before configuring dependent routes.

Checkpoint: Three available public NAT gateways, each in a different AZ/public subnet; public subnet route table has IGW route. Note ongoing NAT hourly and data processing charges, plus applicable public IPv4 charges.

7. Create three application route tables

For each suffix 1a, 1b, 1c:

1. Go to Route tables > Create route table.
2. Name prod-rt-app-<suffix> and choose prod-vpc.
3. Under Routes > Edit routes, add destination 0.0.0.0/0, target NAT gateway -> prod-nat-<suffix>.
4. Under Subnet associations, explicitly associate only prod-subnet-app-<suffix>.
5. Verify the NAT gateway is in the same AZ as the associated application subnet.

Checkpoint: Three app route tables, three distinct same-AZ NAT targets, no direct IGW route.

8. Create three isolated data route tables

For each suffix 1a, 1b, 1c:

1. Create prod-rt-data-<suffix> in prod-vpc.
2. Associate only prod-subnet-data-<suffix>.
3. Leave the route table with its 10.0.0.0/16 -> local route; do not add 0.0.0.0/0 to NAT or IGW.
4. Add only specifically approved private network routes or endpoint routes required by the workload.

Checkpoint: Three data subnets have no default Internet egress route. They can still communicate with VPC destinations subject to security controls; subnet isolation is not a replacement for security groups.

9. Configure security groups

1. Open Security groups > Create security group; select prod-vpc.
2. Create prod-sg-alb: allow inbound TCP 443 from 0.0.0.0/0 only for an approved internet-facing ALB; use approved egress to the application target port. Handle TLS certificates and WAF separately.
3. Create prod-sg-app: allow inbound application port (for example TCP 8080) from prod-sg-alb only; permit only approved outbound destinations/ports. For maintenance, prefer AWS Systems Manager Session Manager rather than public SSH/RDP.
4. Create prod-sg-db: allow inbound database port (for example TCP 3306 for MySQL or 5432 for PostgreSQL) from prod-sg-app only; restrict egress where feasible.
5. Remove overly broad default egress rules when workload connectivity is known; remember security groups are stateful. Do not use 0.0.0.0/0 inbound for database or administration ports.
6. Keep the default security group unused for workloads; audit its rules. Apply security groups to ENIs/resources, not directly to subnets.

Checkpoint: Only intended ALB traffic is public; app and database access are source-SG restricted. Security groups do not replace application authentication.

10. Add private AWS service access where required

1. In VPC > Endpoints > Create endpoint, consider an S3 Gateway endpoint for application and data subnet route tables if workloads need S3. Select prod-vpc, service com.amazonaws.us-east-1.s3, type Gateway, and appropriate route tables; apply a restrictive endpoint policy where supported.
2. Consider a DynamoDB Gateway endpoint similarly when used.
3. For workloads requiring private AWS API access (for example Systems Manager, CloudWatch Logs, ECR, Secrets Manager, KMS), evaluate corresponding Interface endpoints, associated private subnets, private DNS, and endpoint security groups allowing HTTPS TCP 443 from approved workloads.
4. Confirm each endpoint's availability in the chosen region, DNS requirements, pricing, and service-specific dependencies. Interface endpoints incur hourly/data charges. Do not create all endpoints automatically.
5. For isolated data subnets, confirm required service access is satisfied through endpoints or approved private routing; no default route remains.

Checkpoint: Required service calls work without exposing data subnets to internet egress.

11. Add observability and governance

1. Configure VPC Flow Logs (VPC > Your VPCs > select VPC > Flow logs > Create flow log) to the approved CloudWatch Logs or S3 destination. Set IAM delivery permissions, log format, retention, encryption, and cost controls per policy.
2. Ensure CloudTrail coverage for network configuration changes (typically an organization/account-level trail).
3. Consider AWS Config rules, GuardDuty, AWS Network Firewall, central DNS controls, AWS Firewall Manager, and IPAM based on organizational requirements; do not assume these are enabled.
4. Verify tags, owner, cost allocation, budget alerts, and approved architecture record. Consider dual-stack IPv6 separately if needed.

Checkpoint: Change auditability and traffic visibility are documented, with expected log/storage costs.

12. Verify the deployment

Use Console pages to complete this checklist:

• [ ] Correct account, region, VPC ID, VPC CIDR, DNS settings, and tags.
• [ ] Nine subnet IDs, expected CIDRs, correct AZs; app/data subnets do not auto-assign public IPv4.
• [ ] One attached IGW; three NAT gateways Available with three EIPs in public subnets.
• [ ] Seven explicitly created route tables; each of nine subnets explicitly associated with the correct table.
• [ ] Public route table has 0.0.0.0/0 -> IGW.
• [ ] Each app route table has 0.0.0.0/0 -> same-AZ NAT.
• [ ] Each data route table has no default route.
• [ ] All tables have VPC-local route; no blackhole routes.
• [ ] Least-privilege SG rules; no public database or management ingress.
• [ ] Required endpoints, flow logs, and organization guardrails configured or tracked as approved follow-up work.
• [ ] Billing impact and ownership documented.

For functional testing, launch only approved disposable test instances/resources with appropriate IAM and SG settings. Confirm (a) an app subnet instance can reach an approved external endpoint through NAT, (b) a data subnet instance cannot reach the public internet without an approved path, (c) approved VPC-internal app-to-db traffic works, and (d) disallowed traffic fails. Use VPC Reachability Analyzer for supported paths and review flow logs. Avoid assuming that routing alone proves application connectivity.

13. Handoff

Produce a completion report containing: account alias/ID (redact if sharing externally), region, VPC ID/CIDR, nine subnet names/IDs/CIDRs/AZs, IGW ID, NAT IDs/EIPs, seven route table IDs/associations/routes, security group IDs/rules, endpoint IDs, flow log destination, test results, cost considerations, outstanding approvals, and operator/date. Distinguish verified, not tested, and failed checks. Do not invent resource IDs.

Troubleshooting

Cleanup (only on explicit approval)

Never delete production networking casually. First confirm dependent resources and a change window. Remove test resources, endpoints, NAT-dependent app routes, NAT gateways, release unused Elastic IPs, delete custom route tables, detach/delete IGW, delete subnets, then delete VPC. Respect dependencies (ALBs, ENIs, RDS, ECS, etc.), and never release EIPs still required elsewhere. Record completion and check billing afterward.

Official AWS references

• Create a VPC
• Subnets
• Route tables
• NAT gateways
• VPC endpoints
• Security groups
• VPC Flow Logs