API Gateway Patterns Across AWS, Azure, GCP, and OCI

The Role of API Gateways in Cloud Architecture

An API gateway sits between your clients and your backend services, handling cross-cutting concerns like authentication, rate limiting, request transformation, caching, and observability. Without an API gateway, each backend service must implement these concerns independently, leading to duplicated logic, inconsistent behavior, and security gaps. Every major cloud provider offers a managed API gateway service, but they differ significantly in features, pricing models, and operational characteristics. Choosing the right gateway and configuration pattern can mean the difference between a $50/month API infrastructure cost and a $5,000/month cost for the same traffic volume.

This article covers the API gateway services on AWS, Azure, GCP, and OCI, compares their capabilities across critical dimensions, and provides implementation patterns that work well at scale. Whether you are building a public-facing REST API, a GraphQL endpoint, an internal microservices mesh, or a real-time WebSocket service, the patterns here will help you choose and configure the right API gateway for your workload.

AWS API Gateway: REST, HTTP, and WebSocket

AWS offers three distinct API Gateway types, and choosing the wrong one is one of the most common cost mistakes. REST API (API Gateway v1) is the original offering with the most features: request/response transformation, request validation, API keys, usage plans, WAF integration, caching, and client SDK generation. It costs $3.50 per million requests. HTTP API (API Gateway v2) is a newer, simpler offering designed for proxying requests to Lambda and HTTP backends with lower latency and lower cost at $1.00 per million requests. WebSocket API supports bidirectional real-time communication at $1.00 per million messages plus $0.25 per million connection minutes.

For most new APIs, HTTP API is the right choice. It supports Lambda integration, HTTP proxy, VPC Link, JWT authorization, and CORS configuration — which covers the needs of 80 percent of API workloads. The 3.5x cost difference compared to REST API is significant at scale. An API serving 100 million requests per month costs $100/month on HTTP API versus $350/month on REST API. Only use REST API when you specifically need features that HTTP API does not support: request/response transformation templates, API key-based throttling per consumer, request validation, or WAF integration.

For high-throughput internal APIs, consider using an Application Load Balancer (ALB) instead of API Gateway. ALBs charge $0.008 per LCU-hour rather than per-request, which becomes cheaper above approximately 30-40 million requests per month. ALBs support path-based routing, host-based routing, authentication with Cognito or OIDC, and health-check-based target routing. They lack API Gateway features like request transformation, built-in throttling, and API key management, but for simple proxying to ECS/EKS services, an ALB is often more cost-effective.

Azure API Management

Azure API Management (APIM) is the most feature-rich API gateway among the four providers. It includes a developer portal for API documentation, a publisher portal for API lifecycle management, built-in OAuth 2.0 and OpenID Connect support, policy-based request/response transformation, rate limiting, caching, analytics, and monetization features. APIM is positioned as a complete API management platform, not just a gateway.

APIM pricing is tier-based. The Consumption tier charges $3.50 per million API calls with no fixed monthly cost, making it suitable for low-traffic APIs. The Developer tier ($50/month) includes the developer portal but is not for production use. The Basic tier ($155/month) supports up to 1,000 requests per second. The Standard tier ($700/month) increases capacity and adds active-active deployment. The Premium tier ($2,800/month per unit) adds multi-region deployment, virtual network integration, and higher capacity. The v2 tiers (Basic v2 at $175/month, Standard v2 at $350/month) offer improved performance and simplified scaling.

The policy engine is APIM's distinguishing feature. Policies are XML-based rules applied at different scopes (global, product, API, operation) that can transform requests, validate JWT tokens, enforce rate limits, cache responses, perform URL rewriting, call external services, and much more. The policy engine is powerful but has a learning curve — complex policies can become difficult to debug and maintain. Use policies for cross-cutting concerns and keep business logic in your backend services.

For simpler API proxying needs, Azure Functions with HTTP triggers or Azure Container Apps with built-in ingress may be more cost-effective than APIM. Azure Front Door can also serve as a lightweight API gateway with WAF, rate limiting, and global load balancing for $35/month base plus per-request charges.

GCP API Gateway and Apigee

GCP offers two API management services. API Gateway is a lightweight, fully managed gateway for Cloud Functions, Cloud Run, and App Engine backends. It uses OpenAPI specifications to define API configurations, supports API keys, JWT validation, and per-API rate limiting. API Gateway charges $3.00 per million requests for the first billion requests per month, with volume discounts beyond that. It is simpler and cheaper than AWS REST API or Azure APIM for basic API management needs.

Apigee is Google's enterprise API management platform, acquired in 2016. Apigee provides comprehensive API lifecycle management including a developer portal, API analytics, monetization, rate limiting, threat protection, and policy-based mediation. Apigee is priced at the enterprise level with plans starting at $500/month for the evaluation tier, $3,500/month for the Standard tier, and custom pricing for Enterprise. It is overkill for most applications but is the right choice for organizations that need to expose APIs as products to external developers or partners.

For most GCP workloads, the simplest and most cost-effective API gateway is Cloud Run with built-in authentication and Cloud Endpoints. Cloud Run provides HTTP request routing, TLS termination, authentication via Identity-Aware Proxy or Firebase Auth, and autoscaling. Cloud Endpoints adds API key validation, JWT verification, and API usage monitoring. The combination handles the needs of most web APIs without the cost of a dedicated API gateway service.

GCP's global external Application Load Balancer is another option for API routing. It supports URL-based routing to backend services across regions, Cloud CDN integration, Cloud Armor WAF, and Identity-Aware Proxy for authentication. For APIs that need global distribution with low latency, the global load balancer plus Cloud Run backends is an excellent architecture.

OCI API Gateway

OCI API Gateway provides managed API routing, authentication, rate limiting, and request/response transformation. It supports OpenAPI-based API definitions, JWT validation, mutual TLS, and integration with OCI Functions, OCI Container Instances, and any HTTP backend. OCI API Gateway charges $3.00 per million API calls with no fixed monthly cost, making its pricing competitive with the consumption-based tiers of other providers.

OCI API Gateway supports request and response transformation using JSONPath expressions, header manipulation, and query parameter modification. Rate limiting is configurable per route with sliding window algorithms. Authentication supports JWT validation with multiple issuers, custom authorizer functions, and mutual TLS. The service integrates with OCI WAF for web application firewall protection.

A notable advantage of OCI API Gateway is its integration with OCI's identity and access management. You can use OCI IAM policies to control who can deploy and manage APIs, and dynamic groups to authenticate API backends to other OCI services. The 10 TB per month of free outbound data transfer on OCI also makes it attractive for APIs with high response volumes.

Authentication Patterns

API authentication at the gateway level offloads security logic from your backend services and provides a consistent authentication boundary. The most common patterns are API keys, JWT tokens (OAuth 2.0), and mutual TLS.

API keys are the simplest authentication mechanism. The client includes a key in a header or query parameter, and the gateway validates it. API keys are suitable for identifying callers and applying rate limits but are not a strong security mechanism — they are long-lived shared secrets that are difficult to rotate and easy to leak. Use API keys for low-risk, internal, or free-tier API access, not as the sole authentication mechanism for sensitive data.

JWT-based authentication is the standard for production APIs. The client obtains a JWT token from an identity provider (Cognito, Azure AD, Auth0, Okta, Firebase Auth) and includes it in the Authorization header. The API gateway validates the token signature, checks expiration and issuer claims, and optionally extracts claims (user ID, roles, scopes) to pass to the backend. All four cloud API gateways support JWT validation with configurable issuers and audiences. This pattern provides strong security without requiring the backend to implement authentication logic.

Mutual TLS (mTLS) requires both the client and server to present certificates, providing the strongest authentication. It is used for machine-to-machine communication between trusted services, financial and healthcare APIs with strict compliance requirements, and partner integrations where both parties need to verify identity. AWS API Gateway, Azure APIM, GCP API Gateway, and OCI API Gateway all support mTLS with configurable trust stores.

Rate Limiting Strategies

Rate limiting protects your backend services from abuse, ensures fair usage across consumers, and prevents a single misbehaving client from degrading service for everyone. Effective rate limiting requires configuring limits at the right granularity: per API key, per user, per IP address, per endpoint, or per tenant.

A recommended pattern is tiered rate limiting. Apply a global rate limit across all consumers (e.g., 10,000 requests per second for the entire API), a per-consumer rate limit based on their plan or tier (e.g., free tier gets 100 requests per minute, paid tier gets 1,000 requests per minute), and per-endpoint rate limits for expensive operations (e.g., search endpoints limited to 10 requests per second per consumer because they are computationally expensive).

AWS REST API supports usage plans with API keys for per-consumer throttling. HTTP API does not natively support per-consumer rate limiting — you need to implement it in your Lambda authorizer or backend. Azure APIM has the most flexible rate limiting with policies that support sliding windows, fixed windows, and leaky bucket algorithms at any scope. GCP API Gateway supports per-API rate limits. OCI API Gateway supports per-route rate limiting with configurable windows.

Cost Optimization Patterns

API gateway costs can become significant at high volumes. A service handling 500 million requests per month on AWS REST API costs $1,750/month in API Gateway charges alone. Several patterns can reduce these costs dramatically.

First, use the cheapest gateway that meets your needs. If you do not need request transformation or WAF, use HTTP API ($1/million) instead of REST API ($3.50/million). If you only need routing and TLS termination, use an ALB ($0.008/LCU-hour). If you are on GCP, Cloud Run with built-in routing may eliminate the need for a separate API gateway entirely.

Second, implement caching at the gateway level. AWS REST API supports response caching from 0.5 GB to 237 GB ($0.020-$3.800/hour depending on size). Azure APIM supports built-in response caching. Caching eliminates backend calls for repeated requests, reducing both backend costs and response latency. A cache that hits 50 percent of requests effectively halves your backend costs.

Third, offload static responses and health checks. If your API serves a health check endpoint that returns a static response, handle it at the gateway or load balancer level rather than routing it to a Lambda function or container. On AWS, REST API can return mock responses without invoking a backend. On GCP, Cloud Endpoints can return static responses for defined routes.