VPC Networking Demystified: The Complete Guide from Subnets to Security Groups

What a VPC Actually Is

A Virtual Private Cloud (VPC) is a logically isolated network segment inside a shared cloud provider infrastructure. Think of it as your own private data center network — except it runs on shared physical hardware, carved out by software-defined networking.

Before VPCs existed, every instance (virtual machine) you launched shared a flat network with other customers. Traffic was separated by firewall rules, but the underlying network was common. VPCs changed that by giving each account its own IP address space, routing control, and network boundaries — hard boundaries, not just rule-based ones.

Every major cloud provider now makes VPC the default network model. When you launch an instance on InMotion Cloud, it sits inside a VPC. Whether you configured that VPC deliberately or accepted defaults, it exists. Understanding its structure lets you control it — and that control is the difference between a secure, scalable architecture and one that quietly exposes your workloads.

Subnets: The Building Blocks of VPC Architecture

A subnet is a range of IP addresses within your VPC. You carve the VPC's IP space into subnets, then assign instances to specific subnets based on their role.

CIDR notation defines IP ranges. 10.0.0.0/16 means the VPC owns every IP from 10.0.0.0 to 10.0.255.255 — 65,536 addresses. A subnet like 10.0.1.0/24 takes 256 of those addresses. Smaller CIDR prefixes mean larger ranges: /16 is larger than /24.

Subnets divide into two categories based on how they connect to the internet.

Public Subnets

A public subnet has a route to the internet through an internet gateway. Instances in public subnets can receive inbound traffic from the internet and initiate outbound connections directly. Web servers, load balancers, and bastion hosts typically live here.

Public does not mean unprotected. Security groups and network ACLs still control what traffic actually reaches your instances. Public simply means a network path to the internet exists.

Private Subnets

A private subnet has no direct route to the internet. Instances in private subnets cannot be reached from the internet, and they cannot initiate outbound connections unless you route traffic through a NAT gateway or NAT instance sitting in a public subnet.

Application servers, databases, and internal services belong in private subnets. This is the most important architectural habit you can develop: keep anything that doesn't need to be internet-facing in a private subnet.

A well-designed VPC uses multiple subnets across multiple availability zones. This is not optional for production workloads. If your VPC has a single subnet and that availability zone has a hardware issue, everything goes down.

Routing Tables: Directing Traffic Inside Your VPC

Every subnet is associated with a routing table. A routing table is a set of rules that tells traffic where to go based on destination IP.

A basic routing table for a public subnet looks like this:

| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | internet-gateway-id |

The local route handles all traffic within the VPC — instances in any subnet can reach each other through the local route without hitting any external gateway. The second rule sends all other traffic (anything not in the VPC range) to the internet gateway.

A private subnet routing table replaces the internet gateway with a NAT gateway or removes the default route entirely:

| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | nat-gateway-id |

The NAT gateway sits in a public subnet with an Elastic IP. It allows private subnet instances to initiate outbound connections — for package updates, API calls, external service integrations — while blocking all inbound connections originating from outside.

Routing tables are more powerful than most engineers initially realize. You can route specific IP ranges through VPN gateways, through virtual appliances, or through transit gateways. Your routing table is where traffic flow decisions live, not in your security rules.

Security Groups vs. Network ACLs

Both control traffic, but they operate differently. Mixing them up leads to rules that do nothing, or worse, rules you think are doing something they are not.

| Feature | Security Groups | Network ACLs (NACLs) |
|---|---|---|
| Applies to | Individual instances/interfaces | Entire subnets |
| State | Stateful — return traffic allowed automatically | Stateless — both directions must be explicitly allowed |
| Rule type | Allow rules only | Allow and deny rules |
| Rule evaluation | All rules evaluated, most permissive wins | Rules evaluated in order by rule number, first match wins |
| Default behavior | All inbound denied, all outbound allowed | Allow all (default NACL) or deny all (custom NACL) |

Security Groups in Practice

Security groups are your primary instance-level firewall. Every instance belongs to one or more security groups. Rules define allowed traffic — you cannot write a deny rule.

You can reference other security groups in your rules rather than hardcoding IPs. A database security group rule can allow inbound on port 5432 from the application security group. When you scale your application tier, new instances automatically get access because they carry the same security group — no IP-based rule updates required.

This security group referencing pattern is one of the most valuable VPC features. It scales cleanly and eliminates the IP management problem entirely within a VPC.

Network ACLs in Practice

NACLs add a subnet-level control layer. Because they are stateless, you must write rules for both inbound and outbound directions. Return traffic is not automatically permitted.

This stateless behavior catches engineers unexpectedly. If you allow inbound traffic on port 443, you also need an outbound rule allowing the return traffic on ephemeral ports (1024-65535). Forget the outbound rule and connections will time out mysteriously.

Use NACLs for broad subnet isolation. Block entire IP ranges at the subnet boundary, add a layer of protection against misconfigured security groups, or enforce compliance boundaries between environment tiers. For most application-level access control, security groups are the right tool.

VPN and Site-to-Site Connectivity

Connecting your on-premises network to your VPC is a standard requirement for hybrid architectures. You have two primary options.

Site-to-Site VPN

A site-to-site VPN creates an encrypted tunnel over the public internet between your on-premises network and a Virtual Private Gateway attached to your VPC. Traffic traverses the internet but is encrypted end-to-end.

Configuration requires:

• A Virtual Private Gateway on the cloud side
• A Customer Gateway object representing your on-premises VPN device
• A VPN connection linking the two
• Route table updates pointing on-premises CIDR ranges through the Virtual Private Gateway
• Matching IPSec configuration on your on-premises device

Throughput is limited by your internet connection and typically caps at 1.25 Gbps per tunnel. Most deployments run two tunnels for redundancy. BGP routing is available for dynamic route propagation.

Site-to-site VPN is the right starting point for most hybrid setups. It is lower cost than dedicated connectivity and sufficient for management traffic, database replication, and moderate data transfer workloads.

Direct Connect / Dedicated Connectivity

For high-throughput workloads or strict latency requirements, dedicated private connectivity bypasses the internet entirely. InMotion Cloud's private connectivity options provide consistent bandwidth without internet variability.

This matters for large data migrations, real-time analytics pipelines, or compliance requirements that prohibit internet traversal even with encryption.

Common VPC Architectures

Two-Tier Architecture

The simplest production-ready VPC layout. Public subnets hold your load balancers. Private subnets hold your application instances and databases. A NAT gateway in each public subnet handles outbound traffic from the private tier.

Traffic flow: Internet → Internet Gateway → Load Balancer (public subnet) → Application Instance (private subnet) → Database (private subnet).

This covers the majority of web application deployments. It is not the most sophisticated architecture, but it is well understood, easy to audit, and straightforward to troubleshoot.

Three-Tier Architecture

Adds a dedicated data tier to the two-tier model. Public subnets hold load balancers. Application subnets (private) hold your web and API servers. Database subnets (private, no NAT gateway route) hold your databases and caches.

The database subnet has no outbound internet route at all. Instances there cannot call out even through a NAT gateway. This eliminates an entire class of exfiltration paths and is the appropriate design for any workload handling regulated data.

Security group rules enforce the tier boundaries: the load balancer security group allows internet inbound, the application security group allows inbound only from the load balancer security group, the database security group allows inbound only from the application security group.

The three-tier model is the standard for PCI-DSS, HIPAA, and SOC 2 compliant deployments. If your workload has any compliance requirement, start here.

Multi-VPC with Transit Gateway

Large organizations often run separate VPCs per environment (dev, staging, production) or per business unit, then connect them through a Transit Gateway. The Transit Gateway acts as a central hub — every VPC connects to it, and routing between VPCs is managed centrally.

This avoids the complexity of peering connections between every VPC pair and allows centralized routing policy. A security VPC housing your IDS/IPS appliances can inspect all cross-VPC traffic.

The DIY Reality: Time and Error Cost

Configuring a production-grade VPC from scratch is not a weekend project. Here is a realistic time estimate for a two-tier VPC deployment on AWS:

| Task | Estimated Hours |
|---|---|
| CIDR planning and subnet design | 3–5 hours |
| VPC and subnet creation | 1–2 hours |
| Internet gateway and NAT gateway setup | 1–2 hours |
| Routing table configuration | 2–3 hours |
| Security group design and implementation | 4–8 hours |
| Network ACL configuration and testing | 3–5 hours |
| VPN site-to-site setup | 4–8 hours |
| Testing, troubleshooting connectivity | 6–10 hours |
| Documentation | 3–5 hours |
| Total | 27–48 hours |

That estimate assumes no major missteps. Stateless NACL misconfiguration, BGP routing issues, or overlapping CIDR ranges can each add days of troubleshooting. A single misconfigured security group rule can create a security gap that exists for months before someone notices.

The 40+ hour figure is not an exaggeration — it is the common outcome, not the worst case.

InMotion Cloud's Managed VPC comes pre-configured with production-ready defaults: subnets across availability zones, correct routing tables, sensible security group starting points, and NAT gateway configuration. The network architecture that takes an experienced engineer 40+ hours to build and validate is available on day one.

That does not mean you cannot customize it. You can modify routing, add security groups, peer VPCs, and configure VPN connectivity. The difference is you start from a working, validated foundation instead of a blank configuration file.

Practical Configuration Habits

A few patterns that experienced network engineers follow consistently:

Plan CIDR ranges before you create anything. Once instances are running in a VPC, changing the CIDR range is painful. VPC peering and VPN connections will conflict if address spaces overlap. Reserve address space for future subnets. A /16 VPC with /24 subnets gives you room for 256 subnets — plan for growth.

Name everything immediately. VPC resource IDs are not human-readable. A security group named sg-0a3f8b2c1d4e5f6a7 tells you nothing. Apply consistent naming conventions at creation time: prod-web-sg, prod-db-sg, prod-public-subnet-1a. Troubleshooting at 2 AM with unnamed resources is avoidable suffering.

Default deny everywhere. Start with security groups that allow nothing, then open specific ports to specific sources. Do not start with broad rules and try to tighten them later. Broad rules get forgotten. Default deny does not.

Test connectivity explicitly after every change. Tools like telnet, curl, and nc (netcat) verify that expected paths work and unexpected paths do not. A change that opens port 443 to the load balancer should also be verified to not open port 3306 from the internet. Test both.

Log VPC flow data. VPC flow logs capture metadata about traffic accepted and rejected by your network interfaces. They do not capture packet contents, but they show source/destination IPs, ports, and whether traffic was accepted or rejected. Flow logs are the first thing you need during a security incident and the first thing you wish you had when troubleshooting connectivity. Enable them before you need them.

Where Managed VPC Fits

Self-managed VPC makes sense when your team has dedicated networking expertise, compliance requirements mandate custom configurations, or your architecture is unusual enough that defaults do not apply.

For most DevOps teams running web applications, APIs, or SaaS products, the networking layer is infrastructure that needs to work correctly — not a competitive differentiator. Time spent debugging NACL stateless rules is time not spent on application performance, deployment automation, or security hardening higher in the stack.

InMotion Cloud's Managed VPC is designed for that majority. You get correct networking without the configuration burden, with full access to customize as your requirements evolve.

The VPC concepts in this guide — subnets, routing tables, security groups, NACLs, VPN connectivity — remain relevant whether you configure them yourself or start from a managed baseline. Understanding the model helps you make better decisions, whether you are reviewing a managed configuration or building one from scratch.