API Gateway Architectures

Why the front door is a Professional decision

SAP-C02 Task 2.4 asks you to implement loosely coupled dependencies so a spike or an outage in one service does not freeze the rest of the platform. Task 2.5 asks you to design large-scale access patterns. Amazon API Gateway sits at that intersection: it is the managed front door for REST APIs, HTTP APIs, and WebSocket APIs. Independent SAP-C02 study material by OpenExamPrep treats the service as an architecture choice, not a console click-path.

HarborCart is a multi-Region marketplace. Shoppers place orders from mobile apps. Warehouse tablets need live pick-list updates. Marketplace partners call an orders API with per-tenant quotas. Internal finance services must reach the same order commands without a public internet path. Those four audiences do not share one endpoint type. Choosing HTTP APIs for everything because they are cheaper is a common Associate-level shortcut that fails Professional stems about private endpoints, usage plans, or bidirectional push.

REST APIs versus HTTP APIs

REST APIs (the original API Gateway product) and HTTP APIs are both RESTful, stateless, HTTP-based interfaces. AWS's comparison is explicit: REST APIs include more features; HTTP APIs omit many of those features so they can be offered at a lower price. AWS's feature page states HTTP APIs can offer up to 71% cost savings and up to 60% latency reduction compared with REST APIs. That published comparison is not permission to ignore missing capabilities.

Choose REST APIs when the stem needs API keys, per-client throttling or quotas (usage plans), request validation, AWS WAF association, response caching, edge-optimized endpoints, resource policies, access logs to Amazon Data Firehose, execution logs, AWS X-Ray tracing, mock integrations, Velocity Template Language (VTL) mapping templates, or private API endpoints. Choose HTTP APIs when you need a Lambda or HTTP proxy with IAM, Lambda authorizers, or native JSON Web Token (JWT) authorization, plus CORS and custom domains, and you do not need those REST-only management features. HTTP APIs support parameter mapping, not VTL body transforms.

WebSocket APIs

A WebSocket API is a collection of routes integrated with AWS Lambda, HTTP endpoints, or other AWS services. Clients open a persistent connection. The service can push to the client using the connection ID without a new HTTP request. AWS documents typical uses: chat, collaboration, multiplayer games, and financial trading dashboards.

Routes include $connect, $disconnect, $default, and custom route keys selected from the message. Authorization happens on $connect with IAM or Lambda REQUEST authorizers. After connect, HarborCart's warehouse dashboard stores the connection ID in Amazon DynamoDB. When a pick-list changes, a worker posts to that connection through the management API. If the exam wants server-initiated push to browsers, REST polling is the distractor.

Published WebSocket quotas include a 10-minute idle timeout and a 2-hour maximum connection duration. Design heartbeats or reconnect logic; do not assume a day-long socket. Usage plans and API keys can gate WebSocket stages the same way they gate REST stages; they still are not a substitute for an authorizer on $connect.

Private APIs versus VPC links versus an Application Load Balancer

This distinction is the highest-value trap in the section.

A private REST API is an API whose endpoint is reachable only from inside an Amazon Virtual Private Cloud (Amazon VPC), or from on-premises through AWS Direct Connect or a Site-to-Site VPN into that VPC. Clients call it through an interface VPC endpoint for API Gateway (execute-api), powered by AWS PrivateLink. You attach a resource policy that allows that endpoint (and optional VPC or VPC endpoint IDs) and denies the public internet. Private APIs use TLS 1.2. You can associate the VPC endpoint with the API to simplify DNS. Turning on private DNS for the endpoint lets clients use the standard execute-api hostname without extra headers, but AWS warns that this can interfere with invoking public default API Gateway endpoints from the same VPC; the documented workaround is private hosted zones per API.

HTTP APIs do not offer a private endpoint type in AWS's REST-versus-HTTP comparison table. If the stem requires a VPC-only API Gateway endpoint, the answer is a private REST API, not an HTTP API.

A VPC link (private integration) is the opposite direction: API Gateway—often public—reaches a backend that lives in a VPC: an Application Load Balancer (ALB), a Network Load Balancer (NLB), or, for HTTP APIs, IP-based services registered in AWS Cloud Map (for example Amazon ECS tasks). VPC Link V1 for REST APIs is the legacy NLB path. VPC Link V2 encapsulates connections to ALB or NLB and can be reused across APIs. HarborCart's public POST /orders HTTP API can therefore integrate privately with an internal ALB in front of ECS, while shoppers still hit a public custom domain.

An Application Load Balancer is often a better front door than API Gateway when:

• The backend is already Amazon EC2, Amazon Elastic Container Service (Amazon ECS), or Amazon Elastic Kubernetes Service (Amazon EKS) in a VPC.
• You need host-, path-, header-, or query-based routing to target groups, health checks, sticky sessions, or gRPC.
• You need HTTP WebSockets at Layer 7 without API Gateway connection IDs and route keys.
• You authenticate at the load balancer with Amazon Cognito or an OpenID Connect identity provider (authenticate-cognito / authenticate-oidc actions).
• Request volume is high and you do not need API keys, usage plans, VTL transforms, or per-method API-product packaging. ALB pricing is capacity-unit based; API Gateway is request-based. Stems that say "millions of internal microservice calls between ECS services" usually want ALB (or a service mesh), not API Gateway on every hop.

Use API Gateway when the API is a product: partner keys, throttling plans, Lambda proxy, request validation, or a private execute-api endpoint.

Authorizers

AWS Identity and Access Management (IAM) authorization uses Signature Version 4. Callers need execute-api:Invoke. This is the natural choice for service-to-service calls from AWS principals, including HarborCart's finance account assuming a role in the orders account.

Amazon Cognito user pools attach as a REST API authorizer so mobile shoppers present Cognito tokens. On HTTP APIs, Cognito is consumed through a JWT authorizer that validates issuer and audience. REST APIs do not have a native JWT authorizer; validate JWTs from a non-Cognito issuer with a Lambda authorizer.

Lambda authorizers run your code. REST APIs support TOKEN authorizers (a header such as Authorization) and REQUEST authorizers (headers, query string, stage variables, and context). HTTP APIs support Lambda authorizers (payload format 2.0). WebSocket APIs use REQUEST authorizers on $connect. Return an IAM policy document and optional context that API Gateway caches according to the authorizer time to live (TTL). A zero TTL is a latency and cost tax; a long TTL can authorize a revoked user until cache expiry—Professional stems often force that tradeoff.

Mutual TLS (mTLS) is available on REST and HTTP custom domains for partner certificates. Do not confuse mTLS (client certificates) with IAM SigV4.

Usage plans, API keys, and throttling

A usage plan binds API keys to REST or WebSocket stages and optional method-level key requirement. You set a throttle (steady-state rate and burst) and a quota (requests per day, week, or month) per key. Throttling and quotas aggregate across stages in the plan. AWS states they are not hard limits and are applied on a best-effort basis; clients can occasionally exceed them. Do not treat usage plans as a billing hard-stop. AWS tells you to use AWS Budgets to watch cost and AWS WAF to block abuse.

An API key is not an authenticator. Anyone who copies the key can call. Combine keys with IAM, Cognito, or Lambda authorizers. Key values must be unique; two names with the same value are the same key. A key can join more than one plan, but only one plan per API stage.

Throttling also exists without keys:

• Account-level Regional limits (Service Quotas; increase by request).
• Stage-level default method limits.
• Method-level overrides for expensive paths such as POST /checkout.

HarborCart's public partner REST API uses a Lambda authorizer plus usage plans so a noisy partner is throttled without taking down shoppers. The shopper HTTP API has no keys; it uses JWT and account/stage throttling.

HarborCart reference design

Shopper mobile: HTTP API, JWT authorizer against Cognito, Lambda proxy, regional custom domain.

Partner marketplace: REST API, Lambda authorizer plus usage plans, AWS WAF, request validation.

Internal finance: private REST API, execute-api VPC endpoint in the shared-services VPC, resource policy allowing that endpoint, Direct Connect from the corporate network.

Warehouse live board: WebSocket API, Lambda REQUEST authorizer on $connect, DynamoDB connection table.

Public website to ECS catalog: ALB with path routing, not API Gateway.

Traps

1. An HTTP API when the stem requires a private endpoint.
2. Treating a VPC link as a private API.
3. Using API keys as the only security control.
4. Trusting usage-plan quotas as hard cost control.
5. Putting API Gateway in front of every internal ECS hop when ALB is the better front door.
6. REST polling for a push dashboard.
7. A native JWT authorizer on REST (it does not exist).