How Azure Is Organised and How to Use This Course

You already know cloud basics, so this level skips definitions. It gives you the frame that every later table depends on. Before you compare Azure Functions with Lambda, you need to know three things: where a service lives in Azure's hierarchy, how far its resilience reaches, and how you pay for it. These differ more between the three clouds than most of the services do.

Tables in this course were checked against vendor documentation in October 2026. Names, plans and limits change, so recheck before you sign anything.

The hierarchy: tenant → management groups → subscriptions → resource groups

A useful way to picture Azure is as a filing cabinet:

• Tenant: the building. It is one Microsoft Entra ID directory and the boundary for identity. All subscriptions and management groups in a tenant trust that one directory.
• Management groups: the drawers, where you put governance. Policies and role assignments set on a management group pass down to everything beneath it. Every tenant has one root management group, shown by default as "Tenant root group", and new subscriptions land there automatically. Limits: up to 10,000 management groups per directory, nested up to six levels deep (the root and subscription levels don't count), and each item has exactly one parent.
• Subscriptions: the folders. A subscription is where billing happens, it is a boundary for quotas, and it is the usual unit for separating environments.
• Resource groups: the plastic wallets inside a folder. Every resource sits in exactly one resource group, and a resource group usually holds things that share a lifecycle. Delete the group and everything in it is deleted.

Every Azure resource ID shows this path. Read it like an address:

/subscriptions/1111-aaaa/            # billing and quota boundary
  resourceGroups/rg-payments-prod/   # lifecycle container
  providers/Microsoft.Compute/       # the service namespace
  virtualMachines/vm-api-01          # the resource itself
# Management groups and the tenant don't appear in the ID;
# they sit above the subscription and govern it by inheritance.

Worked example: placing a payments API

Tenant: contoso.onmicrosoft.com           (identity)
└─ MG: Root
   └─ MG: Landing Zones                   (policy: allowed regions = EU)
      └─ MG: Production
         └─ Subscription: payments-prod   (bill and quotas)
            └─ RG: rg-payments-api        (VMs, disks, NIC; deleted together)

The same job in the other two clouds

Gotcha: An Azure subscription and an AWS account don't isolate to the same degree. An AWS account has its own IAM and is a hard security boundary. An Azure subscription shares its tenant's identity, so the identity boundary sits one level higher.

Regions, region pairs and availability zones

In all three clouds, a region is a geographic location and availability zones are separate groups of datacenters inside it. Azure's zones have independent power, cooling and networking, are usually within 100 km of each other, and Microsoft aims for under about 2 ms round trip between them. Zone-enabled Azure regions mostly have three zones. Some regions have none.

Azure also has region pairs, which the other two clouds don't. Some regions are paired with another region, usually in the same geography (UK South with UK West, for example). A pair gives you staggered platform updates, priority for recovery in a geography-wide outage, and a fixed target for some services' geo-replication, such as geo-redundant storage (GRS). Many newer regions, such as Italy North, Poland Central and Spain Central, have no pair and rely on zones instead. A pair doesn't fail over for you. You still have to design your own disaster recovery.

Three differences that change designs:

Pitfall: "Zone 1" in two Azure subscriptions may be two different buildings. Check the zone mapping before you assume two workloads are co-located.

Pricing models

The models line up well, but the details differ:

Support plans (checked October 2026)

Retiring: AWS Developer Support, Business Support and Enterprise On-Ramp end on 1 January 2027. They stay available in GovCloud (US). Developer and Business customers can move to Business Support+, and Enterprise On-Ramp customers are being moved to Enterprise Support.

How to read every table in this course

Each category lesson has the same two tables:

1. Service table: each Azure service, its purpose in one line, and any former name (useful when old documentation or contracts use the old one).
2. Equivalence table: Azure | AWS | Google Cloud, one row per job, not per product name. You'll see these markers:
   • No direct equivalent: nothing native does this job. Plan a third-party tool or a different design.
   • Note: the match breaks somewhere, in limits, pricing or behaviour. The free cross-zone traffic row above is an example.
   • ⚖ Judgement: no vendor states this mapping. It is our assessment, so check it against your own use case.

Every table carries a check date. Treat anything older than about six months as a prompt to recheck. Each lesson ends by naming the matching Cloud Pro course, such as Cloud Pro: Azure Compute, if you need more depth.

Key takeaways

• Azure's hierarchy is tenant → management groups → subscriptions → resource groups → resources. A subscription matches an AWS account or a Google Cloud project. A management group matches an OU or a folder.
• In Azure the identity boundary is the tenant, one level higher than in AWS, where each account is its own IAM boundary.
• Resource groups have no direct equivalent in AWS or Google Cloud.
• Region pairs are specific to Azure, many newer regions have none, and a pair never fails over for you.
• Azure doesn't charge for data moved between zones in the same region. AWS does.
• AWS Developer and Business Support end on 1 January 2027.
• In the tables, "no direct equivalent", notes and ⚖ judgement marks matter as much as the matches.