CH03-01: Azure Networking Mental Model

Goal

Chapter 1 introduced Azure as a set of responsibilities: identity, governance, organization, networking, workload services, and operations. Chapter 2 showed how governance gives teams safe boundaries for building in Azure.

This section focuses on the networking responsibility.

The goal is not to memorize every Azure networking feature. The goal is to understand what networking does architecturally: it defines which communication paths should exist, which should not exist, and where those paths should be controlled.

Networking decisions shape security, reliability, migration, operations, troubleshooting, cost, and workload autonomy. A workload can have the right subscription, the right policy, and the right resource group, but it still needs safe paths to users, APIs, databases, monitoring tools, Azure services, and sometimes on-premises systems.

The Short Version

Azure networking is the design of intentional communication paths.

It helps answer five recurring questions:

1. What needs to connect?

2. What should stay isolated?

3. Which traffic should be public or private?

4. Where should routing and inspection happen?

5. How does on-premises connectivity fit?

Those questions matter because cloud resources are easy to connect quickly. That speed is useful, but it can also create accidental exposure, unclear traffic paths, weak segmentation, difficult troubleshooting, and risky dependencies between workloads.

The durable idea for this chapter is:

Azure networking is the design of intentional paths: who can reach what, over which route, through which controls, and whether access should be public, private, hybrid, or isolated.

A Practical Mental Model

Think of Azure networking as five responsibility areas:

flowchart TB
    A["Networking<br/><small>Which communication paths should exist?</small>"]
    B["Placement<br/><small>Where do workloads live?</small>"]
    C["Segmentation<br/><small>What should be isolated?</small>"]
    D["Routing & Inspection<br/><small>Where should traffic go?</small>"]
    E["Hybrid Reachability<br/><small>How do external networks connect?</small>"]
    F["Private Access<br/><small>How do workloads reach Azure services?</small>"]

    A --> B
    A --> C
    A --> D
    A --> E
    A --> F

This is not a deployment order. It is a way to keep the main networking decisions visible while designing Azure environments.

You will see several Azure names in this chapter: virtual networks, subnets, network security groups, route tables, VNet peering, VPN Gateway, ExpressRoute, private endpoints, and private DNS. Do not worry about memorizing all of them at once. Each name will be explained through the decision it supports.

For now, focus on the responsibility first.

Placement

Placement answers:

• Where does this workload live from a network point of view?

• Which private address space does it use?

• Which parts of the application should be placed into separate subnets?

• Does the workload need its own network boundary or can it share one?

• Will this network need to connect to other Azure networks or on-premises networks later?

In Azure, the basic private network boundary is a virtual network, often shortened to VNet. A virtual network is a private network space in Azure. Inside it, subnets divide the address space into smaller areas for workload placement and controls.

For example, an application might use one subnet for web resources, one subnet for application services, and one subnet for private access to data services. The details come in the next section. The important point here is that network placement is an architecture decision. It affects isolation, routing, access control, migration, and operations.

Segmentation

Segmentation answers:

• Which systems should be allowed to talk to each other?

• Which systems should never talk directly?

• How should production differ from non-production?

• Which application tiers need separate controls?

• How do we reduce blast radius if one component is compromised?

A private network is not automatically a safe network. If every system inside a network can talk to every other system, a mistake or compromise in one place can spread too easily.

Azure network security groups, usually called NSGs, help filter traffic. They can allow or deny traffic based on direction, source, destination, protocol, port, and priority. You do not need the rule details yet. For now, remember that NSGs help express which network conversations are allowed.

Segmentation is not about blocking everything. It is about allowing the paths the workload needs and avoiding broad access that has no clear purpose.

Routing and Inspection

Routing answers:

• Where should traffic go next?

• Should traffic go directly to its destination?

• Should it pass through a firewall or inspection service first?

• How does traffic reach another virtual network?

• How does traffic reach an on-premises network?

• How will operators troubleshoot the path when something fails?

Security rules and routes are related, but they are not the same thing.

An NSG rule may decide whether traffic is allowed. A route decides where traffic is sent. For example, a workload may be allowed to reach the internet, but the organization may require that internet-bound traffic first pass through Azure Firewall or another inspection service.

Azure creates many default routes automatically so basic network behavior works. Route tables let teams intentionally shape traffic paths when the default behavior is not enough. This becomes important in hub-spoke networks, hybrid connectivity, central inspection, and controlled outbound access.

Hybrid Reachability

Hybrid reachability answers:

• Which on-premises systems must Azure workloads reach?

• Which on-premises users or services must reach Azure workloads?

• Is internet-based encrypted connectivity enough?

• Is private dedicated connectivity required?

• How will routes and DNS work across both environments?

• What happens during migration when systems are split between Azure and a data center?

Many real Azure environments are hybrid. A company may move applications gradually. Some databases may remain on-premises for a while. Identity, monitoring, deployment, or integration systems may exist outside Azure.

Azure commonly supports hybrid connectivity with VPN and ExpressRoute. VPN provides encrypted connectivity over the internet. ExpressRoute provides private dedicated connectivity through a connectivity provider. The choice is not only technical. It depends on reliability, privacy, cost, bandwidth, timeline, and operating model.

Hybrid networking is where casual network design becomes painful quickly. Address ranges, routing, DNS, inspection, and ownership all need to line up.

Private Access

Private access answers:

• Should this Azure service be reachable through a public endpoint?

• Should access stay on private network paths?

• Which workloads are allowed to reach the service privately?

• How will DNS resolve the service name to the private address?

• How will on-premises clients use the same private path if needed?

Many Azure platform services, such as storage accounts, databases, and key vaults, can be reached through public endpoints unless configured otherwise. Public endpoint does not always mean anonymous access. Identity, authorization, encryption, and service configuration still matter. But for sensitive workloads, teams often want network access to stay private too.

Private endpoints help with this. A private endpoint gives a supported Azure service a private IP address inside a virtual network. Private DNS is usually part of the design because clients still use service names, and those names must resolve to the private address.

The important point is simple: private access is both a network path and a name-resolution design.

Networking Control Map

The table below is a starting vocabulary map. It is not a design checklist yet.

The rest of this chapter turns these names into practical decisions.

Example: An Internal Customer API

Imagine a company wants to move an internal customer API to Azure.

The API needs:

• Access from internal users.

• A web or API hosting tier.

• A database or storage dependency.

• Logs and monitoring.

• Connectivity to one on-premises system during migration.

• Stronger controls in production than in test.

It is tempting to ask only:

Which network do we put this API in?

A stronger design starts with path questions:

• Should users reach the API publicly or only through private/internal access?

• Should the API tier talk directly to the database, or should access be restricted by tier?

• Should the database or storage service expose a public endpoint?

• Does the API need to reach on-premises systems through VPN or ExpressRoute?

• Should outbound traffic go directly to the internet or through central inspection?

• Which logs, flow records, or monitoring signals are needed for operations?

• Who owns the shared network path: the platform team or the workload team?

After those answers, the Azure controls become easier to place. The workload may use a virtual network with separate subnets, NSGs for tier filtering, route tables for central inspection, VNet peering to a shared hub, hybrid connectivity to the data center, and private endpoints for data services.

The design is not only about making the API reachable. It is about making the right paths reachable.

Common Early Mistakes

• Treating networking as only an IP address task. Addressing matters, but networking also includes isolation, routing, inspection, private access, DNS, and operations.

• Allowing public access because it is easier during early deployment. Temporary exposure often becomes permanent unless the private pattern is designed early.

• Designing connectivity before deciding what should remain isolated. If everything can talk, the network is easy to build but risky to operate.

• Ignoring DNS when private access is required. Private endpoints and hybrid access often fail because names resolve to the wrong place.

• Assuming private IP access automatically means the system is secure. Identity, authorization, encryption, service configuration, monitoring, and patching still matter.

• Forgetting troubleshooting. A design that no one can trace during an incident is not a strong network design.

If Someone Asks You

If someone asks, "What does Azure networking mean architecturally?" a clear answer is:

Azure networking is how you design controlled communication paths between users, workloads, Azure services, shared platform services, and external networks. It includes where workloads are placed, which traffic is allowed, where traffic is routed, how Azure connects to on-premises systems, and how workloads reach Azure services privately. A good Azure network design balances connectivity with isolation, inspection, operations, and troubleshooting.

This answer keeps networking connected to architecture decisions instead of listing features.

What You Should Remember

Azure networking is easier to understand when you think in paths.

The most important idea is this:

Strong Azure networking balances reachability and isolation.

Cloud systems need to communicate, but every allowed path should have a reason. The rest of this chapter explains the Azure controls that help you place workloads, filter traffic, route paths, connect networks, support hybrid systems, and keep sensitive service access private.

Questions to Check Your Understanding

1. Why is connectivity different from safe connectivity?

2. What are the five recurring networking questions in this chapter?

3. Why should networking design consider isolation before allowing traffic?

4. How does networking connect back to governance and landing zones?

5. Why is DNS part of private network design?