Why Azure? Ecosystem, Resource Manager & Resource Groups

This is the second course in the site's own three-course Cloud Platform Specifics split, deliberately kept structurally parallel to AWS Fundamentals chapter-for-chapter — but Azure genuinely isn't just "AWS with different names." This chapter starts with its real, separate origin, and flags a genuine structural difference from AWS worth understanding from the very first chapter.

Azure's Real Origin

Azure was first introduced at Microsoft's own Professional Developers Conference in October 2008, under the real internal codename "Project Red Dog." It officially launched as Windows Azure in February 2010, and was renamed Microsoft Azure on 25 March 2014 — the same real year Microsoft introduced Azure Resource Manager (below), reflecting the platform's own broader shift beyond just Windows workloads.

Azure's Real Global Infrastructure

By fiscal year-end 2025, Microsoft reported Azure operating over 400 real datacenters across 70 regions — a genuinely large real footprint, grown from 54 regions as recently as 2018. Azure also runs a separate real CDN network of 118 point-of-presence Edge locations across 100 cities (as of January 2023), a similar concept to AWS's own Edge Locations from Chapter 1 of AWS Fundamentals.

Availability Zones — Where They Exist

Where a region does support them, an Azure Availability Zone is a real, logical grouping of one or more physically separate datacenters, each with independent power, cooling, and networking — the same underlying concept as an AWS AZ. Zones within a region are typically separated by several real kilometers (usually within 100 km of each other), and Microsoft's own real target for inter-zone network latency is under roughly 2 milliseconds. A genuinely useful real detail: Azure does not charge for data transfer between Availability Zones within the same region.

Zone-Redundant vs. Zonal Resources

Azure services that support Availability Zones typically offer two real deployment modes: zone-redundant (Microsoft automatically replicates or spreads the resource across multiple zones, and handles failover itself), and zonal (you deploy into one specific zone yourself, gaining fault isolation from other zones but taking on responsibility for your own multi-zone failover architecture, if you want one).

Azure Resource Manager & Resource Groups

Introduced in 2014, Azure Resource Manager (ARM) lets you organize related resources — a virtual machine, its storage, its network interface — into a real, named Resource Group, deployed, managed, monitored, and (if needed) deleted together as one logical unit. This is a genuinely different default organizational model from AWS, which has no single mandatory grouping construct of this kind — AWS resources are more commonly organized loosely via tags and account/VPC boundaries instead. In Azure, every single resource belongs to exactly one Resource Group from the moment it's created.

The Shared Responsibility Model Still Applies

Exactly the same real principle AWS Fundamentals Chapter 1 introduced holds here too: Microsoft secures the underlying physical infrastructure, while you remain responsible for your own data, access configuration, and (depending on the specific service) operating system and application layer. Nothing about that division changes just because the provider does.

Azure's Real Market Position

Per the same real, documented Synergy Research Group data already cited in AWS Fundamentals Chapter 1 (Q1 2023): Azure holds roughly 25% of the global cloud infrastructure market — second place, behind AWS's real ~31% and ahead of Google Cloud's real ~11%.

AWS vs. Azure — The Region/Zone Model, Compared

Hands-On Exercises