Azure Functions & Serverless Computing

Azure Fundamentals

Chapter 7 · Azure Functions & Serverless Computing

Azure Functions became generally available on 15 November 2016 — a real, striking near-exact two-year echo of AWS Lambda's own real launch on 13 November 2014 (AWS Fundamentals Chapter 7). The two services solve the same real problem, but genuinely diverge on execution limits and how a function connects to other data.

Real Hosting Plans

Azure Functions offers several genuinely different real hosting plans, each with its own execution model:

Flex Consumption — the real current recommended default for serverless functions: pay-as-you-go, scales dynamically (up to 1,000 instances), with optional always-ready instances to reduce cold starts.
Consumption — the original, now-legacy plan (Linux support retiring 30 September 2028); still pay-as-you-go, but with real, tighter limits than Flex Consumption offers.
Premium — real prewarmed, always-warm instances, avoiding cold starts entirely, with more CPU/memory options and longer real allowed execution times.
Dedicated (App Service) — functions run continuously on provisioned instances; cold start "isn't really an issue" at all, per Microsoft's own real documentation, since the host is always running.

A Real, Genuine Difference From Lambda: No Universal Hard Ceiling

Genuinely Different Execution Limits

AWS Lambda enforces a real, fixed 15-minute maximum execution time, with no exceptions, regardless of configuration (AWS Fundamentals Chapter 7). Azure Functions works differently depending on the plan: the legacy Consumption plan has a real, tighter 5-minute default / 10-minute maximum timeout — actually shorter than Lambda's own ceiling — but Flex Consumption, Premium, and Dedicated all offer real, effectively unbounded execution time (with a 60-minute grace period during scale-in events, and 10 minutes during platform updates). A genuinely long-running job that would need to be redesigned or split up for Lambda can, on the right Azure Functions plan, simply keep running.

A Real, Easy-to-Miss HTTP Gotcha

230 Seconds, Regardless of Your Own Timeout Setting

Even on a plan with an unbounded function timeout, an HTTP-triggered function has a real, separate, hard ceiling: 230 seconds to respond to any single request — a limit imposed by the default idle timeout of the underlying Azure Load Balancer itself, not by your own function's own configured timeout at all. A function's own functionTimeout setting genuinely cannot override this. For longer real HTTP-triggered processing, Microsoft's own real recommendation is the Durable Functions async pattern — return an immediate response and process the real work separately.

Triggers & Bindings

Azure Functions has a real, distinctive, declarative concept AWS Lambda doesn't offer in the same form: every function has exactly one real trigger (itself a special kind of input binding, defining what invokes the function and optionally passing in data), plus any number of optional real input bindings (data flowing in) and output bindings (data flowing out) — configured declaratively, rather than by writing manual SDK client calls inside the function's own code.

// function.json — an HTTP trigger with a Queue Storage output binding
{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"]
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue"
    }
  ]
}
  

The function's own code never has to construct a Storage SDK client, authenticate it, or manage a connection — it simply receives the incoming request via the req parameter and returns a value that Azure automatically writes to the queue via the msg output binding. Functions genuinely support multiple bindings at once — a real function could, for example, read from a queue (input) and write to a database (output) in the same invocation.

Bindings Are Optional, Not Mandatory

Azure Functions doesn't force this declarative model on you — you can still create an Azure SDK client directly in your own code and manage connections manually, exactly as a Lambda function typically does. Bindings are a real, genuine convenience layered on top, not a hard requirement.

Cold Starts

On the legacy Consumption plan (and Flex Consumption without always-ready instances configured), a function app can scale to zero when idle, and the next real invocation pays a genuine cold-start delay. Premium's own prewarmed instances, and Dedicated's own continuously-running host, both avoid this real cost entirely — the same underlying tradeoff Lambda's own Provisioned Concurrency feature addresses (AWS Fundamentals Chapter 7), just built into the choice of hosting plan itself in Azure's model.

API Management

Azure's own real equivalent of API Gateway (Chapter 7 of AWS Fundamentals) is Azure API Management — it sits in front of one or more Azure Functions (or any other backend), handling routing, authentication, rate limiting, and request/response transformation before traffic ever reaches your own function code.

Lambda vs. Azure Functions

Property	AWS Lambda	Azure Functions
Real launch	November 2014	November 2016
Max execution time	15 minutes, always, no exceptions	Unbounded on Flex Consumption/Premium/Dedicated; 10 min on legacy Consumption
HTTP response ceiling	Governed by the same 15-min limit	230 seconds, regardless of function timeout setting
Data connections	Manual SDK client calls, typically	Real declarative triggers/bindings, optionally
Avoiding cold starts	Provisioned Concurrency (a feature)	Premium/Dedicated plan choice, or always-ready instances

Hands-On Exercises

Exercise 1

A team needs a function that reliably runs for 25 minutes to process a large real batch job, and they're deciding between AWS Lambda and Azure Functions on the Flex Consumption plan. Explain, in your own words, why this job genuinely cannot run unmodified on Lambda, but could run on Azure Functions.

📄 View solution

Exercise 2

A team sets their HTTP-triggered Azure Function's functionTimeout to 20 minutes, expecting a slow request to be allowed to run that long. Explain, in your own words, why a request might still fail well before 20 minutes, and what real, separate limit is actually responsible.

📄 View solution

Exercise 3

Explain, in your own words, why a function using an input binding to read from a queue and an output binding to write to a database is considered more declarative than a Lambda function manually calling AWS SDK clients to do the same two things.

📄 View solution

Chapter 7 Quick Reference

Azure Functions — launched November 2016, real two-year echo of Lambda's own 2014 launch
Hosting plans — Flex Consumption (current default), legacy Consumption (5/10 min), Premium (prewarmed, no cold starts), Dedicated (always running)
Real major difference: Flex Consumption/Premium/Dedicated offer unbounded execution time — genuinely unlike Lambda's fixed 15-minute ceiling
Real gotcha: HTTP-triggered functions face a separate, hard 230-second response ceiling regardless of the function's own timeout setting
Triggers & bindings — declarative, optional input/output connections, avoiding manual SDK client code
API Management — Azure's real equivalent of API Gateway