Azure Functions vs AWS Lambda for a small project — which to pick?
People agonise over this like it's a database migration. For one small project it isn't. Pick the one your app already lives next to, ship it, and get on with the actual work.
New to cloud? CAMPUX is a free, build-first course. Start here →
For a genuinely small project, pick the serverless platform whose ecosystem your app already lives in. Both Azure Functions and AWS Lambda have effectively-free hobby tiers — roughly a million requests a month, free — so price does not decide this. Ecosystem, the thing that triggers your function, and the skills you already have decide it. That is the whole answer. The rest of this note is just helping you read which side of the line you're on.
I've watched engineers burn an evening comparing per-millisecond billing for a function that will run four hundred times a month. That is a rounding error inside a rounding error. If you have real traffic and real scale, the money starts to matter and there is a place for that math — I'll point you at our full Lambda vs Functions pricing deep-dive for the 1ms-vs-100ms detail and the free-tier fine print. For a side project, weekend build, or internal tool, the free tier absorbs you whole and the decision is about fit, not cost.
Why price isn't the lever here
Both platforms front-load a generous free grant: on the order of a million invocations and 400,000 GB-seconds of compute per month, renewed monthly, no expiry. A small project's problem is almost never "I blew past a million requests." It's "I forgot this thing existed and it accreted a $3 storage bill." The compute is free; the incidental plumbing — a storage account, a log workspace, an egress here and there — is what shows up on the invoice, and it looks nearly identical on both clouds.
So if the money is a wash, stop weighing it. Weigh the friction instead: how fast can you, specifically, get this deployed and forget about it. That is a function of what you already know and what your code already touches.
The cheapest platform is the one you don't have to learn from scratch this weekend.
The decision, in five questions
Run down these. Most people get a clear lean after the first two.
| What you're weighing | Lean Azure Functions if… | Lean AWS Lambda if… |
|---|---|---|
| Language | You write C#/.NET, PowerShell, or a TypeScript app that already targets Azure. .NET support is first-class and native here. | You write Python, Go, or Rust, or want the widest set of community runtimes and layers. Lambda's ecosystem is broadest. |
| What triggers it | The event source is a Microsoft thing — a Blob upload, a Service Bus queue, Cosmos DB changes, an Event Grid event, a Graph webhook. The bindings do the wiring for you. | The event source is an AWS thing — S3, SQS, DynamoDB streams, EventBridge, an API Gateway route. The native integration is tighter and better documented. |
| Where you already live | You have an Azure subscription, a resource group, and identities in Entra already. Keeping one control plane and one bill is worth more than any feature gap. | Your account, your IAM roles, your VPC, and your existing services are all in AWS. Don't open a second cloud for one function. |
| Cold-start tolerance | It's a background job, a webhook, or a low-traffic API where a second of first-hit latency is invisible. The Consumption plan is fine, and Flex Consumption trims cold starts if you need it. | Same tolerance — Lambda cold starts are comparable. If you truly can't have them, provisioned concurrency exists, but that's rarely a small-project need. |
| How you like to deploy | You want to right-click-publish from VS Code, use the Functions Core Tools locally, or wire it through Azure DevOps / GitHub Actions with Bicep. | You reach for the SAM CLI, the Serverless Framework, Terraform, or CDK, and you think in CloudFormation-shaped stacks. |
Count your leans. If they cluster on one side, you're done — go build. If they split, the tie-breaker is always the third row: where you already live. Adding a second cloud provider to a small project doubles the surface you have to secure, monitor, and remember, in exchange for a feature edge you will not feel at this size.
If you're learning cloud on Azure — as most people reading this are — the honest call is Azure Functions, and not because it's technically superior. It's because your subscription, your Entra identities, and your muscle memory are already there. Every hour you'd spend learning Lambda's IAM model and CloudFormation is an hour not spent shipping. Keep the project on the cloud you're getting good at. Reach for Lambda when a specific job genuinely lives in AWS.
What actually bites you later
The platform choice is reversible; the coupling is what stings. Your function body — the code that does the work — ports between clouds in an afternoon. What doesn't port is everything around it: the trigger bindings, the identity model, the deploy pipeline, the environment config. So write your logic as plain, boring functions with the platform handler as a thin shell on top. Do that and a future migration is a shell-swap, not a rewrite. Skip it and you've hand-welded your business logic to one vendor's event system.
The other thing that bites: forgetting the project exists. Serverless doesn't idle to zero cost the way you hope — the compute does, but the log workspace and storage account keep a small meter running. Put a budget alert on the resource group the day you deploy. It's five minutes, and it's the difference between a free project and a mystery $4 you'll notice in March. If cost hygiene is new to you, the cost management class covers exactly this.
My default, stated plainly
Absent a reason to do otherwise: build it where you already are, keep the logic portable, set a budget alert, and don't think about it again until you have traffic. When you do have traffic — real, paying, growing traffic — that's the moment to open the pricing deep-dive and let the money argue back. Not before. A small project's scarcest resource is your attention, and the fastest path to shipping is the platform you don't have to learn twice.
Common questions
Is Azure Functions or AWS Lambda cheaper for a small project?
For a small project, neither — both give you roughly a million free requests and 400,000 GB-seconds of compute per month, which most hobby and side projects never exceed. You will pay nothing on either for a long time. Cost only becomes a real differentiator at scale, where Lambda's 1ms billing granularity beats the Azure Consumption plan's 100ms rounding. That detail is covered in our full pricing deep-dive.
Which is easier to get started with, Azure Functions or Lambda?
Whichever cloud you already have an account and skills in. If you write C# or already use Azure DevOps or a Microsoft stack, Azure Functions is the shorter path — the local tooling and VS Code extension are strong. If you live in AWS and think in IAM roles and CloudWatch, Lambda is the shorter path. The tools are close enough that your existing familiarity outweighs any raw ease-of-use gap.
Do cold starts matter for a small project?
Rarely. For a background job, a webhook handler, or a low-traffic API, a cold start of a few hundred milliseconds to a second or two is invisible. It only matters if a human is waiting on a synchronous response and you cannot tolerate the occasional slow first request. If that describes you, warm-start options exist on both, but on a small project it is usually a non-issue.
Can I switch from one to the other later?
Your business logic ports easily; the glue does not. The function body — the actual code that runs — moves in an afternoon. What ties you down is the surrounding wiring: triggers, bindings, the identity model, and the deploy pipeline. Keep your logic in plain, framework-light functions and treat the platform handler as a thin shell, and a future move stays cheap.