Skip to main content
GCPServerlessintermediate

API Gateway & Cloud Endpoints

Compare GCP API Gateway, Cloud Endpoints, and Apigee for configuration, authentication, rate limiting, and API lifecycle management.

CloudToolStack Team24 min readPublished Feb 22, 2026

Prerequisites

API Management on GCP

Managing APIs at scale requires more than just deploying backend services. You need authentication, rate limiting, monitoring, version management, developer documentation, and traffic control. Google Cloud offers three distinct API management products: API Gateway, Cloud Endpoints, and Apigee, each targeting different complexity levels and organizational needs. Choosing the right one depends on your team size, API maturity, integration requirements, and whether you need to monetize your APIs.

At a high level, these three products sit on a spectrum from simple to enterprise:

  • API Gateway: A fully managed, serverless gateway for lightweight API management. Best for teams that want a simple, low-ops way to add authentication, rate limiting, and monitoring to Cloud Functions, Cloud Run, or App Engine backends. Uses OpenAPI 2.0 specifications for configuration.
  • Cloud Endpoints: A distributed API management system based on the Extensible Service Proxy (ESP/ESPv2). Runs as a sidecar container alongside your backend, providing authentication, monitoring, logging, and quota management. Supports both REST (OpenAPI) and gRPC APIs. More flexible than API Gateway but requires deploying the proxy yourself.
  • Apigee: A full-lifecycle API management platform for enterprises. Includes a developer portal, API analytics, monetization, policy-based traffic management, and multi-cloud support. Designed for organizations with complex API programs that serve external developers.
FeatureAPI GatewayCloud EndpointsApigee
Managed infrastructureFully managed (serverless)Self-managed ESP sidecarFully managed
API specificationOpenAPI 2.0OpenAPI 2.0, gRPCOpenAPI, GraphQL, gRPC, SOAP
AuthenticationAPI keys, JWT, Firebase Auth, Google IDAPI keys, JWT, Firebase Auth, Google ID, customOAuth 2.0, API keys, JWT, SAML, LDAP
Rate limitingPer-API key quotasPer-API key quotasSpike arrest, quota, concurrent rate limit
Developer portalNoNo (can use third-party)Built-in customizable portal
AnalyticsCloud Monitoring metricsCloud Monitoring metricsAdvanced API analytics dashboard
MonetizationNoNoBuilt-in API monetization
Multi-cloudGCP onlyGCP (can proxy to external)GCP, AWS, Azure, hybrid, on-prem
PricingPer million API calls ($3/million)Free (pay for ESP compute)Subscription-based ($$$)

Which Should You Choose?

For most teams starting out, API Gateway is the right choice. It requires no infrastructure management, integrates directly with serverless backends, and provides essential API management features at low cost. Choose Cloud Endpoints if you need gRPC support or want more control over the proxy deployment. Choose Apigee only if you are building an API product with external consumers, need a developer portal, or require enterprise features like monetization and advanced analytics.

API Gateway Overview

API Gateway is GCP's serverless API management service. You define your API using an OpenAPI 2.0 specification that maps HTTP paths and methods to backend services. API Gateway handles request routing, authentication validation, rate limiting, and observability. The gateway runs on Google-managed infrastructure that scales automatically based on traffic, with no servers to provision or maintain.

The API Gateway architecture consists of three components:

  • API: The top-level resource that represents your API. It has a unique identifier and display name. An API can have multiple API configs (versions).
  • API Config: A specific version of your API definition, created from an OpenAPI spec. Configs are immutable; to change your API definition, you create a new config.
  • Gateway: A deployed instance of your API that routes traffic to your backends. Gateways are regional and can be deployed to multiple regions for global availability.
openapi-spec.yaml - API Gateway OpenAPI configuration
# openapi-spec.yaml
swagger: "2.0"
info:
  title: "Orders API"
  description: "API for managing customer orders"
  version: "1.0.0"
host: "orders-api-abc123.apigateway.my-project.cloud.goog"
schemes:
  - "https"
produces:
  - "application/json"
consumes:
  - "application/json"

# Security definitions
securityDefinitions:
  api_key:
    type: "apiKey"
    name: "x-api-key"
    in: "header"
  firebase_auth:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "https://securetoken.google.com/my-project"
    x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com"
    x-google-audiences: "my-project"

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

paths:
  /orders:
    get:
      summary: "List orders"
      operationId: "listOrders"
      security:
        - api_key: []
      x-google-quota:
        metricCosts:
          read-requests: 1
      x-google-backend:
        address: "https://orders-service-abc123.run.app/orders"
        deadline: 30.0
      parameters:
        - name: "page_size"
          in: "query"
          type: "integer"
          default: 20
        - name: "page_token"
          in: "query"
          type: "string"
      responses:
        "200":
          description: "Successful response"
        "401":
          description: "Unauthorized"
        "429":
          description: "Rate limit exceeded"
    post:
      summary: "Create an order"
      operationId: "createOrder"
      security:
        - firebase_auth: []
      x-google-quota:
        metricCosts:
          write-requests: 1
      x-google-backend:
        address: "https://orders-service-abc123.run.app/orders"
        deadline: 30.0
      responses:
        "201":
          description: "Order created"

  /orders/{orderId}:
    get:
      summary: "Get order by ID"
      operationId: "getOrder"
      security:
        - api_key: []
        - firebase_auth: []
      x-google-backend:
        address: "https://orders-service-abc123.run.app/orders/{orderId}"
        path_translation: APPEND_PATH_TO_ADDRESS
      parameters:
        - name: "orderId"
          in: "path"
          required: true
          type: "string"
      responses:
        "200":
          description: "Successful response"
        "404":
          description: "Order not found"
Deploy an API Gateway
# Enable required APIs
gcloud services enable apigateway.googleapis.com
gcloud services enable servicemanagement.googleapis.com
gcloud services enable servicecontrol.googleapis.com

# Create the API resource
gcloud api-gateway apis create orders-api \
  --display-name="Orders API"

# Create an API config from the OpenAPI spec
gcloud api-gateway api-configs create orders-v1 \
  --api=orders-api \
  --openapi-spec=openapi-spec.yaml \
  --backend-auth-service-account=api-gateway-sa@my-project.iam.gserviceaccount.com

# Create a gateway (deploys the API to a region)
gcloud api-gateway gateways create orders-gateway \
  --api=orders-api \
  --api-config=orders-v1 \
  --location=us-central1

# Get the gateway URL
gcloud api-gateway gateways describe orders-gateway \
  --location=us-central1 \
  --format='value(defaultHostname)'

# Create an API key for testing
gcloud services api-keys create \
  --display-name="Test API Key" \
  --api-target=service=orders-api-abc123.apigateway.my-project.cloud.goog

# Test the API
curl -H "x-api-key: YOUR_API_KEY" \
  https://orders-gateway-abc123.uc.gateway.dev/orders

# Update to a new config version
gcloud api-gateway api-configs create orders-v2 \
  --api=orders-api \
  --openapi-spec=openapi-spec-v2.yaml \
  --backend-auth-service-account=api-gateway-sa@my-project.iam.gserviceaccount.com

gcloud api-gateway gateways update orders-gateway \
  --api=orders-api \
  --api-config=orders-v2 \
  --location=us-central1

Cloud Endpoints Overview

Cloud Endpoints uses the Extensible Service Proxy v2 (ESPv2), an Envoy-based proxy that runs as a sidecar alongside your backend service. Unlike API Gateway, which is fully managed, Cloud Endpoints requires you to deploy and manage the ESPv2 container. This gives you more control over the proxy's configuration, placement, and behavior, and is the only GCP-native option that supports gRPC APIs.

ESPv2 intercepts all incoming requests, validates authentication tokens, checks API keys against Service Management, enforces quotas, and reports usage metrics to Service Control. It then forwards valid requests to your backend service running on the same host or network.

Cloud Endpoints can be deployed on:

  • Cloud Run: Deploy ESPv2 as a sidecar container using Cloud Run's multi-container support.
  • GKE: Deploy ESPv2 as a sidecar container in the same pod as your backend service.
  • Compute Engine: Run ESPv2 as a Docker container on the same VM as your backend.
  • App Engine Flexible: Deploy as part of your App Engine application.
Deploy Cloud Endpoints with Cloud Run
# Step 1: Deploy the backend service to Cloud Run
gcloud run deploy orders-backend \
  --image=us-central1-docker.pkg.dev/my-project/images/orders-api:latest \
  --region=us-central1 \
  --no-allow-unauthenticated \
  --platform=managed

# Step 2: Deploy the OpenAPI spec to Service Management
gcloud endpoints services deploy openapi-spec.yaml

# Step 3: Build the ESPv2 container with your service config
chmod +x gcloud_build_image
./gcloud_build_image -s orders-api.endpoints.my-project.cloud.goog \
  -c 2023-01-15r0 \
  -p my-project

# Step 4: Deploy ESPv2 as the public-facing Cloud Run service
gcloud run deploy orders-api-gateway \
  --image=gcr.io/my-project/endpoints-runtime-serverless:orders-api.endpoints.my-project.cloud.goog-2023-01-15r0 \
  --region=us-central1 \
  --allow-unauthenticated \
  --set-env-vars=ESPv2_ARGS=--cors_preset=cors_with_regex \
  --platform=managed

# Step 5: Verify the deployment
GATEWAY_URL=$(gcloud run services describe orders-api-gateway \
  --region=us-central1 --format='value(status.url)')
curl "$GATEWAY_URL/orders" -H "x-api-key: YOUR_API_KEY"

API Gateway vs Cloud Endpoints Comparison

Choosing between API Gateway and Cloud Endpoints requires understanding the specific trade-offs for your use case. While both provide core API management features (authentication, monitoring, quotas), they differ significantly in deployment model, protocol support, and operational responsibility.

AspectAPI GatewayCloud Endpoints
DeploymentFully managed; no container to deployYou deploy ESPv2 as a sidecar
Protocol supportHTTP/REST onlyHTTP/REST and gRPC
OpenAPI versionOpenAPI 2.0 (Swagger)OpenAPI 2.0
Backend authAutomatic (Google-signed JWT)Manual (configure IAM on backend)
Latency overhead~20-50ms (extra network hop)~1-5ms (sidecar, same host)
Custom domainVia domain mappingVia Cloud Run / Load Balancer
Response transformationNot supportedLimited (via Envoy filters)
WebSocket supportNoYes
Pricing$3 per million calls (first 2M free)Free (you pay for ESP compute resources)
Best forSimple REST APIs with serverless backendsgRPC APIs, low-latency requirements, custom proxy config

Start with API Gateway, Migrate if Needed

If you are building a REST API and do not need gRPC support, start with API Gateway. It is simpler to set up, has no proxy to manage, and the same OpenAPI specification can be used with Cloud Endpoints later if you need to migrate. The migration path is straightforward because both services use the same Service Management and Service Control APIs under the hood.

Apigee for Enterprise

Apigee is Google Cloud's enterprise API management platform, offering a superset of features compared to API Gateway and Cloud Endpoints. It is designed for organizations that treat APIs as products, with external developer consumers, SLA requirements, monetization needs, and complex governance policies. Apigee is available in three editions: Apigee X (cloud-managed on GCP), Apigee hybrid (control plane on GCP, runtime on your infrastructure), and the legacy Apigee Edge (SaaS or on-premises).

Apigee adds capabilities that the other options do not provide:

  • Developer portal: A customizable portal where external developers can discover your APIs, register for access, obtain API keys, and view documentation. Supports Drupal-based or integrated portals.
  • API analytics: Detailed analytics on API usage patterns, developer adoption, error rates, and latency trends. Goes far beyond Cloud Monitoring metrics with business-level insights.
  • Monetization: Built-in billing capabilities for charging API consumers based on usage, with support for freemium, tiered, and pay-per-call pricing models.
  • Policy engine: Over 50 pre-built policies for traffic management, security, mediation, and extension. Policies include OAuth 2.0 token generation, XML-to-JSON transformation, CORS handling, threat protection, and JavaScript-based custom logic.
  • Multi-cloud & hybrid: Apigee hybrid lets you run the API runtime on GKE, Anthos, or any Kubernetes cluster, including AWS EKS and Azure AKS, while the management plane stays on Google Cloud.
Apigee X provisioning and basic proxy setup
# Provision Apigee X organization (typically done once)
gcloud apigee organizations provision \
  --project=my-project \
  --authorized-network=default \
  --runtime-location=us-central1 \
  --analytics-region=us-central1

# Create an environment
gcloud apigee environments create prod \
  --organization=my-project \
  --display-name="Production"

# Create an environment group (for custom domains)
gcloud apigee envgroups create prod-group \
  --organization=my-project \
  --hostnames=api.example.com

# Attach environment to group
gcloud apigee envgroups attachments create \
  --organization=my-project \
  --envgroup=prod-group \
  --environment=prod

# Deploy an API proxy (from a bundle)
gcloud apigee apis deploy \
  --organization=my-project \
  --environment=prod \
  --api=orders-api \
  --revision=1

# List deployed API proxies
gcloud apigee apis list --organization=my-project

# Create a developer
gcloud apigee developers create \
  --organization=my-project \
  --email=dev@example.com \
  --first-name=Jane \
  --last-name=Developer \
  --user-name=jdeveloper

# Create an API product (bundle of APIs with quotas)
gcloud apigee products create orders-product \
  --organization=my-project \
  --display-name="Orders API - Free Tier" \
  --apis=orders-api \
  --environments=prod \
  --quota=1000 \
  --quota-interval=1 \
  --quota-unit=hour \
  --approval-type=auto

OpenAPI Specification & Configuration

Both API Gateway and Cloud Endpoints use OpenAPI 2.0 (Swagger) specifications as their primary configuration format. The OpenAPI spec defines your API's endpoints, request/response schemas, authentication requirements, and backend routing. GCP extends the standard OpenAPI spec with vendor-specific extensions (prefixed with x-google-) that configure GCP-specific features like backend routing, JWT validation, and quota enforcement.

Key GCP-specific OpenAPI extensions:

ExtensionPurposeExample
x-google-backendRoute requests to a backend serviceaddress: https://my-service.run.app
x-google-issuerJWT token issuer for authenticationhttps://accounts.google.com
x-google-jwks_uriURL for JWT public key verificationGoogle's JWKS endpoint
x-google-audiencesValid JWT audience valuesYour API's client IDs
x-google-managementQuota and rate limiting configurationMetrics and limits definitions
x-google-quotaPer-operation quota costAssign metric costs to operations

Best Practices for OpenAPI Specs

  • Version your specs: Store OpenAPI specifications in version control alongside your application code. Use semantic versioning for API configs.
  • Use operationId: Assign unique operationId values to every operation. These appear in monitoring metrics and logs, making it easier to trace requests.
  • Define response schemas: Include complete request and response schemas. These serve as documentation and can be used for validation.
  • Set deadlines: Use the deadline property in x-google-backend to set request timeouts. The default is 15 seconds, which may be too short for complex operations.

Authentication & Security

API Gateway and Cloud Endpoints support multiple authentication methods, which can be combined at the per-operation level. A single API can use API keys for simple client identification, JWT tokens for user-level authentication, and Google service account tokens for service-to-service calls.

Authentication configuration in OpenAPI spec
# Security definitions supporting multiple auth methods
securityDefinitions:
  # API Key authentication
  api_key:
    type: "apiKey"
    name: "x-api-key"
    in: "header"

  # Google ID Token (for GCP service-to-service)
  google_id_token:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "https://accounts.google.com"
    x-google-jwks_uri: "https://www.googleapis.com/oauth2/v3/certs"
    x-google-audiences: "orders-api.endpoints.my-project.cloud.goog"

  # Firebase Authentication
  firebase:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "https://securetoken.google.com/my-project"
    x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com"
    x-google-audiences: "my-project"

  # Auth0 (third-party OIDC provider)
  auth0:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "https://my-tenant.auth0.com/"
    x-google-jwks_uri: "https://my-tenant.auth0.com/.well-known/jwks.json"
    x-google-audiences: "https://api.example.com"

paths:
  /public/status:
    get:
      summary: "Public health check (no auth)"
      security: []  # Override global security
      x-google-backend:
        address: "https://my-service.run.app/status"
      responses:
        "200":
          description: "Service is healthy"

  /orders:
    get:
      summary: "List orders (API key required)"
      security:
        - api_key: []
      x-google-backend:
        address: "https://my-service.run.app/orders"
      responses:
        "200":
          description: "Order list"

  /orders/{id}:
    put:
      summary: "Update order (user auth required)"
      security:
        - firebase: []
        - auth0: []
      x-google-backend:
        address: "https://my-service.run.app/orders/{id}"
      responses:
        "200":
          description: "Order updated"

API Keys Are Not Authentication

API keys identify the calling application, not the user. They are useful for rate limiting and usage tracking, but they do not provide user-level authentication or authorization. Never use API keys alone for endpoints that access or modify user data. Combine API keys with JWT-based authentication (Firebase Auth, Auth0, or Google ID tokens) for endpoints that require user identity. Additionally, rotate API keys regularly and never embed them in client-side code.

Rate Limiting & Quotas

Rate limiting protects your backend services from abuse, prevents a single client from consuming all available capacity, and enforces usage tiers for API products. GCP's API management services support per-API-key quotas defined in the OpenAPI specification. When a consumer exceeds their quota, the gateway returns a 429 Too Many Requests response without forwarding the request to your backend.

Quota configuration uses three components: metrics (named counters), limits (maximum values for metrics over a time period), and metric costs (how much of a metric each API operation consumes). This model lets you create sophisticated rate limiting schemes where different operations consume different amounts of quota.

Advanced rate limiting configuration
# Advanced quota configuration with tiered limits
x-google-management:
  metrics:
    - name: "api-requests"
      displayName: "Total API Requests"
      valueType: INT64
      metricKind: DELTA
    - name: "write-operations"
      displayName: "Write Operations"
      valueType: INT64
      metricKind: DELTA
    - name: "heavy-operations"
      displayName: "Heavy Operations (reports, exports)"
      valueType: INT64
      metricKind: DELTA
  quota:
    limits:
      # General API request limit
      - name: "api-request-limit"
        metric: "api-requests"
        unit: "1/min/{project}"
        values:
          STANDARD: 600  # 10 requests/second default
      # Write operation limit (more restrictive)
      - name: "write-limit"
        metric: "write-operations"
        unit: "1/min/{project}"
        values:
          STANDARD: 60   # 1 write/second default
      # Heavy operation limit (very restrictive)
      - name: "heavy-operation-limit"
        metric: "heavy-operations"
        unit: "1/min/{project}"
        values:
          STANDARD: 5    # 5 per minute

paths:
  /orders:
    get:
      x-google-quota:
        metricCosts:
          api-requests: 1          # Costs 1 API request
    post:
      x-google-quota:
        metricCosts:
          api-requests: 1
          write-operations: 1      # Costs 1 API request + 1 write
  /reports/generate:
    post:
      x-google-quota:
        metricCosts:
          api-requests: 10         # Costs 10 API requests
          heavy-operations: 1      # Costs 1 heavy operation

Monitoring & Logging

Both API Gateway and Cloud Endpoints automatically send metrics to Cloud Monitoring and logs to Cloud Logging. These include request count, latency, error rates, and response codes. The built-in monitoring is sufficient for most operational needs, but you can enhance it with custom dashboards and alerting policies.

Key metrics to monitor for your APIs:

MetricDescriptionAlert Threshold
Request count (by status)Number of requests grouped by HTTP status code5xx rate > 1% of total requests
Request latency (p50, p95, p99)Response time distributionp99 > 5 seconds sustained for 5 minutes
Quota utilizationPercentage of quota consumed per API keyAny key at > 80% of quota
Authentication failuresRequests rejected due to auth errorsSpike > 10x normal rate (possible attack)
Backend errorsErrors returned by the backend serviceBackend error rate > 5%
API monitoring and alerting setup
# View API Gateway metrics
gcloud monitoring metrics list \
  --filter='metric.type = starts_with("apigateway.googleapis.com")'

# Create an alert for high error rate on API Gateway
gcloud beta monitoring policies create \
  --display-name="API Gateway High Error Rate" \
  --condition-display-name="5xx errors > 1% for 5 min" \
  --condition-filter='resource.type="apigateway.googleapis.com/Gateway"
    AND metric.type="apigateway.googleapis.com/request_count"
    AND metric.labels.response_code_class="5xx"' \
  --condition-threshold-value=10 \
  --condition-threshold-comparison=COMPARISON_GT \
  --condition-threshold-duration=300s \
  --notification-channels=projects/my-project/notificationChannels/CHANNEL_ID

# View API Gateway logs
gcloud logging read 'resource.type="apigateway.googleapis.com/Gateway"' \
  --limit=20 \
  --format='table(timestamp, httpRequest.status, httpRequest.latency, httpRequest.requestUrl)'

# View Cloud Endpoints logs
gcloud logging read 'resource.type="api" AND resource.labels.service="orders-api.endpoints.my-project.cloud.goog"' \
  --limit=20

Best Practices & Migration Paths

Building production-grade APIs on GCP requires careful consideration of versioning, security, performance, and operational practices. The following recommendations apply regardless of which API management product you choose.

API Versioning

  • URL-based versioning: Include the version in the URL path (e.g., /v1/orders, /v2/orders). This is the most visible and cache-friendly approach.
  • Run multiple versions simultaneously: Deploy each API version as a separate API Gateway config or Cloud Endpoints service. Route traffic based on the URL path prefix.
  • Sunset deprecated versions: Communicate deprecation timelines clearly in your developer portal and API responses. Use the Sunset HTTP header to signal upcoming removals.

Security Best Practices

  • Always use HTTPS: Both API Gateway and Cloud Endpoints enforce HTTPS by default. Never disable TLS.
  • Validate all inputs: API Gateway validates request parameters defined in the OpenAPI spec. Add application-level validation for request bodies and complex parameters.
  • Implement CORS properly: Configure Cross-Origin Resource Sharing headers to allow only trusted origins. Both API Gateway and ESPv2 support CORS configuration.
  • Use short-lived tokens: JWT tokens should have short expiration times (15-60 minutes). Use refresh tokens for long-lived sessions.

Migration Path

If you outgrow API Gateway, the migration to Cloud Endpoints or Apigee is straightforward because all three services use the Service Management API. Your OpenAPI spec works across API Gateway and Cloud Endpoints with minimal changes. Migrating to Apigee requires converting your OpenAPI spec into an Apigee proxy bundle, which can be automated using the Apigee CLI tools.

CORS Configuration for Single-Page Applications

If your API serves a single-page application (React, Angular, Vue), configure CORS on the gateway rather than in your backend code. For API Gateway, add CORS headers in the OpenAPI spec using an OPTIONS operation with x-google-backend pointing to a no-op endpoint. For Cloud Endpoints with ESPv2, set the --cors_preset flag to basic or cors_with_regex to handle preflight requests automatically.

Key Takeaways

  1. 1API Gateway is fully managed and serverless, ideal for Cloud Functions and Cloud Run backends.
  2. 2Cloud Endpoints uses Extensible Service Proxy (ESP) sidecar for gRPC and REST APIs on GKE/Cloud Run.
  3. 3Apigee is the enterprise API management platform with full lifecycle management and analytics.
  4. 4All three support OpenAPI specifications for API definition and documentation.
  5. 5API Gateway supports API keys, JWT validation, and Firebase authentication natively.
  6. 6Choose based on scale: API Gateway for simple APIs, Cloud Endpoints for gRPC, Apigee for enterprise.

Frequently Asked Questions

When should I use API Gateway vs Cloud Endpoints?
Use API Gateway for serverless APIs backed by Cloud Functions, Cloud Run, or App Engine because it is simpler and fully managed. Use Cloud Endpoints when you need gRPC support, are running on GKE, or need the ESP sidecar for fine-grained control.
What is Apigee and when do I need it?
Apigee is Google Cloud's enterprise API management platform. It provides full API lifecycle management (design, develop, test, deploy, monitor, retire), developer portal, monetization, advanced analytics, and API products. Use Apigee for large-scale API programs and API-as-a-product strategies.
How does API Gateway pricing work?
API Gateway charges per million API calls: $3.00/million for the first 2 million calls/month, with volume discounts after. There are no upfront costs or minimum fees. Cloud Endpoints is free for OpenAPI APIs; gRPC proxy costs $3/million calls.
Can I use custom domains with API Gateway?
Yes. API Gateway supports custom domains with automatically managed TLS certificates. Map your domain in the API Gateway console and update your DNS CNAME record to point to the gateway hostname.
Does GCP API Gateway support rate limiting?
API Gateway supports basic rate limiting via API keys and quota configuration in the OpenAPI spec. For advanced rate limiting (sliding window, per-user, spike arrest), Apigee provides more sophisticated traffic management policies.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.