A virtual private cloud (VPC) is a private, logically isolated network that you create inside a public cloud provider. Within it you choose the IP address ranges, divide them into subnets, and control routing, firewall rules and connections to the internet, your offices or other networks. The servers, databases and other resources you place there communicate over this network. The physical hardware underneath is usually shared with other customers; the isolation is enforced by the provider’s software.
At a glance
- A VPC is your own network inside a public cloud, isolated from other customers’ networks by the provider’s software.
- You set the address ranges, subnets, route tables and firewall rules; resources are exposed to the internet only if you configure them to be.
- Subnets are usually placed in specific availability zones, which matters for resilience.
- Private connections to offices and data centers run over a VPN or a dedicated cloud interconnect.
- The name varies by provider; Microsoft Azure calls the equivalent a virtual network.
What problem it solves
When a company runs servers in a public cloud, those servers need a network, and that network has to be separated from other customers and from the open internet. The VPC model gives each customer its own isolated network space, so protection does not depend on per-server settings alone.
A VPC lets a team recreate the familiar structure of a corporate network in the cloud: private address space, segmented subnets for web, application and database tiers, controlled internet access, and private links back to the office. It is the network foundation of most Infrastructure as a Service (IaaS) deployments, and getting its design right early saves painful rework later.
How it works
Address space and subnets. You assign the VPC a private IP range and split it into subnets. A subnet is commonly called public when its route table points to an internet gateway, but a resource in it is directly reachable from the internet only if it also has a public IP address or an inbound mapping (such as through a load balancer) and security rules permit the traffic. Subnets intended to stay private typically have no such inbound path and may reach outward through an address-translating gateway. Exact models vary by provider.
Routing. Route tables decide where traffic from each subnet goes: to other subnets, to an internet gateway, to a VPN, to a private interconnect or to another VPC.
Security controls. Firewall-style rules can be applied at the subnet level and to individual resources. These are the main tools for network segmentation in the cloud.
Connecting outward. VPCs can connect to each other (peering, or a central transit hub), to your offices over an IPsec VPN, and to data centers over private links of the kind described under cloud connectivity. Providers charge for some of these paths and for data passing through them.
Logging. Flow logs record which connections were attempted and allowed, which is useful for troubleshooting and security investigation; they are usually optional and may be billed.
To connect your network to cloud VPCs privately, see our cloud connect solution page.
When it matters for buyers
- Before the first production workload. Plan address ranges that do not overlap with offices, data centers or other clouds; overlapping ranges are hard to fix later.
- When connecting offices to the cloud. Decide between internet VPNs and private interconnects based on traffic volume, consistency needs and data transfer cost.
- During security reviews. Overly broad firewall rules and resources placed in public subnets by mistake are common audit findings.
- When the estate grows. Dozens of VPCs connected ad hoc become hard to manage; a hub design and clear ownership help.
- When designing for resilience. Spread subnets and workloads across availability zones so one zone’s failure does not take down the whole service.
Questions to ask vendors
- What isolation does the VPC provide from other customers, and how is it enforced?
- What does it cost to send data between subnets, availability zones, VPCs and regions, and out to the internet?
- What options exist for private connections from our offices and data centers, and what are their speeds and SLAs?
- How many VPCs, subnets and routes can we create before hitting limits?
- What logging is available for network traffic, and how is it priced?
- Can we use IPv6, and can we bring our own public IP addresses?
- If a partner or managed service provider builds our network, who owns the design documentation and the accounts?
How it differs from private cloud
The words “private cloud” appear in both terms, which causes confusion. A private cloud, one of the deployment models described under public, private and hybrid cloud, is infrastructure operated for a single organization, whether in its own data center or hosted by a provider. A VPC is a network construct inside a public cloud: your address space and traffic rules are private to you, but the servers and network hardware underneath are usually shared. Some providers sell dedicated hosts that can be placed in a VPC, but that is an add-on, not what makes it a VPC.