{"id":538,"date":"2026-04-14T10:36:09","date_gmt":"2026-04-14T10:36:09","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-service-usage-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management\/"},"modified":"2026-04-14T10:36:09","modified_gmt":"2026-04-14T10:36:09","slug":"google-cloud-service-usage-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-service-usage-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management\/","title":{"rendered":"Google Cloud Service Usage Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Access and resource management"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Access and resource management<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p><strong>What this service is<\/strong><br\/>\nService Usage is a Google Cloud control-plane service that lets you <strong>view, enable, and disable Google Cloud APIs and services<\/strong> for a project, and <strong>inspect and manage certain service quotas<\/strong> (where supported).<\/p>\n\n\n\n<p><strong>Simple explanation (one paragraph)<\/strong><br\/>\nIn Google Cloud, most capabilities (like Compute Engine, Cloud Storage, BigQuery, or Cloud Run) are exposed through APIs. Service Usage is the place where you turn those APIs \u201con\u201d or \u201coff\u201d for a project and confirm what\u2019s enabled. It also helps you understand and, in some cases, adjust how much of a service your project is allowed to consume (quotas).<\/p>\n\n\n\n<p><strong>Technical explanation (one paragraph)<\/strong><br\/>\nService Usage provides an API (<code>serviceusage.googleapis.com<\/code>) and corresponding Console and gcloud workflows that operate on resources like <code>projects\/{project}\/services\/{service}<\/code>. It returns service states (enabled\/disabled), supports batch enabling, supports disabling with optional dependency handling, and exposes \u201cconsumer quota\u201d endpoints for listing quota metrics and managing quota overrides (subject to service support and permissions). It integrates with IAM for authorization and Cloud Audit Logs for governance.<\/p>\n\n\n\n<p><strong>What problem it solves<\/strong><br\/>\nWithout a centralized mechanism, controlling which APIs are active in a project becomes inconsistent and risky: engineers may enable APIs ad hoc, security teams may lose visibility, and operations teams may encounter failures caused by missing or accidentally disabled APIs. Service Usage solves this by providing a <strong>standard, auditable<\/strong> way to manage API activation and (where applicable) quota configuration\u2014an essential part of <strong>Access and resource management<\/strong> on Google Cloud.<\/p>\n\n\n\n<blockquote>\n<p>Service name status note: The current product and API are commonly referred to as <strong>Service Usage<\/strong> and the <strong>Service Usage API<\/strong>. It is an active Google Cloud service. Verify the latest naming and capabilities in the official docs: https:\/\/cloud.google.com\/service-usage\/docs<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Service Usage?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Service Usage is designed to help Google Cloud customers <strong>manage the usage of Google Cloud services<\/strong> in their projects by:\n&#8211; Enabling\/disabling services (APIs)\n&#8211; Listing enabled\/available services\n&#8211; Understanding and managing service usage limits (quotas) where supported<\/p>\n\n\n\n<p>Official documentation entry point: https:\/\/cloud.google.com\/service-usage\/docs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Enable services\/APIs<\/strong> on a per-project basis (including batch enable).<\/li>\n<li><strong>Disable services\/APIs<\/strong> (optionally addressing dependent services, depending on method).<\/li>\n<li><strong>Discover<\/strong> which services are enabled and which are available for a project.<\/li>\n<li><strong>Quota visibility<\/strong>: list consumer quota metrics and current limits for supported services.<\/li>\n<li><strong>Quota override management<\/strong> (for supported quotas): configure overrides to cap or adjust usage limits (subject to service rules and permissions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service Usage API<\/strong> (<code>serviceusage.googleapis.com<\/code>)<\/li>\n<li>REST and client libraries<\/li>\n<li>Long-running operations for enable\/disable and batch operations<\/li>\n<li><strong>Google Cloud Console integration<\/strong><\/li>\n<li>\u201cAPIs &amp; Services\u201d and API Library rely on Service Usage behind the scenes<\/li>\n<li><strong>gcloud CLI integration<\/strong><\/li>\n<li><code>gcloud services ...<\/code> commands for enable\/disable\/list<\/li>\n<li><code>gcloud services quotas ...<\/code> commands for quota inspection and some overrides<\/li>\n<\/ul>\n\n\n\n<p>gcloud reference: https:\/\/cloud.google.com\/sdk\/gcloud\/reference\/services<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane \/ management plane<\/strong> service<\/li>\n<li>Not a data processing service; it governs whether other services can be called and what quotas apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional\/global\/project-scoped)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Project-scoped<\/strong> for enabling\/disabling APIs: you enable a service for a specific <strong>Google Cloud project<\/strong>.<\/li>\n<li>The Service Usage control plane itself is <strong>global<\/strong> in the sense that you do not deploy it into a region or zone.<\/li>\n<li>Quota and service state are associated with a project\u2019s service consumer relationship.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Service Usage sits at the intersection of:\n&#8211; <strong>IAM (Identity and Access Management)<\/strong>: who can enable\/disable services and modify quotas\n&#8211; <strong>Resource Manager<\/strong>: projects as the core boundary for service consumption\n&#8211; <strong>Cloud Audit Logs<\/strong>: audit trails for service enablement\/disablement and quota changes\n&#8211; <strong>Service Infrastructure<\/strong>: the underlying platform used by Google to deliver and meter APIs (Service Management and Service Control are related but distinct)<\/p>\n\n\n\n<p>Practical takeaway: <strong>If your workload uses Google Cloud, you almost always use Service Usage\u2014directly or indirectly\u2014because APIs must be enabled for a project before use.<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Service Usage?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Governance and cost control<\/strong>: reduce accidental enablement of expensive APIs and limit runaway consumption through quotas.<\/li>\n<li><strong>Standardization<\/strong>: define an approved catalog of services and ensure projects start from a known baseline.<\/li>\n<li><strong>Auditability<\/strong>: provide evidence of change control for API activation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deterministic deployments<\/strong>: infrastructure-as-code and CI\/CD pipelines can ensure required APIs are enabled before creating resources.<\/li>\n<li><strong>Fewer \u201cit worked in dev\u201d surprises<\/strong>: consistent service enablement across environments.<\/li>\n<li><strong>Dependency management<\/strong>: some services require other APIs; Service Usage helps enable dependencies (often automatically or via prompts).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster troubleshooting<\/strong>: quickly confirm if an API is disabled when errors like <code>SERVICE_DISABLED<\/code> occur.<\/li>\n<li><strong>Quota visibility<\/strong>: identify request rate limits and other constraints that can cause throttling.<\/li>\n<li><strong>Operational safety<\/strong>: disable unused APIs to reduce accidental use and noise.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduced attack surface<\/strong>: fewer enabled APIs can mean fewer ways to misuse credentials.<\/li>\n<li><strong>Policy enforcement<\/strong>: with Organization Policy constraints (where applicable), organizations can restrict which services are allowed to be enabled. (Verify exact constraint names and behavior in official docs.)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Quota planning<\/strong>: knowing default limits helps you scale safely (e.g., request quotas, per-minute quotas).<\/li>\n<li><strong>Controlled rollout<\/strong>: gradually enable APIs and set conservative quotas for new teams\/projects.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Use Service Usage when you need:\n&#8211; Repeatable project bootstrapping\n&#8211; Central visibility into enabled services\n&#8211; Programmatic API enablement\/disablement\n&#8211; Quota inspection and (where supported) quota override management<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Service Usage is <strong>not<\/strong> the right tool for:\n&#8211; Fine-grained authorization of API calls at runtime (use IAM roles, service accounts, VPC Service Controls, API Gateway, etc.)\n&#8211; Monitoring usage cost directly (use Cloud Billing reports\/exports)\n&#8211; Managing service-to-service networking (use VPC, Private Service Connect, etc.)\n&#8211; Producing your own managed APIs for external consumers (look at API Gateway, Cloud Endpoints, Apigee, and Service Management\/Service Control)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Service Usage used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Service Usage is broadly applicable in any industry using Google Cloud, especially:\n&#8211; Financial services (strong governance and audit requirements)\n&#8211; Healthcare and life sciences (compliance-driven controls)\n&#8211; Retail\/e-commerce (fast-changing environments with many projects)\n&#8211; Media\/gaming (high scale and quota awareness)\n&#8211; SaaS and startups (rapid iteration with cost controls)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering \/ cloud center of excellence (CCoE)<\/li>\n<li>DevOps \/ SRE \/ operations<\/li>\n<li>Security engineering \/ GRC teams<\/li>\n<li>Application development teams<\/li>\n<li>Data engineering teams<\/li>\n<li>FinOps \/ cost management teams<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices on Cloud Run \/ GKE<\/li>\n<li>Data platforms on BigQuery \/ Dataflow<\/li>\n<li>Event-driven systems (Pub\/Sub)<\/li>\n<li>ML pipelines (Vertex AI)<\/li>\n<li>Enterprise landing zones (org\/folder\/project hierarchy)<\/li>\n<li>Multi-project environments (per-team or per-environment isolation)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Landing zone \/ project factory<\/strong>: new projects created with a baseline set of enabled APIs.<\/li>\n<li><strong>CI\/CD guardrails<\/strong>: pipelines that refuse to deploy unless required APIs are enabled.<\/li>\n<li><strong>Incident response<\/strong>: identify whether an outage is caused by a disabled API or quota limit.<\/li>\n<li><strong>Security hardening<\/strong>: periodic review to disable unused APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: frequent enabling\/disabling during experimentation; more tolerant of changes.<\/li>\n<li><strong>Production<\/strong>: strict change control; enabling\/disabling APIs should be reviewed because disabling can break workloads immediately.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Service Usage is central.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Project bootstrap (\u201cAPI baseline\u201d)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: New projects start empty; engineers forget to enable required APIs.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Programmatically enable a standard set of APIs at project creation.<\/li>\n<li><strong>Example<\/strong>: A platform team creates a \u201cweb-app-prod\u201d project and immediately enables Cloud Run, Artifact Registry, Cloud Build, Secret Manager, and Logging APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) CI\/CD preflight checks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Deployments fail mid-pipeline because an API is disabled.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Check and enable APIs as a pipeline step.<\/li>\n<li><strong>Example<\/strong>: A Terraform pipeline runs <code>gcloud services enable ...<\/code> before applying infrastructure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Reduce security exposure by disabling unused APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Too many enabled services increase risk and audit scope.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Inventory enabled APIs and disable the ones not needed.<\/li>\n<li><strong>Example<\/strong>: A security review finds Google Sheets API enabled in a production project with no usage; it is disabled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Investigate <code>SERVICE_DISABLED<\/code> errors<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Applications suddenly fail with \u201cAPI has not been used in project before or it is disabled\u201d.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Quickly verify the service enablement state.<\/li>\n<li><strong>Example<\/strong>: After a project migration, Pub\/Sub calls fail\u2014Service Usage shows <code>pubsub.googleapis.com<\/code> is disabled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Controlled rollout of new capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams want to adopt a new API, but leadership wants staged enablement.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Enable API only in sandbox first, then in dev, then production.<\/li>\n<li><strong>Example<\/strong>: Enable Vertex AI only for the ML sandbox project until governance is ready.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Quota visibility for scale planning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need to know which quotas might throttle a launch.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: List quota metrics and limits for critical services.<\/li>\n<li><strong>Example<\/strong>: Before a marketing event, the team checks API request quotas for a backend service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Quota guardrails to prevent runaway cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A bug can generate massive requests and unexpected charges.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Where supported, apply conservative quota overrides as circuit breakers.<\/li>\n<li><strong>Example<\/strong>: Cap a high-cost API\u2019s requests\/day so a bad deploy cannot explode usage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Standardize service catalog across many projects<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Different teams enable different APIs, complicating governance.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Enforce or validate a known list of enabled services.<\/li>\n<li><strong>Example<\/strong>: An org mandates only approved APIs can be enabled in production folders (often paired with Organization Policy).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) M&amp;A \/ migration: reconcile enabled services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Migrated workloads depend on APIs that are not enabled in the destination project.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Compare enabled services between source and destination projects.<\/li>\n<li><strong>Example<\/strong>: A script exports enabled services from old projects and applies the same set to new projects.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Troubleshoot quota-related errors (429 \/ RESOURCE_EXHAUSTED)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Requests are throttled with quota errors.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Inspect which quota metric is limiting you and current limits.<\/li>\n<li><strong>Example<\/strong>: Cloud Tasks enqueue calls return <code>RESOURCE_EXHAUSTED<\/code>; Service Usage helps identify the relevant quota metric.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Temporary lockdown during incident response<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Suspected credential compromise and potential abuse of an API.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Disable the abused API quickly to stop further calls (with awareness of production impact).<\/li>\n<li><strong>Example<\/strong>: Disable a high-risk API in a compromised project while rotating credentials.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Environment parity checks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Dev and prod drift in enabled services, causing behavior differences.<\/li>\n<li><strong>Why Service Usage fits<\/strong>: Compare lists of enabled APIs and reconcile differences.<\/li>\n<li><strong>Example<\/strong>: Prod has Cloud Scheduler enabled; dev does not, causing tests to miss scheduled execution flows.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 1: List enabled services for a project<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Shows services currently enabled in a project.<\/li>\n<li><strong>Why it matters<\/strong>: Your project can only call enabled services; this is the source of truth.<\/li>\n<li><strong>Practical benefit<\/strong>: Quick auditing and troubleshooting.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Some services may be enabled by default or required; exact defaults can vary\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 2: List available services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Shows services that can be enabled for a project.<\/li>\n<li><strong>Why it matters<\/strong>: Helps discover service names like <code>run.googleapis.com<\/code> or <code>storage.googleapis.com<\/code>.<\/li>\n<li><strong>Practical benefit<\/strong>: Automations can validate service availability before enabling.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Availability can depend on organization policies, billing status, region\/service constraints, and permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 3: Enable a service (API)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Activates a service for a project so that API requests are allowed.<\/li>\n<li><strong>Why it matters<\/strong>: Most Google Cloud services must be enabled before use.<\/li>\n<li><strong>Practical benefit<\/strong>: Enables consistent infrastructure provisioning and application deployments.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Enablement is not always instantaneous; propagation may take time.<\/li>\n<li>Enabling some services may require enabling dependencies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 4: Batch enable services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables multiple services in one operation.<\/li>\n<li><strong>Why it matters<\/strong>: Project bootstrapping often needs multiple APIs.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster setup; fewer manual steps.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Batch operations are still subject to permissions and dependency requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 5: Disable a service (API)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Deactivates a service for a project so API requests fail.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces usage surface area and can stop unwanted consumption.<\/li>\n<li><strong>Practical benefit<\/strong>: Security hardening and cost control.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Disabling can immediately break production workloads.<\/li>\n<li>Disabling an API does not necessarily delete existing resources created by that API; behavior varies by service\u2014verify per-service docs.<\/li>\n<li>Dependency handling must be considered; disabling a dependency can break other enabled services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 6: Dependency awareness when disabling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Some workflows allow disabling dependent services (or require you to address them).<\/li>\n<li><strong>Why it matters<\/strong>: Services can rely on others (e.g., build\/deploy stacks).<\/li>\n<li><strong>Practical benefit<\/strong>: Avoid partial failures caused by leaving dependents in inconsistent states.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Options vary by tool\/command and service graph; validate with your chosen method (Console, gcloud, API).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 7: Get service state and metadata<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Retrieves a service\u2019s state (enabled\/disabled) and related details for a project.<\/li>\n<li><strong>Why it matters<\/strong>: Useful for programmatic checks and \u201cpreflight\u201d validations.<\/li>\n<li><strong>Practical benefit<\/strong>: Automated deployment guardrails.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Requires correct service name and permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 8: Quota visibility (consumer quota metrics)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lists quota metrics and limits tied to a service for a project (where supported).<\/li>\n<li><strong>Why it matters<\/strong>: Quotas commonly cause production throttling.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster troubleshooting and capacity planning.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Not all quotas are adjustable; some are fixed, some require quota increase requests, and some are managed in newer quota experiences. Verify per service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 9: Quota override management (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Creates\/updates quota overrides to adjust limits (commonly used to <em>reduce<\/em> limits as a safety control, or manage approved limits depending on service and permissions).<\/li>\n<li><strong>Why it matters<\/strong>: Prevent runaway usage; align limits with policy.<\/li>\n<li><strong>Practical benefit<\/strong>: \u201cCircuit breaker\u201d controls.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Not all quota metrics allow overrides.<\/li>\n<li>Increasing limits often requires an approval process outside of overrides.<\/li>\n<li>Google Cloud\u2019s quota tooling evolves; verify whether a given quota should be managed via Service Usage or newer quota tooling in the Console for that service.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Service Usage is a <strong>central control plane<\/strong> that governs whether a project is a consumer of a given Google Cloud service API. When you enable an API:\n1. Service Usage records the enablement state for the project.\n2. The target service\u2019s infrastructure recognizes the project as an authorized consumer (subject to IAM, billing, org policy, and quotas).\n3. Requests to the target service API become valid (again, subject to authz and quotas).<\/p>\n\n\n\n<p>When you disable an API:\n1. Service Usage marks it disabled for the project.\n2. Calls to that API for that project typically fail with a \u201cservice disabled\u201d error.\n3. Existing resources are not necessarily removed; behavior depends on the service.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane path<\/strong>: Administrator or automation \u2192 Service Usage API \u2192 service enablement state stored\/propagated \u2192 target service accepts\/rejects calls.<\/li>\n<li><strong>Runtime data plane path<\/strong>: Application \u2192 target service API endpoint \u2192 enforcement checks:<\/li>\n<li>Is the service enabled for the project?<\/li>\n<li>Does the caller have IAM permission?<\/li>\n<li>Are quotas exceeded?<\/li>\n<li>Are there policy restrictions (e.g., VPC Service Controls perimeter, org policy restrictions)?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong>: controls who can enable\/disable services and modify quota overrides.<\/li>\n<li><strong>Cloud Resource Manager<\/strong>: project identification and hierarchy.<\/li>\n<li><strong>Organization Policy Service<\/strong>: can restrict which services may be enabled (constraint-based).<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: records administrative actions for governance.<\/li>\n<li><strong>Infrastructure as Code<\/strong>:<\/li>\n<li>Terraform <code>google_project_service<\/code> commonly enables APIs (uses Google APIs under the hood).<\/li>\n<li>Other IaC tools (Pulumi, Config Connector) also need APIs enabled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Service Usage doesn\u2019t \u201crun\u201d inside your VPC; instead it orchestrates enablement for services that may have their own dependencies. In real deployments:\n&#8211; Your CI\/CD system (Cloud Build, GitHub Actions, Jenkins) calls Service Usage.\n&#8211; Terraform\/Deployment tools call Service Usage (directly or indirectly).\n&#8211; The application then calls the enabled service APIs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authentication<\/strong>: Typically OAuth 2.0 access tokens via:<\/li>\n<li>User credentials (admin\/operator)<\/li>\n<li>Service accounts (CI\/CD automation)<\/li>\n<li><strong>Authorization<\/strong>: IAM permissions such as:<\/li>\n<li>Viewing service enablement<\/li>\n<li>Enabling\/disabling services<\/li>\n<li>Viewing\/managing quotas (where supported)<\/li>\n<\/ul>\n\n\n\n<p>Common predefined roles (verify in IAM docs for latest):\n&#8211; <code>roles\/serviceusage.serviceUsageViewer<\/code>\n&#8211; <code>roles\/serviceusage.serviceUsageAdmin<\/code><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage is a Google-managed API endpoint accessed over the public internet.<\/li>\n<li>Access is typically via:<\/li>\n<li>Google Cloud Console<\/li>\n<li>gcloud CLI<\/li>\n<li>REST calls to <code>https:\/\/serviceusage.googleapis.com\/<\/code><\/li>\n<li>If you enforce restricted network egress, ensure your admin tooling can reach required Google APIs. For private access patterns, evaluate Google\u2019s private access options and constraints (varies by API)\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Audit Logs<\/strong>: Admin Activity logs track enable\/disable operations and quota changes (where applicable).<\/li>\n<li><strong>Cloud Logging<\/strong>: central place to query these audit entries.<\/li>\n<li><strong>Cloud Monitoring<\/strong>: Service Usage itself isn\u2019t typically \u201cmonitored\u201d like a workload, but you can monitor:<\/li>\n<li>automation failures<\/li>\n<li>API errors returned from services due to disabled APIs or quota limits<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  A[Admin \/ CI Pipeline] --&gt;|gcloud \/ Console \/ REST| SU[Service Usage API]\n  SU --&gt;|Enable\/Disable state| P[(Google Cloud Project)]\n  App[Application] --&gt;|Calls API| SVC[Target Google Cloud API\\n(e.g., storage.googleapis.com)]\n  SVC --&gt;|Checks service enabled + IAM + quota| P\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Organization \/ Governance]\n    OP[Organization Policy\\n(allowed services constraints)]\n    IAM[IAM Roles &amp; Service Accounts]\n    AL[Cloud Audit Logs]\n  end\n\n  subgraph Delivery[Platform Engineering]\n    Repo[Git Repo\\nTerraform \/ Scripts]\n    CI[CI\/CD\\nCloud Build \/ GitHub Actions]\n  end\n\n  subgraph Project[Google Cloud Project]\n    SU[Service Usage\\nEnable\/Disable + Quotas]\n    S1[Cloud Run API]\n    S2[Artifact Registry API]\n    S3[Cloud Storage API]\n  end\n\n  Repo --&gt; CI\n  CI --&gt;|Auth as SA| IAM\n  CI --&gt;|Enable required APIs| SU\n  OP --&gt;|Restricts what can be enabled| SU\n  SU --&gt; S1\n  SU --&gt; S2\n  SU --&gt; S3\n  SU --&gt; AL\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with access to a <strong>Google Cloud project<\/strong>.<\/li>\n<li>Ability to create projects (optional for this tutorial; you can use an existing project).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>At minimum, you need permissions to:\n&#8211; View services: typically <code>roles\/serviceusage.serviceUsageViewer<\/code>\n&#8211; Enable\/disable services: typically <code>roles\/serviceusage.serviceUsageAdmin<\/code><\/p>\n\n\n\n<p>If you are using a service account for automation, grant the necessary roles <strong>to that service account<\/strong> at the project level.<\/p>\n\n\n\n<blockquote>\n<p>Principle of least privilege: avoid granting broad roles like <code>roles\/owner<\/code> just to manage APIs.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage itself does not generally require billing to be enabled.<\/li>\n<li><strong>Many Google Cloud services require a billing account<\/strong> to create billable resources. Enabling an API alone usually does not incur charges, but using it may.<\/li>\n<li>If you enable a paid API and then create resources, billing will apply per that service\u2019s pricing.<\/li>\n<\/ul>\n\n\n\n<p>Verify service prerequisites in their docs and pricing pages.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud SDK (gcloud)<\/strong>: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>A terminal with:<\/li>\n<li><code>gcloud<\/code><\/li>\n<li><code>curl<\/code> (optional, for direct REST calls)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage is a global management service and not deployed to a region.<\/li>\n<li>The services you enable may have regional constraints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage operations can be subject to API rate limits and permissions.<\/li>\n<li>Quota override support varies by service and metric.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In many projects, the Service Usage API is available by default. If you encounter errors indicating it is disabled, enable <strong>Service Usage API<\/strong> in the Console API Library:<\/li>\n<li>https:\/\/console.cloud.google.com\/apis\/library\/serviceusage.googleapis.com<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (accurate overview)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service Usage itself is generally provided at no additional cost<\/strong> as a management\/control-plane API.<\/li>\n<li><strong>The services\/APIs you enable may be billable<\/strong> based on their own pricing models.<\/li>\n<\/ul>\n\n\n\n<p>Because pricing is primarily driven by downstream services, the key cost question is not \u201cHow much does Service Usage cost?\u201d but rather:\n&#8211; <strong>Which APIs did you enable, and what usage do they incur?<\/strong><\/p>\n\n\n\n<p>Official starting points:\n&#8211; Service Usage docs: https:\/\/cloud.google.com\/service-usage\/docs\n&#8211; Google Cloud pricing overview: https:\/\/cloud.google.com\/pricing\n&#8211; Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions<\/h3>\n\n\n\n<p>Service Usage does not typically expose SKUs you pay for directly. Cost drivers arise indirectly:\n1. <strong>Downstream service usage<\/strong>: API requests, compute, storage, managed resources, etc.\n2. <strong>Logging retention\/volume<\/strong>:\n   &#8211; Admin Activity audit logs are generally enabled by default for many services and are not billed the same way as data access logs; billing depends on log type and exports\/retention. Verify Cloud Logging pricing details: https:\/\/cloud.google.com\/logging\/pricing\n3. <strong>Automation overhead<\/strong>:\n   &#8211; CI\/CD steps that repeatedly query\/enable services usually have negligible cost, but they can hit rate limits or produce logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage does not have a typical \u201cfree tier\u201d concept because it is not usually billed directly.<\/li>\n<li>Many Google Cloud services have free tiers or always-free quotas; check each service\u2019s pricing page.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Accidental enablement of expensive APIs<\/strong> and subsequent resource creation (e.g., deploying managed databases, running data processing jobs).<\/li>\n<li><strong>Dependency enablement<\/strong>: enabling one service might lead teams to enable several dependent services, expanding footprint.<\/li>\n<li><strong>Quota increases<\/strong> can enable higher throughput, which can increase spend if usage scales.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enabling an API does not transfer your workload data.<\/li>\n<li>Using enabled services may involve:<\/li>\n<li>inter-region egress<\/li>\n<li>internet egress<\/li>\n<li>cross-service data movement<br\/>\n  These are billed per the downstream service and network pricing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate<\/h3>\n\n\n\n<p>A realistic \u201cstarter\u201d scenario:\n&#8211; You use Service Usage to enable a few APIs (e.g., Cloud Storage API, Cloud Run API), <strong>but you do not create billable resources<\/strong>.\n&#8211; <strong>Expected cost<\/strong>: typically $0 from Service Usage; downstream costs remain $0 if you do not use paid resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, cost management becomes about:\n&#8211; Only enabling approved APIs\n&#8211; Setting guardrails (quotas where supported)\n&#8211; Monitoring usage and spend for enabled services (Billing reports\/exports)\n&#8211; Periodic audits of enabled services to reduce sprawl<\/p>\n\n\n\n<p>Cost optimization checklist:\n&#8211; Maintain an \u201capproved services list\u201d for production projects.\n&#8211; Use Organization Policy restrictions where applicable (verify official docs).\n&#8211; Use least privilege for who can enable services.\n&#8211; Add CI checks that prevent enabling unapproved APIs.\n&#8211; Regularly export enabled services list and review with security\/FinOps.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Use Service Usage in Google Cloud to:\n1. List enabled services in a project\n2. Enable a Google Cloud API\n3. Verify enablement via gcloud and direct REST calls\n4. Inspect quota metrics for that service (read-only)\n5. Clean up by disabling the service (or deleting the project)<\/p>\n\n\n\n<p>This lab is designed to be <strong>safe and low-cost<\/strong> by avoiding creation of billable resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n&#8211; Select or create a Google Cloud project\n&#8211; Use <code>gcloud services<\/code> to inventory APIs\n&#8211; Enable <code>storage.googleapis.com<\/code> (Cloud Storage API) as an example\n&#8211; Validate the service is enabled\n&#8211; View quota metrics (if available)\n&#8211; Disable the service to return the project to the prior state<\/p>\n\n\n\n<blockquote>\n<p>Note: Cloud Storage itself can incur costs if you create buckets, store data, or generate requests. This lab does <strong>not<\/strong> create any buckets or objects.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up gcloud and pick a project<\/h3>\n\n\n\n<p>1) Install and initialize gcloud (if not already):\n&#8211; Install: https:\/\/cloud.google.com\/sdk\/docs\/install\n&#8211; Initialize:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud init\n<\/code><\/pre>\n\n\n\n<p>2) Choose an existing project <strong>or create a new one<\/strong>.<\/p>\n\n\n\n<p>To create a new project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"su-lab-$(date +%Y%m%d%H%M%S)\"\ngcloud projects create \"$PROJECT_ID\" --name=\"Service Usage Lab\"\n<\/code><\/pre>\n\n\n\n<p>Set it as default:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project \"$PROJECT_ID\"\n<\/code><\/pre>\n\n\n\n<p>Fetch the project number (useful for some API calls):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_NUMBER=\"$(gcloud projects describe \"$PROJECT_ID\" --format='value(projectNumber)')\"\necho \"$PROJECT_NUMBER\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; You have a project ID selected in gcloud config.\n&#8211; You know the project number.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Confirm you have the required permissions<\/h3>\n\n\n\n<p>If you lack permissions, you may see <code>PERMISSION_DENIED<\/code> errors when listing or enabling services.<\/p>\n\n\n\n<p>Check your active identity:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth list\ngcloud config list account\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; You can identify which user\/service account is being used.<\/p>\n\n\n\n<p>If you are in a managed environment, ask an administrator to grant one of:\n&#8211; <code>roles\/serviceusage.serviceUsageViewer<\/code> (read-only)\n&#8211; <code>roles\/serviceusage.serviceUsageAdmin<\/code> (enable\/disable)<\/p>\n\n\n\n<p>IAM roles reference (verify current roles and permissions):<br\/>\nhttps:\/\/cloud.google.com\/iam\/docs\/understanding-roles<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: List currently enabled services (API inventory)<\/h3>\n\n\n\n<p>List enabled services:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled\n<\/code><\/pre>\n\n\n\n<p>For a cleaner, script-friendly output:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --format=\"value(config.name)\" | sort\n<\/code><\/pre>\n\n\n\n<p>Save the enabled services to a file (useful for audits and change tracking):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --format=\"value(config.name)\" | sort &gt; enabled-services-before.txt\nwc -l enabled-services-before.txt\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; You see a list of enabled service names like <code>iam.googleapis.com<\/code>, <code>cloudresourcemanager.googleapis.com<\/code>, etc.<br\/>\n&#8211; You have an <code>enabled-services-before.txt<\/code> file capturing the baseline.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Check whether the target API is already enabled<\/h3>\n\n\n\n<p>We\u2019ll use the Cloud Storage API (<code>storage.googleapis.com<\/code>) as an example.<\/p>\n\n\n\n<p>Check status:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"config.name:storage.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<p>If nothing is returned, it is not enabled.<\/p>\n\n\n\n<p>You can also query the service directly:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services describe storage.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; You confirm whether <code>storage.googleapis.com<\/code> is enabled already.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Enable an API with Service Usage<\/h3>\n\n\n\n<p>Enable Cloud Storage API:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable storage.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; The command completes successfully.\n&#8211; The Storage API is now enabled for the project.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"config.name:storage.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<p>You should see <code>storage.googleapis.com<\/code> listed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Verify enablement via the Service Usage REST API (optional but recommended)<\/h3>\n\n\n\n<p>This step proves Service Usage is the control plane behind the scenes.<\/p>\n\n\n\n<p>1) Get an access token:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export ACCESS_TOKEN=\"$(gcloud auth print-access-token)\"\n<\/code><\/pre>\n\n\n\n<p>2) Call the Service Usage API to get the state.<\/p>\n\n\n\n<p>Resource name format:\n&#8211; <code>projects\/{projectNumber}\/services\/{serviceName}<\/code><br\/>\n(Using project number is common in examples; project ID may also work in some contexts\u2014verify if needed.)<\/p>\n\n\n\n<p>Call:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -sS -H \"Authorization: Bearer ${ACCESS_TOKEN}\" \\\n  \"https:\/\/serviceusage.googleapis.com\/v1\/projects\/${PROJECT_NUMBER}\/services\/storage.googleapis.com\" \\\n  | sed -e 's\/{\/{\\n{\/g' -e 's\/,\/,\\n\/g'\n<\/code><\/pre>\n\n\n\n<p>Look for:\n&#8211; <code>\"state\": \"ENABLED\"<\/code><\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; The JSON response shows <code>state<\/code> as <code>ENABLED<\/code>.<\/p>\n\n\n\n<p>If you see permission errors, confirm the caller has the right IAM role.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Inspect quota metrics for the enabled service (read-only)<\/h3>\n\n\n\n<p>Quota surfaces differ by service. Some services expose several quota metrics; others expose fewer. This step is still useful to learn the workflow.<\/p>\n\n\n\n<p>List quota metrics via gcloud:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services quotas list --service=storage.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>To reduce output, you can format specific fields (the exact fields available can vary):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services quotas list --service=storage.googleapis.com --format=\"table(metric,limit.name,limit.values)\"\n<\/code><\/pre>\n\n\n\n<p>If your gcloud version differs, run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services quotas list --help\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; You see quota metrics (if exposed) and current limits for the service.<\/p>\n\n\n\n<blockquote>\n<p>If quotas do not appear as expected, or if a service manages quotas differently, verify per-service quota documentation and the current Google Cloud quota tooling. The Console \u201cQuotas\u201d UI may show details even when CLI output is limited.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: (Practical automation) Create a preflight script to ensure required APIs are enabled<\/h3>\n\n\n\n<p>Create a file named <code>ensure-apis-enabled.sh<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; ensure-apis-enabled.sh &lt;&lt;'EOF'\n#!\/usr\/bin\/env bash\nset -euo pipefail\n\nREQUIRED_SERVICES=(\n  \"serviceusage.googleapis.com\"\n  \"storage.googleapis.com\"\n)\n\necho \"Project: $(gcloud config get-value project 2&gt;\/dev\/null)\"\necho \"Checking required services...\"\n\nfor svc in \"${REQUIRED_SERVICES[@]}\"; do\n  if gcloud services list --enabled --format=\"value(config.name)\" | grep -qx \"$svc\"; then\n    echo \"OK: $svc is enabled\"\n  else\n    echo \"Enabling: $svc\"\n    gcloud services enable \"$svc\"\n  fi\ndone\n\necho \"Done.\"\nEOF\n\nchmod +x ensure-apis-enabled.sh\n.\/ensure-apis-enabled.sh\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; The script reports enabled services and enables missing ones.\n&#8211; This is a common CI\/CD building block for reliable deployments.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Run these checks:<\/p>\n\n\n\n<p>1) Confirm Storage API enabled:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"config.name:storage.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<p>2) Compare before\/after service inventory:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --format=\"value(config.name)\" | sort &gt; enabled-services-after.txt\ndiff -u enabled-services-before.txt enabled-services-after.txt || true\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; You see <code>storage.googleapis.com<\/code> as an added enabled service (if it wasn\u2019t already enabled).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong><code>PERMISSION_DENIED<\/code> when enabling or listing services<\/strong>\n&#8211; Cause: Your identity lacks Service Usage permissions.\n&#8211; Fix: Ask for <code>roles\/serviceusage.serviceUsageViewer<\/code> (list) or <code>roles\/serviceusage.serviceUsageAdmin<\/code> (enable\/disable).<\/p>\n\n\n\n<p>2) <strong><code>SERVICE_DISABLED<\/code> when calling an API<\/strong>\n&#8211; Cause: The target API is disabled for the project.\n&#8211; Fix: Enable it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable &lt;service-name&gt;\n<\/code><\/pre>\n\n\n\n<p>Then wait a minute and retry.<\/p>\n\n\n\n<p>3) <strong>Enablement succeeded, but API calls still fail<\/strong>\n&#8211; Cause: Propagation delay or missing IAM permissions for the calling principal.\n&#8211; Fix:\n  &#8211; Wait briefly and retry.\n  &#8211; Verify the service account\/user has the right roles for the <em>target service<\/em> (Service Usage only enables the API; it does not grant runtime permissions).<\/p>\n\n\n\n<p>4) <strong>Dependencies block disable<\/strong>\n&#8211; Cause: Other services depend on the one you\u2019re disabling.\n&#8211; Fix:\n  &#8211; Review dependency warnings carefully.\n  &#8211; Avoid disabling dependencies in production without an impact review.\n  &#8211; Use the Console or API options carefully if you must disable dependent services (behavior differs by tool). Verify in official docs.<\/p>\n\n\n\n<p>5) <strong>Quotas output is empty or confusing<\/strong>\n&#8211; Cause: Not all services expose quotas in the same way; tooling may vary.\n&#8211; Fix: Check the service-specific quota documentation and the Console Quotas page; verify current guidance in official docs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Option A (recommended for this lab): disable the API you enabled:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services disable storage.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"config.name:storage.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:<br\/>\n&#8211; No output for the filter (service disabled).<\/p>\n\n\n\n<p>Option B (if you created a dedicated lab project): delete the project to remove everything:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects delete \"$PROJECT_ID\"\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Project deletion is irreversible and will delete all resources in the project. Use with care.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Treat API enablement as part of your platform \u201cbootstrap\u201d layer<\/strong>:<\/li>\n<li>Create a baseline enabled-services set per environment (dev\/test\/prod).<\/li>\n<li><strong>Separate duties<\/strong>:<\/li>\n<li>Platform automation can enable APIs; application teams consume them.<\/li>\n<li><strong>Design for dependency awareness<\/strong>:<\/li>\n<li>Document which APIs are required for each platform capability (e.g., Cloud Run + Artifact Registry + Cloud Build).<\/li>\n<li><strong>Use infrastructure-as-code<\/strong> for consistent enablement:<\/li>\n<li>Terraform <code>google_project_service<\/code> (or equivalent) is a common approach.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege<\/strong>:<\/li>\n<li>Grant <code>roles\/serviceusage.serviceUsageAdmin<\/code> only to a small set of platform operators or CI\/CD service accounts.<\/li>\n<li>Grant <code>roles\/serviceusage.serviceUsageViewer<\/code> broadly for visibility if appropriate.<\/li>\n<li><strong>Use separate service accounts for automation<\/strong>:<\/li>\n<li>Make changes traceable and reduce reliance on user accounts.<\/li>\n<li><strong>Protect who can enable high-risk APIs<\/strong>:<\/li>\n<li>Pair with Organization Policy restrictions where applicable (verify official docs and constraints).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Approve and document<\/strong> which APIs are allowed in production.<\/li>\n<li><strong>Disable unused APIs<\/strong> periodically (with impact analysis).<\/li>\n<li><strong>Use quota guardrails<\/strong> where supported to prevent runaway usage.<\/li>\n<li><strong>Monitor spend<\/strong> for enabled services using Cloud Billing reports\/exports rather than relying on enablement alone.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage is not in the runtime path for your workload\u2019s latency, but:<\/li>\n<li><strong>Quotas are<\/strong>. Keep quota limits and scaling plans aligned.<\/li>\n<li>Validate that high-throughput services have adequate quota before launch.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Avoid disabling APIs in production without a rollback plan<\/strong>.<\/li>\n<li><strong>Use change management<\/strong>:<\/li>\n<li>Treat enable\/disable operations like configuration changes.<\/li>\n<li><strong>Automate verification<\/strong>:<\/li>\n<li>Preflight checks in pipelines reduce production surprises.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Keep an inventory<\/strong> of enabled services per project and review it:<\/li>\n<li>Export the list regularly to a repository or asset inventory.<\/li>\n<li><strong>Centralize audit review<\/strong>:<\/li>\n<li>Use Cloud Logging queries on audit logs for enable\/disable actions.<\/li>\n<li><strong>Standard naming\/tagging<\/strong>:<\/li>\n<li>Use project labels and folder structure to reflect environment and ownership; it simplifies governance review.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Maintain:<\/li>\n<li>Project naming conventions (<code>app-env-region<\/code> patterns if helpful)<\/li>\n<li>Labels (owner, cost-center, data-classification)<\/li>\n<li>Apply organization policies (where supported) to restrict service enablement in production folders.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage is governed by <strong>IAM<\/strong>.<\/li>\n<li>You need separate permissions for:<\/li>\n<li>Enabling\/disabling services (control plane)<\/li>\n<li>Using the enabled service\u2019s APIs (runtime permissions)<\/li>\n<li>Avoid conflating these:<\/li>\n<li>Enabling <code>storage.googleapis.com<\/code> does not grant <code>storage.objects.get<\/code> or any data access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage is a management API; it does not store your application data.<\/li>\n<li>Google API calls are encrypted in transit (HTTPS).<\/li>\n<li>Data at rest concerns apply to downstream services (Cloud Storage, BigQuery, etc.).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage is reached via Google API endpoints.<\/li>\n<li>If your organization restricts egress, ensure admin tooling can reach required Google APIs.<\/li>\n<li>Consider organizational controls (proxy, egress controls) consistent with your governance model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid embedding long-lived credentials in scripts.<\/li>\n<li>Prefer:<\/li>\n<li>Workload Identity \/ short-lived credentials where applicable<\/li>\n<li>Service accounts with scoped IAM roles<\/li>\n<li>Rotate keys if you must use service account keys; consider avoiding keys entirely where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service enable\/disable events should be captured in <strong>Cloud Audit Logs<\/strong> (Admin Activity).<\/li>\n<li>Security teams should:<\/li>\n<li>Monitor for unexpected enablement of sensitive APIs<\/li>\n<li>Alert on changes in production projects\/folders<\/li>\n<\/ul>\n\n\n\n<p>Cloud Audit Logs overview: https:\/\/cloud.google.com\/logging\/docs\/audit<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Service Usage supports compliance indirectly through:\n&#8211; Auditability of changes\n&#8211; Enforceable governance (with org policy + IAM)\n&#8211; Reduced service surface area<\/p>\n\n\n\n<p>Your compliance posture still depends on:\n&#8211; IAM policies\n&#8211; Downstream service configurations\n&#8211; Data residency and access logging requirements per service<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Granting <code>roles\/owner<\/code> to developers just so they can enable APIs.<\/li>\n<li>Enabling broad sets of APIs \u201cjust in case\u201d.<\/li>\n<li>Disabling an API as a \u201csecurity fix\u201d without understanding production blast radius.<\/li>\n<li>Assuming an enabled API is secure by default (many services require additional hardening).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a controlled group for service enablement (platform team).<\/li>\n<li>Use CI\/CD service accounts with minimal required roles.<\/li>\n<li>Use organization policies to restrict which services can be enabled in sensitive environments (verify constraints and behavior).<\/li>\n<li>Review enabled services regularly and disable those not in use.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Project-level enablement<\/strong>: Service Usage enable\/disable is primarily per project; it\u2019s not a per-resource toggle.<\/li>\n<li><strong>Propagation delay<\/strong>: After enabling, it can take time before the API is fully usable.<\/li>\n<li><strong>Disabling doesn\u2019t necessarily delete resources<\/strong>: Many services keep resources intact; calls may fail. Cleanup behavior is service-specific\u2014verify per-service docs.<\/li>\n<li><strong>Dependencies can be complex<\/strong>:<\/li>\n<li>Disabling a foundational service can break multiple capabilities.<\/li>\n<li>Dependency handling options differ between Console, gcloud, and API methods\u2014verify your tool\u2019s behavior.<\/li>\n<li><strong>Quota override support varies<\/strong>:<\/li>\n<li>Not all quotas are overrideable.<\/li>\n<li>Some increases require explicit quota increase requests.<\/li>\n<li>Quota tooling in Google Cloud evolves; verify current recommended approach for quota management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage has its own API quotas\/rate limits.<\/li>\n<li>Target services have their own quotas.<\/li>\n<li>Automation that repeatedly lists\/enables services across many projects can hit rate limits\u2014implement retries with backoff.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service Usage is global; region constraints come from the services you enable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enabling an API does not necessarily cost money, but:<\/li>\n<li>It makes it easier to create billable resources.<\/li>\n<li>If a pipeline automatically enables APIs, it can unintentionally expand your billable footprint.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some older automation assumes a service is enabled by default; this may not hold in all environments.<\/li>\n<li>Organization Policy restrictions may block enabling certain services even for admins.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201cFixing\u201d an incident by disabling an API can cause wider outages if shared dependencies exist.<\/li>\n<li>Multiple teams enabling\/disabling APIs without coordination creates drift and instability\u2014centralize control for production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>When migrating projects or workloads:<\/li>\n<li>Ensure required APIs are enabled in the new project(s).<\/li>\n<li>Compare enabled services lists as part of migration checklists.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Service Usage is the core Google Cloud mechanism for API enablement, but you often interact with it through other tools.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud Console API Library<\/strong>: UI for enabling\/disabling services (uses Service Usage behind the scenes).<\/li>\n<li><strong>Terraform (<code>google_project_service<\/code>)<\/strong>: declarative enablement; great for GitOps.<\/li>\n<li><strong>Config Connector \/ Kubernetes<\/strong>: manage GCP resources via KRM; still requires APIs enabled.<\/li>\n<li><strong>Organization Policy<\/strong>: restrict what can be enabled (governance layer, not a replacement).<\/li>\n<li><strong>Cloud Quotas tooling<\/strong>: quota management interface; may complement or supersede some Service Usage quota workflows depending on the service (verify current docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Resource Providers registration<\/strong>: Azure services often require registering providers (e.g., <code>Microsoft.Compute<\/code>) at the subscription level.<\/li>\n<li><strong>AWS<\/strong>: Many services are \u201cavailable by default,\u201d but governance is achieved through IAM policies, SCPs (AWS Organizations), and service control mechanisms. AWS has <strong>Service Quotas<\/strong> for quota visibility\/management but not an exact equivalent of \u201cenable API per project\u201d because AWS service model differs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source\/self-managed alternatives<\/h3>\n\n\n\n<p>There isn\u2019t a true self-managed replacement for Service Usage because it is part of Google Cloud\u2019s control plane. However, you can use:\n&#8211; Terraform\/Pulumi wrappers to standardize enablement\n&#8211; Internal policy-as-code to validate allowed services lists<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Service Usage (API \/ gcloud)<\/strong><\/td>\n<td>Programmatic control, scripting, automation<\/td>\n<td>Canonical control plane; auditable; integrates with IAM and audit logs<\/td>\n<td>Requires permissions; dependency\/propagation nuances<\/td>\n<td>When you need reliable automation or troubleshooting around API enablement and quotas<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Console API Library<\/strong><\/td>\n<td>Manual operations, small teams, ad hoc enablement<\/td>\n<td>Easy UI; shows dependencies and helpful prompts<\/td>\n<td>Not ideal for consistent automation; can cause drift<\/td>\n<td>When you\u2019re learning, prototyping, or doing occasional administrative changes<\/td>\n<\/tr>\n<tr>\n<td><strong>Terraform <code>google_project_service<\/code><\/strong><\/td>\n<td>GitOps\/IaC-driven orgs<\/td>\n<td>Declarative, reviewable, consistent across environments<\/td>\n<td>State management complexity; must handle ordering\/dependencies<\/td>\n<td>When you want API enablement to be code-reviewed and repeatable<\/td>\n<\/tr>\n<tr>\n<td><strong>Organization Policy (service restrictions)<\/strong><\/td>\n<td>Central governance for large orgs<\/td>\n<td>Prevents unapproved services; supports compliance<\/td>\n<td>Not a tool to enable\/disable directly; requires org-level governance setup<\/td>\n<td>When you must restrict what teams can enable in production<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure provider registration<\/strong><\/td>\n<td>Azure governance<\/td>\n<td>Similar intent (control service availability)<\/td>\n<td>Different cloud model; not portable conceptually<\/td>\n<td>When implementing the equivalent governance in Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Service Quotas + IAM\/SCPs<\/strong><\/td>\n<td>AWS governance<\/td>\n<td>Strong quota visibility and org-level restrictions<\/td>\n<td>Doesn\u2019t map 1:1 to per-project API enablement<\/td>\n<td>When implementing comparable controls in AWS ecosystems<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated financial services landing zone<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Hundreds of projects across dev\/test\/prod; auditors require proof that only approved services are used in production. Teams frequently request new services, and quota issues have caused outages during peak events.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>A \u201cproject factory\u201d pipeline creates projects and immediately uses Service Usage to enable a baseline set of APIs.<\/li>\n<li>Organization Policy restricts which services can be enabled in production folders (verify exact constraints in official docs).<\/li>\n<li>A weekly job exports enabled services lists to a central repository for review.<\/li>\n<li>Quota metrics are reviewed for critical APIs; quota changes follow change management.<\/li>\n<li><strong>Why Service Usage was chosen<\/strong>:<\/li>\n<li>It is the canonical control-plane mechanism for API enablement.<\/li>\n<li>Integrates with IAM and Cloud Audit Logs for traceability.<\/li>\n<li>Works well with automation and IaC.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Reduced audit findings (clear inventory and change history)<\/li>\n<li>Fewer outages due to missing APIs or unexpected disablement<\/li>\n<li>Improved cost control through reduced service sprawl and quota guardrails<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: CI\/CD reliability for a SaaS backend<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small team ships frequently. Deployments occasionally fail because a required API wasn\u2019t enabled in a new environment project.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>A preflight script in CI uses Service Usage (via <code>gcloud services enable<\/code>) to ensure required APIs are enabled before Terraform applies.<\/li>\n<li>Minimal set of APIs enabled: only what the stack needs.<\/li>\n<li>Simple audit: enabled services list stored alongside infrastructure code.<\/li>\n<li><strong>Why Service Usage was chosen<\/strong>:<\/li>\n<li>Quick to adopt without heavy governance overhead.<\/li>\n<li>Eliminates a common class of deployment failures.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster, more reliable deployments<\/li>\n<li>Reduced \u201cenvironment drift\u201d<\/li>\n<li>Better security posture by keeping enabled APIs minimal<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Service Usage the same as IAM?<\/strong><br\/>\nNo. IAM controls <em>who<\/em> can do <em>what<\/em>. Service Usage controls whether a service\/API is enabled for a project. You typically need both: enable the API (Service Usage) and grant permissions (IAM).<\/p>\n\n\n\n<p>2) <strong>Does enabling an API automatically grant permissions to use it?<\/strong><br\/>\nNo. Enablement only allows the API to be called for the project. Callers still need appropriate IAM permissions\/roles for that service.<\/p>\n\n\n\n<p>3) <strong>Does enabling an API incur cost immediately?<\/strong><br\/>\nUsually, enabling alone does not incur charges. Costs start when you use the service (create resources, run jobs, make billable API calls). Always check the service\u2019s pricing.<\/p>\n\n\n\n<p>4) <strong>Why do I get <code>SERVICE_DISABLED<\/code> errors?<\/strong><br\/>\nCommonly because the API is disabled for the project. Enable it via Service Usage (Console, gcloud, or REST) and retry after a short delay.<\/p>\n\n\n\n<p>5) <strong>How long does it take for an API enablement to propagate?<\/strong><br\/>\nOften seconds to minutes. If calls fail immediately after enabling, wait briefly and retry. If it persists, verify you enabled the correct API and the caller has IAM permissions.<\/p>\n\n\n\n<p>6) <strong>Can I enable APIs at the organization or folder level?<\/strong><br\/>\nAPI enablement is typically per project. Organizations\/folders are used more for policy and governance. Verify current capabilities in official docs.<\/p>\n\n\n\n<p>7) <strong>What is the difference between \u201cavailable\u201d and \u201cenabled\u201d services?<\/strong><br\/>\n\u201cAvailable\u201d means a service can potentially be enabled for the project. \u201cEnabled\u201d means it is currently active and callable for that project.<\/p>\n\n\n\n<p>8) <strong>Can I disable an API in production safely?<\/strong><br\/>\nOnly after impact analysis. Disabling can break workloads immediately. Prefer change management and staged rollout.<\/p>\n\n\n\n<p>9) <strong>Does disabling an API delete resources created by that API?<\/strong><br\/>\nUsually no, but behavior varies by service. Disabling often blocks API calls but may not remove existing resources. Verify per-service behavior.<\/p>\n\n\n\n<p>10) <strong>What are dependent services?<\/strong><br\/>\nSome services require other APIs to function. For example, a deployment workflow might rely on Cloud Build, Artifact Registry, and IAM APIs. Disabling a dependency can break the parent service\u2019s workflows.<\/p>\n\n\n\n<p>11) <strong>How do I find the correct service name (like <code>run.googleapis.com<\/code>)?<\/strong><br\/>\nUse:\n&#8211; Cloud Console API Library\n&#8211; <code>gcloud services list --available<\/code>\n&#8211; Service documentation that lists the API endpoint name<\/p>\n\n\n\n<p>12) <strong>Can Service Usage manage quotas for all services?<\/strong><br\/>\nQuota visibility and overrides vary by service and quota metric. Some quotas are adjustable, some require quota increase requests, and some may be managed via newer quota tools. Verify in official docs.<\/p>\n\n\n\n<p>13) <strong>What IAM role do I need to enable\/disable services?<\/strong><br\/>\nTypically <code>roles\/serviceusage.serviceUsageAdmin<\/code> at the project level. Your org may use custom roles.<\/p>\n\n\n\n<p>14) <strong>How do I audit who enabled a service?<\/strong><br\/>\nUse Cloud Audit Logs (Admin Activity) in Cloud Logging and filter for Service Usage enable\/disable actions.<\/p>\n\n\n\n<p>15) <strong>Can I use Terraform instead of gcloud for enabling APIs?<\/strong><br\/>\nYes. Terraform\u2019s <code>google_project_service<\/code> is commonly used so API enablement is code-reviewed and repeatable. Service Usage remains the underlying control-plane concept.<\/p>\n\n\n\n<p>16) <strong>If an Organization Policy restricts services, can a project owner still enable blocked APIs?<\/strong><br\/>\nTypically no\u2014org policies can prevent enablement even for powerful roles. Exact behavior depends on policy configuration; verify in official docs.<\/p>\n\n\n\n<p>17) <strong>What\u2019s the safest way to manage service enablement across many projects?<\/strong><br\/>\nUse a centralized platform process (project factory), IaC, restricted admin roles, organization policies, and periodic audits of enabled services.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Service Usage<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Service Usage docs \u2014 https:\/\/cloud.google.com\/service-usage\/docs<\/td>\n<td>Canonical overview, concepts, and workflows<\/td>\n<\/tr>\n<tr>\n<td>API reference<\/td>\n<td>Service Usage REST reference \u2014 https:\/\/cloud.google.com\/service-usage\/docs\/reference\/rest<\/td>\n<td>Exact resource names, methods, request\/response schemas<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>gcloud services command \u2014 https:\/\/cloud.google.com\/sdk\/gcloud\/reference\/services<\/td>\n<td>Practical CLI commands for enable\/disable\/list<\/td>\n<\/tr>\n<tr>\n<td>Console entry point<\/td>\n<td>API Library \u2014 https:\/\/console.cloud.google.com\/apis\/library<\/td>\n<td>UI workflow used by many teams<\/td>\n<\/tr>\n<tr>\n<td>IAM roles<\/td>\n<td>IAM roles overview \u2014 https:\/\/cloud.google.com\/iam\/docs\/understanding-roles<\/td>\n<td>Understand role-based access needed for Service Usage<\/td>\n<\/tr>\n<tr>\n<td>Audit logging<\/td>\n<td>Cloud Audit Logs \u2014 https:\/\/cloud.google.com\/logging\/docs\/audit<\/td>\n<td>How to audit enable\/disable changes<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>Google Cloud Pricing \u2014 https:\/\/cloud.google.com\/pricing<\/td>\n<td>Understand that costs come from enabled services, not Service Usage itself<\/td>\n<\/tr>\n<tr>\n<td>Cost estimation<\/td>\n<td>Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Estimate costs of services you enable and use<\/td>\n<\/tr>\n<tr>\n<td>Quotas overview<\/td>\n<td>Quotas overview \u2014 https:\/\/cloud.google.com\/docs\/quota<\/td>\n<td>Background on quotas, limits, and best practices<\/td>\n<\/tr>\n<tr>\n<td>Hands-on labs<\/td>\n<td>Google Cloud Skills Boost \u2014 https:\/\/www.cloudskillsboost.google\/<\/td>\n<td>Find guided labs related to enabling APIs, IAM, and project setup (search within the catalog)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams, beginners to intermediate<\/td>\n<td>Google Cloud operations, DevOps, automation fundamentals (verify exact course outlines on site)<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students, DevOps practitioners<\/td>\n<td>DevOps and SCM\/tooling foundations; may include cloud modules (verify)<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops engineers, sysadmins transitioning to cloud<\/td>\n<td>Cloud operations practices; Google Cloud basics (verify)<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability engineers, platform teams<\/td>\n<td>SRE practices, monitoring, incident response; may map to Google Cloud ops workflows (verify)<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Operations teams, platform teams, engineers exploring AIOps<\/td>\n<td>AIOps concepts; automation and ops analytics (verify)<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>Cloud\/DevOps training content (verify offerings on site)<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring (verify offerings on site)<\/td>\n<td>DevOps engineers, students<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps help\/training resources (verify offerings on site)<\/td>\n<td>Teams needing short-term expertise<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify offerings on site)<\/td>\n<td>Ops\/DevOps teams<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact services on site)<\/td>\n<td>Platform engineering, cloud migrations, operational readiness<\/td>\n<td>Landing zone setup, CI\/CD pipelines, governance automation (examples)<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training organization (verify service catalog on site)<\/td>\n<td>DevOps transformation, tooling adoption, cloud automation<\/td>\n<td>Build CI\/CD standards, implement IaC, operational best practices (examples)<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact services on site)<\/td>\n<td>DevOps strategy, implementation support<\/td>\n<td>Pipeline implementation, Kubernetes enablement, cloud ops practices (examples)<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Service Usage<\/h3>\n\n\n\n<p>To use Service Usage effectively, learn:\n&#8211; Google Cloud fundamentals:\n  &#8211; Projects, folders, organizations\n  &#8211; Billing accounts\n&#8211; IAM basics:\n  &#8211; Roles, permissions, service accounts\n&#8211; Core operational tooling:\n  &#8211; gcloud CLI\n  &#8211; Cloud Console navigation\n&#8211; Basic cloud governance concepts:\n  &#8211; least privilege\n  &#8211; separation of duties\n  &#8211; audit logs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Service Usage<\/h3>\n\n\n\n<p>Once you understand API enablement, expand into:\n&#8211; Organization Policy and governance (service allow\/deny restrictions)\n&#8211; Infrastructure as Code:\n  &#8211; Terraform (including <code>google_project_service<\/code>)\n  &#8211; Policy as code (where applicable)\n&#8211; Observability:\n  &#8211; Cloud Logging (audit queries)\n  &#8211; Cloud Monitoring\n&#8211; Cost management:\n  &#8211; Billing exports, budgets, alerts\n&#8211; Service-specific operational readiness:\n  &#8211; quotas, SLOs, capacity planning<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer \/ platform engineer<\/li>\n<li>DevOps engineer<\/li>\n<li>SRE<\/li>\n<li>Security engineer (cloud security\/governance)<\/li>\n<li>Cloud architect<\/li>\n<li>FinOps analyst (service inventory + spend governance)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Service Usage is not typically tested as a standalone product, but it is a practical skill within broader Google Cloud certifications. Consider:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Architect\n&#8211; Professional Cloud DevOps Engineer<br\/>\nVerify current certification paths: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201cproject bootstrapper\u201d script:<\/li>\n<li>Create project, apply labels, enable baseline APIs, write inventory file.<\/li>\n<li>Implement a CI pipeline stage:<\/li>\n<li>Preflight check: required APIs enabled before Terraform apply.<\/li>\n<li>Build a compliance report:<\/li>\n<li>Weekly export of enabled services; diff against approved list; alert on drift.<\/li>\n<li>Incident drill:<\/li>\n<li>Simulate <code>SERVICE_DISABLED<\/code> and quota errors in a sandbox and document runbooks.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>API (Application Programming Interface)<\/strong>: A programmatic interface to a cloud service, typically via HTTPS endpoints.<\/li>\n<li><strong>Service (Google Cloud service)<\/strong>: A Google-managed capability such as Cloud Storage, Cloud Run, BigQuery, etc., often accessed via an API like <code>storage.googleapis.com<\/code>.<\/li>\n<li><strong>Service enablement<\/strong>: Turning on a specific API for a project so that it can be used.<\/li>\n<li><strong>Service disablement<\/strong>: Turning off an API for a project so calls fail (often immediately).<\/li>\n<li><strong>Project<\/strong>: The primary isolation and billing boundary for resources and service consumption in Google Cloud.<\/li>\n<li><strong>IAM (Identity and Access Management)<\/strong>: Google Cloud system that controls permissions for identities (users, service accounts).<\/li>\n<li><strong>Service account<\/strong>: A non-human identity used by applications and automation.<\/li>\n<li><strong>Quota<\/strong>: A limit on usage of a service (requests per minute, resources per project, etc.).<\/li>\n<li><strong>Quota override<\/strong>: An adjustment to quota limits (where supported), often used as a safety guardrail or to apply approved limits.<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: Logs that record administrative actions and access events for Google Cloud resources and services.<\/li>\n<li><strong>Control plane<\/strong>: Management layer used to configure resources (enable APIs, set policies).<\/li>\n<li><strong>Data plane<\/strong>: Runtime layer where application traffic and data processing occur.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Service Usage in <strong>Google Cloud<\/strong> is a foundational <strong>Access and resource management<\/strong> service that controls which Google Cloud APIs are enabled for a project and provides visibility into service state and certain quota metrics\/overrides. It matters because API enablement is a prerequisite for using most Google Cloud services, and because controlling enabled services improves <strong>security posture, operational reliability, and cost governance<\/strong>.<\/p>\n\n\n\n<p>Key points to remember:\n&#8211; <strong>Cost<\/strong>: Service Usage itself is generally not a direct cost driver, but enabling APIs makes downstream spend possible. Control what\u2019s enabled and monitor usage.\n&#8211; <strong>Security<\/strong>: Use IAM least privilege and audit logs; restrict who can enable APIs and consider organization-level policy restrictions where appropriate.\n&#8211; <strong>Operations<\/strong>: Automate enablement (CI\/CD or IaC), inventory enabled services, and treat enable\/disable actions as change-managed events\u2014especially in production.<\/p>\n\n\n\n<p>Next step: Implement API enablement as code (Terraform or scripted preflight checks) and learn how Organization Policy and audit logs combine with Service Usage for end-to-end governance.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Access and resource management<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[52,51],"tags":[],"class_list":["post-538","post","type-post","status-publish","format-standard","hentry","category-access-and-resource-management","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/538","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=538"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/538\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=538"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=538"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=538"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}