Serverless Pricing Comparison: AWS Lambda vs Cloud Run vs Functions

Overview

A useful serverless pricing comparison starts with a practical point: these platforms do not bill the same unit of work in exactly the same way. Even when two products both feel like “run my code on demand,” the billing model can differ enough that small architectural choices change the result.

For example, one workload may be dominated by request count, while another is dominated by execution duration, allocated memory, CPU, idle capacity, or outbound traffic. A simple API that responds in tens of milliseconds behaves very differently from an image processing job, a webhook worker, or a containerized background service with occasional bursts.

That is why this article compares AWS Lambda vs Cloud Run pricing and functions-style offerings through a buyer-guide lens rather than a fixed price table. Cloud pricing changes. Free tiers change. Regional rates change. The durable skill is knowing how to model your own app.

Use this article if you are trying to answer questions like these:

• Which serverless app platform is more predictable for a new SaaS MVP?
• When does request-based billing stop being the main cost driver?
• How much does networking matter in a serverless pricing comparison?
• Should you use function-based deployment or container-based serverless execution?
• What should you put into a simple serverless cost calculator worksheet?

At a high level, the tradeoffs usually look like this:

• AWS Lambda often fits event-driven functions, lightweight APIs, scheduled jobs, and glue code between services.
• Cloud Run often fits HTTP services, containerized apps, APIs that benefit from more runtime control, and teams that want a smoother path from local containers to production.
• Cloud Functions-style products are often attractive for teams that want the simplest function deployment model and are comfortable with more platform opinionation.

The cheapest option depends less on branding and more on workload profile. If your team is still deciding whether serverless is the right architectural path at all, see When to Use Serverless for Web Apps and When to Avoid It and Monolith vs Microservices vs Serverless: Best Architecture for New Cloud Apps.

How to estimate

The fastest way to get a useful estimate is to stop thinking in provider marketing terms and break the workload into billable dimensions. A good serverless cost calculator guide should answer five questions.

1. How many invocations or requests happen each month?

Start with total monthly requests, but also note peak requests per second. Two systems with the same monthly volume can cost differently if one sees steady traffic and the other sees sharp spikes that trigger more cold starts, concurrency, or minimum instance decisions.

2. How much compute does each request consume?

Estimate average execution time and p95 or p99 execution time, not just the mean. Also note memory allocation and any CPU assumptions. For function platforms, memory settings often have a direct effect on compute cost. For container-style serverless platforms, the CPU and memory profile may be more explicit and tunable.

3. Does the app need warm capacity?

Some teams care more about latency consistency than absolute cost. If you configure minimum instances, provisioned capacity, or similar warm-start features, your monthly bill may shift from purely event-driven usage toward a partially fixed baseline. This is often where early estimates go wrong.

4. How much data leaves the service?

Networking is easy to ignore when focusing on execution pricing, but outbound traffic can dominate cost for APIs serving large JSON payloads, image transformations, file downloads, or public web apps with asset-heavy responses. In some cases, the “compute is cheap” conclusion disappears once egress is included.

5. What supporting services are required?

A serverless function rarely operates alone. You may need managed databases, queues, object storage, secrets management, logging retention, build pipelines, and observability tooling. Those are part of the real platform cost, even if they are not listed on the function runtime page.

A practical estimation workflow looks like this:

1. Define one workload, not your entire company.
2. Measure monthly requests, average duration, peak concurrency, and average response size.
3. Separate inbound traffic from outbound traffic.
4. Decide whether low-latency warm capacity is required.
5. Add support costs: storage, database, logs, queueing, CI/CD, and monitoring.
6. Run the same assumptions across each platform.
7. Stress-test the estimate with a 2x growth scenario and a burst scenario.

If you are building a broader cloud deployment workflow, it helps to estimate serverless runtime cost alongside developer workflow cost. For that angle, see Best Developer Workflow Tools for Cloud App Teams in 2026 and GitHub Actions vs GitLab CI vs CircleCI vs Buildkite for App Teams.

Inputs and assumptions

This section is the core of a refreshable buyer guide. Instead of fixed pricing claims, use the same input sheet every time you compare platforms. That makes the article worth revisiting whenever rates or product defaults change.

Workload inputs to capture

• Monthly request count: total invocations or HTTP requests.
• Peak request rate: requests per second during bursts.
• Average execution time: typical runtime per request.
• Tail latency execution time: slower requests under real load.
• Memory allocation: function memory or container memory.
• CPU profile: especially important for CPU-heavy transforms.
• Average response size: drives outbound data transfer.
• Cold-start sensitivity: whether the app needs warm instances.
• Background processing: queues, schedules, or long-running tasks.
• Runtime packaging: function zip versus container image.

Assumptions that often change the result

HTTP API vs event worker. A public API with short responses may map well to both Lambda and Cloud Run, but the economics shift if the service needs persistent connections, larger binaries, or custom container dependencies.

Short-lived vs long-running work. Functions are appealing for quick, stateless tasks. Container-based serverless platforms may become more natural when requests run longer, need more custom runtimes, or benefit from tuning concurrency at the container level.

Steady traffic vs spiky traffic. Very spiky workloads often benefit from pure scale-to-zero behavior. Steadier workloads may narrow the cost gap between serverless and more traditional platform as a service offerings, especially once warm capacity is enabled.

Response payload size. If your service returns large API payloads, files, or generated assets, outbound data charges may be more important than execution cost. Teams often miss this when comparing only request and compute units.

Observability habits. Verbose logging looks harmless in development and expensive in production. A chatty serverless app can produce meaningful billable logging, storage, and query overhead.

Regional placement. Many teams deploy near users for latency, but multi-region design can increase operational complexity and cost. Keep the first estimate region-specific.

A simple worksheet formula

You do not need a sophisticated spreadsheet to begin. A useful first-pass model is:

Total monthly cost = request cost + compute cost + warm-capacity cost + network egress + supporting services + observability + CI/CD overhead

Then create three scenarios:

• Lean: low traffic, no minimum warm capacity, modest logs.
• Expected: real production assumptions for the next 3 to 6 months.
• Stress: 2x to 5x traffic, higher burst rates, and noisier logging.

This framing is especially useful when comparing a cloud native app platform against a more general app hosting platform or PaaS. If you are also evaluating non-serverless hosting options, compare this guide with PaaS Pricing Comparison: Heroku, Render, Railway, Fly.io, and Northflank.

Worked examples

The examples below are intentionally qualitative. They show how to think, not what a provider definitely costs today. Use them to structure your own estimate.

Example 1: Lightweight JSON API for a SaaS dashboard

Imagine a B2B SaaS product serving authenticated dashboard requests. Each request performs small database reads, minimal transformation, and returns compact JSON. Traffic is light overnight and moderate during business hours.

Cost drivers:

• Request count matters.
• Execution time is short.
• Payloads are small, so egress is limited.
• Latency matters, but not enough to justify large always-on capacity.

Likely outcome: this is the kind of workload where both Lambda and function platforms often look efficient on paper. Cloud Run can still be competitive, especially if the team already ships containerized services and wants operational consistency across environments.

What to watch: if dashboard traffic spikes at the start of the workday and users are sensitive to cold starts, warm capacity settings may matter more than raw request pricing.

Example 2: Image processing webhook

Now consider a media workflow that receives uploads, generates thumbnails, performs metadata extraction, and writes results to object storage. Requests are less frequent but much heavier.

Cost drivers:

• Compute duration is far more important than request count.
• Memory and CPU allocation matter.
• Storage reads and writes are part of the total system cost.
• Outbound traffic may rise if processed images are served directly.

Likely outcome: platforms that make resource tuning clear and container packaging easy may feel more natural for this workload. The cheapest function request fee matters less when each job is compute-heavy. For these jobs, the better buyer question is often not “which request meter is lowest?” but “which platform lets me finish the work with the least waste?”

Example 3: Public web app backend with unpredictable bursts

Suppose you want to deploy app to cloud for a consumer-facing launch with press-driven traffic spikes. The backend handles auth callbacks, API reads, a few writes, and occasional fan-out jobs.

Cost drivers:

• Burst concurrency matters.
• Cold starts may affect user experience.
• Logs can explode during launch week.
• Network egress may grow faster than expected.

Likely outcome: a scale-to-zero platform remains attractive, but budgeting should include stress scenarios. A platform that looks like the best cheap serverless platform in a steady-state example may be less predictable during bursts if you need warm instances or extensive debugging logs.

Example 4: Internal event processor with low human latency sensitivity

This workload consumes queue messages, syncs data between systems, and runs on schedules. No end user is waiting for a response.

Cost drivers:

• Total jobs per month.
• Compute time per job.
• Queueing and storage costs.
• Retries and failure handling.

Likely outcome: this is often a strong fit for Lambda or cloud functions-style products because the application is event-native and tolerant of startup overhead. Here, low baseline cost can matter more than runtime flexibility.

Across all four examples, note the pattern: the right pricing choice follows workload behavior. That is why a good buyer guide is less about one platform winning and more about matching billing shape to app shape.

If your application includes a frontend deployed separately from backend services, you may also want to review How to Host a React App with Preview Builds and Custom Domains and How to Set Up Branch Previews for Every Pull Request. Keeping frontend hosting, preview environments, and backend runtime costs in one worksheet usually leads to better planning than optimizing the function layer alone.

When to recalculate

The best pricing model is the one you revisit before the bill surprises you. Recalculate your serverless estimate when any of the following change:

• Provider pricing inputs change. This is the obvious trigger for any refreshable pricing guide.
• Your traffic pattern changes. A product launch, enterprise customer rollout, or seasonal event can alter concurrency and egress dramatically.
• Your architecture changes. Moving from functions to containers, adding queues, introducing image processing, or splitting services can change which line items dominate.
• You enable warm capacity. This often converts a mostly variable-cost service into something closer to a hybrid fixed-plus-variable model.
• Your logs or metrics grow. Observability costs should be monitored, not treated as background noise.
• You change regions or go multi-region. Latency improvements can come with different economics.
• You add a managed database or storage-heavy feature. The runtime is only one part of the bill.

A practical monthly review takes less time than a migration caused by bad assumptions. Use this checklist:

1. Export the last 30 days of request volume, execution time, and network usage.
2. Compare average and peak behavior, not just totals.
3. Check whether warm-capacity settings are still justified.
4. Review log retention and verbose debug output.
5. Re-run your three scenarios: lean, expected, and stress.
6. Decide whether the current platform still matches the workload shape.

If your team is in early planning, pair this review with an architecture document and deployment workflow review. A good starting point is Reference Architecture for a Cloud-Native SaaS MVP.

One final note: a serverless cost estimate is only as good as the inputs. Use realistic payload sizes, real execution traces, and actual logging behavior whenever possible. If you are testing payloads, schemas, or event bodies during planning, lightweight utilities such as a JSON formatter and validator or a regex tester can reduce avoidable debugging noise before those messages become billable production logs.

The short version is simple: compare AWS Lambda, Cloud Run, and functions-style platforms by workload profile, not by slogan. Measure requests, compute, warm capacity, networking, and support services. Then revisit the model whenever prices, traffic, or architecture change. That approach will stay useful long after any single rate card is outdated.