- Coverage by target cloud
- How the targets compare
- On Google Cloud, Azure, and OCI
- On Google Cloud
- On Azure
- Service level agreements
- Debug this service
Coverage by target cloud
How the targets compare
Each row compares a capability of API Gateway v2 (HTTP/WebSocket) with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
On Google Cloud, Azure, and OCI
Via Envoy
HTTP APIs and WebSocket APIs
The Tensor9 service adapter maps API Gateway v2 APIs to Envoy and adapter-owned API state in the target cluster. HTTP APIs route individual requests by method and path. WebSocket APIs establish a connection and then select integrations for connection events and messages. The protocol selected when creating the API determines which authorizers, events and integration settings apply. Management calls record routes, integrations, authorizers, deployments and stages. Envoy handles HTTP transport; a connection worker owns each accepted WebSocket. Backend integrations use their service adapters, including the Lambda adapter for function execution. Protocol Request path State held while serving HTTP Request → route and authorization → integration → response Stage configuration and one request WebSocket Connection authorization → socket owner → selected message integration Connection identifier and live socketHTTP events and authorizers
HTTP Lambda proxy integrations select payload format1.0 or 2.0. The choice changes the function event and response contract, including cookies and repeated headers. Configure it explicitly and use a handler written for that format; a REST proxy handler is not automatically a format-2.0 handler.
For an HTTP JWT authorizer, the adapter checks the configured issuer, audience, signing key, token times and route scopes. Lambda authorizers have separate format-1.0 and format-2.0 events. A simple Boolean response and an IAM-policy response are different configurations, with different cache and route-policy consequences.
AWS_IAM uses target-environment credentials and an execute-api:Invoke decision. Public routes use NONE. Backend authorization is evaluated independently: allowing the caller does not grant the integration permission to invoke a function. The AWS_PROXY label alone does not identify a Lambda integration; other AWS-service subtypes are outside this profile’s contract.
WebSocket connection ownership
WebSocket admission runs on$connect, using NONE, AWS_IAM or a REQUEST Lambda authorizer. HTTP JWT authorization does not apply to this handshake. Once accepted, the connection receives an identifier and remains attached to the worker holding its socket. Message routes and $default select integrations using the configured route-selection expression.
The connection identifier is not a portable session. If its worker stops, clients reconnect, pass admission again and receive a new identifier. Applications must handle a missed $disconnect notification and must not use that event as their only cleanup mechanism.
PostToConnection, GetConnection and DeleteConnection use a management endpoint scoped to the API and stage. The application making these calls authenticates separately from the connected client and needs the relevant execute-api:ManageConnections permission. A connection identifier by itself grants no permission. Sending to an absent connection returns a gone response; acceptance of a send is not an acknowledgement from the remote application.
Deployment changes and connectivity
HTTP stages can select explicit deployments or use auto-deploy. This profile requires explicit deployments for WebSocket configuration. The adapter keeps the API configuration in durable storage, but a durable configuration record cannot recreate an open socket after worker loss. For a change that must affect every WebSocket client, disconnect and reconnect those clients after deploying the stage. This profile does not promise immediate application of changed route policies, integration settings or credential revocation to existing connections. Public client access and private backend access are configured separately. An HTTP VPC link reaches a private HTTP integration; it does not create a private HTTP or WebSocket frontend. Lambda integrations use the Lambda adapter and need no VPC link. Private HTTP and WebSocket integrations and AWS endpoint-identity policy conditions are outside this profile’s connectivity contract.Limitations
△ Differences to review before moving an HTTP or WebSocket API- HTTP and WebSocket authorizers differ. JWT authorization belongs to HTTP APIs. WebSocket REQUEST authorization runs at connection establishment; applications needing per-message user authorization must enforce it in their message handlers.
- Open connections do not survive owner loss. Reconnect with application-level recovery for subscriptions, delivery positions and unfinished work. This mapping does not provide transparent socket migration or exactly-once message delivery.
- Policy changes require a connection policy. Use explicit disconnection where an existing session must lose access. Do not assume a stage deployment immediately reauthorizes every connected client.
- Additional API Gateway products are excluded. Portal and product publishing, non-Lambda AWS-service integration subtypes, private WebSocket integrations and private frontend equivalence are not part of this profile.
Other considerations
- Migration. Recreate APIs and backend permissions, configure target credentials and certificates, then switch HTTP endpoints or reconnect WebSocket clients. Connection identifiers from AWS cannot address sockets in the target environment.
- Operation. Tensor9 maintains the service adapter and connection-management behavior. The target platform supplies gateway compute, durable configuration storage, networking and TLS termination. Restrict internal worker and authorization endpoints to the serving components.
- Application recovery. Store durable subscription or workflow state in the application, outside the live socket. Give retried messages application identifiers and acknowledge them at the application level when delivery matters.
- Capacity. Track concurrent connections, message sizes, slow-client queues and integration concurrency separately. An HTTP request rate is not a capacity estimate for long-lived WebSocket connections.
On Google Cloud
Via Google Cloud API Gateway
How an API lands on Google Cloud API Gateway
Your tooling calls the API Gateway v2 management API unchanged. The adapter records the API, its routes, integrations, authorizers, deployments and stages, and when a stage is deployed it renders that stage as an OpenAPI document, creates a Google Cloud API Gateway API config from it and points a gateway at the config. Requests from your clients go to the gateway’s hostname and are handled by Google; the adapter is not on the request path. The decision to use this target is made once per API. Every route, authorizer and integration is checked against the rule below as it is created, and an API that fits is served here in full. An API that does not fit is served on Envoy in full. Routes are never split between the two backends, because a custom domain has one DNS target and every API mapped under it must resolve the same way.The eligibility rule
Google Cloud API Gateway serves an API when:- every route’s authorization is a JWT authorizer with no required scopes, or NONE; and - every integration is an HTTP_PROXY to a URL, or a Lambda proxy (AWS_PROXY) reached through the adapter’s ingress.
Authorizers and integrations
For a JWT authorizer the gateway checks issuer, audience, signing keys and token times against the configured identity provider, and passes the verified claims to the backend. A public route (NONE) is served without a check. An HTTP_PROXY integration forwards the request to the integration URL and returns the backend’s response. A Lambda proxy integration forwards to the adapter’s ingress, which builds the payload format 1.0 or 2.0 event, invokes the function under the integration’s own authority and returns the function’s status, headers and body; the gateway holds no AWS credential and cannot invoke a function itself.Deployments and stages
A deployment records a fixed revision of the API; a stage selects one. Each stage change becomes a new API config and a gateway update, and Google Cloud propagates a config change over minutes rather than seconds, so a stage update is a rollout rather than an instant switch. Deploy the stage, wait for the gateway to report the new config, and exercise the route before moving traffic.Limitations
- The rule is the boundary. AWS_IAM routes, Lambda authorizers, JWT scopes and WebSocket APIs are not expressible on Google Cloud API Gateway; an API that uses any of them is served on Envoy in full. - Config changes propagate over minutes. A stage update is an API config rollout on Google’s side; plan cutovers around that, and do not treat CreateStage’s response as serving readiness. - Integrations are reached over public URLs. The gateway does not join your network; a private backend needs its own exposure, and VPC links are outside this contract. - The gateway hostname is Google’s. Custom domains and certificates are configured on Google Cloud, not through the API Gateway v2 domain-name calls.
Other considerations
- Operations and ownership. Google Cloud runs the gateway; the adapter owns your API configuration and the Lambda ingress. Gateway quotas, request logs and metrics are Google’s. - Choosing between the two targets. If any API you deploy needs AWS_IAM or a Lambda authorizer, the Envoy target serves everything and keeps one operating model. Pick this target when your APIs are JWT or public and you want Google to run the request path. - Migration. Recreate the API, deploy a stage, confirm the gateway’s hostname answers, then repoint clients or DNS.
On Azure
Via Azure API Management
How an API lands on Azure API Management
Your tooling calls the API Gateway v2 management API unchanged. The adapter records the API, its routes, integrations, authorizers, deployments and stages, and when a stage is deployed it writes an API Management API with one operation per route and method, each carrying the policies its authorization needs and a backend pointing at the integration. Requests from your clients go to the API Management hostname and are handled by Azure. The decision to use this target is made once per API. Every route, authorizer and integration is checked against the rule below as it is created, and an API that fits is served here in full. An API that does not fit is served on Envoy in full; routes are never split between the two backends.The eligibility rule
Azure API Management serves an HTTP API when every integration is an HTTP_PROXY to a URL, or a Lambda proxy (AWS_PROXY) reached through the adapter’s ingress. Any of the four authorizer kinds is accepted: NONE and JWT are decided by API Management’s own policies, and AWS_IAM and Lambda authorizers are decided by the adapter through a policy callout on each request. A WebSocket API is outside the rule and is served on Envoy. A CreateRoute, CreateAuthorizer or CreateIntegration outside the rule is refused when it is made, with the reason.Authorizers and the callout
A JWT authorizer becomes a validate-jwt policy on each of its operations: issuer, audience, signing keys, token times and required scopes are checked by API Management. A public route has no authorization policy. An AWS_IAM route or a route with a Lambda authorizer carries a policy that sends the request’s identity material to the adapter before the backend is called. For AWS_IAM the adapter verifies the SigV4 signature and evaluates execute-api:Invoke against the caller’s permissions; for a Lambda authorizer it runs your authorizer function with the configured identity sources and honours its cache settings. A deny is returned to the client as API Gateway would return it, and the backend is not reached. The callout is a network hop on every such request, so an AWS_IAM or Lambda-authorizer route on this target has higher latency than the same route on Envoy, where the check is in-cluster.Integrations, deployments and stages
An HTTP_PROXY integration becomes the operation’s backend URL. A Lambda proxy integration’s backend is the adapter’s ingress, which builds the payload format 1.0 or 2.0 event, invokes the function under the integration’s own authority and returns the function’s status, headers and body; API Management holds no AWS credential and cannot invoke a function itself. A deployment records a fixed revision of the API and a stage selects one. A stage change is a set of operation and policy writes on API Management, applied together; propagation is a matter of seconds, not the minutes of an API config rollout. Exercise a route after deploying before moving traffic.Limitations
- WebSocket APIs are not served here. They are served on Envoy, where the adapter’s connection worker owns the socket. - AWS_IAM and Lambda-authorizer routes cost a callout. Each such request makes a synchronous call to the adapter before the backend; measure the added latency for your routes before choosing this target for a latency-sensitive API. - One operation per route and method. A route key with ANY becomes one operation per HTTP method, and the policy document that decides eligibility grows with the route count; a very large API may exceed API Management’s policy size limit and is refused with the reason. - API Management reaches backends over HTTP/1.1. There is no HTTP/2 from the gateway to the backend. - Custom domains and certificates are configured on API Management, not through the API Gateway v2 domain-name calls.
Other considerations
- Operations and ownership. Azure runs API Management; the adapter owns your API configuration, the authorization callouts and the Lambda ingress. Gateway capacity, request logs and metrics are Azure’s, and the Standard v2 tier is the one this mapping provisions. - Private ingress. Standard v2 supports an inbound private endpoint, so the gateway can be made reachable only through your network; configure that on API Management. - Choosing between the two targets. Pick this target when you want Azure to run the request path and your authorizer mix is mostly JWT or public. An API whose routes are mostly AWS_IAM or Lambda-authorized keeps lower latency on Envoy. - Migration. Recreate the API, deploy a stage, confirm the API Management hostname answers, then repoint clients or DNS.
Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.API Gateway v2 (HTTP/WebSocket) to Azure API Management
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Authoring calls validate and store API, route, integration, authorizer, deployment and stage records. Deployment materialization onto azure::1.0.0::api-management is coordinated separately. For served requests, ingress parsing, authorization callouts, Lambda-event construction and response conversion remain adapter work; backend integration execution is separately spanned.How the latency targets were chosen
API Gateway authoring reads: 5 ms monthly p99.GetApi, GetApis, GetAuthorizer, GetAuthorizers, GetIntegration, GetIntegrations, GetRoute, GetRoutes. Indexed control-state read and bounded response encoding.
API, route, integration and authorizer mutation: 12 ms monthly p99. CreateApi, CreateAuthorizer, CreateIntegration, CreateRoute, DeleteApi, DeleteAuthorizer, DeleteIntegration, DeleteRoute, UpdateApi, UpdateAuthorizer, UpdateIntegration, UpdateRoute. Validation and one durable authoring-state mutation.
Deployment and stage coordination: 25 ms monthly p99. CreateDeployment, CreateStage, DeleteStage, GetDeployment, GetDeployments, GetStage, GetStages, UpdateStage. Immutable snapshot construction and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Authoring scales by API while mutations to one API are generation ordered. Reads and bounded lists scale horizontally. Qualification fixes routes, integrations, authorizers, stages, document bytes and list-page size; deployment trials include materialization fan-out without folding provider propagation time into local processing. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A deployment is an immutable complete revision, stages select one revision atomically, dependent routes never become public when an authorizer is removed, and invocation authority remains separate from caller authority. Unsupported private links or custom-domain shapes fail explicitly.Example and diagnosis
CreateDeployment snapshots 50 routes and five authorizers. The coordinated-write target covers snapshot construction and durable admission. Writing those routes and policies to API Management or Google API Gateway is measured as propagation; stage traffic changes only when the selected revision is ready under the profile contract. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
API Gateway v2 (HTTP/WebSocket) to Envoy
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Authoring calls validate and store API, route, integration, authorizer, deployment and stage records. Deployment materialization onto envoy::1.0.0::proxy is coordinated separately. For served requests, ingress parsing, authorization callouts, Lambda-event construction and response conversion remain adapter work; backend integration execution is separately spanned.How the latency targets were chosen
WebSocket connection management: 5 ms monthly p99.DeleteConnection, GetConnection, PostToConnection. Authorization, connection-owner lookup and bounded frame admission or metadata response.
API Gateway authoring reads: 5 ms monthly p99. GetApi, GetApis, GetAuthorizer, GetAuthorizers, GetIntegration, GetIntegrations, GetRoute, GetRoutes. Indexed control-state read and bounded response encoding.
API, route, integration and authorizer mutation: 12 ms monthly p99. CreateApi, CreateAuthorizer, CreateIntegration, CreateRoute, DeleteApi, DeleteAuthorizer, DeleteIntegration, DeleteRoute, UpdateApi, UpdateAuthorizer, UpdateIntegration, UpdateRoute. Validation and one durable authoring-state mutation.
Deployment and stage coordination: 25 ms monthly p99. CreateDeployment, CreateStage, DeleteStage, GetDeployment, GetDeployments, GetStage, GetStages, UpdateStage. Immutable snapshot construction and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Authoring scales by API while mutations to one API are generation ordered. Reads and bounded lists scale horizontally. Qualification fixes routes, integrations, authorizers, stages, document bytes and list-page size; deployment trials include materialization fan-out without folding provider propagation time into local processing. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A deployment is an immutable complete revision, stages select one revision atomically, dependent routes never become public when an authorizer is removed, and invocation authority remains separate from caller authority. Unsupported private links or custom-domain shapes fail explicitly.Example and diagnosis
CreateDeployment snapshots 50 routes and five authorizers. The coordinated-write target covers snapshot construction and durable admission. Writing those routes and policies to API Management or Google API Gateway is measured as propagation; stage traffic changes only when the selected revision is ready under the profile contract. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Authoring calls validate and store API, route, integration, authorizer, deployment and stage records. Deployment materialization onto google::1.0.0::api-gateway is coordinated separately. For served requests, ingress parsing, authorization callouts, Lambda-event construction and response conversion remain adapter work; backend integration execution is separately spanned.How the latency targets were chosen
API Gateway authoring reads: 5 ms monthly p99.GetApi, GetApis, GetAuthorizer, GetAuthorizers, GetIntegration, GetIntegrations, GetRoute, GetRoutes. Indexed control-state read and bounded response encoding.
API, route, integration and authorizer mutation: 12 ms monthly p99. CreateApi, CreateAuthorizer, CreateIntegration, CreateRoute, DeleteApi, DeleteAuthorizer, DeleteIntegration, DeleteRoute, UpdateApi, UpdateAuthorizer, UpdateIntegration, UpdateRoute. Validation and one durable authoring-state mutation.
Deployment and stage coordination: 25 ms monthly p99. CreateDeployment, CreateStage, DeleteStage, GetDeployment, GetDeployments, GetStage, GetStages, UpdateStage. Immutable snapshot construction and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Authoring scales by API while mutations to one API are generation ordered. Reads and bounded lists scale horizontally. Qualification fixes routes, integrations, authorizers, stages, document bytes and list-page size; deployment trials include materialization fan-out without folding provider propagation time into local processing. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A deployment is an immutable complete revision, stages select one revision atomically, dependent routes never become public when an authorizer is removed, and invocation authority remains separate from caller authority. Unsupported private links or custom-domain shapes fail explicitly.Example and diagnosis
CreateDeployment snapshots 50 routes and five authorizers. The coordinated-write target covers snapshot construction and durable admission. Writing those routes and policies to API Management or Google API Gateway is measured as propagation; stage traffic changes only when the selected revision is ready under the profile contract. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.