Most Azure networking guides assume you're starting fresh. But a lot of people come to Azure already thinking in AWS terms, or coming in cold and just wanting the mental model without wading through Microsoft's naming. So here's Azure's network architecture explained around the concepts, with the AWS parallels called out, because the ideas are nearly identical even when the labels aren't.
**
The VNet is your private network (AWS calls it a VPC)**
Everything starts with the Virtual Network, the VNet. It's your isolated private network inside Azure, the same idea as a VPC in AWS. Walled off, yours to define, nothing in it unless you put it there. If you've built in a VPC before, you already understand the VNet, it's the same concept wearing a different name. If you haven't, the concept is simple: a private slice of the cloud where you define the network layout yourself.
Subnets divide it, same as anywhere
Within the VNet you create subnets, sections of your private network, and the same crucial distinction applies: some things should be reachable from the internet and most things shouldn't. The design discipline is identical across every cloud, keep your databases, internal services, and sensitive systems in subnets that aren't directly internet-facing, and expose only what genuinely must be exposed, as little as possible. The concept doesn't change between providers. Only the buttons do.
NSGs are Azure's security groups
Access control in Azure runs mainly through Network Security Groups, NSGs. If you know AWS security groups, NSGs are the same job, rules governing what traffic is allowed to and from resources. One difference worth knowing: NSGs can be applied at both the subnet level and the individual resource (network interface) level, which gives you layered control, a broad rule on the subnet and finer rules on specific resources. Useful, and also a place to confuse yourself if you forget both layers are in play when you're debugging why traffic isn't flowing.
The principle to bring is the usual one: least privilege. Allow the specific traffic that's needed, deny the rest by default, and don't fling an NSG wide open to fix a problem, because that temporary fix has a way of becoming permanent.
Where Azure genuinely differs: identity is the home-field advantage
Here's the real Azure-specific thing, and it's a legitimate strength rather than marketing. Azure integrates deeply with Microsoft's identity world, Entra ID, formerly Azure AD. If your organization already lives in Microsoft, Office, Windows, the enterprise stack, Azure's networking and access tie into that existing identity system in a way that's genuinely convenient. Your network access decisions can lean on the identity infrastructure you already run, rather than bolting on a separate one.
This matters because modern network security is moving toward identity as the control point rather than network location, and if your identity backbone is already Microsoft, Azure meets you where you are. It's the single most compelling reason to pick Azure over the alternatives, and it's got nothing to do with the networking features themselves and everything to do with what you're already tied to.
Hub-and-spoke, the topology you'll hear about
One pattern that comes up constantly in Azure land is hub-and-spoke: a central VNet (the hub) holding shared services, connected to multiple other VNets (the spokes) for different workloads or teams or environments. The point is centralizing the shared stuff, connectivity, security controls, common services, in one place instead of duplicating it everywhere. You don't need it on day one, but when someone mentions it, that's the idea: a central hub of shared infrastructure with workload spokes hanging off it, so you manage the common concerns once.
The recurring truth, because it's true everywhere
Same as any cloud: exposure is a configuration outcome, there's no accidental safety, and your job is to always know what's reachable from the internet and keep the sensitive things off that list. Azure gives you the tools, the same conceptual tools as everyone else, and hands you responsibility for using them well.
The summary if you're coming from AWS
VNet is VPC. NSG is security group. Subnets and the public/private discipline are identical. The concepts transfer almost completely, so don't relearn networking, just relearn the labels. The one genuinely distinct thing is the deep Microsoft identity integration, which is either a major advantage or a non-factor depending entirely on whether you're already in that ecosystem. Everything else is the same networking you already know, with Azure's names on it.
Top comments (0)