Last year, Google Cloud presented something called FinOPS.
The idea is simple: to save money on our cloud infrastructure.
So, what we're going to do here is use a number of tools. As you can see on the screen, when we go to FS, we'll have various options to understand how we can save money.
For example, in our scenario, it tells us that we have a potential monthly saving of $61 in our billing account because of some expenses in cloud usage.
Next, if we scroll down, we see a top recommendation because we have a number of recommendations; in this case, there are ten.
But okay, we have this top recommendation.
What we can see is that, for example, we can save $15 to $30 using this Commitment User Discount (CUD).
But how does this work? For example, in this case, we tell Google that for one year or three years, as you can see on the screen, we will pay a fixed amount in euros.
In this case, for example, the estimated monthly cost is almost €18. We pay €18 per month, and we save $16 per month. The problem here is that you are signing a three-year contract. At the beginning of the month, you pay these €16, and after that, you don't need to pay anything else.
It's great if you have an application that is always up and running and you have consistent expenses. But if your needs vary, it might be better to opt for the one-year commitment or another option.
This is excellent because we have all the top recommendations, plus if we go here, we have all the recommendations they're giving us.
There's a FinOps score, as you can see on the right side of the screen. If we go here, it even tells us how we can improve our score.
In this case, we have a score of 3.0, and we can improve to a maximum of five. The same goes for the benchmark.
It tells us, "Okay, if you want to increase this score, here's what you need to do." We have to do three things.
The first one is tagging. We need to tag our components, like our SQS (Simple Queue Service). This way, we can create reports based on our tags. For example, we tag everything related to one application, like Cloud Run Database. Then, it's easy for us to understand where the expenses are because we can search by tag.
The second is what we saw before. We can apply these Commitment User Discounts to save per year or for three years.
The third one is something new that was created in 2023: a way to export all your expenses to a BigQuery database. In BigQuery, we can perform any kind of search we want. This is useful, for example, if you have a large environment.
Okay, there's something else I want to explain because, in this scenario, it's telling me that I'm spending a lot of money. If we go to this overview or these reports, it shows that we're spending a lot of money on computing.
Instead of going to the test, let's look at Claimora Pro and Claimora Staging. As you can see in those two machines, we have expenses of almost €2 per day. Over these €2 per day, we have €1.22 in daily computing expenses, totaling about €45 per month.
So, most of our expenses are from these computing instances in Claimora Pro and Claimora Staging.
Let's do something. Let's go to the computing instance and see what we can do. We choose the project, for example, Claimora Pro, because today nobody is working there.
We can see that, hey, where are our instances? Maybe they are in Claimora Staging.
Okay, there is nothing here.
There should be something that tells me what happened here. Why is it saying that we're spending this amount of money? It’s not a lot, but at the end of the year, it's around €500 for something that doesn't appear to exist.
This new FinOps tool doesn’t show us this information. So, if we go to observability, we’ll have a way to understand the problem.
The reason is simple. When you go here and see that we have a number of consumers, let's look at Claimora Pro and Claimora Stadium. You can see that we have resources here.
The problem is related to serverless VPC.
What is a serverless VPC? A serverless VPC is a component used in Cloud Run to connect something that is in a VPC (Virtual Private Cloud) with internal resources in Google Cloud.
For example, in our case, as we saw in another article, we want to connect our Cloud Run to Cloud SQL. To do that, both Cloud SQL and Cloud Run need to communicate through the internal VPC. This requires a default VPC to talk to each other.
To achieve this, we use Cloud Run's serverless VPC, which creates hidden compute instances inside the VPC network to enable communication between Cloud Run and the instances.
We are spending €500 annually to enable this internal communication. An alternative is to communicate externally using a public IP in our Cloud SQL. Since it's within Google's network, the traffic is internal, not via the public internet, saving costs.
There's a new feature called Directly to VPC (DTV), which does not use instances and is both cheaper and faster.
To use it, let’s go to our project in Cloud Run. In the Claimora instance, we edit the settings, go to networking, and switch from serverless VPC to DTV. We can then select the appropriate network.
Now, if we go to the VPC, open the subnets, and select the correct one (e.g., 132.00.20), we configure it to use this network and deploy. This tells Cloud Run to use the new DTV method, saving us €500 annually.
Even though Google's billing doesn't show this, it’s important to dig internally because there are still hidden expenses in Google Cloud. Unless you know what you're doing, it’s challenging to identify and reduce these costs.
Cloud infrastructure costs can quickly spiral out of control, leaving you with unexpected expenses. That’s why we’re offering a Free Cloud Cost Audit — to help companies uncover hidden inefficiencies and optimize their cloud spending. Our goal is simple: empower you with actionable insights so you can take control of your cloud budget.
Here's the same article in video form for your convenience:
Top comments (0)