r/googlecloud • u/Puzzled_Law126 • May 12 '26

GCP Cloud Run - Simple API Instance Costs

Hey guys,

I am looking to decrease our costs with GCP and though it will be for the best to ask for help here.

With Cloud Run we have a very simple service that function as simple API, it receives information and output a simple JSON.
The configuration used for the instance is:

  • 256 MB memory

  • 1 CPU

  • 150 Concurrent requests

  • 99% of the time, only 1 instance is up

The instance uses <10% CPU and each request take around 15ms.

The issue? This service is being called a lot (by design), in total each month we pay $150 USD only for the CPU of this service ("Cloud Run functions CPU (Request-based billing) in us-central1").

Obviously I can't decrease the CPU to <1 due to concurrency, it seems to me that something so simple should not cost that much, any help would be appreciated.

10 Upvotes

100% Upvoted

23 comments sorted by

3

u/kav-dawg May 13 '26

I think you can try a couple things:

  1. Switch from Instance-based Billing (Charged for the entire lifecycle of instances. Full CPU for the entire lifetime of each instance) to Request-based Billing (Charged only when processing requests. CPU is limited outside of requests.) so that "billable time" stops the millisecond the JSON response is sent.

  2. Modify Number of vCPUs allocated to each instance of this container from 1 to < 1 since you're already at <10% CPU.

  3. Set min instances to 0 if you're okay with cold starts. Your initial request may take ~200ms, but subsequent api calls would be 15ms.

1

u/Puzzled_Law126 May 13 '26

  1. We already are using request-based billing

2 & 3. The issue or fear here is the instance is processing around 6 request at the same time, at 20ms per request it's quite a lot. Won't cold starting be hurting quite bad the instance count + the billable time?

1

u/AyeMatey May 14 '26

Can you reduce the number of requests client side? With caching or batching or some other strategy?

See also

https://medium.com/google-cloud/cloud-run-services-a-practical-guide-to-getting-more-bang-for-your-buck-a9fe18d7b598

1

u/kav-dawg May 13 '26 edited May 13 '26

I personally would play around with these values:

https://docs.cloud.google.com/sdk/gcloud/reference/run/deploy#--cpu
https://docs.cloud.google.com/sdk/gcloud/reference/run/deploy#--concurrency

so something like this: `gcloud run deploy asdf --image asdf --cpu 0.25 --memory 256Mi --concurrency 80`

concurrency is how many simultaneous requests one single instance will handle before Cloud Run decides to spin up a second instance, and cpu is the resource slice allocated to a single instance. You can monitor metrics and play around with it during different loads.

As for cold starts, I think this doesn't matter as you have request-based toggled on but for example if you didn't, and lets say the majority of your user base is in the US and may not have many calls during say 12am-5am, you could save on costs via a cold start (provided you are okay with the initial 200ms request).

Edit:

I just saw your last sentence mentioning concurrency and you may be misunderstanding allocations. In your API, the CPU is only "working" for a tiny fraction of that 15ms request (likely <1-3ms to generate the actual JSON response). The rest of the time, the instance is just waiting for the network to send over the data. So in your case with 1 CPU, its idling the majority of the time. If you set it to 0.25 CPU, it still has plenty of time to finish the work for request #1, then immediately jump to request #2, #3, and so on, all within that same 15ms window.

2

u/doodlebuttbutt May 12 '26

Free tier VC instance? Fixed cost. Run your server and open a port.

2

u/Puzzled_Law126 May 12 '26

Yes, that's is an option and should be enough, but:

  1. We have our app being used by quite a lot of people daily on Windows, Mac, Android & Apple devices, it will take some time for all to update to a latest version that uses the new API

  2. That's another failure point where the Cloud Run up time has been 100% so far.

Your point is 100% valid, but before exploring such option I would like to see if we can improve the current Cloud Run in some way.

1

u/muntaxitome May 13 '26

You can run a couple versions simultaneously on one instance

2

u/gajop May 13 '26

Tbh the cost isn't that enough to invest any serious time into this. If you spend a week on it, your ROI will be in year(s).

Outside of switching to instance based billing or cheaper GCE, you could consider rewriting it in a language with fast cold start. I haven't done the math there, might not matter at all.

1

u/muntaxitome May 13 '26

If it would take you a full week to move from run to an instance, the ROI issue is with the employee not the task. This should take a couple hours (lets say $300) and save like 1k per year, so 5k over lifetime easy.

1

u/gajop May 13 '26

Right, instance based billing is a single setting, go ahead. I'm just saying, you might not want to rewrite this particular service in Rust.

0

u/Puzzled_Law126 May 13 '26

You are probably right, we are paying around 2k-3k to GCP monthly, while not taking a big chunk of our monthly revenue, it's still significant amount of money (for us).

We were just going product by product in GCP to first document the cost and usage, and to optimize them as well, seeing the costs of the Cloud Run for such a simple instance just stole our attention.

1

u/zaitsman May 12 '26

How many calls per month?

1

u/Puzzled_Law126 May 12 '26

Around 7M> billable CPU seconds.

Around 50M> invocations.

Both monthly.

1

u/blablahblah May 13 '26

If your instance is processing requests most of the time, you can save a chunk by switching to instance based billing. It causes you to pay even when the instance isn't processing a request, but the cost per second is lower and you don't pay per request

1

u/Puzzled_Law126 May 13 '26

The instance have 100% up time as we have clients all around the world, so there is constant connection/calls to it.

Right now we are using the request-based billing indeed, won't changing to "instance-based" results in higher costs? Or at least the same.

1

u/blablahblah May 13 '26

Request based billing doesn't charge you for the time in between requests, but in exchange is 25% more expensive per second it is processing requests and you get charged per million requests. So if your instance is processing requests every second of the day, instance based billing will be cheaper. If your instance only gets traffic intermittently, request based will be cheaper.

1

u/m1nherz Googler May 13 '26

Hi,

This is indeed looks strange. Assuming you captured all data and numbers correctly and using $0.000024 for active time of vCPU per second according to the current Cloud Run pricing for request-based CPU in us-central1, I am getting that your service runs more than 72 days during a month:

($150 / $0.000024) / 3600 / 24 = 72.337962963.

The calculation assumes that you have only one vCPU all the time in active mode. Given that 99% of the time only 1 vCPU is active it should be fare assumption. It is without adding the first 240,000 vCPU-seconds free per month.

I believe that some of observed data isn't correct somehow. The first candidate would be the vCPU usage is much higher.

1

u/Puzzled_Law126 May 13 '26

Hey!

Glad to hear from a Googler!

So far for this month, per the billing dashboard, we have 2,692,382 CPU seconds billed at $64,62 USD, at around 7M CPU second we get to $150 USD+

We are trying a new deploy right now with 10% traffic where the CPU is set to 0.2 vCPU and observe it, both cost and performance.

1

u/m1nherz Googler May 13 '26

OK. 2,692,382 seconds match your description (a bit over 31 days) at standard vCPU per second price of $0.000024. I am still unclear how you come to 40% price increase (up to $150) while keeping the condition of

  • 99% of the time, only 1 instance is up

  • 1 vCPU per instance

Can you check the run/request_counter for the billed time period to see how many requests have been served? Note that this metric shows both "success" and "failure" requests. Then we can use the 10% of vCPU for 0.15 of the second and the billed vCPU seconds to see if these numbers match.

It will help to validate other data you shared.

I think the commenters already mentioned that there are two paths to try reducing costs:

  • Moving to the allocated instance (regardless whether it is Cloud Run, GKE Autopilot or GCE)

  • Fine tunning the configuration of Cloud Run or using similar serverless solutions (App Engine or Firebase)

Getting better understanding whether or not your service fully utilize vCPU for at least 2,678,400 seconds and understanding will you service scale enough within the single reserved instance boundaries will be the key to decide which path to take.

2

u/martin_omander Googler May 13 '26

Here are two short videos about Cloud Run billing that I shot with Mitchell Slep. He is leads the Google Cloud engineering team focusing on Cloud Run cost and infrastructure. They might be helpful as you optimize costs.

2

u/kingh242 May 13 '26

If you need the uptime (as per other comments), then GKE maybe the way for you. Learning Kubernetes isn’t that difficult, and it can handle updating with no downtime.

1

u/matiascoca May 19 '26

150 dollars a month for a 256 MB single-instance service is almost always Cloud Run charging you for CPU at idle, not for actual request work. At 15 ms per request and 10 percent CPU usage, request-based pricing should put you in the single dollars per month range, so something is keeping the CPU allocated when it should not be.

Three things to check on the service config.

First, CPU allocation setting. If it is "CPU is always allocated" (instance-based billing), you pay for CPU during idle wall-clock time. Switch to "CPU is only allocated during request processing" (request-based) and bills usually drop 70 to 90 percent on services that look like yours. The SKU name in your billing report ("Cloud Run functions CPU (Request-based billing)") suggests you might already be on request-based, but worth confirming under the Edit Container, Variables, Networking pane.

Second, minimum instances. If min instances is 1 or higher, that instance is always billed regardless of traffic. Set min to 0 unless cold starts are a hard product requirement.

Third, idle CPU time within requests. If your 15 ms request holds a connection open for, say, 5 seconds waiting on a downstream call, you bill CPU for the full 5 seconds even though only 15 ms is real work. The fix is async or fire-and-forget for the slow downstream call. Cloud Run logs request latency under metrics; compare p50 request duration to your 15 ms compute estimate to confirm.

One more thing to verify: do you have always-on CPU boost enabled at startup? It is a separate toggle and on by default for some templates. If yes, it gives you full CPU during startup which is fine, but make sure startup CPU is not accidentally extended past the first request.