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. Networking is also where a large share of cloud security incidents start: a database left reachable from the public internet, a management port open to 0.0.0.0/0, a flat network with no boundary between test and production. Once you have the basics down, our cloud security fundamentals guide builds on this with identity, encryption, and monitoring concepts that depend on a solid networking foundation.

Cloud network security is the practice of designing subnets, routing, and access controls so only intended traffic can reach a given resource. It combines segmentation (isolating workloads from each other), access control (security groups, NSGs, and NACLs), and visibility (DNS and traffic logging) to limit what an attacker can reach if any single resource is compromised.

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.

Network segmentation as a security control

A subnet layout is a networking decision. What is and isn't allowed to talk to what is a security decision. Segmentation splits a network into isolated zones so that compromising one workload doesn't automatically give an attacker a path to every other workload, and it's one of the most commonly missing controls in cloud environments that grew organically from a single flat VPC.

A joint advisory from the NSA and CISA, based on real red team and blue team assessments across US organizations, lists insufficient network segmentation as one of the top ten most common misconfigurations they observe. Without it, an attacker who footholds one low-value machine (a jump box, a test server) can reach production databases on the same flat network, because nothing was blocking east-west traffic in the first place.

Hub-and-spoke segmentation design example

A hub-and-spoke topology is a practical pattern for enforcing segmentation at scale (it underpins both Azure landing zones and typical AWS multi-account designs). A central "hub" network holds shared security services; each workload lives in its own "spoke," peered to the hub but not directly to other spokes:

Hub VNet/VPC (shared services)
├── Firewall / NVA (inspects all inter-spoke traffic)
├── VPN / ExpressRoute / Direct Connect gateway
└── Private DNS resolver

Spoke: prod-web    (10.1.0.0/20)  -- peered to hub only
Spoke: prod-app     (10.2.0.0/20)  -- peered to hub only
Spoke: prod-data     (10.3.0.0/20)  -- peered to hub only, no internet route
Spoke: non-prod       (10.9.0.0/20)  -- peered to hub only, isolated from prod spokes

The rule that makes this work: spoke-to-spoke traffic isn't peered directly. If prod-web needs to reach prod-app, that traffic routes through the hub, where a firewall or network virtual appliance can inspect and log it. A compromised workload in the non-prod spoke has no network path to prod-data at all, because no peering or route exists between them. It's the same tiering principle (web, app, database) applied one level up, at the environment boundary.

Security groups and NSGs vs network ACLs

Stateful vs stateless: what that means in practice

Security groups (AWS) and network security groups (Azure NSGs) are stateful: allow inbound traffic on a port and the matching return traffic is automatically allowed out, with no outbound rule required. Network ACLs are stateless: return traffic must be explicitly permitted by an outbound rule too, or it gets dropped. This is the single most common source of "it works from my laptop but not from this subnet" tickets: someone locks down a NACL's outbound rules without realizing security groups' stateful assumption doesn't apply.

Both controls exist for a reason. Security groups/NSGs attach to individual resources and give fine-grained, per-workload rules. NACLs attach to an entire subnet and apply to everything in it regardless of resource-level rules. Using both is defense in depth: a NACL is a coarse backstop that still blocks traffic even if someone attaches an overly permissive security group to a new resource.

For a deeper comparison of NSGs against perimeter controls like Azure Firewall and Application Gateway, and where each one belongs in the stack, see our NSG vs Firewall vs Application Gateway decision guide.

Security group and NSG hardening checklist

• Deny-by-default: start with no inbound rules and add only what is explicitly needed.
• No 0.0.0.0/0 (or ::/0) on management ports. Scope SSH (22), RDP (3389), and WinRM (5985/5986) to a bastion host, a VPN range, or just-in-time access.
• Reference security groups, not raw CIDR blocks, where supported (AWS security-group-to-security-group rules, Azure application security groups). These survive IP changes and autoscaling; hardcoded ranges don't.
• One security group per tier or role, not one shared "allow-all-internal" group. Sharing a group between web and database tiers gives a web vulnerability database-tier network reach.
• Tag and document every rule with an owner and a business justification. An unexplained rule is one nobody feels safe deleting.
• Filter egress too, not only inbound. Unrestricted outbound lets a compromised workload exfiltrate data or reach command-and-control infrastructure even with inbound locked down.
• Review and prune on a schedule. Rules opened for a demo or POC are the top source of the leftover 0.0.0.0/0 rules described below.

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.

DNS security basics

DNS is a control plane, not just a lookup service, and it deserves the same scrutiny as your routing tables. A few basics matter for every cloud environment:

• Use the private resolver your cloud provider gives your VPC/VNet for internal names. Public resolvers have no reason to know your internal topology.
• Configure split-horizon DNS so internal hostnames (database.internal, api.internal) never resolve from outside your network.
• Enable DNSSEC on public-facing domains to protect against cache poisoning and spoofing, which can redirect users to an attacker-controlled server without touching your application.
• Log DNS queries where your provider supports it (Route 53 Resolver query logging, Azure DNS analytics). DNS is a common exfiltration channel, and query logs are often the first signal that catches it.

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

Private endpoints: keeping PaaS traffic off the public internet

A managed database, storage account, or queue service usually gets a public endpoint by default: a hostname resolving to a public IP, reachable from anywhere unless locked down with firewall rules. Private endpoints (Azure Private Link) and interface endpoints (AWS PrivateLink) change that: the service gets a private IP inside your own VNet or VPC, and traffic never leaves the cloud provider's internal network.

This removes a whole class of exposure. A storage account or database with no public endpoint at all cannot be found by internet-wide scanners or hit by credential-stuffing, because there is no public listener to hit, and sensitive traffic stays on infrastructure your provider controls end to end.

The most common gap isn't ignorance of the feature, it's inertia: a database stood up early with a public endpoint and firewall rules, working fine, so nobody circled back once the VNet design matured. Checking which PaaS resources still have public endpoints enabled is one of the highest-signal, lowest-effort reviews you can run on an existing environment.

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: once a device is on the tunnel, it typically has broad network reach. For a deeper look at the identity-centric approach that's replacing that model, see our Zero Trust security implementation guide.

Troubleshooting basics

When things don't connect, check:

1. Security groups / firewalls: is the port allowed?
2. Route tables: is there a path to the destination?
3. DNS resolution: can you resolve the name?
4. Network ACLs: stateless rules for entire subnets

Common failure modes: how misconfigured networking becomes a breach

Most cloud network incidents are not sophisticated. They trace back to a small number of repeat patterns:

• Overly permissive inbound rules left from testing: a security group opened to 0.0.0.0/0 on SSH or RDP for a quick debug session, never closed. This needs no exploit development, just a scan for the open port.
• Flat networks with no segmentation: every workload and environment on one subnet with permissive internal rules, so one compromised host reaches everything.
• Public IPs on resources that never needed them: a database or internal API assigned a public IP by a default template, then left that way because migrating it later felt risky.
• NACL rules that only cover inbound. Because NACLs are stateless, a missing outbound rule causes intermittent connectivity failures that often get "fixed" by opening the NACL wide instead of adding the correct narrow rule.
• DNS that leaks internal topology: hostnames and IP ranges resolvable from the public internet because split-horizon DNS was never configured, handing reconnaissance data to an attacker for free.

Tradeoff framework: segmentation granularity vs operational complexity

More segmentation is not automatically better. Every extra boundary is another set of rules to write and maintain, and a wrong rule can break production just as easily as a missing one enables a breach. Match segmentation granularity to your team's operational maturity, not to an abstract ideal:

A reasonable default is tier-based segmentation combined with environment separation: web, application, and data tiers each in their own subnet with security groups scoped between them, and production fully isolated from non-production. That alone prevents most of the failure modes above. Move toward micro-segmentation once you have infrastructure as code and monitoring that can quickly flag a rule change that breaks something, because that's when the operational cost drops enough to justify the smaller blast radius.

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 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 rules about how data moves from A to B, and which of those movements should be allowed. Learn the rules, and you'll solve connectivity problems faster and close off the misconfigurations that turn into security incidents.

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.

What is the difference between a security group and a network ACL?

A security group (or NSG in Azure) is stateful and attaches to individual resources: allow an inbound port and the matching outbound return traffic is permitted automatically. A network ACL is stateless and attaches to an entire subnet: inbound and outbound rules must both be configured explicitly, and it applies uniformly to every resource in that subnet regardless of its own security group rules. Use security groups for fine-grained, per-workload access control, and NACLs as a coarse, subnet-wide backstop, not as your only control.

What is a private endpoint and when should I use one?

A private endpoint (Azure Private Link, AWS PrivateLink interface endpoint) gives a managed PaaS service, such as a database or storage account, a private IP address inside your own VNet or VPC instead of a public one. Traffic to the service then stays on the cloud provider's internal network rather than traversing the public internet. Use a private endpoint for any PaaS resource that only needs to be reached from inside your network: it removes the resource from internet-wide scanning and brute-force attempts entirely, which is a stronger guarantee than firewall rules on a public endpoint alone.