Virtual Private Cloud (VPC)

A virtual private cloud is a logically isolated network inside a public cloud provider, with an address range you choose and full control over routing, subnets and traffic rules. Resources launched into it can talk to each other privately, and nothing reaches the public internet unless you deliberately provide a path. It is the boundary most cloud security architecture is built on. The standard layout separates subnets by exposure: a public subnet holding only the load balancer and other things that must accept inbound traffic from the internet, and private subnets holding application servers, databases and caches with no route in from outside. Access to a private resource then happens through the load balancer, a bastion, or an identity-aware proxy — never by opening a database port to the world, which remains one of the most common causes of data exposure. Two things are worth stating for teams new to it. Network isolation is necessary but not sufficient: inside a VPC, service-to-service traffic still needs authentication, since a single compromised workload otherwise gains a flat internal network. And the VPC boundary is where several other concerns are enforced in practice — private connectivity to managed services and SaaS vendors, egress control over what your workloads may call out to, and the traffic logging that makes an incident reconstructable after the fact. For buyers, whether a vendor can deploy into or peer with your own VPC is often a decisive procurement question.