Paying for the cloud: the consumption-based model, pricing models and serverless

Why this matters

The cloud changes how a company pays for IT before it changes anything else. A finance director sees servers disappear from the asset register and a monthly bill appear instead. A project manager can start a trial without a purchase order. A developer can run code without asking anyone for a server. Each of those people needs to know how the bill is built, because the same workload can cost very different amounts depending on how it is bought.

Without this, money leaks in predictable ways. A team buys a three-year commitment for a project that is cancelled in a month. Another leaves a steady database on pay-as-you-go rates for years and pays far more than it needed to. A third puts a server that must never stop on the cheapest option, which can be switched off at short notice. This lesson explains the consumption-based model, the main ways Azure prices compute, and serverless computing, where the customer stops thinking about servers at all.

The lesson

Describe the consumption-based model

Under the consumption-based model, a customer pays for the resources it uses, while it uses them, and stops paying when it releases them. There is no hardware to buy before starting.

Take a virtual machine that runs for ten days of a month and is then deleted. The customer pays for ten days of compute and nothing after deletion. Bills still arrive monthly, but they add up what was actually used rather than charging a full month for every resource.

The model changes the type of spending.

• Capital expenditure (CapEx) is up-front spending on physical assets, such as servers, storage and networking equipment bought for a datacenter. The company pays a large sum at once and then depreciates the asset's value over several years.
• Operational expenditure (OpEx) is ongoing spending on services as they are used. No asset is bought. Cloud services billed by consumption are OpEx.

The difference matters most for demand that changes. On premises, a company must buy enough hardware for its busiest day. For the rest of the year that capacity sits idle, but it has already been paid for. In the cloud, costs follow usage. An online retailer whose traffic triples over the holiday season pays for the extra resources during the peak and stops paying once it scales back in January.

The benefits, in short:

• no up-front infrastructure costs;
• no need to buy capacity for the peak and leave it idle;
• pay for extra resources only when they are needed, and stop paying when they are released;
• a new product with an uncertain future can launch without buying anything first, so a poor forecast carries little financial risk.

A bill that varies with usage is a feature of this model, not a risk it removes. If usage grows, the bill grows with it. Keeping that under control is the subject of lesson 12.

Compare cloud pricing models

The consumption-based model is the principle. Azure offers several ways to buy compute under it, and they trade flexibility against price.

Pay-as-you-go. The default. A resource created without any commitment or discount is billed at the standard rate for the time it runs. There is no commitment, and charges stop as soon as the resource is removed. It suits short-lived, experimental or unpredictable workloads, such as a trial project that may be cancelled in a few weeks.

Azure Reservations. The customer commits to a specific resource, such as a VM size in a particular region, for a one-year or three-year term, in exchange for a significant discount on the pay-as-you-go price. It suits steady workloads that run all the time and will not change, such as a database server that must run around the clock for the next three years. The catch: a reservation is charged for the whole term whether or not the matching resources run. A company that shuts its reserved VMs down every night still pays for those hours, so the nights waste the discount. Stopping the VMs does not cancel the reservation or make them free.

Azure savings plan for compute. The customer commits to a fixed hourly spend on compute for one or three years. The discount applies across eligible compute services, VM sizes and regions. It suits a company whose overall compute spend is steady but which often changes VM sizes or moves workloads between regions. A reservation would lose value in that situation, because its discount is tied to one resource type in one region.

Azure Spot Virtual Machines. Spot VMs run on Azure's spare capacity at a deep discount. When Azure needs that capacity back, it can evict them at short notice. They suit work that can stop and restart at any time without harm, such as batch jobs or some test workloads. They are wrong for anything that must not be interrupted, however cheap they are.

Two other names appear in questions about pricing and are easily mixed up:

• Azure Hybrid Benefit lets a customer use Windows Server and SQL Server licences it already owns in Azure, to reduce the cost of those licences. It is a licensing benefit, not a commitment to compute.
• Azure Dedicated Host gives the customer a physical server reserved for its own VMs. It answers isolation and compliance needs. It is not a discount.

The Azure free account lets newcomers try a range of services at no charge, within limits that change over time. It is a way to start, not a pricing model for production work.

Choosing well comes down to two questions: how steady is the workload, and can it be interrupted? Steady and unchanging points to a reservation. Steady spend but changing shape points to a savings plan. Interruptible points to Spot. Unknown or temporary points to pay-as-you-go.

Describe serverless

Serverless computing means the cloud provider runs the servers, keeps them patched and scales them automatically. The customer deploys only its code or its workflow and pays for what runs.

The name is misleading. Servers still exist. The customer simply never sees, provisions or maintains them. A colleague who says serverless means "no servers at all" is wrong, and so is anyone who says it means code running on the user's own device.

Serverless has three typical traits:

• No server management. Microsoft manages the servers, the operating system and the scaling. The customer patches no guest operating system and provisions no capacity in advance. Those are the duties of infrastructure as a service (lesson 4).
• Event-driven. Code runs in response to an event, such as an HTTP request, a timer, a new message in a queue or a file uploaded to storage.
• Pay per use, and scale to almost nothing. The platform scales out as demand rises and back in as it falls. On a consumption plan, an idle application costs little or nothing.

Azure has two serverless services to know.

Azure Functions runs small pieces of code in response to events. A developer who wants a function to run each time a file is uploaded to storage, without managing any servers, uses Azure Functions. On a consumption plan, the company pays mainly for the number of executions and the time the code runs. A function that runs for a few seconds a few times a day costs very little, because no VM is running all day and night.

Azure Logic Apps builds automated workflows in a visual designer, using prebuilt connectors to many services. A team that wants to copy new email attachments into a database, designing the steps visually with no servers to manage, uses Logic Apps. Functions is code first; Logic Apps is design first.

Neither should be confused with services that look similar in a list of options:

• Azure Batch runs large parallel jobs on pools of virtual machines.
• Azure Kubernetes Service runs containers on a cluster of nodes that the customer sizes and manages.
• Azure Bastion gives secure remote access to virtual machines.
• Azure Monitor collects metrics and logs (lesson 16).

Serverless sits at the managed end of the range described in lesson 4. It builds on the platform idea, where Microsoft runs the platform, and takes it further: the customer does not even choose a server size.

What the exam is really asking

• CapEx versus OpEx. Buying servers for a datacenter is CapEx and is depreciated. Paying for cloud services as they are used is OpEx. Consumption-based billing creates OpEx.
• Costs follow usage. Under the consumption model a bill rises with a peak and falls afterwards. It does not stay fixed at the peak, and it is not a fixed price whatever is used. No multi-year contract is needed to start.
• The default is pay-as-you-go. A resource created with no reservation, savings plan or Spot setting is billed at pay-as-you-go rates.
• Reservation versus savings plan. Both are one-year or three-year commitments for a discount. A reservation is tied to a specific resource type and region; a savings plan commits to an hourly spend and follows the workload across sizes and regions.
• Commitments are paid for whether used or not. Stopping reserved VMs at night saves nothing.
• Spot means eviction. Spot VMs are the cheapest compute, but only for work that can be interrupted. A server that must not stop belongs on a reservation or pay-as-you-go.
• Serverless still has servers. The provider manages them. Look for "event", "no servers to manage" and "pay only when the code runs" to pick Azure Functions, and "visual workflow" or "connectors" to pick Azure Logic Apps.