Applying Google Cloud Recommenders to Optimize Operations

Implement and Validate Cost Optimization Actions is the FinOps practice of turning cost findings into applied changes and then proving the savings. Recommender (opens in a new tab) generates findings from cost, performance, and utilization signals, while the operator decides, applies, and verifies each change. Validation requires separating true savings opportunities from utilization signals and tracking spend after the change with cost reports, billing alerts, and the Recommender API. The ordered workflow is first remove idle waste, then rightsize what remains, and only then commit stable usage to discounted pricing in the FinOps hub (opens in a new tab).

1.1Cost Recommender Actions for Rightsizing and Idle Cleanup

Cost recommender actions map an oversized, idle, or misconfigured resource to a specific remediation. The finding flows from the monitored resource to the recommender, which returns a recommendation entity that names the target in its resource field as //API_NAME/RESOURCE_PATH, such as a Compute Engine VM path. The operator then applies the change with the service-specific tool, such as Compute Engine commands for a VM resize or Cloud SQL edit for an instance resize, because Recommender itself does not mutate the resource.

1.2Decision Criteria for Idle and Overprovisioned Cloud SQL Instances

Idle and overprovisioned decisions for Cloud SQL depend on observation windows, savings thresholds, and safety review. The Cloud SQL overprovisioned recommender analyzes primary instances older than 30 days using CPU (database/cpu/utilization) and memory (database/memory/utilization) peaks over the last 30 days, excludes read replicas and high-availability (HA) instances, refreshes every 24 hours, and only generates a recommendation when estimated monthly savings are greater than or equal to $10. The Cloud SQL idle recommender emits insight LOW_ACTIVITY with recommendation SHUTDOWN_INSTANCE when activity stays low through the observation period, and stopping suspends instance charges while storage and IP address charges continue. Because thresholds are conservative and larger sizes can increase operational latency, the flagged instance must be reviewed with the owning team and in-context charts before downsizing, stopping with a prior backup, or deleting.

1.3Controlled Lifecycle for Applying Recommendations

The controlled lifecycle for applying recommendations enforces review, explicit state transitions, and rollback readiness before production change. Human review must assess performance, reliability, and permission impacts first, and any automated application without review requires a prebuilt rollback process. Only recommendations first retrieved through the API or BigQuery Export can be transitioned through the API, and applying the change requires the recommender-specific apply role plus the target-service permission. Viewing Cloud SQL findings requires recommender.cloudsqlViewer or cloudsql.viewer, while applying them requires recommender.cloudsqlAdmin, cloudsql.editor, or cloudsql.admin.

The lifecycle preserves order from finding to verified result:

1. List: List recommendations for the target project, location, and recommender ID with gcloud recommender recommendations list or GET /v1/projects/PROJECT_ID/locations/LOCATION/recommenders/RECOMMENDER_ID/recommendations.
2. Claim or dismiss: Mark a recommendation the team intends to apply as claimed, or mark one it will not apply as dismissed, so ownership and intent are recorded before mutation.
3. Apply: Apply the change manually with the resource-specific console action, gcloud command, or REST call identified by the recommendation resource field, or automatically through Active Assist in the console.
4. Confirm outcome: Mark the recommendation as succeeded or failed only after verifying the resource state and spend effect, preserving the audit trail from finding to result.

Enabling the Recommender API (recommender.googleapis.com) requires the serviceusage.services.enable permission, typically granted through Owner or Service Usage Admin, and billing-project callers also need serviceusage.services.use, typically through Service Usage Consumer.

1.4Validating Savings and Committing to Discounted Capacity

Validation of savings confirms that an applied rightsizing or deletion actually lowers the bill and does not merely shift utilization. Cost validation flows from the changed resource to billing telemetry and back to FinOps review through cost reports in the console, Cloud Monitoring and billing alerts for threshold breaches, and export of recommendations to BigQuery for analysis in Looker Studio or Looker. For Cloud SQL rightsizing, detailed insights come from CpuUsageInsight and MemoryUsageInsight, which expose max CPU and memory utilization and map LOW_CPU_UTILIZATION or LOW_MEMORY_UTILIZATION to CHANGE_INSTANCE_SIZE, so the team can judge whether the exact suggested size fits future growth. When steady-state usage remains after cleanup, Committed Use Discounts (CUDs) lock in lower pricing for predictable consumption. Spend-based CUDs commit to a spend amount and resource-based CUDs commit to specific resources, and CUD analysis identifies which stable Compute Engine and related usage should be committed rather than left on-demand.

Integrating recommenders into operational workflows means ingesting Active Assist recommendations and insights through code rather than manual console clicks, then routing them through governance to automated remediation or human review. The pipeline pulls data from the Recommender API or gcloud CLI, evaluates risk and change scope, and then claims, applies, or dismisses each recommendation with full audit history. This pattern applies consistently across security, performance, reliability, and cost signals while preserving safety checks for high-impact changes.

2.1Programmatic Ingestion of Recommendations and Insights

Programmatic ingestion is the process where a scheduled job or CI/CD pipeline calls the recommender interfaces to collect actionable findings for a project, folder, or organization. The pipeline depends on the Recommender API being enabled and on an automation identity that holds viewer roles, and it scopes every call by PROJECT_ID and LOCATION such as us-central1. Data flows from the recommender service to the pipeline, then from the pipeline to ticketing, policy checks, or remediation jobs. Because ingestion is pull-based and refresh-driven, pipelines must handle pagination with pageSize and pageToken and filter by recommenderSubtype or insightSubtype.

A standard ingestion workflow preserves order and repeatability across environments:

1. Enable access: Enable the Recommender API and grant least-privilege roles to the pipeline identity before any list calls succeed.
2. List recommendations: Call recommendations.list or gcloud recommender recommendations list for a specific recommender ID, such as google.cloudsql.instance.PerformanceRecommender or google.alloydb.instance.SecurityRecommender, with a filter like recommenderSubtype=MYSQL_RECONFIG_OPEN_TABLES or recommenderSubtype=ENABLE_DATABASE_AUDITING.
3. List insights: Call insights.list or gcloud recommender insights list for the paired insight type, such as google.cloudsql.instance.PerformanceInsight filtered to MYSQL_HIGH_NUMBER_OF_OPEN_TABLES or MYSQL_FREQUENT_OUT_OF_MEMORY.
4. Normalize and route: Transform the returned name, description, primaryImpact, priority, targetResources, and content.operationGroups fields into a common record, then route the record to auto-remediation or review based on governance rules.

2.2Governance for Automated Remediation Versus Human Review

Governance for recommender automation is the set of policies that decides which findings a pipeline may fix directly and which findings require human approval based on risk and change classification. The decision uses fields supplied by the recommender itself: primaryImpact.category such as SECURITY, priority such as P1, recommenderSubtype, and the concrete operations that would execute. Low-risk, reversible, and well-understood changes are candidates for automation, while changes that alter memory, enforce organization policy, or touch production databases require review. This separation keeps velocity high without allowing a pipeline to apply a breaking or irreversible change unattended.

The following comparison shows how documented signals map to different automation postures:

Pipelines implement this governance by checking the resourceType, targetResources, and value.spec.rules in the recommendation content before acting. For example, an Organization Policy recommendation names the policy resource //orgpolicy.googleapis.com/projects/123456789012/policies/iam.managed.disableServiceAccountKeyCreation and its desired spec with enforce: true, so the pipeline can verify exactly which project would be constrained. A performance recommendation names the Cloud SQL (opens in a new tab) instance and the flag to raise, so the pipeline can verify peak open_tables or memory usage from observability data first.

2.3Applying and Tracking Lifecycle Changes Safely

Applying a recommendation safely requires locking it, executing the change, and preserving lifecycle history for audit and rollback. A recommendation moves through ordered states where it starts as ACTIVE, transitions to CLAIMED while work is in progress, and then resolves to applied or DISMISSED when intentionally deferred. The transition to CLAIMED depends on the current etag, which prevents two pipelines or users from changing the same recommendation concurrently. Dismissed recommendations appear dimmed but remain restorable from the Active Assist Dashboard through History, so deferral is reversible and auditable.

To apply a recommendation through the API without creating a race condition, follow this order:

1. Mark as CLAIMED: Call recommendations.markClaimed with the full recommendation name, which ends in the RECOMMENDATION_ID, plus the current ETAG and the RESOURCE_TYPE of projects, folders, or organizations with its RESOURCE_ID.
2. Execute the operation: Apply the content.operationGroups.operations exactly as described, such as an add operation at path / for an Organization Policy, or update the database flag or machine type through the owning service API.
3. Verify and release: Confirm the target state, monitor for the next refresh cycle, and allow the recommender to clear the finding or manually dismiss with stateMetadata such as reviewedBy and priority for traceability.

Access control enforces this lifecycle at the trust boundary between the pipeline and Google Cloud. Viewing requires list and get permissions, while claiming, applying, or dismissing requires update permission, typically granted through viewer and admin roles. Examples include recommender.gmpProjectManagementRecommendations.list and .get for viewing versus .update for changing, granted via Recommender Viewer and Recommender Admin roles, and recommender.alloydbViewer versus recommender.alloydbAdmin or alloydb.admin for AlloyDB findings. Granting these roles can expose a partial view of the target resource, so pipeline identities should be scoped to only the projects, folders, or locations they manage.

2.4Security, Reliability, and Performance Signals for Pipelines

Security, reliability, and performance recommenders provide the domain-specific evidence that pipelines use to prioritize work and validate fixes. Security signals include unrestricted Google Maps Platform (opens in a new tab) API keys from google.gmp.project.ManagementRecommender, disabled AlloyDB auditing, overly broad IAM grants surfaced as Security Command Center findings from IAM Recommender, and missing service-account key controls. Performance and reliability signals include Cloud SQL high open-table counts, high open-table-definition counts, and frequent out-of-memory events, each paired with detailed insights that identify the affected instance and current versus recommended configuration. Cost signals from the Cloud Hub Optimization (opens in a new tab) page complement these by showing the top five cost recommendations, cost trend, and high-cost low-utilization resources, excluding the committed use discounts recommender.

These signals carry operational constraints that pipelines must respect before auto-remediation. Database auditing and performance recommendations refresh daily, so after increasing table_open_cache by 1000 or table_definition_cache by 500, or after resizing for frequent out-of-memory events, the pipeline must wait about 24 hours before the recommendation clears. Increasing cache values requires more memory, so the pipeline must check peak usage and monitor memory after the change rather than looping increases blindly. IAM fixes flow from Security Command Center to the IAM page, where excess permissions are reviewed and applied, and the finding transitions to inactive within days.

Recommender insights are machine-generated findings about resource usage, and recommendations are the suggested actions that follow from those findings. In Google Cloud, Active Assist surfaces both through the Recommender API across cost, security, performance, manageability, and reliability domains to support FinOps (opens in a new tab) practices. An insight explains the observed pattern, such as low CPU utilization or a trending-out-of-disk condition, while the recommendation proposes the fix, such as rightsizing, enabling autogrow, or removing an idle resource. Prioritization weighs business impact, such as projected cost savings or avoided downtime, against technical feasibility, such as whether a smaller machine type can still meet performance requirements.

3.1How Insights Become Actionable Recommendations

A Recommender workflow moves data from usage analysis to operator action in a fixed order. First, the Recommender API analyzes telemetry and generates an insight object with a type and subtype, such as google.cloudsql.instance.SecurityInsight with DATABASE_AUDITING_NOT_ENABLED or DiskUsageTrendInsight with TRENDING_OUT_OF_DISK. Then the service generates a linked recommendation, such as ENABLE_AUTO_STORAGE_INCREASE, which appears in the Google Cloud console recommendation panel, in gcloud recommender recommendations list and gcloud recommender insights list, and in the Recommender API recommendations.list and insights.list calls. The operator evaluates the detail and chooses to apply it, such as clicking View instance and then Edit Instance to increase Cloud SQL storage or enable database auditing, to dismiss it so it appears dimmed and de-emphasized, or to cancel and close the panel without change.

3.2High-Impact Cost Recommenders to Prioritize First

High-impact cost recommenders identify idle resources that can be removed and overprovisioned resources that can be downsized with low operational risk. Compute Engine provides machine type recommendations to match VM instance types to workload compute requirements, including custom machine types for workloads with predictable needs, while managed instance groups and reservations have parallel rightsizing signals. These cost actions typically offer direct savings and simple remediation, so they rank above nuanced tuning that saves little or requires rearchitecture.

Idle-cluster, idle-instance, and unattended-project findings usually represent the highest business impact because the entire cost of the resource is waste. Overprovisioned VM, GKE, and Cloud SQL findings come next because rightsizing preserves function while lowering spend, but each requires checking peak load, scaling behavior, and latency goals before applying.

3.3Reliability and Performance Signals That Do Not Show as Cost Savings

Reliability and performance insights identify underprovisioned resources that need more capacity, not less, so they improve service health rather than reduce spend. Cloud Monitoring, Cloud Logging, Cloud Trace, and Cloud Profiler provide the latency, traffic, error rate, saturation, and code-level evidence needed to confirm whether an underprovisioned signal reflects real user impact. Because these actions may increase cost or require capacity planning, the FinOps Recommendations dashboard excludes them, while the FinOps Utilization insights dashboard retains them for engineering review. This split prevents teams from treating a stability fix as a savings opportunity.

3.4Validating Technical Feasibility Before Applying Changes

Technical feasibility validation tests whether a recommended change preserves performance, availability, and security controls before it reaches production. Database Center assessments support this check for Cloud SQL for PostgreSQL for three recommendation types: compute resource expansion to larger vCPU or memory machine types, edition upgrade from Cloud SQL Enterprise edition to Cloud SQL Enterprise Plus edition, and data cache activation for latency and throughput improvement. Assessment depends on the Secret Manager API, Cloud Run Admin API, Cloud SQL Admin API, Cloud Monitoring API, and Cloud Logging API, plus a database username and password stored in Secret Manager and a service account that can read the secret and coordinate benchmarking.

An assessment runs as an ordered simulation against a clone rather than the production instance:

1. Clone: Database Center clones the target Cloud SQL for PostgreSQL instance.
2. Benchmark: The service runs benchmarking simulation tests on the clone with baseline and recommended configurations.
3. Compare: The service compares baseline latency and throughput against post-change performance to quantify impact.

Use the comparison to decide whether projected savings justify migration effort, restart impact, or higher spend for reliability. For Compute Engine workloads, confirm that the recommended predefined or custom machine type covers peak CPU, memory, and disk I/O, and retain operational practices such as using zonal internal DNS names for application-to-database connectivity and maintaining patched custom OS images through image families (opens in a new tab). For security hardening, enable database auditing (opens in a new tab) only after confirming audit log volume and access controls.

Key Facts

• Recommender generates findings that name the target in the resource field, but the operator must apply the change with the owning service tool because Recommender does not mutate resources.
• The Cloud SQL overprovisioned recommender only fires for primary instances older than 30 days with 30-day CPU and memory peaks and estimated monthly savings of at least $10.
• Recommendations move from ACTIVE to CLAIMED using the current etag before applying, and dismissed findings remain restorable from History.
• Underprovisioned VM, GKE, and Cloud SQL findings appear on the Utilization insights dashboard but are excluded from the FinOps Recommendations dashboard.
• Database Center validates Cloud SQL for PostgreSQL changes by cloning the instance, benchmarking baseline versus recommended configurations, and comparing latency and throughput.