Serverless computing — also known as Function as a Service (FaaS) — lets developers run code in the cloud without provisioning or managing any infrastructure. You upload your code, the platform executes it on demand, and you pay only for the compute resources consumed during execution. No idle servers, no capacity planning, no OS patching.
Two platforms dominate this space for most enterprise teams: AWS Lambda, which launched in late 2014, and Microsoft Azure Functions, which followed in 2016. Both solve the same core problem, but they differ in meaningful ways. This article breaks down those differences so you can make an informed decision.
What “Serverless” Actually Means
The term is a misnomer — your code still runs on servers. What changes is who manages them. In a serverless model, the cloud provider handles all infrastructure concerns: server provisioning, scaling, availability, and runtime patching. Developers write functions that respond to events (an HTTP request, a file upload, a queue message) and the platform takes care of everything else.
This model is well-suited to event-driven workloads. Common use cases include:
- Media processing (video transcoding, image resizing)
- On-demand ETL pipelines
- Mobile and IoT back ends
- Web application APIs
- Stream and timer-based processing
- Webhook handlers and automation scripts
Programming Language Support
Language support is often the most immediately relevant differentiator, because it directly affects whether your existing developers can be productive on day one.
At the time of the original comparison (early 2017), the two platforms supported the following languages natively:
| Platform | Natively Supported Languages (at launch era) |
|---|---|
| AWS Lambda | Java, Node.js, Python, C# |
| Azure Functions | C#, F#, JavaScript, PHP, Python, Bash, PowerShell |
Both platforms have expanded their language support significantly since 2017 — AWS Lambda now supports runtimes including Go, Ruby, and custom runtimes via the Runtime API, while Azure Functions has similarly grown its supported language list. Always check the current documentation for each service before making a decision based on language support alone.
The practical advice remains sound: match the platform to the skills your team already has. If your back-end developers are primarily PHP or PowerShell practitioners, Azure Functions eliminates the need to introduce a new language. If your team lives in Python or Java, Lambda has been a mature option for those runtimes longer.
Pricing Models
Both services offer a permanent free tier (not just a trial) that is generous enough to cover low-volume workloads and experimentation:
- 1 million free requests per month
- 400,000 GB-seconds of compute time per month
Beyond the free tier, both services bill on two dimensions: the number of function invocations and the compute resources consumed (measured in GB-seconds or GB-milliseconds). The exact per-unit rates below are from the original 2017 source and should be verified against current pricing pages before budgeting.
Azure Functions Pricing (as of original article)
- $0.20 per million executions beyond the free tier
- $0.000016 per GB-second of compute usage
- Optionally, functions can run within an existing Azure App Service Plan, which changes the effective cost
AWS Lambda Pricing (as of original article)
- $0.20 per million requests beyond the free tier
- Compute fees scale with the memory allocation you configure: 128 MB costs approximately $0.000000208 per 100 ms; 1,536 MB costs approximately $0.000002501 per 100 ms
In practice, the headline compute costs are close enough that pricing alone is rarely the deciding factor. Where costs diverge is in the surrounding services: storage, databases, API gateways, data transfer, and monitoring. These ancillary costs can exceed the function execution costs themselves for many real-world applications, so model your full architecture when estimating spend.
Both AWS and Azure provide cost estimation calculators on their respective websites to help with this.
Ecosystem Integration: The More Important Factor
For most organizations, the surrounding ecosystem matters more than the FaaS platform itself. A serverless function rarely runs in isolation — it is triggered by, and produces output for, other cloud services: object storage, message queues, databases, API gateways, and monitoring systems.
John Chapin and Mike Roberts, co-founders of Symphonia (a serverless and cloud consultancy), put it clearly: “We often see developers and companies evaluating serverless compute offerings in a vacuum — the real value is in the capability of the entire serverless ecosystem that a cloud provider offers.”
This leads to the most actionable rule of thumb:
If your organization already has significant investment in a cloud platform, default to that platform’s serverless offering. Migrating data, re-integrating services, and retraining teams costs far more than any per-invocation pricing difference.
Teams already using S3, DynamoDB, API Gateway, and CloudWatch will find Lambda far easier to integrate than Azure Functions. Teams using Azure Blob Storage, Cosmos DB, and Azure Monitor will have the opposite experience.
How to Choose: A Decision Framework
Use these questions to guide your selection:
- Where does your existing infrastructure live? Default to the serverless offering from your primary cloud vendor.
- What languages does your team use? Check current runtime support for both platforms. This matters most if you use a less common language like F# or PowerShell.
- What events will trigger your functions? Verify that the triggering service (e.g., a specific message queue or storage event type) has native integration with your chosen platform.
- What does your full-stack cost look like? Model the cost of the entire event pipeline, not just the function invocations.
- Have you run a small proof of concept? Both platforms offer free tiers. Run a representative workload on each before committing.
Getting Started
Both AWS Lambda and Azure Functions are accessible through their respective consoles and CLIs, and both offer infrastructure-as-code support (AWS SAM / CloudFormation for Lambda; Bicep / ARM templates for Azure Functions). Start with a single, well-defined function that handles one event type — a webhook, a file-upload trigger, or a scheduled job — before expanding to more complex event-driven architectures.
The free tiers are generous enough that you can run meaningful experiments at zero cost. Take advantage of that before locking in a platform choice for production workloads.
This article is based on a comparison originally sourced from Datamation (2017), with updated context. Pricing figures and language support lists reflect the state of each platform at that time and should be verified against current AWS and Azure documentation.