Serverless Computing in Azure: Azure Functions and Event-Driven Billing

Serverless computing is a cloud execution model in which Azure automatically allocates, scales, and manages the infrastructure that runs your code, so you write and deploy functions without ever provisioning or maintaining a server. The flagship example in Azure is Azure Functions, which runs small pieces of event-triggered code and charges you only for the compute time that code actually consumes. If a workload fires occasionally, in response to unpredictable events, and should cost close to nothing while it sits idle, serverless is almost always the answer.

What “serverless” actually means

The name is misleading — servers still exist, running in Azure’s datacenters, just like they do for every other compute service. What makes serverless different isn’t the absence of hardware; it’s the absence of customer-managed infrastructure. With Azure Functions, you never pick an operating system image, size a virtual machine, configure a host-level firewall rule, or install a security patch. Azure’s platform decides how many instances your code needs at any given moment, starts them, and shuts them back down, including scaling all the way to zero when there’s nothing to process. That’s a sharp contrast with Infrastructure as a Service, Platform as a Service, and Software as a Service, where even the lightest-touch model still leaves you with some layer of the stack to configure.

Azure Functions is Microsoft’s primary serverless compute offering, but it isn’t the only one — Azure Logic Apps, which runs workflow-based automations triggered by events, is also a serverless service. Both share the same defining traits: no servers to provision, automatic scaling driven by demand, and billing tied to actual usage rather than pre-allocated capacity.

How execution-based billing works

A serverless function running on a consumption plan is billed by two things: how many times it executes, and how much compute time and memory it consumes while running. There’s no charge for the seconds, hours, or days between triggers. Picture a function that resizes a photo and generates a thumbnail the instant a user uploads an image to storage — outside of those upload moments, the function costs nothing, because there’s no reserved capacity sitting idle waiting for the next event.

This is the opposite of how a virtual machine or an always-on hosting plan works. A VM you provision for peak load keeps costing money at 3 a.m. when nobody is using it, and it keeps needing patches whether or not it’s doing anything useful — that always-on pattern is exactly where Azure VM scale sets and availability sets come in, since you’re the one configuring how that capacity scales. A consumption-plan function has no such floor: zero events in an hour means zero dollars for that hour, the same execution-based logic behind the CapEx-to-OpEx shift that consumption pricing enables generally.

Serverless vs. other Azure compute options

	Azure Functions (serverless)	Azure App Service (PaaS)	Virtual Machines (IaaS)
Who scales it	Azure, automatically, including to zero	Azure scales within your configured plan	You configure and manage scale sets
Who patches the OS	Nobody — no guest OS is exposed to you	Azure patches the host OS and runtime	You patch the guest OS yourself
Billing basis	Per execution and compute time consumed	Per allocated plan tier, continuously	Per provisioned VM, continuously
Best fit	Occasional, event-triggered, bursty tasks	Steady, always-on custom applications	Full control over the OS and stack

Azure App Service, Azure Functions, and containers sit on the same continuum of “how much of the stack does Azure manage for you” — Functions is the far end of that spectrum, where Azure owns everything except the code you write.

Matching workload patterns to the right model

The exam-relevant skill here isn’t memorizing that Functions is serverless — it’s recognizing which workload description points to serverless versus something else. A customer-facing web application that needs to be available all day, handling steady traffic, is usually a poor fit for pure serverless billing; it’s better matched to an always-on PaaS host like App Service. A small piece of code that runs a handful of times a day, triggered by a file upload or a webhook, is the textbook serverless case: no dedicated infrastructure staff needed, no idle cost, and automatic scale-out if a burst of events arrives all at once.

Some scenarios blend both patterns — a steady web front end paired with an occasional report-processing job. The correct approach isn’t to force everything into one model; it’s pairing each workload with the hosting approach that matches its actual usage pattern.

How the AZ-900 exam tests this

• The event-triggered, cost-sensitive task. A scenario describes a small job — resizing images, processing an upload, reacting to a webhook — that runs unpredictably and shouldn’t cost anything while idle. The correct answer is a serverless function; wrong answers dangle an always-on VM sized for peak load, a dedicated on-premises server, or a private cloud deployment, all of which keep costing money and needing maintenance during idle time.
• The billing-model identification. A question asks how a serverless workload is typically billed. The right answer ties billing to executions and compute time consumed; distractors offer a flat monthly fee, a per-employee charge, or a one-time perpetual license — none of which reflect consumption-based pricing.
• The scaling-and-patching responsibility split. A question compares who scales capacity and who patches the OS between a serverless function and an IaaS virtual machine. Azure handles both automatically for serverless; for IaaS, the customer configures scaling and applies OS patches.
• The mixed-workload matching question. A scenario pairs a continuously running application with a small, occasional task and asks which hosting combination fits both. The correct pairing puts the steady app on a managed PaaS host and the occasional task on a serverless function — not everything crammed into one model.

Recognizing these four patterns is most of what AZ-900 asks about serverless; work through AZ-900 practice questions built around exactly these scenario shapes to make the pattern automatic.

Quick reference

• Serverless doesn’t mean no servers exist — it means Azure manages them, not you.
• Azure Functions and Azure Logic Apps are Azure’s core serverless offerings.
• Consumption-plan billing charges for execution count and compute time consumed, not for idle capacity.
• Serverless scales automatically, including down to zero, when there’s no work to do.
• You never patch a guest operating system in Azure Functions — that entire layer is Azure’s responsibility.
• Serverless fits occasional, event-driven, bursty workloads; steady, always-on applications usually belong on App Service or virtual machines instead.
• When a scenario blends both patterns, match each workload to its own hosting model rather than forcing one approach to cover everything.