How Microsoft's Cloud Platform Works Under the Hood

By vaayaa Editorial Team · Subject panel: Hiroshi Tanaka (PhD, Computer Science), Carlos García (Master's, Data Science)

Microsoft Azure is a cloud computing platform with a vast catalogue of services. This explainer works through the concepts a newcomer needs: region and availability design, the IaaS, PaaS and SaaS split, compute and networking services, storage options, the consumption pricing model, the shared responsibility boundary, and the governance tooling that keeps costs and access under control.

Cloud computing turns computing power into a metered utility. Azure is Microsoft's version of that utility, and understanding its basics means understanding four things: how Microsoft arranges its physical estate, what categories of service sit on top of it, how it charges for them, and where the customer's responsibility begins. The sections below work through each of these in plain terms, with worked examples and the design choices beginners routinely get wrong.

What cloud computing actually changes

Renting computing capacity instead of owning it removes three constraints that defined earlier IT. The first is lead time: capacity that once took weeks to procure arrives in minutes. The second is capital layout, since spending shifts from upfront hardware purchase toward usage-based billing. The third is operational load, because the provider maintains the physical equipment and the customer configures only what sits above it ^[3][8].

That shift is described through a handful of standard characteristics. The National Institute of Standards and Technology framework, which Microsoft's own training content mirrors, names on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service ^[9]. Together these properties mean a customer can provision, scale and retire resources without human negotiation with the provider.

Resource pooling matters more than it first appears. Physical servers are shared across many tenants, and virtualization is the mechanism that keeps those tenants isolated from one another. That is why a single virtual machine can be created in seconds and priced by the hour. Isolation is a software guarantee, not a physical one, and the platform's architecture is built around enforcing it.

Elasticity and scalability are related but distinct. Scaling out means adding more instances to handle load. Scaling up means moving to a larger instance size. Elasticity is the ability to do either automatically and then reverse it when demand falls. A workload that scales out but never scales back in is paying for peak capacity around the clock, which is one of the most common cost mistakes in cloud operations.

Public, private and hybrid deployment models

The deployment model answers a simple question: whose hardware runs the workload? In a public cloud model, Microsoft owns and operates the estate and customers share it. In a private cloud, the infrastructure is dedicated to one organization, whether on-premises or hosted. Hybrid combines the two, keeping some systems local while others run in the public cloud ^[9].

Hybrid is not a compromise; it is frequently the correct answer. Regulated data, latency-sensitive machinery and legacy systems with no cloud equivalent often belong on local servers, while web front ends, analytics and disaster recovery targets sit comfortably in the public cloud. Azure Arc exists specifically to bring on-premises and multi-cloud resources under a single management control plane ^[9].

Choosing a model well comes down to four inputs: data residency obligations, latency requirements, existing sunk investment in hardware, and the compliance posture of the organization. A hospital that must keep patient records in a specific jurisdiction and a startup building a consumer app will reach different conclusions from the same set of facts. There is no universally better model.

Community cloud is a fourth, narrower option in which several organizations with shared concerns pool infrastructure. It appears less often in practice than the other three but is worth recognizing because services can be deployed into government and sovereign variants that behave similarly for compliance purposes ^[4].

IaaS, PaaS and SaaS: the responsibility ladder

The service model determines where the customer's management burden stops. With infrastructure as a service, the provider supplies compute, storage and networking, and the customer installs and patches the operating system, runtime and application. With platform as a service, the provider also manages the operating system and runtime, leaving the customer responsible for code and data. Software as a service hands over a finished application, and the customer manages only users and content ^[4][9].

The boundaries are not abstract. A virtual machine running a custom database engine is infrastructure as a service: someone must apply operating system patches. A web app deployed to Azure App Service is platform as a service: the platform handles patching and scaling, and the developer ships code. A hosted email or collaboration suite is software as a service: nobody in the customer's organization touches a server ^[5].

Most real architectures mix all three. A typical business system might run a lift-and-shifted legacy application on virtual machines, a new customer portal on a managed app platform, and productivity tooling as a hosted service. The skill being tested here is not memorizing labels but recognizing which model a given component belongs to, because that determines who gets paged when something breaks.

Regions, region pairs and availability zones

The platform's physical footprint is organized hierarchically. A region is a geographic area containing one or more datacenters networked together with low latency. Regions are paired with a partner region in the same geopolitical boundary for services that replicate automatically. Availability zones are physically separate groups of datacenters within a single region, each with independent power, cooling and networking ^[4][5].

That structure exists to make resilience concrete. Deploying two virtual machines in different availability zones of the same region protects against a datacenter-level failure while keeping latency low. Deploying across paired regions protects against a broader regional event, at the cost of higher cross-region latency and data transfer charges ^[5].

Sovereign regions serve specific legal jurisdictions with separate operational agreements. These exist because some public sector and regulated customers cannot use the standard commercial regions regardless of the technical merits. Reading a region list without understanding which regions are sovereign, and which services are available in each, is a frequent source of design rework.

Not every service is available in every region. Service availability varies, and some newer capabilities launch in a subset of locations first. Checking regional availability before committing to an architecture is a mundane step that saves substantial rework later.

The resource hierarchy that governs everything

Resources are grouped into four nested levels: resources, resource groups, subscriptions and management groups. A resource is a single deployable item such as a virtual machine or storage account. A resource group is a logical container for resources that share a lifecycle. A subscription is a billing and access boundary. A management group sits above subscriptions and applies policy and access across many of them at once ^[4][5].

The practical value of resource groups comes from deletion behavior. Removing a resource group removes every resource inside it. That makes resource groups the natural unit for temporary environments, demonstrations and project cleanup. It also makes careless grouping dangerous, since a group that mixes production and test resources turns cleanup into an outage.

Subscriptions usually reflect organizational structure: one per department, one per environment, or one per billing arrangement. Management groups then enforce common rules across the whole estate. This hierarchy is what makes governance scale, because a policy defined once at the management group level applies to every subscription beneath it without anyone repeating the configuration.

Naming and tagging conventions belong at this layer too. Tags are key-value labels applied to resources for cost allocation, ownership and environment tracking. A tagging standard written before the first resource is deployed is cheap; retrofitting one across hundreds of resources is not.

Compute choices from virtual machines to functions

Azure offers several compute models, and picking among them is mostly a question of how much control the workload needs. Virtual machines provide full control of the operating system, suitable for custom software, legacy applications and anything requiring specific kernel configuration. Virtual Machine Scale Sets add automatic horizontal scaling to identical machine images. Azure Virtual Desktop hosts desktop sessions for remote workers ^[4][5].

Containers package an application with its dependencies and run on a shared host operating system, which makes them lighter and faster to start than virtual machines. Azure Functions goes further, running individual pieces of code in response to events with no server management at all. This event-driven style is often called serverless compute, though servers obviously still exist; the point is that nobody on the customer's team manages them ^[4].

App Service sits between these poles, hosting web applications and APIs on a managed platform. The tradeoff is consistent across the range: more managed means less operational work, and less managed means more control over the environment. A team without a dedicated operations function should lean managed; a team with unusual runtime requirements may not have that option.

The most common beginner error is defaulting to virtual machines for everything. Lift-and-shift migrations often start there because they are familiar, and that is a legitimate first step. Staying there indefinitely, though, means paying for patching labor and idle capacity that a managed service would absorb.

Networking in virtual networks

A virtual network is the fundamental networking construct in Azure, defining a private address space within which resources communicate. It is subdivided into subnets, each with its own range carved out of the parent space. Azure reserves a small number of addresses in each subnet for internal platform tasks, so the usable address count is always slightly lower than the theoretical maximum ^[5].

Subnets typically separate tiers of an application, for example a front-end subnet and a database subnet, so that network security rules can be applied at the boundary. Two virtual networks do not communicate by default. Connecting them requires peering, which must be configured explicitly, and traffic crossing regional boundaries incurs additional charges ^[5].

Address planning deserves more attention than it usually gets. Ranges must not overlap with on-premises networks if a hybrid connection is ever likely, and they must leave room for growth. Rebuilding a virtual network because the original range collided with a corporate network is a painful and entirely avoidable migration.

Domain name resolution is the other half of networking. A managed DNS service handles registering and resolving names, and private DNS zones cover internal resolution for virtual networks. Route tables control where traffic flows, which becomes relevant when directing traffic through a firewall appliance or back to a local network ^[7].

Storage types and when each fits

Azure storage comes in several forms aimed at different access patterns. Blob storage holds unstructured objects such as files, images and backups. File storage offers managed file shares accessible over a standard protocol. Table storage holds structured NoSQL key-value data. Queue storage carries messages between application components ^[3].

The distinction that newcomers miss is access tiering. Blob data can be stored in tiers that trade retrieval cost against storage cost, so data read frequently belongs in a hot tier while archival data can sit in a cold or archive tier at far lower storage cost but with higher retrieval charges and latency. Choosing the wrong tier for a workload can invert the expected savings entirely.

Durability is achieved through replication. Options range from multiple copies within a single datacenter to copies spread across availability zones or paired regions. Each step up improves resilience against a wider class of failure and raises the cost. Matching replication choice to the value of the data is the core decision.

Databases are a separate family from raw storage. Relational engines, NoSQL services and analytics warehouses each serve different query patterns. Beginners often default to a familiar relational engine for every job, which works for transactional systems but becomes expensive and awkward for large-scale analytics.

The consumption pricing model

Billing runs on consumption for most services. Charges accrue while a resource runs, measured in seconds or hours for compute, in gigabytes for storage, and in data transferred for networking. This model converts a fixed capital cost into a variable operating expense, and it means an idle virtual machine still costs money ^[8].

Several levers reduce that bill without changing the architecture. Reserved capacity commits to a term in exchange for a discount. Spot pricing takes advantage of unused capacity at a steep reduction in exchange for the possibility of eviction. Stopping and deallocating a virtual machine halts compute charges, whereas merely shutting down the operating system inside it does not ^[3].

The critical concept is that pricing follows the resource, not the machine's internal state. A common beginner surprise is a large bill from a virtual machine that was off but never deallocated in the platform's terms. Cost tooling that shows spend by resource group and by tag makes such cases visible before they become a monthly shock.

Service level agreements set the availability commitment for each service and differ across tiers. A service offered at one availability target may be financially backed at that level only when deployed in a multi-zone configuration. Reading the agreement rather than assuming a single number applies to everything is part of costing an architecture honestly ^[3].

Shared responsibility and the security boundary

The shared responsibility model is the single most useful mental tool for cloud security. Microsoft is responsible for the physical datacenters, hosts, network fabric and the hypervisor. The customer is responsible for data, identities and access configuration. The grey area in between shifts depending on whether the workload is infrastructure, platform or software as a service ^[4][5].

Concretely: with infrastructure as a service, the customer patches the operating system and secures the application. With platform as a service, Microsoft patches the platform and the customer secures code, configuration and data. With software as a service, Microsoft handles almost everything and the customer handles user access and data classification. The line moves, and misunderstanding where it sits is a recurring cause of exposure.

Identity is the customer's territory in every model. Access control, conditional policies, multi-factor authentication and privileged role assignment all sit firmly on the customer side. A platform that is secure by default still becomes insecure when permissions are too broad or credentials leak.

Security tooling supports this work rather than replacing it. Posture management surfaces misconfigurations, compliance tooling maps controls to regulatory frameworks, and Microsoft's own enterprise records indicate very high adoption among large organizations, which is one reason these skills appear across many job descriptions ^[2].

Governance, cost control and the certification map

Governance here is enforced through policy rather than documentation. Policies can require tags, restrict which regions resources may be created in, or block specific service types outright. Because policies attach at management group and subscription level, they apply uniformly without relying on individual discipline ^[4].

Cost management works alongside this. Budgets generate alerts when spend approaches a threshold. Cost analysis breaks expenditure down by resource group, tag or service. Combined with the resource hierarchy, these tools let finance and engineering discuss the same numbers instead of arguing from separate spreadsheets.

The certification ladder mirrors the service catalogue. Introductory credentials cover cloud concepts, core architecture and governance at a basic level, and a roadmap for beginners usually starts there before branching into administration or development tracks ^[1]. A published guide to the credential types organizes them into fundamentals, associate, expert and specialty levels, which helps a newcomer see where the first checkpoint sits and what comes after it. Community-reported results put pass rates for these entry exams noticeably above the expert-tier ones ^[11]. That gap reflects the material, not the difficulty of the underlying platform.

The exam's domain weightings reveal what Microsoft considers foundational. Cloud concepts occupy roughly a quarter to a third of the assessment, architecture and services take the largest share at around 35 to 40 percent, and management plus governance account for the remainder ^[4]. The distribution is a reasonable study plan in itself: architecture and services deserve the most attention, but governance is not optional.

Business audiences gain something distinct from the same material. A non-technical professional who understands the vocabulary can sit in meetings, reason about costs and reduce onboarding friction, which is why the topic is recommended as a baseline skill beyond engineering roles ^[2]. A commercial training provider makes a parallel case, arguing that the entry credential demonstrates a grasp of principles critical to modern business and supports career transitions into cloud sales, project management and operations ^[10]. A further benefits-oriented write-up points to the demand for people who can work with the platform as its service range grows, which broadens the pool of roles that value the knowledge ^[6]. Microsoft's own introductory module frames the platform as a way to build solutions ranging from simple web hosting to full custom software and managed data services. Together these sources agree on one point: the concepts travel well beyond the certificate, and the certificate is merely a convenient checkpoint.

Frequently asked questions

Conclusion

Cloud basics are less about memorizing a service list than about internalizing a few structural ideas: the physical hierarchy determines resilience options, the service model determines where management ends, the pricing model follows the resource rather than its internal state, and the responsibility boundary determines who secures what. Get those four straight and the individual service names become details that fill in around a frame you already understand. The natural next step is to build a small environment, watch what it costs, and confirm that the responsibility split you wrote down matches what the platform actually enforces.

References

1. GUVI. Azure Certification Roadmap: 7 Certifications Beginners Must Know.
2. LinkedIn. Why Azure is a must-have skill for non-engineers.
3. ITnation. (AZ-900) Microsoft Azure Fundamentals.
4. Intunedin. AZ-900: Microsoft Azure Fundamentals Exam Resource Guide (November 2025 Update).
5. GitHub. Guide for the Microsoft Azure Fundamentals Certification (AZ-900).
6. Microtek Learning. 5 Key Benefits of Microsoft Azure Fundamentals.
7. Skillsoft. Courses for Cloud Foundation to Azure Foundation.
8. LinkedIn. AZ-900 Certification: Key Takeaways and Career Path.
9. Skillsoft. Microsoft Azure Fundamentals: Azure Cloud Computing.
10. Readynez. Beginner's Guide to Microsoft Azure AZ-900 Certification.
11. NicheeLab. Azure Certification Pass Rates: Difficulty Ranking and How Not to Fail.