Google Cloud Recommender Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Access and resource management

by

Category

Access and resource management

1. Introduction

Google Cloud Recommender (exposed through the Recommender API and surfaced in the Google Cloud Console as recommendations) is a managed service that analyzes configuration, usage signals, and best-practice rules to generate actionable recommendations and insights for Google Cloud resources.

In simple terms: Recommender tells you what to change in your Google Cloud environment—such as tightening IAM permissions, resizing resources, or fixing risky configurations—and explains the expected impact.

Technically, Recommender is part of Google Cloud’s Active Assist ecosystem. It publishes structured recommendation objects (with metadata, impact estimates, and suggested operations) that you can retrieve via the Recommender API and incorporate into automation, governance workflows, ticketing, and engineering reviews. Recommendations are scoped to different resource hierarchies (project, folder, organization, billing account), depending on the recommender type.

Recommender solves a common problem in cloud operations: as environments grow, teams struggle to continuously identify cost waste, security exposures, and reliability/performance issues across hundreds or thousands of resources. Recommender provides a centralized, programmatic way to discover improvement opportunities and track whether they were applied.

2. What is Recommender?

Official purpose (what it’s for)
Recommender helps you improve your Google Cloud environment by generating recommendations (suggested actions) and insights (supporting observations) across supported Google Cloud services. It is designed for continuous optimization of cost, security, reliability, performance, and manageability, depending on the recommender.

Core capabilities – Discover available recommenders and insight types for a given scope (project/folder/org/billing account). – List and retrieve recommendations and insights. – Track lifecycle state of recommendations (for example: active vs dismissed) by marking them as claimed/succeeded/failed/dismissed (availability depends on the API methods for your recommender). – Use recommendation content and impact signals to drive human workflows or automation.

Major components – Recommenders: The engines/types that generate recommendations (for example IAM-related recommenders and resource optimization recommenders). Each recommender has an ID and supported locations. – Recommendation resources: Individual recommendation objects with: – Suggested changes (often represented as operation groups) – Impact projections (varies by recommender) – Priority and/or other metadata (varies) – An etag for concurrency control – Insight types: The engines/types that generate insights. – Insight resources: Individual insight objects describing observations (for example, “this permission hasn’t been used” or “resource utilization is low”), often linked to recommendations. – Recommender API: A Google Cloud API endpoint (recommender.googleapis.com) to query and manage recommendations/insights programmatically.

Service type – Fully managed Google Cloud service (API-driven; integrates with Google Cloud Console recommendations views). – No infrastructure to run; you consume it through Console and APIs.

Scope and locations – Hierarchy scope: Recommendations and insights can be scoped to different resource containers: – projects/{PROJECT_ID} – folders/{FOLDER_ID} – organizations/{ORG_ID} – billingAccounts/{BILLING_ACCOUNT_ID} Which scopes are supported depends on the specific recommender/insight type. – Locations: Many recommender resources are accessed via the global location, but some may use other locations depending on the recommender. Always confirm supported locations in the official docs and via API discovery for your environment.

How it fits into the Google Cloud ecosystem Recommender sits at the intersection of: – Access and resource management: especially IAM-focused recommenders (least privilege, policy hygiene). – FinOps: identifies cost efficiency opportunities (rightsizing, idle resources, commitment planning, etc., depending on supported recommenders). – Security and governance: supports posture improvement and policy enforcement workflows (often alongside services like Security Command Center, Cloud Asset Inventory, and Cloud Logging/Audit Logs). – Operations: provides a structured feed that SRE and platform teams can track and operationalize.

Naming note: The product is commonly referred to as Recommender and accessed via the Recommender API. It remains an active Google Cloud service as of this writing. Verify any major changes in the official documentation and release notes.

3. Why use Recommender?

Business reasons

  • Reduce cloud waste: Identify unused or underutilized resources and configuration inefficiencies (depending on what recommenders apply to your services).
  • Lower risk: Spot risky access patterns and configuration issues early, before they lead to incidents.
  • Standardize best practices: Apply consistent optimization guidance across teams and projects.
  • Improve engineering velocity: Replace ad-hoc manual audits with a repeatable, programmatic signal.

Technical reasons

  • API-driven optimization: Pull recommendations into CI/CD, policy-as-code workflows, or internal dashboards.
  • Structured recommendation content: Recommendations often include machine-readable “what to change” data, not just text.
  • Hierarchy-aware: Consume signals at the project level or aggregate across folders/organizations (as supported by each recommender).

Operational reasons

  • Continuous improvement loop: Monitor active recommendations, triage, assign ownership, and track closure.
  • Change management friendly: Mark recommendation states (for example dismissed/claimed) to avoid repeated re-triage and to measure adoption.
  • Scales with your organization: Works better than spreadsheet audits as your cloud footprint grows.

Security/compliance reasons

  • Least privilege posture: IAM-focused recommenders can help reduce standing access and unused permissions, supporting compliance initiatives.
  • Auditability: Recommendation state changes and acting on recommendations can be tied to operational processes and logged through normal Google Cloud logging/audit mechanisms (verify exact audit logging details for your environment).

Scalability/performance reasons

  • Identify resource mismatches: When supported, recommenders can highlight when resources are overprovisioned or underprovisioned.
  • Operational consistency: Use standardized decision inputs for scaling and tuning.

When teams should choose Recommender

Choose Recommender if you want: – A native Google Cloud recommendation feed. – A single place (API + Console) to track optimization signals. – A way to integrate cloud recommendations into internal platforms (FinOps dashboards, security hygiene pipelines, platform governance).

When teams should not choose it

Recommender may not be the right tool if: – You need real-time recommendations (many recommenders rely on historical signals and are not instantaneous). – You require recommendations for services or patterns not covered by Google Cloud recommenders. – You want a tool that automatically applies fixes end-to-end without review. Recommender is typically advisory; applying changes requires separate action/automation and proper controls.

4. Where is Recommender used?

Industries

  • SaaS and tech: continuous cost and IAM optimization.
  • Financial services: access governance, least privilege, audit-driven hygiene.
  • Healthcare: compliance-oriented access review and risk reduction.
  • Retail/e-commerce: cost optimization at scale and operational reliability improvements.
  • Media and gaming: seasonal scaling patterns and resource utilization tuning.

Team types

  • Platform engineering teams operating multi-project organizations.
  • SRE/operations teams running shared services.
  • Security engineering / IAM governance teams.
  • FinOps teams tracking savings opportunities and optimization adoption.
  • DevOps teams integrating optimization signals into pipelines.

Workloads

  • Multi-project microservices environments.
  • Data platforms with variable compute usage.
  • Batch/ETL workloads with ephemeral resources.
  • Environments with many service accounts and complex IAM policies.

Architectures

  • Organization/folder-based landing zones with guardrails.
  • Centralized logging/monitoring with policy enforcement.
  • Multi-tenant platforms with strict access boundaries.

Real-world deployment contexts

  • Production: Used for continuous posture monitoring and change management workflows (recommendation triage, assignment, remediation).
  • Dev/test: Used to enforce hygiene (avoid cost sprawl, remove unused IAM grants, spot idle resources).

5. Top Use Cases and Scenarios

Below are realistic scenarios where Recommender is commonly operationalized. Availability depends on which recommender types apply to your resources and org setup.

1) IAM least privilege cleanup

  • Problem: Teams accumulate broad roles and permissions over time.
  • Why Recommender fits: IAM-focused recommenders can identify unused permissions/roles (based on observed usage signals) and suggest narrowing.
  • Example: A platform team reviews recommendations weekly to remove unused IAM bindings from service accounts.

2) Access review preparation for audits

  • Problem: Auditors require evidence of periodic access reviews and privilege reduction.
  • Why Recommender fits: Provides a consistent feed of access-related improvements and a way to track whether teams dismissed/applied them.
  • Example: Security exports recommendation state metrics and attaches them to compliance reports.

3) Detect and act on idle resources (cost hygiene)

  • Problem: Forgotten dev/test resources create recurring charges.
  • Why Recommender fits: Cost-oriented recommenders can flag idle/underused resources for cleanup (where supported).
  • Example: A FinOps pipeline opens tickets for idle resources and tracks closure.

4) Rightsize workloads for performance/cost balance

  • Problem: Overprovisioned compute wastes money; underprovisioned compute causes latency and errors.
  • Why Recommender fits: Rightsizing recommenders can suggest machine type adjustments (where supported).
  • Example: SRE reviews recommendations during capacity planning and applies changes in maintenance windows.

5) Standardize governance across many projects

  • Problem: Different teams optimize inconsistently; some never revisit old configurations.
  • Why Recommender fits: Centralized API access enables organization-wide dashboards and consistent triage processes.
  • Example: A central platform team aggregates recommendations across all projects in a folder.

6) Automate triage with labeling and ticketing

  • Problem: Human triage doesn’t scale.
  • Why Recommender fits: API output can be mapped to “owner”, “severity”, “environment”, and routed to the right queues.
  • Example: A Cloud Run job pulls recommendations daily and creates Jira tickets with resource links.

7) Prevent security regressions in IAM policies

  • Problem: Policies drift; temporary broad access becomes permanent.
  • Why Recommender fits: IAM recommendations can surface risky or unnecessary access patterns (depending on recommender capabilities available to you).
  • Example: Security team reviews weekly and requires approvals for dismissals.

8) Track optimization adoption (FinOps KPI)

  • Problem: Savings opportunities exist but are not acted on, and leadership wants measurable progress.
  • Why Recommender fits: Recommendation states can be used to measure “recommendations addressed vs outstanding”.
  • Example: FinOps reports monthly adoption rate per business unit.

9) Build internal “cloud hygiene score”

  • Problem: No objective, repeatable measure of environment hygiene.
  • Why Recommender fits: Recommendations/insights can be categorized and weighted (cost/security/reliability) to compute scores.
  • Example: A platform team publishes a dashboard per folder showing trendlines.

10) Support controlled automation (“human-in-the-loop”)

  • Problem: Full auto-remediation is risky; manual remediation is slow.
  • Why Recommender fits: Recommendations provide a structured plan; teams can gate changes through approvals.
  • Example: Automation creates PRs or change requests rather than applying changes directly.

11) Organization-wide governance for shared services

  • Problem: Shared VPC and central services are sensitive and expensive.
  • Why Recommender fits: Central teams can monitor recommendations for critical shared projects.
  • Example: SREs review and approve only low-risk changes, dismissing others with justification.

12) Reduce operational toil in periodic audits

  • Problem: Quarterly reviews are time-consuming.
  • Why Recommender fits: Continuous recommendation feeds reduce “big bang” audit work.
  • Example: Instead of quarterly manual IAM reviews, teams continuously address IAM recommendations.

6. Core Features

Feature availability can differ by recommender type; always validate behavior for the recommenders that apply to your resources.

1) Recommendation discovery and listing (API + Console)

  • What it does: Lets you list recommendations for a scope (project/folder/org/billing account) and a specific recommender ID.
  • Why it matters: Enables automation and centralized dashboards.
  • Practical benefit: You can pull all active recommendations nightly and route them to owners.
  • Caveats: Some environments may have zero recommendations until sufficient usage signals exist.

2) Insight discovery and listing

  • What it does: Provides “insights” that explain conditions behind recommendations.
  • Why it matters: Improves trust and decision quality—teams can see why a recommendation exists.
  • Practical benefit: Use insights as evidence in change approvals.
  • Caveats: Not every recommender provides insights, and insight availability varies.

3) Structured recommendation content (machine-readable changes)

  • What it does: Many recommendations include structured “operations” describing the suggested change.
  • Why it matters: Enables safer automation and consistent remediation steps.
  • Practical benefit: Automation can translate an operation into an internal runbook or a proposed change.
  • Caveats: Even when operations are included, applying them automatically may not be appropriate without validation.

4) Impact estimation metadata

  • What it does: Recommendations often include impact signals (for example cost projections or risk reduction indicators).
  • Why it matters: Helps prioritize work.
  • Practical benefit: FinOps can rank recommendations by projected savings; security can rank by risk.
  • Caveats: Impact data is an estimate and can differ from real outcomes; verify before applying large changes.

5) Recommendation lifecycle management (state changes)

  • What it does: Lets you mark recommendations as claimed/succeeded/failed/dismissed (exact methods depend on API support).
  • Why it matters: Prevents repeated work and supports governance metrics.
  • Practical benefit: Track ownership (claimed), completion (succeeded), and exceptions (dismissed with reasons).
  • Caveats: State changes require correct IAM permissions and an up-to-date etag.

6) Concurrency control with etag

  • What it does: Uses etag in write operations to avoid conflicting updates.
  • Why it matters: Ensures your automation doesn’t overwrite another team’s state changes.
  • Practical benefit: Safer multi-team operations at org scale.
  • Caveats: If you use a stale etag, the API should reject the change; your automation must re-fetch and retry.

7) Hierarchy support (project/folder/org/billing)

  • What it does: Lets you query recommendations at different aggregation scopes.
  • Why it matters: Enables centralized governance and reporting.
  • Practical benefit: Security can query org-level IAM recommendations instead of per-project.
  • Caveats: Not all recommenders support all hierarchy levels.

8) Filtering and pagination (API query controls)

  • What it does: Supports pagination and (for some list methods) filtering.
  • Why it matters: Critical for scale; avoids pulling everything every time.
  • Practical benefit: Retrieve only active recommendations or only certain subtypes (where supported).
  • Caveats: Filter syntax and supported fields can vary—verify in the API reference.

7. Architecture and How It Works

High-level service architecture

Recommender continuously evaluates Google Cloud resources using service-specific signals (usage, configuration, policy, telemetry) and generates: – Insights (observations), and – Recommendations (actions).

You consume those through: – The Google Cloud Console recommendations pages, and/or – The Recommender API for programmatic workflows.

Request/data/control flow (typical)

  1. Google Cloud services emit signals (metrics, configuration state, policy bindings, historical usage patterns).
  2. Recommender processes those signals and creates recommendation/insight resources for supported recommenders.
  3. Users or automation query Recommender via API.
  4. Users/automation decide whether to apply changes.
  5. Users/automation update recommendation state (dismiss/claim/succeed/etc.) to reflect workflow progress.

Integrations with related services

Common integrations include: – IAM (for access and resource management-focused recommendations). – Cloud Monitoring and service telemetry (as inputs to utilization-based recommenders). – Cloud Logging / Cloud Audit Logs (to audit who changed IAM or resources after reviewing recommendations). – Cloud Asset Inventory (often used alongside Recommender to inventory resources and correlate changes). – Cloud Scheduler + Cloud Run/Functions (to build scheduled exports and ticket creation workflows). – BigQuery (to store snapshots of recommendations for analytics; typically implemented via custom ingestion unless an official export exists for your use case—verify in official docs).

Dependency services

Recommender depends on: – The underlying Google Cloud services it analyzes (for signals and applicability). – Google Cloud IAM for access control to the Recommender API and for remediation actions.

Security/authentication model

  • API access is controlled by Google Cloud IAM.
  • Clients authenticate using:
  • User credentials (Cloud Shell / gcloud auth), or
  • Service account credentials (recommended for automation).
  • To act on a recommendation, your identity typically needs permissions on:
  • Recommender objects (to read/update state), and
  • The underlying target resource (to apply remediation), which is separate.

Networking model

  • Recommender API is a public Google API endpoint (https://recommender.googleapis.com).
  • Access is over HTTPS; no VPC connectivity is required to call the API.
  • If your organization restricts access to Google APIs (for example using VPC Service Controls), validate Recommender support and perimeter behavior in official docs.

Monitoring/logging/governance considerations

  • Track:
  • Number of active recommendations by category and project/folder.
  • Aging (how long recommendations remain active).
  • Dismissal rate and reasons (governance signal).
  • Applied savings (if you track outcomes externally).
  • Use Cloud Logging and Audit Logs to correlate:
  • Recommendation state changes (if logged)
  • Resource changes that implement recommendations

Simple architecture diagram (conceptual)

flowchart LR
  A[Google Cloud services\n(IAM, compute, databases, etc.)] --> B[Recommender]
  C[Engineer / FinOps / Security] -->|Console or API| B
  D[Automation\n(Cloud Run/Functions)] -->|Recommender API| B
  B --> E[Recommendations & Insights]
  E --> C
  E --> D
  C --> F[Apply changes\n(IAM updates, resize, cleanup)]
  D --> F

Production-style architecture diagram (operationalized)

flowchart TB
  subgraph Org[Google Cloud Organization]
    P1[Projects / Folders] --> R[Recommender API]
    P1 --> S[Target services\n(IAM, compute, etc.)]
  end

  subgraph Ops[Ops & Governance]
    SCH[Cloud Scheduler] --> CR[Cloud Run job\nRecommendation harvester]
    CR -->|List recommenders + recommendations| R
    CR --> BQ[(BigQuery\nrecommendations snapshot)]
    CR --> PUB[Pub/Sub\nnotifications]
    PUB --> AL[Alerting endpoint\n(Chat/Email/Ticketing)]
    BQ --> DS[Dashboards\n(Looker Studio/BI)]
  end

  subgraph Sec[Security Controls]
    IAM[IAM\nleast privilege SA] --> CR
    LOG[Cloud Logging] --> CR
  end

  CR --> LOG
  Human[Review board / Change mgmt] --> DS
  Human -->|Approve remediation| S

8. Prerequisites

Account/project requirements

  • A Google Cloud account with access to a Google Cloud project (or ability to create one).
  • Billing enabled for the project if you plan to create resources while experimenting. (You can still explore Recommender without creating new billable resources.)

Permissions / IAM roles

At minimum, you need permissions to: – Enable APIs: typically roles/serviceusage.serviceUsageAdmin (or equivalent). – Read recommendations: typically roles/recommender.viewer on the scope you query (project/folder/org/billing). – Update recommendation state (optional): typically roles/recommender.admin or an appropriate Recommender role, depending on your governance model.

To apply changes suggested by recommendations, you also need the appropriate IAM roles on the target resources (for example, IAM Admin permissions to change IAM policy, Compute Admin permissions to stop/delete instances, etc.).

Verify current predefined Recommender roles in IAM docs and the Recommender documentation, as role names and included permissions can evolve.

Billing requirements

  • Recommender itself is typically not a direct billable resource, but the actions you take (or resources you create for the lab) can incur costs.
  • Always review Google Cloud Billing and set budgets/alerts for safety.

CLI/SDK/tools

  • Google Cloud CLI (gcloud) (available in Cloud Shell): https://cloud.google.com/sdk/docs/install
  • Optional: curl (available in Cloud Shell)
  • Optional: jq for nicer JSON viewing (sudo apt-get install jq in Cloud Shell, if needed)

Region availability

  • Recommender is accessed via a global Google API endpoint.
  • Some recommenders are accessed using the global location; confirm the correct location(s) for the recommender IDs you use.

Quotas/limits

  • API quotas exist (requests per minute/day). Exact values can change; check:
  • Google Cloud Console → APIs & Services → Recommender API → Quotas
  • Official documentation for quota guidance (verify in official docs)

Prerequisite services

  • Recommender API must be enabled in the project you use to call it:
  • Service name: recommender.googleapis.com

9. Pricing / Cost

Current pricing model (how you are charged)

Recommender is a managed recommendation service. In many cases, there is no separate line-item cost to retrieve recommendations via the API, but you must confirm the current pricing model in official Google Cloud sources because pricing and SKUs can change.

  • Start with official docs: https://cloud.google.com/recommender/docs
  • Check Google Cloud Pricing Calculator (for any relevant SKUs or related service costs): https://cloud.google.com/products/calculator
  • Check your Billing export / SKU list if you need definitive proof for your organization.

If Recommender API usage is free (as is commonly the case for advisory APIs), your costs come primarily from: – The resources being recommended (compute/storage/network). – The automation you build to consume recommendations (Cloud Run/Functions, Scheduler, Pub/Sub, BigQuery). – Any additional monitoring/logging retention and exports.

Pricing dimensions to consider

Even if Recommender itself is not charged directly, end-to-end solutions have cost dimensions: – API requests (Recommender API quotas; typically not billed separately but verify). – Compute for ingestion (Cloud Run jobs, Functions). – Storage/analytics (BigQuery tables for snapshots, retention). – Network egress (if exporting data outside Google Cloud). – Logging (Cloud Logging ingestion/retention/export).

Free tier (if applicable)

  • Google Cloud services like Cloud Run, Cloud Scheduler, Pub/Sub, and BigQuery have their own free tiers or low-cost entry tiers. Verify in their pricing pages.
  • Do not assume Recommender has a free tier unless explicitly stated in official pricing documentation.

Hidden or indirect costs

  • Applying recommendations can increase costs in some cases (for example, performance improvements that require larger instances).
  • Misapplied automation can delete/resize resources incorrectly—risk cost is real even if API cost is not.
  • BigQuery storage growth if you snapshot recommendations frequently without retention controls.

Network/data transfer implications

  • Recommender API responses are typically small JSON payloads.
  • Cost impact is mainly from:
  • exporting data outside Google Cloud, or
  • storing long-term snapshots and logs.

How to optimize cost

  • Query only what you need:
  • Use pagination.
  • Use filtering (where supported) to pull only active recommendations.
  • Snapshot less frequently (daily is often enough).
  • Use BigQuery partitioned tables and retention policies.
  • Keep Cloud Run jobs short; avoid high-frequency schedules unless required.

Example low-cost starter estimate (no fabricated prices)

A minimal setup often includes: – Cloud Shell (no direct cost to you beyond your Google Cloud usage) – Recommender API calls (verify pricing; often no direct charge) – Optional: a daily Cloud Run job + Cloud Scheduler trigger (low usage) – Optional: store results in a small BigQuery dataset (storage and query costs are usually low at small scale)

Because exact prices vary by region and service SKUs, use the Pricing Calculator to estimate: – Cloud Run CPU/memory seconds – Scheduler job frequency – BigQuery storage (GB-month) and query processing (TB)

Example production cost considerations

In production, the main cost drivers are usually: – BigQuery dataset growth (daily snapshots across hundreds of projects) – High-frequency ingestion (hourly or near-real-time) – Downstream workflows (ticketing, alerting, dashboards) – Staff time and change management overhead (often the largest “cost”)

10. Step-by-Step Hands-On Tutorial

Objective

Enable the Recommender API and use it to: 1. Discover which recommenders and insight types are available for your project. 2. List recommendations and insights. 3. (Optional) Update the lifecycle state of a recommendation (dismiss/claim/succeed) if you have at least one recommendation available.

This lab is designed to be safe and low-cost: it does not require creating billable resources, and it does not automatically apply any changes to your environment.

Lab Overview

You will: – Use Cloud Shell to configure a project. – Enable recommender.googleapis.com. – Call the Recommender REST API with curl. – Inspect results and understand resource naming. – Optionally mark a recommendation as dismissed (only if one exists), then verify the state change.

Important: Many recommendations require historical usage signals. It is common for a new or small project to return zero recommendations. That’s not an error.

Step 1: Select (or create) a Google Cloud project

In Cloud Shell, set your project:

gcloud projects list

Set the project you want to use:

export PROJECT_ID="YOUR_PROJECT_ID"
gcloud config set project "${PROJECT_ID}"

Expected outcome – gcloud is now targeting your project.

Verification

gcloud config get-value project

It should output your PROJECT_ID.

Step 2: Enable the Recommender API

Enable the API:

gcloud services enable recommender.googleapis.com

Expected outcome – The command completes without errors.

Verification

gcloud services list --enabled --filter="name:recommender.googleapis.com"

You should see recommender.googleapis.com in the output.

Step 3: Obtain an access token for REST calls

In Cloud Shell, get an OAuth 2.0 access token:

export ACCESS_TOKEN="$(gcloud auth print-access-token)"
echo "${ACCESS_TOKEN}" | head -c 20 && echo

Expected outcome – A token string is printed (first characters only).

Step 4: List available recommenders for your project (discovery)

Call the Recommender API to list recommenders under the global location:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/recommenders" | head -n 60

Expected outcome – JSON output containing a recommenders array (may be empty in some environments).

If you want nicer output (optional)

sudo apt-get update -y && sudo apt-get install -y jq

Then:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/recommenders" \
  | jq -r '.recommenders[]?.name'

You should see entries like:

projects/PROJECT_ID/locations/global/recommenders/RECOMMENDER_ID

If the list is empty: that can be normal depending on your project/services. Try a different project, or verify in official docs which recommenders should apply.

Step 5: Pick one recommender ID and list recommendations

Choose one recommender name from Step 4. Extract the recommender ID from the returned resource name. For example, if you see:

projects/my-project/locations/global/recommenders/google.iam.policy.Recommender

Then the recommender ID is:

google.iam.policy.Recommender

Set it as a variable:

export RECOMMENDER_ID="PASTE_RECOMMENDER_ID_HERE"

Now list recommendations:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/recommenders/${RECOMMENDER_ID}/recommendations?pageSize=10" \
  | jq

Expected outcome – JSON with a recommendations array. – If no recommendations exist, the array may be missing or empty.

What to look for in a recommendation – name: the unique recommendation resource name – description / content / impact fields (field names and details vary) – etag: required for state-changing operations – Links to affected resources (often inside recommendation content)

Step 6: List insight types and insights (optional but recommended)

First list insight types:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/insightTypes" \
  | jq -r '.insightTypes[]?.name'

Pick an insight type ID from the output and set it:

export INSIGHT_TYPE_ID="PASTE_INSIGHT_TYPE_ID_HERE"

Now list insights:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/insightTypes/${INSIGHT_TYPE_ID}/insights?pageSize=10" \
  | jq

Expected outcome – JSON with an insights array (may be empty).

Step 7: Get a specific recommendation and capture its etag

If you have at least one recommendation from Step 5, copy its full name field and set:

export RECOMMENDATION_NAME="PASTE_FULL_RECOMMENDATION_RESOURCE_NAME_HERE"

Retrieve the recommendation:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/${RECOMMENDATION_NAME}" \
  | jq

Extract the etag:

export ETAG="$(curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/${RECOMMENDATION_NAME}" | jq -r '.etag')"

echo "${ETAG}"

Expected outcome – You have an etag value stored in the shell.

Step 8: (Optional) Dismiss a recommendation (state update)

Only do this if you have a recommendation that is safe to dismiss in your environment and you have appropriate permissions.

Dismiss the recommendation (include the etag):

curl -sS -X POST \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  "https://recommender.googleapis.com/v1/${RECOMMENDATION_NAME}:markDismissed" \
  -d "{\"etag\":\"${ETAG}\",\"stateMetadata\":{\"dismissedBy\":\"lab-user\",\"reason\":\"Reviewed in lab\"}}" \
  | jq

Expected outcome – The API returns the updated recommendation object (or an operation result) indicating it is dismissed.

Note: The exact method names and behavior are defined in the Recommender API reference. If markDismissed is not supported for your recommendation type, verify supported methods in the official REST reference for your API version.

Validation

Use the GET call again and inspect state-related fields:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/${RECOMMENDATION_NAME}" \
  | jq

Expected outcome – You can see the recommendation’s state indicates it has been dismissed (field names vary by API resource schema; check stateInfo or similar fields).

Also validate that listing recommendations still works:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://recommender.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/recommenders/${RECOMMENDER_ID}/recommendations?pageSize=5" \
  | jq

Troubleshooting

Error: PERMISSION_DENIED (403) – Causes: – Recommender API not enabled in the project you’re calling from. – Your identity lacks roles/recommender.viewer (or equivalent) on the scope. – Org policy restrictions or VPC Service Controls perimeter restrictions. – Fix: – Enable the API (gcloud services enable recommender.googleapis.com) – Ask an admin to grant appropriate IAM roles. – Test with a project where you have Owner-level permissions (for lab only).

Error: NOT_FOUND (404) – Causes: – Wrong PROJECT_ID, location, or recommender/insight type ID. – The recommender exists but not in the global location for your case. – Fix: – Re-run discovery calls to list recommenders and insight types. – Verify the location in official docs for that recommender.

Empty lists (no recommendations/insights) – Causes: – No supported resources exist in the project. – Not enough historical usage signal. – The recommender is not applicable to your configuration. – Fix: – Try a mature production-like project (read-only). – Wait for signals to accumulate (some recommenders can take days/weeks).

Error when dismissing: FAILED_PRECONDITION or etag mismatch – Causes: – You used a stale etag. – Another process updated the recommendation state. – Fix: – Re-fetch the recommendation to get a fresh etag, then retry.

Cleanup

If you used an existing project, the safest cleanup is to: – Do nothing (you only read data), unless you dismissed a recommendation.

If you dismissed a recommendation during the lab and want to revert: some state transitions may not be reversible depending on recommender behavior. Verify in official docs for the specific recommendation type.

Optional cleanup actions: – Disable the API (not usually necessary, but possible):

gcloud services disable recommender.googleapis.com
  • Unset environment variables:
unset ACCESS_TOKEN PROJECT_ID RECOMMENDER_ID INSIGHT_TYPE_ID RECOMMENDATION_NAME ETAG

If you created a dedicated lab project, you can delete it (high impact):

gcloud projects delete "${PROJECT_ID}"

11. Best Practices

Architecture best practices

  • Treat Recommender as a signal source: Build a pipeline that reads recommendations, enriches context (owner, environment), then routes to humans/automation.
  • Separate “read” from “act”: Use one service account for listing recommendations and another identity (with stronger permissions) for applying changes.
  • Centralize aggregation: For large orgs, prefer organization/folder-level reporting patterns (where supported) instead of per-project scripts.

IAM/security best practices

  • Least privilege:
  • Grant roles/recommender.viewer widely (read-only) if needed.
  • Restrict who can dismiss/claim/succeed recommendations to avoid hiding risk.
  • Use service accounts for automation with:
  • Narrow scopes
  • Keyless authentication where possible (Workload Identity Federation or in-platform identities like Cloud Run service identities)
  • Require approvals for high-risk changes suggested by recommendations (IAM changes, deletions, network exposure changes).

Cost best practices

  • Prioritize by impact: Use impact projections to focus effort, but validate with billing reports before big changes.
  • Avoid over-snapshotting: Don’t store raw JSON daily for every project forever without retention.
  • Measure outcomes: Track “recommendations applied” vs “savings realized” separately—recommendations are advisory.

Performance best practices

  • Use pagination and filtering to reduce API calls.
  • Batch and cache: If building dashboards, store snapshots in BigQuery rather than querying the API on every dashboard load.
  • Backoff and retry on rate limits with exponential backoff.

Reliability best practices

  • Idempotent processing: Use recommendation name as a stable identifier.
  • Handle state transitions with etag and retry logic.
  • Graceful degradation: If Recommender API is temporarily unavailable, your ops should still function (queue work, retry later).

Operations best practices

  • Define ownership: Map resources/projects to owning teams so recommendations are actionable.
  • Set SLAs for triage: For example, security recommendations reviewed within 7 days.
  • Create standard dismissal reasons: Avoid “dismissed because no time” without explanation.
  • Integrate with ticketing: Ensure recommendation links and resource IDs are captured.

Governance/tagging/naming best practices

  • Use consistent resource labels/tags:
  • env (prod/dev)
  • owner (team)
  • cost_center
  • Use these labels in your aggregation pipeline to route recommendations automatically.

12. Security Considerations

Identity and access model

  • Access to Recommender is IAM-controlled.
  • Typical permission layers: 1. Permission to read/update recommendation objects. 2. Permission to apply changes to the underlying resource.
  • In Access and resource management contexts, IAM-related recommendations can be sensitive because they reveal:
  • Which principals have access
  • Where permissions may be excessive
  • Potential policy weaknesses

Encryption

  • Data in transit: HTTPS to Google APIs.
  • Data at rest: Managed by Google Cloud for the service. For any exports you store (BigQuery, Cloud Storage), apply your own encryption/KMS policies as needed.

Network exposure

  • Calls are made to public Google API endpoints.
  • If you restrict egress, ensure your egress rules allow Google APIs.
  • If you use VPC Service Controls, validate whether Recommender API is supported within perimeters and how it behaves (verify in official docs).

Secrets handling

  • Prefer keyless auth for automation (Cloud Run service identity, Workload Identity Federation).
  • Avoid embedding access tokens in scripts stored in repos.
  • If you must use keys (not recommended), store them in Secret Manager and rotate regularly.

Audit/logging

  • Ensure Cloud Audit Logs are enabled appropriately for:
  • IAM policy changes (when applying recommendations)
  • Any state changes to recommendation objects (verify how they appear in audit logs for your environment)
  • For governance, keep evidence of:
  • Who dismissed a recommendation and why
  • Who applied the fix and when

Compliance considerations

  • Recommender can support compliance by:
  • Encouraging least privilege (IAM)
  • Reducing risky configurations (depending on recommender types)
  • It does not replace:
  • Formal access reviews
  • Policy enforcement
  • Security Command Center findings and controls

Common security mistakes

  • Giving automation broad permissions to apply recommendations directly in production without approvals.
  • Allowing teams to dismiss recommendations without accountability.
  • Treating recommendations as “always correct” without validating business context.

Secure deployment recommendations

  • Use a dedicated “recommendation harvester” service account with viewer permissions only.
  • Implement approval workflows for remediation.
  • Store recommendation snapshots in a controlled dataset with least-privilege access.
  • Use separate environments (dev/prod) for your automation pipeline.

13. Limitations and Gotchas

  • Not real-time: Many recommendations depend on historical usage. Expect delays.
  • Coverage varies: Recommender coverage differs by Google Cloud product and configuration.
  • Zero recommendations is normal: Especially for new projects or projects without supported resources.
  • Location confusion: Many use global, but not all recommender/insight types necessarily do. Always discover supported IDs and locations.
  • State changes require etag: If you ignore etag, you’ll get conflicts or failures.
  • Acting requires separate permissions: Recommender can tell you what to do, but you still need IAM privileges to change the underlying resources.
  • Risk of automation: Auto-remediation can cause downtime or security regressions if recommendations are misinterpreted.
  • Quotas: API rate limits can affect org-wide ingestion jobs. Implement backoff and batching.
  • Recommendation semantics differ: Fields and content structure can vary by recommender type; don’t hardcode assumptions across all recommenders.
  • Governance complexity: Dismissed recommendations can hide risk if dismissal reasons are not controlled and audited.

14. Comparison with Alternatives

Recommender is the native Google Cloud recommendation feed, but it’s not the only way to optimize cloud environments.

Alternatives in Google Cloud

  • Active Assist (Console UI): The user interface that surfaces recommendations from Recommender and related systems.
  • Security Command Center (SCC): Security posture management and findings (not the same as recommendations; broader security focus).
  • Policy Intelligence / IAM tooling: For analyzing IAM policies and access risk (complementary).
  • Cloud Asset Inventory: For inventory and history; does not generate recommendations, but is used to correlate and govern.

Alternatives in other clouds

  • AWS Trusted Advisor: Recommendations for cost optimization, security, fault tolerance, etc.
  • Azure Advisor: Recommendations across cost, security, performance, reliability.

Open-source / self-managed alternatives

  • Custom scripts scanning Cloud Asset Inventory exports + policy rules.
  • Policy-as-code engines (for enforcement) such as Open Policy Agent (OPA) / custom compliance rules—these usually enforce constraints but don’t provide the same managed, usage-signal-based recommendation feed.

Comparison table

Option Best For Strengths Weaknesses When to Choose
Google Cloud Recommender Native recommendations & insights in Google Cloud API + Console integration; structured recommendation objects; hierarchy support Coverage varies; not real-time; applying fixes is external You want a managed recommendation feed and want to operationalize it
Active Assist (Console recommendations) Human-driven review Easy UI; no coding Hard to scale across many projects; limited automation Small teams or ad-hoc reviews
Security Command Center Security posture & findings Broad security visibility; findings aggregation Not a replacement for optimization recommenders; different object model Security teams running centralized security operations
Cloud Asset Inventory + custom rules Custom governance Full inventory; flexible rule logic You must build/maintain rules, pipelines, and evidence You need custom checks not covered by Recommender
AWS Trusted Advisor AWS environments Broad recommendation coverage for AWS Not Google Cloud-native Multi-cloud teams comparing AWS posture
Azure Advisor Azure environments Native Azure recommendations Not Google Cloud-native Multi-cloud teams comparing Azure posture

15. Real-World Example

Enterprise example (regulated industry)

  • Problem: A financial services organization runs hundreds of Google Cloud projects with complex IAM policies. Audit findings show overprivileged service accounts and inconsistent review processes.
  • Proposed architecture:
  • Central Cloud Run job scheduled daily to query Recommender across critical folders/projects.
  • Recommendations stored in BigQuery with metadata: business unit, app owner, environment.
  • Dashboards for security governance and weekly review meetings.
  • Remediation done via change requests; high-impact IAM changes require approval.
  • Why Recommender was chosen:
  • Native Google Cloud IAM recommendation capabilities (where available) align with least-privilege goals.
  • Structured recommendation objects fit governance reporting and ticketing.
  • Expected outcomes:
  • Reduced standing access over time.
  • Measurable metrics: active IAM recommendations aging, closure rate, and dismissal reasons.
  • Faster audit responses due to consistent evidence and reporting.

Startup / small-team example

  • Problem: A startup moves quickly and repeatedly leaves dev resources running, causing surprise bills. The team also struggles to keep IAM permissions tight as new engineers join.
  • Proposed architecture:
  • Weekly review of Recommender in Console.
  • Lightweight script (Cloud Shell or GitHub Actions using Workload Identity Federation) to pull recommendations and post a summary in Slack.
  • Manual remediation during a weekly “cloud hygiene hour.”
  • Why Recommender was chosen:
  • Minimal setup, integrated into Google Cloud.
  • Helps highlight “easy wins” without building a full platform.
  • Expected outcomes:
  • Fewer idle resources and better cost predictability.
  • Cleaner IAM posture as the company grows.

16. FAQ

1) Is Recommender the same as Active Assist?
No. Active Assist is an umbrella/experience in Google Cloud that surfaces recommendations. Recommender is the service/API that provides many of those recommendation objects.

2) Does Recommender automatically fix issues?
Usually no. Recommender provides advice and structured operations, but applying changes requires separate action (manual or automated) and proper permissions.

3) Why do I see zero recommendations?
Common reasons: your project has no supported resources, the recommender isn’t applicable, or it needs more historical usage data. Zero is often normal for new projects.

4) Is Recommender global or regional?
The API is a global Google API endpoint. Many recommenders are accessed using the global location, but you should confirm the correct location for each recommender/insight type.

5) What permissions do I need to read recommendations?
Typically a Recommender viewer role on the relevant scope (project/folder/org/billing account). Verify current IAM roles and permissions in official docs.

6) What permissions do I need to apply a recommendation?
Permissions on the underlying resource (IAM, Compute, SQL, etc.). Recommender permissions alone are not enough.

7) Can I query recommendations at organization level?
Some recommenders support org/folder scopes. Support varies by recommender type.

8) How do I prevent teams from hiding security issues by dismissing recommendations?
Restrict who can dismiss; require standard dismissal reasons; audit dismissal actions; and review dismissal metrics regularly.

9) What is an etag and why do I need it?
It’s a concurrency token. When you update recommendation state, the API expects the current etag to prevent conflicting updates.

10) Can I export recommendations to BigQuery automatically?
You can build an ingestion pipeline using Cloud Run/Functions + Scheduler and store snapshots in BigQuery. If Google provides a native export for your scenario, verify in official docs.

11) How often are recommendations updated?
It depends on the recommender. Many are periodic and based on historical windows. Verify timelines per recommender in official docs.

12) Are recommendations always correct?
They’re best-practice signals and estimates. Always validate business context, dependencies, and potential downtime before applying changes.

13) Can I use Recommender in CI/CD?
Yes—many teams use it for reporting and gating (human-in-the-loop) rather than automatic enforcement. Be cautious about applying changes automatically.

14) What’s the difference between an insight and a recommendation?
An insight is an observation; a recommendation is an action to take. Insights often provide the “why” behind recommendations.

15) How do I discover recommender IDs without guessing names?
Use the API discovery endpoint to list recommenders for your scope (as shown in the lab), then use the returned IDs.

16) Does using the Recommender API cost money?
Often there is no direct cost, but you must verify current pricing. Indirect costs come from automation, storage (BigQuery), and applying changes to resources.

17. Top Online Resources to Learn Recommender

Resource Type Name Why It Is Useful
Official documentation Recommender documentation – https://cloud.google.com/recommender/docs Primary source for concepts, supported recommenders, and usage guidance
API reference Recommender REST API reference – https://cloud.google.com/recommender/docs/reference/rest Exact endpoints, request/response schemas, methods like listing and marking states
Product overview Active Assist – https://cloud.google.com/active-assist Explains how recommendations are surfaced in Google Cloud and how Recommender fits in
CLI reference gcloud Recommender command group – https://cloud.google.com/sdk/gcloud/reference/recommender If you prefer CLI over raw REST calls (verify available commands for your use case)
Pricing tool Google Cloud Pricing Calculator – https://cloud.google.com/products/calculator Estimate costs for automation around Recommender (Cloud Run, BigQuery, Scheduler)
IAM guidance Cloud IAM overview – https://cloud.google.com/iam/docs/overview Important background when using IAM-related recommendations
Governance/inventory Cloud Asset Inventory – https://cloud.google.com/asset-inventory/docs/overview Useful for correlating recommendations with asset inventory and ownership metadata
Monitoring basics Cloud Monitoring – https://cloud.google.com/monitoring/docs Helps interpret utilization-based recommendations and validate changes
Logging/auditing Cloud Audit Logs – https://cloud.google.com/logging/docs/audit Track who changed resources after reviewing recommendations
Architecture guidance Google Cloud Architecture Center – https://cloud.google.com/architecture Patterns for building governance pipelines (useful for exporting and reporting)

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps engineers, SREs, platform teams Google Cloud operations, automation, governance fundamentals (verify course specifics) Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers DevOps and cloud learning paths; foundations that complement Recommender usage Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud operations teams Cloud operations practices, monitoring, cost and governance topics Check website https://www.cloudopsnow.in/
SreSchool.com SREs, reliability engineers Reliability practices, operational maturity, using signals for continuous improvement Check website https://www.sreschool.com/
AiOpsSchool.com Ops teams exploring automation Operational analytics, automation approaches, integrating recommendation signals Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud training content (verify current offerings) Students, engineers seeking guided learning https://rajeshkumar.xyz/
devopstrainer.in DevOps training platform (verify specifics) DevOps engineers, SREs https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps expertise platform (verify services) Teams needing short-term coaching/support https://www.devopsfreelancer.com/
devopssupport.in DevOps support and training (verify scope) Ops teams needing hands-on support https://www.devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps consulting (verify current portfolio) Building automation pipelines and governance reporting Recommender aggregation to BigQuery; dashboards; operational workflows https://cotocus.com/
DevOpsSchool.com DevOps and cloud consulting/training Process + tooling implementation Governance workflows; Cloud Run ingestion pipeline; IAM review processes https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting services Platform ops, CI/CD, cloud governance accelerators Recommendation-driven ticketing workflows; landing zone governance https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Recommender

  • Google Cloud fundamentals:
  • Projects, folders, organizations, billing accounts
  • IAM principals, roles, policies, service accounts
  • Operational basics:
  • Cloud Logging and Cloud Monitoring
  • Cost management basics (billing reports, budgets)
  • API consumption:
  • OAuth tokens, service accounts, gcloud and REST APIs

What to learn after Recommender

  • Building governance pipelines:
  • Cloud Scheduler + Cloud Run/Functions
  • Pub/Sub and alerting integrations
  • BigQuery modeling for time-series snapshots
  • Policy and security tooling:
  • Security Command Center (security posture)
  • Organization Policy Service (guardrails)
  • Cloud Asset Inventory for inventory and compliance
  • FinOps practices:
  • KPI design (savings realized vs opportunities)
  • Chargeback/showback models
  • Optimization lifecycle management

Job roles that use it

  • Cloud engineer / platform engineer
  • SRE / operations engineer
  • Security engineer (especially IAM governance)
  • FinOps analyst / cloud cost engineer
  • DevOps engineer building automation pipelines

Certification path (if available)

There is no separate “Recommender certification.” Instead, Recommender knowledge supports: – Google Cloud Associate/Professional certifications (architect, DevOps, security) by strengthening optimization and governance skills. Verify current certification paths at: https://cloud.google.com/learn/certification

Project ideas for practice

  • Build a daily Recommender harvester (Cloud Run) that writes to BigQuery.
  • Create a dashboard showing:
  • Count of active recommendations by category
  • Aging buckets (0–7 days, 8–30, 30+)
  • Dismissal reasons frequency
  • Integrate with a ticketing system:
  • Create tickets for high-impact recommendations
  • Auto-assign based on project labels
  • Create a “human-in-the-loop” workflow:
  • Generate a weekly report
  • Require approval before applying any changes

22. Glossary

  • Active Assist: Google Cloud umbrella for assistive features, including recommendations surfaced in Console.
  • Recommender: Google Cloud service that produces recommendations and insights; accessed via the Recommender API.
  • Recommender API: The REST API (recommender.googleapis.com) used to list and manage recommendations and insights.
  • Recommendation: An actionable suggestion to change a configuration or resource.
  • Insight: An observation that can explain why a recommendation exists.
  • Recommender ID: Identifier for a recommender type (returned by discovery endpoints).
  • Insight type ID: Identifier for an insight type (returned by discovery endpoints).
  • Scope: The resource container you query (project/folder/organization/billing account).
  • Location: Recommender API location segment (often global) used in resource names.
  • etag: Concurrency token required to update recommendation state safely.
  • Dismiss: Marking a recommendation as not applicable or intentionally not acted upon (with reasons/metadata).
  • Claim/Succeed/Fail: Lifecycle states used in workflows to indicate ownership and outcome (method availability varies).
  • Least privilege: IAM practice of granting only the minimum permissions necessary.
  • FinOps: Cloud financial operations discipline—cost governance, optimization, and accountability.

23. Summary

Google Cloud Recommender is a managed service in the Access and resource management ecosystem that provides recommendations and insights to help you improve cloud cost efficiency, security posture (especially IAM hygiene), reliability, and operational manageability—depending on which recommenders apply to your environment.

It matters because it turns optimization from an occasional, manual audit into a continuous, measurable process that scales across projects and teams. Architecturally, it fits best as an input signal to governance pipelines: query recommendations via the Recommender API, triage and prioritize using impact metadata, route work to owners, then track lifecycle state.

Cost-wise, the biggest drivers are typically indirect (automation compute, analytics storage, and the downstream impact of applying changes), so treat Recommender as part of a broader ops/FinOps system. Security-wise, implement least-privilege access to recommendation state updates and require approvals for sensitive remediations (especially IAM changes).

Use Recommender when you want a native, programmatic recommendation feed for Google Cloud. Next step: build a small pipeline that snapshots recommendations into BigQuery and produces an actionable weekly report for your teams, then expand into ticketing and approval workflows as you mature.