Vocabulary for Cloud Networking: VPC, Subnet, Peering and NAT Explained

Cloud networking has a vocabulary that’s dense, full of acronyms, and easy to misuse. Saying “the subnet can’t reach the internet because of the route table” requires you to understand and pronounce a whole chain of terms correctly. This guide explains the core cloud networking vocabulary with example sentences you can use on calls and in design docs.

The container: VPC

• VPC (Virtual Private Cloud) — your isolated private network in the cloud. Say “V-P-C”. “We run everything inside one VPC per environment.”
• region — a geographic location (e.g. eu-central-1). “The VPC lives in the Frankfurt region.”
• availability zone (AZ) — an isolated datacenter within a region. “We spread subnets across three AZs for resilience.”

A VPC is the boundary. Everything else lives inside it.

“We have one VPC per environment, each spanning three availability zones in the Frankfurt region.”

Carving it up: subnets and CIDR

• subnet — a slice of the VPC’s address space. “Put the database in a private subnet.”
• public subnet — has a route to the internet. “The load balancer sits in a public subnet.”
• private subnet — no direct internet route. “App servers go in private subnets.”
• CIDR block — the IP range, written like 10.0.0.0/16. Say “ten dot oh dot oh dot oh slash sixteen” or “a /16”. “The VPC is a /16; each subnet is a /24.”
• address space / IP range — the pool of addresses. “We’re running out of address space.”
• to carve up / to subdivide — split a range. “We carved the /16 into eight /20 subnets.”

The public vs private distinction is the single most important one in cloud networking — get it cold.

Getting in and out: gateways

• internet gateway (IGW) — lets a VPC talk to the public internet. “Public subnets route through the internet gateway.”
• NAT gateway — lets private subnets reach out to the internet without being reachable from it. Say “NAT” (rhymes with “cat”). “Private subnets use a NAT gateway for outbound traffic.”
• egress / outbound — traffic leaving. “We only allow egress to the package registry.”
• ingress / inbound — traffic coming in. “Ingress is restricted to the load balancer.”

The classic pattern, in one sentence:

“App servers in the private subnet reach the internet for outbound calls through a NAT gateway, but nothing on the internet can reach them directly.”

NAT (Network Address Translation) is the term people most often fumble. It lets many private machines share one public IP for outbound traffic only.

Directing traffic: route tables

• route table — rules for where traffic goes. “The route table sends 0.0.0.0/0 to the NAT gateway.”
• route — a single rule. “There’s no route to the internet from this subnet.”
• default route — 0.0.0.0/0, the catch-all. “The default route points at the IGW.”
• to associate — attach a route table to a subnet. “Associate the private route table with these subnets.”
• blackhole — traffic with nowhere to go. “That route is a blackhole — the gateway was deleted.”

“Traffic isn’t leaving because the subnet’s route table has no default route — it’s effectively a dead end.”

Connecting networks: peering and beyond

• VPC peering — a direct private link between two VPCs. “We peered the data VPC with the app VPC.”
• transit gateway — a hub connecting many VPCs and on-prem. “All VPCs attach to a transit gateway.”
• to peer — connect two networks. “Can we peer with their VPC?”
• non-transitive — peering doesn’t chain. If A peers with B and B with C, A still can’t reach C. “Peering is non-transitive, so we need a direct link.”
• VPN — encrypted tunnel, often to on-prem. “On-prem connects over a site-to-site VPN.”
• Direct Connect / dedicated link — a private physical line to the cloud.
• private endpoint / PrivateLink — reach a cloud service privately, without the internet. “We hit S3 over a private endpoint.”

The fact that peering is non-transitive trips up many teams — worth saying out loud in design reviews.

Controlling access: firewalls

• security group — a stateful firewall on a resource. “Open port 443 in the security group.”
• stateful — return traffic is allowed automatically. “Security groups are stateful, so you only define inbound rules.”
• NACL (network ACL) — a stateless firewall at the subnet level. Say “knack-ull” or “N-A-C-L”. “The NACL is blocking the ephemeral ports.”
• stateless — you must allow both directions. “NACLs are stateless — don’t forget the return rule.”
• allow / deny rule — “There’s a deny rule on that port.”
• port range / ephemeral ports — the high ports clients use for replies. “The NACL drops the ephemeral port range.”

Stateful (security group) vs stateless (NACL) is a classic interview and debugging distinction.

Names and addresses: DNS

• DNS resolution — turning names into IPs. “DNS isn’t resolving inside the VPC.”
• private DNS / private hosted zone — internal names. “The service has a private DNS name.”
• public IP / private IP — “It only has a private IP, so it’s not reachable externally.”
• Elastic / static IP — a fixed public address. “The NAT gateway has a static IP.”

Phrases for the design review or incident

• “It’s in a private subnet with no NAT, so it can’t reach the registry.”
• “The security group’s blocking inbound on 5432.”
• “Peering’s up, but the route table doesn’t have the return route.”
• “We’re exhausting the address space — we need a bigger CIDR.”
• “That should go over PrivateLink, not the public internet.”
• “Traffic’s blackholing — the route points at a deleted gateway.”

Common mistakes

• Confusing IGW and NAT. IGW = bidirectional internet for public subnets; NAT = outbound-only for private subnets.
• Saying “subnet” when you mean “VPC”. The VPC is the whole network; subnets are slices of it.
• Forgetting peering is non-transitive. A→B and B→C does not give A→C.
• Mixing up security groups and NACLs. Security groups are stateful and per-resource; NACLs are stateless and per-subnet.
• Ignoring the route table. Connectivity needs both a firewall rule and a route.

Key takeaways

• A VPC is the boundary; subnets (public/private) slice it; CIDR defines the ranges.
• IGW = internet for public subnets; NAT = outbound-only for private subnets.
• Route tables decide where traffic goes — no route, no connectivity.
• Peering is non-transitive; use a transit gateway or PrivateLink for more.
• Security groups are stateful per-resource; NACLs are stateless per-subnet.

Master this vocabulary and you’ll diagnose connectivity problems — and design networks — with confidence in any cloud.

In Practice: Navigating Communication Challenges

Let’s be honest – when you’re learning professional English, particularly within the rapidly evolving world of cloud networking, the sheer volume of specialized terms can feel overwhelming. It’s not just about knowing what something is; it’s about understanding how to discuss it effectively with your team, and that often hinges on precise phrasing. A common challenge for developers from non-English speaking backgrounds isn’t necessarily grasping the technical definitions themselves, but rather how native speakers communicate these concepts – particularly around ambiguity or potential misunderstandings.

Consider this scenario: you’re reviewing a pull request (PR) submitted by a colleague who’s recently joined the team. The PR introduces a new subnet within the VPC and includes a comment like, “Implemented NAT gateway for outbound access.” As a reviewer, you might instinctively flag it as needing clarification. However, your colleague might perceive this as criticism if phrased bluntly. Instead of saying, “This NAT setup is unclear – what’s the rationale?” (which can feel accusatory), a more constructive approach would be: “Could we discuss the decision to use a NAT gateway here? I’m just trying to understand the broader network strategy and ensure it aligns with our security requirements. Perhaps we could explore alternative options if they offer better performance or cost-effectiveness.” This shifts the focus from you judging their work to collaborative problem-solving.

Another common situation arises in Slack conversations when discussing routing. A junior developer might say, “I’m having trouble getting traffic to the database subnet.” While technically accurate, it doesn’t convey the full picture. A more detailed explanation – “I’ve confirmed that the route table on the web server instance does include a destination route for the database CIDR block, but I suspect there might be an issue with the security group rules allowing traffic from the web servers to the database subnet.” – provides context and immediately directs troubleshooting efforts. The key is anticipating potential questions or areas of confusion based on your colleague’s background and experience level. Remember, clear communication builds trust and accelerates problem-solving.

Finally, when writing PR descriptions, avoid overly technical jargon if possible, especially for a wider audience. Instead of saying “Configured VPC peering with Route Table updates,” try “Established network connectivity between the development and staging environments using VPC peering to facilitate testing.” This is more accessible and clearly outlines the purpose of the change.

Here’s an example of how you might use terraform to create a simple subnet:

resource "aws_subnet" "example" {
  cidr_block = "10.0.2.0/24"
  availability_zone = "us-east-1a"
  vpc_id          = "vpc-xxxxxxxxxxxxxxxxx" # Replace with your VPC ID

  tags = {
    Name = "Development Subnet"
  }
}

This basic Terraform code demonstrates the fundamental concept of a subnet’s CIDR block, which is crucial for understanding network addressing and routing.