Pick the wrong serverless platform in September 2026 and you will not find out for months, right around the moment your invoice or your p99 latency graph forces the conversation. AWS Lambda, Azure Functions, and Google Cloud Run functions (the current name for what used to be Cloud Functions) all promise the same pitch: write a handler, skip the server, pay for what runs. The pricing units, cold-start behavior, memory ceilings, and networking models underneath that pitch differ enough to swing a mid-size workload’s monthly bill by hundreds of dollars and its latency profile by full seconds.

This comparison pulls current 2026 pricing straight from each vendor’s published rate card, cross-references cold-start numbers from three independent benchmark sources, and walks through a real migration path between the three. No vendor blog post is going to tell you Lambda’s Graviton discount beats Cloud Run functions on compute cost while Cloud Run functions still wins on free-tier request volume. We will.

Serverless functions remain one of the few compute categories where the three big clouds still compete on raw specs instead of just brand loyalty. A team choosing between them in 2026 is not just picking a runtime, they are picking a pricing model, a concurrency ceiling, and a debugging workflow that will shape how the engineering org builds for years. Get the choice wrong and the fix usually isn’t a config change, it’s a rewrite of trigger wiring, IAM policy, and deployment tooling months into a project.

We built this comparison specifically to cut through the naming confusion Google introduced when it rebranded Cloud Functions, to reconcile conflicting cold-start numbers floating around different benchmark blogs, and to give engineering leads a spec sheet and pricing table they can actually hand to a finance team. Every figure below traces back to either a vendor’s own pricing or quota documentation, or a named third-party benchmark, so you can go verify any of it yourself before committing budget. For the broader cloud computing context this comparison sits inside, AWS has been losing overall market share while Google Cloud gained ground, a shift documented in recent cloud market-share reporting that has knock-on effects for which platform gets the most aggressive new feature investment.

What AWS Lambda, Azure Functions, and Cloud Run Functions Actually Are

All three products fall under the function-as-a-service (FaaS) umbrella: you upload code, define a trigger, and the platform handles provisioning, scaling, and teardown. The naming gets messy fast, which trips up a lot of comparison shopping. Google folded its original Cloud Functions product into Cloud Run functions, so anything built on the newer 2nd-generation runtime now runs on Cloud Run’s underlying infrastructure even though the developer-facing experience still looks like a simple function trigger. If you see “Cloud Functions” in a 2024 tutorial, assume the current equivalent is Cloud Run functions.

AWS Lambda

Lambda launched in 2014 and remains the reference point every competitor gets measured against. It runs on AWS’s Firecracker microVM tech, supports zip and container-image deployment, and ties natively into the rest of the AWS event ecosystem: S3, DynamoDB Streams, SQS, EventBridge, and API Gateway. Lambda’s Graviton (ARM) option is the platform’s biggest lever for cutting compute cost on CPU-bound workloads.

Azure Functions

Azure Functions ships across four hosting plans (Consumption, Premium, Dedicated/App Service, and the newer Flex Consumption), which is the single biggest structural difference from Lambda and Cloud Run functions. Each plan changes the memory ceiling, cold-start behavior, and VNet access you get, so “Azure Functions pricing” is really four separate answers depending on which plan a team picks.

Google Cloud Run Functions

Cloud Run functions (2nd gen) inherits Cloud Run’s container-native scaling model, which is why its memory ceiling (32 GiB) and execution timeout (up to 60 minutes for HTTP triggers) dwarf both competitors. Google bills compute in split vCPU-seconds and GiB-seconds rather than Lambda and Azure’s bundled GB-second unit, which matters when you’re estimating cost for CPU-heavy versus memory-heavy jobs.

The rebrand is more than cosmetic. Under the old Cloud Functions 1st-gen model, functions ran on a lighter, more constrained execution environment capped at 8 GiB of memory. Moving to 2nd-gen changed the underlying scheduler to Cloud Run’s, which is why the memory ceiling nearly quadrupled and the timeout jumped from 9 minutes to a full hour for HTTP triggers. Teams still running 1st-gen functions are leaving real capability on the table and should plan a migration to 2nd-gen regardless of whether they ever consider leaving Google Cloud.

Specs at a Glance: 2026 Comparison Table

Here is the full spec sheet pulled from each vendor’s own documentation, including AWS Lambda’s quota documentation and Google’s Cloud Run functions quota page, as of late September 2026, cross-checked against third-party benchmarking sites where AWS or Microsoft did not publish a direct figure.

SpecAWS LambdaAzure FunctionsCloud Run Functions
Max execution timeout900 seconds (15 min)10 min default on Consumption; longer on Premium/Dedicated60 min (HTTP), 30 min (scheduled/queue), 9 min (event-driven)
Max memory10,240 MB~1.5 GB on Consumption, up to ~3.5 GB on Premium32 GiB (2nd gen)
Free tier1M requests + 400,000 GB-s/month1M executions + 400,000 GB-s/month2M requests + 180,000 vCPU-s + 360,000 GiB-s/month
Request price after free tier$0.20 per 1M requests~$0.20 per 1M executions$0.40 per 1M requests
Compute unitGB-second (x86 or Arm)GB-secondvCPU-second + GiB-second (split)
Arm/Graviton discountYes, roughly 20% cheaper per GB-secondNo equivalent published discountNo equivalent published discount
Deployment formatZip archive or container imageZip, container (Premium/Flex), or code-onlySource (buildpacks) or container image
Default concurrency per instance1 request per execution environmentPlan and trigger dependentUp to 80 requests per instance by default, configurable to 1,000
Regional concurrency quota1,000 by default, raisable via support ticketNo single universal cap; plan and subscription dependentRegional quota, configurable instance max
Provisioned/pre-warmed instancesProvisioned Concurrency, billed separately at ~$0.0000042/GB-sPremium plan’s “always ready” instancesMinimum instances setting on the underlying Cloud Run service
VPC/private networkingNative ENI-based VPC attachment, needs NAT gateway for egressVNet integration + Private Link, stronger on Premium/DedicatedServerless VPC Access or Direct VPC egress
Native language runtimesNode.js, Python, Java, C#/.NET, Go, Ruby + custom runtimesC#/.NET, Java, Node.js, Python, PowerShell + custom handlersNode.js, Python, Go, Java, .NET, Ruby, PHP

Two things jump out immediately. Cloud Run functions’ 32 GiB ceiling and 60-minute timeout put it in a different weight class for long-running or memory-hungry jobs, the kind of workload that would need Step Functions orchestration or a switch to a full container service like Fargate on AWS. Azure’s plan-fragmented memory and timeout limits mean the “Azure Functions” answer to a spec question is really “it depends which of four plans you picked.”

Pricing Breakdown: Who’s Actually Cheapest

Vendor pricing pages update fast enough that a six-month-old comparison article is often wrong by the time it ranks. Here is the current rate card, verified against AWS Lambda’s own pricing page, Google’s Cloud Run functions pricing overview, and Azure’s Functions pricing page in August and September 2026.

PlatformRequest pricingCompute pricingFree allowance
AWS Lambda (x86)$0.20 / 1M requests$0.0000166667 / GB-second1M requests + 400,000 GB-s
AWS Lambda (Arm/Graviton)$0.20 / 1M requests$0.0000133334 / GB-second1M requests + 400,000 GB-s
Azure Functions (Consumption)~$0.20 / 1M executions~$0.000016 / GB-second1M executions + 400,000 GB-s
Cloud Run functions$0.40 / 1M requests$0.000024 / vCPU-s + $0.0000025 / GiB-s2M requests + 180,000 vCPU-s + 360,000 GiB-s

Modeled against a workload of 9 million requests and 600,000 GB-seconds a month, a comparison run by Tech Insider in August 2026 put Lambda on x86 at roughly $4.93 a month and Lambda on Arm at roughly $4.27, a gap driven entirely by the Graviton compute discount. Neither Azure nor Google publish an equivalent discount for ARM-based execution, so workloads that are heavily CPU-bound and can tolerate an Arm/Graviton runtime will generally land cheapest on Lambda once you clear the free tier.

Cloud Run functions’ free tier is roughly double Lambda and Azure’s request allowance (2 million versus 1 million), which matters for low-traffic services, internal tools, or side projects that rarely leave the free tier at all. Once volume climbs into paid territory, the $0.40 per million request rate (double Lambda and Azure’s $0.20) starts eating into that free-tier advantage, especially for request-heavy, compute-light functions like webhook relays.

Cost tracking firm CloudZero flagged a related trap in its Cloud Run functions cost guide: billing splits CPU and memory into separate line items instead of Lambda’s single bundled GB-second, so a function allocated more memory than it needs quietly burns budget on the GiB-second charge even if CPU usage stays flat. Teams coming from Lambda’s mental model of “just size memory and go” need to actively separate CPU and memory tuning on Cloud Run functions instead of treating them as one dial.

Run the same math on a smaller workload and the free tiers start to matter more than the per-unit rates. A side project or internal tool doing 500,000 requests a month with modest 128 MB functions will likely stay entirely inside the free allowance on all three platforms, making the bill effectively $0 regardless of which one you pick. The pricing gap only opens up once a workload clears roughly 1 to 2 million requests a month, which is the point where Cloud Run functions’ higher per-request rate and Lambda’s Graviton discount actually start showing up as separate line items on an invoice instead of rounding to zero.

One more line item that rarely makes it into vendor pricing calculators: egress. All three clouds charge separately for data leaving the region, and a function that reads from object storage in one region and serves users in another can rack up bandwidth charges that dwarf the compute cost itself. None of the three platforms discount egress for serverless functions specifically, so this cost behaves identically regardless of which FaaS provider you pick, and it belongs in any total cost of ownership estimate built from the tables above. It’s the same category of hidden spend that shows up in broader cloud waste reporting, where forgotten NAT gateways and cross-region transfers routinely outweigh the compute line item teams actually budget for.

Cold Start Benchmarks From Three Independent Sources

Cold-start numbers are the most-cited and least-comparable figures in this entire market, because every benchmark uses a different runtime, package size, memory setting, and trigger type. Rather than pick one number and call it fact, here is what three separate 2026 studies actually measured, side by side.

SourceAWS LambdaAzure FunctionsCloud Run functions
IJMSRT academic benchmark, Jan. 2026190 ms average350 ms average270 ms average
LoadFocus performance testing analysis, May 2026200–1,500 ms500–2,000 ms400–1,200 ms
NCI dissertation, ML inference workload, Sept. 20263,120 ms unoptimized / 267 ms optimized2,690 ms unoptimized / 298 ms optimized2,740 ms unoptimized / 302 ms optimized

Read these as directional, not interchangeable. The IJMSRT study and LoadFocus’s serverless performance testing analysis both ran lightweight function workloads, while the NCI dissertation tested a heavy machine-learning inference payload, which explains why its raw cold-start numbers run 10x to 15x higher than the other two studies before optimization. What holds across all three: Lambda comes out fastest or tied-fastest on light workloads, and the gap between platforms compresses sharply once you apply platform-specific optimization (Lambda’s SnapStart for Java, provisioned concurrency, or minimum-instance settings on the other two).

The practical takeaway matches what teams running AWS’s own cold-start-focused tooling have found: cold starts are a solvable problem on any of the three platforms, but only if you actively pay for pre-warmed capacity or pick a lighter runtime. Left on default settings, all three can hit multi-second cold starts under heavier payloads, and none of them advertise that clearly on their pricing pages.

Execution Limits and Memory Ceilings

Lambda caps every function at 15 minutes and 10,240 MB, full stop, according to AWS’s own quota documentation. That ceiling has not moved in years and forces teams running longer batch jobs onto Step Functions orchestration or a different compute model entirely.

Azure Functions splits this by hosting plan. The Consumption plan defaults to a 5-minute timeout with a configurable maximum of 10 minutes, while Premium and Dedicated (App Service) plans support materially longer executions since they run on allocated instances rather than fully ephemeral ones. Memory follows the same pattern: roughly 1.5 GB on Consumption, up to around 3.5 GB on Premium, according to third-party benchmarking from DevOpsBoys’ 2026 platform comparison and Tech Insider, since Microsoft’s own docs don’t publish one universal number across every plan.

Cloud Run functions is the outlier by a wide margin. Google’s own quota page lists 60 minutes for HTTP-triggered functions, 30 minutes for scheduled and Task Queue functions, and 9 minutes for event-driven functions, with memory scaling up to 32 GiB on 2nd-generation functions (versus 8 GiB on the older 1st-gen model). That combination effectively lets teams run genuine batch and ETL workloads on Cloud Run functions without switching to a separate compute product, something neither Lambda nor Azure Functions can match without moving to containers or VMs.

Worth flagging for capacity planning: none of these limits are static once a team hits them in production. AWS periodically raises Lambda’s default account-level quotas as usage history builds, Azure’s Premium and Dedicated plans scale memory and duration with the underlying instance size a team selects, and Google’s quota page explicitly notes that some 2nd-gen limits can be raised through a support request. Treat every number in this section as a starting point for a new account, not a hard ceiling that stays fixed forever.

Concurrency and Auto-Scaling Behavior

Lambda’s scaling model is the strictest of the three: each execution environment handles exactly one invocation at a time, and AWS scales horizontally by spinning up new environments. The default regional concurrency quota sits at 1,000 concurrent executions, adjustable on request, with Reserved and Provisioned Concurrency available to carve out guaranteed capacity for latency-sensitive functions.

Cloud Run functions inherits Cloud Run’s container concurrency model, defaulting to 80 requests per instance and configurable up to 1,000 for services that can safely share an instance across requests. That single-instance concurrency is a structural advantage for I/O-bound workloads, since one warm instance can serve dozens of simultaneous requests instead of spinning up a new environment per request the way Lambda does.

According to Microsoft’s own Functions scaling documentation, Azure Functions ties concurrency to both the hosting plan and the trigger type, with the newer Flex Consumption plan introducing configurable HTTP concurrency that behaves closer to Cloud Run functions’ model than classic Consumption’s per-instance scaling. Because scaling limits also depend on subscription-level quotas and per-function scale behavior, Azure does not publish one clean number the way AWS does with its 1,000-concurrency default, which makes capacity planning genuinely harder to reason about upfront.

Language and Runtime Support

All three platforms cover the mainstream languages: Node.js, Python, Java, and a .NET/C# variant ship as first-class managed runtimes everywhere. The differences show up at the edges.

  • AWS Lambda adds native Go and Ruby runtimes, plus custom runtimes and full container-image deployment, which opens the door to Rust, PHP, or any language you can package yourself.
  • Azure Functions adds PowerShell as a first-class runtime, a natural fit for teams already scripting Azure infrastructure, and supports custom handlers for HTTP-based languages like Go or Rust.
  • Cloud Run functions adds PHP and Ruby as managed runtimes and, because 2nd-gen functions run on Cloud Run’s container infrastructure, supports buildpacks and full container deployment for essentially any language.

For teams standardized on Go or Ruby, Lambda and Cloud Run functions both have you covered natively, while Azure requires the custom handler workaround. For teams already deep in PowerShell-based automation, Azure Functions is the only one of the three with native support.

VPC and Private Networking

Lambda’s VPC integration is the most mature of the three, having existed since the platform’s early years. Functions attach to private subnets and security groups directly, though outbound internet access from inside a VPC still requires a NAT gateway, an extra cost and configuration step teams frequently forget until their function can’t reach an external API.

Azure Functions supports VNet integration for outbound traffic and Private Link plus private endpoints for inbound and private service access, but the completeness of that networking stack depends heavily on hosting plan. Premium, Dedicated, and Flex Consumption plans get materially more private-networking control than the base Consumption plan, another instance of Azure’s plan fragmentation showing up in a core feature.

Cloud Run functions uses Serverless VPC Access or the newer Direct VPC egress model, and Google’s own migration documentation draws a specific distinction between full VPC access and more granular VPC egress controls, giving teams finer-grained control over exactly which traffic leaves the VPC versus routes over the public internet.

Ecosystem, Monitoring, and Developer Tooling

Specs and pricing get the headlines, but day-to-day developer experience often decides which platform a team actually enjoys working in. AWS pairs Lambda with CloudWatch for logs and metrics, X-Ray for distributed tracing, and either SAM or CDK for infrastructure-as-code deployment. The SAM CLI’s local invoke and debug tooling is mature enough that most Lambda teams can iterate without touching the console at all.

Azure Functions ties into Application Insights for tracing and Azure Monitor for metrics and alerting, with the Azure Functions Core Tools CLI handling local development. Teams already using Bicep or ARM templates for the rest of their Azure footprint get a consistent deployment story across Functions and everything else in the subscription, which is a real advantage for platform teams standardizing tooling across dozens of services.

Cloud Run functions logs to Cloud Logging and traces through Cloud Trace by default, and because 2nd-gen functions are Cloud Run services under the hood, teams get access to the same revision-based rollout and traffic-splitting controls Cloud Run offers full containers, a feature neither Lambda nor Azure Functions expose as directly for gradual canary rollouts of a single function.

Vendor Lock-In and Portability

Every FaaS platform ties your trigger model to its own event format, and that coupling is usually the real cost of switching clouds later, not the compute code itself. Lambda’s event payloads for S3, SQS, and API Gateway are AWS-specific JSON shapes with no cross-cloud standard behind them. Azure Functions bindings work the same way, tightly coupled to Azure Storage, Service Bus, and Event Grid formats.

Cloud Run functions has a slight structural edge here because it sits on Knative, an open-source project the wider Kubernetes ecosystem also builds on, and Google has pushed CloudEvents as a more standardized event envelope across some of its triggers. That does not make Cloud Run functions fully portable, but it does mean the underlying container and HTTP-trigger model transfers more cleanly to a self-managed Knative cluster if a team ever needs to exit managed Cloud Run entirely.

The practical lock-in mitigation most teams land on is the same regardless of platform: keep business logic in plain functions or classes that accept simple arguments, and isolate the platform-specific trigger-handling code in a thin adapter layer. That pattern alone is why the migration guide later in this article can port the actual handler logic in under an hour, while the surrounding IAM, secrets, and trigger wiring take days.

Real-World Use Cases Across All Three Platforms

These six patterns show up constantly in production serverless architectures, and each one stresses a different part of the spec sheet above.

  • Image and video processing pipelines. An object-storage upload (S3, Blob Storage, or Cloud Storage) triggers a function that generates thumbnails or transcodes media. This is memory- and CPU-heavy, which pushes teams toward Cloud Run functions’ higher memory ceiling or Lambda’s Graviton pricing for cost control. Teams processing large source files (raw video, high-resolution RAW photos) often hit Lambda’s 10 GB memory ceiling before they hit its time limit, making Cloud Run functions the more forgiving default for this workload.
  • Webhook receivers for SaaS integrations. Stripe, GitHub, and Slack all fire webhooks that need a fast, cheap, always-on HTTP endpoint. Request volume matters more than compute here, which is where Cloud Run functions’ larger free tier or Lambda’s flat $0.20/million rate both compete well. Because webhook payloads are small and processing is usually just a database write or a queue publish, cold-start latency matters more than raw memory for this category.
  • Scheduled ETL and batch jobs. Nightly data warehouse loads or report generation routinely exceed Lambda’s 15-minute ceiling, making Cloud Run functions’ 30-to-60-minute window (or Azure Premium’s longer-running instances) the more natural fit. Teams that outgrow even Cloud Run functions’ hour-long cap typically graduate to a dedicated orchestration tool like Step Functions or Cloud Composer rather than fighting the FaaS timeout further.
  • API backends for mobile and web apps. HTTP-triggered functions behind API Gateway, Azure API Management, or a Cloud Run functions HTTP trigger are the most common FaaS use case of all three platforms, and this is where cold-start latency directly affects user-perceived app performance. A mobile app pulling a product catalog on cold start is exactly the scenario where the benchmark differences in the cold-start table above translate into a user actually noticing a delay.
  • IoT telemetry ingestion. High-frequency, small-payload events from connected devices need cheap per-invocation pricing and fast scale-out, favoring whichever platform’s free tier and per-request pricing best match the device fleet’s traffic pattern. A fleet reporting once a minute from 10,000 devices generates roughly 14.4 million invocations a month, well past every platform’s free tier, so per-request pricing becomes the deciding factor at that scale.
  • AI agent and LLM-backed function calling. Functions that proxy requests to a language model API, enrich a prompt with retrieved context, or run a lightweight inference step benefit from whichever platform keeps execution time predictable, since model API latency already eats into any timeout budget. The longer timeout ceilings on Cloud Run functions give more headroom for multi-step agent chains that call out to an LLM more than once before returning, a pattern also showing up in managed offerings like Bedrock, Azure AI Foundry, and Vertex AI that now sit alongside these same three clouds’ FaaS products.

Migration Guide: Moving Between the Three Platforms

Migrating a function-based workload between clouds is rarely a line-for-line code port. The trigger model, environment variable handling, and IAM/service-account permissions all differ enough to require real rework. Here is the general sequence that holds regardless of which direction you’re migrating.

  1. Inventory every trigger type in use (HTTP, storage event, queue, schedule, stream) and map each one to its equivalent on the target platform.
  2. Separate business logic from the platform-specific handler wrapper so the core function can be tested independently of the trigger.
  3. Rebuild environment variable and secrets handling using the target platform’s native secrets manager rather than hardcoding values.
  4. Re-provision IAM roles or service accounts with least-privilege access matching the target platform’s permission model.
  5. If memory or timeout limits differ (especially moving from Lambda to Cloud Run functions, or vice versa), re-tune resource allocation rather than copying the old settings.
  6. Load test cold-start behavior on the target platform before cutover, since the numbers in the benchmark table above show real, workload-dependent variance.
  7. Cut over gradually using weighted traffic routing or a blue-green DNS switch rather than an all-at-once flip.

The handler signature itself is usually the easiest part to port. Here’s the same basic HTTP handler shape across all three platforms:

// AWS Lambda (Node.js)
exports.handler = async (event, context) => {
  return { statusCode: 200, body: "ok" };
};

// Azure Functions (Node.js, v4 programming model)
app.http('handler', {
  methods: ['GET'],
  handler: async (request, context) => {
    return { status: 200, body: "ok" };
  }
});

// Cloud Run functions (Node.js, functions-framework)
functions.http('handler', (req, res) => {
  res.status(200).send("ok");
});

The real migration cost lives outside this snippet, in trigger wiring, IAM, and observability tooling, which is usually 80% or more of the actual engineering time on a cross-cloud FaaS migration.

Pros and Cons of Each Platform

AWS Lambda

Pros: fastest cold starts in two of three benchmark sources, Graviton discount cuts compute cost meaningfully, deepest event-source ecosystem within AWS, most mature VPC integration, largest community and tooling base.
Cons: hard 15-minute/10,240 MB ceiling with no path around it short of switching compute products, one-request-per-environment concurrency model scales less efficiently for I/O-bound workloads than Cloud Run functions’ shared-instance model.

Azure Functions

Pros: tightest fit for teams already standardized on Azure/.NET/PowerShell, Flex Consumption narrows the concurrency and networking gap with the other two, four hosting plans give genuine flexibility for different workload shapes.
Cons: that same plan fragmentation makes specs (memory, timeout, concurrency) inconsistent and harder to reason about upfront, slowest or near-slowest cold starts across two of the three benchmark sources reviewed here.

Cloud Run Functions

Pros: largest memory ceiling (32 GiB) and longest timeout (60 minutes) by a wide margin, shared-instance concurrency model scales efficiently for request-heavy workloads, largest free-tier request allowance of the three.
Cons: highest per-request price after the free tier ($0.40/million versus $0.20/million for the other two), split CPU/memory billing requires more careful cost tuning than Lambda or Azure’s bundled model.

Which Platform Fits Your Use Case

  • Long-running batch or ETL jobs: Cloud Run functions, for the 60-minute HTTP timeout and 32 GiB memory ceiling neither competitor can match.
  • Cost-sensitive, CPU-bound workloads at scale: AWS Lambda with Graviton, for the roughly 20% per-GB-second discount over x86 pricing.
  • Teams already standardized on Azure or .NET: Azure Functions, for the native ecosystem fit even though its cold starts and spec consistency lag the other two.
  • Request-heavy, low-compute webhook and API workloads: Cloud Run functions’ shared-instance concurrency (up to 1,000 requests/instance) or Lambda’s flat request pricing, depending on whether the workload is I/O-bound or CPU-bound.
  • Latency-critical, low-traffic services: AWS Lambda, based on its lead in two of the three independent cold-start benchmarks reviewed above.

The Verdict

No single platform wins across every column of the spec sheet, and that is the honest takeaway after pulling apart the pricing pages, quota docs, and three separate benchmark studies. AWS Lambda still leads on raw cold-start speed in the majority of sources checked here and on compute cost once Graviton enters the picture. Cloud Run functions wins decisively on ceiling: memory, timeout, and free-tier request volume all favor it for workloads that don’t fit neatly inside Lambda’s 15-minute box. Azure Functions earns its place through ecosystem gravity rather than raw specs, the right call for teams already committed to Azure infrastructure, PowerShell tooling, or .NET-first engineering teams, even though its plan-fragmented limits make it the hardest of the three to reason about from a cold read of the docs.

If you’re picking without any existing cloud commitment and your workload is a typical HTTP API or event handler under a few hundred milliseconds of work, start with Lambda. If your jobs regularly run past 15 minutes or need more than 10 GB of memory, Cloud Run functions removes that ceiling entirely. Azure Functions makes the most sense as a default when your organization’s data, identity, and DevOps tooling already live in Azure, since the integration savings there usually outweigh a few hundred milliseconds of extra cold-start latency.

The broader pattern worth remembering is that none of these three platforms has stood still, and none of them will over the next year. Google’s rebrand of Cloud Functions into Cloud Run functions already reshuffled the spec sheet once in 2026, Azure keeps adding hosting plans to catch up on cold starts and concurrency, and AWS keeps expanding Graviton’s price advantage as it pushes more of its own infrastructure onto ARM. Treat this comparison as a snapshot, re-check the vendor pricing pages before a large commitment, and weight ecosystem fit and existing team expertise at least as heavily as the millisecond-level cold-start differences, since those differences shrink fast once a function is warm and serving real traffic.

Frequently Asked Questions

Is Google Cloud Functions the same as Cloud Run functions?

Yes, as of 2026 Google’s current documentation presents “Cloud Run functions” as the product name for what was previously branded Cloud Functions, running on Cloud Run’s underlying 2nd-generation infrastructure. Older tutorials referencing “Cloud Functions” are describing the same product family.

Which platform has the fastest cold starts in 2026?

Across the three independent benchmark sources reviewed in this article, AWS Lambda posted the fastest or tied-fastest cold-start times in two of three studies on lightweight workloads. Results vary significantly by runtime, memory allocation, and whether provisioned or minimum-instance capacity is enabled, so teams with latency-sensitive functions should benchmark their own specific payload rather than rely on any single published figure.

Can I run a function for longer than 15 minutes?

Not on AWS Lambda, which hard-caps every function at 900 seconds regardless of plan or configuration. Cloud Run functions supports up to 60 minutes for HTTP-triggered functions, and Azure Functions can exceed 10 minutes on Premium or Dedicated hosting plans, though the base Consumption plan caps out at 10 minutes.

Which platform is cheapest for a typical workload?

It depends on the shape of the workload. Lambda on Graviton generally wins on pure compute cost for CPU-bound functions. Cloud Run functions’ larger free tier can make it cheapest for low-traffic services that stay within the 2-million-request monthly allowance. Azure Functions’ pricing sits close to Lambda’s on paper but varies more in practice depending on hosting plan.

Do all three platforms support container image deployment?

AWS Lambda and Cloud Run functions both support full container-image deployment natively. Azure Functions supports containers on its Premium and Flex Consumption plans, though the base Consumption plan is more limited in this regard.

How does VPC access affect performance?

Attaching any of the three platforms to a private VPC or VNet historically added cold-start overhead, and while all three vendors have optimized this over time, private networking still typically adds latency compared to a function running with public internet access only. Lambda’s ENI-based model, Azure’s VNet integration, and Cloud Run functions’ Direct VPC egress each handle this differently, so teams with strict latency budgets should benchmark VPC-attached functions specifically rather than assume parity with public-facing ones.

What’s the easiest platform to migrate to from Lambda?

Cloud Run functions tends to be the more straightforward technical migration from Lambda because both support container-image deployment and similar event-driven trigger models. Azure Functions requires more rework around IAM, environment configuration, and hosting-plan selection, since its permission and scaling models differ more structurally from Lambda’s.

Should I use Kubernetes instead of any of these three?

Only if your workload runs continuously enough that per-invocation billing stops making financial sense, or if you need control the FaaS model doesn’t expose, like custom networking, long-lived connections, or specialized scheduling. For workloads with genuine idle time between invocations, all three FaaS platforms covered here will generally be cheaper and simpler to operate than running an always-on cluster, though it’s worth comparing the operational overhead against options like Kubernetes versus simpler container orchestrators before committing to either extreme.