Networking in Cloud: VPC, Subnets, Gateways, and DNS
📅 Published: Feb 2026
⏱️ Estimated Reading Time: 18 minutes
🏷️ Tags: Cloud Networking, VPC, Subnets, Route Tables, NAT Gateway, DNS, AWS, Azure, GCP
Introduction: Building Your Cloud Network
When you move to the cloud, you are building a virtual data center. Just like a physical data center needs networking—routers, switches, firewalls, and cables—your cloud environment needs networking to connect resources, control access, and communicate with the internet.
Cloud networking gives you complete control over your virtual network. You define the IP address space, divide it into subnets, control traffic with route tables, and connect to the internet through gateways.
This guide covers the fundamental networking components that every cloud architecture needs: Virtual Private Clouds, subnets, route tables, internet gateways, NAT, and DNS services.
Virtual Private Cloud (VPC): Your Isolated Network
What is a VPC?
A Virtual Private Cloud (VPC) is a logically isolated section of the cloud where you can launch resources in a virtual network that you define. You have complete control over your network environment, including IP address ranges, subnets, route tables, and network gateways.
Think of a VPC as your own private data center inside the cloud provider's infrastructure. It is isolated from other customers' networks but can be connected to the internet, other VPCs, and your on-premises data center.
VPC Terminology Across Providers
| Provider | Service Name | Region Scope | Key Features |
|---|---|---|---|
| AWS | VPC | Regional | Subnets across Availability Zones |
| Azure | Virtual Network (VNet) | Regional | Subnets across Availability Zones |
| Google Cloud | VPC | Global | Subnets across regions, global routing |
While the names differ, the concepts are nearly identical across providers.
IP Addressing in VPCs
When you create a VPC, you define an IP address range using CIDR (Classless Inter-Domain Routing) notation. This range cannot overlap with other networks you will connect to your VPC.
Common CIDR ranges:
10.0.0.0/8 — 16 million addresses (very large, use subnets)
172.16.0.0/12 — 1 million addresses
192.168.0.0/16 — 65,536 addresses
Choosing the right size:
Plan for growth. It is difficult to change CIDR ranges later.
Leave room for future subnets and services.
Use 10.0.0.0/16 for most workloads (65,536 addresses).
Avoid overlapping with on-premises networks if you plan hybrid connectivity.
Subnets: Dividing Your Network
What Are Subnets?
A subnet is a range of IP addresses within your VPC. You launch resources into specific subnets. Subnets allow you to organize resources and control traffic flow.
Think of subnets as floors in a building. Each floor has its own purpose, its own access controls, and its own connections to other floors.
Public vs Private Subnets
| Subnet Type | Routing | Use Cases |
|---|---|---|
| Public Subnet | Route to Internet Gateway | Web servers, load balancers, bastion hosts |
| Private Subnet | No direct internet route | Databases, application servers, internal services |
Public subnets have a route to an internet gateway. Resources in public subnets can communicate directly with the internet.
Private subnets have no direct internet route. Resources in private subnets cannot be accessed from the internet without going through a NAT gateway or load balancer.
Subnet Placement Across Availability Zones
In cloud environments, subnets are tied to a single availability zone. To build highly available applications, you create subnets in multiple availability zones.
Example: Three-tier architecture across three zones
| Zone | Public Subnet | Private Subnet (App) | Private Subnet (Database) |
|---|---|---|---|
| us-west-2a | 10.0.1.0/24 | 10.0.11.0/24 | 10.0.21.0/24 |
| us-west-2b | 10.0.2.0/24 | 10.0.12.0/24 | 10.0.22.0/24 |
| us-west-2c | 10.0.3.0/24 | 10.0.13.0/24 | 10.0.23.0/24 |
This design allows you to deploy resources across zones. If one zone fails, resources in other zones continue running.
Subnet Sizing
When designing subnets, allocate enough addresses for your resources. Consider:
Each resource (virtual machine, load balancer, database) consumes at least one IP address
Some services reserve addresses for internal use
Plan for auto scaling—future instances need IP addresses
Leave room for growth
Common subnet sizes:
| CIDR | Addresses | Use Case |
|---|---|---|
| /28 | 16 | Very small (NAT gateways, test) |
| /26 | 64 | Small application tiers |
| /24 | 256 | Standard application tier |
| /23 | 512 | Larger deployments |
| /22 | 1024 | Enterprise applications |
Route Tables: Directing Traffic
What Are Route Tables?
Route tables contain rules, called routes, that determine where network traffic is directed. Every subnet in your VPC must be associated with a route table.
Think of route tables as street signs. They tell traffic: to get to the internet, go this way. To get to another subnet, go that way.
Default Routes
Every VPC comes with a main route table. The main route table has a default local route that allows communication between all resources in the VPC.
Destination Target 10.0.0.0/16 local
This route ensures that resources in different subnets can communicate with each other.
Common Route Patterns
Public Subnet Route Table
| Destination | Target | Purpose |
|---|---|---|
| 10.0.0.0/16 | local | VPC internal traffic |
| 0.0.0.0/0 | Internet Gateway | Internet traffic |
Private Subnet Route Table (with NAT)
| Destination | Target | Purpose |
|---|---|---|
| 10.0.0.0/16 | local | VPC internal traffic |
| 0.0.0.0/0 | NAT Gateway | Internet traffic initiated from inside |
Private Subnet Route Table (no internet)
| Destination | Target | Purpose |
|---|---|---|
| 10.0.0.0/16 | local | VPC internal traffic |
Route Priority
When multiple routes match a destination, the most specific route wins. A route to 10.0.0.0/24 is more specific than a route to 10.0.0.0/16.
This allows you to override general routes with more specific ones.
Internet Gateway: Connecting to the Internet
What is an Internet Gateway?
An Internet Gateway (IGW) is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet.
Think of an internet gateway as the front door to your VPC. It is the entry point for traffic coming from the internet and the exit point for traffic going to the internet.
How Internet Gateway Works
One IGW per VPC
Attached to the VPC, not to specific subnets
Public subnets have routes to the IGW
Resources in public subnets need public IP addresses to receive internet traffic
Internet Gateway vs NAT Gateway
| Feature | Internet Gateway | NAT Gateway |
|---|---|---|
| Direction | Both inbound and outbound | Outbound only |
| Public IP | Required for inbound | Not required |
| Use Case | Public-facing resources | Private resources needing internet access |
| Cost | No additional cost (data transfer only) | Hourly charge + data transfer |
NAT Gateway: Outbound-Only Internet Access
What is NAT?
Network Address Translation (NAT) allows resources in private subnets to access the internet while preventing the internet from accessing those resources.
Think of NAT as a secure side door. Resources inside can go out to get packages, but outsiders cannot come in through that door.
NAT Gateway vs NAT Instance
| Feature | NAT Gateway | NAT Instance |
|---|---|---|
| Managed by | Cloud provider | You |
| Availability | Highly available across zones | You must manage |
| Bandwidth | Up to 100 Gbps | Depends on instance type |
| Scaling | Automatic | Manual |
| Cost | Hourly charge | Instance cost + hourly |
NAT Gateway is the recommended approach for most workloads. It is managed by the cloud provider, highly available, and scales automatically.
NAT Gateway Architecture
For high availability, deploy a NAT gateway in each availability zone. Private subnets in a zone route internet traffic through the NAT gateway in the same zone.
Availability Zone A: Availability Zone B:
Public Subnet Public Subnet
| |
NAT Gateway A NAT Gateway B
| |
Private Subnet A Private Subnet BIf a NAT gateway fails, only resources in that availability zone lose internet access. Resources in other zones continue working.
DNS Services: Translating Names to Addresses
What is DNS?
The Domain Name System (DNS) translates human-readable domain names (like example.com) into IP addresses that computers use to communicate.
Think of DNS as the phonebook of the internet. You look up a name, and it gives you a number.
Cloud DNS Services
| Provider | Service Name | Features |
|---|---|---|
| AWS | Route 53 | Domain registration, routing policies, health checks |
| Azure | Azure DNS | Domain hosting, private DNS zones |
| Google Cloud | Cloud DNS | High availability, low latency |
Public DNS vs Private DNS
Public DNS resolves names from anywhere on the internet. This is how users find your website.
Private DNS resolves names only within your VPC. This is how your application servers find your database without traversing the internet.
Private DNS Zones
Private DNS zones are internal namespaces that resolve only within your VPCs. You can use them to:
Give friendly names to internal resources (database.internal, api.internal)
Simplify application configuration (use names instead of IPs)
Ensure internal traffic stays within the VPC
DNS Resolution in VPCs
When you launch a resource in a VPC, it receives a private DNS name automatically. For example, an EC2 instance with private IP 10.0.1.10 gets a name like ip-10-0-1-10.ec2.internal.
You can also create custom DNS records in private zones to give more meaningful names.
Route 53 Routing Policies (AWS)
| Policy | Use Case |
|---|---|
| Simple | Single resource, single record |
| Weighted | Split traffic across multiple resources (A/B testing, blue-green deployment) |
| Latency | Route users to the region with the lowest latency |
| Failover | Active-passive disaster recovery |
| Geolocation | Route based on user location (content localization) |
| Multi-value Answer | Simple load balancing with health checks |
Putting It All Together: Complete VPC Architecture
A production-ready VPC includes all these components working together:
VPC Configuration
CIDR: 10.0.0.0/16
3 Availability Zones
DNS hostnames enabled
DNS resolution enabled
Subnets
| Purpose | Zone A | Zone B | Zone C |
|---|---|---|---|
| Public | 10.0.1.0/24 | 10.0.2.0/24 | 10.0.3.0/24 |
| Private (App) | 10.0.11.0/24 | 10.0.12.0/24 | 10.0.13.0/24 |
| Private (DB) | 10.0.21.0/24 | 10.0.22.0/24 | 10.0.23.0/24 |
Gateways
Internet Gateway attached to VPC
NAT Gateway in each public subnet
Route Tables
Public Route Table (associated with public subnets):
10.0.0.0/16 → local
0.0.0.0/0 → Internet Gateway
Private App Route Table (associated with private app subnets):
10.0.0.0/16 → local
0.0.0.0/0 → NAT Gateway (same zone)
Private DB Route Table (associated with private DB subnets):
10.0.0.0/16 → local
No internet route
DNS
Private hosted zone:
app.internalRecords:
api.app.internal→ internal load balancerRecords:
database.app.internal→ RDS cluster endpoint
Network Security
Security Groups vs Network ACLs
| Feature | Security Group | Network ACL |
|---|---|---|
| Scope | Instance level | Subnet level |
| State | Stateful | Stateless |
| Rules | Allow only | Allow and deny |
| Order | All rules evaluated | Rules evaluated in order |
| Use Case | Instance firewall | Subnet perimeter |
Security Groups act as virtual firewalls for individual instances. They are stateful: if you allow inbound traffic, outbound responses are automatically allowed.
Network ACLs act as firewalls for entire subnets. They are stateless: you must specify both inbound and outbound rules.
Best Practices
Use security groups for most access control
Use network ACLs for subnet-level defense in depth
Create separate security groups for each tier (web, app, database)
Deny all inbound by default, allow only what is needed
Real-World Scenarios
Scenario 1: Web Application with Database
A web application has three tiers: web servers, application servers, and a database.
Architecture:
Public subnets for web servers (receive internet traffic)
Private subnets for application servers (internal only)
Private subnets for database (internal only)
Internet Gateway for public subnets
NAT Gateway for application servers to download updates
Traffic flow:
User request hits load balancer in public subnet
Load balancer forwards to application server in private subnet
Application server queries database in private subnet
Database responds directly to application server
Scenario 2: Multi-Region Disaster Recovery
An application needs to survive a region-wide failure.
Architecture:
VPC in primary region (us-west-2)
VPC in secondary region (us-east-1)
VPC peering or Transit Gateway between regions
Route 53 with failover routing
Database replication across regions
Traffic flow (normal):
Route 53 directs users to primary region
All traffic stays in us-west-2
Traffic flow (failover):
Health checks detect primary region failure
Route 53 directs users to secondary region
Application runs from us-east-1
Scenario 3: Hybrid Cloud with On-Premises
An organization wants to extend their on-premises data center to the cloud.
Architecture:
VPC with non-overlapping CIDR (10.1.0.0/16)
VPN connection or Direct Connect to on-premises
Route tables include routes to on-premises network
Private DNS resolution across environments
Traffic flow:
Cloud resources can communicate with on-premises servers
On-premises servers can communicate with cloud resources
Internet traffic for cloud resources uses cloud gateways
Internal traffic stays within the hybrid network
Best Practices for Cloud Networking
Plan your CIDR blocks carefully. Choose ranges that do not overlap with existing or planned networks. Leave room for growth.
Use multiple availability zones. Deploy resources across zones for high availability. A single zone failure should not impact your application.
Implement defense in depth. Use security groups and network ACLs together. Restrict access at multiple layers.
Enable VPC flow logs. Capture information about IP traffic. Use logs for security monitoring and troubleshooting.
Use private DNS for internal services. Avoid hardcoding IP addresses. Use names that resolve within your VPC.
Tag your networking resources. Use consistent tagging to identify purpose, environment, and owner. Tags help with cost allocation and management.
Summary
| Component | Purpose | Key Consideration |
|---|---|---|
| VPC | Isolated network | Choose non-overlapping CIDR |
| Subnets | Organize resources | Public vs private, multi-zone |
| Route Tables | Direct traffic | Default routes, internet gateway |
| Internet Gateway | Internet access | For public resources |
| NAT Gateway | Outbound internet | For private resources |
| DNS | Name resolution | Public zones, private zones |
These components form the foundation of any cloud architecture. Understanding how they work together is essential for designing secure, scalable, and highly available applications.
Practice Questions
You need to deploy a web application with public-facing web servers and private databases. How would you design the VPC and subnets?
Application servers in private subnets need to download security updates from the internet. What networking component allows this?
You need to connect VPCs in two different regions for disaster recovery. What options are available?
A database server should not be accessible from the internet but should be reachable from application servers in the same VPC. How do you configure this?
You have a VPC with resources in three availability zones. How many NAT gateways should you deploy for high availability?
Learn More
Practice cloud networking with hands-on exercises in our interactive labs:
https://devops.trainwithsky.com/
Comments
Post a Comment