# How I Cut Cloud Costs by 40%: Real Optimization Strategies That Work

> Practical cloud cost optimization techniques from actual production deployments — rightsizing, committed use discounts, storage tiering, and FinOps habits that stick.

URL: https://www.matthewswong.com/en/blog/cloud-cost-optimization/

- Author: Matthews Wong (https://www.matthewswong.com/en/about/)
- Published: 2025-06-10
- Updated: 2026-10-17
- Category: DevOps

On a growing project, cloud bills can easily grow faster than the revenue from the work running on that infrastructure. A single GCP project for an ERP integration can cost more than double what was budgeted. After a systematic review, the bill can often come down substantially without any performance degradation. The strategies are not exotic — they are basic hygiene that nobody has time to apply when projects are in rapid development. This guide covers what to do and in what order.

## Start with Visibility: You Can't Optimize What You Can't See

The first step is not optimization — it's measurement. Enable billing export to BigQuery in every GCP project and set up a dashboard in Looker Studio (free) that shows daily spend by service, resource, and label. Without this visibility, optimization is guesswork. On DigitalOcean, the billing overview is simpler but set up spending alerts via the notification settings. The goal of this step is to find the top 3 cost drivers — in our case, Cloud SQL (40%), Compute Engine (35%), and Cloud Storage (15%) accounted for 90% of the bill. Fix those three before touching anything else.

### Resource Tagging for Cost Allocation

Apply labels to every GCP resource: project, environment, team, and service. Without labels, your BigQuery billing export shows you costs by service but not by which team or feature is driving them. With labels, you can run queries like 'show me all costs for resources labeled service=invoice-processor in the last 30 days.' This granularity is essential for chargeback to clients and for identifying which internal services are cost outliers. Organizations implementing proper tagging report 25-40% cost reduction simply from the visibility it enables — teams change behavior when they can see what they're spending.

### Rightsizing: The Biggest Win

In development, we provision VMs with generous specs to avoid performance issues during testing. Those specs often persist unchanged into production, even when the actual workload is light. GCP's Active Assist provides rightsizing recommendations in the Compute Engine console — check it monthly. In my case, three e2-standard-4 instances (4 vCPU, 16GB RAM) running at average 15% CPU utilization were candidates to downsize to e2-standard-2. The switch saved $45/month with zero user-facing impact. Cloud SQL is even more impactful — db-custom-4-16384 running at 20% CPU and 30% RAM is a $80/month savings if you downsize to db-custom-2-8192.

> From my experience: the highest-leverage optimization on GCP is Committed Use Discounts (CUDs) for resources you know you'll run for at least 12 months. A 1-year CUD on a Cloud SQL db-custom-4-16384 instance saves approximately 37% compared to on-demand pricing — that's often $60-100/month saved on a single database instance. Purchase CUDs only after rightsizing, because a CUD locks you into a specific resource type for 12 months. Rightsize first, then commit.

## Compute Optimization Strategies

For batch processing and non-critical background jobs, Spot VMs (preemptible on GCP) offer 60-91% discounts compared to on-demand prices. The trade-off is that Spot VMs can be terminated with 30 seconds notice. For fault-tolerant workloads — thumbnail generators, batch report jobs, data export tasks — this is an excellent trade. Design these workloads to checkpoint progress and restart gracefully. Running PDF report generation and data export jobs on Spot VMs instead of on-demand instances is a typical place to start saving.

### Scheduling Non-Production Environments

Development and staging environments don't need to run 24/7. A Cloud Scheduler job that starts GCP instances at 8 AM Jakarta time and stops them at 8 PM saves 50% of compute costs for those environments immediately. For Cloud SQL in non-production environments, enable the automatic storage increase feature but downsize the machine type significantly — dev/staging databases rarely need more than db-custom-2-4096. Implement instance scheduling with a simple Cloud Function triggered by Cloud Scheduler for start/stop operations.

> **Don't cut costs by reducing backup retention**

> When I was optimizing our Cloud SQL costs, I noticed that automated backup retention was set to 30 days on all instances including dev. The dev instance backup costs added $8/month. I was tempted to reduce dev backup retention to 1 day to save costs — but our dev environment sometimes contains real data snapshots from production (for debugging), which means losing the ability to recover a dev database could cause real data loss. The lesson: optimize compute and storage tiers aggressively, but be conservative with backup and recovery configuration. The cost of a data recovery incident far exceeds the savings from minimal backup retention.

## Storage Optimization: Tiers and Lifecycle Policies

GCP Cloud Storage has four storage classes: Standard, Nearline, Coldline, and Archive. Standard costs $0.02/GB/month; Archive costs $0.0012/GB/month — 16x cheaper. But Archive has a 365-day minimum storage duration and $0.05/GB retrieval cost. Implement lifecycle policies that automatically transition objects: move log files to Nearline after 30 days, Coldline after 90 days, and Archive after 365 days. For a bucket storing 500GB of logs, this lifecycle policy reduces monthly storage costs from $10 to under $2. The GCP console's lifecycle rule editor makes this a 5-minute task.

## Network and Egress Cost Reduction

GCP charges for data leaving a region — $0.085/GB for Asia region egress to internet. If your application serves 50GB/day of images or file downloads, that's $127/month in egress alone. Solutions: use a CDN (Cloud CDN or Cloudflare in front of GCP) to cache static assets at the edge, reducing origin egress by 60-80%. Place Cloud Storage buckets and application servers in the same region to avoid inter-region transfer costs. Use Private Google Access for services communicating within GCP to avoid public IP routing charges.

## FinOps as a Culture, Not a One-Time Project

The 43% cost reduction I achieved was not a one-time fix — it's an ongoing practice. I now review cloud bills weekly, set budget alerts at 80% of expected monthly spend, and have a standing item in our monthly team meeting for cloud cost review. The discipline of FinOps — making cloud cost a shared team responsibility rather than something only DevOps thinks about — is what sustains savings over time. For Indonesian companies working with clients who pay in IDR, predictable and controlled cloud costs are essential for project profitability, especially when GCP prices are in USD and the IDR/USD rate fluctuates.

## Sources & Further Reading

- Google Cloud — Active Assist Recommender — https://cloud.google.com/recommender/docs/recommenders
- Ternary — Top 15 Cloud Cost Optimization Strategies in 2025 — https://ternary.app/blog/cloud-cost-optimization-strategies/
- nOps — 20 Best Cloud Cost Optimization Strategies — https://www.nops.io/blog/cloud-cost-optimization/

## Source links

- https://cloud.google.com/recommender/docs/recommenders
- https://www.nops.io/blog/cloud-cost-optimization/

## FAQ

### What was the first step taken before any optimization work began?

The first step was measurement, not optimization. Billing export to BigQuery was enabled on every GCP project and a free Looker Studio dashboard was set up to show daily spend by service, resource, and label. This visibility revealed that Cloud SQL (40%), Compute Engine (35%), and Cloud Storage (15%) accounted for 90% of the bill — making it clear where to focus.

### Why must rightsizing always happen before purchasing Committed Use Discounts?

A Committed Use Discount locks you into a specific resource type for 12 months. If you commit to a db-custom-4-16384 instance before rightsizing and later discover you only need db-custom-2-8192, you forfeit the potential savings and are stuck paying for capacity you don't use. The correct order is: rightsize first, then commit.

### Which workloads are good candidates for Spot VMs, and what is the key design requirement?

Spot VMs are well-suited for fault-tolerant, non-critical background jobs such as thumbnail generation, batch report creation, and data export tasks. The key design requirement is that these workloads must checkpoint their progress and restart gracefully, because Spot VMs can be terminated with only 30 seconds' notice.

### What is the one cost area the post explicitly warns against cutting aggressively?

Backup retention. Although reducing dev instance backup retention from 30 days to 1 day would have saved $8/month, the post warns against it because dev environments sometimes contain real data snapshots from production for debugging purposes. The cost of a data recovery incident far exceeds the savings from minimal backup retention.

### How does treating FinOps as a culture rather than a one-time project sustain savings over time?

Sustained savings come from making cloud cost a shared team responsibility rather than a DevOps-only concern. Practical habits include reviewing cloud bills weekly, setting budget alerts at 80% of expected monthly spend, and holding a standing cloud cost review item in monthly team meetings. This discipline is especially important for Indonesian companies billed in USD while earning revenue in IDR.

---

- HTML version: https://www.matthewswong.com/en/blog/cloud-cost-optimization/
- Bahasa Indonesia: https://www.matthewswong.com/id/blog/cloud-cost-optimization/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json