AWS
Microsoft Azure
Google Cloud
Key takeaways
1
Cloud Run charges for allocated resources and billable time, not just the number of requests.
2
The free tier can cover small workloads, including up to 2 million requests monthly under request-based billing.
3
Billing mode, concurrency, and minimum instances affect costs. Test performance before changing settings.
4
Committed use discounts can reduce eligible costs by up to 46%, but native commitments require ongoing payments.
Google Cloud Run pricing is easier to understand when you calculate one workload from start to finish. A small API that receives occasional requests can cost very little, while an application with continuously running instances, databases, or GPUs can generate a much larger bill.
This guide covers current rates, monthly examples, billing modes, free allowances, and opportunities to reduce spending.
The following prices come from Google’s official Cloud Run pricing page and use the Tier 1 region Iowa (us-central1). The usage rates shown are published USD list prices before free-tier allowances, committed use discounts or negotiated discounts, checked October 20, 2026.
This guide covers current rates, monthly examples, billing modes, free allowances, and opportunities to reduce spending.
Google Cloud Run Pricing and Free Tier
Google Cloud Run uses consumption-based pricing for CPU, memory, requests, and other resources. Rates vary by region and workload type.The following prices come from Google’s official Cloud Run pricing page and use the Tier 1 region Iowa (us-central1). The usage rates shown are published USD list prices before free-tier allowances, committed use discounts or negotiated discounts, checked October 20, 2026.
| Charge or monthly allowance | Request-based services | Instance-based services |
|---|---|---|
| Active CPU per vCPU-second | $0.000024 | $0.000018 |
| Idle minimum-instance CPU per vCPU-second | $0.0000025 | Normal lifecycle rate |
| Memory per GiB-second | $0.0000025 | $0.000002 |
| Requests per million | $0.40 | No separate request fee |
| Free CPU allowance | 180,000 vCPU-seconds | 240,000 vCPU-seconds |
| Free memory allowance | 360,000 GiB-seconds | 450,000 GiB-seconds |
| Free requests | 2 million | No separate request fee |
A vCPU-second measures one allocated virtual CPU for one second. A GiB-second measures one gibibyte of allocated memory for one second.
The free tier is applied as a monthly spending discount calculated using Tier 1 prices. It is shared across eligible usage in the billing account, not granted separately to every deployment.
Other services can add charges, including internet egress, Cloud SQL, Cloud Logging, Artifact Registry, and networking components.
Consider a simplified request-based API with these assumptions:
The free tier is applied as a monthly spending discount calculated using Tier 1 prices. It is shared across eligible usage in the billing account, not granted separately to every deployment.
Other services can add charges, including internet egress, Cloud SQL, Cloud Logging, Artifact Registry, and networking components.
How much does Google Cloud Run cost per month?
Cloud Run does not have one fixed monthly price. The same number of requests can produce different bills depending on request duration, allocated resources, concurrency, and instance lifecycle.Consider a simplified request-based API with these assumptions:
Region: us-central1
CPU: 1 vCPU
Memory: 0.5 GiB
Average request duration: 200 milliseconds
Effective concurrency: 1
Minimum instances: 0
No startup or shutdown overhead
No networking, database, or other supporting-service charges
| Monthly requests | Active instance time | Gross Cloud Run compute and request cost |
|---|---|---|
| 100,000 | 20,000 seconds | $0.55 |
| 1 million | 200,000 seconds | $5.45 |
| 10 million | 2,000,000 seconds | $54.50 |
These are illustrative gross costs before free allowances or committed use discounts.
For example, one million requests produce:
For example, one million requests produce:
CPU: 200,000 × $0.000024 = $4.80
Memory: 200,000 × 0.5 × $0.0000025 = $0.25
Requests: 1 × $0.40 = $0.40
Total: $5.45
If the billing account has its entire applicable free tier available, the modeled one-million-request workload has no Cloud Run compute or request charges after allowances.
Actual billing can differ because requests overlap, startup and shutdown time may be billed, and applications may use other Google Cloud services.
Instance-based services have separate CPU and memory allowances shown in the pricing table above.
The free tier does not mean an entire application is free. Networking, databases, image storage, logging, and other supporting resources may generate charges.
Actual billing can differ because requests overlap, startup and shutdown time may be billed, and applications may use other Google Cloud services.
What is included in the Cloud Run free tier?
For request-based services, the monthly free tier includes 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests.Instance-based services have separate CPU and memory allowances shown in the pricing table above.
The free tier does not mean an entire application is free. Networking, databases, image storage, logging, and other supporting resources may generate charges.
How to Calculate Google Cloud Run Pricing
For a request-based service, estimate the gross cost using the following components:
Gross cost = Active CPU cost + Active memory cost + Idle minimum-instance cost + Request charges
Where:
Active CPU cost = allocated vCPUs × billable active seconds × CPU rate
Active memory cost = allocated GiB × billable active seconds × memory rate
Idle minimum-instance cost = idle billable resource usage × applicable idle rates
Request charges = billable requests ÷ 1,000,000 × request rate
Then subtract applicable free-tier discounts and add other billable services.
For instance-based billing, use the full billable instance lifecycle instead of request-processing time. There is no separate per-request charge.
These formulas are simplified estimates. Cloud Run rounds billable time in 100 ms increments, and lifecycle minimums and additional features can change the calculation.
You can validate an estimate using the Google Cloud pricing calculator.
Google’s billing settings documentation explains how each mode handles resource allocation.
For instance-based billing, use the full billable instance lifecycle instead of request-processing time. There is no separate per-request charge.
These formulas are simplified estimates. Cloud Run rounds billable time in 100 ms increments, and lifecycle minimums and additional features can change the calculation.
You can validate an estimate using the Google Cloud pricing calculator.
Request-Based vs. Instance-Based Cloud Run Billing
Cloud Run services support two billing settings. Choosing the right one can materially affect monthly costs.Google’s billing settings documentation explains how each mode handles resource allocation.
| Feature | Request-based billing | Instance-based billing |
|---|---|---|
| Billable time | Request processing, startup, shutdown, and eligible minimum-instance idle time | Entire instance lifecycle |
| Request charge | Yes | No |
| CPU availability | Primarily during request processing | Throughout instance lifecycle |
| Idle minimum instances | Reduced idle rates | Normal lifecycle rates |
| Typical use case | Intermittent APIs and web services | Sustained workloads or background processing |
Request-based billing is often worth testing first for intermittent traffic. Instance-based billing can be more economical when instances remain busy or need CPU outside request processing.
However, instance-based billing does not automatically mean instances run continuously. Services can still scale to zero under supported autoscaling configurations.
However, instance-based billing does not automatically mean instances run continuously. Services can still scale to zero under supported autoscaling configurations.
Example 1: Does keeping one minimum instance increase costs?
Consider a request-based API running for 30 days with:1 vCPU and 0.5 GiB memory
500,000 monthly requests
200 ms processing time per request
One instance handling requests sequentially
100,000 seconds of active processing
Assume the requests arrive in 500 separated bursts, with no overlap between bursts. A retained minimum instance is idle for the remaining 2,492,000 seconds.
The calculation excludes startup and shutdown overhead, networking, and other services.
The calculation excludes startup and shutdown overhead, networking, and other services.
| Monthly component | Minimum 0 | Minimum 1 |
|---|---|---|
| Active CPU | $2.40 | $2.40 |
| Retained idle CPU | $0.00 | $6.23 |
| Memory | $0.13 | $3.24 |
| Requests after allowance | $0.00 | $0.00 |
| Total before compute allowances | $2.53 | $11.87 |
| Total after compute allowances | $0.00 | $6.65 |
The free-tier CPU allowance has a $4.32 value at the request-based active CPU rate, and the memory allowance has a $0.90 value. Apply the discounts to the unrounded component costs before rounding the final total.
In this simplified model, keeping one minimum instance adds approximately $6.65 per month after available free-tier allowances. This assumes the instance remains allocated throughout the modeled idle periods.
Actual costs may vary because Cloud Run can restart instances, and startup behavior, resource usage, and billing adjustments can affect the final bill.
For an I/O-bound application, overlapping requests may share instance time and reduce billable resource consumption. For CPU-intensive applications, increasing concurrency may instead increase latency.
Consider one million requests, each taking 200 ms, with 1 vCPU and 0.5 GiB memory.
Assume free allowances have already been consumed and no CUDs apply.
In this simplified model, keeping one minimum instance adds approximately $6.65 per month after available free-tier allowances. This assumes the instance remains allocated throughout the modeled idle periods.
Actual costs may vary because Cloud Run can restart instances, and startup behavior, resource usage, and billing adjustments can affect the final bill.
Example 2: How concurrency changes Cloud Run costs
Concurrency determines how many requests one Cloud Run instance can process simultaneously.For an I/O-bound application, overlapping requests may share instance time and reduce billable resource consumption. For CPU-intensive applications, increasing concurrency may instead increase latency.
Consider one million requests, each taking 200 ms, with 1 vCPU and 0.5 GiB memory.
Assume free allowances have already been consumed and no CUDs apply.
| Billing mode | Effective request sharing | Modeled billable time | Gross cost |
|---|---|---|---|
| Request-based | 1 | 200,000 seconds | $5.45 |
| Request-based | 20 | 10,000 seconds | $0.65 |
| Instance-based | 1 | 200,000 seconds | $3.80 |
| Instance-based | 20 | 10,000 seconds | $0.19 |
These figures are illustrative estimates, not guaranteed Cloud Run charges. They assume requests overlap efficiently without increasing processing time. The instance-based figures represent an idealized lower bound with no additional idle lifecycle time.
Actual costs depend on achieved concurrency, instance scaling, startup overhead, and the duration instances remain running between requests. Setting concurrency to 20 does not guarantee twentyfold savings.
For example, at 200,000 active seconds:
Actual costs depend on achieved concurrency, instance scaling, startup overhead, and the duration instances remain running between requests. Setting concurrency to 20 does not guarantee twentyfold savings.
For example, at 200,000 active seconds:
Request-based billing: $5.45
Instance-based billing with 1× lifecycle time: $3.80
Instance-based billing with 2× lifecycle time: $7.60
Instance-based billing with 3× lifecycle time: $11.40
Configured concurrency is not guaranteed effective concurrency. Setting a maximum of 20 does not mean every instance will consistently process 20 simultaneous requests.
Use Google’s concurrency guidance and replay representative traffic before changing production settings.
Consider an API using Cloud Run alongside Cloud SQL, Artifact Registry, and Cloud Logging.
Use Google’s concurrency guidance and replay representative traffic before changing production settings.
What Else Contributes to a Cloud Run Monthly Bill?
Cloud Run compute may be only one component of the total application cost.Consider an API using Cloud Run alongside Cloud SQL, Artifact Registry, and Cloud Logging.
| Component | How to estimate it |
|---|---|
| Cloud Run | CPU, memory, requests, and billable time |
| Cloud SQL | Database instance, storage, backups, and applicable networking |
| Artifact Registry | Stored container image data and applicable transfers |
| Cloud Logging | Billable log ingestion and retention |
| Internet egress | Transferred data and applicable network rates |
| VPC connector | Connector resources and related networking charges |
For example, if an application generates $5.45 in gross Cloud Run charges, its total bill is not necessarily $5.45.
You must add the actual database, storage, logging, and networking charges. Those costs depend on configuration and usage and should not be estimated from request count alone.
This distinction is important when comparing serverless applications with traditional virtual machines.
A job that runs for several minutes is billed for its allocated resources during the billable lifecycle. Retries add execution costs, while parallel tasks can increase concurrent spending.
Delayed Jobs have a separate rate card and should not be estimated using standard job prices.
They have their own CPU and memory pricing. Worker pools do not use the same request-based billing model as ordinary Cloud Run services.
A worker pool’s cost depends on its configured resources, instance count, running duration, and any applicable GPU charges.
Check the official Cloud Run pricing tables before estimating worker-pool spending.
For an L4 GPU without zonal redundancy, the Tier 1 reference rate is $0.0001867 per second, or approximately $0.67 per hour for the GPU component alone.
GPU-enabled services require instance-based billing.
For an L4 configuration with 4 vCPUs and 16 GiB memory, supporting compute at the instance-based reference rates adds:
You must add the actual database, storage, logging, and networking charges. Those costs depend on configuration and usage and should not be estimated from request count alone.
This distinction is important when comparing serverless applications with traditional virtual machines.
Cloud Run Jobs, Worker Pools, and GPU Pricing
Cloud Run pricing also covers jobs, worker pools, and GPU workloads. These resources have different billing characteristics.Cloud Run jobs pricing
Cloud Run jobs use instance-based lifecycle billing. Each started instance has a one-minute minimum billing duration.A job that runs for several minutes is billed for its allocated resources during the billable lifecycle. Retries add execution costs, while parallel tasks can increase concurrent spending.
Delayed Jobs have a separate rate card and should not be estimated using standard job prices.
Cloud Run worker pools pricing
Cloud Run worker pools support workloads that need continuously running background processing rather than incoming HTTP requests.They have their own CPU and memory pricing. Worker pools do not use the same request-based billing model as ordinary Cloud Run services.
A worker pool’s cost depends on its configured resources, instance count, running duration, and any applicable GPU charges.
Check the official Cloud Run pricing tables before estimating worker-pool spending.
Cloud Run GPU pricing
Cloud Run supports NVIDIA L4 and NVIDIA RTX PRO 6000 Blackwell GPU configurations, subject to regional availability and configuration requirements.For an L4 GPU without zonal redundancy, the Tier 1 reference rate is $0.0001867 per second, or approximately $0.67 per hour for the GPU component alone.
GPU-enabled services require instance-based billing.
For an L4 configuration with 4 vCPUs and 16 GiB memory, supporting compute at the instance-based reference rates adds:
CPU: 4 × 3,600 × $0.000018 = $0.2592/hour
Memory: 16 × 3,600 × $0.000002 = $0.1152/hour
GPU: 3,600 × $0.0001867 = $0.67212/hour
Combined reference cost: approximately $1.05 per running hour, before allowances, discounts, networking, and other services.
GPU charges do not receive the Cloud Run free-tier allowance, and Compute flexible CUDs do not discount the GPU component.
Google’s GPU configuration documentation explains resource requirements and redundancy options.
Request-based billing can work well for intermittent applications. Instance-based billing may be more economical for sustained processing or background work.
Test different configurations while monitoring request latency, CPU utilization, memory usage, and errors.
Higher concurrency can reduce instance time for suitable workloads, but it should not compromise performance.
Use a nonzero minimum only when its measured latency benefit justifies the additional cost.
However, region selection should also account for users, data residency, database placement, latency, and network transfer costs.
Avoid committing based only on peak traffic or temporary demand.
Google’s Cloud Run cost optimization guidance provides additional configuration recommendations.
These discounts exchange a recurring spending commitment for lower resource prices over a one-year or three-year term.
According to Google’s flexible CUD documentation, the discounts differ by billing mode.
GPU charges do not receive the Cloud Run free-tier allowance, and Compute flexible CUDs do not discount the GPU component.
Google’s GPU configuration documentation explains resource requirements and redundancy options.
How to Reduce Google Cloud Run Costs
Cloud Run cost optimization begins with resource configuration and billing behavior. Commitment discounts should generally be evaluated after those settings are reviewed.1. Choose the right billing mode
Compare request-based and instance-based billing using representative traffic.Request-based billing can work well for intermittent applications. Instance-based billing may be more economical for sustained processing or background work.
2. Optimize CPU, memory, and concurrency
Avoid allocating more resources than the application needs.Test different configurations while monitoring request latency, CPU utilization, memory usage, and errors.
Higher concurrency can reduce instance time for suitable workloads, but it should not compromise performance.
3. Review minimum instances
Minimum instances can improve responsiveness but generate charges while idle.Use a nonzero minimum only when its measured latency benefit justifies the additional cost.
4. Compare regions and supporting services
Tier 1 regions generally have lower Cloud Run compute rates than Tier 2 regions.However, region selection should also account for users, data residency, database placement, latency, and network transfer costs.
5. Review committed use discounts
Once you understand your stable eligible baseline, committed use discounts may reduce recurring costs.Avoid committing based only on peak traffic or temporary demand.
Google’s Cloud Run cost optimization guidance provides additional configuration recommendations.
Cloud Run Committed Use Discounts: Rates and Eligibility
Google Cloud Run supports Compute flexible committed use discounts, or CUDs, for eligible usage.These discounts exchange a recurring spending commitment for lower resource prices over a one-year or three-year term.
According to Google’s flexible CUD documentation, the discounts differ by billing mode.
| Eligible usage | One-year discount | Three-year discount |
|---|---|---|
| Request-based services | 17% | 17% |
| Instance-based services | 28% | 46% |
| Cloud Run jobs | 28% | 46% |
| Cloud Run worker pools | 28% | 46% |
| GPU and networking charges | Not eligible | Not eligible |
Compute flexible CUDs can cover eligible usage across supported services, projects, and regions within the same Cloud Billing account.
Google no longer sells new standalone Cloud Run CUDs, although existing commitments remain supported through their terms.
For a broader comparison, read our guide to GCP committed use discounts.
A fully utilized three-year Compute flexible commitment provides a 46% discount, making the corresponding committed hourly cost $54.
If eligible usage later drops to an on-demand equivalent of $50 per hour and there is no other eligible usage to consume the commitment, the $54 payment obligation remains.
You would pay $4 more for that hour than the equivalent on-demand usage.
This simplified example excludes other eligible services, free allowances, management fees, and other billing adjustments.
Native commitments cannot be cancelled simply because usage decreases.
Before purchasing, review your existing commitment coverage and utilization, workload changes, and predictable hourly demand.
Monitor request volume, billable instance time, instance count, latency, errors, and Cloud Billing exports.
Google provides the run.googleapis.com/container/billable_instance_time metric for observing billable instance time. It should not be treated as a complete invoice calculation.
Google no longer sells new standalone Cloud Run CUDs, although existing commitments remain supported through their terms.
For a broader comparison, read our guide to GCP committed use discounts.
Example: When can a Cloud Run commitment become expensive?
Suppose your stable eligible instance-based usage costs $100 per hour at on-demand rates.A fully utilized three-year Compute flexible commitment provides a 46% discount, making the corresponding committed hourly cost $54.
If eligible usage later drops to an on-demand equivalent of $50 per hour and there is no other eligible usage to consume the commitment, the $54 payment obligation remains.
You would pay $4 more for that hour than the equivalent on-demand usage.
This simplified example excludes other eligible services, free allowances, management fees, and other billing adjustments.
Native commitments cannot be cancelled simply because usage decreases.
Before purchasing, review your existing commitment coverage and utilization, workload changes, and predictable hourly demand.
How to Monitor and Control Cloud Run Spending
Cost optimization should continue after deployment.Monitor request volume, billable instance time, instance count, latency, errors, and Cloud Billing exports.
Google provides the run.googleapis.com/container/billable_instance_time metric for observing billable instance time. It should not be treated as a complete invoice calculation.
| Control | What it does |
|---|---|
| Budget alerts | Notify you about spending thresholds |
| Maximum instances | Help limit scaling, subject to documented behavior |
| Budget spend caps | Can pause eligible services when configured thresholds are reached |
| Billing exports | Provide detailed cost data for analysis |
Budget alerts do not automatically stop workloads.
Spend-cap enforcement also has limitations, including possible overages and service disruption. Existing commitments and some supporting-service charges can continue.
Review Google’s billing controls before relying on them.
Our read-only Savings Test identifies potential savings without requiring purchasing permissions. With CoPilot and Autopilot, teams can approve recommendations or automate eligible commitment purchases.
With our Flex Insured Commitments, teams can access a 46% discount on eligible instance-based Cloud Run usage through a three-year Compute flexible CUD with none of the commitment risk.
If an eligible Flex Commitment costs more than equivalent pay-as-you-go usage, we provide Cashback protection for the qualifying difference under our program terms. Our protection does not cancel the underlying commitment, and we do not automatically protect existing customer-owned commitments as Flex Commitments.
We charge an agreed percentage of realized savings, so our fees are tied to verified results rather than a fixed platform subscription.
Spend-cap enforcement also has limitations, including possible overages and service disruption. Existing commitments and some supporting-service charges can continue.
Review Google’s billing controls before relying on them.
How Usage.ai Helps Optimize Cloud Run Commitments
At Usage.ai, we help teams reduce Google Cloud Run costs by identifying eligible commitment savings, managing purchases, and reducing financial exposure when usage changes.Our read-only Savings Test identifies potential savings without requiring purchasing permissions. With CoPilot and Autopilot, teams can approve recommendations or automate eligible commitment purchases.
With our Flex Insured Commitments, teams can access a 46% discount on eligible instance-based Cloud Run usage through a three-year Compute flexible CUD with none of the commitment risk.
If an eligible Flex Commitment costs more than equivalent pay-as-you-go usage, we provide Cashback protection for the qualifying difference under our program terms. Our protection does not cancel the underlying commitment, and we do not automatically protect existing customer-owned commitments as Flex Commitments.
We charge an agreed percentage of realized savings, so our fees are tied to verified results rather than a fixed platform subscription.
Frequently asked questions
How much does one million Cloud Run requests cost?
One million requests have a $0.40 request-charge component under request-based pricing before free allowances. If the monthly two-million-request allowance remains available, that component is $0. CPU, memory, and supporting-service costs are calculated separately. Total costs depend on allocated resources, billable time, and concurrency.
Is Google Cloud Run free?
Google Cloud Run offers monthly free allowances for eligible CPU, memory, and request usage. Small applications may fit within those allowances, but databases, networking, storage, and other supporting services can still generate charges. The free tier is shared across applicable usage in the billing account.
Does Cloud Run charge when there are no requests?
Request-based services can scale to zero and avoid instance compute charges when no instances are running. Retained minimum instances incur idle charges. Instance-based services are billed throughout each running instance's lifecycle, including idle periods. Supporting resources and existing commitments may still cost money.
How can I reduce Google Cloud Run pricing costs?
Start by reviewing CPU, memory, concurrency, minimum instances, and billing mode. Compare regional rates and supporting-service costs. Once the configuration is efficient, evaluate Compute flexible committed use discounts against stable eligible hourly demand. Monitor utilization to avoid paying for commitments that workloads no longer consume.
Can I cancel a Cloud Run committed use discount?
Google's Compute flexible committed use discounts cannot be cancelled after purchase. The hourly payment obligation continues for the commitment term even if usage decreases. Usage.ai offers separate cashback protection for qualifying Flex Insured Commitments under applicable program terms, but that protection does not cancel Google's underlying obligation.
Share
Facebook
X
LinkedIn
Reddit
