Every AWS account ships with a default VPC in every region. Every subnet in that VPC is public. Every EC2 instance launched into it gets a public IP address unless you explicitly say otherwise. And if your startup is like most early-stage teams, your production database, your application servers, and your internal tooling are all sitting in that default VPC right now — reachable from the internet by design, separated from each other by nothing.
This is not a theoretical risk. It is the single most common architectural debt I see in early-stage cloud environments, and it is the one that hurts most when it finally matters — during a breach investigation, a SOC 2 readiness assessment, or the moment your infrastructure needs to support ten times the traffic it was built for.
The good news: fixing it is not a rewrite. It is soil work — foundational, methodical, and worth every hour you invest before the pressure arrives.
Why the Default VPC Is a Trap, Not a Shortcut
AWS created the default VPC so that new users could launch resources immediately without understanding networking. That design decision optimized for onboarding speed, not for production safety. Here is what you inherit when you leave everything in place:
- Every subnet is public. The default VPC creates one subnet per Availability Zone, and each one has a route to an Internet Gateway. Any resource placed in these subnets is routable from the public internet unless a security group explicitly blocks inbound traffic.
- Security groups are your only boundary. Without private subnets, NACLs configured for defense in depth, or any network segmentation, a single misconfigured security group rule is the difference between a locked-down service and a publicly exposed database.
- No separation between workloads. Your staging environment, your production API, your internal admin panel, and your CI/CD runners all share the same flat network. Lateral movement after a compromise is trivial.
- No foundation for compliance. SOC 2, HIPAA, PCI — every framework your future customers or investors will ask about assumes network segmentation as a baseline control. Retrofitting it under audit pressure is expensive and stressful.
The default VPC is a prototype environment shipped as a convenience. Treating it as production architecture is like building a house on a slab poured for a garden shed. It will hold weight — until it will not.
Private vs Public Subnets: The Line That Changes Everything
The most important concept in AWS network architecture is the distinction between public and private subnets, and it is simpler than most teams assume.
A public subnet has a route table entry pointing to an Internet Gateway. Resources in it can send and receive traffic directly from the internet. A private subnet has no such route. Resources in it can only reach the internet through a NAT Gateway (for outbound calls like pulling packages or calling third-party APIs), and nothing on the internet can initiate a connection to them.
That single architectural decision — which subnets are public, which are private — determines your entire security posture. When designed correctly:
- Your load balancers and bastion hosts live in public subnets. They are built to be internet-facing, hardened accordingly, and they are the only entry points.
- Your application servers, databases, caches, queues, and internal services live in private subnets. They are unreachable from the internet by network design, not just by security group configuration.
- Your CI/CD runners, observability collectors, and internal tooling live in their own private subnets, segmented from production workloads.
This is defense in depth at the network layer. A misconfigured security group on a database in a private subnet does not expose it to the internet, because the network itself has no route for that traffic. You have removed an entire class of failure.
Cloud Network Segmentation: Think in Layers, Not Permissions
Security groups are necessary. They are not sufficient. Real cloud network segmentation works in layers, and each layer catches failures that the others miss.
Layer 1: VPC and Subnet Architecture
Design a custom VPC with a CIDR block sized for your growth trajectory. A /16 gives you 65,536 addresses — more than enough for most startups, and it leaves room to carve out subnets cleanly. Create at least three tiers of subnets across multiple Availability Zones:
- Public tier — load balancers, NAT Gateways, bastion hosts
- Application tier — compute workloads (ECS tasks, EKS pods, EC2 instances running your application code)
- Data tier — RDS instances, ElastiCache clusters, any persistent storage
Each tier gets its own subnets and its own route tables. The application tier routes outbound traffic through a NAT Gateway. The data tier may have no internet route at all — it communicates only with the application tier via internal routes.
Layer 2: Network ACLs
NACLs are stateless firewalls applied at the subnet level. They are coarser than security groups but serve as a backstop. Use them to enforce broad rules: the data tier subnets should deny all inbound traffic except from the application tier CIDR ranges. If someone accidentally opens a security group too wide, the NACL catches it.
Layer 3: Security Groups
Now security groups do what they do best — granular, stateful rules at the resource level. Reference other security groups by ID instead of CIDR blocks where possible. Your application security group allows inbound traffic from the load balancer security group. Your database security group allows inbound traffic from the application security group. No IP addresses to manage, no ranges to keep in sync.
Layer 4: VPC Endpoints and Private Connectivity
Every call your application makes to S3, DynamoDB, SQS, or Secrets Manager can traverse a VPC endpoint instead of leaving your VPC and routing through the public internet. Gateway endpoints for S3 and DynamoDB are free. Interface endpoints for other services cost a few dollars per month and keep your data plane traffic entirely within the AWS network. This matters for both security and latency.
Infrastructure as Code: The Only Way This Stays Correct
A well-designed VPC created through the AWS console is already drifting the moment someone makes a manual change. This is where infrastructure as code earns its keep — not as a DevOps best practice in the abstract, but as the mechanism that makes your network architecture reproducible, auditable, and version-controlled.
Define your VPC, subnets, route tables, NACLs, security groups, NAT Gateways, and VPC endpoints in Terraform or a similar declarative tool. Store the configuration in Git. Require pull request review before any change merges. Run a plan step in CI so the team sees exactly what will change before it is applied.
This approach gives you three things that manual configuration never will:
- Reproducibility. Need a staging environment that mirrors production networking? Apply the same module with different variables. Need to stand up a disaster recovery VPC in another region? Same code, different provider block.
- Audit trail. Every change to your network architecture is a commit with a timestamp, an author, and a review. When an auditor asks who opened port 443 on the public subnet NACL, the answer is in your Git history.
- Drift detection. Run periodic plans against your live state. If someone makes a console change — and someone always does — the diff surfaces it before it becomes a hidden liability.
At FigTree, our own infrastructure runs on this exact pattern. The Kubernetes cluster, the GitOps pipelines, the observability stack — every component is declared in code, reviewed before merge, and applied through automated pipelines. We build this way because we have seen what happens at scale when the alternative is a VPC that exists only as tribal knowledge in the head of an engineer who left the company two years ago.
The Migration Path: From Default VPC to Production-Grade Networking
If you are reading this and recognizing your own infrastructure, the path forward is not a weekend project and it is not a six-month initiative. For most early-stage teams, the work falls into a focused engagement measured in weeks, not months.
Step 1: Inventory and Map
Document every resource in the default VPC. Map the dependencies: what talks to what, on which ports, in which direction. This step alone often reveals surprises — internal services exposed to the internet that nobody realized were public, or database ports open to 0.0.0.0/0 because a frustrated engineer needed connectivity at 2 AM and never cleaned it up.
Step 2: Design the Target Architecture
Define the custom VPC, the subnet tiers, the routing, the security group strategy. Size the CIDR blocks with room for growth. Decide on single-NAT-Gateway (cheaper, less resilient) or NAT-per-AZ (more expensive, eliminates a single point of failure). This is architecture work, and the decisions you make here will live in your infrastructure for years.
Step 3: Build in Code, Test in Isolation
Stand up the new VPC with infrastructure as code. Deploy a non-critical workload into it first. Validate connectivity, DNS resolution, outbound internet access through NAT, and VPC endpoint routing. Get comfortable with the new topology before you move anything that matters.
Step 4: Migrate Workloads Methodically
Move services one at a time, starting with the most self-contained. For stateless application servers behind a load balancer, this can be as smooth as launching new instances in the new VPC and draining traffic from the old ones. For databases, it requires more care — RDS supports subnet group changes in some scenarios, but a snapshot-and-restore into the new VPC is often cleaner and gives you a rollback point.
Step 5: Decommission and Lock Down
Once everything has migrated, remove the resources from the default VPC. Consider deleting the default VPC entirely in every region you do not use — it removes a landing zone for any accidentally launched resources. For the regions you do use, delete the default VPC once your custom VPC is proven.
The Real Cost of Waiting
The default VPC security risks compound over time. Every new service deployed into a flat, public network adds another resource to migrate later and another potential exposure today. Every month without network segmentation is a month where a single security group misconfiguration could expose customer data. And every compliance framework your next enterprise customer requires will ask for network controls that the default VPC cannot demonstrate.
The work is foundational. It is not glamorous. But it is the difference between infrastructure that holds under pressure and infrastructure that cracks at the worst possible moment.
Related service: Cloud infrastructure and DevOps services in Tampa Bay — what we build, how we work, and what it costs.
Build the Roots Before You Need the Reach
VPC design for startups is not about over-engineering for hypothetical scale. It is about getting the network foundations right so that growth, compliance requirements, and security incidents do not force a panicked rebuild. The teams that invest in this soil work early are the ones whose infrastructure can support what comes next — whether that is a Series B, a SOC 2 audit, or a traffic spike that would have broken a flat network.
If your production workloads are still running in the default VPC and you are not sure where to start, we can help you map what you have, design where you need to be, and build the path between the two — all in code, all reviewed, all built to hold.
Book a free 20-minute discovery call with us at FigTree Development. We will look at your current architecture together and give you an honest assessment of the work involved — no pressure, no surprises, just a grounded conversation about what your infrastructure needs to scale with you.