Azure Functions

What Azure Functions actually is

Azure Functions is Microsoft's serverless compute platform: you deploy small units of code, and Azure runs them in response to events — an HTTP request, a queue message, a blob upload, a timer, a Service Bus event, a webhook from a third-party system. The preview opened in March 2016 and the service went generally available on November 15, 2016, which makes it one of the older established serverless runtimes and explains both its breadth and its accumulated rough edges.

The mental model is a trigger and a binding. A function declares what starts it (trigger) and what it connects to (input and output bindings — storage queues, Cosmos DB, Event Hubs, SignalR, and dozens more). Most integration plumbing disappears into configuration. On top of that sits Durable Functions, which adds stateful orchestration: chaining, fan-out/fan-in, human-approval workflows, and long-running processes that would be awkward as raw event spaghetti. For .NET teams this is the strongest serverless story on the market, and the bindings model is why: the equivalent AWS Lambda code usually carries explicit SDK calls that Functions handles declaratively.

Hosting plans shape everything. Consumption bills per execution and per gigabyte-second and scales to zero. Flex Consumption (newer) adds configurable instance sizes, per-instance concurrency, VNet integration, and optional always-ready pre-warmed instances. Premium (Elastic Premium) eliminates cold starts and keeps at least one instance allocated at all times. Dedicated runs inside a regular App Service plan you already pay for. There is also a Container Apps hosting option. You can mix languages — C# and JavaScript were GA at launch, with Python, Java, PowerShell, and others added since — and deploy from Visual Studio, VS Code, the CLI, or CI/CD pipelines.

We track it under serverless platforms, where its closest comparison points are AWS Lambda and Cloudflare Workers.

Pricing: what you really pay

The Consumption plan's free grant is the part that makes Azure Functions genuinely cheap for small workloads: 1 million executions and 400,000 GB-s of resource consumption per month, per subscription, permanently. Beyond that, the metered rates are $0.20 per million executions and $0.000016 per GB-s (Microsoft's own worked example — 1.1 million billable GB-s — totals $17.60, which is exactly that rate). Resource consumption is measured as memory in GB times execution time in seconds, with memory rounded up to the nearest 128 MB (max 1,536 MB) and a 100 ms per-execution minimum.

A few thousand invocations a day of sub-second functions costs nothing. That is not spin: an HTTP-triggered function serving 5 million requests a month at 200 ms and 256 MB lands around $0.80/month in execution charges with the GB-s consumption inside the free grant. The break-even conversations start at scale. Flex Consumption runs $0.000026 per GB-s on demand and $0.40 per million executions, with always-ready baseline instances at $0.000004 per GB-s while idle. Premium has no execution charge but bills allocated vCPU-seconds and memory-seconds from the moment the plan exists — an EP1 plan runs on the order of $146/month at US pay-as-you-go rates whether it serves traffic or not, and 1- or 3-year savings plans discount that.

Two costs hide outside the function bill. Every Functions app creates a storage account, and that account is billed separately at standard storage rates. And once Premium or Dedicated plans carry VNet-integrated traffic, networking charges apply. Our practical rule: Consumption for spiky and event-driven work, Premium above roughly 50–100 executions per second or whenever cold starts hurt, Dedicated only when an existing App Service plan already covers the compute.

Performance & infrastructure

Functions runs wherever Azure runs: 70+ regions (Microsoft's marketing pages say 80+), hundreds of datacenters, EU/US/APAC residency, plus sovereign clouds. At GA in 2016 it was available in 12 regions; today region coverage is effectively the whole platform. The service inherits Azure's free platform-level DDoS infrastructure protection and the standard compliance catalogue.

The performance story is dominated by cold starts. On Consumption, an idle function app pays latency on the first invocation after a scale event — variable, worse for .NET on Windows than for lightweight Python or JavaScript, and something you must measure with your own code. Flex Consumption reduces this with pre-provisioned per-instance concurrency and always-ready instances; Premium eliminates it by keeping a warm instance allocated. Maximum scale on Consumption is generous (200 instances on Windows, 100 on Linux, with per-instance memory capped at 1.5 GB and one core) — if your workload wants fat per-instance compute, this is not the shape you want.

Reliability is contractually stated rather than measured by us: Microsoft's SLA guarantees that functions on Consumption plans run 99.95% of the time after a trigger fires successfully, and that Flex Consumption and App Service-plan function apps run or are available 99.95% of the time, with service credits stepping 10% / 25% / 100% below 99.95% / 99% / 95%. Note the wording: on Consumption, an execution that never gets scheduled because the platform missed it counts; slow cold starts do not. Durable Functions' managed scheduler backends carry their own numbers — 99.95% on the Dedicated plan, 99.9% on the Consumption plan of the durable task scheduler. We have no hands-on numbers for Functions; our measurement work at /benchmarks covers conventional compute hosts.

Where it falls short

Cold starts remain the standing complaint for latency-sensitive HTTP workloads, and the fix — Premium or always-ready Flex instances — is exactly where the "serverless means free at idle" economics stop applying. If your traffic is steady rather than spiky, a small always-on VM from a value provider can be both cheaper and more predictable.

Billing predictability is the second issue. GB-s rounding (128 MB buckets, 100 ms minimum on Consumption) inflates the cost of very short, memory-attached functions, and the Azure surface around a "simple" function — storage account, Application Insights, Key Vault references, identity, networking — accumulates line items. The platform's complexity is the same complaint we make about Azure generally: powerful, documented, and a lot of it.

Platform constraints bite specific workloads: 1.5 GB memory and one core per Consumption instance, execution timeouts (5 minutes default on Consumption, configurable higher on Premium/Dedicated), and a 230-second HTTP request timeout on Consumption that forces async patterns for long requests. Lock-in is real too — bindings and Durable Functions abstractions are Azure-shaped, and porting to Lambda is a rewrite of the integration layer even when the business logic survives.

Finally, support and docs are strong but enterprise-tier support is a paid relationship. Free/community support for a production outage is not a plan.

One point on operational maturity: Application Insights integration, deployment slots, and managed identity come as part of the platform workflow rather than as add-ons you discover during an incident. For teams without a dedicated operations function, that bundling matters more than raw function pricing. It is also where Azure's enterprise posture shows — the audit trail, RBAC, and policy controls satisfy procurement questions that a bare serverless offering would fail.

Who should pick this

We pick Azure Functions for Microsoft-centric teams building event-driven systems: queue and blob-triggered processing, workflow automation with Durable Functions, internal APIs, IoT ingestion, and scheduled jobs. If you already run .NET, use Entra ID, and deploy from Azure DevOps or GitHub Actions into an Azure estate, it is the path of least resistance and usually the cheapest one at low volume. The 1 million free executions per month make it our default recommendation for hobby projects and spiky MVP workloads inside the Microsoft ecosystem.

We would not pick it for steady high-throughput APIs (Premium pricing approaches always-on VM economics), for workloads needing more than ~1.5 GB per instance, or for teams that want to stay cloud-portable. For those, containers on a plain VPS or a Kubernetes cluster measured in our benchmarks is the more honest fit. And if you are not a Microsoft shop, AWS Lambda or Cloudflare Workers will usually integrate better with what you already run.

Key takeaways

• Serverless compute on Azure since November 2016 (GA), with trigger/binding integrations and Durable Functions for stateful workflows.
• Consumption plan free grant: 1 million executions plus 400,000 GB-s per month; beyond that $0.20 per million executions and $0.000016 per GB-s.
• Cold starts on Consumption are real for latency-sensitive work; Flex Consumption ($0.000026/GB-s, $0.40/million executions) and Premium ($0.000004/GB-s idle baseline for always-ready) are the mitigation — and the cost.
• Premium bills allocated compute continuously (an EP1 plan is roughly $146/month at US rates) and has no execution charge.
• SLA: 99.95% for Consumption, Flex, and App Service-plan apps, with credits up to 100% below 95% uptime.
• Best for .NET/Azure estates and event-driven workloads; wrong fit for steady high-throughput traffic or cloud-portable designs.

Sources

• https://azure.microsoft.com/en-us/pricing/details/functions
• https://azure.microsoft.com/en-us/products/functions
• https://azure.microsoft.com/en-us/blog/announcing-general-availability-of-azure-functions/
• https://www.azure.cn/en-us/support/sla/functions/
• https://learn.microsoft.com/en-us/azure/reliability/regions-overview
• https://azure.microsoft.com/en-us/explore/global-infrastructure
• https://azure.microsoft.com/en-us/products/ddos-protection
• https://modal.com/blog/azure-function-pricing-guide
• https://dev.to/martin_oehlert/scaling-azure-functions-consumption-vs-premium-vs-dedicated-2gm
• https://microsoftnegotiations.com/blog/azure-functions-licensing-guide
• https://en.wikipedia.org/wiki/Microsoft