The Zero-Cost Cloud Engineer: The $300 Dilemma and Provisioning the Free VM

#gcp #devops #architecture #springboot

The Zero-Cost Cloud Engineer: Mastering GCP on the Always Free Tier

Part 1: The $300 Dilemma and Provisioning the Free VM

It’s a tale as old as time for developers: You sign up for Google Cloud Platform (GCP). You see that glorious "$300 Free Trial Credit" banner. You think of all the massive, distributed microservice architectures you are going to build over the weekend to learn the cloud.

Then, life happens. Work gets busy. You blink, and 90 days have passed. You log back in, and your $300 credit has silently expired. You didn't even have time to spin up a single database.

Don't panic. This is actually a blessing in disguise.

When you have $300 of "funny money," you don't learn how to architect systems efficiently. You over-provision RAM. You leave databases running overnight. You accidentally pay for public IP addresses you don't need.

By losing the credit, you are now forced to explore the "Always Free" Tier. This tier never expires, but it imposes strict limits on disk space, memory, and network usage. Building a functioning ecosystem inside these constraints makes you a significantly better Cloud Engineer because you are forced to understand exactly what every resource costs and how to optimize it.

Step 1: Designing the Zero-Cost VM

Our entry point to the cloud is a core compute instance (a VM). However, if you simply click "Create VM" and accept the defaults, Google will aggressively charge you.

To stay 100% free, your VM must strictly adhere to these rules:

Machine Type: e2-micro (2 vCPUs, 1 GB memory)
Region: Must be in an eligible US region like us-east1, us-west1, or us-central1.
Disk: 30 GB standard persistent disk (CRITICAL: Ensure this is not an SSD balanced disk, which is the default in the UI and will immediately start charging you hourly!).

Step 2: Warding Off the Hidden Costs

There are two major traps that catch beginners and start generating bills on the very first day:

The Default SSD Trap: When you create a VM, GCP defaults the boot disk to a "Balanced persistent disk" (SSD). The Always Free tier only covers a basic "Standard persistent disk." If you don't manually change this dropdown, you will be billed.
The External IP Trap: By default, GCP assigns your new VM an External IP Address (a public IPv4 address). As of 2024, Google charges for all public IPv4 addresses, regardless of whether you are actually serving web traffic. Furthermore, having a public IP means bots will immediately start probing your tiny 1GB VM, eating up your precious CPU cycles.

The Golden Rule: We prefer the GCP graphical UI over command-line interfaces for provisioning infrastructure as beginners. CLI defaults can easily sneak in public IPs if you aren't paying close attention.

Step 3: Preparing for Java 25 (The Startup Script Catch-22)

To run a Spring Boot application, our VM needs Java. The most efficient way to install software on a new VM is using a Startup Script. We want to use Debian 13 (Trixie) and install the latest Java 25 (LTS).

Here is the exact startup script we need:

#!/bin/bash
# 1. Set up 2GB of swap space (crucial for 1GB VMs)
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab

# 2. Install dependencies & Add Adoptium repository
apt-get update
apt-get install -y wget apt-transport-https gnupg
wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | tee /etc/apt/trusted.gpg.d/adoptium.gpg > /dev/null
echo "deb https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list

# 3. Install Java 25 (LTS)
apt-get update
apt-get install -y temurin-25-jdk

🚨 The Catch-22: If we provision the VM with No External IP from the start, this script will immediately fail. The VM won't be able to reach deb.debian.org or packages.adoptium.net to download Java.

The Workaround: We will provision the VM with a temporary External IP, let the script run, and then instantly delete the IP so we don't get billed for it.

Step 4: Provisioning via the GCP Console

Here is how to safely provision your VM and apply the workaround:

Open the GCP Console.
Navigate to Compute Engine > VM instances and click Create Instance.
Name your instance (e.g., free-tier-vm).
Select us-east1 as your region.
In the Machine Configuration, change the series to E2 and the machine type to e2-micro.
Scroll down to the Boot Disk section. Click Change. Select the Debian 13 image, ensure the disk type is "Standard Persistent Disk", and set the size to 30 GB.
Expand the Advanced Options, then expand Management.
In the Automation > Startup script text box, paste the Bash script from Step 3.
Temporarily leave the networking settings alone (let it assign a public IPv4 address).
Click Create at the bottom.

Wait roughly 2 minutes for the VM to fully boot and the backend script to finish installing Java.

Step 5: Securing the Island (Stripping the IP)

Now, we must immediately lock down the VM to prevent getting billed for the public IP.

Go back to your VM's details page.
Click EDIT at the top top.
Scroll down to Network interfaces and click the default network.
Under External IPv4 address, change it from "Ephemeral" to None.
Click Save.

Your VM is now a perfectly secure, completely free, Java 25-equipped island.

Step 6: Accessing the Disconnected Island

How do you, the developer, access a VM with no public IP?

If you try to use standard terminal SSH on your laptop (ssh user@<ip>), it will fail because there is no public IP to hit.

Instead, go back to your VM instances page in the GCP Console. Next to your new VM, click the SSH button.

A new browser window will open, and a terminal will appear. You are in!

Connecting via your Local Terminal
If you prefer to work from your local laptop terminal instead of a browser pop-up, Google provides a seamless command that leverages this exact same secure tunnel via the gcloud CLI:

gcloud compute ssh free-tier-vm --zone=<YOUR_REGION> --tunnel-through-iap

(Replace <YOUR_REGION> with the zone your VM is in, e.g., us-east1-b).

How does this magic work?
Whether using the browser button or the gcloud ssh command, Google is using a free service under the hood called Identity-Aware Proxy (IAP). It securely tunnels your traffic through Google's internal backbone directly into your private VM, all without exposing the VM to the public internet.

You now have a perfectly secure, absolutely free cloud server.

But having a running VM is just the "entry ticket." To truly learn Google Cloud, you should use this isolated VM as a secure hub to explore the other "Always Free" services natively, building out a production-like ecosystem without ever generating a monthly bill.

In Part 2, we will use our new hub to solve absolute necessity: Observability, and we'll learn exactly why your Java applications seem to magically hide their logs when deployed to a secure cloud VM.