Azure Functions vs AWS Lambda vs Google Cloud Functions

Three names for the same trick: hand the platform a bit of code, pick what wakes it up, and it runs and scales it for you. The trick is identical. Two Azure-specific pieces are where people crossing over stumble.

New to cloud? CAMPUX is a free, build-first course. Start here →

Azure Functions, AWS Lambda, and Google Cloud Functions are the same idea in three flavours — you upload a function, attach a trigger, and the platform runs it on demand and scales it out, billing per invocation plus compute time, with no servers to manage. What doesn't map cleanly is the packaging: Azure wraps your functions in a Function App with a chosen hosting plan (Lambda has no such grouping), and Azure lets you wire inputs and outputs declaratively with bindings (Lambda and GCF make you call the SDK yourself). Learn the shared idea once, then re-learn those two Azure parts.

Functions-as-a-service is the row on every cloud cheat sheet that looks the most 1:1 — Azure Functions ⇄ Lambda ⇄ Cloud Functions, done. And for the core loop, that's fair. But I've watched Lambda engineers land on Azure, go looking for the "create a function" button, and get stuck on why they're being asked to make an app first. Let's map the honest parts and then open up where the mental model actually differs.

The shared idea, in one breath

On all three you write a small unit of code, you tell the platform what event should run it, and from then on the platform owns the hard part: spinning up instances when requests arrive, tearing them down when they stop, and charging you only for what ran. You never pick a server size or keep a box alive. That's serverless compute, and it's genuinely the same primitive on Azure, AWS, and GCP. The disagreements are all in the packaging around that unit.

The terminology, three vocabularies

Here's the mapping. Read the first three rows as near-synonyms; the rows on grouping and bindings are where the analogy leaks, and we open those up below.

The core loop is a true synonym. The Function App and bindings are not — they're the two rows a Lambda veteran actually has to learn.

Leak one: the Function App has no Lambda equivalent

This is the first thing that trips people. On Lambda you deploy a function and that's the whole object — it carries its own runtime, memory, timeout, and triggers, and there's nothing above it except the account. On Azure the unit you deploy and configure is the Function App, and your individual functions live inside it. The app is what owns the runtime version, the app settings, and — crucially — the hosting plan and scaling behaviour. Several functions in one app share all of that.

So "deploy a function to Azure" really means "deploy a Function App that contains one or more functions." Coming from Lambda, expect that extra layer and expect to make a plan decision you never had to make on AWS. It's not busywork once you see it — the app is a sensible boundary for a set of related functions that should scale and be configured together — but it is a genuine structural difference, not a rename.

Leak two: bindings, the Azure convenience nobody else copied

On Lambda or Cloud Functions, if your function needs to read a blob or drop a message on a queue, you import the SDK, build a client, handle its config, and call it — plumbing code inside every function. Azure's bindings let you declare that plumbing instead of writing it. An input binding hands your function a Blob or a Cosmos document already loaded; an output binding writes a Queue message or a database row when you return a value. A trigger is really just a special binding — the one that starts the function.

That means a lot of Azure functions have almost no glue code: the wiring lives in configuration, and the body does the actual work. It's a real difference in how you write the code, not just a different word for the same thing. Whether you love it or find it too magic is taste, but it's the Azure-distinctive feature to know about.

Leak three: hosting plans, and where "serverless" is heading

Lambda is pure consumption — you pay per use and buy provisioned concurrency if you need instances kept warm. Google Cloud Functions is likewise consumption, and its 2nd gen is actually built on Cloud Run underneath. Azure gives you a choice up front: Consumption (classic pay-per-use), Flex Consumption (fast scale with more control), Premium (pre-warmed, no cold starts, VNet access), or Dedicated on an App Service plan (runs on VMs you already pay for). Picking that plan is part of setting up Functions on Azure, and it's a decision the other two mostly don't ask you to make.

Worth naming the trend, too: the line between functions and containers is blurring. GCP folded its functions onto Cloud Run, and Azure Container Apps and AWS App Runner sit right next to FaaS as "serverless containers." So "serverless" now spans both functions and serverless containers — if your workload outgrows a function, the neighbouring service is often a short hop, and on Azure that's containers on Azure.

What about cold starts?

All three suffer cold starts — the delay when the platform has to spin a fresh instance to serve a request after a quiet spell. It's the same tax on every cloud, and every cloud sells the same fix: keep some instances warm. Azure does it with the Premium plan or always-ready instances; Lambda with provisioned concurrency; GCF with a minimum-instances setting. If cold starts matter for your latency, you pay to hold capacity — the mechanism has three names but one shape.

So what about the money?

All three bill the same way — per invocation plus compute time, memory times duration — and all three have a free tier, so the real number depends on your traffic and memory settings more than on the logo. The differences are small and situational, and they deserve their own careful look rather than a throwaway table here. We cover the pricing and free-tier battle in detail separately in AWS Lambda vs Azure Functions — go there for the money side; this piece is about the mental model.

If you're learning this for the first time, do it on Azure, where the Function App, the plan, and bindings make the moving parts visible as separate things you set on purpose. Once you've felt that split, Lambda collapsing everything into a lone function and GCF leaning on Cloud Run both read cleanly. That's the order we teach it in — start with Azure Functions explained, then carry it across with this guide.

Common questions