Five more ways to save on Compute Engine costs

In previous post I shared with you five tips on how to save money when using Google Compute Engine. We were just getting started. Here are five more ways to save!

1. Let go of external IPs

Compute instances, by default, when created with gcloud or in the Google Cloud console come with an ephemeral external IP address. Sometimes it’s just what you need to set up a quick prototype or to host a single-VM instance of some service using Dynamic DNS. However, if you use VMs together with a load balancer, it’s worth asking whether you still want them to have an external IP. After all, clients talk to your services through your load balancer’s public IP address. On the other hand, it can be very useful to be able to reach out to the internet, for example to communicate with third-party services; out of the box, a virtual machine without an external IP cannot reach the internet. 

Luckily, Cloud NAT solves this problem with Public NAT configuration. Cloud NAT does what many internet service providers do for their customers: provide network address translation, hiding multiple machines behind a single external IP address. From the outside, it looks like all requests are coming from this single IP, while in reality, there are multiple different machines making those requests. Side note: This works for GKE as well.

If your fleet contains only a couple virtual machines, you probably won’t notice much of a difference on your monthly invoice by turning off external IPs. However, the savings grow linearly with the size of your fleet. And there are two other benefits to using Cloud NAT: you increase security (your virtual machines are not exposed to the internet) and you don’t consume the IP address quota in your project.

2. Automate turning machines on and off

Cron (the Unix job scheduling utility) is a pillar of many automated, cyclic, batch processing systems. It allows you to schedule actions in a regular pattern without worrying about triggering them manually. Virtual machines configured using cron wait for the right time to start a time-consuming task. For a couple of hours, the machine is very busy working on its task, but once the job is done, the VM just sits there, waiting for the cron job to start again. In other words, for a couple hours, the VM generates value for the company, while for the rest of the day, it’s generating cost. Wouldn’t it be great if you could get rid of the “generating cost” part? Turns out, you can — sort of.

A VM generates cost when it consumes resources like vCPUs, memory, disks, accelerators (GPUs and TPUs) or external IPs. When it’s powered on, it uses all those resources, but when it’s turned off, the only cost that it incurs is for the disk (assuming you don’t use static external IP here). It’s natural for a computer that’s not being used to be turned off (to save electricity and save the planet). Unfortunately, a machine that’s turned off cannot start cron jobs, unless… you can use a cron-like system  to start the machine instead! 

What do I mean by that? Turns out you can create a cron-like schedule in your project to start your machine for you. Then, you just need to change your cron-based process to autostart at machine startup, and tada! You have the same functionality (nightly builds/nightly processing), but without wasting money on keeping the VM running when you don’t need it. When your nightly process is finished, the machine can turn itself off from the inside, and wait in that state until the next time it’s needed.

3. Consider using Spot VMs

Spot VMs are a type of preemptible instances that can save you significant costs (they’re up to 90% cheaper than standard VMs). Unlike regular VMs, which run continuously, Spot VMs run on spare capacity in Google Cloud and are subject to preemption. That means that if Google needs the resources back, your Spot VM will be terminated with 30-seconds notice.

But don't let that scare you away! Spot VMs are ideal for batch processing, stateless workloads, and other workloads that can tolerate interruption. And because they're priced so much lower than regular VMs, you can save a lot on your cloud computing costs.

One of the best things about Spot VMs is that you can use them just like regular VMs. You can create them using the same tools and APIs, and they can run the same operating systems and applications. The only difference is that you pay less for them (and they can be turned off with minimum notice). Switching your Managed Instance Group (stateless) or Google Kubernetes Engine (GKE) instances to Spot VMs is almost seamless, as those two systems simply recreate machines that get preempted for you.

4. Compare regions, find the best deal

Hosting your software on Google Cloud comes with many advantages, one of which is the freedom to pick the physical location of the machines that run your services. Your choice in location may be impacted by aspects of your business, such as compliance with local laws, feature availability, and proximity to your user base (and latency to services). 

Another factor is pricing. If you inspect the Compute pricing page, you can easily compare how much the products you use cost in different regions. In some cases, where latency or sovereignty aren’t the key variable, it makes a lot of sense to pick a region that’s more cost effective especially when regions with different pricing are near each other. To help you pick the ideal regions, we also have our Google Cloud region picker which helps you balance all of these variables. 

5. Introduce automated time limits

If you forget about your VMs, there’s a new feature that can help you save money: the ability to set a time limit after which your VMs are turned off or deleted.  

Currently in preview, this can be useful in various scenarios. Imagine:

• You have a long running operation. If it runs over a certain number of hours, you can set the VM to stop automatically after that time so that you don't waste money and can revisit and debug rather than leaving it running. 

• Your team needs to run experiments. You can set up temporary VMs that stop after a specific duration, ensuring that no one has to remember to terminate them manually.

• Spiky usage. When you need additional compute power for a limited time (the Christmas season, for example), you can create VMs that will automatically be deleted on a given date, and free up the resources.

The more you think about  it, the more uses you’ll find for this feature. You may not always be able to use it, but it's a good thing to keep in mind when setting up your daily infrastructure operations. 

Last words

I've covered a lot of ground, talking about various ways to optimize your spending on Google Cloud. From fine-tuning your disk sizes to leveraging committed use discounts, exploring Cloud NAT, scheduling your instances, and utilizing Spot VMs, there's no lack of ways to save money.

Remember, keeping an eye on your cloud spending is like managing your personal finances: every penny counts! So, take the time to explore these strategies and make the most of your cloud investment.

May your projects be successful, and may your cloud bills be manageable. Happy optimizing!