Cloud Endpoints 與 API Gateway

Cloud Endpoints 與 API Gateway 簡介

Google Cloud 提供兩個獨立但相鄰的 API 管理產品，PCD 考試會把它們當成兩個不同的答案，另外再加上 Apigee 作為干擾選項。Cloud Endpoints 是較舊的 proxy-based 方案：你把 Extensible Service Proxy (ESP 或 ESPv2) 以 sidecar 形式部署在後端 (App Engine flexible、GKE、Compute Engine、Cloud Run) 前面，由該 proxy 透過呼叫 Service Control API 與 Service Management API 來執行驗證、配額與遙測。API Gateway 則是較新的全代管 serverless 閘道，專為 Cloud Run、Cloud Functions (1st / 2nd gen)、App Engine 後端設計 — 資料平面由 Google 以 Envoy 維運，你只要上傳一份 OpenAPI v2 spec，Google 就會替你開出 Gateway endpoint。Apigee 是企業級的全生命週期平台 (開發者入口網站、收費機制、進階 policy)，只有當題目提到合作夥伴變現、複雜的 policy chain 或公開 API product catalog 時才會是正確答案。

PCD 要求你能依題幹敘述判斷該選哪個產品、記住每個產品支援哪些傳輸協定與驗證方式、寫出一份能啟用 API Key / JWT / Firebase Auth / Google ID Token 的最小 OpenAPI spec、設定 配額 阻擋濫用流量，並能讀懂 proxy 送進 Cloud Logging 與 Cloud Monitoring 的紀錄與指標。本筆記會搭配實際的 gcloud 指令、OpenAPI 片段，以及驅動選擇樹的取捨，把這些元件逐一展開。

後端是 Cloud Run / Cloud Functions / App Engine 且要求零維運時選 API Gateway。需要 gRPC、gRPC transcoding to REST，或後端跑在 GKE / GCE / 地端 時選 Cloud Endpoints 搭配 ESPv2。要求 開發者入口網站、變現或進階 policy chain 時才選 Apigee。三者都支援 API Key、JWT 與 Cloud Logging / Monitoring；只有 Endpoints 能處理 gRPC；只有 Apigee 內建完整 developer portal。 ::

白話文解釋（Plain English Explanation）

API gateway 的詞彙 — proxy、sidecar、OpenAPI spec、Service Control、quota — 密度很高，所以先用三個類比把概念釘穩，再進入 YAML 與 gcloud 指令。

類比 1：飯店櫃台 vs. 禮賓部 vs. 旅遊顧問

想像有三個不同角色擋在房客與飯店設施之間。櫃台接待員就是 API Gateway — 他坐在 Google 蓋好的那一張固定櫃台後面，幫你查房卡 (API Key) 與訂房紀錄 (JWT)，再把你導向正確的設施：spa、健身房、餐廳 (Cloud Run、Cloud Functions、App Engine)。他不處理 gRPC，因為這間飯店的 spa 從不講 gRPC。禮賓部 (Concierge) 就是 Cloud Endpoints + ESPv2 — 他可以站在任何建築物的任何門口 (sidecar 部署在 GKE、GCE、地端的 app 旁邊)，而且同時聽得懂英文與員工內部對講機代號 (REST 與 gRPC)。他比較彈性，但你得幫他準備制服並指定站哪裡。大廳的旅遊顧問就是 Apigee — 他不只查證件，還賣套裝行程 (變現)、維護一個簡介架 (developer portal)、辦會員制度 (進階 policy)。對「讓內部服務互相呼叫」來說殺雞用牛刀，對「要把 API 賣給 200 家合作夥伴」來說則是必要工具。

類比 2：餐廳菜單 (OpenAPI Spec)

OpenAPI 規格 就是餐廳的印刷菜單。廚房 (你的後端服務) 會做的菜很多，但菜單會告訴客人哪些菜有供應、每道菜叫什麼名字 (path)、有哪些變化 (parameters)、含哪些過敏原 (驗證需求：api_key、jwt)、價格多少 (quota cost)。每次推出新菜，就重新印一張菜單 — 對應到 gcloud endpoints services deploy openapi.yaml 或 gcloud api-gateway api-configs create。Gateway / proxy 本身則是服務生：他照菜單收單，菜單上沒有的東西一律拒絕，會在點菜單上補上桌號 (request ID)，再把點菜單送回廚房。服務生從不發揮創意 — 不在 spec 裡的，一律 404。

類比 3：高速公路收費站 (配額與 Service Control)

配額的運作很像搭配每日點數卡的收費站。OpenAPI spec 宣告配額 metric ("read-requests"、"write-requests") 與上限 ("每分鐘每位 consumer 1000 次")。每個呼叫都帶著 API Key — 那就是點數卡。Proxy (ESP) 或 Gateway 在每一個請求時都會回頭呼叫 Service Control API，問「這張卡還有額度嗎？」並上報 (report) 用掉了多少。如果卡點數用完，proxy 就立刻回 HTTP 429，根本不會打擾後端。後端是你的景觀收費道路 — 他可以專心提供駕駛體驗，不必數車。Service Management API 則是鎮公所裡另一間獨立的辦公室，你跑那邊去註冊這條收費道路、宣告費率、印新的點數卡；Gateway 的資料平面在 runtime 不會去碰那間辦公室。

Cloud Endpoints 架構 — ESP、ESPv2 與 Service Control 迴圈

Cloud Endpoints 本質上是一個由 Google 代管的 control plane，搭配一個由你自己跑的開源 proxy 資料平面。理解這兩半各自跑在哪裡，是整個考試最值錢的心智模型。

ESP 與 ESPv2 — 你到底該跑哪個 proxy？

ESP (Extensible Service Proxy) 是初代的 NGINX-based proxy，支援 OpenAPI 2.0 與 gRPC，可以跑在 App Engine flexible、GKE、GCE 與 Kubernetes 上。ESPv2 是基於 Envoy 的新一代替代品；它支援同樣的 OpenAPI 2.0 輸入，再加上 gRPC transcoding 為 JSON/REST、更好的 HTTP/2 處理，而且是 Cloud Run 上唯一支援的 proxy (因為 Cloud Run 本來就跑 container，Envoy 剛好符合模型)。新部署應預設使用 ESPv2 (gcr.io/endpoints-release/endpoints-runtime-serverless:2)。ESP 已進入維護模式，但仍會出現在較舊的 PCD reference architecture 題目中。

Service Control 呼叫路徑

每個進來的請求會在 proxy 內部依下列順序流過：

1. 驗證 (Authentication) — 對 Service Management 驗證 API Key、或對設定的 issuer 的 JWKS 驗證 JWT。
2. 授權 / 配額檢查 (Authorization / quota check) — 呼叫 servicecontrol.googleapis.com/v1/services/{service}:check 確認 API Key 仍啟用且配額還有餘量。
3. 轉送到後端 — 走 HTTP/1.1、HTTP/2 或 gRPC。
4. 回報 (Report) — 非同步呼叫 servicecontrol.googleapis.com/v1/services/{service}:report 帶上 metric (latency、status、bytes、quota 消耗)。 check 是同步呼叫，會增加約 5–20 ms；report 是批次呼叫，幾乎免費。這也是為什麼 ESPv2 若用錯 service account (缺 roles/servicemanagement.serviceController)，每個請求都會 503 — proxy 連不上 Service Control。

Service Management API vs. Service Control API

Service Management 是設定面 (config plane) — 儲存你的 OpenAPI spec、API Key 定義、配額定義與版本歷程。每次 deploy 才會被 gcloud endpoints services deploy 打一次。Service Control 是執行面 (runtime plane) — proxy 在每一個請求都會打。兩個 API 常被干擾選項混為一談；認得這個拆分至少值一題。

OpenAPI 規格 — 如何描述一個 Endpoints / API Gateway 服務

Cloud Endpoints 與 API Gateway 都吃 OpenAPI 2.0 (前身為 Swagger 2.0) 規格。撰寫當下，兩者都不支援 OpenAPI 3.0 — 注意「上傳 OpenAPI 3.0 spec」這種干擾選項。gRPC 服務則改用 .proto 檔搭配 gRPC service config YAML。

最小可用 spec

一份指向 Cloud Run 後端、可用於 API Gateway 的 openapi.yaml 大致長這樣：

swagger: "2.0"
info:
  title: orders-api
  version: 1.0.0
host: orders.gateway.dev
schemes: [https]
produces: [application/json]
x-google-backend:
  address: https://orders-abcdef-uc.a.run.app
paths:
  /orders/{id}:
    get:
      operationId: getOrder
      parameters:
        - name: id
          in: path
          required: true
          type: string
      security:
        - api_key: []
      responses:
        "200": { description: OK }
securityDefinitions:
  api_key:
    type: apiKey
    name: key
    in: query

注意 x-google-backend.address — 這個 Google 專屬擴充欄位告訴 API Gateway 該轉送到哪裡。對 Endpoints 部署 Cloud Run 後端時，等價擴充是 x-google-backend.jwt_audience，用來把 Google 簽發的 ID token 帶到私有 Cloud Run 服務。

必須認得的 x-google-* 擴充欄位

• x-google-backend.address — 後端 URL。
• x-google-backend.deadline — 單一路由 timeout 秒數 (預設 15，API Gateway 上限 300)。
• x-google-backend.path_translation — CONSTANT_ADDRESS 與 APPEND_PATH_TO_ADDRESS 兩種策略。
• x-google-issuer、x-google-jwks_uri、x-google-audiences — securityDefinitions 下的 JWT 驗證參數。
• x-google-management.metrics 與 x-google-management.quota — 用於宣告自訂配額 metric 來做 rate limiting。
• x-google-allow — all 或 configured，控制未列出的 path 要轉送還是拒絕。

部署 spec

Endpoints：gcloud endpoints services deploy openapi.yaml 會產生一個 config ID；再以 --rollout_strategy=managed 重新部署搭載 proxy 的後端，讓它持續拉最新 config。API Gateway：gcloud api-gateway api-configs create v1 --api=orders --openapi-spec=openapi.yaml，接著 gcloud api-gateway gateways create orders-gw --api=orders --api-config=v1 --location=us-central1。Gateway URL 是 regional，長相為 https://orders-gw-<hash>.uc.gateway.dev。

gRPC 支援 — 為什麼 Endpoints 在這裡完勝

gRPC 支援是兩個產品最乾淨的分水嶺，幾乎是必出考題。

Endpoints 的 gRPC pass-through

Cloud Endpoints 搭配 ESPv2 是 Google 唯一可以端到端代理原生 gRPC 的 API 管理產品。你用 Protocol Buffers .proto 定義服務，產生gRPC service config YAML，接著 gcloud endpoints services deploy api_descriptor.pb api_config.yaml。ESPv2 會在 HTTP/2 上接收 application/grpc 請求，依設定執行驗證與配額 (做法與 REST 完全相同)，再把二進位 protobuf frame 轉發給後端。

gRPC transcoding — REST 進、gRPC 出

ESPv2 也支援 gRPC transcoding：在 .proto 上加註 google.api.http 選項，proxy 就會接收來自客戶端的 HTTP/1.1 上的 JSON，把它轉成 gRPC 給後端，再把回應反向轉回 JSON。這就是 Google 自家公開 API (Pub/Sub、Spanner、BigQuery) 用單一服務定義同時對外提供 REST 與 gRPC 的方式。Transcoding 完全在 .proto 裡設定，不必另外維護一份 OpenAPI spec。

為什麼 API Gateway 做不到 gRPC

API Gateway 不支援 gRPC 後端，也不做 gRPC transcoding。 它的 Envoy 資料平面被設定為只處理 HTTP/1.1 與 HTTP/2 JSON。如果 PCD 題目敘述「我在 GKE 上有 gRPC 服務，想要代管驗證與配額」，正確答案是 Cloud Endpoints with ESPv2 sidecar，不是 API Gateway。

驗證方式 — API Key、JWT、Firebase、Google ID Token、OAuth 2.0

兩個產品實作相同的五種驗證模式，都在 OpenAPI spec 的 securityDefinitions 宣告，由 proxy / gateway 在請求到達後端之前強制執行。

API Key

API Key 識別呼叫方專案 / consumer，不是呼叫方使用者。它在 APIs & Services → Credentials 建立，以 ?key=... query param 或 x-api-key header 帶入。用途是rate limiting、每個 consumer 的使用分析、快速停用濫用客戶端。不要用它做使用者驗證 — key 會外洩。

JWT (issuer + JWKS)

通用 JWT 驗證：宣告 x-google-issuer (例如 https://accounts.example.com)、x-google-jwks_uri (公鑰 endpoint) 與 x-google-audiences (期望的 aud claim)。Proxy 會在每個請求驗證簽章、過期與 audience。這是你自己掌控 IdP 的機器對機器 (machine-to-machine) 驗證的標準模式。

Firebase Auth

JWT 驗證的特化，issuer 為 https://securetoken.google.com/<project-id>、JWKS URI 為 https://www.googleapis.com/service_accounts/v1/metadata/x509/[email protected]。當客戶端是已經用 Firebase Authentication 做使用者登入的 mobile app 或 web app (Google 登入、Email/密碼、手機 OTP、匿名登入) 時使用。

Google ID Token (service-account auth)

針對後端對後端、呼叫方本身就是 GCP workload (Cloud Run、Cloud Functions、有 Workload Identity 的 GKE pod) 的情境，呼叫方會向 metadata server 取得一個指定 aud claim 的 Google 簽發 ID token，proxy 對 https://www.googleapis.com/oauth2/v3/certs 驗證。這是 Cloud Run 在同一個 VPC 內做服務對服務 (service-to-service) 驗證的模式。

OAuth 2.0

針對使用者委派存取 (第三方應用程式代表使用者行動)，宣告 x-google-issuer 為 https://accounts.google.com，audience 對應你的 OAuth client ID。Proxy 會驗證 Google 簽發的 OAuth access token。非 Google OAuth 供應商 (Auth0、Okta) 則改用通用 JWT 模式搭配供應商的 JWKS URI。

Rate Limiting 與配額 — Service Control 的實戰

Endpoints / API Gateway 的配額在 OpenAPI spec 宣告，由 Service Control 強制執行，並透過 API Key 對應到單一 consumer。

宣告配額

你宣告一個 metric 與一或多個上限：

x-google-management:
  metrics:
    - name: "read-requests"
      displayName: "Read requests"
      valueType: INT64
      metricKind: DELTA
  quota:
    limits:
      - name: "read-limit"
        metric: "read-requests"
        unit: "1/min/{project}"
        values:
          STANDARD: 1000

再把每個 operation 的 metric cost 對接上：

paths:
  /orders/{id}:
    get:
      x-google-quota:
        metricCosts:
          read-requests: 1

一個 consumer (專案) 每分鐘呼叫 GET /orders/{id} 超過 1000 次後，會開始收到帶 RateLimitExceeded 的 HTTP 429，後端完全不會被打到。

每個方法 vs. 每個 consumer

配額永遠是每個 consumer 專案 (由 API Key 識別) — Endpoints / API Gateway 這一層不能以來源 IP 限速 (那是 Cloud Armor 的工作)。若要限制匿名流量，請對每個 path 都要求 API Key，把 key 本身當作限速單位。

配額覆寫

Consumer 可以為特定專案申請配額覆寫 (quota override) — 例如給高級客戶 10× 預設額度。覆寫在 consumer 自己的專案 APIs & Services → Quotas 管理，不是在你的專案。

選擇樹 — Cloud Endpoints vs. API Gateway vs. Apigee

這是 PCD 考試最常重複的選擇。記下提問順序，不只是記產品。

步驟 1：後端是 serverless (Cloud Run / Cloud Functions / App Engine) 且只走 REST 嗎？

是 → API Gateway。零維運、regional endpoint、設定最快、有免費額度 (每月 2M 次呼叫)。結束。

步驟 2：服務是否說 gRPC，或跑在 GKE / GCE / 地端？

是 → Cloud Endpoints with ESPv2 sidecar。這是唯一能處理 gRPC、gRPC transcoding 或非 serverless 後端的路線。

步驟 3：需要 developer portal、變現、合作夥伴上架、SOAP/REST 之間的 mediation 或複雜 policy chain 嗎？

是 → Apigee X 或 Apigee hybrid。Apigee 是唯一內建 developer portal、API products、變現與 policy chain 編輯器的產品。它也明顯更貴 — Apigee X eval 起跳大約 USD 500/月。

步驟 4：是 GKE 上內部 east-west 微服務流量嗎？

那考慮 Anthos Service Mesh (基於 Istio) 而非任何上述產品。Service Mesh 原生處理 mTLS、retry、traffic splitting 與可觀測性，不必再多一層對外 gateway。

監控、Logging 與 Tracing

兩個產品都透過 Service Control 發出相同的遙測資料，但 resource type 與 dashboard 不同。

Cloud Logging

Endpoints 寫入 log name endpoints_log、resource type 為 api；API Gateway 寫入 apigateway.googleapis.com/requests、resource type 為 apigateway.googleapis.com/Gateway。兩者都捕捉 request method、path、status、latency、consumer API Key (雜湊後) 與 JWT subject。過濾範例：

resource.type="api" AND severity>=ERROR
resource.type="apigateway.googleapis.com/Gateway" AND httpRequest.status>=500

Cloud Monitoring

兩者都在 serviceruntime.googleapis.com/ namespace 下提供標準 metric：api/request_count、api/request_latencies、api/request_sizes、api/error_count。建議的 SRE 基線告警是5xx 錯誤率高於 1% 與 p99 latency 高於 500 ms。透過 consumer_id label 可以再依 consumer 切片。

Cloud Trace

ESPv2 與 API Gateway 都會傳遞 X-Cloud-Trace-Context header，並以可設定比例採樣送進 Cloud Trace。Span 以 OpenAPI info.title 宣告的服務名稱發出。端到端 trace 可以分別觀察 proxy 與後端 latency — 對於證明「瓶頸不在 gateway」極為實用。

Endpoints Portal

Endpoints 會在 https://endpointsportal.<project-id>.cloud.goog 自動產生一個基本的 developer portal，展示 spec、方法與 try-it-out 表單。它不等同於 Apigee 的 developer portal — 沒有變現、沒有 app 註冊流程。

自訂網域與 Regional API Gateway

預設兩個產品給你的都是 Google 持有的 hostname (<service>.endpoints.<project>.cloud.goog 或 <gateway>-<hash>.uc.gateway.dev)。正式環境幾乎都會需要自訂網域。

API Gateway 的自訂網域

API Gateway 不直接接受自訂網域。受支援的模式是在 Gateway 前面架一個 Global External HTTP(S) Load Balancer，搭配 serverless NEG 指向 Gateway，掛上 managed SSL certificate，再在 LB 加自訂網域。較簡單的情境也可以用 Cloud Run 當薄薄一層 reverse proxy 並掛自訂網域對應，套在 Gateway 前面。

Cloud Endpoints 的自訂網域

Endpoints 有兩條路。(1) DNS-verified 自訂網域 — 在 Search Console 驗證網域所有權後，在 spec 寫上 host: api.example.com。適合 App Engine 與 GKE 後端 (你自己控制 LB)。(2) 在 Cloud Run / GKE 上的 ESPv2 前面架 Global External HTTP(S) Load Balancer，與 API Gateway 同樣的模式。

Regional vs. global

API Gateway 是 regional — gcloud api-gateway gateways create --location=us-central1。沒有內建 global anycast。多 region 部署的標準做法是每個 region 各建一個 Gateway，再以 Global External Load Balancer 搭配各 region 的 serverless NEG 達到低延遲 failover。Cloud Endpoints + ESPv2 on Cloud Run 沿用 Cloud Run 的 regional 模型，同樣以多 region LB 應對。Endpoints on App Engine standard 則因為 App Engine 的 global front-end 而是多 region 的。

TLS 與憑證

透過 LB 掛自訂網域時，使用 Google-managed SSL certificate (gcloud compute ssl-certificates create --domains=api.example.com --global)。DNS 驗證通常 15–60 分鐘內完成。也支援自管憑證 (--certificate=/path/to/cert.pem --private-key=...)，但 rotation 由你負責。

安全 Policy 與最佳實踐

驗證之外，幾項 gateway-level policy 能實際縮小攻擊面。

對外路徑一律要求 API Key

即便 JWT 是主要驗證機制，也務必再上一層 API Key。Key 讓你在數秒內停用濫用 consumer，不必輪替 JWT 簽章金鑰。

前面疊 Cloud Armor 做 L7 防護

Endpoints 與 API Gateway不包含 WAF 規則、地理封鎖或 DDoS shaping。對外 API 請在 Gateway 前面架 Global External HTTP(S) Load Balancer + Cloud Armor policy。Cloud Armor 處理 OWASP Top 10 規則集、bot 管理與依 IP 限速 — 正是 Gateway 那一層做不到的事。

在 LB 強制 HTTPS-only 與 HSTS

兩個 Gateway 預設都接受 HTTPS，但 HTTP→HTTPS 轉址與 Strict-Transport-Security header 注入必須由 LB 設定 (透過 backend bucket 或 Cloud Run proxy 加 header)。API Gateway 本身不會注入 HSTS。

鎖定 JWT audience

千萬不要把 x-google-audiences 設成 "*" — 那等同於停用 audience 驗證，會讓任何有效的 Google ID token 都能呼叫你的服務。一律鎖定到具體 API 名稱或後端 URL。

稽核紀錄

若法規要求保留 API spec 變更與 runtime 驗證決策證據，請對 servicemanagement.googleapis.com 與 servicecontrol.googleapis.com 啟用 Data Access audit logs。Data Access 預設是關閉的。

計費與配額 (運維現實)

• API Gateway： 每月 2M 次免費額度之後 USD $3 / 百萬次呼叫；egress 另計。
• Cloud Endpoints： 每月前 2M 次免費，2M–1B 區段 USD $3 / 百萬次，1B 以上 USD $1.50 / 百萬次。ESP/ESPv2 的運算費用算在你後端 (Cloud Run、GKE) 上。
• Apigee X： eval 大約 USD $500/月起；正式 "Standard" 從每月低數千美金起跳。
• Service Control 配額： 預設每個服務每分鐘 6000 次 check + report；高流量 API 通常需開配額調升票。

常見問題 (FAQs)

Q1：API Gateway 可以打到 Google Cloud 外 (地端或 AWS) 的後端嗎？

A1：不能直接。x-google-backend.address 必須是公開可達的 HTTPS URL，但 Gateway 本身沒有原生方式進到地端私網。受支援的做法是中間架一層 Cloud Run 或搭配 hybrid connectivity NEG 的 HTTP(S) Load Balancer，再讓 API Gateway 指向它。把 Cloud Endpoints + ESPv2 直接部署在地端叢集本身則是更直接的答案。

Q2：要從 API Gateway 安全呼叫私有 Cloud Run 服務怎麼做？

A2：把 x-google-backend.jwt_audience 設成該 Cloud Run 服務 URL，並指派一個對該服務具備 roles/run.invoker 的 service account 給 Gateway。API Gateway 會用該 audience 簽發 Google ID token，以 Authorization: Bearer ... 帶到後端。Cloud Run 服務必須設成 --no-allow-unauthenticated。

Q3：對外 API 如何在不破壞既有客戶端的前提下做版本管理？

A3：在 OpenAPI spec 中採用 path-based 版號 (/v1/orders、/v2/orders)，把每個版本當成獨立 API config 部署 (或寫在同一份 spec 裡)。Endpoints 部署新 config ID，並以 --rollout_strategy=managed 漸進切換。API Gateway 則建立新 api-config 後把 Gateway 指過去 — 它本身不支援 config 間 traffic split (要做金絲雀就在前面加 LB)。

Q4：Cloud Endpoints 支援 WebSocket 嗎？

A4：ESP (NGINX) 支援 WebSocket pass-through；ESPv2 (Envoy) 從 2.41+ 才支援 WebSocket，而且僅限 HTTP/1.1 模式。API Gateway不支援 WebSocket。長時間雙向 stream 建議改用 Endpoints 上的 gRPC streaming，或直接走 Cloud Run 服務、不要在前面掛 Gateway。

Q5：除了配額之外，怎麼擋住 API 濫用？

A5：三層組合 — (1) 前面掛 Cloud Armor 處理 IP 層 rate limiting、地理封鎖與 OWASP 規則；(2) API Gateway / Endpoints 配額做 per-consumer 流量控制；(3) Cloud Logging + 告警偵測異常模式 (4xx 突增、新 consumer ID)。對登入端點若要防 credential stuffing，再加上客戶端的 reCAPTCHA Enterprise。

Q6：可以用這些服務管理 Google Cloud 外的 API 嗎？

A6：Cloud Endpoints (透過 ESP/ESPv2) 是 container image，可以跑在任何地方 — 地端 GKE、EKS、bare-metal Kubernetes，甚至純 Docker host — 並透過公網回報 Service Control。API Gateway 是 Google Cloud 代管服務，沒有可攜形式；其後端技術上可以是任何 HTTPS endpoint，但 Gateway 本身只跑在 Google Cloud 上。Apigee hybrid 是專為地端 / 多雲 control plane 設計的 hybrid 方案。

Q7：如何防止我的 API 被過度呼叫？

A7：兩層防禦 — 在 OpenAPI spec 宣告 per-consumer 配額 (例如每個專案每分鐘 1000 次)，讓濫用者在 proxy 直接撞到 HTTP 429，後端完全不會被打到；再在 LB 加 Cloud Armor rate-limiting 規則處理匿名或未驗證路徑的 IP 層限速。後端本身的爆量保護則設 Cloud Run --max-instances 與 --concurrency，即便配額層失效，後端也不會超過已知容量。