4.1 API Management & Rate Limiting with Apigee and API Gateway

2.2 API Management & Rate Limiting with Apigee and API Gateway

Modern cloud-native architectures rely on microservices communicating over HTTP/REST and gRPC. Exposing raw backend container endpoints directly to external clients introduces severe security and operational risks, including credential leakage, resource starvation, cascading failures, and uncontrolled billing spikes. Google Cloud provides two primary API management solutions: Google Cloud API Gateway and Apigee.

---

Architectural Comparison: API Gateway vs. Apigee

Understanding when to select API Gateway versus Apigee is a core skill for Google Cloud developers.

---

Google Cloud API Gateway Deep Dive

Google Cloud API Gateway sits in front of serverless backends (Cloud Run, Cloud Functions, and App Engine), terminating incoming client requests, validating tokens, and forwarding requests over authenticated Google internal channels.

+--------------------------------------------------------------------------+
| Google Cloud API Gateway Traffic Flow                                    |
+--------------------------------------------------------------------------+
|                                                                          |
| [ Mobile / Web Client ]                                                  |
|        |                                                                 |
|        | 1. HTTP Request + Bearer JWT / API Key                          |
|        v                                                                 |
| +----------------------------------------------------------------------+ |
| | Google Cloud API Gateway (Managed Envoy Core)                        | |
| | - Uses the API config; application still validates payloads                                       | |
| | - Authenticates JWT via Google/Firebase JWKS URI                     | |
| | - Injects Service Account OIDC Identity Token                        | |
| +----------------------------------------------------------------------+ |
|        |                                                                 |
|        | 2. Authenticated Internal Ingress (`x-google-backend`)          |
|        v                                                                 |
| +----------------------------------+----------------------------------+ |
| |                                  |                                  | |
| v                                  v                                  v |
| [ Cloud Run: /orders ]     [ Cloud Functions: /auth ]     [ App Engine ]|
+--------------------------------------------------------------------------+

OpenAPI 2.0 Configuration and Google Extensions

API Gateway is configured using standard Swagger/OpenAPI 2.0 files augmented with proprietary x-google-* vendor extensions:

swagger: "2.0"
info:
  title: "Customer Commerce API"
  description: "Serverless edge API for order management"
  version: "1.0.0"
schemes:
  - "https"
produces:
  - "application/json"
paths:
  /v1/orders:
    get:
      summary: "List customer orders"
      operationId: "listOrders"
      security:
        - firebase_auth: []
      x-google-backend:
        address: "https://orders-service-xyz-uc.a.run.app"
        path_translation: "APPEND_PATH_TO_ADDRESS"
        jwt_audience: "https://orders-service-xyz-uc.a.run.app"

securityDefinitions:
  firebase_auth:
    type: "oauth2"
    flow: "implicit"
    authorizationUrl: ""
    x-google-issuer: "https://securetoken.google.com/my-gcp-project-id"
    x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com"
    x-google-audiences: "my-gcp-project-id"

Deployment Lifecycle CLI Workflow

Deploying API Gateway requires a three-step command sequence:

## Create the API resource container
gcloud api-gateway apis create commerce-api \
    --project=my-gcp-project-id

## Upload the OpenAPI spec and compile the API Config
gcloud api-gateway api-configs create commerce-api-cfg-v1 \
    --api=commerce-api \
    --openapi-spec=openapi-spec.yaml \
    --backend-auth-service-account=api-gw-invoker@my-gcp-project-id.iam.gserviceaccount.com \
    --project=my-gcp-project-id

## Provision the physical gateway instance in the target region
gcloud api-gateway gateways create commerce-gateway \
    --api=commerce-api \
    --api-config=commerce-api-cfg-v1 \
    --location=us-central1 \
    --project=my-gcp-project-id

---

Apigee Enterprise API Management & The Proxy Pipeline

Apigee abstracts downstream microservices by placing an API Proxy between client applications and backend target endpoints.

Anatomy of an API Proxy

1. ProxyEndpoint: Defines how client applications consume your API (inbound URL path, TLS settings, client authentication, and request/response transformations).
2. TargetEndpoint: Defines how the proxy communicates with downstream backend services (forwarding URLs, service discovery, connection pooling, and backend authentication).

+--------------------------------------------------------------------------+
| Apigee Flow Processing Pipeline                                          |
+--------------------------------------------------------------------------+
|                                                                          |
| Client ---> [ ProxyEndpoint PreFlow ] (SpikeArrest, VerifyJWT)           |
|                    |                                                     |
|                    v                                                     |
|             [ Conditional Flows ] (Verb & Resource Path Rules)           |
|                    |                                                     |
|                    v                                                     |
|             [ ProxyEndpoint PostFlow ]                                   |
|                    |                                                     |
|                    v                                                     |
|             [ TargetEndpoint PreFlow ] (AssignMessage, Backend Auth)     |
|                    |                                                     |
|                    v                                                     |
|             [ Target Service Invocation ] (Cloud Run / GKE / On-Prem)    |
|                    |                                                     |
|                    v                                                     |
|             [ TargetEndpoint PostFlow ]                                  |
|                    |                                                     |
|                    v                                                     |
|             [ ProxyEndpoint PostFlow ] (JSONToXML, Masking)              |
|                    |                                                     |
| Client <--- [ ProxyEndpoint PostClientFlow ] (Async Cloud Logging Sink)  |
+--------------------------------------------------------------------------+

Pipeline Flow Execution Order

• PreFlow: Always executes first on every request. Developers place high-priority security policies (e.g., SpikeArrest, VerifyAPIKey, VerifyJWT) here to terminate unauthorized or abusive traffic before executing expensive logic.
• Conditional Flows: Executes selectively based on HTTP verbs or URI path conditions (e.g., executing an XMLToJSON policy only when request.verb = "GET" AND proxy.pathsuffix MatchesPath "/items").
• PostFlow: Executes after conditional flows on every transaction. Used for global response logging, header cleanup, or CORS injection.
• PostClientFlow: Executes after the response has been completely transmitted back to the client. This flow is strictly non-blocking and is used for streaming metrics, audit logging, and analytics to Cloud Logging without impacting client perceived latency.

---

Traffic Shaping: SpikeArrest, Quota, and Backend Capacity

SpikeArrest protects services against excessive request rates. Quota tracks a business usage allowance such as 10,000 requests per developer per month. Neither automatically gives a database an exact upper bound on live connections.

Current Apigee organizations should use UseEffectiveCount=true. This uses a regional distributed sliding-window algorithm. The older smoothing description of one request every two seconds for 30pm applies to a different mode and must not be treated as the behavior of current production Apigee.

<SpikeArrest name="ProtectBackend">
  <Rate>30pm</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

Requests that exceed the policy are rejected rather than queued. A burst below the configured sliding-window allowance is not automatically rejected just because two requests arrive within the same second. Identity-based counters can use an authenticated client identifier; an API key identifies a consuming application, not necessarily an end user.

A Quota policy is appropriate for a contractual allowance. Choose its identifier, interval, distributed counter, and synchronization behavior deliberately. Asynchronous distributed counters can overshoot during bursts. A quota is not a billing reconciliation ledger.

ConcurrentRateLimit is a legacy/deprecated Edge policy and is not a current Apigee capacity-control recommendation. Protect databases through bounded application pools, workload scaling limits with headroom, timeouts, and Cloud Tasks when work can be queued. A proxy request may perform several queries or share a pool, so 75 in-flight HTTP requests do not imply exactly 75 database connections.

Protecting Backend Microservices Against Starvation

When microservices running on Cloud Run or GKE face unexpected upstream load, failures propagate downstream into databases and caches unless buffered by the API layer.

1. Fail Early at the Edge: Place SpikeArrest and VerifyJWT in the ProxyEndpoint PreFlow. An unauthorized or over-limit request can be rejected before invoking the backend, without consuming backend compute vCPU or VPC connector bandwidth.
2. Protect Shared Databases: Bound application connection pools and reserve database capacity for administration, maintenance, and concurrent revisions. Queue asynchronous work in Cloud Tasks where suitable.
3. Decouple Asynchronous Writes: When an API receives high-throughput ingestion data that does not require synchronous database writes, use Apigee to route requests directly to a Cloud Pub/Sub topic via service callout or API Gateway backend, transforming the interaction into an asynchronous event stream.

Official references checked October 18, 2026: Google Cloud 1, Google Cloud 2.