Skip to main content
IMHCloud Logo
Back to glossary

Virtual Private Cloud

A Virtual Private Cloud (VPC) is an isolated network environment within a public cloud provider where you control IP addressing, subnets, routing tables, and security rules for your cloud resources.

What is a Virtual Private Cloud in cloud hosting?

A Virtual Private Cloud (VPC) is an isolated network segment within a public cloud provider's infrastructure. You define the IP address range, create subnets, configure routing tables, and set security rules that apply only to your resources. Other cloud customers cannot see or access your VPC network unless you explicitly allow it.

When you launch cloud resources such as instances (virtual machines), databases, or load balancers, they connect to your VPC. The VPC acts as a private network boundary, controlling which traffic can enter, leave, or move between your resources. You retain full control over network topology without managing physical hardware.

Why Virtual Private Clouds Exist

Before VPCs, cloud resources shared a flat network with other customers. This created security concerns because traffic could potentially be visible to or intercepted by neighboring tenants. Configuring network isolation required complex workarounds or additional services.

VPCs solve this by giving each customer a logically separate network. You choose your own IP ranges, which means you can match your on-premises addressing scheme. You control exactly which resources can communicate and how traffic flows. Without VPCs, running sensitive workloads in a public cloud would require trusting shared network infrastructure you cannot inspect or configure.

What Do Virtual Private Clouds Actually Do?

  • Allocates a private IP address range (CIDR block) that only your resources use within that VPC
  • Divides the address range into subnets that you assign to different availability zones or functions
  • Routes traffic between subnets based on routing table rules you configure
  • Blocks all inbound traffic from the internet by default until you attach an internet gateway and update routes
  • Isolates your network from other cloud customers at the hypervisor and software-defined networking layer
  • Allows you to connect the VPC to your on-premises data center via VPN or dedicated connection
  • Enables you to peer two VPCs together so resources in each can communicate using private IP addresses

When would I use a Virtual Private Cloud?

You would use a VPC when you need network isolation for your cloud workloads. Common situations include:

  • Running production applications that handle customer data and require separation from public internet by default
  • Deploying a multi-tier architecture where web servers, application servers, and databases each belong to different subnets with different access rules
  • Connecting cloud resources to an existing on-premises network so they appear on the same logical network
  • Hosting multiple environments (development, staging, production) in separate VPCs to prevent accidental cross-environment access
  • Complying with regulatory requirements that mandate network segmentation and controlled access paths

When would I not use a Virtual Private Cloud?

A VPC adds configuration overhead. If you are testing a single instance for a short time and do not need network isolation, you may use a simpler default network provided by some cloud platforms.

VPCs require planning. If you choose an IP range that overlaps with your on-premises network, you cannot easily connect them later. Changing the CIDR block of an existing VPC is often impossible without recreating it.

If all your resources need direct public internet access and you have no internal communication requirements, a VPC provides limited benefit beyond default isolation. However, most production workloads benefit from the control a VPC provides.

Real-world example

Company A runs an e-commerce platform on InMotion Cloud. They create a VPC with the IP range 10.0.0.0/16, giving them 65,536 possible addresses. They divide this into three subnets:

  • 10.0.1.0/24 (public subnet): Holds the load balancer that accepts HTTPS traffic from customers
  • 10.0.2.0/24 (private subnet): Holds the application servers that process orders
  • 10.0.3.0/24 (private subnet): Holds the database server that stores customer and order data

The routing table for the public subnet sends internet-bound traffic to an internet gateway. The private subnets have no route to the internet gateway, so the application and database servers cannot be reached from outside. Security groups allow the load balancer to forward traffic to application servers on port 8080, and application servers to query the database on port 5432. No other traffic is permitted.

This setup ensures that even if an attacker knows the database server's private IP address, they cannot reach it from the internet. All external traffic must pass through the load balancer first.

Frequently Asked Questions

Do I need more than one VPC? One VPC is sufficient for many workloads. Multiple VPCs are useful when you want hard isolation between environments (such as production and development) or between different business units. Each VPC operates independently, so a misconfiguration in one does not affect another.

Does creating a VPC cost money? Most cloud providers do not charge for the VPC itself. Costs come from the resources you place inside it (instances, storage, data transfer) and optional features like NAT gateways or VPN connections. Check your provider's pricing for specific components.

Can I change my VPC's IP range after creating it? No. The primary CIDR block of a VPC is fixed at creation. Some providers allow you to add secondary CIDR blocks, but you cannot remove or change the original range. Plan your IP addressing before creating the VPC.

What happens if I delete a VPC? You must first remove all resources inside the VPC (instances, subnets, gateways, security groups). Once empty, you can delete the VPC. Any IP addresses or configurations defined in that VPC are permanently removed.

Can resources in different VPCs communicate? By default, no. VPCs are isolated from each other. To allow communication, you must set up VPC peering, a transit gateway, or a VPN connection between them. Each option has different complexity and cost implications.

Summary

  • A Virtual Private Cloud (VPC) is an isolated network within a public cloud where you control IP addressing, subnets, routing, and security rules
  • VPCs separate your resources from other cloud customers and block unauthorized traffic by default
  • You divide a VPC into subnets that group resources by function or security requirements
  • VPCs enable secure multi-tier architectures, hybrid cloud connections, and regulatory compliance
  • Planning your IP address range before creating a VPC is important because it cannot be changed later

Related terms

  • Subnet: A smaller network range within a VPC that groups resources by function or access level, such as placing web servers in a public subnet and databases in a private subnet.
  • Security group: A set of firewall rules attached to specific resources that controls which ports and IP addresses can send or receive traffic, such as allowing TCP port 443 from any address for HTTPS.
  • Routing table: A list of rules that determines where network traffic goes when it leaves a subnet, such as directing internet-bound traffic to an internet gateway.
  • Internet gateway: A component that connects your VPC to the public internet, such as enabling your web server to receive requests from external users.
  • Network ACL (Access Control List): A subnet-level firewall that filters traffic before it reaches individual resources, such as blocking all traffic from a specific IP range.

Related Terms

Read definition

Multi-Tenancy

Multi-tenancy is a cloud architecture where multiple customers share the same physical infrastructure while remaining logically isolated from each other, enabling efficient resource utilization and cost sharing.

Infrastructure
Learn more
Read definition

Project

A project is an isolated resource container in OpenStack that groups users, instances, networks, storage, and other cloud resources under a single administrative boundary with defined quotas and access controls.

Infrastructure
Learn more