apointoo.
Request access
HIPAA

AWS API Gateway REST vs HTTP for a Protected API

cmsapointoo··9 min read

Short answer: Choose API Gateway REST or HTTP only after mapping the required feature, WAF placement, request path, identity, logging, and cost assumptions. As of 2026-08-15, Amazon Web Services documents differences between the two API types, publishes API Gateway pricing, and publishes separate AWS WAF pricing. None of those pages proves that a protected API is configured correctly.

AWS service fit and regional boundary

There is no universally safer API Gateway type. The right choice is the smallest API product that supports the required route, authorization, integration, observability, throttling, and protection controls. AWS’s API Gateway HTTP API and REST API Comparison is the authority for documented feature differences as of the retrieval date. A security review should turn those differences into pass or fail requirements instead of treating REST as automatically stronger or HTTP as automatically simpler.

Start with the boundary around the endpoint. Record the public hostname, API type, region, stages, custom domain, authentication mechanism, WAF association, backend integration, request size, timeout, retry behavior, and log destination. Then identify where protected health information could appear. A request body, query string, response, error, access log, WAF sample, or trace can become a data path even when the database is private.

The eligible-service question is not the same as the deployment question. If a service appears in an AWS eligibility reference, that supports a bounded provider claim. It does not establish that every API route is authorized, that WAF rules block all unwanted traffic, or that downstream services use a safe region. Keep the provider page, account configuration, application policy, and customer risk record distinct.

Decision axis REST or HTTP question Proof
Feature Which documented capability is required? Requirement matrix and working route
Edge Where is WAF attached and which traffic reaches the backend? Association record and blocked-request test
Identity How are caller and tenant membership checked? Allowed and denied request tests
Cost Which requests, rules, logs, and regions are included? Dated estimate with assumptions

For a runtime view, read AWS Lambda runtime boundaries. For a wider service and contract review, use the AWS HIPAA eligible services checklist.

Request, data, key, and identity path

Protect the route by proving each hop, not by naming the gateway. A useful trace is client request, edge policy, gateway authorization, tenant resolution, backend function, data store, response, and operational record. At each hop list the fields that can be present. Keep advertising examples generic: an approved event name, event time, currency, and conversion value are different from a person’s contact data or treatment detail.

Authentication proves an identity, not necessarily a tenant. The backend should resolve membership server-side and reject a caller who changes a tenant parameter, uses an unapproved route, or supplies an expired credential. A WAF can block patterns and volumes, but it does not replace membership checks, database authorization, or output minimization.

WAF placement deserves an explicit diagram. Identify whether the custom domain reaches API Gateway directly, whether another load balancer or CDN is in front, and whether any alternate hostname bypasses the intended WAF. Test the origin and direct service endpoint separately. A passing public route test leaves a gap if an alternate origin still accepts requests.

client
  -> custom domain
  -> WAF policy
  -> API Gateway authorization
  -> tenant membership check
  -> backend integration
  -> approved data store

Keys and secrets sit outside the gateway comparison. Document which identity can decrypt, which service can administer, how rotation is handled, and whether logs reveal secret references or request content. The API type can reduce or increase operator work, but it cannot decide those controls for the customer.

Queue, audit, backup, and failure handling

A protected API must fail closed at every alternate path. Check missing authentication, invalid audience, wrong tenant, malformed payload, oversized payload, WAF block, backend timeout, retry, and dead-letter behavior. A gateway error should not echo sensitive input. A backend exception should not copy the request into a verbose log or tracing span.

Audit events should preserve decision evidence without preserving the entire request. Record route, principal, tenant context, decision, timestamp, correlation reference, and reason code where permitted. Do not assume a gateway access log is a complete audit trail. It may omit the application decision, the database operation, or the administrator who changed the policy.

Backups and exports are outside the REST versus HTTP choice but inside the risk boundary. Test an export initiated through an allowed route, an export attempted by another tenant, and a support recovery. Verify that queue payloads, cached responses, error samples, and restored records use the same access policy. A gateway that blocks an external request cannot protect a privileged batch job that bypasses it.

Cost and proof gate

Use AWS pricing pages as date-labeled inputs, not as a conclusion. API Gateway pricing can depend on API type, request volume, region, and related services. AWS WAF pricing can depend on web ACLs, rules, and requests. Add logs, data transfer, backend calls, key operations, and retention. The estimate should identify what is included and what remains unknown.

Do not describe a lower request price as a security saving. A missing feature may require a second proxy, custom authorization, or a separate logging path. Conversely, a feature that exists in REST may be unnecessary if the route needs only the HTTP capabilities already documented. Make the tradeoff visible in a matrix.

  • List requirements before selecting the API type.
  • Associate WAF with every public and alternate origin.
  • Run tenant, authentication, payload, and bypass tests.
  • Review logs, traces, cache, retries, and dead letters for data leakage.
  • Recalculate request and rule estimates at the current region and retrieval date.

Protected API proof checklist

Approve the route only when a reviewer can reproduce the negative cases. Use synthetic records and record the exact API type, region, WAF policy, identity, backend, and date.

  1. Send an allowed request and verify the expected tenant context.
  2. Change tenant input and confirm denial before backend data access.
  3. Remove or expire authentication and confirm denial.
  4. Send malformed and oversized input and inspect the response and logs.
  5. Attempt the backend origin or alternate hostname and confirm it cannot bypass the edge policy.
  6. Trigger a timeout and retry, then inspect every queue and dead-letter record.
  7. Review policy changes, restore, export, and support paths with separate credentials.

When the feature matrix and proof disagree, stop. Keep the choice provisional until the documented behavior, customer contract, and application test agree. A bounded non-production proof is the useful next step, not a blanket claim about API Gateway.

One practical way to settle the REST versus HTTP question is to create a route matrix. For each route, list required authentication, tenant lookup, request validation, throttling, WAF rule, integration, timeout, response policy, log fields, and recovery behavior. Mark a feature as required only when a real route needs it. This avoids paying for a capability that is not used and avoids selecting a simpler API that cannot satisfy a named requirement.

Run the matrix against both a normal request and an adversarial request. Change the tenant value, remove authentication, use a direct origin, exceed the payload limit, force a backend error, and replay a request. Inspect edge and backend evidence together. If the two API types produce different logs, retries, or failure responses, record that difference as part of the decision.

Document a rollback that does not leave an alternate public route active. DNS, certificates, WAF rules, gateway stages, backend configuration, and application authorization should change in an order that leaves a tested path available. Keep the decision provisional until the route matrix, cost estimate, and negative tests agree. The related DynamoDB tenant-partitioning review shows the same principle at the data layer: a named boundary still needs alternate-path tests.

Keep a route-level change record. Record API type, stage, region, domain, WAF association, authentication, tenant lookup, backend, timeout, retry, log fields, and rollback owner. When a feature or price changes, re-run the route matrix instead of carrying forward an old comparison. A dated decision is easier to revise than a broad statement about REST or HTTP.

Use synthetic data for edge tests. Verify that a WAF block, authorization failure, backend timeout, and direct-origin call produce safe responses and redacted logs. Check that a failed request cannot be replayed through another hostname or stage. These tests define what the selected API path actually protects.

Include operational ownership in the choice. A feature that reduces custom code may increase policy or cost complexity. A feature that is absent may require a small application control. Compare the total proof burden and keep unresolved provider behavior or contract questions open for review.

Frequently asked questions

Should a protected API always use REST API?

No. Compare required features, WAF placement, authorization, logging, and backend behavior. REST may be justified by a documented requirement, while HTTP may be sufficient for another route. The decision must be tied to evidence and tests.

Does AWS WAF replace authentication and tenant checks?

No. WAF filters traffic according to its rules. It does not establish application membership, database authorization, output minimization, or privileged-job controls.

What should be included in an API Gateway cost estimate?

Include request volume, region, API type, WAF ACL and rule assumptions, logs, data transfer, backend calls, keys, and retention. Mark prices and free allocations as estimates checked on a stated date.

What approval is needed before production?

The customer and counsel should approve the data and contract boundary. Engineering should prove allowed and denied calls, alternate-origin blocking, redacted failures, retries, exports, restores, and support access.

References

Related articles