Recommendations for GCP

CloudZero analyzes your GCP environment and generates recommendations that identify specific resources where you can reduce costs or improve efficiency. Each recommendation includes the affected resources, the estimated savings, and guidance on how to address it.

For details on how to work with recommendations in the CloudZero UI (search, filter, group, take action), see Recommendations.

What you need

Most GCP recommendations require a GCP Recommender connection. The table below marks which recommendations require this prerequisite. Recommendations marked "CloudZero" use CloudZero's own billing data analysis and require no additional GCP configuration.

Overview of GCP Recommendations

Compute

Databases

Storage

Compute

Delete Idle Address

CloudZero has identified Google Compute Engine external IP addresses that appear to be idle (reserved but not attached to any running resource). Unused reserved external IPs can incur ongoing charges, so releasing them can reduce spend with low operational risk when validated.

Google's Recommender flags idle IP addresses using association/usage signals. Treat these as starting points and confirm ownership and dependencies before releasing.

How to address this

• Verify the IP is truly unused: Confirm it is not attached to a VM NIC, forwarding rule, or load balancer configuration (and isn't being used by any active service)
• Check dependencies before release: Review DNS records, firewall allowlists, application configs, and documentation that reference the IP
• Validate ownership/intent: Confirm the IP is not reserved for disaster recovery, cutovers, or upcoming migrations; coordinate with service owners (especially for prod)
• Release safely: Prefer non-prod validation first, schedule changes during maintenance windows, and monitor after release
• Understand recovery limitations: Once released, the same IP address is not recoverable; plan updates to any references accordingly

For how to view, apply, or manage these recommendations in Google Cloud, refer to Google's documentation on viewing and applying idle resources recommendations.

---

Delete Idle Disk

CloudZero has identified Google Compute Engine persistent disks that are blank and appear to be idle and safe candidates for cleanup. Removing idle disks can reduce ongoing storage costs without impacting workloads.

Google recommends deleting this persistent disk based on low utilization and age. This recommendation suggests direct deletion without creating a snapshot first, typically for disks with minimal or no value for recovery.

How to address this

• Confirm it's truly idle: Check the disk isn't attached to instances, referenced in instance templates, or part of instance groups
• Verify no data loss risk: Ensure the disk contains no data needed for recovery, compliance, or business operations
• Check ownership: Coordinate with the application team, especially in production
• Review tags and policies: Confirm deletion aligns with organizational retention and governance requirements
• Test in dev/staging first
• Schedule deletions during maintenance windows
• Monitor dependent applications after removal

For more details, refer to Google's documentation on viewing and applying idle resources recommendations.

---

Delete Idle Image

CloudZero has identified Google Compute Engine custom images that appear to be idle and safe candidates for cleanup. Unused custom images can incur ongoing storage costs, so deleting them can reduce spend with low operational risk when validated.

Google's Recommender (google.compute.image.IdleResourceRecommender, Sub-Type: DELETE_IMAGE) flags idle custom images using utilization and age signals. Treat these as starting points and confirm ownership and dependencies before deleting.

How to address this

• Verify the image is truly unused: Confirm it is not referenced in instance templates, used by any active instances, or required for disaster recovery or future deployments
• Check dependencies before deletion: Review instance templates, managed instance groups, and any automation or documentation that reference the image
• Validate ownership/intent: Confirm the image is not reserved for upcoming migrations, rollbacks, or compliance requirements; coordinate with service owners (especially for prod)
• Review image lineage: If the image was created from a snapshot or another image, ensure deletion won't impact related resources or recovery workflows
• Delete safely: Prefer non-prod validation first, schedule changes during maintenance windows, and monitor after deletion
• Understand recovery limitations: Once deleted, the same image cannot be recovered; plan updates to any references accordingly and ensure backups exist if needed

For how to view, apply, or manage these recommendations in Google Cloud, refer to Google's documentation on deleting idle custom images.

---

Google Compute Engine Instance Rightsizing

CloudZero has identified Google Compute Engine instances that are over-provisioned and can be rightsized to better match your actual workload requirements. These instances are running with more CPU, memory, or storage than needed, resulting in unnecessary costs that can add up significantly over time.

Google's Machine Type Recommender analyzes your instance utilization patterns and suggests more cost-effective machine types that can deliver the same performance at a lower price point. By rightsizing these instances, you can typically achieve 20-40% cost savings while maintaining or even improving performance.

How to address this

• Review the suggested machine types: Google's recommendations are based on your actual usage patterns over the past 30 days
• Test in a non-production environment first: Validate that the recommended machine type meets your application's performance requirements
• Consider your workload patterns: Ensure the new machine type can handle peak loads and any seasonal variations
• Monitor performance after changes: Use Cloud Monitoring to verify that rightsizing doesn't impact application performance
• Apply changes during maintenance windows: Plan instance type changes to minimize disruption to running applications

Rightsizing is particularly effective for development, testing, and batch processing workloads where resource utilization patterns are more predictable.

---

Snapshot and Delete Idle Disk

CloudZero has identified Google Compute Engine persistent disks and snapshots that appear to be idle and safe candidates for cleanup. Removing idle disks or outdated snapshots can reduce ongoing storage costs without impacting workloads.

Google's Recommender highlights cleanup opportunities using utilization and age signals. Treat these as starting points and validate with service owners and policies before acting.

How to address this

• Validate usage: Ensure disks aren't attached or used by instance groups, templates, or backup workflows
• Review snapshot lineage: Confirm remaining snapshots still meet restore/RPO/RTO and compliance needs
• Check ownership and labels: Verify tags and coordinate with application owners, especially for prod
• Mind encryption and retention: Align cleanup with CMEK and organizational retention requirements
• Change safely: Test in non-prod, schedule during maintenance windows, and monitor afterward

For how to view, apply, or manage recommendations in Google Cloud, refer to Google's Recommender documentation.

---

Stop Idle VM Instance

CloudZero has identified Google Compute Engine VM instances that appear to be idle and have not been actively used over recent days. These idle VMs continue to incur compute charges even when not performing meaningful work, making them prime candidates for cost optimization.

Google's Idle VM Recommender analyzes instance activity patterns over 1 to 14 days, including CPU utilization, network traffic, and disk I/O, to identify VMs that can be safely stopped. Stopping idle instances can significantly reduce your compute bill while preserving the instance configuration for future use.

How to address this

• Verify the VM is truly idle: Review the instance's actual usage patterns, scheduled jobs, and application dependencies to confirm it's safe to stop
• Check for critical workloads: Ensure the VM isn't running background processes, cron jobs, monitoring agents, or serving as a jump host
• Consider stopped VM costs: Stopped VMs still incur charges for attached persistent disks and reserved IP addresses
• Test in non-production first: Validate the impact of stopping VMs in dev/test environments before applying to production
• Create a snapshot or backup: For added safety, create a snapshot before stopping instances that need recovery options
• Coordinate with teams: Confirm with service owners and stakeholders, especially for shared or production resources
• Plan restart procedures: Document how to restart the VM and verify services come back online properly

Stopping a VM preserves its configuration, attached disks, and metadata, making it easy to restart when needed. For VMs that will never be used again, consider deletion instead to eliminate all associated costs. For more details, refer to Google's documentation on viewing and applying idle VM recommendations.

Databases

Google Cloud SQL Resize Over-Provisioned Instances

CloudZero has identified Google Cloud SQL instances that are over-provisioned and can be resized to better match your actual workload requirements. These instances are running with more CPU and memory than needed, resulting in unnecessary costs.

Google's Overprovisioned Recommender analyzes CPU and memory utilization patterns over the past 30 days for primary instances older than 30 days. It identifies instances with low peak utilization and suggests resizing to more cost-effective machine types. Recommendations are generated daily for instances with estimated monthly savings of at least $10.

How to address this

• Review the suggested machine types: Google's recommendations are based on your actual CPU and memory usage patterns over the past 30 days
• Test in a non-production environment first: Validate that the recommended machine type meets your database performance requirements
• Consider workload patterns: Ensure the new machine type can handle peak loads, query complexity, and connection counts
• Monitor performance after changes: Use Cloud Monitoring to verify that resizing doesn't impact database performance or query latency
• Apply changes during maintenance windows: Plan instance resizing to minimize disruption to running applications
• Exclusions: The recommender only analyzes primary instances; read replicas and high availability configurations are excluded

This recommender supports MySQL, PostgreSQL, and SQL Server instances. Resizing is particularly effective for development, testing, and workloads with predictable utilization patterns.

For more details:

• MySQL overprovisioned recommender
• PostgreSQL overprovisioned recommender
• SQL Server overprovisioned recommender

Storage

Disk Snapshots Exceeds Target Threshold

This recommendation identifies when the cost of GCP Compute Engine disk snapshots exceeds 5% of the total Compute Engine disk storage costs. This indicates that there are an excessive number of snapshots.

How to address this

• Reduce the frequency of scheduled snapshots to weekly if the workload allows
• Delete snapshot schedules for workloads that no longer require it
• Shorten the retention policy for auto generated snapshots
  • If you don't set a retention policy, all your auto-generated snapshots are retained indefinitely and incur storage costs until manually deleted
• Update the Source disk deletion policy to ensure snapshots from deleted disks are removed
• Switch the location of snapshots to Regional instead of Multi-Regional when high availability is not necessary
• Remove snapshots older than 90 days

---

Multi-Region Storage Exceeds Target Threshold

This recommendation looks at availability settings for Cloud Storage. By default, buckets are set to the Multi-Region which is the most redundant and the most expensive configuration option offering Cross-geography data access and Cross-region redundancy, ideal for serving content. Reducing availability to Dual-Region or Region can result in savings.

CloudZero has a target threshold of 30%, with remaining buckets set to Dual-Region and Region availability.

How to address this

For the top Multi-Region buckets, evaluate the access patterns and consider changing location type of the buckets.

Bucket location cannot be changed after creation. In order to change the location you must move your data to a bucket in a different location. Check GCP documentation for any costs incurred from moving data between locations.

---

Standard Disk Below Target Threshold

This recommendation looks at usage of Standard Persistent Disk storage. Standard Persistent Disks are a type of disk storage in GCP that is suitable for large data processing workloads that primarily use sequential I/Os and is backed by standard hard disk drives (HDD), providing efficient and reliable block storage for a variety of use cases. Changing your storage option to Standard Persistent Disk can result in cost savings.

If you create a disk in the Google Cloud console, the default disk type is Balanced Persistent Disk. If you create a disk using the gcloud CLI or the Compute Engine API, the default disk type is Standard Persistent Disk.

CloudZero has a target threshold for Standard Persistent Disk of 50%.

How to address this

Optimize costs by evaluating the workload for the highest-cost disks identified and consider whether using a cheaper storage option is appropriate.

Learn more about the different storage options and pricing.

To change the type of an existing Persistent Disk volume, you must migrate your data from the current disk to a new type of disk. A disk's type cannot be directly changed.

Migrating your data to a new type of disk

1. Create a snapshot of the existing disk and use that snapshot to create a disk of the new type.
2. After you create and validate the new disk, delete the snapshot and delete the original disk.

---

Standard Storage Class Exceeds Target Threshold

This recommendation looks at the amount of data kept in the GCP Cloud Storage Standard Class of storage. Standard class is the default and most expensive tier ideally used for frequently accessed data. Moving data that is not frequently accessed to lower Storage classes can result in savings.

CloudZero has a target threshold of 50%, with remaining data being in Nearline, Coldline, Archival storage classes.

How to address this

Consider moving your data to colder storage classes or applying AutoClass.