AWS Lambda vs Google Cloud Functions vs Azure Functions: Real Performance Comparison

In recent years cloud computing has increasingly decoupled server‑side infrastructure and application logic, and Function‑as‑a‑Service (FAAS) pushes this trend to its extreme.

Originally a design pattern for low‑utilization tasks, FAAS has become a widely applicable programming model, prompting users to question its resource utilization, isolation quality, and DDoS resistance.

Researchers from the University of Wisconsin‑Madison, Ohio State University, and Cornell University employed techniques including reverse engineering to evaluate AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions across metrics such as cold‑start latency, resource allocation, isolation, instance reuse, and billing accuracy.

Key findings include:

AWS scales concurrency by launching a separate function instance for each call (tested up to 200 concurrent invocations). Azure’s concurrency support is limited to about 10 instances per function, despite documentation claiming up to 200, and Google often initializes only half of the requested instances, queuing the rest.

Cold‑start time is strongly language‑dependent: Python starts fastest, Java slowest.

Using Node.js 6 with 128 MB memory, median cold‑start times are ~265 ms for Lambda, ~493 ms for Google Cloud Functions, and ~3.64 s for Azure Functions. Over a 168‑hour run, AWS’s cold‑start duration remains the most stable.

AWS Lambda instances have a median lifetime of 6.2 hours, whereas 90 % of Google Cloud Function instances (128 MB) invoked every 5 seconds survive between 3 and 31 minutes.

Azure Functions run on VMs of varying specs, with 55 % of instance time on low‑performance VMs.

Google Cloud Functions exhibit a billing flaw allowing background processes to run indefinitely without being charged, a vulnerability not present in Lambda or Azure Functions.

For detailed methodology and additional data, refer to the original paper.