Why VPC Is the Foundation Every Cloud Product Is Built On
Gagan Kataria
When businesses decide to move their products or workloads to the cloud, the conversation usually starts in the right place — which cloud provider, which region, what services. AWS, GCP, Azure. Mumbai, Singapore, US East. Compute, storage, managed databases.
But there is one foundational decision that often gets made too quickly, or too late, or not deliberately enough. And it is the one that everything else sits on top of.
That decision is your Virtual Private Cloud — your VPC.
Get it right at the start and it becomes invisible infrastructure, quietly doing its job. Get it wrong and you will spend months untangling security vulnerabilities, paying for avoidable data transfer costs, and rebuilding network architecture under pressure while your product is already in production.
This post explains what a VPC is, why it matters for any serious cloud product, and how we think about it at Enerasoft when we design and build cloud-native software.
What Is a VPC — Without the Jargon
Here is the simplest way to think about it.
Imagine a busy office building where dozens of companies share the same floors, elevators, and corridors. The building is the public cloud — shared infrastructure owned by AWS or Google or Microsoft. Now imagine your company gets its own floor, with its own locked doors, its own internal layout, and its own rules about who can come in and what they can access. That floor is your VPC.
A VPC gives you your own private, isolated network within the public cloud — where you control who enters, what can talk to what, and what reaches the outside world.
More precisely, a Virtual Private Cloud is a logically isolated segment of a cloud provider's infrastructure where you can deploy resources — virtual machines, databases, application servers, containers — inside a network that you define and control. Other tenants on the same cloud infrastructure cannot see or reach your VPC unless you explicitly allow it.
The key word is isolated. You get the scale and economics of the public cloud, but with the privacy and control of a private data centre — without having to actually build or maintain one.
How a VPC Is Structured
A VPC is not just a single network boundary. Inside it, you have building blocks that let you design how traffic flows, what is visible to the internet, and what stays completely private.
Subnets — Public and Private
Within your VPC, you carve out subnets — smaller network segments. The most important distinction is between public subnets and private subnets.
- Public subnets host resources that need to be reachable from the internet — your load balancers, API gateways, and web servers.
- Private subnets host everything that should never be directly exposed — your application servers, databases, internal microservices, and queue processors.
At Enerasoft, every product we deploy follows this pattern. The database never sits in a public subnet. Ever.
Security Groups and Network ACLs
Security Groups act as virtual firewalls at the resource level — controlling which ports and protocols can send traffic to or from a specific server or service. Network ACLs operate at the subnet level, adding another layer of traffic filtering.
Together, they let you define rules like: only the application server can talk to the database on port 3306, and only the load balancer can reach the application server on port 8080. Nothing else gets through.
Internet Gateway and NAT Gateway
An Internet Gateway connects your VPC to the public internet — but only for the resources in public subnets that you explicitly route through it. Resources in private subnets have no direct internet access by default.
A NAT Gateway allows resources in private subnets to initiate outbound connections to the internet — to download updates or call external APIs — without exposing them to inbound internet traffic. This is a critical distinction that many early cloud deployments miss.
VPC Peering and Private Endpoints
When you have multiple VPCs — for different environments, different products, or different client workloads — VPC Peering lets them communicate privately without traffic ever touching the public internet. Private Endpoints let your VPC communicate with cloud managed services like storage buckets or managed databases over the private network rather than the public internet.
Why VPC Is Non-Negotiable for Any Serious Cloud Product
There are five reasons we consider VPC configuration a first-day, non-negotiable decision on every project at Enerasoft. Not a Week 4 consideration. Not something to revisit after the MVP launches. Day one.
1. Security Is Architecture, Not Configuration
The most expensive mistake in cloud security is treating it as something you add on top of an existing architecture rather than designing it in from the start. A VPC forces you to make security decisions at the network level — before a single application is deployed.
Without a properly configured VPC, you risk deploying databases with public IP addresses, running services with no firewall rules, and relying entirely on application-level authentication to protect resources that should never be reachable in the first place.
💡 At Enerasoft: Every product we ship runs in a VPC with clearly defined public and private subnet separation. Our databases connect to application servers via private network paths — never over the public internet.
2. Compliance Requires It
If your product handles financial data, health records, personal information, or any data covered by GDPR, India's DPDP Act, PCI-DSS, or ISO 27001, network isolation is not optional — it is a compliance requirement.
Auditors and enterprise clients will ask how your data is network-isolated. A well-designed VPC is the answer. For Enerasoft's enterprise clients, VPC architecture is frequently a prerequisite for a security questionnaire sign-off before a contract is finalised.
3. It Controls What Can Talk to What
In a microservices architecture or a multi-tier application, you have many services that need to communicate with each other — but not with everything else. A VPC lets you enforce this at the network level.
- Your payment processing service should only be reachable from your order management service
- Your admin dashboard should only be accessible from your company's IP range
- Your database should only accept connections from your application servers
Without VPC-level controls, these boundaries exist only in application logic — which can have bugs, misconfigurations, and vulnerabilities. Network-level controls are a harder boundary that application bugs cannot override.
4. Performance and Cost Optimisation
Traffic that stays within a VPC does not traverse the public internet. This means lower latency, higher throughput, and in most cloud providers, lower or zero data transfer costs for intra-VPC traffic.
💰 Real cost impact: On GCP Cloud Run — where Enerasoft deploys its backend services — traffic between Cloud Run instances and Cloud SQL within the same VPC is significantly cheaper and faster than routing via public IPs. At scale, this matters.
5. Scalability Without Compromising Security
As your product grows — more services, more regions, more customers — your VPC grows with it. Products that launch without a proper VPC architecture typically face a painful retrofitting exercise as they scale: moving databases into private subnets, reconfiguring security groups, and setting up private endpoints while the product is live and customers are depending on it.
This is entirely avoidable if the VPC is designed correctly from the start.
VPC Across Cloud Providers
| Feature | AWS VPC | GCP VPC | Azure VNet |
|---|---|---|---|
| Scope | Regional | Global (subnets are regional) | Regional |
| Default VPC | Yes (avoid using it) | Yes (avoid using it) | No — create explicitly |
| Private Endpoints | AWS PrivateLink | Private Service Connect | Private Endpoint |
| Peering | VPC Peering | VPC Network Peering | VNet Peering |
| Enerasoft Usage | Client projects | Primary — Cloud Run, GCS | Client projects |
One important note on GCP specifically, where Enerasoft runs its own products: GCP VPCs are global by default, meaning a single VPC can span multiple regions. Subnets are regional, but the VPC itself is not tied to one region. This is a meaningful architectural advantage for globally deployed applications and is one of the reasons Enerasoft chose GCP Cloud Run as its primary deployment target.
5 Common VPC Mistakes — and How to Avoid Them
❌ Mistake 1 — Using the Default VPC
Every major cloud provider creates a default VPC in your account when you sign up. It is tempting to use it because it is already there. Do not. The default VPC is configured for ease of getting started, not for production security. Always create a custom VPC for any production workload.
❌ Mistake 2 — Putting Databases in Public Subnets
This is surprisingly common and almost always the result of a developer trying to access a cloud database directly from their laptop during development. The fix is to use a bastion host or VPN for developer access — not to make the database public. A database with a public IP address and a security group that allows inbound connections from 0.0.0.0/0 is a breach waiting to happen.
❌ Mistake 3 — Overly Permissive Security Groups
Security groups that allow all inbound traffic (0.0.0.0/0) on all ports are the network equivalent of leaving every door in your building unlocked. Every security group rule should specify exactly the source, exactly the protocol, and exactly the port. Principle of least privilege applies at the network level.
❌ Mistake 4 — No VPC Flow Logging
VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC. Without them, you have no visibility into who is talking to what, no way to diagnose connectivity issues, and no audit trail for security incidents. Turn them on from day one.
❌ Mistake 5 — Ignoring CIDR Range Planning
Your VPC's IP address range (CIDR block) determines how many resources you can run and whether you can peer with other VPCs in future. A /16 CIDR gives you 65,536 IP addresses. A /28 gives you 16. Plan for growth. CIDR ranges cannot be changed after a VPC is created without destroying and recreating it.
How Enerasoft Approaches VPC in Every Build
VPC design is part of our technical architecture phase — before any code is written, before any cloud resources are provisioned. Here is our standard approach for cloud-native product builds:
- ✅ Custom VPC with a
/16CIDR block — never the default VPC, always room to grow - ✅ Three-tier subnet architecture — public (load balancers), private application (Cloud Run / compute), private data (databases, caches, queues)
- ✅ Security groups with explicit least-privilege rules per service — no wildcard inbound rules
- ✅ NAT Gateway for outbound internet access from private subnets
- ✅ Private endpoints for all managed cloud services — storage, databases, and secret managers over the private network
- ✅ VPC Flow Logs enabled from day one — routed to a centralised logging service
- ✅ Separate VPCs per environment (development, staging, production) with controlled peering where needed
This is not over-engineering. For any product handling real business data and real customers, this architecture is the baseline.
Security is not a feature you add to a cloud product. It is the architecture the product runs on. VPC is where that architecture begins.
The Bottom Line
A VPC is not a technical detail that only architects need to care about. It is a business decision. It determines whether your customer data is network-isolated, whether your infrastructure can scale without a security crisis, whether you can pass an enterprise security audit, and whether a misconfigured port can bring your entire product down.
The good news is that getting it right is not complicated — it just requires making the decision deliberately, at the start, with someone who has done it before.
If you are building a cloud product and want to talk through your architecture — whether you are starting fresh or trying to fix an existing setup — we would be glad to have that conversation.
Written by Gagan Kataria, Founder & CEO at Enerasoft Technologies LLP — an AI-powered software company helping businesses build intelligent, scalable cloud products.