Serverless Compared: AWS Lambda vs Cloud Functions vs Azure Functions

Serverless computing is an event-driven execution model that runs application code in response to triggers without requiring teams to provision, patch, or manage the underlying infrastructure.

Three platforms dominate the function as a service (FaaS) space for cloud-native teams: AWS Lambda, Google Cloud Functions, and Azure Functions. Each carries a distinct billing model, scaling architecture, and ecosystem fit. Choosing the wrong one means paying for idle time your workload does not need, or locking into a trigger model that fights your architecture rather than supporting it.

What Serverless Computing Actually Means

Serverless computing removes the layer of persistent server management from application delivery. Developers write single-purpose functions, define a trigger, and the platform handles capacity, availability, and billing. The underlying compute infrastructure exists, but the cloud provider owns its operational burden. For teams weighing serverless computing against always-on servers, that shift in operational ownership is the central trade-off.

The model is a subset of FaaS, which lets you deploy individual callable units of code rather than a full application runtime. Those units activate on demand and return to an idle state when traffic drops. Billing follows execution rather than reservation, which is the defining characteristic of pay-per-invocation pricing.

Event-driven architecture (EDA) is the broader pattern that FaaS platforms are built for. Functions subscribe to events: an HTTP request arrives, a message lands in a queue, a file is written to object storage, a scheduled timer fires. The runtime responds, executes, and exits. For workloads with variable or unpredictable traffic, this model matches cost to actual demand more efficiently than a pool of always-on instances. For latency-sensitive, consistently high-traffic workloads, the cold start penalty and per-invocation overhead may favor container-based or dedicated compute instead. The contrast between those two scenarios is the central selection factor explored throughout this comparison. Background on the broader cloud compute spectrum: the edge computing vs cloud computing explainer covers where FaaS sits relative to edge runtimes and traditional cloud instances.

AWS Lambda: Triggers, Extensions, and Ephemeral Storage

AWS Lambda is the longest-running FaaS platform in production, and its depth of integration with the broader AWS ecosystem remains its primary competitive advantage. Lambda executes code in a managed execution environment that spins up in response to a trigger, runs the function handler, and either stays warm for subsequent invocations or recycles after inactivity.

Lambda supports a wide trigger surface: API Gateway, Application Load Balancer, S3 event notifications, DynamoDB Streams, SQS, SNS, EventBridge, Kinesis, and direct invocation via the SDK. This breadth makes Lambda the natural choice for teams running multi-service architectures on AWS, where the trigger source is already a managed AWS service.

Two differentiators stand out for production deployments. First, Lambda extensions allow external tooling to attach to the execution environment as independent processes. Monitoring agents, secret managers, and telemetry collectors can run alongside function code without modifying the handler itself. Extensions are billed at 1 ms increments, the same granularity as function execution time, so their cost contribution is observable (AWS Lambda Extensions documentation). Second, the per-function ephemeral storage at /tmp can be configured up to 10,240 MB, which enables processing of large artifacts such as video segments or ML model weights without streaming to S3 mid-function (AWS Lambda ephemeral storage announcement).

Key Lambda characteristics for architecture decisions:

• Billing granularity of 1 ms, charged per invocation plus duration
• Provisioned Concurrency to pre-warm execution environments and reduce cold start latency
• Lambda extensions ecosystem for observability and secrets injection without code changes
• Per-function configurable ephemeral /tmp storage up to 10,240 MB
• Native triggers across the full AWS service catalog, including EventBridge, Kinesis, and DynamoDB Streams
• Support for container image deployment alongside zip-based function packages

Teams already invested in AWS infrastructure will find that Lambda fits into a well-understood operational model. Scaling, retry behavior, and observability via CloudWatch are handled consistently across the service layer. For a deeper look at how Lambda's scaling model compares to compute-level auto scaling, see the load balancing and auto scaling comparison.

Google Cloud Functions: Pay-per-100ms and the v2 Shift

Google Cloud Functions is the GCP-native FaaS offering for lightweight, single-purpose event handlers. The runtime responds to HTTP requests or CloudEvents-format triggers, scales from zero automatically, and charges nothing during idle periods. Google meters execution time to the nearest 100 milliseconds, with no charge when idle, which can produce meaningful savings for functions with brief, sporadic execution patterns (Google Cloud Functions overview).

The product has undergone a significant nomenclature shift. Cloud Functions v2, which reached general availability in February 2025, runs on Cloud Run infrastructure rather than the original managed environment. Google now markets v2 deployments under the Cloud Run functions label, though the Cloud Functions API remains backward-compatible. Teams referencing current documentation should expect to see "Cloud Run functions" in the v2 context and "Cloud Functions" in legacy v1 content (Google Cloud Run functions runtime support).

Key Cloud Functions characteristics for architecture decisions:

• Pay-per-invocation billing metered to the nearest 100 milliseconds, no charge during idle
• Automatic scale-to-zero with no traffic, no charge
• v2 generation (now marketed as Cloud Run functions) supports longer timeouts and higher per-instance concurrency than v1
• CloudEvents trigger support for Pub/Sub, Eventarc, Cloud Storage, Firebase, and HTTP
• Minimum instance configuration available to reduce cold start frequency for latency-sensitive workloads
• Runtime lifecycle managed with a 90-day deprecation notice period before support ends for any given runtime version

For teams building GCP-native microservices or lightweight data pipelines that react to Pub/Sub or Cloud Storage events, the pay-per-100ms model and deep GCP integration make Cloud Run functions the low-friction path. Teams with mixed cloud or AWS-primary footprints may find the GCP-specific Eventarc trigger surface less useful.

Azure Functions: Hosting Plans and the Flex Consumption Model

Azure Functions is Microsoft's event-driven serverless compute platform, and hosting plan selection is the first decision any new deployment faces. Microsoft now recommends the Flex Consumption plan for new Azure Functions applications; the original Consumption plan is designated a legacy option and should not be treated as the current default for new workloads.

The Flex Consumption plan addresses the primary limitation of the legacy Consumption plan: cold start unpredictability. Under Flex Consumption, instance memory sizes are configurable at 512 MB, 2,048 MB, and 4,096 MB, and the plan scales out to up to 1,000 instances. Pre-provisioned instances can be reserved to eliminate cold start latency for latency-sensitive functions, giving teams a cost lever between always-on dedicated compute and pure serverless cold starts (Azure Functions hosting plans documentation).

Key Azure Functions characteristics for architecture decisions:

• Flex Consumption plan recommended for new deployments; original Consumption plan is a legacy option
• Configurable instance memory tiers under Flex Consumption: 512 MB, 2,048 MB, or 4,096 MB per instance
• Scale-out ceiling of up to 1,000 instances on the Flex Consumption plan
• Pre-provisioned instances available within Flex Consumption to reduce cold start latency
• Durable Functions extension for stateful orchestration, fan-out/fan-in, and long-running workflow patterns
• Native integration with Azure Event Grid, Service Bus, Cosmos DB, Blob Storage, and Azure DevOps pipelines

Azure Functions is the strongest option for teams operating in a Microsoft-stack environment. The Durable Functions extension handles stateful orchestration workflows that pure FaaS patterns cannot address without external state stores, which makes it the practical answer for multi-step business process automation on Azure.

Side-by-Side Comparison: Triggers, Scaling, and Pricing Model

The table below compares AWS Lambda, Google Cloud Functions, and Azure Functions across the six dimensions that most directly affect architecture and cost decisions. Billing granularity figures reflect primary-source documentation for Lambda (1 ms) and Cloud Functions (100 ms). Per-invocation dollar prices are not included, as those vary by memory tier, region, and free-tier status; consult current vendor pricing pages for accurate figures.

The billing granularity difference between Lambda (1 ms) and Cloud Functions (100 ms) matters most for functions with very short execution times, where the rounding increment directly affects cost per million invocations. For functions that run for several hundred milliseconds or more, the granularity gap narrows and other factors, including trigger breadth and ecosystem fit, carry more weight.

When to Choose Each Platform

AWS Lambda suits teams already operating within the AWS ecosystem where the trigger source is a managed AWS service. If the architecture includes API Gateway for HTTP routing, SQS for queue-driven processing, DynamoDB Streams for change data capture, or EventBridge for scheduled and cross-service events, Lambda slots in without adding cross-cloud network paths. The Lambda extensions ecosystem is an additional argument for teams that need observability or secrets injection at the execution environment level without modifying function code. For DNS and CDN routing configuration that often accompanies Lambda-fronted APIs, the DNS and CDN routing configuration comparison covers the relevant options.

Google Cloud Functions, deployed as Cloud Run functions on the v2 runtime, suits GCP-native workloads where simplicity and billing transparency are priorities. The pay-per-100ms model is easy to reason about for teams building lightweight HTTP microservices or Pub/Sub consumers. Teams that need to react to Cloud Storage object writes, Firebase events, or Eventarc triggers from GCP services will find the event-driven architecture integration direct and well-documented.

Azure Functions fits Microsoft-stack teams most cleanly. Durable Functions provides stateful orchestration, fan-out/fan-in, and human-in-the-loop approval workflows that most FaaS platforms require external services to replicate. If the CI/CD pipeline runs on Azure DevOps, the application stores data in Cosmos DB or Azure SQL, and the team writes primarily in C# or .NET, the native runtime support and tight service-bus integration make Azure Functions the lowest-friction path. The Flex Consumption plan's configurable memory tiers also give teams more control over the cost and performance tradeoff than a single-memory-tier on-demand plan offers.

How to Choose: A Decision Checklist

Use these questions to narrow the selection before committing to an execution environment. Each answer maps directly to a platform advantage or exclusion.

1. Which cloud provider hosts the rest of your stack? Serverless computing performs best when the function runtime and its trigger sources share a cloud network boundary. Cross-cloud trigger paths add latency and egress cost.
2. What trigger types does the workload require? Queue, schedule, HTTP, and cloud-native event sources differ by platform. Verify your required trigger is natively supported before selecting a platform.
3. Does the workload require stateful orchestration? If yes, Azure Functions with Durable Functions is the only native FaaS answer in this comparison. Lambda and Cloud Functions both require external state stores for multi-step coordination.
4. How sensitive is the workload to cold start latency? All three platforms offer mitigation, but at different price points and configuration models. Pre-warmed capacity is never free; weigh the cost against the latency requirement.
5. What runtime language does the team use? Each platform has first-class support for different language runtimes. Lambda's container image support broadens language flexibility but adds deployment complexity. Check current runtime lifecycle status before selecting a version.
6. Does the workload need per-function observability tooling without code changes? Lambda extensions support this natively. GCP and Azure have equivalent capabilities through their monitoring agents but with different integration models.
7. What is the expected execution duration and frequency? Function as a service platforms optimize for short, infrequent bursts. Workloads with consistent high throughput may find always-on container or VM-based compute more cost-effective than per-invocation serverless computing.

References

• AWS Lambda Extensions documentation (docs.aws.amazon.com)
• AWS Lambda configurable ephemeral storage announcement (aws.amazon.com)
• Azure Functions hosting plans and scale (learn.microsoft.com)
• Google Cloud Functions overview (cloud.google.com)
• Cloud Run functions runtime support (cloud.google.com)

Frequently Asked Questions