How to set up a VPC (cloud networking basics)

Every workload you migrate lands inside a virtual network, and its layout quietly decides your security posture, your availability, and how painful future growth is. Here is the design that works on all three major clouds, and the decisions behind it.

The same idea, three names

A VPC (Virtual Private Cloud) is your own isolated slice of the provider’s network: you choose the IP range, carve it into subnets, and write the rules for what talks to what. The concepts map almost one-to-one across providers:

Concept	AWS	Azure	Google Cloud
The network	VPC	Virtual Network (VNet)	VPC
Scope	Regional	Regional	Global (subnets are regional)
Subnet firewall attachment	Security groups (per instance)	Network security groups (per subnet or NIC)	Firewall rules (per network, by tag)
Outbound for private instances	NAT Gateway	NAT Gateway	Cloud NAT
Internet edge	Internet Gateway	Built in	Built in

The one structural difference worth knowing: a GCP VPC is global with regional subnets, while AWS and Azure networks live in one region. For a first deployment this changes little; the design below applies to all three.

Step 1: Plan the address space (the decision you cannot cheaply undo)

Choose a CIDR block from private RFC 1918 space, typically a /16 like 10.0.0.0/16 (about 65,000 addresses). Two rules:

• No overlap, ever, with anything you might connect to. The office network, the on-prem data centre you are migrating from, future VPCs, a partner VPN. Overlapping ranges cannot route to each other, and re-numbering a live network is weeks of work.
• Oversize it. Address space costs nothing. A /16 for the VPC with /24 subnets (251 usable addresses each) leaves room for years of growth; teams that start with a tight /24 VPC regret it at the first peering request.

If you expect several environments, allocate them now on paper: 10.0.0.0/16 for production, 10.1.0.0/16 for staging, 10.2.0.0/16 for dev. A ten-line registry beats a re-IP project. (Multi-account structure and who owns which network is landing zone territory.)

Step 2: Public and private subnets, across two availability zones

Split the VPC into subnets with two jobs:

• Public subnets hold the few things that must face the internet: load balancers, NAT gateways, maybe a bastion host.
• Private subnets hold everything else: application servers, databases, caches. Nothing here is reachable from the internet, which removes the most common breach path outright.

Then duplicate the pair across at least two availability zones, because high availability starts in the network layout: a subnet lives in exactly one zone, so surviving a zone outage requires subnets, and instances, in a second one.

A layout that serves most businesses for years:

Subnet	CIDR	Zone	Holds
public-a	10.0.0.0/24	a	Load balancer, NAT gateway
public-b	10.0.1.0/24	b	Load balancer, NAT gateway
private-app-a	10.0.10.0/24	a	Application servers
private-app-b	10.0.11.0/24	b	Application servers
private-data-a	10.0.20.0/24	a	Databases, caches
private-data-b	10.0.21.0/24	b	Databases, caches

That uses under 2 percent of the /16. Good.

Step 3: Route tables make subnets public or private

“Public” and “private” are not checkboxes; they are routing:

• The public route table sends 0.0.0.0/0 (everything non-local) to the internet gateway. Attach it to the public subnets.
• The private route table sends 0.0.0.0/0 to the NAT gateway. Attach it to the private subnets.

The NAT gateway is what lets private instances initiate outbound connections (OS updates, package installs, third-party APIs) while remaining unreachable from outside. It is also the first place a new cloud bill surprises people: roughly $32 per month per gateway plus about $0.045 per GB processed on AWS, with Azure NAT Gateway and GCP Cloud NAT in the same neighbourhood. One NAT gateway per zone is the resilient pattern (a zone outage otherwise takes down outbound traffic for surviving instances); one total is a defensible saving for small estates. Heavy traffic to provider services like S3 should bypass NAT entirely via gateway endpoints, which are free and remove that traffic from the per-GB meter.

Step 4: Security groups do the real firewalling

Security groups (AWS and GCP terminology; NSGs on Azure) are stateful firewalls attached to instances. Stateful means reply traffic is allowed automatically; you only write the “who may initiate” rules. The pattern that keeps rules maintainable:

• Reference groups, not IP addresses. Rule: the database group accepts port 5432 from the app-server group. Instances then inherit the right access by membership, and the rule survives every instance replacement and autoscale event.
• Chain the tiers. Load balancer group accepts 443 from the internet. App group accepts the app port only from the load balancer group. Data group accepts the database port only from the app group. Three rules describe the whole architecture.
• No inbound 0.0.0.0/0 on anything except the load balancer’s 443 (and 80 for redirects). Especially not SSH or RDP; use the provider’s session tooling (SSM Session Manager, Azure Bastion, IAP) instead of an open port 22.

Network ACLs (subnet-level, stateless) exist on AWS and Azure; leave them at defaults until you have a specific edge case. And write all of this as infrastructure as code (Terraform, CloudFormation, Bicep) from day one: a VPC is maybe 200 lines, and you get review, history, and an identical staging copy for free.

Common mistakes, quick list

• Using the provider’s default VPC for production (flat, permissive, unplanned addressing).
• A /16 that overlaps the office network, discovered the day the VPN goes up.
• Databases in public subnets “temporarily.”
• One availability zone everywhere, discovered during the zone outage.
• Security group rules pinned to individual IPs that stopped existing months ago.
• Nobody watching NAT data-processing charges; see avoiding bill shock.

FAQ

What IP range should a VPC use?

Pick a /16 from the private RFC 1918 space, such as 10.0.0.0/16, giving about 65,000 addresses. The only hard rule is no overlap with any network you will ever connect to: the office LAN, the on-prem data centre, other VPCs, a partner’s network. Keep a simple registry of which team uses which range. Address space is free; overlap is a re-numbering project.

What is the difference between a public and a private subnet?

Only the route table. A public subnet has a route to the internet gateway, so instances with public IPs are reachable from the internet. A private subnet has no such route; its instances reach out through a NAT gateway but cannot be reached from outside. Load balancers belong in public subnets; nearly everything else, especially databases, belongs in private ones.

Do we really need a NAT gateway? It looks expensive.

Private instances need one to reach the internet for updates, package installs, and external APIs. A managed NAT gateway runs about $32 per month plus about $0.045 per GB processed on AWS, and similar on Azure and GCP. One per availability zone is the resilient setup; one total is an accepted cost saving for smaller estates. The alternative of giving everything public IPs saves that money by giving up the security model.

Security groups vs network ACLs: which should we use?

Security groups (NSGs on Azure, firewall rules on GCP) do almost all the work: they are stateful, attach to instances, and can reference other groups, which is how you express app-tier-to-database rules cleanly. Network ACLs are stateless subnet-level filters best left at their defaults until you have a specific need, such as blocking a hostile IP range at the subnet edge.

---

Designing the network your migration will land in? Talk to a Webisoft cloud engineer. We’ll review your CIDR plan, subnet layout, and security group design before anything is built, when changes are still free.