Skip to content
Back to Cloud Services

Cloud Run vs Lambda

Comparison of GCP Cloud Run (container, request-based scaling, concurrency) vs AWS Lambda (function, event-driven, no concurrency).

Cloud ComparisonIntermediate

Why

Cloud Run runs any container and scales based on concurrent requests (up to 1000 per instance), so one instance handles many requests — lower cost and fewer cold starts. Lambda runs one function per request (no in-instance concurrency, except Lambda Provisioned), with a 15-min timeout.

Cloud Run is better for web services; Lambda for event-driven pipelines.

When

Use Cloud Run for web APIs, web apps, and long-running services (up to 60 min timeout) packaged as containers. Use Lambda for event-driven (S3, DynamoDB streams, EventBridge), short tasks (<15 min), or when you want per-function billing.

Cloud Run is the better default for 'serve HTTP'; Lambda for 'react to events'.

How

1. Containerize your app (Dockerfile). 2. Cloud Run: gcloud run deploy with the image; Lambda: zip the code and update-function-code. 3. Cloud Run: set --concurrency (default 80, max 1000) and --max-instances. 4. Lambda: set memory (which scales CPU) and timeout. 5. Both: set min-instances/min-instances to avoid cold start (Cloud Run) or provisioned concurrency (Lambda). ```bash # Cloud Run gcloud run deploy svc --source . --region us-central1 --allow-unauthenticated --concurrency 80 --max-instances 10 # Lambda aws lambda create-function --function-name fn --runtime nodejs18.x --handler index.handler --zip-file fileb://fn.zip --memory-size 512 --timeout 30 ```

Example

Cost for 1M requests, 100ms each, 512MB (approximate): ```text Cloud Run: 1M req / 80 concurrency = 12,500 instance-seconds * $0.00002400 = $0.30 + negligible CPU Lambda: 1M req * 100ms * 512MB = 50,000 GB-s * $0.0000166667 = $0.83 ``` Cloud Run is cheaper due to concurrency (one instance serves 80 req in parallel). Lambda is cheaper for very sparse traffic (scales to zero with no min). ```bash # Cloud Run with min instances to avoid cold start gcloud run deploy svc --image gcr.io/proj/svc --min-instances 1 --concurrency 80 # Lambda with provisioned concurrency aws lambda put-provisioned-concurrency --function-name fn --provisioned-concurrent-executions 5 ```

Common Problems

  • ⚠Cloud Run cold start on min-instances=0 — set --min-instances 1 (small cost) to keep one warm, or accept ~1-2s cold for sparse traffic.
  • ⚠Lambda 15-min timeout — for longer jobs use Step Functions, Fargate, or Cloud Run (60 min, or 24h with --task-timeout on jobs).
  • ⚠Cloud Run concurrency too high for your app — if the app is not thread-safe, set --concurrency 1; default 80 assumes the container handles parallel requests.

Best Practices

  • ✓Default to Cloud Run for HTTP services (concurrency cuts cost and cold starts) and Lambda for event-driven (S3/DynamoDB streams) where per-event billing fits.
  • ✓Set Cloud Run --concurrency to what your app actually handles (test with load) — too high causes 5xx under load; too low wastes instances.
  • ✓Use Cloud Run min-instances=1 for latency-critical APIs (small always-on cost) and 0 for dev/spike traffic; use Lambda Provisioned Concurrency similarly.

FAQ

What is Cloud Run vs Lambda and what problem does it solve?

Comparison of GCP Cloud Run (container, request-based scaling, concurrency) vs AWS Lambda (function, event-driven, no concurrency). It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.

How do I get started with Cloud Run vs Lambda in 5 minutes?

Two steps to run it: (1) Containerize your app (Dockerfile).; (2) Cloud Run: gcloud run deploy with the image; Lambda: zip the code and update-function-code.. Validate on the free tier first, then wire into production.

What is the #1 pitfall with Cloud Run vs Lambda?

The most frequent issue is: Cloud Run cold start on min-instances=0 — set --min-instances 1 (small cost) to keep one warm, or accept ~1-2s cold for sparse traffic.. Run a pre-launch checklist item by item, and add policy/config scanning in CI.

What are the best practices for Cloud Run vs Lambda?

Best practices for Cloud Run vs Lambda include: Default to Cloud Run for HTTP services (concurrency cuts cost and cold starts) and Lambda for event-driven (S3/DynamoDB streams) where per-event billing fits.; Set Cloud Run --concurrency to what your app actually handles (test with load) — too high causes 5xx under load; too low wastes instances.; Use Cloud Run min-instances=1 for latency-critical APIs (small always-on cost) and 0 for dev/spike traffic; use Lambda Provisioned Concurrency similarly.. The first one — "Default to Cloud Run for HTTP services (concurrency cuts cost and cold starts) and Lambda for event-driven (S3/DynamoDB streams) where per-event billing fits." — should be a team default baked into your IaC templates.

How do I control cost and avoid bill surprises with Cloud Run vs Lambda?

Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most Cloud Run vs Lambda options offer a free tier — validate within free quota before scaling.