Cloud Network Design: VPCs, Subnets, and Sane Defaults

Start with the address plan, not the first VPC

The most expensive cloud networking mistakes are made in the first hour, before a single workload ships, when someone accepts the default 10.0.0.0/16 the console suggests and moves on. That default is fine for exactly one VPC that never talks to anything else. The moment you add a second VPC, peer to a partner, connect a VPN back to the data center, or acquire a company, overlapping address space becomes a months-long project to unwind, because you cannot route between two networks that both think they own 10.0.0.0/16.

Plan the whole address space first, on paper, as if you already have twenty VPCs. A workable pattern:

• Reserve a large private block for all cloud use — for example 10.0.0.0/8 or a 10.x range you carve deliberately — and never let a team allocate outside it.
• Give each region and each environment a predictable slice. A /16 per VPC, split into /20 or /24 subnets, leaves room to grow without renumbering.
• Leave gaps. Contiguous, fully-packed allocation looks tidy and guarantees pain the first time a VPC needs a bigger subnet.
• Write the plan down in one authoritative place and treat it as code. Overlap discovered after workloads are live is the single most common reason a cloud network cutover requires downtime.

CIDR planning is not glamorous, but it is the foundation everything else routes on. Get it wrong and every subsequent decision inherits the constraint.

Public and private subnets, and what actually belongs in each

A subnet is not public or private because of a name. It is public if its route table sends 0.0.0.0/0 to an internet gateway, and private if it does not. That distinction decides what any host in the subnet can reach and be reached by, so put almost nothing in the public tier.

• Public subnets should hold only the things that genuinely need an inbound path from the internet: load balancers, a bastion or managed connection service, and NAT. Nothing else.
• Private subnets hold everything that matters — application servers, containers, and especially databases and internal services, which should have no route to or from the internet at all.

Figure: the public tier holds only load balancers and NAT; everything of value lives in private tiers where no inbound internet path exists.

Spread each tier across at least two, preferably three, availability zones. A subnet lives in exactly one zone, so single-zone designs fail the moment that zone has a bad day. The layout that ages well is a small public tier, a larger private application tier, and an isolated data tier — repeated per availability zone — so that losing a zone degrades capacity rather than causing an outage. This tiering is the cloud expression of the same segmentation discipline covered in our network security practice.

NAT and egress: control what leaves, not just what enters

Teams obsess over inbound rules and wave through outbound traffic. Attackers rely on exactly that asymmetry. Once a workload is compromised, unrestricted egress is how malware calls home, how data is exfiltrated, and how a foothold becomes a breach.

Private subnets reach the internet for patches and API calls through a NAT gateway sitting in the public tier. Two things to get right:

• Cost. Managed NAT gateways charge per hour and per gigabyte processed. A busy environment pushing terabytes through NAT can run a surprising monthly bill. Route traffic to in-cloud services through private endpoints instead of NAT wherever possible, and consolidate rather than deploying one NAT per subnet without thinking.
• Control. NAT gives outbound reachability, not outbound governance. For egress you can actually inspect and filter — allow-listing which domains a workload may reach and logging the rest — route outbound through a firewall or proxy. Default-deny egress from sensitive tiers is one of the highest-value, least-deployed controls in cloud networking.

Security groups versus NACLs — use both, for different jobs

Two mechanisms filter traffic in a VPC, and confusing them produces either false security or hours lost debugging.

1. Security groups are stateful and attach to a workload — an instance, a container task, a database. Allow the return traffic automatically, they are the right place to express intent: "this app tier may reach this database on 5432, and nothing else may." Reference security groups by ID rather than IP so the rule follows the workload as addresses churn.
2. Network ACLs are stateless and attach to a subnet. Because they evaluate every packet in both directions and support explicit deny, they are a coarse backstop — for example, blocking a known-bad range at the subnet edge — not your primary control. Their statelessness means you must open ephemeral return ports manually, which is a classic source of mysterious failures.

The working model: security groups do the real, least-privilege work close to each workload; NACLs provide a blunt secondary boundary at the subnet. Reaching for NACLs to express fine-grained application policy is a sign the security-group design needs attention.

Private endpoints keep traffic off the internet entirely

Every call from a private workload to a cloud storage bucket, a queue, or a managed database does not need to traverse a public path. Private endpoints and PrivateLink project a service directly into your VPC as a private IP, so the traffic never leaves the cloud provider's backbone.

• Access managed services (object storage, databases, secrets) through their private endpoint rather than a public URL. Traffic stays private, and you can drop the NAT egress those calls would otherwise consume.
• Expose your own internal services to another VPC or a partner through PrivateLink instead of peering entire networks. The consumer sees one endpoint, not your whole address space, which is both cleaner and far tighter than opening a route between two full VPCs.

This is a core habit in a defensible cloud posture — the fewer paths that touch the public internet, the smaller your attack surface, a principle we build into every cloud security engagement.

Connecting many VPCs without a spaghetti of peerings

Peering two VPCs is easy. Peering twenty is a full mesh of connections nobody can reason about, because VPC peering is non-transitive — A peered to B and B peered to C does not let A reach C. Past a handful of VPCs, move to a hub.

• A transit gateway (AWS) or virtual WAN hub (Azure) is a central router every VPC attaches to once. Connectivity, on-premises links, and inspection are configured in one place instead of N-times-N peerings.
• The hub is also the natural chokepoint for centralized egress filtering and for terminating VPN or direct-connect links back to physical sites — the same hub-and-spoke discipline we apply when designing cloud infrastructure that spans regions and data centers.
• Keep routing intentional. A hub makes any-to-any trivial, which is exactly why you should not enable it. Segment route tables so production cannot reach development and a partner attachment reaches only what it is entitled to.

Hub-and-spoke scales to hundreds of VPCs, gives you one place to inspect east-west traffic, and keeps the routing table something a human can still audit.

DNS is part of the network, not an afterthought

More cloud connectivity tickets trace back to name resolution than to routing. Private endpoints, hybrid links, and split-horizon setups all depend on DNS resolving the same name to the right address from every vantage point.

• Use a private hosted zone for internal names, and confirm that both cloud workloads and on-premises clients resolve them consistently — split-horizon mismatches are a top hybrid-cloud failure mode.
• Private endpoints only deliver their benefit when the service's public name resolves to the private IP inside your VPC. Verify the resolver override actually took effect, per VPC.
• Centralize outbound and inbound DNS resolution at the hub so hybrid name resolution has one predictable path rather than per-VPC guesswork.

Sane defaults we deploy

The point of a good design is that the safe choice is also the default choice. Before the first workload lands, we set:

• A documented, non-overlapping CIDR plan covering every planned region and VPC.
• Multi-AZ public, private-application, and private-data tiers, with almost nothing in the public tier.
• Databases and internal services with no route to the internet, reached only through private endpoints.
• Default-deny egress on sensitive tiers, with outbound routed through inspection.
• Security groups referencing each other by ID for least-privilege east-west traffic, and NACLs as a coarse backstop only.
• A hub for multi-VPC and hybrid connectivity, with segmented route tables rather than open any-to-any.
• VPC flow logs and DNS query logging enabled and shipped to monitoring from day one.

Where to start

If you already run cloud networks, do not rebuild everything at once. Audit for the two failures that cause the most damage first: overlapping CIDR ranges that will block your next integration, and private workloads with an unnecessary path to the internet. Fixing those two removes most of the risk and most of the future pain.

Cloud network design is one of those foundations that is invisible when it is right and enormously expensive to change when it is wrong. intSignal designs VPC and multi-cloud networks the way they should be built — address plan first, private by default, egress under control, and connectivity you can actually audit. If you want a review of your current topology and a sequenced plan to fix what will not scale, talk to our team.