Microsoft Azure Architecture and Services: Understanding Azure from a Datacenter Perspective

Microsoft Azure can initially appear complicated because it contains Hundreds of Services, Resource types, Management Tools, Security Capabilities, and Deployment Options. The easiest way to understand Azure is not to Memorize Every Service. Instead, understand what Azure is, who Controls each Layer, how Resources are Organized, and how the Azure Operating Model differs from a Traditional Datacenter.

At a High Level, Azure Provides Compute, Networking, Storage, Databases, Security, Identity, Application Platforms, Monitoring, Automation, and many other Services from Infrastructure Operated by Microsoft.

The Fundamental Difference is Simple:

In your own Datacenter, you Own or Control the Underlying Infrastructure. In Azure, Microsoft Controls the Physical Infrastructure and Exposes Predefined Cloud Resources and Services that Customers Configure and Consume.

This distinction affects almost everything: Server Sizing, Networking, Storage, Security, Availability, Capacity Planning, Change Management, and Troubleshooting.

1. What Is Microsoft Azure?

Microsoft Azure is a Global Cloud Computing Platform operated by Microsoft.

Instead of an Organization Purchasing Physical Servers, Storage Arrays, Network Switches, Firewalls, Racks, Power Systems, Cooling Systems, and Datacenter Space for every Workload, Azure makes Computing Resources Available as Services.

A Simplified Architecture looks like this:

Microsoft Global Infrastructure

            │

            ▼

       Geographies

            │

            ▼

         Regions

            │

            ▼

Availability Zones / Datacenters

            │

            ▼

Microsoft Physical Infrastructure

            │

     ┌──────┼──────┐

     ▼      ▼      ▼

  Compute Storage Network

     │      │      │

     └──────┼──────┘

            ▼

     Azure Platform

            │

 ┌──────────┼──────────┐

 ▼          ▼          ▼

Compute   Network    Storage

 ▼          ▼          ▼

VMs       VNets      Disks

VMSS      Firewall   Blobs

AKS       VPN        Files

Apps      LB         Data Lake

            │

            ▼

 Identity / Security / Governance

            │

            ▼

 Monitoring / Management / Automation

            │

            ▼

      Customer Workloads

The customer works primarily with the logical Azure resources exposed by the platform rather than Microsoft's physical equipment.

2. Azure Global Infrastructure

At the bottom of everything are real physical datacenters.

Azure infrastructure can conceptually be viewed as:

Geography → Region → Availability Zone → Datacenter → Physical Infrastructure

A Region is a geographic area in which Microsoft operates Azure infrastructure and makes particular Azure services available.

Many regions support Availability Zones. Availability Zones provide physically separated infrastructure within a region, with independent power, cooling, and networking characteristics designed to improve workload resiliency.

Underneath these abstractions are Microsoft's physical servers, network infrastructure, storage systems, power, cooling, buildings, and global backbone network.

This infrastructure belongs to and is operated by Microsoft.

That immediately establishes an important Azure boundary:

An Azure customer does not administer Microsoft's physical servers, switches, storage arrays, hypervisors, racks, power systems, or datacenter facilities.

Microsoft Operates those Layers.

3. Azure Control Plane

Between the administrator and Microsoft's Infrastructure is an extremely important part of Azure: the Control Plane.

When an administrator creates a VM in the Azure Portal, they are not logging into a Microsoft hypervisor and creating a VM directly.

The request follows the Azure management architecture.

Administrator

      │

      ├── Azure Portal

      ├── PowerShell

      ├── Azure CLI

      ├── REST API

      ├── Bicep / ARM

      └── Terraform

             │

             ▼

     Azure Resource Manager

             │

             ▼

       Resource Provider

             │

             ▼

       Azure Platform

             │

             ▼

        Azure Resource

Azure Resource Manager (ARM) provides the management framework through which Azure resources are deployed and managed.

Azure Resource Providers implement particular resource types.

Examples Include:

Microsoft.Compute

Microsoft.Network

Microsoft.Storage

Therefore, creating an Azure VM is fundamentally different from opening VMware vCenter or Hyper-V Manager and configuring a virtual machine against hardware that your organization controls.

4. Azure Resource Organization

Azure provides a Hierarchical Management Structure.

Microsoft Entra Tenant

        │

        ▼

Management Groups

        │

        ▼

Subscriptions

        │

        ▼

Resource Groups

        │

        ▼

    Resources

Management Groups

Management Groups provide Governance above Subscriptions. Policies and Access Controls can be Applied Across Groups of Subscriptions.

Subscriptions

A Subscription Provides an Administrative, Billing, Quota, and Resource Boundary.

Resource Groups

A Resource Group is a Logical Container used to Organize related Azure Resources.

Resources

Resources are the actual Azure Objects being Consumed.

Examples Include:

• Virtual Machine
• Virtual Network
• Storage Account
• Network Interface
• Public IP Address
• Azure Firewall
• Key Vault
• SQL Database
• Load Balancer

This Hierarchy is one of the major differences between Azure and Traditional Datacenter Administration.

5. Core Azure Service Categories

Although Azure contains a very large number of Services, most Infrastructure discussions can initially be Organized into Several Major Categories.

The important point is that Azure does not merely provide Virtual Machines in Microsoft's Datacenters.

Azure provides an Entire Service Ecosystem surrounding those Workloads.

6. Compute: Azure Virtual Machines

Azure Virtual Machines are probably the easiest Azure service for traditional infrastructure administrators to understand.

Conceptually:

Physical Server

     │

     ▼

Hypervisor

     │

     ▼

Virtual Machine

still exists underneath the Platform.

However, the customer does not manage those underlying layers.

Instead, Microsoft exposes predefined VM configurations called VM SKUs.

For example, an Azure VM SKU defines a particular combination of resources and capabilities such as:

Vcpu + Memory + Storage Capabilities + Network Capabilities + Platform Features

This produces one of the most important differences between Azure and traditional virtualization.

On-Premises

An Administrator may configure:

VM

├── 4 vCPU

├── 8 GiB RAM

├── 128 GB OS Disk

└── NIC

Later:

Need more RAM?

       │

       ▼

Change 8 GiB → 16 GiB

The Administrator Controls the Hypervisor and can Modify Supported Virtual Hardware Configurations.

Azure

Azure Works Differently.

Current VM SKU

Standard_xxxxx

      │

      │ Need more Memory

      ▼

Find Appropriate Azure VM SKU

      │

      ▼

Verify SKU Availability

      │

      ▼

Resize VM

You do not Independently Modify the Memory Allocation defined by an Azure VM SKU.

Microsoft defines Azure VM SKUs. Customers select the SKU that provides the required Resource Configuration and Capabilities.

This is an Extremely Important Architectural Distinction.

7. You cannot treat Azure like your Own Hypervisor

A common mistake is assuming:

“I'll deploy the VM with 8 GiB of RAM now and add another 8 GiB later.”

That is an On-Premises Virtualization Mindset.

Azure does not expose an Add Memory Operation that lets the Customer Alter a predefined VM SKU.

If additional Memory is required, the Administrator selects another VM SKU containing the required Memory.

That resize can introduce an interruption and, depending on the resize path and underlying capacity, may require deallocation.

Therefore, what appeared to be:

“Add another 8 GiB.”

can become:

Select SKU → Verify Compatibility → Verify Availability → Resize → Restart/Deallocate if required → Start VM

That difference should be understood before Production Capacity Planning, not discovered during a Production Outage.

8. Azure Networking

Azure Networking is Software-Defined.

A Virtual Network (VNet) provides the Primary Private Network boundary for Azure Resources.

Within a VNet, Administrators Create Subnets.

Azure VNet 10.10.0.0/16

       │

       ├── Web Subnet 10.10.1.0/24  

       │

       ├── Application Subnet 10.10.2.0/24

       │

       └── Data Subnet 10.10.3.0/24        

Azure then provides Specialized Networking Services around those Networks.

Examples Include:

Azure Load Balancer for Layer 4 Load Balancing.

Application Gateway for Layer 7 Application Delivery.

Azure Firewall for Managed Network Security.

VPN Gateway for Encrypted Connectivity.

ExpressRoute for Private Connectivity between Customer Environments and Microsoft.

Azure Front Door for Global Application Delivery.

Private Endpoint for Private Access to supported Azure Services.

The administrator designs the logical network architecture, but does not configure Microsoft's physical switches and routers.

9. Azure Storage

Traditional datacenters may require administrators to design and operate:

Local Disks → RAID → SAN → NAS → Storage Fabrics → Replication

Azure abstracts much of this into Services.

Examples Include:

Managed Disks for VM Persistent Storage.

Blob Storage for Object Storage.

Azure Files for Managed File Shares.

Data Lake Storage for Large-Scale Analytics-Oriented Storage.

The Customer chooses the Service, Configuration, Redundancy Model, Performance Characteristics, Access Controls, and other Supported Options.

Microsoft Manages the physical storage Infrastructure underneath those Services.

10. Identity and Access

Identity is Fundamental to Azure Architecture.

Microsoft Entra ID provides Azure's cloud identity platform.

Azure Resource Manager then uses Azure Role-Based Access Control (RBAC) to determine who can perform particular Operations against Azure Resources.

Conceptually:

Identity

   │

   ▼

Authentication

   │

   ▼

Authorization

   │

   ▼

Azure RBAC

   │

   ▼

Subscription / Resource Group / Resource

Instead of simply asking:

“Who is a Local Administrator?”

Azure Architecture also asks:

“Who can create, Delete, Modify, Read, or Manage this Azure Resource?”

This separates Control of the Azure Resource from Administration inside the Operating System.

Someone can have Permission to Manage an Azure VM Resource without Automatically having Administrative Access to Windows inside that VM, and Vice Versa.

11. Security Is a Shared Responsibility

Moving infrastructure to Azure does not transfer all security responsibility to Microsoft.

Responsibility depends on the Service Model.

For an Azure VM, Microsoft is responsible for the Underlying Physical Infrastructure and Platform Components under its Responsibility.

The Customer remains responsible for Substantial Portions of the Workload Configuration, including areas such as Operating-System Configuration, Identities, Permissions, Applications, and Data.

Conceptually:

                    CUSTOMER

                    │

          Data / Applications

                    │

          Identity / Configuration

                    │

            Operating System

                    │

       ───── Responsibility Boundary ─────

                    │

              Azure Platform

                    │

               Hypervisor

                    │

             Physical Servers

                    │

          Network / Datacenter

                    │

                MICROSOFT

The precise Boundary changes when using managed PaaS or SaaS Services.

The more infrastructure Azure manages for the Customer, the less underlying Infrastructure the Customer Administers.

12. Azure Governance

A Traditional Datacenter frequently Controls Infrastructure through Organizational Processes and Administrator Permissions.

Azure Adds Platform-Level Governance Mechanisms.

For example, Azure Policy can Evaluate and Enforce Requirements against Azure Resources.

An organization might Establish Policies Controlling:

Allowed Azure regions

Permitted resource types

Required resource tags

Security configuration

Network configuration

Diagnostic settings

Governance can therefore become part of the Platform rather than existing only as Documentation saying what Administrators are supposed to do.

13. Azure Monitoring and Resource Management

Azure also provides Centralized Monitoring and Management Services.

Azure Monitor provides a Broad Monitoring Platform.

Log Analytics provides Log Collection and Query Capabilities.

Application Insights Provides Application Performance Monitoring.

Azure Update Manager Provides Update-Management Capabilities.

Azure Automation Supports Automation.

Cost Management Provides Cloud Cost Visibility and Analysis.

Service Health provides Information about Azure Service Issues and Planned Maintenance relevant to Customer Resources.

This means Azure Architecture is not complete simply because the VM, Network, and Storage exist.

A properly designed environment also requires:

Resources

   │

   ├── Monitoring

   ├── Logging

   ├── Security

   ├── Identity

   ├── Governance

   ├── Backup / Recovery

   ├── Automation

   └── Cost Management

14. Azure vs. Traditional Datacenter Infrastructure

The following comparison captures the fundamental operating-model difference.

15. What Azure Customers CAN Do

Azure Customers have Substantial Control over the Resources Exposed by Azure.

They can choose VM SKUs, Operating Systems, Regions, Availability Architecture, Network address spaces, subnets, routing, firewall policies, Storage Configurations, Identity Permissions, Encryption Options, Monitoring, Backup, Application Architecture, Scaling Configuration, and Thousands of other Supported Settings.

They can also Automate Infrastructure using:

Bicep

ARM Templates

Terraform

PowerShell

Azure CLI

REST APIs

This makes Azure Highly Configurable—but configurable within the abstractions and capabilities Microsoft Exposes.

16. What Azure Customers CANNOT Do

Understanding what Customers cannot Control is Equally Important.

An Azure Customer cannot simply decide to:

Install another DIMM into the physical Azure server.

Modify a Microsoft-Defined VM SKU to contain a different amount of RAM.

Replace Microsoft's Physical Network Switches.

Select an arbitrary Physical CPU configuration outside available Azure offerings.

Walk into an Azure Datacenter and Repair the Server Hosting the VM.

Control Microsoft's underlying Hardware Maintenance Procedures.

Customer Consumes the Capabilities Exposed by Azure. That is it.

That produces the fundamental Azure Model:

Microsoft Designs, Operates, and exposes the Cloud Platform. The Customer selects, Configures, Secures, Connects, Monitors, and Operates the Azure Resources and Services required by the Workload.

17. Azure is not simply someone else's Datacenter

This is perhaps the most Important Concept for someone Learning Azure.

Azure contains Datacenters, Servers, Networks, Storage Systems, and Virtualization Technology, but Azure should not be approached merely as a remote VMware or Hyper-V Environment.

The Architecture is Service-Oriented.

Instead of Asking:

“What Hardware Should I Install?”

you increasingly ask:

“Which Azure Service Provides the Capability the Workload Requires?”

Instead of: Build Storage Server

you might select Azure Files.

Instead of: Build Load-Balancing Appliances

you might select Azure Load Balancer, Application Gateway, or Front Door, depending on the requirement.

Instead of: Build a Kubernetes Cluster from Virtual Machines

you might use Azure Kubernetes Service.

Instead of: Build a Database Server

you might use Azure SQL Database.

This shift from Building Infrastructure Components to selecting Platform Capabilities is central to Cloud Architecture.

18. The Most Important Mental Model

For someone coming from traditional infrastructure, the easiest way to remember Azure architecture is:

TRADITIONAL DATACENTER

You Own/Control Infrastructure

        ↓

You Build the Platform

        ↓

You Configure Virtual Hardware

        ↓

You Deploy Applications

MICROSOFT AZURE

Microsoft Operates Infrastructure

        ↓

Azure Exposes Services/Resources

        ↓

You select and Configure Them

        ↓

You Secure and Govern them

        ↓

You Deploy Applications

Neither Model Eliminates Engineering.

It changes where Engineering Responsibility Exists.

In the Datacenter, considerable Engineering effort is devoted to Building and Maintaining the Underlying Infrastructure.

In Azure, much of that Physical Infrastructure is Abstracted away, while Architecture increasingly concentrates on Service Selection, Resource Configuration, Identity, Networking, Security, Governance, Resiliency, Automation, Observability, and Cost.

Summary

Microsoft Azure is a Globally Distributed Cloud Platform built on Physical Infrastructure Operated by Microsoft and exposed to Customers through Standardized Resources, Services, APIs, and Management Interfaces.

The Customer does not control Azure in the same way an Administrator Controls an On-Premises Datacenter or hypervisor.

The Fundamental Relationship is:

Microsoft Controls the Physical Cloud Infrastructure.

Azure defines the Services and Supported Capabilities.

Customers Select and Configure those Services.

Customers remain responsible for correctly Architecting their Workloads within the Azure Platform.

Once that Distinction is Understood, the enormous Azure Service Catalog becomes much easier to understand. Azure Stops looking like Hundreds of Unrelated Products and starts looking like a Collection of Compute, Networking, Storage, Data, Identity, Security, Governance, Management, and Application Services built on top of a Common Global Cloud Architecture.

Found this Article Useful? 😊
If this Article saved you an hour of Troubleshooting, a few minutes of searching, or one Microsoft documentation Rabbit Hole, consider turning some of that saved time into a Coffee. ☕ Your support helps keep new Technical Guides coming.