Virtual networks, subnets and routing inside a cloud

Why this matters

Cloud networking is the objective where people with strong traditional networking backgrounds lose marks, because the familiar words mean slightly different things and the differences are exactly what is tested.

There is no cable to check. A packet that does not arrive was stopped by one of a small number of logical objects, and the whole troubleshooting method in objective 6.2 depends on knowing what those objects are and in what order they act. This lesson builds that model.

It also contains the decision people most regret: the address range you choose for a virtual network is very hard to change once workloads are in it, and choosing it badly causes a peering problem years later.

The lesson

The virtual network as an address space you choose, and choosing one you can grow into

A virtual network is a logically isolated network you define inside a provider's infrastructure. You pick a private address range — normally from RFC 1918 space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) — and carve subnets out of it.

Providers call this object different things: a VPC, a virtual network, a VPC network. The exam is vendor-neutral, so learn the concept and recognise the names.

Three properties that differ from a physical network:

• It is isolated by default. Two virtual networks cannot talk unless you connect them, even in the same account and region.
• Routing between its own subnets is automatic. There is an implicit local route; you do not configure routing to get one subnet talking to another. What you configure is how to reach things outside.
• The provider reserves addresses in every subnet — typically the network address, a gateway, a DNS address, and the broadcast address, commonly five in total. A /28 does not give you sixteen usable addresses.

Choosing the range is the decision to take seriously. Pick something large enough to grow into, and — critically — pick something that does not collide with your on-premises network, your partners' networks, or the other cloud networks you might one day peer with. 10.0.0.0/16 is the most-used default in the world, which makes it the most likely to collide. Overlapping ranges cannot be peered, and the remedy is renumbering or address translation, both painful.

Public and private subnets, and what actually makes a subnet public

This is the single most common misunderstanding in the objective.

A subnet is public if its route table has a route to an internet gateway. That is all. It is not a checkbox, it is not a property of the subnet, and it is not determined by whether the instances have public addresses.

Follow the consequences:

• An instance in a public subnet with no public IP cannot be reached from the internet and cannot reach it directly.
• An instance with a public IP in a private subnet still cannot reach the internet, because the route does not exist.
• Both a route and an address are required for inbound internet connectivity, plus permissive security rules.

The standard architecture that follows: public subnets hold only the things that must face the internet — load balancers, NAT gateways, bastions — and everything else sits in private subnets. Objective 4.5 treats this as a security control; here it is simply how routing works.

Availability zones belong in this picture. A subnet lives in one zone. To build something zone-resilient you need a subnet per zone and a load balancer or scaling group spanning them, which is why real designs have subnets in multiples.

Route tables, internet gateways and the NAT gateway that lets private hosts reach out

• Route table. Associated with a subnet; decides where traffic for a destination goes. There is always an implicit local route for the virtual network's own range, and it cannot be overridden. Most-specific prefix wins, exactly as in traditional routing.
• Internet gateway. A horizontally-scaled provider object that allows bidirectional internet traffic for resources with public addresses. Attaching it to the network does nothing by itself — a subnet becomes public only when a route points at it.
• NAT gateway (or NAT instance). Lets resources in private subnets make outbound connections to the internet while remaining unreachable from it. It lives in a public subnet and private subnets route their default traffic to it.

The NAT gateway is worth extra attention because it appears in both troubleshooting and billing questions:

• It is outbound only. Nothing on the internet can initiate a connection through it.
• It is zonal. A NAT gateway in one zone is a single point of failure for private subnets in other zones routed through it, and cross-zone traffic to reach it is chargeable.
• It is metered, both per hour and per gigabyte, and it is a routine surprise on a bill when a large volume of traffic — patch downloads, backups to a public endpoint, container image pulls — flows through it. The fix is usually a private service endpoint, covered in the next lesson.

Security groups versus network ACLs: stateful and stateless, and where each applies

Providers give you two filtering layers, and the exam tests the difference constantly.

Stateful means a reply to an allowed outbound connection is permitted automatically. You write one rule and the return traffic works.

Stateless means each direction is evaluated independently. If you allow inbound on port 443 and forget the outbound rule for the ephemeral port range, the request arrives and the response is dropped — a connection that hangs rather than fails cleanly, and a classic exam scenario.

Practical guidance that matches how they are actually used:

• Do the everyday work in security groups. They are the finer instrument, and many providers let one security group reference another as a source, which expresses "the web tier may reach the database tier" without any addresses at all.
• Use network ACLs for coarse subnet-wide rules and, importantly, for explicit denies — blocking a specific address range is something security groups cannot express.
• Remember there may be a host firewall inside the guest as well. Three layers, all of which must permit the traffic.

The three providers' names for the same four objects, which the exam will mix

CV0-004 is vendor-neutral, so questions describe behaviour rather than naming a console. Recognising the same object under different names is the skill:

Read the scenario for the behaviour: is it stateful or stateless, does it attach to an instance or a subnet, is it outbound-only. The behaviour identifies the object regardless of the word used, and that is precisely what a vendor-neutral exam is testing.

What to take into the exam

• A subnet is public because its route table points at an internet gateway, not because of any property of the subnet or its instances.
• Internet connectivity needs route + public address + permissive rules. Missing any one produces silence.
• NAT gateway = outbound only, lives in a public subnet, is zonal, and is metered per gigabyte.
• Security groups are stateful and allow-only, attached to instances. Network ACLs are stateless, ordered, support deny, attached to subnets.
• A stateless rule set that forgets ephemeral return ports produces hanging connections.
• The provider reserves several addresses per subnet; usable count is lower than the maths suggests.
• Overlapping address ranges cannot be peered. Choose the range with that in mind.