DEV Community

박준희
박준희

Posted on • Originally published at aicoreutility.com

Cloud Build Cost Skyrockets: How a Single 'machineType' Line Killed My Free Tier

#cloudbuild #freetier #costoptimization #cicd

Cloud Build Cost Skyrockets: How a Single 'machineType' Line Killed My Free Tier

As a solo developer running a full AI product on a single, small VM, every dollar counts. I'm constantly monitoring costs and looking for ways to optimize. Recently, I noticed a massive spike in my Google Cloud Build costs, jumping from almost nothing to around ₩36,000 (roughly $30 USD) in a matter of days. This was alarming, especially since my goal is to keep infrastructure costs as low as possible.

The trigger for this cost surge was a commit made on June 7th, intended to speed up deployments. The commit message read: "Accelerate deployment (20→8 minutes)". It seemed like a good change, but it came with a hidden, devastating consequence.

Upon investigating the GCP billing report and correlating it with my commit history, I pinpointed the exact culprit: the addition of a single line in my cloudbuild.yaml file: machineType: E2_HIGHCPU_8.

The Root Cause: Free Tier Annihilation

This single line did two things simultaneously, both contributing to the massive cost increase:

  1. Free Tier Loss: Cloud Build offers a generous free tier of 2,500 build minutes per month. However, specifying a custom machineType (like E2_HIGHCPU_8) completely disables this free tier. Suddenly, every minute of every build was billable.
  2. Increased Unit Cost: The default machine type used when no machineType is specified is typically an E2-medium, which falls within the free tier. When you opt for a custom, more powerful machine like E2_HIGHCPU_8, the per-minute cost is significantly higher – about 8 times more expensive than the free tier's effective rate.

The math was stark. Between June 7th and the time I caught the issue, there were 168 builds. Each build averaged about 8.5 minutes. This resulted in approximately 1,420 billable minutes. At the higher rate (around $0.016/minute), this quickly added up to roughly ₩34,750, matching the observed ₩36,290 bill almost exactly.

Before this change, from June 4th to June 6th, my builds were using the default, free-tier-eligible machine. During that period, 21 builds ran, but they were all within the free tier, resulting in near-zero cost for Cloud Build.

The Fix: Reverting to the Free Tier

The solution, thankfully, was straightforward: remove the offending line. I created a test tag, :cost-test-medium, to verify that the default machine (an e2-medium with 4GB RAM) could still handle the build without issues. I also ensured my Dockerfile had sufficient memory allocation via NODE_OPTIONS=--max-old-space-size=3072.

The test build using the default machine took 11 minutes and 54 seconds, successfully completing without Out-Of-Memory errors. While this was about 3.5 minutes longer than the 8.5-minute builds on the 8-core machine, it was a small price to pay to regain the free tier and eliminate the exorbitant costs.

I then committed the fix (commit f18a97c), removing the machineType line from cloudbuild.yaml and keeping only the necessary logging options. With approximately 150 builds per month expected, the total minutes would be around 1,800, well within the 2,500-minute free tier limit. This put my Cloud Build costs back on track to be close to ₩0 per month.

I added a prominent warning comment in the cloudbuild.yaml file:

# WARNING: Do NOT specify machineType here. 
# Doing so disables the Cloud Build free tier (2,500 minutes/month) 
# and incurs significant costs. 
# Optimize build frequency, not machine power, for cost savings.
Enter fullscreen mode Exit fullscreen mode

Lessons Learned: The Cost of a Single Line

This incident was a harsh reminder that even a single line of configuration can have a massive impact, especially when dealing with cloud infrastructure and free tiers. The key takeaways for me were:

  • Respect the Free Tier: Always be aware of the conditions that might disqualify you from free tiers. Specifying custom hardware is a common pitfall.
  • Prioritize Build Frequency Over Machine Power: For cost optimization, it's usually better to have more, shorter builds on free-tier-eligible hardware than fewer, longer builds on expensive custom machines.
  • Verify with Test Tags: Using specific test tags (like :cost-test-medium) is crucial for validating changes without impacting production or incurring unexpected costs.
  • Monitor Infrastructure Costs Actively: While I had general cost monitoring, I didn't have a specific alert for Cloud Build costs. The new infrastructure monitoring section in my admin panel (as documented in another post) would have caught this sooner.

This experience reinforced the importance of meticulous configuration management and continuous cost vigilance. It's a scar, but one that will hopefully prevent similar costly mistakes in the future.

...building aicoreutility.com in the open... aicoreutility.com

Top comments (0)