Microsoft Azure Fundamentals Training Course

Every Azure resource that communicates over a network does so within a virtual network, or through a service endpoint that reaches one. Networking is where a lot of otherwise straightforward Azure work goes wrong, and understanding the basic shapes prevents most of it.

Virtual networks

An Azure virtual network, usually shortened to VNet, is a logically isolated private network in Azure. It is the cloud equivalent of the network in your own building, with two important differences: you create it in seconds, and it is isolated from every other customer's network by default.

A virtual network belongs to one region and one subscription, and you define its address space using private IP ranges expressed in CIDR notation — 10.0.0.0/16, for example. Resources placed in the network receive private addresses from that space and can reach each other over it.

Two constraints matter and are frequently examined. A virtual network exists in a single region; it does not span regions, though networks in different regions can be connected. And the address space you choose should not overlap with other networks you will ever need to connect to — not your on-premises network, not another virtual network you may peer with later. Overlapping address spaces are the single most common cause of connectivity work that cannot be completed without renumbering.

Subnets

A subnet divides a virtual network's address space into smaller segments. Resources are placed into subnets, not directly into the network, and subnets are the natural boundary for applying network security rules.

The usual pattern is to divide by tier or by function: a subnet for web servers, another for application servers, another for databases, with rules between them that allow only the traffic each tier legitimately needs. That segmentation is a defense-in-depth measure — an attacker who reaches the web tier does not automatically reach the database.

Azure reserves several addresses in every subnet for its own use, so the number of usable addresses is smaller than the raw size of the range. Some services also require their own dedicated subnet, which is worth planning for rather than discovering later.

Network security groups

A network security group filters traffic to and from resources. It contains rules, each with a priority, a direction, a source and destination, a port range, a protocol, and an allow or deny action. Rules are evaluated in priority order and the first match wins.

Network security groups can be associated with a subnet, with a network interface, or with both. Applying them at the subnet level covers everything in the subnet, including resources added later, which is usually what you want.

Azure includes default rules that permit traffic within the virtual network and outbound to the internet, and deny inbound traffic from the internet. Those defaults are the reason a newly created virtual machine can reach the internet but is not reachable from it until you allow something.

Peering

Virtual network peering connects two virtual networks so that resources in each can communicate using private IP addresses, as if they were on the same network. Traffic between peered networks travels over the Microsoft backbone rather than the public internet.

The characteristics to know:

• Peering works between networks in the same region and between networks in different regions, the latter usually called global peering.
• Peered networks must not have overlapping address spaces.
• Peering is not transitive. If network A is peered with B, and B with C, A cannot reach C through B by default. This is the most examinable fact about peering.
• Data transferred between peered networks is charged, and the rate depends on whether the peering is within a region or across regions.

The non-transitivity is why organizations with many networks adopt a hub-and-spoke topology: a central hub network holds shared services such as firewalls and gateways, each application network peers with the hub, and routing through the hub is arranged deliberately rather than assumed.

Reaching resources privately

Many Azure platform services — storage accounts, databases — are reached by default over a public endpoint, protected by authentication. Where that is not acceptable, private endpoints give the service a private IP address inside your virtual network, so traffic to it never traverses the public internet. This is a common requirement in regulated environments and is worth recognizing by name.

Planning an address space

It is worth spending a moment on the part that causes the most trouble later. Choose the virtual network's address range from the private ranges, size it generously, and keep a record of what every network in the organization uses. Networks are cheap; renumbering a production environment is not. The classic failure is that two teams independently pick 10.0.0.0/16 for their networks, everything works perfectly for a year, and then a business requirement arrives that those two environments must talk to each other. Peering will not accept overlapping ranges, and the only remedies are to renumber one side or to introduce address translation, both of which are far more expensive than the five minutes of planning that would have avoided the collision. The same applies to the on-premises network in a hybrid design: find out what it uses before you choose, not after.

What the exam expects

Be able to state that a virtual network is a private, isolated network scoped to one region; that subnets segment it and are where resources are placed; that network security groups filter traffic by rule with the first match winning; and that peering joins networks privately, non-transitively, and requires non-overlapping address spaces. Those five facts answer the great majority of networking questions at this level.