What it is
A virtual private cloud is a private network inside a public cloud. You define an IP range. You split it into subnets. You attach route tables, gateways and security rules. The provider runs the hardware. You own the design and the rules.
Think of it as a software-defined data center network without the switches. On premises you might use VLANs and a firewall. In a VPC you use subnets and security groups. The boundary is logical, not physical. Two VPCs can share hardware and stay isolated.
Providers differ. AWS calls it a VPC and scopes it to a region. Azure calls it a virtual network and scopes it to a region. Google Cloud calls it a VPC and makes it global, with regional subnets. The concepts are similar. The details matter when you design for growth.
How it works
Start with a CIDR block, for example 10.0.0.0/16. That gives you 65,536 addresses. Carve it into subnets, such as /24 blocks for web, app and data tiers. Each subnet lives in one availability zone. A subnet is public if its route table sends 0.0.0.0/0 to an internet gateway. A subnet is private if it sends that traffic to a NAT gateway or has no default route.
Route tables are the traffic cops. Every subnet associates with one. The most specific route wins. Security groups are stateful firewalls attached to network interfaces. Network ACLs are stateless filters on subnets. Use security groups for most rules. Use NACLs for a coarse extra layer when you need it.
VPC peering connects two VPCs directly. A transit gateway or hub VPC centralizes routing across many VPCs and on-premises links. VPC endpoints let you reach cloud services such as object storage without going over the internet or through NAT. Flow logs record accepted and rejected traffic. Private DNS zones resolve internal names.
Why it matters for a business
Segmentation limits blast radius. Put payment data in its own subnets with tighter rules. Put development in a separate VPC. If a test instance is compromised, it cannot reach production databases by default. That is a control auditors ask about, and it is easier to explain than a flat network.
It shapes cost and performance. NAT gateways bill by the hour and by data processed. VPC endpoints remove that traffic and keep it private. Cross-zone traffic can add cost. Putting chatty services in the same zone can cut latency and spend. The network design decides much of this before a single server runs.
It clarifies ownership. A VPC maps to accounts, teams and environments. Finance can tag a VPC and see spend. Security can review route changes. Operations can reason about failure domains. When you acquire a company, overlapping IP ranges are a real integration problem. A written plan saves weeks later.
Common mistakes
Overlapping IP ranges. Many teams pick 10.0.0.0/16 in every environment, then cannot peer or connect to the office VPN. Write an IP plan first. Reserve space for cloud, data centers, partners and future regions. Avoid ranges that carriers or home networks use.
A flat network. One VPC, one subnet, everything open. This is easy at first and painful at audit time. Split by tier and environment. Put databases in private subnets with no internet route. Use a bastion or session manager for admin access instead of exposing SSH.
Ignoring operations. No flow logs, no tagging, no change control. Network changes break more things than application deploys. Review route and security group changes like code. Test them in a staging VPC. Keep a diagram that matches reality, and update it when peering links change.
How to get started
Write a one-page IP and subnet plan. List regions, environments, and which systems need internet exposure. Choose a small set of VPCs: often one per environment or one shared services VPC. Define naming and tags. Get security and finance to agree before you build.
Build with infrastructure as code from day one. Terraform, CloudFormation or Bicep. Create the VPC, subnets, route tables, NAT gateways and flow logs in a module. Keep the state file locked and backed up. Run a plan review for every change. This makes the network reproducible and testable.
Pilot with one workload. Deploy a web app with a public load balancer and private app and database subnets. Turn on flow logs. Test from inside and outside. Then expand. If you want help with the design, a structured option is the Cloudverg Discovery and roadmap sprint at $9,500/month, which produces an architecture, diagrams and a phased plan you keep. You can also use a solutions architect from your cloud provider, an independent consultant or your own team. Pick based on the skills you already have.
Frequently asked questions
Is a VPC the same as a private cloud?
No. A VPC is a network you define inside a public cloud. A private cloud is infrastructure dedicated to one organization, often in your own data center. A VPC still runs on shared provider hardware.
Do I need a separate VPC for every application?
Usually no. Separate VPCs add peering and routing work. Start with one VPC per environment or business unit, then split when you need strong isolation, different network owners, or separate compliance boundaries. Use subnets and security groups for most separation.
How large should my VPC CIDR be?
Choose a range that leaves room to grow. A /16 gives 65,536 addresses and is common for production. Subnets of /24 give 256 addresses, enough for most workloads but tight for Kubernetes pods. Avoid ranges that overlap your offices, VPNs or partners, and document the plan.