AWS Lambda vs Azure Functions vs GCP Cloud Run — Serverless Comparison

In this tutorial, you'll learn about AWS Lambda vs Azure Functions vs GCP Cloud Run. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

AWS Lambda vs Azure Functions vs GCP Cloud Run is the defining serverless decision in 2026 — three cloud platforms with different execution models, scaling behaviors, and ecosystem lock-in.

AWS Lambda pioneered function-as-a-service with event-driven execution, short timeouts, and a massive ecosystem of triggers. Azure Functions offers deep Microsoft ecosystem integration including Active Directory, SharePoint, and Dynamics. Cloud Run differentiates itself with container-based serverless — deploy any HTTP container and pay only for requests. This comparison helps you choose based on cold start performance, concurrency model, pricing, and language support.

What You'll Learn

Why It Matters

Serverless platforms abstract infrastructure but introduce trade-offs in cold start latency, concurrency limits, pricing complexity, and vendor lock-in. Choosing the wrong platform leads to unexpected bills, performance issues, or migration costs. Understanding each platform's architecture helps you match the right service to your workload pattern.

Who Should Use What

AWS Lambda suits teams already in the AWS ecosystem needing maximum event source integration. Azure Functions suits enterprise Microsoft shops requiring Active Directory, .NET, and Azure DevOps pipelines. GCP Cloud Run suits teams wanting container portability, longer request timeouts, and concurrent request handling per instance.

flowchart TD
    A[Choose Serverless Platform] --> B{Primary ecosystem?}
    B -->|AWS| C[AWS Lambda]
    B -->|Azure| D[Azure Functions]
    B -->|GCP| E[Cloud Run]
    B -->|Multi-cloud| F{Workload type?}
    F -->|Event-driven, short-lived| C
    F -->|Enterprise .NET / AD| D
    F -->|HTTP containers, long requests| E
    C --> G{Need >15 min timeout?}
    G -->|Yes| H["Use Lambda + ECS/Fargate"]
    G -->|No| I[Lambda is fine]
    E --> J{Need concurrent requests?}
    J -->|Yes| K[Cloud Run handles this natively]
    J -->|No| L[Cloud Run still fine]

Feature Comparison

Performance Comparison

Cold start latency varies dramatically between platforms. Cloud Run has the lowest cold starts (50-200ms) because it uses a container image that stays partially warm. AWS Lambda cold starts range from 200ms (Python/Node) to 1s+ (Java/.NET). Azure Functions Premium plan reduces cold starts to 100-400ms but costs more.

For concurrent request handling, Cloud Run excels — a single container instance can handle 250+ concurrent requests, reducing cost for workloads with idle wait time (database queries, external API calls). Lambda and Azure Functions scale to one instance per request, which increases concurrency costs for I/O-bound workloads.

Pricing: Cloud Run is typically cheapest for HTTP services with sustained traffic because of concurrent request pricing. Lambda is cheapest for event-driven, short- duration workloads. Azure Functions Enterprise Agreement discounts can make it competitive for .NET-heavy organizations.

Code Examples

Hello World HTTP Function

AWS Lambda (Python)

import json

def lambda_handler(event, context):
    name = event.get("queryStringParameters", {}).get("name", "World")
    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"message": f"Hello, {name}!"})
    }

Expected output: {"message": "Hello, World!"} when invoked via API Gateway with no query parameters.

Azure Functions (Python)

import azure.functions as func
import json

def main(req: func.HttpRequest) -> func.HttpResponse:
    name = req.params.get("name", "World")
    return func.HttpResponse(
        json.dumps({"message": f"Hello, {name}!"}),
        mimetype="application/json",
        status_code=200
    )

Expected output: Same JSON response, but requires the azure.functions binding library.

GCP Cloud Run (Python, FastAPI)

import os
from fastapi import FastAPI
from mangum import Mangum

app = FastAPI()

@app.get("/")
def read_root(name: str = "World"):
    return {"message": f"Hello, {name}!"}

handler = Mangum(app)

Expected output: Same JSON, but runs as a FastAPI application inside a Docker container on Cloud Run.

Processing a File Upload

AWS Lambda with S3

import boto3

s3 = boto3.client("s3")

def lambda_handler(event, context):
    bucket = event["Records"][0]["s3"]["bucket"]["name"]
    key = event["Records"][0]["s3"]["object"]["key"]

    response = s3.get_object(Bucket=bucket, Key=key)
    content = response["Body"].read().decode("utf-8")
    lines = content.splitlines()

    print(f"Processed {len(lines)} lines from {key}")
    return {"statusCode": 200, "lines": len(lines)}

Expected output: Logs line count of uploaded file; event originates from S3 bucket notification.

Azure Functions with Blob Storage

import azure.functions as func
import logging

def main(myblob: func.InputStream):
    content = myblob.read().decode("utf-8")
    lines = content.splitlines()
    logging.info(f"Processed {len(lines)} lines from {myblob.name}")

Expected output: Same behavior, triggered by Azure Blob Storage binding.

Cloud Run with Cloud Storage (via Pub/Sub)

import base64, json
from flask import Flask, request

app = Flask(__name__)

@app.route("/", methods=["POST"])
def handle_event():
    envelope = request.get_json()
    data = base64.b64decode(envelope["message"]["data"]).decode("utf-8")
    event = json.loads(data)
    print(f"File {event['name']} uploaded to {event['bucket']}")
    return ("", 204)

Expected output: HTTP 204, logs the file event from Cloud Storage notification via Pub/Sub.

Stateful Workflow

AWS Lambda (Step Functions)

# First state in a Step Functions workflow
def lambda_handler(event, context):
    order_id = event["order_id"]
    return {
        "order_id": order_id,
        "status": "PROCESSING",
        "validation": validate_order(order_id)
    }

Expected output: Step Functions orchestrates this as the first step, passing output to subsequent states.

Azure Functions (Durable Functions)

import azure.durable_functions as df

def orchestrator_function(context: df.DurableOrchestrationContext):
    order_id = context.get_input()
    validation = yield context.call_activity("ValidateOrder", order_id)
    payment = yield context.call_activity("ProcessPayment", validation)
    return payment

main = df.Orchestrator.create(orchestrator_function)

Expected output: Durable Functions manages state, retries, and checkpoints automatically — a built-in advantage over Lambda requiring Step Functions.

When to Choose AWS Lambda

Choose AWS Lambda when you are already in the AWS ecosystem and need deep integration with S3, DynamoDB, SQS, SNS, Kinesis, or EventBridge. Lambda has the richest event source catalog, the largest community, and the most tooling (SAM, Serverless Framework, Terraform, Pulumi). Lambda is ideal for event-driven data processing pipelines, real-time file transformations, and API backends with low traffic variability.

When to Choose Azure Functions

Choose Azure Functions when your organization uses Microsoft 365, Active Directory, SharePoint, or Dynamics 365. Azure Functions integrates natively with Azure DevOps, provides managed identity for secure resource access, and offers Durable Functions for stateful workflows. The Premium plan reduces cold starts for latency-sensitive .NET applications. Azure Functions is the strongest choice for enterprise .NET shops.

When to Choose GCP Cloud Run

Choose Cloud Run when you want portability (standard containers), need longer request timeouts (up to 60 minutes), or have variable traffic patterns with concurrent requests. Cloud Run's container model means no cold starts for languages with slow startup (Java, .NET) because you can pre-warm containers. It's also the cheapest for HTTP services with sustained traffic because one container handles many concurrent requests. Cloud Run is ideal for Machine Learning inference endpoints, media processing, and anything that fits in a container.

Migration Guide

Migrating between serverless platforms requires rewriting function code (different SDKs, bindings, and event models) but the business logic stays the same. Use Hexagonal Architecture — keep business logic independent of cloud SDKs, with thin adapters for each platform. The Serverless Framework supports Lambda and Azure Functions, reducing deployment differences. For Cloud Run, packaging as a standard container means you can run the same image on Cloud Run, ECS, AKS, or any Kubernetes cluster.

Common Mistakes

1. Ignoring cold starts — Java and .NET Lambda functions can take 5-10 seconds to start without provisioned concurrency. Test latency-sensitive paths under cold start conditions before going to production.
2. Over-provisioning memory — Lambda charges for duration times memory. Find the memory sweet spot using AWS Lambda Power Tuning. More memory also allocates more CPU, sometimes making functions cheaper by finishing faster.
3. Concurrency confusion — Lambda and Azure Functions process one request per invocation. Cloud Run handles concurrent requests on one container. Design your code accordingly — Cloud Run handlers must be thread-safe.
4. Assuming infinite scale — All three platforms have account-level concurrency limits. Lambda defaults to 1,000 concurrent executions. Cloud Run defaults to 100 container instances. Request limit increases early.
5. Using VPC without planning — Lambda in a VPC can't access the internet without a NAT Gateway, adding cost and latency. Use VPC endpoints for AWS services or avoid VPC for functions that only need AWS service access.

FAQ

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.