As you all know, Cloud Run is a serverless product. Let's discuss how we can save money with Cloud Run, as its pricing can often seem fixed, as noted in the pricing considerations.
There are a few strategies we can employ. According to the documentation, one way to save is by using committed use discounts. This means, for example, committing to Google that you will use Cloud Run at a certain capacity for one or three years in exchange for a discount.
To illustrate this, we have an example where we made changes to our Cloud Run setup to demonstrate how different approaches can save a significant amount of money.
As you can see in this blue line, this is Compute Engine. You might be wondering why we're discussing Compute Engine when we are focusing on Cloud Run. This will become clear in the second part. Here in the chart of top spenders we also have Cloud SQL (red), Cloud Storage (Green) and Cloud Run (orange):
What happened here is that we had a database connected to Cloud Run using Cloud Run VPC serverless, which in turn uses Compute Engine. As you can see, this blue segment disappears at a certain point. On the Feb 9, Google Cloud removed all the Cloud Run VPC connections we had and the trend started to decline.
At the Feb 23 point, there was no communication with VPC connectors. As you can see, we started saving this entire block of expenses. Without using VPC connectors to communicate Cloud SQL with Cloud Run, we switched to using direct egress. While direct egress increased our Cloud Run costs slightly, it significantly reduced the costs associated with Compute Engine.
Previously, we were spending approximately 1.95 euros per day. Now, after these changes, we are spending less than 1 euro per day. We have effectively saved around 50% of our expenses. Wow!
So, yes, we can save money. Now let's talk about the 4 days in the graph when the Cloud Run cost spiked. This is another tactic we used - adjusting the CPU allocation. We set the CPU to always be allocated.
What does this mean? For Cloud Run, you can choose to have the CPU always running or only running when needed. The difference is significant. For example, if a new thread starts because your service needs more capacity, launching a new instance of a container will take longer if the CPU is not always allocated. The CPU is consumed during container startup, shutdown, and usage. If the CPU is always allocated, it's always there but comes at a constant cost.
This graph compares the same consumption over four days with CPU always allocated (Feb 16 - Feb 19) vs. only allocated when needed (Feb 20 and further). The difference highlights that there are various tricks and strategies to save money with Cloud Run.
These are just a few ways we can help you keep your cloud costs down. Without it can be easy to end up spending more than you expected. That’s why we’re offering a Free Cloud Cost Audit — to help companies uncover hidden inefficiencies and optimize their cloud spending. Our objective is straightforward: to equip you with actionable insights so that you can assume control of your cloud budget.
Learn more about the audit and how we can help here.
Here's the same article in video form for your convenience:
Top comments (0)