{"id":582,"date":"2026-04-14T15:00:08","date_gmt":"2026-04-14T15:00:08","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-api-gateway-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/"},"modified":"2026-04-14T15:00:08","modified_gmt":"2026-04-14T15:00:08","slug":"google-cloud-api-gateway-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-api-gateway-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/","title":{"rendered":"Google Cloud API Gateway Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application development"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Application development<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Google Cloud <strong>API Gateway<\/strong> is a managed service that sits in front of your HTTP APIs and backend services to provide a consistent, controlled entry point for clients. You define your API surface using an <strong>OpenAPI<\/strong> specification, deploy it to a managed gateway, and use it to route requests to services such as <strong>Cloud Run<\/strong> and <strong>Cloud Functions<\/strong>\u2014with built-in authentication, monitoring hooks, and centralized configuration.<\/p>\n\n\n\n<p>In simple terms: <strong>API Gateway gives you one URL for your API, one contract (OpenAPI) that defines it, and one place to enforce basic access controls<\/strong> like API keys or JWT validation\u2014without you running your own proxy layer.<\/p>\n\n\n\n<p>Technically, API Gateway provisions and operates a Google-managed gateway that uses your OpenAPI configuration to:\n&#8211; validate and authorize requests (for supported auth methods),\n&#8211; route requests to configured backends,\n&#8211; emit logs\/metrics suitable for production operations,\n&#8211; support API lifecycle management via versioned configs.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> teams building APIs (especially in <strong>Application development<\/strong> and platform engineering) often struggle with sprawl: inconsistent endpoints, ad hoc auth, duplicated routing logic, and poor observability. API Gateway addresses these by making routing, authentication policy, and API definition consistent and auditable across environments.<\/p>\n\n\n\n<blockquote>\n<p>Service status note: <strong>API Gateway<\/strong> is an active Google Cloud service. It is distinct from <strong>Apigee<\/strong> (full API management) and from <strong>Cloud Endpoints<\/strong> (an older pattern\/proxy stack). If you are evaluating products, compare them explicitly (see Section 14).<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is API Gateway?<\/h2>\n\n\n\n<p><strong>Official purpose (in practice):<\/strong> API Gateway provides a managed API front door where you deploy an API configuration (OpenAPI) and expose it through a gateway endpoint, routing to Google Cloud backends while applying authentication\/authorization checks and producing operational telemetry.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>API Gateway is commonly used to:\n&#8211; Define an API contract using <strong>OpenAPI 2.0<\/strong> (Swagger) with Google-specific extensions (for example, backend routing).\n&#8211; Deploy that contract to a <strong>Gateway<\/strong> that provides a stable hostname.\n&#8211; Authenticate requests using supported mechanisms (commonly <strong>API keys<\/strong> and <strong>JWT validation<\/strong>; confirm current supported auth methods in docs).\n&#8211; Route requests to serverless backends such as <strong>Cloud Run<\/strong> and <strong>Cloud Functions<\/strong> (and to other HTTP backends that are reachable; confirm constraints in docs).\n&#8211; Integrate with <strong>Cloud Logging<\/strong> and <strong>Cloud Monitoring<\/strong> for operational visibility.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (mental model)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Component<\/th>\n<th>What it is<\/th>\n<th>Why it matters<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>API<\/strong><\/td>\n<td>A logical container representing an API product in a project<\/td>\n<td>Organizes configs\/versions; clean separation across environments<\/td>\n<\/tr>\n<tr>\n<td><strong>API config<\/strong><\/td>\n<td>A versioned configuration derived from an OpenAPI document<\/td>\n<td>Enables promotion (dev \u2192 staging \u2192 prod) and rollback<\/td>\n<\/tr>\n<tr>\n<td><strong>Gateway<\/strong><\/td>\n<td>The managed runtime that serves requests according to an API config<\/td>\n<td>The actual entry point clients call (hostname is provided)<\/td>\n<\/tr>\n<tr>\n<td><strong>Service account \/ IAM<\/strong><\/td>\n<td>Identity used to administer gateway resources<\/td>\n<td>Controls who can deploy\/modify gateway and configs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Service type and scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service type:<\/strong> Fully managed API gateway (control plane + managed data plane).<\/li>\n<li><strong>Resource scope:<\/strong> <strong>Project-scoped<\/strong> resources.<\/li>\n<li><strong>Location model:<\/strong> Gateways are created in a <strong>region<\/strong> (regional resource). APIs and API configs are managed within the project; some aspects behave globally from a configuration standpoint, but the gateway runtime is regional.<\/li>\n<li><strong>How it fits into Google Cloud:<\/strong> API Gateway complements:<\/li>\n<li><strong>Cloud Run \/ Cloud Functions<\/strong> for serverless backends,<\/li>\n<li><strong>Cloud IAM<\/strong> for admin access control,<\/li>\n<li><strong>API Keys<\/strong> for client access control (where used),<\/li>\n<li><strong>Cloud Logging\/Monitoring<\/strong> for operations,<\/li>\n<li><strong>Cloud Load Balancing \/ Cloud Armor<\/strong> when you need advanced edge controls (often used in front of a gateway; verify best-practice architectures for your requirements).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use API Gateway?<\/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>Faster delivery with guardrails:<\/strong> teams ship APIs faster when a consistent gateway pattern exists (one place for API entry, basic auth, logging).<\/li>\n<li><strong>Reduced operational overhead:<\/strong> you avoid running and patching your own proxy fleet.<\/li>\n<li><strong>Consistency across teams:<\/strong> standardize how APIs are exposed, versioned, and governed.<\/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>Contract-first APIs:<\/strong> OpenAPI becomes the source of truth for routing and (some) policy.<\/li>\n<li><strong>Decoupling clients from backends:<\/strong> you can refactor backend URLs\/services while keeping a stable gateway endpoint (subject to API config changes).<\/li>\n<li><strong>Simple security at the edge of your API:<\/strong> enforce an API key requirement or validate JWTs before hitting the backend.<\/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>Better observability:<\/strong> structured gateway logs and metrics support troubleshooting and capacity planning.<\/li>\n<li><strong>Controlled deployments:<\/strong> versioned API configs enable safer releases and rollbacks.<\/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>Centralized access control and auditability:<\/strong> gateway configuration changes can be tracked via audit logs; access can be restricted via IAM.<\/li>\n<li><strong>Reduces accidental exposure:<\/strong> instead of exposing each backend directly, you can expose the gateway as the official entry (you still must secure backends appropriately).<\/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>Managed scaling of the gateway runtime:<\/strong> no need to manage instances, autoscaling groups, or patch cycles for the gateway itself (details are managed by Google; review quotas and limits).<\/li>\n<li><strong>Regional placement:<\/strong> deploy gateways in regions close to your users or backends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose API Gateway when you need:\n&#8211; A managed gateway for HTTP APIs defined in OpenAPI\n&#8211; Basic auth enforcement (API keys\/JWT) and centralized routing\n&#8211; A straightforward front door for Cloud Run\/Cloud Functions backends\n&#8211; A lighter-weight option than full API management platforms<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid (or reassess) API Gateway if you need:\n&#8211; <strong>Full API management<\/strong> features (advanced quotas, monetization, developer portal, complex transformations, advanced analytics): evaluate <strong>Apigee<\/strong> instead.\n&#8211; <strong>Protocol needs beyond typical HTTP\/REST<\/strong> (for example, gRPC end-to-end through the gateway): verify current protocol support; if unsupported, consider alternatives.\n&#8211; <strong>Advanced edge protection<\/strong> natively in the gateway (WAF, bot management, complex L7 rules): you may need <strong>Cloud Load Balancing + Cloud Armor<\/strong> in front, or another API management product.\n&#8211; <strong>Private-only ingress<\/strong> patterns: confirm whether the gateway can reach private backends; many designs require public\/reachable endpoints or additional networking patterns.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is API Gateway used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and B2B platforms exposing partner APIs<\/li>\n<li>Retail\/e-commerce integrating web\/mobile channels<\/li>\n<li>Media\/mobile apps needing a stable API surface<\/li>\n<li>FinTech\/healthcare where consistent audit and access patterns matter (with proper security design)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Application development teams building microservices<\/li>\n<li>Platform\/DevOps teams standardizing API exposure<\/li>\n<li>SRE teams improving reliability and observability<\/li>\n<li>Security teams enforcing baseline API access controls<\/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>Serverless APIs with Cloud Run or Cloud Functions<\/li>\n<li>Microservices where one gateway routes to multiple services<\/li>\n<li>\u201cBackend for Frontend\u201d (BFF) patterns<\/li>\n<li>Internal APIs (with strong IAM restrictions) and external APIs (with keys\/JWT + additional edge controls)<\/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>Production:<\/strong> stable entry point, versioned configs, structured logging\/metrics, controlled rollouts.<\/li>\n<li><strong>Dev\/test:<\/strong> quick iteration on API contracts, ephemeral gateways per environment, CI\/CD-driven deployments.<\/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 Google Cloud API Gateway is commonly a good fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Front door for a Cloud Run REST API<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Cloud Run services often start as direct URLs; teams need a stable API endpoint and basic auth.<\/li>\n<li><strong>Why API Gateway fits:<\/strong> It provides an API contract and a managed endpoint in front of Cloud Run.<\/li>\n<li><strong>Example:<\/strong> <code>\/v1\/orders<\/code> routes to a Cloud Run <code>orders-service<\/code> with an enforced API key.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Single gateway routing to multiple microservices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Clients shouldn\u2019t call 10 different service URLs.<\/li>\n<li><strong>Why it fits:<\/strong> One gateway can route different paths to different backends (as defined in OpenAPI).<\/li>\n<li><strong>Example:<\/strong> <code>\/v1\/users<\/code> \u2192 users service, <code>\/v1\/payments<\/code> \u2192 payments service, <code>\/v1\/catalog<\/code> \u2192 catalog service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Partner API exposure with API keys<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need to issue credentials to partners and revoke\/rotate them.<\/li>\n<li><strong>Why it fits:<\/strong> API keys are a practical baseline control for identifying clients (not a full security model by itself).<\/li>\n<li><strong>Example:<\/strong> Each partner gets a key; you monitor usage and revoke compromised keys.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Mobile app backend with JWT validation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Mobile clients need authenticated access without embedding long-lived secrets.<\/li>\n<li><strong>Why it fits:<\/strong> JWT validation at the gateway reduces unauthenticated traffic reaching backends.<\/li>\n<li><strong>Example:<\/strong> Mobile app signs in with an identity provider; gateway validates JWT before routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Versioned API rollout (v1 \u2192 v2)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Breaking changes must be introduced safely.<\/li>\n<li><strong>Why it fits:<\/strong> API configs are versioned; you can deploy multiple gateways or update a gateway to a new config.<\/li>\n<li><strong>Example:<\/strong> <code>v1<\/code> and <code>v2<\/code> are separate configs; staging gateway runs v2 until validated.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Centralized logging for troubleshooting API issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Backend logs alone don\u2019t show what clients attempted or how routing behaved.<\/li>\n<li><strong>Why it fits:<\/strong> Gateway access logs provide request metadata at the entry point.<\/li>\n<li><strong>Example:<\/strong> Identify that 401s are caused by missing API key header rather than backend failures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Enforce an API contract for internal teams<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Internal consumers break APIs due to undocumented behavior changes.<\/li>\n<li><strong>Why it fits:<\/strong> OpenAPI provides an explicit contract and encourages disciplined changes.<\/li>\n<li><strong>Example:<\/strong> CI rejects deployments if OpenAPI doesn\u2019t match required patterns (linting).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) \u201cBackend for Frontend\u201d (BFF) for a web app<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Web UI needs a stable, tailored API, while backend services evolve.<\/li>\n<li><strong>Why it fits:<\/strong> Gateway exposes stable BFF endpoints routing to appropriate backend services.<\/li>\n<li><strong>Example:<\/strong> <code>\/ui\/dashboard<\/code> routes to a Cloud Run BFF service that aggregates multiple calls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Controlled exposure during migrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Migrating from a monolith to microservices without breaking clients.<\/li>\n<li><strong>Why it fits:<\/strong> Gateway routes some paths to legacy and others to new services.<\/li>\n<li><strong>Example:<\/strong> <code>\/v1\/legacy\/*<\/code> \u2192 old VM, <code>\/v1\/new\/*<\/code> \u2192 Cloud Run services (verify supported backend types).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Standard entry point across multiple environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Different teams expose APIs differently in dev\/staging\/prod.<\/li>\n<li><strong>Why it fits:<\/strong> Repeatable gateway + config deployment patterns.<\/li>\n<li><strong>Example:<\/strong> <code>dev-gateway<\/code>, <code>staging-gateway<\/code>, <code>prod-gateway<\/code> with consistent naming and IAM.<\/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<p>This section focuses on practical, current capabilities commonly associated with Google Cloud API Gateway. If you rely on a specific feature for production, <strong>verify in official docs<\/strong> because capabilities evolve.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">OpenAPI-based API definition (contract-first)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> You define routes, methods, and security requirements in an OpenAPI document.<\/li>\n<li><strong>Why it matters:<\/strong> The gateway behavior is documented, reviewable, and versionable.<\/li>\n<li><strong>Practical benefit:<\/strong> Easier reviews, automated validation, and consistent routing across environments.<\/li>\n<li><strong>Caveats:<\/strong> API Gateway\u2019s OpenAPI support may not cover every OpenAPI feature; Google-specific extensions are often required for backend routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Versioned API configs (repeatable deployments)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> API configs are immutable versions you can deploy to gateways.<\/li>\n<li><strong>Why it matters:<\/strong> Supports change control, promotion pipelines, and rollbacks.<\/li>\n<li><strong>Practical benefit:<\/strong> Safer production releases\u2014keep prior configs for rollback.<\/li>\n<li><strong>Caveats:<\/strong> Cleanup is your responsibility; stale configs can accumulate over time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Managed gateway runtime and hostname<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Google hosts the gateway runtime; you get a default hostname for your gateway.<\/li>\n<li><strong>Why it matters:<\/strong> No proxy infrastructure to run\/patch\/scale.<\/li>\n<li><strong>Practical benefit:<\/strong> Teams can focus on API design and backend implementation.<\/li>\n<li><strong>Caveats:<\/strong> For custom domains and advanced edge policies, you may need additional services (often a load balancer in front). Verify current custom domain support.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Backend routing with Google extensions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Routes from OpenAPI paths\/methods to backend URLs (commonly Cloud Run\/Cloud Functions endpoints).<\/li>\n<li><strong>Why it matters:<\/strong> Centralizes routing configuration outside of app code.<\/li>\n<li><strong>Practical benefit:<\/strong> Backends can be swapped\/updated without changing clients.<\/li>\n<li><strong>Caveats:<\/strong> Backends must be reachable under the networking model supported by API Gateway.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Authentication and authorization (baseline controls)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enforces configured auth before routing (commonly API keys; JWT validation where supported).<\/li>\n<li><strong>Why it matters:<\/strong> Reduces unauthorized traffic and supports client identification.<\/li>\n<li><strong>Practical benefit:<\/strong> A consistent security policy at the API entry.<\/li>\n<li><strong>Caveats:<\/strong> API keys are not user authentication; they are best for project\/app identification. For user auth, use JWT\/OIDC patterns. Verify exact supported identity providers and JWT settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Observability integration (Logging\/Monitoring)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Emits logs and metrics suitable for production monitoring.<\/li>\n<li><strong>Why it matters:<\/strong> Gateways are often the best vantage point for client behavior.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster debugging (auth failures, routing issues, latency).<\/li>\n<li><strong>Caveats:<\/strong> Logging volume can be a cost driver. Use sampling\/filters where applicable (verify what is configurable).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM for administration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses Google Cloud IAM to control who can create\/update\/delete APIs, configs, and gateways.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents unauthorized changes to your API entry point.<\/li>\n<li><strong>Practical benefit:<\/strong> Supports separation of duties (platform vs app teams).<\/li>\n<li><strong>Caveats:<\/strong> IAM controls administration, not necessarily per-request authorization (that is done via gateway auth configuration).<\/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>API Gateway has a control plane and a managed runtime:\n1. You author an OpenAPI spec and create an <strong>API config<\/strong>.\n2. You deploy the config to a <strong>Gateway<\/strong> in a region.\n3. Clients call the gateway hostname.\n4. The gateway validates auth (if configured), then routes the request to the backend.\n5. Logs\/metrics are emitted to Google Cloud observability services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow (deployment time):<\/strong><\/li>\n<li>Developer\/CI uses <code>gcloud<\/code> or the Console to create API \u2192 API config \u2192 gateway.<\/li>\n<li>Configuration is stored and used to program the managed gateway runtime.<\/li>\n<li><strong>Data flow (request time):<\/strong><\/li>\n<li>Client \u2192 Gateway (TLS) \u2192 Auth checks \u2192 Backend (TLS) \u2192 Response \u2192 Client<\/li>\n<li><strong>Telemetry flow:<\/strong><\/li>\n<li>Gateway emits access logs and metrics to Cloud Logging\/Monitoring.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations in Google Cloud:\n&#8211; <strong>Cloud Run \/ Cloud Functions:<\/strong> popular serverless backends.\n&#8211; <strong>API Keys (Google Cloud):<\/strong> manage client keys used for API key enforcement.\n&#8211; <strong>Cloud Logging \/ Monitoring:<\/strong> operational telemetry.\n&#8211; <strong>Cloud Audit Logs:<\/strong> administrative change tracking.\n&#8211; <strong>Cloud Load Balancing + Cloud Armor (optional):<\/strong> advanced edge protection, custom domain strategies, global routing (verify recommended reference architectures).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services (commonly required)<\/h3>\n\n\n\n<p>In many deployments you will enable:\n&#8211; API Gateway API\n&#8211; Service Management \/ Service Control APIs (used under the hood for API infrastructure)\n&#8211; API Keys API (when using API keys)\n&#8211; Cloud Run \/ Cloud Functions APIs for your backends<\/p>\n\n\n\n<p>Exact dependencies can change\u2014<strong>verify in official docs<\/strong> for the latest.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model (two layers)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Administrative access (IAM):<\/strong> Who can deploy or change gateway resources.<\/li>\n<li><strong>Client access (gateway auth):<\/strong> Who can call the API at runtime (API keys\/JWT, depending on configuration).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (practical implications)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Gateways expose an HTTPS endpoint on a Google-managed hostname.<\/li>\n<li>Backend reachability depends on what API Gateway supports and how your backend is exposed.<\/li>\n<li>If you need private-only backend connectivity, you may require additional architecture (for example, a load balancer or other pattern). <strong>Verify in official docs<\/strong> for supported private connectivity options.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent labels\/naming across APIs\/configs\/gateways for auditability.<\/li>\n<li>Define log-based metrics for common failures (401\/403\/404\/5xx).<\/li>\n<li>Treat OpenAPI specs as code: review, lint, and version them in Git.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  C[Client] --&gt;|HTTPS request| G[API Gateway&lt;br\/&gt;Gateway endpoint]\n  G --&gt;|Route + auth checks| B[Backend&lt;br\/&gt;(Cloud Run \/ Cloud Functions)]\n  G --&gt; L[Cloud Logging]\n  G --&gt; M[Cloud Monitoring]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Internet\n    U[Users \/ Partner Clients]\n  end\n\n  subgraph Edge[\"Edge (optional)\"]\n    LB[External HTTPS Load Balancer&lt;br\/&gt;(optional for custom domain\/global routing)]\n    CA[Cloud Armor policy&lt;br\/&gt;(optional WAF\/bot controls)]\n    DNS[Cloud DNS]\n  end\n\n  subgraph Gateway[\"API Layer\"]\n    GW[API Gateway (regional)]\n    CFG[API Config (OpenAPI versioned)]\n  end\n\n  subgraph Serverless[\"Backends\"]\n    CR1[Cloud Run service: users]\n    CR2[Cloud Run service: orders]\n    CF[Cloud Functions: webhook handler]\n  end\n\n  subgraph Ops[\"Operations &amp; Governance\"]\n    LOG[Cloud Logging]\n    MON[Cloud Monitoring]\n    AUD[Cloud Audit Logs]\n    CI[CI\/CD Pipeline&lt;br\/&gt;Git + Cloud Build\/other]\n  end\n\n  U --&gt; DNS --&gt; LB --&gt; GW\n  CA -. policy .- LB\n  CI --&gt; CFG --&gt; GW\n  GW --&gt; CR1\n  GW --&gt; CR2\n  GW --&gt; CF\n  GW --&gt; LOG\n  GW --&gt; MON\n  CI --&gt; AUD\n  GW --&gt; AUD\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<p>Before you start:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project and billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>billing enabled<\/strong>.<\/li>\n<li>Ability to enable APIs and create resources in the project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You typically need permissions to:\n&#8211; Create and manage API Gateway resources (API, API config, gateway).\n&#8211; Deploy and manage Cloud Run\/Cloud Functions backends.\n&#8211; Create API keys (if using API key auth).\n&#8211; View logs\/metrics.<\/p>\n\n\n\n<p>Common roles (exact needs vary):\n&#8211; API Gateway Admin (or equivalent permissions)\n&#8211; Cloud Run Admin (for this tutorial)\n&#8211; Service Usage Admin (to enable services)\n&#8211; API Keys Admin (if creating keys)<\/p>\n\n\n\n<p>Use least privilege in production and <strong>verify role names in IAM documentation<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cloud.google.com\/sdk\/docs\/install\">Google Cloud SDK (<code>gcloud<\/code>)<\/a><\/li>\n<li>A shell environment (Cloud Shell is fine)<\/li>\n<li><code>curl<\/code> for testing<\/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>API Gateway is regional. Pick a region supported by both API Gateway and your backend service (Cloud Run region, etc.). Check the <strong>locations<\/strong> in the official docs.<\/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>Expect quotas around number of gateways\/configs and request rates. Review in:<\/li>\n<li>Google Cloud Console \u2192 IAM &amp; Admin \u2192 Quotas (or the Quotas page for the service)<\/li>\n<li>Do not assume default quotas are sufficient for production load tests.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services (APIs to enable)<\/h3>\n\n\n\n<p>You will commonly enable:\n&#8211; API Gateway API\n&#8211; Cloud Run API (for this lab)\n&#8211; Service Management \/ Service Control\n&#8211; API Keys API (if using API keys)<\/p>\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<p>API Gateway pricing is <strong>usage-based<\/strong> and can vary by region and SKU. Because exact unit prices can change, use the official sources for current numbers:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/cloud.google.com\/api-gateway\/pricing  <\/li>\n<li>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you are usually billed for)<\/h3>\n\n\n\n<p>Common billing dimensions to evaluate:\n&#8211; <strong>API calls \/ requests processed by the gateway<\/strong>\n&#8211; Potentially other gateway-related SKUs depending on the current model (for example, per-instance-hour or per-feature). <strong>Verify in official pricing<\/strong>.<\/p>\n\n\n\n<p>You will also pay for <strong>everything behind the gateway<\/strong>, including:\n&#8211; Cloud Run \/ Cloud Functions compute\n&#8211; Logging ingestion\/storage (Cloud Logging)\n&#8211; Monitoring metrics (generally included up to limits; verify)\n&#8211; Network egress (especially to the public internet)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>Some Google Cloud services have free tiers or free quotas. <strong>Verify on the API Gateway pricing page<\/strong> whether a free tier exists and what it includes (calls per month, etc.).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Request volume:<\/strong> total monthly API calls.<\/li>\n<li><strong>Payload sizes:<\/strong> larger requests\/responses can increase networking and backend compute time.<\/li>\n<li><strong>Logging volume:<\/strong> high-cardinality logs and verbose request logging increase Cloud Logging costs.<\/li>\n<li><strong>Backend compute:<\/strong> slow handlers increase Cloud Run CPU-seconds and concurrency pressure.<\/li>\n<li><strong>Internet egress:<\/strong> responses to internet clients incur egress costs depending on destination.<\/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>Cloud Logging retention and sinks:<\/strong> exporting logs to BigQuery or storage can add cost quickly.<\/li>\n<li><strong>Load balancer in front (optional):<\/strong> if you add External HTTPS Load Balancing for custom domain\/global routing\/Cloud Armor, that introduces additional LB and data processing costs.<\/li>\n<li><strong>Security services:<\/strong> Cloud Armor policies and rule evaluations are billed separately.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization strategies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>appropriate logging levels<\/strong> and exclusions where safe (don\u2019t log sensitive data).<\/li>\n<li>Keep <strong>payloads small<\/strong> and enable compression at the backend where appropriate.<\/li>\n<li>Use <strong>Cloud Run concurrency<\/strong> effectively to reduce per-request overhead.<\/li>\n<li>Consider whether you truly need a load balancer in front of the gateway, or if the default gateway hostname is sufficient.<\/li>\n<li>Implement caching at appropriate layers (often at CDN\/LB or application level; API Gateway itself is not typically used as a caching proxy).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (framework, not fabricated numbers)<\/h3>\n\n\n\n<p>To estimate a simple dev environment:\n1. Determine expected monthly calls: <code>N_calls<\/code>\n2. Multiply by gateway request rate: <code>Cost_gateway = (N_calls \/ pricing_unit) * unit_price<\/code>\n3. Add backend costs:\n   &#8211; Cloud Run requests + CPU\/memory time\n4. Add observability:\n   &#8211; log volume (GB ingested) \u00d7 logging rate (if applicable)\n5. Add network egress if users are on the internet<\/p>\n\n\n\n<p>Because unit prices vary and can change, plug in current SKUs from the pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, model:\n&#8211; peak vs average request rate (capacity and SLO planning),\n&#8211; multi-region strategy (if used),\n&#8211; DDoS\/WAF posture (Cloud Armor),\n&#8211; data egress profiles by geography,\n&#8211; log retention requirements for compliance.<\/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<p>This lab deploys a small Cloud Run backend and publishes it through <strong>API Gateway<\/strong> using an OpenAPI spec with <strong>API key<\/strong> enforcement.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploy a Cloud Run service.<\/li>\n<li>Create an API in API Gateway.<\/li>\n<li>Deploy an API config (OpenAPI).<\/li>\n<li>Create a gateway and obtain its public hostname.<\/li>\n<li>Create an API key and successfully call the API through API Gateway.<\/li>\n<li>Validate logs and clean up all resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build this flow:<\/p>\n\n\n\n<p>Client \u2192 API Gateway (API key required) \u2192 Cloud Run \u201chello\u201d service<\/p>\n\n\n\n<p>Approximate time: 30\u201360 minutes (first time).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set variables and select a project<\/h3>\n\n\n\n<p>Open Cloud Shell (or your terminal with <code>gcloud<\/code> authenticated) and set your project and region:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\nexport REGION=\"us-central1\"\n\ngcloud config set project \"$PROJECT_ID\"\ngcloud config set run\/region \"$REGION\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>gcloud<\/code> is pointing to the correct project.<\/p>\n\n\n\n<p><strong>Verify:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config get-value project\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable required APIs<\/h3>\n\n\n\n<p>Enable the core APIs used in this tutorial:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  apigateway.googleapis.com \\\n  run.googleapis.com \\\n  servicemanagement.googleapis.com \\\n  servicecontrol.googleapis.com \\\n  apikeys.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs are enabled successfully.<\/p>\n\n\n\n<p><strong>Verify:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:apigateway.googleapis.com OR name:run.googleapis.com OR name:apikeys.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Deploy a Cloud Run backend<\/h3>\n\n\n\n<p>Deploy a small public Cloud Run service using the official sample container image.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export RUN_SERVICE=\"hello-backend\"\n\ngcloud run deploy \"$RUN_SERVICE\" \\\n  --image=\"us-docker.pkg.dev\/cloudrun\/container\/hello\" \\\n  --allow-unauthenticated \\\n  --region=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<p>Fetch the Cloud Run URL:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export BACKEND_URL\nBACKEND_URL=\"$(gcloud run services describe \"$RUN_SERVICE\" --region \"$REGION\" --format='value(status.url)')\"\necho \"Backend URL: $BACKEND_URL\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a working HTTPS URL for the backend.<\/p>\n\n\n\n<p><strong>Verify (call backend directly):<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"$BACKEND_URL\"\n<\/code><\/pre>\n\n\n\n<p>You should see an HTTP 200 response from the sample service.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create an OpenAPI spec for API Gateway<\/h3>\n\n\n\n<p>Create a file named <code>openapi.yaml<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; openapi.yaml &lt;&lt;'EOF'\nswagger: \"2.0\"\ninfo:\n  title: \"hello-api\"\n  description: \"API Gateway in front of a Cloud Run backend\"\n  version: \"1.0.0\"\nschemes:\n  - https\nproduces:\n  - application\/json\n\n# Enforce an API key on all methods unless overridden.\nsecurityDefinitions:\n  api_key:\n    type: \"apiKey\"\n    name: \"x-api-key\"\n    in: \"header\"\nsecurity:\n  - api_key: []\n\npaths:\n  \/:\n    get:\n      operationId: \"root\"\n      x-google-backend:\n        address: \"BACKEND_URL_REPLACE_ME\"\n      responses:\n        \"200\":\n          description: \"OK\"\nEOF\n<\/code><\/pre>\n\n\n\n<p>Now replace the backend placeholder with your Cloud Run URL:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sed -i \"s|BACKEND_URL_REPLACE_ME|$BACKEND_URL|g\" openapi.yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a valid OpenAPI file referencing your backend.<\/p>\n\n\n\n<p><strong>Verify:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">grep -n \"x-google-backend\" -n openapi.yaml\ngrep -n \"$BACKEND_URL\" openapi.yaml\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Note: OpenAPI and <code>x-google-backend<\/code> requirements can evolve. If you run into spec validation errors, compare your file with the latest official \u201cDeploying an API\u201d example in the API Gateway docs.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create API Gateway resources (API, config, gateway)<\/h3>\n\n\n\n<p>Set resource IDs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export API_ID=\"hello-api\"\nexport API_CONFIG_ID=\"hello-config-v1\"\nexport GATEWAY_ID=\"hello-gateway\"\n<\/code><\/pre>\n\n\n\n<p>Create the API:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud api-gateway apis create \"$API_ID\"\n<\/code><\/pre>\n\n\n\n<p>Create the API config from your OpenAPI file:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud api-gateway api-configs create \"$API_CONFIG_ID\" \\\n  --api=\"$API_ID\" \\\n  --openapi-spec=\"openapi.yaml\" \\\n  --project=\"$PROJECT_ID\"\n<\/code><\/pre>\n\n\n\n<p>Create the gateway (regional):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud api-gateway gateways create \"$GATEWAY_ID\" \\\n  --api=\"$API_ID\" \\\n  --api-config=\"$API_CONFIG_ID\" \\\n  --location=\"$REGION\" \\\n  --project=\"$PROJECT_ID\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The gateway is created and becomes ready.<\/p>\n\n\n\n<p><strong>Verify (get gateway hostname):<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">export GATEWAY_HOST\nGATEWAY_HOST=\"$(gcloud api-gateway gateways describe \"$GATEWAY_ID\" --location \"$REGION\" --format='value(defaultHostname)')\"\necho \"Gateway host: $GATEWAY_HOST\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create an API key for clients<\/h3>\n\n\n\n<p>Create an API key (you can do this via Console or <code>gcloud<\/code>). Here is the <code>gcloud<\/code> approach:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export KEY_DISPLAY_NAME=\"hello-gateway-key\"\n\ngcloud services api-keys create --display-name=\"$KEY_DISPLAY_NAME\"\n<\/code><\/pre>\n\n\n\n<p>List keys and capture the resource name for the key you just created:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services api-keys list --format=\"table(name,displayName,createTime)\"\n<\/code><\/pre>\n\n\n\n<p>Set <code>KEY_NAME<\/code> to the <code>name<\/code> value (it looks like <code>projects\/...\/locations\/global\/keys\/...<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export KEY_NAME=\"PASTE_KEY_NAME_HERE\"\n<\/code><\/pre>\n\n\n\n<p>Fetch the actual key string:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export API_KEY\nAPI_KEY=\"$(gcloud services api-keys get-key-string \"$KEY_NAME\" --format='value(keyString)')\"\necho \"API key: $API_KEY\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have an API key string to use in requests.<\/p>\n\n\n\n<blockquote>\n<p>Best practice: restrict API keys. Restriction options depend on the service infrastructure backing your gateway configuration. Review the API Gateway docs for recommended key restriction patterns and avoid leaving keys unrestricted in production.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Call the API through API Gateway<\/h3>\n\n\n\n<p>Because your OpenAPI requires an API key via the <code>x-api-key<\/code> header, first try without a key:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"https:\/\/$GATEWAY_HOST\/\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You should receive an authorization-related error (typically 401\/403) because the key is missing.<\/p>\n\n\n\n<p>Now call with the key:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"https:\/\/$GATEWAY_HOST\/\" -H \"x-api-key: $API_KEY\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> HTTP 200 from the backend, but served through the gateway endpoint.<\/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>Use these checks to confirm the end-to-end behavior:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Gateway is reachable:<\/strong>\n<code>bash\n   curl -I \"https:\/\/$GATEWAY_HOST\/\"<\/code><\/p>\n<\/li>\n<li>\n<p><strong>Auth is enforced:<\/strong>\n   &#8211; Without <code>x-api-key<\/code> \u2192 denied\n   &#8211; With <code>x-api-key<\/code> \u2192 allowed<\/p>\n<\/li>\n<li>\n<p><strong>Backend is being called:<\/strong>\n   &#8211; Compare the response body from:<\/p>\n<ul>\n<li><code>curl \"$BACKEND_URL\"<\/code><\/li>\n<li><code>curl \"https:\/\/$GATEWAY_HOST\/\" -H \"x-api-key: $API_KEY\"<\/code><\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Logs exist in Cloud Logging:<\/strong>\n   &#8211; In the Console: <strong>Logging \u2192 Logs Explorer<\/strong>\n   &#8211; Filter by resource relevant to API Gateway (resource types and labels can vary). Search for the gateway ID, or filter by the API Gateway service.\n   &#8211; If unsure, query logs by keyword:<\/p>\n<ul>\n<li><code>hello-gateway<\/code><\/li>\n<li>the gateway hostname<\/li>\n<li>your request path<\/li>\n<\/ul>\n<\/li>\n<\/ol>\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<ol class=\"wp-block-list\">\n<li>\n<p><strong><code>PERMISSION_DENIED<\/code> when creating API\/config\/gateway<\/strong>\n   &#8211; Ensure your user\/service account has sufficient IAM roles for API Gateway administration.\n   &#8211; Confirm the required APIs are enabled.<\/p>\n<\/li>\n<li>\n<p><strong>OpenAPI spec validation errors<\/strong>\n   &#8211; Compare your OpenAPI with the latest official example.\n   &#8211; Confirm indentation and that the <code>x-google-backend.address<\/code> is an HTTPS URL.\n   &#8211; If you add additional paths, ensure backends can serve those paths.<\/p>\n<\/li>\n<li>\n<p><strong>Gateway host returns 404<\/strong>\n   &#8211; Confirm you are requesting a path defined in the OpenAPI (this tutorial defines only <code>\/<\/code>).\n   &#8211; Confirm the gateway is deployed with the config you expect.<\/p>\n<\/li>\n<li>\n<p><strong>Backend returns 403\/401<\/strong>\n   &#8211; If Cloud Run is not <code>--allow-unauthenticated<\/code>, the gateway call will fail unless you configure the gateway\/backend auth pattern correctly (service identity, tokens). For this beginner lab we made Cloud Run public.<\/p>\n<\/li>\n<li>\n<p><strong>API key doesn\u2019t work<\/strong>\n   &#8211; Confirm your OpenAPI security definition uses the same header name you send (<code>x-api-key<\/code>).\n   &#8211; Confirm you used the correct key string (not the key resource name).\n   &#8211; If key restrictions were applied, confirm they match the gateway\/service configuration.<\/p>\n<\/li>\n<\/ol>\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>To avoid ongoing charges, delete resources:<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Delete API Gateway resources\ngcloud api-gateway gateways delete \"$GATEWAY_ID\" --location=\"$REGION\" --quiet\ngcloud api-gateway api-configs delete \"$API_CONFIG_ID\" --api=\"$API_ID\" --quiet\ngcloud api-gateway apis delete \"$API_ID\" --quiet\n\n# Delete Cloud Run service\ngcloud run services delete \"$RUN_SERVICE\" --region=\"$REGION\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete the API key (optional but recommended):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services api-keys delete \"$KEY_NAME\" --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> No gateway, config, API, backend service, or key remains.<\/p>\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 OpenAPI as code:<\/strong> keep specs in Git, review via pull requests, and run OpenAPI linting in CI.<\/li>\n<li><strong>Separate environments:<\/strong> use distinct APIs\/gateways per environment (dev\/staging\/prod) or distinct projects where appropriate.<\/li>\n<li><strong>Design for change:<\/strong> version your endpoints (<code>\/v1\/...<\/code>) and create new API configs for breaking changes.<\/li>\n<li><strong>Keep gateway responsibilities minimal:<\/strong> do auth + routing + basic validation; avoid pushing complex business logic into the gateway layer.<\/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> restrict who can create\/update API configs and gateways.<\/li>\n<li><strong>Separation of duties:<\/strong> platform team manages gateway; app team manages backend; coordinate via CI\/CD.<\/li>\n<li><strong>API keys are not user auth:<\/strong> use JWT\/OIDC for user identity and authorization where appropriate.<\/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>Control <strong>logging volume<\/strong> (avoid excessive payload logging; use exclusions where safe).<\/li>\n<li>Keep backend latency low to reduce Cloud Run\/Functions compute cost.<\/li>\n<li>Avoid unnecessary extra hops (for example, adding a load balancer in front) unless you need features like custom domain, Cloud Armor, or global routing.<\/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>Place gateway and backend in the <strong>same region<\/strong> to reduce latency and egress between them (validate networking costs).<\/li>\n<li>Optimize Cloud Run concurrency and handler performance.<\/li>\n<li>Keep payload sizes small; use pagination and compression strategies.<\/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>Use <strong>multiple gateway deployments<\/strong> only when justified (multi-region DR, latency). Document failover.<\/li>\n<li>Implement retries carefully on clients (idempotency and backoff).<\/li>\n<li>Monitor 5xx rates and latency at both gateway and backend.<\/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>Create dashboards tracking:<\/li>\n<li>request count, error rate (4xx\/5xx), latency distributions<\/li>\n<li>backend saturation signals (Cloud Run concurrency, CPU)<\/li>\n<li>Define alerts on:<\/li>\n<li>sustained 5xx spikes<\/li>\n<li>auth failures spikes (could indicate abuse or client bugs)<\/li>\n<li>latency regressions<\/li>\n<li>Standardize naming: <code>api-&lt;domain&gt;-&lt;env&gt;<\/code>, <code>gw-&lt;domain&gt;-&lt;env&gt;<\/code>, <code>cfg-&lt;domain&gt;-vN<\/code>.<\/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>Use labels (where supported) for cost allocation: <code>env<\/code>, <code>team<\/code>, <code>system<\/code>, <code>cost-center<\/code>.<\/li>\n<li>Maintain an API inventory: owners, SLA, data classification, consumers, change policy.<\/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><strong>Admin plane:<\/strong> controlled by IAM (who can deploy\/modify gateway resources).<\/li>\n<li><strong>Runtime plane:<\/strong> client identity is typically established via API keys and\/or JWT validation (verify currently supported mechanisms and configurations).<\/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>Client-to-gateway traffic uses <strong>HTTPS\/TLS<\/strong>.<\/li>\n<li>Gateway-to-backend should also use HTTPS whenever possible (especially for Cloud Run\/Cloud Functions URLs).<\/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>API Gateway endpoints are typically <strong>internet-accessible<\/strong> via a Google-managed hostname.<\/li>\n<li>If you need private ingress or IP allowlists, you may need additional edge components (load balancer + policy) and a carefully designed backend exposure 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>Do not embed secrets in OpenAPI specs stored in Git.<\/li>\n<li>API keys must be stored and rotated securely (Secret Manager, CI secret stores).<\/li>\n<li>Never log API keys or JWTs in plaintext.<\/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>Use <strong>Cloud Audit Logs<\/strong> to track who changed API Gateway resources.<\/li>\n<li>Use <strong>Cloud Logging<\/strong> for access logs, but ensure logs don\u2019t contain sensitive payload data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data residency: gateways are regional; align region choice with compliance requirements.<\/li>\n<li>Retention: ensure log retention policies meet compliance (and cost) needs.<\/li>\n<li>Access review: periodically review IAM bindings and API key inventory.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Leaving Cloud Run backends publicly callable when the gateway is intended as the only entry point.<\/li>\n<li>Using API keys as the sole control for sensitive user data APIs.<\/li>\n<li>Not rotating keys or not revoking unused keys.<\/li>\n<li>Overly broad IAM permissions for gateway deployment.<\/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>Prefer JWT\/OIDC for user-level authentication.<\/li>\n<li>If using API keys, restrict and rotate them; monitor usage anomalies.<\/li>\n<li>Consider Cloud Armor (via a load balancer in front) for WAF\/bot protections if you have public exposure.<\/li>\n<li>Ensure backends validate authorization too (defense in depth).<\/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<p>The following are common constraints to plan for. <strong>Verify current details and quotas in official docs<\/strong>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Not a full API management suite:<\/strong> limited built-in policies compared to Apigee (transformations, advanced quotas, developer portal, monetization).<\/li>\n<li><strong>OpenAPI constraints:<\/strong> some OpenAPI features may not be supported or may require Google extensions.<\/li>\n<li><strong>Custom domain requirements may add architecture:<\/strong> you may need additional services (like external HTTPS Load Balancing) depending on current API Gateway custom domain support.<\/li>\n<li><strong>Backend networking constraints:<\/strong> gateway must be able to reach your backend; private\/internal-only services may require alternate patterns.<\/li>\n<li><strong>Quotas:<\/strong> gateways per region\/project, request limits, config limits.<\/li>\n<li><strong>Logging volume:<\/strong> gateway access logs can become noisy; plan exclusions and retention carefully.<\/li>\n<li><strong>Multi-region design:<\/strong> if you need global traffic management, API Gateway alone may not provide global anycast\/edge routing; consider fronting it with global load balancing (tradeoffs: cost and complexity).<\/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<h3 class=\"wp-block-heading\">Nearest services in Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Apigee:<\/strong> full API management platform (policies, quotas, developer portal, analytics, monetization).<\/li>\n<li><strong>Cloud Endpoints:<\/strong> older approach for API management\/proxy using service infrastructure and ESP; may still be used in existing systems, but evaluate current recommendations.<\/li>\n<li><strong>Cloud Load Balancing + Cloud Armor:<\/strong> not an API gateway by itself, but can provide edge routing, TLS, WAF, and L7 controls. Often combined with gateway\/backends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS API Gateway<\/strong><\/li>\n<li><strong>Azure API Management<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source\/self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Kong<\/strong>, <strong>NGINX<\/strong>, <strong>Envoy<\/strong>, <strong>Tyk<\/strong> (requires you to run\/patch\/scale and integrate logging\/auth).<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\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>Google Cloud API Gateway<\/strong><\/td>\n<td>Simple managed gateway for OpenAPI-defined HTTP APIs<\/td>\n<td>Managed runtime, OpenAPI configs, integrates with Cloud Run\/Functions, basic auth + observability<\/td>\n<td>Fewer advanced API management features than Apigee; may require extra components for edge needs<\/td>\n<td>Serverless-first teams needing a consistent entry point and basic controls<\/td>\n<\/tr>\n<tr>\n<td><strong>Apigee (Google Cloud)<\/strong><\/td>\n<td>Enterprise API management<\/td>\n<td>Rich policy framework, quotas, analytics, developer portal, lifecycle governance<\/td>\n<td>More complex; typically higher cost; more platform to operate<\/td>\n<td>Large-scale partner ecosystems, advanced API programs, complex governance\/policies<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Endpoints (Google Cloud)<\/strong><\/td>\n<td>Existing deployments; lightweight API proxy patterns<\/td>\n<td>Mature patterns; integrates with service infrastructure<\/td>\n<td>Product positioning vs API Gateway can be confusing; evaluate latest guidance<\/td>\n<td>If you already run it and it meets needs; otherwise re-evaluate<\/td>\n<\/tr>\n<tr>\n<td><strong>External HTTPS LB + Cloud Armor<\/strong><\/td>\n<td>Edge security + routing<\/td>\n<td>Global edge, WAF\/bot controls, TLS, routing features<\/td>\n<td>Not a full API contract\/auth layer by itself<\/td>\n<td>When you need advanced edge controls and are building a layered approach<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS API Gateway<\/strong><\/td>\n<td>AWS-native managed API gateway<\/td>\n<td>Deep AWS integration; broad features<\/td>\n<td>Cross-cloud complexity if you\u2019re on Google Cloud<\/td>\n<td>When primary platform is AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure API Management<\/strong><\/td>\n<td>Azure-native API management<\/td>\n<td>Strong enterprise features<\/td>\n<td>Cross-cloud complexity if you\u2019re on Google Cloud<\/td>\n<td>When primary platform is Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Kong\/NGINX\/Envoy (self-managed)<\/strong><\/td>\n<td>Maximum control and portability<\/td>\n<td>Highly customizable, runs anywhere<\/td>\n<td>You operate it: patching, scaling, HA, upgrades<\/td>\n<td>When you need custom policies\/features not provided by managed services<\/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: Partner onboarding API for a B2B platform<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> An enterprise exposes partner APIs for order submission and status tracking. They need a stable front door, consistent authentication, and auditability. They also require WAF protections and a custom domain.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>External HTTPS Load Balancer (custom domain, TLS) + Cloud Armor (WAF)<\/li>\n<li>API Gateway (OpenAPI contract, API key\/JWT validation)<\/li>\n<li>Cloud Run microservices (orders, status, partner management)<\/li>\n<li>Central logging\/monitoring; audit logs for configuration changes<\/li>\n<li><strong>Why API Gateway was chosen:<\/strong> It provides a managed, contract-first gateway that integrates cleanly with serverless backends while keeping operational overhead low.<\/li>\n<li><strong>Expected outcomes:<\/strong> Faster partner onboarding, fewer breaking changes through contract governance, improved incident response via gateway-level logs and metrics.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Mobile app backend on Cloud Run<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A small team needs a stable API URL, basic access control, and the ability to evolve the backend quickly without running infrastructure.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>API Gateway in front of Cloud Run<\/li>\n<li>JWT validation for signed-in users (verify and implement per docs)<\/li>\n<li>Cloud Logging + basic alerts for 5xx and latency<\/li>\n<li><strong>Why API Gateway was chosen:<\/strong> Minimal operational overhead and easy API definition in OpenAPI, without the complexity of a full API management platform.<\/li>\n<li><strong>Expected outcomes:<\/strong> Rapid iteration, consistent API access patterns, basic security posture, and clearer debugging signals.<\/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<h3 class=\"wp-block-heading\">1) Is Google Cloud API Gateway the same as Apigee?<\/h3>\n\n\n\n<p>No. <strong>API Gateway<\/strong> is a lighter-weight managed gateway primarily driven by OpenAPI configuration and basic auth\/telemetry needs. <strong>Apigee<\/strong> is a full API management platform with advanced policies, analytics, and developer portal capabilities.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Do I need OpenAPI to use API Gateway?<\/h3>\n\n\n\n<p>In practice, yes\u2014API Gateway is configured using an <strong>OpenAPI<\/strong> spec (often OpenAPI 2.0 with Google extensions). Check the docs for currently supported OpenAPI versions and features.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Is API Gateway regional or global?<\/h3>\n\n\n\n<p>Gateways are created in a <strong>region<\/strong>. Plan region placement near your backends\/users. For global routing, you may need additional architecture (for example, global load balancing).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) Can API Gateway route to Cloud Run?<\/h3>\n\n\n\n<p>Yes, Cloud Run is a common backend target. Your OpenAPI configuration uses a backend address pointing to the Cloud Run URL.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) Can I secure the API with API keys?<\/h3>\n\n\n\n<p>Yes, API keys are a common supported pattern. Remember: API keys identify calling projects\/apps, not end users.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) Can I use JWT\/OIDC authentication?<\/h3>\n\n\n\n<p>API Gateway commonly supports JWT validation patterns, but exact capabilities\/configuration options can change. <strong>Verify supported JWT providers and configuration in official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) Does API Gateway do rate limiting?<\/h3>\n\n\n\n<p>Basic quota behaviors may exist via underlying service infrastructure, but advanced rate limiting\/policy control is generally not the same as Apigee. If you need sophisticated rate limiting, evaluate alternatives.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) Can I use a custom domain name?<\/h3>\n\n\n\n<p>API Gateway provides a default hostname. For custom domains, you may need additional configuration or a load balancer in front depending on current product support\u2014<strong>verify current custom domain guidance<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Can API Gateway protect against OWASP API attacks?<\/h3>\n\n\n\n<p>Not by itself like a WAF would. For WAF\/bot mitigation, consider <strong>Cloud Armor<\/strong> (typically attached to a load balancer in front of the gateway).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) Should I still secure my backend if I use API Gateway?<\/h3>\n\n\n\n<p>Yes. Use defense in depth. Backends should enforce authorization and should not assume the gateway is the only caller unless you have enforced that at the network\/identity level.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) How do I version APIs safely?<\/h3>\n\n\n\n<p>Use versioned paths (<code>\/v1<\/code>) and\/or separate API configs. Promote configs through environments via CI\/CD and keep rollback configs available.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) What\u2019s the operational visibility like?<\/h3>\n\n\n\n<p>You get gateway-level logs and metrics integrated with Cloud Logging\/Monitoring. Combine this with backend metrics (Cloud Run) for full tracing of latency and errors.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) How does API Gateway compare to running Kong or NGINX?<\/h3>\n\n\n\n<p>API Gateway is managed (less ops). Self-managed gateways provide more customization but require patching, scaling, HA design, and ongoing maintenance.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) Can I use API Gateway for internal APIs only?<\/h3>\n\n\n\n<p>Yes, but you must design access controls appropriately (IAM\/admin controls, runtime auth, network exposure). Verify how to limit exposure (for example, private access patterns).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) What should I monitor first in production?<\/h3>\n\n\n\n<p>Start with:\n&#8211; request volume\n&#8211; 4xx\/5xx rates\n&#8211; latency percentiles\n&#8211; backend saturation (Cloud Run concurrency\/CPU)\n&#8211; auth failures spikes (potential abuse or client misconfiguration)<\/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 API Gateway<\/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>API Gateway docs: https:\/\/cloud.google.com\/api-gateway\/docs<\/td>\n<td>Authoritative reference for concepts, configuration, limits, and operations<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>API Gateway pricing: https:\/\/cloud.google.com\/api-gateway\/pricing<\/td>\n<td>Current SKUs, billing dimensions, and free tier (if any)<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build request-volume-based estimates including backend, logs, and egress<\/td>\n<\/tr>\n<tr>\n<td>Getting started<\/td>\n<td>API Gateway tutorials\/quickstarts (start here): https:\/\/cloud.google.com\/api-gateway\/docs\/tutorials<\/td>\n<td>Step-by-step guides with Cloud Run\/Cloud Functions examples<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td><code>gcloud api-gateway<\/code> reference: https:\/\/cloud.google.com\/sdk\/gcloud\/reference\/api-gateway<\/td>\n<td>Exact commands\/flags for scripting and CI\/CD<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>Cloud Logging: https:\/\/cloud.google.com\/logging\/docs<\/td>\n<td>How to query gateway logs, build alerts, export logs<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>Cloud Monitoring: https:\/\/cloud.google.com\/monitoring\/docs<\/td>\n<td>Dashboards and alerting for API health<\/td>\n<\/tr>\n<tr>\n<td>Serverless backend<\/td>\n<td>Cloud Run docs: https:\/\/cloud.google.com\/run\/docs<\/td>\n<td>Backend deployment patterns and security\/performance tuning<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center: https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures and best practices (search for API and serverless patterns)<\/td>\n<\/tr>\n<tr>\n<td>Samples<\/td>\n<td>GoogleCloudPlatform on GitHub: https:\/\/github.com\/GoogleCloudPlatform<\/td>\n<td>Many official samples; search within for API Gateway\/ESPv2 patterns<\/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, developers<\/td>\n<td>Google Cloud fundamentals, DevOps, CI\/CD, cloud operations; may include API exposure patterns<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>DevOps\/SCM foundations, tooling, practical labs<\/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 operations and DevOps learners<\/td>\n<td>Cloud operations, monitoring, reliability practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations teams<\/td>\n<td>SRE principles, production readiness, monitoring\/incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops\/SRE and automation-focused teams<\/td>\n<td>AIOps concepts, automation, operational analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/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>DevOps\/cloud training and mentoring (verify offerings)<\/td>\n<td>Individuals and teams wanting guided training<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tooling and practices (verify offerings)<\/td>\n<td>Beginners to working professionals<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps consulting\/training resources (verify offerings)<\/td>\n<td>Teams seeking flexible coaching<\/td>\n<td>https:\/\/devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify offerings)<\/td>\n<td>Teams needing operational help and upskilling<\/td>\n<td>https:\/\/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)<\/td>\n<td>Architecture, platform engineering, delivery enablement<\/td>\n<td>API platform patterns, CI\/CD design, operational readiness reviews<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps\/cloud consulting and training<\/td>\n<td>DevOps transformation, CI\/CD, cloud migrations<\/td>\n<td>Standardizing API delivery pipelines, SRE enablement, governance<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact services)<\/td>\n<td>Automation, cloud operations, deployment engineering<\/td>\n<td>Implementing CI\/CD for API Gateway + Cloud Run, monitoring and alerting setup<\/td>\n<td>https:\/\/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 API Gateway<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>HTTP fundamentals: methods, headers, status codes, TLS<\/li>\n<li>REST API design: versioning, pagination, idempotency<\/li>\n<li>OpenAPI basics (especially OpenAPI 2.0\/Swagger if required by your implementation)<\/li>\n<li>Google Cloud basics: projects, IAM, service accounts, billing<\/li>\n<li>A backend runtime: Cloud Run or Cloud Functions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after API Gateway<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Apigee (if you need enterprise API management)<\/li>\n<li>Cloud Load Balancing + Cloud Armor (edge security and global routing)<\/li>\n<li>Observability at scale: log-based metrics, tracing, SLOs<\/li>\n<li>Secure API design: OAuth2\/OIDC, JWT hardening, threat modeling<\/li>\n<li>CI\/CD for API contracts and gateways (policy-as-code and spec validation)<\/li>\n<\/ul>\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 \/ SRE<\/li>\n<li>Backend engineer (API-focused)<\/li>\n<li>Security engineer (API security posture)<\/li>\n<li>Solutions architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>Google Cloud certifications change over time. A practical path is:\n&#8211; Associate Cloud Engineer (foundation)\n&#8211; Professional Cloud Developer or Professional Cloud Architect (role-dependent)\n&#8211; Add SRE\/DevOps focus depending on your job role<br\/>\nVerify current certification tracks at: 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 multi-service API gateway routing to three Cloud Run services with separate paths.<\/li>\n<li>Implement JWT validation and role-based authorization in the backend (defense in depth).<\/li>\n<li>Add an external HTTPS load balancer + Cloud Armor in front (if needed) and measure latency\/cost tradeoffs.<\/li>\n<li>Create a CI pipeline that lints OpenAPI and deploys a new API config to staging.<\/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 Gateway:<\/strong> Managed Google Cloud service that exposes APIs via a managed endpoint using an OpenAPI configuration.<\/li>\n<li><strong>OpenAPI (Swagger):<\/strong> Specification format for describing REST APIs (paths, methods, schemas, and security).<\/li>\n<li><strong>API (API Gateway resource):<\/strong> Logical container representing an API within a Google Cloud project.<\/li>\n<li><strong>API config:<\/strong> Versioned configuration created from an OpenAPI document and deployed to a gateway.<\/li>\n<li><strong>Gateway:<\/strong> The regional managed runtime that serves your API configuration and provides a hostname.<\/li>\n<li><strong>API key:<\/strong> A string credential used to identify calling applications\/projects (not a user identity).<\/li>\n<li><strong>JWT (JSON Web Token):<\/strong> A signed token used for stateless authentication\/claims; commonly used with OIDC.<\/li>\n<li><strong>IAM (Identity and Access Management):<\/strong> Google Cloud authorization system controlling who can administer resources.<\/li>\n<li><strong>Cloud Run:<\/strong> Serverless container platform on Google Cloud; commonly used as an API backend.<\/li>\n<li><strong>Cloud Logging:<\/strong> Central log storage\/query service for Google Cloud.<\/li>\n<li><strong>Cloud Monitoring:<\/strong> Metrics, dashboards, and alerting for Google Cloud services.<\/li>\n<li><strong>Cloud Armor:<\/strong> Google Cloud WAF and DDoS protection service (typically used with load balancing).<\/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>Google Cloud <strong>API Gateway<\/strong> is a managed, OpenAPI-driven API front door for <strong>Application development<\/strong> teams building HTTP APIs\u2014especially on <strong>Cloud Run<\/strong> and <strong>Cloud Functions<\/strong>. It helps you standardize routing and baseline authentication (such as API keys and supported JWT patterns), while improving operational visibility through Cloud Logging and Monitoring.<\/p>\n\n\n\n<p>From a cost and operations perspective, the biggest drivers are request volume, backend compute, logging volume, and internet egress\u2014so model those early using the official pricing page and calculator. From a security perspective, use IAM for strong admin controls, avoid treating API keys as user authentication, and consider layering edge protections (like Cloud Armor via load balancing) for public APIs.<\/p>\n\n\n\n<p>Next step: follow the official tutorials and expand this lab to multi-service routing, JWT validation, CI\/CD-driven API config promotion, and production monitoring\/alerting.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Application development<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54,51],"tags":[],"class_list":["post-582","post","type-post","status-publish","format-standard","hentry","category-application-development","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/582","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=582"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/582\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=582"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=582"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=582"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}