Azure networking for AWS engineers: what transfers, what breaks, and what to learn first

If you already think in VPCs, you do not need another glossary that tells you a VNet is like a VPC. You need a sequence: which of your habits transfer untouched, which ones quietly break, and which labs to run in what order. This is that sequence — the same one I walk AWS people through in class.

New to cloud? CAMPUX is a free, build-first course. Start here →

If you know AWS networking, you can be productive in Azure VNets within a couple of focused weeks: CIDR planning, subnets, and route tables transfer almost directly, while NSGs, zone-spanning subnets, outbound internet, and private DNS behave differently enough to need deliberate practice — and the DNS part, honestly, takes longer than most AWS people expect.

One housekeeping note before the path. If what you actually want is a side-by-side feature table — VNet vs VPC, service by service — that page already exists. Keep the VNet vs AWS VPC vs GCP VPC comparison open in another tab as your reference table, and the wider Azure–AWS–GCP equivalents hub for everything beyond networking. This article is the thing those tables cannot be: a learning path with an order to it, written for someone whose reflexes were trained on AWS and who wants to know where those reflexes will betray them.

Part 1: What transfers instantly — you are not starting over

Start with the good news, because it is genuinely most of the picture. The private-network mental model you built in AWS is the same model in Azure. A VNet is an isolated private address space in a region. You give it one or more CIDR blocks. You carve those blocks into subnets. Traffic between subnets in the same VNet routes automatically. Every subnet has an effective route table — Azure calls the ones you write user-defined routes instead of route table entries, but the longest-prefix-match logic, the idea of overriding a system route, the habit of drawing the packet's path before you touch anything — all of it carries over untouched.

Your CIDR discipline transfers too. Plan address space so VNets never overlap, leave room to grow, do not burn 10.0.0.0/16 on a three-VM workload. Azure reserves five addresses per subnet, same count as AWS, so your subnet-sizing arithmetic barely changes. Peering works the way you expect at the packet level: private connectivity between two networks, non-transitive, cheap to set up. If you can draw an AWS network diagram on a whiteboard, you can draw the Azure version today and be roughly right.

This is worth saying plainly because AWS people often approach Azure braced for a full rewrite of their knowledge. It is not that. It is maybe seventy percent the same network engineering with different nouns. The remaining thirty percent is where the painful differences live, and that is what the rest of this path is about.

Part 2: Six behaviors to actually internalize — each one breaks an AWS reflex

These are not trivia. Each one is a place where doing the AWS thing in Azure produces a design that is wrong, redundant, or about to be deprecated. Work through them in order; the later ones build on the earlier ones.

1. Subnets span availability zones

The AWS reflex it breaks: one subnet per AZ. In AWS, a subnet lives in exactly one availability zone, so your zone-failure design is baked into your subnet layout — three AZs means three public subnets and three private ones, and half your Terraform is lists indexed by AZ. In Azure, a subnet is regional and spans all zones. Zone placement happens at the resource level instead: you pin a VM or a scale set to zone 1, 2, or 3, or spread instances across zones, while they all sit in the same subnet. This simplifies your address plan — no more multiplying subnets by zone count — but zone-resilience is no longer visible in your network diagram. You design it deliberately at the compute and load-balancer layer, and you can no longer infer zone spread from someone's subnet layout the way you could in AWS.

2. NSGs are not quite security groups, and there is no NACL layer

The AWS reflex it breaks: security groups on instances, NACLs on subnets. Azure collapses that two-layer model into one construct, the network security group. An NSG attaches to a subnet or to a NIC (or both — and when both are present, traffic must pass both). Rules are stateful, like security groups, so return traffic is allowed automatically. But rules carry explicit priority numbers from 100 to 4096, lower wins, and each rule is an allow or a deny — so an NSG can express the deny-by-exception logic you needed NACLs for in AWS. There is no separate stateless ACL layer to keep in sync, which removes a whole category of "why is this packet dropped" debugging. The habit to build: baseline rules on the subnet NSG, NIC-level NSGs only for genuine exceptions, and gaps left in your priority numbering for later. Also meet application security groups early — they restore the tag-like "refer to a group of servers by name in a rule" behavior that made AWS security groups pleasant.

3. Default outbound internet exists — and it is on its way out

The AWS reflex it breaks: no NAT gateway, no outbound. In AWS, an instance in a private subnet has no internet path until you build one, so your reflex is "no NAT, no egress." Azure historically did the opposite: a VM with no public IP could still reach the internet through an implicit, SNAT-ed outbound path you never configured. Convenient, un-auditable, and a reliable source of surprised security reviews. As of 2026, Microsoft has announced the retirement of default outbound access for new deployments (the announced cutoff was September 2025 for newly created scenarios — check the current learn.microsoft.com guidance, because dates and scope have shifted before). The modern pattern is the one your AWS instincts already like: explicit outbound, usually a NAT Gateway attached to the subnet. So the practical advice is simple — design as if default outbound does not exist, put a NAT Gateway on subnets that need egress, and treat any implicit outbound you find in an existing environment as legacy to be migrated, not a feature to rely on.

4. There is no Transit Gateway waiting for you — hub-spoke is the pattern

The AWS reflex it breaks: reach for TGW when networks multiply. When an AWS estate outgrows peering, the answer is Transit Gateway — a managed hub you attach VPCs to. Azure has no single default building block shaped like that. The standard enterprise answer is the hub-spoke topology you assemble yourself: a hub VNet holding shared services (firewall, VPN or ExpressRoute gateway, DNS), peered individually to each spoke VNet. Because VNet peering is non-transitive, spoke-to-spoke traffic does not flow by default — you steer it through the hub with user-defined routes pointing at a firewall or network virtual appliance. That is more manual than TGW, and the route tables are yours to maintain. The managed version exists — Azure Virtual WAN, which runs the hubs and the transitive routing for you and is the closest thing to TGW in spirit — but in my experience most enterprises you will actually work in run plain hub-spoke, so learn to build it by hand first. Our hub-spoke networking lab has you build exactly this topology, and it is the single highest-value lab on this path.

5. Private endpoints and the private DNS zone dance

The AWS reflex it breaks: tick "enable private DNS" on an interface endpoint and move on. This is the difference AWS people underestimate most, so slow down here. Azure private endpoints are the equivalent of AWS interface endpoints: a NIC in your subnet with a private IP that fronts a PaaS service — a storage account, a SQL database, a Key Vault. Creating one is easy. Making name resolution work is the actual job. The service's public hostname has to resolve to the private IP from inside your network and to the public IP (or nothing) from outside — split-horizon DNS. In AWS, the console checkbox wires most of this up. In Azure, you assemble it: a private DNS zone per service type (privatelink.blob.core.windows.net and its many siblings), a DNS record for each endpoint, and — the step everyone forgets — a VNet link from that zone to every VNet that needs to resolve it. In hub-spoke, that means deciding whether zones live in the hub with every spoke linked to them (usually yes). Miss one link and you get the classic failure: the endpoint exists, the packet path is fine, and connections still go to the public IP because DNS never heard the news. Read private endpoints explained before you lab this, and expect to break it at least once before it sticks.

6. No internet gateway, no EIP-per-instance — public IPs attach directly

The AWS reflex it breaks: IGW on the VPC, route to it, EIP on the instance. In AWS, internet access is a chain you assemble: an internet gateway attached to the VPC, a route table entry pointing at it, an Elastic IP mapped to the instance. Azure has no internet gateway object at all. A public IP address is a standalone resource you associate directly with a NIC, a load balancer frontend, a NAT Gateway, or an application gateway — and that association alone creates the internet path. Nothing to route to, no gateway to forget to attach. The flip side is that public exposure is easier to create by accident: any NIC can get a public IP with one association, so your governance reflex ("does this route table even reach an IGW?") has to become an Azure Policy or an NSG rule instead. Production traffic should arrive through a load balancer or application gateway frontend; individual VM public IPs should be rare and deliberate.

Part 3: The name map

Pin this mental table up. It is deliberately small — the full three-way comparison has the long version.

The nouns are the easy part. The reflexes — subnet-per-AZ, NACL habits, "no NAT means no egress" — are what actually need retraining.

Part 4: The labs, in order

Reading this article gets you oriented. It does not build reflexes — only reps do. Here is the sequence I give AWS people, using the free CAMPUX classes and labs (all of it is open; you do not need to pay anyone to run this path):

1. Foundation first: skim Class 10 — virtual networks and subnets. Most of it will feel familiar; you are reading it for the Azure-specific details (reserved IPs, regional subnets, NSG association points), not the concepts.
2. Build the topology: run the hub-spoke networking lab. Build the hub, peer the spokes, write the user-defined routes, watch spoke-to-spoke traffic fail until you steer it through the hub. This one lab covers differences 1, 4, and 6 above in a single sitting.
3. Then go private: work through Class 14 — private connectivity and put a private endpoint in front of a storage account inside your hub-spoke build. Deliberately skip the DNS setup first, watch resolution go to the public IP, then fix it with the private DNS zone and VNet links. Breaking it on purpose is the fastest way to learn what the checkbox in AWS was doing for you.
4. Finish with hybrid DNS: Class 15 — hybrid DNS closes the loop: DNS Private Resolver, inbound and outbound endpoints, conditional forwarders, and how on-premises networks resolve your private endpoints. This is the material that separates "I did the tutorial" from "I can debug name resolution in a real estate."

Total honest time estimate: two to four weeks of evenings if you actually build everything rather than reading about it. When you want to check retention, the free exam practice bank has networking questions drawn from AZ-104-style scenarios — a decent way to find the gaps you did not know you had.

Part 5: The honest gap — where Azure will genuinely annoy you

A fair guide owes you the parts that are worse, not just different. Two stand out, and neither is a secret to anyone who has run both clouds.

The DNS story is more fiddly than Route 53. Not conceptually harder — the pieces are ordinary DNS — but there are more of them to assemble and more seams to leak at. Private DNS zones per service type, a VNet link per zone per network, resolver inbound endpoints for on-premises queries, outbound endpoints and forwarding rules for the reverse direction, conditional forwarders on the on-premises side pointing at the right place. Route 53 Resolver bundles most of this into fewer moving parts. In Azure, every seam is explicit, which is good for understanding and bad for your first month. Plan real practice time here; this is where I watch experienced AWS engineers get humbled, and it is why Classes 14 and 15 sit at the end of the lab sequence rather than being optional extras.

Load balancing splits across four products where AWS has two. Your NLB/ALB instincts map to Azure Load Balancer and Application Gateway — layer 4 and layer 7, regional, broadly familiar. But Azure also gives you Front Door and Traffic Manager for global traffic, and the four overlap enough that choosing among them is a genuine design decision, not a lookup. (AWS has global answers too — CloudFront, Global Accelerator, Route 53 policies — but the mainstream AWS mental model is "NLB or ALB," and Azure will not let you keep it that simple.) Read both comparison pieces before an interview; "when would you use Front Door versus Application Gateway" is a question I have seen asked more than once.

Neither gap is a reason to avoid Azure. They are a reason to weight your practice time toward DNS and traffic routing instead of spreading it evenly — which is exactly what the lab order above does.

Questions people also ask

Is Azure networking harder than AWS networking?

No — it is differently shaped, not harder. The core layer (VNets, subnets, route tables, peering) is arguably simpler than AWS because there is no NACL layer and no internet gateway to manage. Where Azure asks more of you is private DNS: private endpoints depend on private DNS zones, VNet links, and resolver endpoints that Route 53 mostly handles for you with one checkbox. Budget your practice time accordingly — the packet-flow concepts will feel familiar within days, the DNS plumbing takes deliberate reps.

What is the Azure equivalent of a VPC?

A virtual network, or VNet. It plays the same role — a private, isolated address space you carve into subnets — and your CIDR planning habits transfer directly. The two behavioral differences worth knowing up front: Azure subnets are regional and span all availability zones (there is no per-AZ subnet), and a VNet has no internet gateway object — outbound and inbound internet paths are handled by NAT Gateway, load balancers, and public IP resources attached directly to NICs.

Does Azure have a Transit Gateway equivalent?

Not as a single default building block. The standard Azure pattern is hub-spoke: a hub VNet peered to each spoke VNet, with a firewall or network virtual appliance in the hub and user-defined routes steering traffic through it, because VNet peering is non-transitive. The managed product that behaves most like Transit Gateway is Azure Virtual WAN, which runs the hubs and routing for you. Most enterprises you will interview with run plain hub-spoke, so learn that pattern first.

How long does it take to learn Azure networking if I already know AWS?

For basic productivity — designing VNets, writing NSG rules, setting up peering — most AWS network people are functional within one to two focused weeks, because the mental model transfers. Genuine comfort with the parts that differ, especially private endpoints with private DNS zones and hybrid DNS resolution, realistically takes another few weeks of hands-on labs. Timelines vary with how much hands-on time you actually put in; reading alone does not build the reflexes.

What is the Azure equivalent of AWS security groups?

Network security groups (NSGs). Like security groups they are stateful, but they differ in three ways that matter: NSGs attach to subnets or to individual NICs rather than to instances by group membership, rules carry explicit priority numbers (lower number wins) and can be allow or deny, and there is no separate NACL layer — an NSG on a subnet covers the ground NACLs covered in AWS. Application security groups add the tag-like grouping behavior AWS people miss.