Networking Basics Every Cloud Engineer Should Know

Why Networking Matters in the Cloud

You can be great at writing code or managing servers, but if you don't understand networking, you'll hit walls constantly. Why can't my application reach the database? Why is this timing out?

Usually, it's networking. Once you have the basics down, our [cloud security fundamentals guide](/blog/cloud-security-fundamentals-beginners) builds on this with identity, encryption, and monitoring concepts that depend on a solid networking foundation.

IP Addresses: Your Cloud Address System

An IPv4 address looks like 192.168.1.100: four numbers (0-255), separated by dots.

Private IP ranges (used inside your network):

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

Public IP addresses: Everything else. These are routable on the internet.

Subnets and CIDR

10.0.0.0/16: what does this mean?

The /16 tells you how many bits are fixed:

/16 = first 16 bits fixed = 65,536 addresses
/24 = first 24 bits fixed = 256 addresses
/28 = first 28 bits fixed = 16 addresses

Practical Example

VPC: 10.0.0.0/16 (65,536 addresses)
├── Public Subnet: 10.0.1.0/24
├── Private Subnet A: 10.0.10.0/24
├── Private Subnet B: 10.0.11.0/24
└── Database Subnet: 10.0.20.0/24

Each subnet gets its own range. They can't overlap.

DNS: Translating Names to Numbers

Nobody wants to remember 54.231.17.108. We use names like www.example.com instead.

Common Record Types

A: Maps name to IPv4
AAAA: Maps name to IPv6
CNAME: Alias to another name
MX: Mail server
TXT: Text data

Private DNS

Inside your cloud network, use private DNS:

database.internal → 10.0.20.15

Your application connects to database.internal instead of an IP. If the database moves, just update DNS.

Load Balancing

When one server isn't enough, distribute traffic between multiple servers.

Types

Layer 4 (TCP): Routes based on IP and port. Faster.

Layer 7 (HTTP): Routes based on URL, headers. More flexible.

Cloud Load Balancers

Cloud	L4	L7
AWS	NLB	ALB
Azure	Load Balancer	Application Gateway
GCP	Network LB	HTTP(S) LB

VPNs and Private Connectivity

Site-to-Site VPN

Connects your office network to your cloud VPC through an encrypted tunnel.

Point-to-Site VPN

Individual users connect to cloud from anywhere.

Direct Connect/ExpressRoute

Dedicated physical connection. More bandwidth, more consistent, more expensive.

VPNs and ExpressRoute are still perimeter-based models. For a deeper look at the identity-centric approach that's replacing them, see our [Zero Trust security implementation guide](/blog/what-is-zero-trust-security-complete-guide).

Troubleshooting Basics

When things don't connect, check:

Security Groups / Firewalls: Is the port allowed?
Route Tables: Is there a path to the destination?
DNS Resolution: Can you resolve the name?
Network ACLs: Stateless rules for entire subnets

Cheat Sheet

Common Ports:

22: SSH
80: HTTP
443: HTTPS
3306: MySQL
5432: PostgreSQL
6379: Redis

Not sure which of these ports are exposed on your own infrastructure? Run them through our free [vulnerability scanner](/tools/vulnerability-scanner) to check for open ports and missing security headers.

CIDR Quick Math:

/24 = 256 IPs
/25 = 128 IPs
/26 = 64 IPs
/27 = 32 IPs
/28 = 16 IPs

Networking isn't magic. It's just rules about how data moves from A to B. Learn the rules, and you'll solve problems much faster.

Frequently Asked Questions

What is CIDR notation and why does it matter for cloud networking?

CIDR (Classless Inter-Domain Routing) notation expresses an IP address range as a base address plus a prefix length, such as 10.0.0.0/16. The prefix length tells you how many bits are fixed: /16 leaves 16 bits for host addresses, giving 65,536 possible IPs. Cloud engineers need to understand CIDR to design VPCs and subnets without accidentally creating overlapping ranges, which cause routing failures, or ranges that are too small to accommodate future growth. A /24 subnet (256 addresses) is fine for a small application tier; a /16 VPC gives room to add many subnets as a project grows.

What is the difference between a public and private subnet in a VPC?

A public subnet has a route to an Internet Gateway, meaning resources in it can receive traffic from the internet and send traffic out directly. A private subnet has no direct route to the internet; outbound traffic must go through a NAT Gateway or similar proxy. The standard pattern for secure cloud architecture is to place public-facing resources like load balancers in public subnets and all backend resources like application servers and databases in private subnets, so they are not directly reachable from the internet.

How does DNS work in cloud environments and why is private DNS important?

DNS translates human-readable names into IP addresses. In cloud environments, each VPC or VNet typically has a private DNS resolver that resolves internal hostnames without sending queries to the public internet. Private DNS matters for security and reliability: applications should connect to internal resources by name (database.internal) rather than IP address, so that if a resource's IP changes (after failover or scaling), only the DNS record needs updating rather than every application configuration. Private DNS also keeps internal topology invisible to external observers.

What is the difference between a Layer 4 and Layer 7 load balancer?

A Layer 4 load balancer routes traffic based on TCP/UDP port and IP address without inspecting the content of packets. It is faster and handles any TCP protocol. A Layer 7 load balancer understands HTTP/HTTPS content and can route based on URL paths, hostnames, or HTTP headers, enabling features like path-based routing (/api to one backend, / to another), SSL termination, and web application firewall integration. For web applications, Layer 7 (Application Load Balancer on AWS, Application Gateway on Azure) is generally preferred. For non-HTTP protocols or pure throughput use cases, Layer 4 is appropriate.

What should a cloud engineer check first when a service cannot connect to another service?

Work through the OSI model from bottom to top. First, verify security group and firewall rules allow the specific port between the source and destination. Second, check route tables to ensure there is a route from the source subnet to the destination subnet. Third, verify DNS resolution: can the source resolve the destination's hostname? Fourth, check Network ACLs if you use them, as they are stateless and require both inbound and outbound rules. Finally, verify the destination service is actually listening on the expected port. Most connectivity issues are security group misconfigurations or missing routes.