Google Cloud Platform Cost Optimization: A Complete Guide for Infrastructure Teams

Understanding GCP Billing Fundamentals

Google Cloud Platform charges for compute time, storage capacity, network egress, and API requests. Each service has distinct pricing models: Compute Engine bills per second with a one-minute minimum, Cloud Storage charges monthly based on data volume and storage class, and network egress costs vary by destination region.

The GCP billing console aggregates charges across projects and services. Costs appear as line items grouped by SKU (stock keeping unit), which represents a specific billable resource like 'N1 Standard 4 instance hours' or 'Standard Storage US Multi-region'. Understanding these SKUs is the first step in identifying optimization targets.

Resource labels and project organization form the foundation of cost tracking. Without structured labeling, you cannot attribute costs to specific teams, environments, or applications. Tag resources with environment (production, staging, development), cost-center, and owner labels before attempting optimization.

Auditing Current Resource Usage

Start with the Cost Table report in the billing console. Filter by service and time range to identify the highest-cost resources. Export the report as CSV for detailed analysis offline. Look for patterns: resources running 24/7 that could operate on schedules, dev/test instances sized identically to production, or storage volumes that haven't been accessed in months.

Use the gcloud CLI to list resources programmatically. For Compute Engine, run 'gcloud compute instances list --format=json' to export all instances with their machine types and zones. Cross-reference running hours against actual usage: an n1-standard-4 instance running continuously but averaging 10% CPU utilization is a right-sizing candidate.

Check for orphaned resources that continue billing after their purpose expired. Unattached persistent disks, static IP addresses not assigned to active instances, and load balancers forwarding to deleted backends all incur charges. Query these with 'gcloud compute disks list --filter="-users:*"' and 'gcloud compute addresses list --filter="status:RESERVED"'.

• Review the top 10 line items in the billing report by total cost
• Identify resources tagged as 'development' or 'test' running on production-grade machine types
• Export a full resource inventory with creation dates to find long-running temporary instances
• Check for persistent disks larger than 100GB attached to small instances (potential oversizing)

Right-Sizing Compute Resources

Compute Engine instances sized for peak load waste money during normal operations. GCP provides recommender suggestions based on actual CPU and memory utilization over the past eight days. Access these in the console under Compute Engine > VM instances > Recommendations, or via 'gcloud recommender recommendations list --recommender=google.compute.instance.MachineTypeRecommender'.

Before resizing, verify the recommendation aligns with observed workload patterns. A recommendation to downgrade from n1-standard-4 to n1-standard-2 saves approximately 50% on compute costs, but only if CPU utilization consistently stays below 40% and memory usage remains under 50%. Check Cloud Monitoring metrics for the past 30 days, not just the eight-day recommendation window.

Resizing requires stopping the instance, which causes downtime. Test the procedure on non-production instances first. Create a snapshot before making changes: 'gcloud compute disks snapshot DISK_NAME --snapshot-names=pre-resize-backup'. After resizing, monitor for performance degradation over 48-72 hours. If issues arise, resize back up using the same procedure.

• Only resize instances with sustained utilization below 40% CPU and 50% memory
• Schedule resizing during maintenance windows to avoid service disruption
• Keep the original machine type documented in instance labels for quick rollback
• Use custom machine types when predefined types don't match workload requirements

Implementing Storage Lifecycle Policies

Cloud Storage buckets default to Standard class, which costs more than necessary for infrequently accessed data. Lifecycle management rules automatically transition objects to Nearline (accessed less than once per month), Coldline (accessed less than once per quarter), or Archive (accessed less than once per year) storage classes based on age or last access time.

A typical policy moves objects to Nearline after 30 days and Coldline after 90 days. This reduces storage costs from $0.020/GB/month (Standard US multi-region) to $0.010/GB (Nearline) to $0.004/GB (Coldline). For a 1TB bucket, that's a reduction from $20/month to $4/month for rarely-accessed data.

Define lifecycle policies in JSON and apply them with 'gsutil lifecycle set lifecycle.json gs://bucket-name'. Include deletion rules for temporary data: logs older than 90 days, build artifacts older than 30 days, or database backups older than one year. Always test policies on a non-production bucket first to ensure deletion rules don't remove needed data.

• Identify buckets over 100GB without lifecycle policies using 'gsutil du -s gs://*'
• Start conservative: transition to Nearline after 90 days, evaluate for 30 days before tightening
• Exclude buckets containing active databases or frequently-accessed application assets
• Set object versioning retention before enabling deletion rules to prevent accidental data loss

Purchasing Committed Use Discounts

Committed use discounts (CUDs) provide savings up to 57% for workloads with predictable resource needs. You commit to a minimum spend on vCPUs and memory for one or three years in exchange for lower per-hour rates. A one-year commitment for 10 vCPUs and 40GB memory in us-central1 costs approximately $270/month compared to $450/month on-demand.

Calculate commitment size from baseline usage, not peak capacity. Review the past 90 days of Compute Engine usage to find the consistent minimum. If you run 15 instances averaging 60 vCPUs total but scale down to 40 vCPUs overnight and on weekends, commit to 40 vCPUs, not 60. Over-committing locks you into paying for unused capacity.

Committed use discounts apply automatically to matching resources within the commitment region and machine family. For regional flexibility, purchase commitments in multiple regions based on actual workload distribution. Use the GCP pricing calculator to model savings before purchasing. Note that commitments cannot be canceled; choose one-year terms initially to maintain flexibility.

Setting Up Budget Alerts and Monitoring

Budget alerts prevent cost overruns by sending notifications when spending approaches defined thresholds. Create budgets in the billing console with alerts at 50%, 75%, 90%, and 100% of the monthly target. Route alerts to email, Slack, or PagerDuty depending on urgency and team workflow.

Programmatic budget alerts enable automated responses. Configure Pub/Sub notifications to trigger Cloud Functions that stop non-production instances or send detailed cost breakdowns. A basic function checks if the alert source is a development project and stops all instances when the budget reaches 90%.

Use Cloud Monitoring dashboards to track cost trends over time. Create charts showing daily spend by project, service, and SKU. Set up anomaly detection alerts for sudden cost increases: a 50% day-over-day spike in Compute Engine costs often indicates an autoscaling misconfiguration or a runaway batch job. Regular monitoring catches issues before they compound.

• Set budget amounts 10-15% above historical monthly averages to account for growth
• Create separate budgets for production and non-production projects
• Include forecast alerts to catch increasing trends before hitting thresholds
• Review alert thresholds quarterly as baseline usage changes

Scheduling Non-Production Resources

Development and staging environments rarely need to run outside business hours. Stopping these instances overnight and on weekends eliminates 70% of runtime hours, translating directly to 70% cost savings on those resources. A development instance costing $150/month drops to $45/month with a business-hours-only schedule.

Implement scheduling with instance schedules (a GCP feature) or Cloud Scheduler with Cloud Functions. Instance schedules attach directly to VM instances and define start/stop times in the instance's time zone. Create a schedule named 'business-hours' that starts instances at 8 AM and stops them at 6 PM Monday through Friday.

Test scheduling on a single non-critical instance before rolling out broadly. Verify that applications handle unexpected stops gracefully and that startup scripts run correctly when instances restart. Document the schedule in instance labels and project documentation so team members know when resources are available.