What Is Cloud Computing? An Azure AZ-900 Guide

Cloud computing is the delivery of computing services over the internet, so you can rent technology instead of owning it. Those services include compute (processing power such as virtual machines), storage (space to keep files, databases, and backups), and networking (the connections that tie everything together). A cloud provider such as Microsoft Azure owns the physical datacenters, servers, and hardware, and lets you use that capacity on demand.

The word on-demand is important. You request resources when you need them and they are ready in minutes, not the weeks or months it takes to buy and install physical equipment. When you no longer need a resource, you switch it off and stop paying for it. This is very different from a traditional setup where you buy servers up front, house them in your own room, and maintain them yourself whether they are busy or idle.

Because the provider runs the underlying infrastructure, you can focus on your applications and data rather than on cables, cooling, and hardware failures. In one sentence, cloud computing is the on-demand delivery of compute, storage, and networking over the internet on a pay-as-you-go basis. That single sentence captures what every Azure service has in common.

The consumption-based model means you pay only for the resources you actually use, and only for as long as you use them. There is no large payment up front and no charge for idle capacity you have not requested. If you run a virtual machine for three hours, you pay for three hours; if you store fifty gigabytes of data, you pay for fifty gigabytes. This is what people mean by pay-as-you-go.

This model brings real advantages. You stop guessing capacity: instead of buying enough hardware to survive your busiest day and letting it sit idle the rest of the year, you scale your spending up and down with real demand. You also pay for what you consume rather than for what you predict, which lowers waste. And because a resource can be created in minutes, you can experiment cheaply and delete anything that does not work out.

For example, an online shop expecting a holiday rush can add extra Azure capacity for December and remove it in January, paying only for that busy period. A traditional business would have had to buy servers for the peak and keep paying for them all year. The idea behind the phrase "pay only for what you use" is the consumption-based model. Pay-as-you-go is its default pricing, but it is not the only way to buy cloud capacity — the next sections compare it with committed options.

Cloud computing changes not just how you buy technology but the kind of expense it is. Traditional, on-premises IT is a capital expense (CapEx): you spend a large amount of money up front to buy physical assets such as servers, storage arrays, and networking gear, plus the datacenter to house them. You own those assets and typically write off their cost over several years, whether or not you use them fully.

Cloud computing is instead an operating expense (OpEx): an ongoing cost for a service you consume, billed as you go, much like a utility bill for electricity. There is no big purchase and nothing to own or depreciate — you simply pay for the resources you used this month.

The test is ownership and timing: buying and owning datacenter hardware up front is CapEx, while paying each month for cloud resources you consumed is OpEx. Moving to the cloud shifts spending from CapEx to OpEx.

Cloud pricing models differ in one trade-off: how much you commit in advance versus how much you pay per hour. Pay-as-you-go needs no commitment and costs the most per unit; committed options lower the rate in exchange for paying for a term whether you use the capacity or not; buying your own hardware is the most up-front of all. Choosing well means matching each model to a demand pattern.

Pay-as-you-go is the default cloud model: you are billed only for what you consume, for as long as it runs, with no term and no fixed fee. You can resize or delete a resource at any time. Be precise about what "stops" means: a virtual machine that is deallocated (stopped from the portal) stops accruing compute charges, but its managed disks keep billing for the storage they hold, and so does a static public IP address. Only deleting a resource ends all of its charges.

Fixed or up-front capacity is the traditional alternative: you buy (or lease on a fixed contract) enough capacity for your peak and pay for it every day, busy or idle. If demand drops, you keep paying; if it grows past your purchase, you must buy more and wait.

Azure also offers ways to pay less than pay-as-you-go in return for a commitment or for accepting interruptions:

Matching the model to the demand

Most real workloads have a steady baseline plus peaks. Commit only to what you are sure to use: cover the always-on baseline with a reservation (or a savings plan if its sizes and regions will shift), and run the peaks on pay-as-you-go so the extra capacity costs nothing when it is not running. Reserving for the peak pays for idle capacity all year; running the baseline on pay-as-you-go gives up a discount you could have had. When the deciding factor is "no commitment at all", only pay-as-you-go fits.

Between the two commitments, the distinction is flexibility versus depth of discount: a reservation is the better buy when the VM family and region are fixed for the whole term, while a savings plan trades some of that discount for the freedom to change VM sizes, regions or compute services.

Serverless computing is a cloud model in which the provider runs and scales all of the servers for you, and your code runs only when an event triggers it — so you pay for the executions and resources your code actually consumes, with little or no charge while it is idle. It is the consumption-based model taken to its furthest point: you do not provision, size or patch any server.

"Serverless" does not mean there are no servers. The code still runs on servers in Microsoft's datacenters; the name means the servers are invisible to you because the provider manages them. Four traits define it:

• No server management — no operating system, patching or capacity planning on your side.
• Event-driven execution — code starts in response to an event, such as a file upload, a message on a queue, an HTTP request or a timer, and does not keep running between events.
• Automatic scaling — the platform adds instances as events arrive and scales back down, often to zero, when they stop.
• Pay per execution — billing follows the executions and resources consumed rather than reserved capacity, so idle time costs little or nothing.

In Azure, Azure Functions (run code on events) and Azure Logic Apps (run workflows on events) are the classic serverless services when they are hosted on a consumption-based plan. They are covered in more depth in Domain 2.

Serverless versus always-running services

Platform as a service already removes OS management, so the difference from serverless is how the service runs and bills, not who patches it:

So serverless suits work that happens in bursts or occasionally — resizing an image when one is uploaded, processing a message, running a nightly clean-up — where an always-on server would sit idle most of the time.

The shared responsibility model describes how security and management duties are divided between the cloud provider and you, the customer. Moving to the cloud never makes everything the provider's job, and it never leaves everything to you. In your own on-premises datacenter you own every layer; in the cloud, each side owns part of the stack, and where the line sits depends on the service type.

Three responsibilities always stay with you, whatever service you use:

• Information and data — what you store and who may see it.
• Devices — the phones and PCs that are allowed to connect to your cloud resources.
• Accounts and identities — the people, service accounts and credentials that access your environment.

Three responsibilities always belong to the provider: the physical datacenter, the physical network and the physical hosts. Microsoft secures the buildings, the servers and the cabling — you can never manage those.

Everything in between varies by service type: the operating system, network controls, applications, and identity and directory infrastructure. The more of the stack the provider runs for you, the more of these move to the provider.

Read the table as a slider. With IaaS (for example, Azure virtual machines) you patch and secure the guest operating system yourself. Move the same workload to PaaS — say, a web application moved from a VM to Azure App Service — and the operating system and runtime become Microsoft's to maintain, while the information, the accounts and the access you grant remain yours. With SaaS (for example, Microsoft 365) Microsoft runs the application itself, yet you are still responsible for your data, the devices that connect and your users' identities. Note the difference between accounts and identities (always yours) and identity and directory infrastructure (the identity platform itself, which shifts toward shared).

A cloud model describes who can use the cloud resources and where they run. The three core models are public, private and hybrid; Microsoft also describes multicloud, and Azure offers tools for running across mixed environments.

A public cloud is built, controlled and maintained by a third-party provider such as Microsoft Azure, and anyone who wants to buy cloud services can use it. That general public availability is the key difference from a private cloud. Many customers share the provider's hardware, with their resources logically isolated from one another. There is no capital expense to scale up, applications can be provisioned and removed quickly, and you pay only for what you use — but you do not have complete control over the resources and their security.

A private cloud is a cloud used by a single entity. It may be hosted in your own onsite datacenter, or in a dedicated datacenter offsite — even one run by a third party that has dedicated that hardware to you. What makes it private is single-entity use, not its location. It gives the most control over resources and security, but you must buy the hardware and are responsible for its maintenance and updates.

A hybrid cloud uses public and private clouds in one interconnected environment. It can let a private cloud surge into the public cloud for increased, temporary demand, and it lets you decide where each application runs — keeping regulated data private while using the public cloud for the rest. It offers the most flexibility.

Multicloud means using two or more public cloud providers at once — for example, a team that uses one provider's AI service while the rest of its estate runs on Azure — which means governing resources, identities and costs in more than one cloud. It differs from hybrid, which combines public with private.

Azure tools for mixed environments: Azure Arc and Azure VMware Solution

Two Azure offerings come up with hybrid and multicloud setups, and they solve different problems:

Azure Arc itself is covered in more depth with the other management tools in Domain 3.

Each cloud model suits different situations; match the scenario's deciding requirement to the model built for it.

Choose a public cloud when you want low up-front cost, fast setup, and the ability to scale to very large workloads without buying hardware. A startup launching a new web application, or any team that wants to experiment and grow quickly, is a natural fit. You accept less control over the underlying hardware in exchange for speed and flexibility.

Choose a private cloud when you need maximum control or must meet strict compliance, security, or data-residency requirements that call for dedicated, single-tenant hardware. A bank or a government agency with rules about exactly where and how data is held may prefer a private cloud, accepting higher cost and more management in return. The hardware can still sit in a third party's facility, as long as it is dedicated to that one organization.

Choose a hybrid cloud when you want the strengths of both. A common example is a hospital that keeps confidential patient records in a private cloud for compliance while running its public-facing website and appointment booking in the public cloud. Another is a business that runs day to day on private infrastructure but bursts into the public cloud to handle seasonal spikes. Keeping some systems private while using the public cloud for the rest — or surging a private environment into public capacity for a temporary peak — is the defining hybrid pattern.

Choose multicloud when you deliberately use more than one public provider — for example, to use a service only one provider offers, or because different teams already run on different clouds. If you also want one place to manage and govern those resources where they run, that is the role of Azure Arc; if you instead want to move VMware workloads into Azure without retooling, that is Azure VMware Solution.

Let us tie the ideas together with one story. Imagine a small company, Contoso, that currently runs its accounting software on a few aging servers in a cupboard. Those servers were a capital expense: bought up front, owned by Contoso, and maintained by its own staff whether busy or idle.

Contoso decides to move to Microsoft Azure. Now it rents virtual machines and storage on demand over the internet and pays only for what it uses each month — its spending has shifted from CapEx to an ongoing operating expense. Under the shared responsibility model, Microsoft secures the physical datacenter and hardware, while Contoso stays responsible for its own data, user accounts, and access.

Because Contoso must keep some financial records on dedicated hardware for compliance, it keeps those in a private cloud and runs everything else in the public cloud — a hybrid arrangement. Its accounting servers run all day, every day, at the same size, so it covers them with an Azure reservation for a lower rate. When the busy end-of-year period arrives, it adds pay-as-you-go capacity for a few weeks and removes it afterward, paying only for that peak thanks to the consumption-based model. And a small piece of code that converts each uploaded invoice to PDF runs as a serverless function, costing nothing between uploads.

That single example uses every idea in this lesson: on-demand delivery over the internet, pay-as-you-go, CapEx versus OpEx, pricing models, serverless, shared responsibility, and the public, private, and hybrid cloud models. If you can explain Contoso's move, you understand what cloud computing is.