About Cloud Run
It’s hard not to be impressed by the current featureset of Google Cloud Run, the stateless & serverless GCP service that celebrated it’s first birthday recently.
As new capabilities are dropped frequently, there is an increasing number of use cases. In many of our architectural designs at vBridge, Cloud Run gets a front seat.
But what does it cost?
“Ok, you have my attention, but .. what about pricing? Typically, as with every serverless technology, the answer to this question is the start of a new conversation: “it depends”. Unfortunately, this answer does not rhyme with the expectations of most companies: they expect clear upfront cost estimations.
Before educated guessing is possible, the first challenge is to get to know the application. How much RAM is required? How long does it take to process a request on average? How much CPU cores are required?
To put things in perspective, I created a GSheet that might be helpful if you’re new to Cloud Run. The free tier is taken into account. It has a value of about $5/month
Be aware that is not a golden bullet for Cloud Run pricing:
- Egress traffic is not included
- non-free supporting services (logging, container hosting, …) might be needed too.
- One of the distinctive features of Cloud Run is the fact that a container can process multiple (up to 80) requests simultaneously, without being charged extra. This effect is not taken into account, because the traffic pattern (bursty vs non-bursty traffic) is unknown. Parallel requests will have a positive effect on pricing, mainly for the pricing of the memory part…
Cost scenario 1
In a scenario with 512MB RAM, 1CPU and 0.6s average per request:
As you can see: the pricing for requests is negligible.
Cost scenario 2
In a scenario with 1GB RAM, 1CPU and 1s average per request:
Cost scenario 3
This scenario could be a backend service that processes some more heavy tasks: 4s/request, 4GB RAM, 2CPU
Your cost scenario
Feel free to copy and fiddle arround with the GSheet I used to create this post.
Final thoughts
I deliberately limited the number of requests in the simulations to 3bln/month. For a higher number of requests, other effects start to set in, and you might opt to invite additional Cloud components to the party: Load balancing, caching layers, CDN, …
All these moving parts will make this estimation less useful.