apointoo.
Healthcare Cloud

AWS Lambda and DynamoDB vs Cloud Run and Firestore: Serverless Cost Drivers for a Health Data Island

cmsapointoo··9 min read

AWS Lambda with DynamoDB and Google Cloud Run with Firestore can both support a small isolated health workload. Neither stack is the universal monthly cost winner. The result depends on region, request pattern, execution duration, memory, concurrency, document or item size, consistency, query shape, storage, backups, logs, and network paths.

A useful comparison converts the same observed workload into each provider’s billing units, applies current regional rates and allowances, and exposes excluded services. This produces a reproducible estimate without presenting a temporary rate as permanent.

Start with one normalized workload

Freeze the period, region, traffic, retention, and recovery policy. Use production telemetry when available. Otherwise, label low, expected, and burst cases as assumptions. Give both stacks equal durability and observability.

Input Unit to record Why it changes cost
Requests Monthly successful and failed invocations Runtime request charges and retry volume
Compute Duration, CPU, memory, concurrency GB-seconds or vCPU and GiB seconds
Database reads Items, documents, index entries, consistency Billing unit differs by database and query
Database writes Writes, deletes, transactions, replicated writes Size and mode can multiply units
Storage Data, metadata, indexes, monthly growth Stored shape can exceed logical payload size
Recovery Backup size, retention, restore frequency Optional recovery features have separate charges
Operations Log volume, retention, metrics, traces Verbose output can dominate a small workload
Network Origin, destination, direction, bytes Region and egress path determine treatment

If one design batches writes, caches reads, or uses higher concurrency, show it as a named architecture variant. For broader budgeting, compare the cloud bill with the operating program instead of mixing staff work into request rates.

Lambda and Cloud Run compute differently

AWS Lambda charges for requests and execution duration measured in GB-seconds. Allocated memory affects the duration charge and the compute resources available to the function. Architecture and region can change the applicable rate. As of August 16, 2026, the published free tier includes one million requests and 400,000 GB-seconds per month, but the estimate should still show gross usage before the allowance.

For Lambda, collect invocations, billed duration, memory, architecture, region, and retries. Multiply billed seconds by allocated memory in GB for each function class. Use provider billing metrics rather than wall-clock latency. Include provisioned concurrency only when used. The Lambda runtime boundary review distinguishes compute from adjacent services.

Cloud Run supports request-based and instance-based billing. Request-based billing charges CPU and memory during billable instance time, with idle charges possible for minimum instances. Instance-based billing charges for the container instance lifetime and has a minimum duration. Concurrency changes how many requests share an instance, so requests and latency alone cannot reproduce cost.

For Cloud Run, record billing mode, vCPU, memory, requests, billable instance seconds, concurrency, minimum instances, region, and retries. As of August 16, 2026, the request-based allowance uses active us-central1 pricing and corresponds to 180,000 vCPU-seconds, 360,000 GiB-seconds, and two million requests per month. The instance-based service allowance uses us-central1 pricing and corresponds to 240,000 vCPU-seconds and 450,000 GiB-seconds per month.

DynamoDB and Firestore operations are not equivalent

DynamoDB offers on-demand and provisioned capacity modes. On-demand bills read and write request units. Provisioned mode bills hourly capacity allocated, even when actual use is lower. For on-demand reads, item size and consistency matter: reads are calculated in 4 KB increments, with eventually consistent, strongly consistent, and transactional reads consuming different units. Writes use 1 KB increments, and transactional writes consume more units than standard writes.

“Ten million reads” is not yet a price input. Add item size, consistency, transactions, table class, region, replication, streams, and commitments. Large items can consume several units. Global tables add regional storage and replicated writes.

Firestore Standard edition charges document reads, writes, deletes, index-entry reads, stored data including indexes and metadata, and network bandwidth. Query shape matters. A query can incur document reads plus index-entry reads. Listeners may create reads when results change or clients reconnect. Offsets can charge for skipped documents. Security-rule evaluation can require dependent-document reads.

Do not translate one DynamoDB read unit into one Firestore document read. Model operations produced by each access pattern. Test indexes and authorization queries with synthetic data. The Firestore database proof connects access and billing behavior.

Free allowances need their own row

Free usage can hide boundaries. Lambda’s request and duration allocations are monthly. As of August 16, 2026, DynamoDB’s free tier for provisioned Standard tables applies per Region and payer account. It includes 25 write capacity units, 25 read capacity units, 25 replicated write capacity units for global tables across two Regions, 25 GB of storage, 2.5 million DynamoDB Streams read requests, and 1 GB of data transfer out per month, with 15 GB of transfer for the first 12 months. It does not apply provisioned capacity to on-demand mode.

Cloud Run allowances depend on billing mode and use a us-central1 price equivalent. A deployment in another region should apply the current regional mechanics from the pricing page. Firestore permits free quota for only one database per project. Its published free quota includes 1 GiB of storage, 50,000 document reads per day, 20,000 writes per day, 20,000 deletes per day, and 10 GiB of outbound transfer per month. Daily quotas reset around midnight Pacific time.

Firestore provides no free usage for point-in-time recovery data, backup data, restore, clone, and TTL deletes. Daily quota also does not protect a burst from limits. Show gross units, eligible allowance, and billable units separately. Confirm account eligibility, database count, region, mode, and cadence before subtraction.

Storage, backups, logs, and egress close the gap

Logical payload size is not total storage. DynamoDB storage depends on table class and region, while indexes, streams, backups, point-in-time recovery, and global replicas create additional surfaces. On-demand backup storage and recovery features are billed separately. Cross-region paths can add transfer charges.

Firestore storage includes document data, metadata, and indexes, calculated from daily storage over the month. Point-in-time recovery, backups, restore, and clone have separate treatment. An index-heavy model can grow faster than the visible records. Compare retention and restore objectives, not only live database size.

Logs, audit records, traces, metrics, and exports need explicit inputs. Estimate bytes per request and retention, then test a synthetic run. Keep record contents out of logs. For network, record source, destination, direction, and bytes. Internet egress, cross-region traffic, database responses, and external calls can follow different schedules.

Also list adjacent components that the architecture actually uses: API gateway or load balancer, queue, scheduler, object store, key service, secrets, DNS, monitoring, and support. Do not assign them to a runtime price line. The pooled regional stack model is useful when fixed resources are shared across isolated workloads.

Build a reproducible calculator

Create one input sheet, two translation sheets, and one comparison sheet. Save source URL, retrieval date, currency, region, architecture, billing mode, and rate beside every unit price. Rates should be replaceable without rewriting formulas.

AWS monthly usage =
  max(0, Lambda requests - eligible request allowance) * regional request rate
  + max(0, Lambda GB-seconds - eligible duration allowance) * regional duration rate
  + DynamoDB read units * selected read rate
  + DynamoDB write units * selected write rate
  + table and index storage * regional storage rate
  + backups + recovery + logs + network + adjacent services

Google Cloud monthly usage =
  billable Cloud Run requests * regional request rate
  + billable vCPU-seconds * regional CPU rate
  + billable GiB-seconds * regional memory rate
  + Firestore document and index reads * regional read rates
  + writes and deletes * regional operation rates
  + database and index storage * regional storage rate
  + backups + recovery + logs + network + adjacent services

For Lambda, compute GB-seconds = invocations × billed seconds × allocated memory in GB by function class. For Cloud Run, use provider billable instance metrics rather than deriving them from request latency when possible. For DynamoDB, translate each operation by item size, consistency, transaction type, and capacity mode. For Firestore, count document operations and index-entry reads by query.

Run low, expected, and burst rows. Add sensitivity for duration, item size, indexes, log retention, backup growth, and cross-region egress. This shows which measurement deserves engineering work.

How to interpret the result

Use the range that matches observed behavior. Lambda with DynamoDB may suit one spiky, item-oriented workload. Cloud Run with Firestore may suit another with favorable concurrency and document access. Change consistency, duration, index fan-out, region, or minimum instances and the ranking can reverse.

Keep cost and control claims separate. Service eligibility, configuration, isolation, backup proof, incident readiness, and contract review require their own evidence. Prefer the estimate that can be reproduced and operated within the required boundary.

Frequently asked questions

Which stack is cheaper for a small health data island?

There is no universal answer. Use the same region, traffic, duration, memory, read and write behavior, storage, backup, logging, and egress assumptions, then apply current provider rates.

Can I compare Lambda requests with Cloud Run requests directly?

Only one part maps directly. Compute also depends on Lambda GB-seconds or Cloud Run CPU and memory billable time, billing mode, concurrency, minimum instances, architecture, and region.

Can free allowances make the monthly bill zero?

They may reduce eligible usage, but they have different limits, cadence, regions, modes, and exclusions. Backups, logs, egress, extra databases, recovery features, and adjacent services can still generate charges.

How often should the calculator be refreshed?

Refresh rates before procurement and after a region, architecture, billing mode, workload, retention, or recovery change. Preserve the retrieval date and recalculate from observed metrics each month during early operation.

References

Related articles