These tables show Tensor9’s standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
Amazon Web Services
| Origin service | Adapter | SLA | Service level | Conditions | Notes |
|---|---|---|---|---|---|
| API Gateway (REST) | API Gateway (REST) to Envoy | API Gateway authoring reads | 5 ms monthly p99 | Point read or at most 100 returned records; configuration at most 1 MiB. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing. | Deployment availability. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing. |
| API Gateway (REST) | API Gateway (REST) to Envoy | API, route, integration and authorizer mutation | 12 ms monthly p99 | One resource per call; API configuration at most 1 MiB. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing. | 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. |
| API Gateway (REST) | API Gateway (REST) to Envoy | Deployment and stage coordination | 25 ms monthly p99 | at most 100 routes and at most 20 authorizers/integrations; provider propagation separate. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| API Gateway (REST) | API Gateway (REST) to Envoy | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| API Gateway (REST) | API Gateway (REST) to Envoy | Documented adapter behavior | Preserve the supported behavior documented for this adapter | 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. | |
| API Gateway (REST) | API Gateway (REST) to Envoy | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing. | |
| API Gateway (REST) | API Gateway (REST) to Envoy | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Azure API Management | API Gateway authoring reads | 5 ms monthly p99 | Point read or at most 100 returned records; configuration at most 1 MiB. | 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. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Azure API Management | API, route, integration and authorizer mutation | 12 ms monthly p99 | One resource per call; API configuration at most 1 MiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Azure API Management | Deployment and stage coordination | 25 ms monthly p99 | at most 100 routes and at most 20 authorizers/integrations; provider propagation separate. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Azure API Management | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Azure API Management | Documented adapter behavior | Preserve the supported behavior documented for this adapter | 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. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Azure API Management | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Azure API Management | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Envoy | WebSocket connection management | 5 ms monthly p99 | One owned connection and at most 32 KiB posted data; client receipt is not implied. | 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. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Envoy | API Gateway authoring reads | 5 ms monthly p99 | Point read or at most 100 returned records; configuration at most 1 MiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Envoy | API, route, integration and authorizer mutation | 12 ms monthly p99 | One resource per call; API configuration at most 1 MiB. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Envoy | Deployment and stage coordination | 25 ms monthly p99 | at most 100 routes and at most 20 authorizers/integrations; provider propagation separate. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Envoy | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Envoy | Documented adapter behavior | Preserve the supported behavior documented for this adapter | 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. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Envoy | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Envoy | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway | API Gateway authoring reads | 5 ms monthly p99 | Point read or at most 100 returned records; configuration at most 1 MiB. | 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. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway | API, route, integration and authorizer mutation | 12 ms monthly p99 | One resource per call; API configuration at most 1 MiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway | Deployment and stage coordination | 25 ms monthly p99 | at most 100 routes and at most 20 authorizers/integrations; provider propagation separate. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway | Documented adapter behavior | Preserve the supported behavior documented for this adapter | 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. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| API Gateway v2 (HTTP/WebSocket) | API Gateway v2 (HTTP/WebSocket) to Tensor9 Trivial | Not applicable | No numerical term | The application or appliance ingress supplies this routing capability; there is no API Gateway adapter endpoint to measure for this mapping. | |
| AWS Organizations | AWS Organizations to Organization account store | Bounded account listing | 8 ms monthly p99 | At most 100 accounts in the entire backing account store and 1 MiB serialized output; authorization, full-store scan and serialization included. No pagination is provided. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability. | Deployment availability. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability. |
| AWS Organizations | AWS Organizations to Organization account store | Organization creation | 15 ms monthly p99 | One authenticated management account, one organization and a 64 KiB request; durable commit included. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability. | 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. |
| AWS Organizations | AWS Organizations to Organization account store | Account lifecycle transaction | 40 ms monthly p99 | One account and at most 20 linked identity/claim records; host-owned transaction and durable response included, external provisioning readiness excluded. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| AWS Organizations | AWS Organizations to Organization account store | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| AWS Organizations | AWS Organizations to Organization account store | Documented adapter behavior | Preserve the supported behavior documented for this adapter | CreateOrganization must bind the verified caller. CreateAccount may succeed only when bootstrap authority and the host transaction are available; retries preserve account identity. CloseAccount must not retire a foreign member. DescribeOrganization is deliberately unserved, not a hidden implication of the shared model. | |
| AWS Organizations | AWS Organizations to Organization account store | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability. | |
| AWS Organizations | AWS Organizations to Organization account store | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| AppConfig | AppConfig to Azure App Configuration | Not applicable | No numerical term | Configuration is seeded during deployment and read through the target’s native SDK. There is no AppConfig request-serving adapter on this path. | |
| AppConfig | AppConfig to Flagsmith | Not applicable | No numerical term | Configuration is seeded during deployment and read through the target’s native SDK. There is no AppConfig request-serving adapter on this path. | |
| Application Load Balancer | Application Load Balancer to Azure Load Balancer | Network and load-balancer state reads | 8 ms monthly p99 | One resource or at most 100 returned listeners, targets or rules. | 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. |
| Application Load Balancer | Application Load Balancer to Azure Load Balancer | Listener, target and topology mutation | 18 ms monthly p99 | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Application Load Balancer | Application Load Balancer to Azure Load Balancer | Bounded routing and authorization policy | 25 ms monthly p99 | at most 100 routing rules, at most 20 conditions per rule and at most 20 target groups. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Application Load Balancer | Application Load Balancer to Azure Load Balancer | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Application Load Balancer | Application Load Balancer to Azure Load Balancer | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| Application Load Balancer | Application Load Balancer to Azure Load Balancer | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Application Load Balancer | Application Load Balancer to Azure Load Balancer | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Application Load Balancer | Application Load Balancer to Cloud Load Balancing | Network and load-balancer state reads | 8 ms monthly p99 | One resource or at most 100 returned listeners, targets or rules. | 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. |
| Application Load Balancer | Application Load Balancer to Cloud Load Balancing | Listener, target and topology mutation | 18 ms monthly p99 | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Application Load Balancer | Application Load Balancer to Cloud Load Balancing | Bounded routing and authorization policy | 25 ms monthly p99 | at most 100 routing rules, at most 20 conditions per rule and at most 20 target groups. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Application Load Balancer | Application Load Balancer to Cloud Load Balancing | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Application Load Balancer | Application Load Balancer to Cloud Load Balancing | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| Application Load Balancer | Application Load Balancer to Cloud Load Balancing | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Application Load Balancer | Application Load Balancer to Cloud Load Balancing | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Application Load Balancer | Application Load Balancer to DigitalOcean Load Balancer | Network and load-balancer state reads | 8 ms monthly p99 | One resource or at most 100 returned listeners, targets or rules. | 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. |
| Application Load Balancer | Application Load Balancer to DigitalOcean Load Balancer | Listener, target and topology mutation | 18 ms monthly p99 | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Application Load Balancer | Application Load Balancer to DigitalOcean Load Balancer | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Application Load Balancer | Application Load Balancer to DigitalOcean Load Balancer | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| Application Load Balancer | Application Load Balancer to DigitalOcean Load Balancer | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Application Load Balancer | Application Load Balancer to DigitalOcean Load Balancer | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Application Load Balancer | Application Load Balancer to OCI Load Balancer | Network and load-balancer state reads | 8 ms monthly p99 | One resource or at most 100 returned listeners, targets or rules. | 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. |
| Application Load Balancer | Application Load Balancer to OCI Load Balancer | Listener, target and topology mutation | 18 ms monthly p99 | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Application Load Balancer | Application Load Balancer to OCI Load Balancer | Bounded routing and authorization policy | 25 ms monthly p99 | at most 100 routing rules, at most 20 conditions per rule and at most 20 target groups. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Application Load Balancer | Application Load Balancer to OCI Load Balancer | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Application Load Balancer | Application Load Balancer to OCI Load Balancer | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| Application Load Balancer | Application Load Balancer to OCI Load Balancer | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Application Load Balancer | Application Load Balancer to OCI Load Balancer | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Application Load Balancer | Application Load Balancer to Scaleway Load Balancer | Not applicable | No numerical term | This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply. | |
| Aurora PostgreSQL | Aurora PostgreSQL to AlloyDB for PostgreSQL (Aurora management adapter) | Bounded cluster and member status | 20 ms monthly p99 | One cluster or at most 100 adapter-owned cluster/member records and 256 KiB response; observed target status included, PostgreSQL query time excluded. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here. | Deployment availability. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here. |
| Aurora PostgreSQL | Aurora PostgreSQL to AlloyDB for PostgreSQL (Aurora management adapter) | Cluster and member lifecycle admission | 30 ms monthly p99 | One cluster or member and at most 32 KiB supported settings; validation and durable intent included, AlloyDB provisioning, failover and teardown readiness excluded. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here. | 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. |
| Aurora PostgreSQL | Aurora PostgreSQL to AlloyDB for PostgreSQL (Aurora management adapter) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Aurora PostgreSQL | Aurora PostgreSQL to AlloyDB for PostgreSQL (Aurora management adapter) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle call means complete desired state is durable, not that AlloyDB is ready. The adapter preserves the Aurora cluster/member relationship and writer-versus-reader identities, refuses unsupported Aurora settings, and never reports a foreign database as adapter-managed. Status reflects observed target readiness rather than an optimistic synthetic success. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Aurora PostgreSQL | Aurora PostgreSQL to AlloyDB for PostgreSQL (Aurora management adapter) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here. | |
| Aurora PostgreSQL | Aurora PostgreSQL to AlloyDB for PostgreSQL (Aurora management adapter) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Aurora PostgreSQL | Aurora PostgreSQL to Cloud SQL for PostgreSQL | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| Aurora PostgreSQL | Aurora PostgreSQL to Cloud SQL for PostgreSQL | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Aurora PostgreSQL | Aurora PostgreSQL to Cloud SQL for PostgreSQL | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Aurora PostgreSQL | Aurora PostgreSQL to Cloud SQL for PostgreSQL | Bounded Data API translation | 5 ms monthly p99 | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. | |
| Aurora PostgreSQL | Aurora PostgreSQL to Cloud SQL for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Aurora PostgreSQL | Aurora PostgreSQL to Cloud SQL for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| Aurora PostgreSQL | Aurora PostgreSQL to Cloud SQL for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Aurora PostgreSQL | Aurora PostgreSQL to Cloud SQL for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Aurora PostgreSQL | Aurora PostgreSQL to OCI Database with PostgreSQL | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| Aurora PostgreSQL | Aurora PostgreSQL to OCI Database with PostgreSQL | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Aurora PostgreSQL | Aurora PostgreSQL to OCI Database with PostgreSQL | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Aurora PostgreSQL | Aurora PostgreSQL to OCI Database with PostgreSQL | Bounded Data API translation | 5 ms monthly p99 | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. | |
| Aurora PostgreSQL | Aurora PostgreSQL to OCI Database with PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Aurora PostgreSQL | Aurora PostgreSQL to OCI Database with PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| Aurora PostgreSQL | Aurora PostgreSQL to OCI Database with PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Aurora PostgreSQL | Aurora PostgreSQL to OCI Database with PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL | Bounded Data API translation | 5 ms monthly p99 | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL (CloudNativePG) | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL (CloudNativePG) | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL (CloudNativePG) | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL (CloudNativePG) | Bounded Data API translation | 5 ms monthly p99 | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL (CloudNativePG) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL (CloudNativePG) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL (CloudNativePG) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL (CloudNativePG) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL Flexible Server | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL Flexible Server | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL Flexible Server | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL Flexible Server | Bounded Data API translation | 5 ms monthly p99 | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Aurora PostgreSQL | Aurora PostgreSQL to PostgreSQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Aurora PostgreSQL | Aurora PostgreSQL to Scaleway Managed Database for PostgreSQL | Not applicable | No numerical term | This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Anthropic Messages API | Unary model request translation | 5 ms monthly p99 | Request and response each at most 64 KiB; model execution excluded by observed span; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Anthropic Messages API | Streaming model first-chunk translation | 8 ms monthly p99 | Request at most 256 KiB; first response chunk at most 64 KiB; at most 8 concurrent streams per caller; model execution excluded by observed span. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Anthropic Messages API | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Anthropic Messages API | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Payload bytes and content types are preserved, streaming chunks remain ordered, cancellation stops adapter-owned work, and provider safety or model errors retain a typed failure rather than becoming a fabricated success. CountTokens never implies an inference call. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Anthropic Messages API | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Anthropic Messages API | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Azure RAI Content Filter Policy | Not applicable | No numerical term | This mapping provisions an Azure content-filter policy. A policy is not a Bedrock inference endpoint; inference adapters have their own operation-specific terms. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OCI Generative AI | Unary model request translation | 5 ms monthly p99 | Request and response each at most 64 KiB; model execution excluded by observed span; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OCI Generative AI | Streaming model first-chunk translation | 8 ms monthly p99 | Request at most 256 KiB; first response chunk at most 64 KiB; at most 8 concurrent streams per caller; model execution excluded by observed span. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OCI Generative AI | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OCI Generative AI | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Payload bytes and content types are preserved, streaming chunks remain ordered, cancellation stops adapter-owned work, and provider safety or model errors retain a typed failure rather than becoming a fabricated success. CountTokens never implies an inference call. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OCI Generative AI | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OCI Generative AI | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OpenAI Chat Completions | Unary model request translation | 5 ms monthly p99 | Request and response each at most 64 KiB; model execution excluded by observed span; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OpenAI Chat Completions | Streaming model first-chunk translation | 8 ms monthly p99 | Request at most 256 KiB; first response chunk at most 64 KiB; at most 8 concurrent streams per caller; model execution excluded by observed span. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OpenAI Chat Completions | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OpenAI Chat Completions | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Payload bytes and content types are preserved, streaming chunks remain ordered, cancellation stops adapter-owned work, and provider safety or model errors retain a typed failure rather than becoming a fabricated success. CountTokens never implies an inference call. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OpenAI Chat Completions | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to OpenAI Chat Completions | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Scaleway Managed Inference | Unary model request translation | 5 ms monthly p99 | Request and response each at most 64 KiB; model execution excluded by observed span; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Scaleway Managed Inference | Streaming model first-chunk translation | 8 ms monthly p99 | Request at most 256 KiB; first response chunk at most 64 KiB; at most 8 concurrent streams per caller; model execution excluded by observed span. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Scaleway Managed Inference | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Scaleway Managed Inference | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Payload bytes and content types are preserved, streaming chunks remain ordered, cancellation stops adapter-owned work, and provider safety or model errors retain a typed failure rather than becoming a fabricated success. CountTokens never implies an inference call. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Scaleway Managed Inference | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Scaleway Managed Inference | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Claude | Unary model request translation | 5 ms monthly p99 | Request and response each at most 64 KiB; model execution excluded by observed span; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Claude | Streaming model first-chunk translation | 8 ms monthly p99 | Request at most 256 KiB; first response chunk at most 64 KiB; at most 8 concurrent streams per caller; model execution excluded by observed span. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Claude | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Claude | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Payload bytes and content types are preserved, streaming chunks remain ordered, cancellation stops adapter-owned work, and provider safety or model errors retain a typed failure rather than becoming a fabricated success. CountTokens never implies an inference call. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Claude | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Claude | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Gemini | Unary model request translation | 5 ms monthly p99 | Request and response each at most 64 KiB; model execution excluded by observed span; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Gemini | Streaming model first-chunk translation | 8 ms monthly p99 | Request at most 256 KiB; first response chunk at most 64 KiB; at most 8 concurrent streams per caller; model execution excluded by observed span. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Gemini | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Gemini | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Payload bytes and content types are preserved, streaming chunks remain ordered, cancellation stops adapter-owned work, and provider safety or model errors retain a typed failure rather than becoming a fabricated success. CountTokens never implies an inference call. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Gemini | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Gemini | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Llama | Unary model request translation | 5 ms monthly p99 | Request and response each at most 64 KiB; model execution excluded by observed span; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Llama | Streaming model first-chunk translation | 8 ms monthly p99 | Request at most 256 KiB; first response chunk at most 64 KiB; at most 8 concurrent streams per caller; model execution excluded by observed span. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Llama | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Llama | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Payload bytes and content types are preserved, streaming chunks remain ordered, cancellation stops adapter-owned work, and provider safety or model errors retain a typed failure rather than becoming a fabricated success. CountTokens never implies an inference call. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Llama | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to Vertex AI - Llama | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to vLLM / Ollama | Unary model request translation | 5 ms monthly p99 | Request and response each at most 64 KiB; model execution excluded by observed span; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to vLLM / Ollama | Streaming model first-chunk translation | 8 ms monthly p99 | Request at most 256 KiB; first response chunk at most 64 KiB; at most 8 concurrent streams per caller; model execution excluded by observed span. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to vLLM / Ollama | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Bedrock (LLM inference) | Bedrock (LLM inference) to vLLM / Ollama | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Payload bytes and content types are preserved, streaming chunks remain ordered, cancellation stops adapter-owned work, and provider safety or model errors retain a typed failure rather than becoming a fabricated success. CountTokens never implies an inference call. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to vLLM / Ollama | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Bedrock (LLM inference) | Bedrock (LLM inference) to vLLM / Ollama | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (provisioned) | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | 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. |
| DynamoDB | DynamoDB to Azure Cosmos DB (provisioned) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Azure Cosmos DB (provisioned) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Azure Cosmos DB (provisioned) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (provisioned) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | 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. |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Small point reads | 1 ms monthly p99 | One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page. | 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. |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Plain small-item writes | 1 ms monthly p99 | One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Conditional writes and updates | 5 ms monthly p99 | One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Bounded query and scan pages | 10 ms monthly p99 | One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Bounded item batches | 10 ms monthly p99 | At most 25 item actions and 100 KiB aggregate full-item data. Per-item results and unprocessed-item behavior follow this backend’s profile. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Bounded PartiQL statements | 10 ms monthly p99 | At most 10 statements of 2 KiB each; at most 100 examined items or 400 KiB returned/decoded data. Only grammar and transaction forms supported by this target are covered. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | DynamoDB Streams reads | 10 ms monthly p99 | One stream page, at most 100 records and 400 KiB total record data; a single shard iterator and the documented retention window. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Azure Cosmos DB (serverless) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | 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. |
| DynamoDB | DynamoDB to Cloud Bigtable | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Cloud Bigtable | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Cloud Bigtable | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Small point reads | 1 ms monthly p99 | One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page. | 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. |
| DynamoDB | DynamoDB to Cloud Bigtable | Plain small-item writes | 1 ms monthly p99 | One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Cloud Bigtable | Conditional writes and updates | 3 ms monthly p99 | One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Cloud Bigtable | Bounded query and scan pages | 5 ms monthly p99 | One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Bounded item batches | 10 ms monthly p99 | At most 25 item actions and 100 KiB aggregate full-item data. Per-item results and unprocessed-item behavior follow this backend’s profile. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Cloud Bigtable | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | 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. |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Small point reads | 1 ms monthly p99 | One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page. | 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. |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Plain small-item writes | 1 ms monthly p99 | One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Conditional writes and updates | 3 ms monthly p99 | One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Bounded query and scan pages | 5 ms monthly p99 | One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Bounded transactions | 10 ms monthly p99 | At most 10 actions and 40 KiB total item data, at most two tables, within the target’s documented transaction scope. This row does not add transaction support to a profile that rejects it. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | DynamoDB Streams reads | 10 ms monthly p99 | One stream page, at most 100 records and 400 KiB total record data; a single shard iterator and the documented retention window. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Cloud SQL for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Cloud Spanner | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | 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. |
| DynamoDB | DynamoDB to Cloud Spanner | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Cloud Spanner | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Cloud Spanner | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Cloud Spanner | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Firestore | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | 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. |
| DynamoDB | DynamoDB to Firestore | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Firestore | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Firestore | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Firestore | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Firestore | Correct request handling | 99.9% per calendar month | Only the operations listed in this adapter’s latency rows, using supported request options. | What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met. |
| DynamoDB | DynamoDB to Firestore | Endpoint reachability | 99.9% per calendar month | Tests whether the endpoint can be reached, separately from whether requests complete correctly. | DynamoDB write limits. A plain write has no ConditionExpression or legacy Expected, no returned old item (ReturnValues absent or NONE), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies. |
| DynamoDB | DynamoDB to Firestore | GetItem, plain PutItem / DeleteItem latency | 1 ms monthly p99 | Full item ≤4 KiB, at most 64 attributes and nesting depth 8. Covered read-consistency settings. Writes have no condition, ReturnValues absent/NONE, no secondary-index maintenance, and streams disabled. | Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA. |
| DynamoDB | DynamoDB to Firestore | UpdateItem, conditional or old-item-return PutItem / DeleteItem latency | 3 ms monthly p99 | Full item ≤4 KiB; expression ≤2 KiB and at most 20 clauses; at most two maintained indexes; streams disabled. Use supported conditions and return-value options. Local retries and adapter metadata waits count. | Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment. |
| DynamoDB | DynamoDB to Firestore | Query, Scan latency | 10 ms monthly p99 | One page. The adapter may examine or load ≤100 items and ≤400 KiB of data, including items filtered out of the response. | |
| DynamoDB | DynamoDB to Firestore | TransactWriteItems latency | 20 ms monthly p99 | Supported combinations of operations, with ≤100 actions and ≤400 KiB of total data. Any smaller API or adapter limit still applies. | |
| DynamoDB | DynamoDB to Firestore | Saving writes without losing data | Save all required data before returning success | Save both the target data and required adapter records before returning success. The adapter must not lose data it has confirmed as saved. | |
| DynamoDB | DynamoDB to Firestore | Conditions, transactions and stored values | Preserve the behavior documented for this adapter | Apply each condition check and write together. Preserve supported all-or-nothing transactions, number values, and read/index behavior. The supported item-size limit remains 400 KiB. | |
| DynamoDB | DynamoDB to Firestore | Adapter autoscaling and limits | Automatic scaling within agreed traffic and deployment limits | Agree limits for the mix of operations, full item and expression sizes, indexes, heavily used documents, which process writes stream records, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Target capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits. | |
| DynamoDB | DynamoDB to OCI NoSQL Database | Not applicable | No numerical term | The mapping provisions OCI NoSQL tables without exposing a DynamoDB management endpoint. There is no DynamoDB request-serving fabric on this path. | |
| DynamoDB | DynamoDB to OCI NoSQL Database | Not applicable | No numerical term | The application uses the OCI NoSQL API on this mapping. It does not provide a DynamoDB request translator, so DynamoDB fabric latency does not apply. | |
| DynamoDB | DynamoDB to PostgreSQL | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | 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. |
| DynamoDB | DynamoDB to PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to PostgreSQL | Small point reads | 1 ms monthly p99 | One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page. | 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. |
| DynamoDB | DynamoDB to PostgreSQL | Plain small-item writes | 1 ms monthly p99 | One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to PostgreSQL | Conditional writes and updates | 3 ms monthly p99 | One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to PostgreSQL | Bounded query and scan pages | 5 ms monthly p99 | One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts. | |
| DynamoDB | DynamoDB to PostgreSQL | Bounded transactions | 10 ms monthly p99 | At most 10 actions and 40 KiB total item data, at most two tables, within the target’s documented transaction scope. This row does not add transaction support to a profile that rejects it. | |
| DynamoDB | DynamoDB to PostgreSQL | DynamoDB Streams reads | 10 ms monthly p99 | One stream page, at most 100 records and 400 KiB total record data; a single shard iterator and the documented retention window. | |
| DynamoDB | DynamoDB to PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| DynamoDB | DynamoDB to PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | |
| DynamoDB | DynamoDB to PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | Correct request handling | 99.9% per calendar month | Only the operations listed in this adapter’s latency rows, using supported request options. | What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met. |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | Endpoint reachability | 99.9% per calendar month | Tests whether the endpoint can be reached, separately from whether requests complete correctly. | DynamoDB write limits. A plain write has no ConditionExpression or legacy Expected, no returned old item (ReturnValues absent or NONE), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies. |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | GetItem, plain PutItem / DeleteItem latency | 1 ms monthly p99 | Full item ≤4 KiB, at most 64 attributes and nesting depth 8. Covered read-consistency settings. Writes have no condition, ReturnValues absent/NONE, no secondary-index maintenance, and streams disabled. | Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA. |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | UpdateItem, conditional or old-item-return PutItem / DeleteItem latency | 5 ms monthly p99 | Full item ≤4 KiB; expression ≤2 KiB and at most 20 clauses; at most two maintained indexes; streams disabled. Use supported conditions and return-value options. Local retries and adapter metadata waits count. | Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment. |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | Query, Scan latency | 10 ms monthly p99 | One page. The adapter may examine or load ≤100 items and ≤400 KiB of data, including items filtered out of the response. | |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | BatchGetItem, BatchWriteItem latency | 20 ms monthly p99 | ≤100 items and ≤400 KiB of total data. Any smaller API limit still applies. Report items that were not processed. | |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | Saving each write completely | Save all required data before returning success | Save each write within its partition together with required metadata and records for pending follow-up work. Apply supported condition checks and writes together. No multi-item transaction SLA. | |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | Base-table and index consistency | Read consistency as documented for this adapter | Use a Strong-consistency Cosmos DB account for strongly consistent table and local secondary index reads. Global secondary indexes update asynchronously, with no fixed freshness deadline. Strongly consistent GSI requests are rejected. | |
| DynamoDB | DynamoDB to Provisioned Cosmos DB | Adapter autoscaling and limits | Automatic scaling within agreed traffic and deployment limits | Agree limits for the mix of operations, full item and expression sizes, indexes and streams, Cosmos DB throughput mode (RU/s), partition and container layout, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Target capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | 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. |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Small point reads | 1 ms monthly p99 | One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page. | 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. |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Plain small-item writes | 1 ms monthly p99 | One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Conditional writes and updates | 3 ms monthly p99 | One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Bounded query and scan pages | 5 ms monthly p99 | One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Bounded transactions | 10 ms monthly p99 | At most 10 actions and 40 KiB total item data, at most two tables, within the target’s documented transaction scope. This row does not add transaction support to a profile that rejects it. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Bounded PartiQL statements | 10 ms monthly p99 | At most 10 statements of 2 KiB each; at most 100 examined items or 400 KiB returned/decoded data. Only grammar and transaction forms supported by this target are covered. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Table and configuration API responses | 20 ms monthly p99 | One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| DynamoDB | DynamoDB to Scaleway Managed Database for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| DynamoDB | DynamoDB to Spanner | Correct request handling | 99.9% per calendar month | Only the operations listed in this adapter’s latency rows, using supported request options. | What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met. |
| DynamoDB | DynamoDB to Spanner | Endpoint reachability | 99.9% per calendar month | Tests whether the endpoint can be reached, separately from whether requests complete correctly. | DynamoDB write limits. A plain write has no ConditionExpression or legacy Expected, no returned old item (ReturnValues absent or NONE), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies. |
| DynamoDB | DynamoDB to Spanner | GetItem latency | 1 ms monthly p99 | Full item ≤4 KiB. Use the read-consistency and index settings covered by your agreement. | Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA. |
| DynamoDB | DynamoDB to Spanner | Plain PutItem / DeleteItem latency | 1 ms monthly p99 | Full item ≤4 KiB, at most 64 attributes and nesting depth 8. Covered read-consistency settings. Writes have no condition, ReturnValues absent/NONE, no secondary-index maintenance, and streams disabled. | Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment. |
| DynamoDB | DynamoDB to Spanner | UpdateItem, conditional or old-item-return PutItem / DeleteItem latency | 3 ms monthly p99 | Full item ≤4 KiB; expression ≤2 KiB and at most 20 clauses; at most two maintained indexes; streams disabled. Use supported conditions and return-value options. Local retries and adapter metadata waits count. | |
| DynamoDB | DynamoDB to Spanner | Query, Scan latency | 5 ms monthly p99 | One page. The adapter may examine or load ≤100 items and ≤400 KiB of data, including items filtered out of the response. | |
| DynamoDB | DynamoDB to Spanner | BatchGetItem, BatchWriteItem latency | 20 ms monthly p99 | ≤100 items and ≤400 KiB of total data. Any smaller API limit still applies. Report items that were not processed. | |
| DynamoDB | DynamoDB to Spanner | TransactGetItems, TransactWriteItems latency | 20 ms monthly p99 | Supported combinations of operations, with ≤100 actions and ≤400 KiB of total data. Any smaller API or adapter limit still applies. | |
| DynamoDB | DynamoDB to Spanner | Saving writes without losing data | Save all required data before returning success | Save both the target data and required adapter records before returning success. Recovering adapter records must not lose data already confirmed as saved. | |
| DynamoDB | DynamoDB to Spanner | Transactions, reads and stored values | Preserve the behavior documented for this adapter | Transactions must be all-or-nothing and safe to retry as documented. Preserve exact decimals and strongly consistent table reads; update indexes with the transaction. Strongly consistent GSI reads are unsupported. | |
| DynamoDB | DynamoDB to Spanner | Adapter autoscaling and limits | Automatic scaling within agreed traffic and deployment limits | Agree limits for the mix of operations, full item and transaction sizes, indexes, total connections and sessions, heavily used rows, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Target capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits. | |
| EC2 | EC2 Instances to Compute Engine | Local identity endpoint | 2 ms monthly p99 | One caller identity document; no provider call. | 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. |
| EC2 | EC2 Instances to Compute Engine | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 | EC2 Instances to Compute Engine | Instance and volume lifecycle admission | 20 ms monthly p99 | at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness separate. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 | EC2 Instances to Compute Engine | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| EC2 | EC2 Instances to Compute Engine | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | |
| EC2 | EC2 Instances to Compute Engine | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 | EC2 Instances to Compute Engine | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 | EC2 Instances to Compute Instance | Local identity endpoint | 2 ms monthly p99 | One caller identity document; no provider call. | 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. |
| EC2 | EC2 Instances to Compute Instance | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 | EC2 Instances to Compute Instance | Instance and volume lifecycle admission | 20 ms monthly p99 | at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness separate. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 | EC2 Instances to Compute Instance | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| EC2 | EC2 Instances to Compute Instance | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | |
| EC2 | EC2 Instances to Compute Instance | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 | EC2 Instances to Compute Instance | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 | EC2 Instances to Droplet | Local identity endpoint | 2 ms monthly p99 | One caller identity document; no provider call. | 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. |
| EC2 | EC2 Instances to Droplet | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 | EC2 Instances to Droplet | Instance and volume lifecycle admission | 20 ms monthly p99 | at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness separate. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 | EC2 Instances to Droplet | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| EC2 | EC2 Instances to Droplet | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | |
| EC2 | EC2 Instances to Droplet | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 | EC2 Instances to Droplet | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 | EC2 Instances to KubeVirt VM | Local identity endpoint | 2 ms monthly p99 | One caller identity document; no provider call. | 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. |
| EC2 | EC2 Instances to KubeVirt VM | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 | EC2 Instances to KubeVirt VM | Instance and volume lifecycle admission | 20 ms monthly p99 | at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness separate. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 | EC2 Instances to KubeVirt VM | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| EC2 | EC2 Instances to KubeVirt VM | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | |
| EC2 | EC2 Instances to KubeVirt VM | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 | EC2 Instances to KubeVirt VM | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 | EC2 Instances to Scaleway Instance | Local identity endpoint | 2 ms monthly p99 | One caller identity document; no provider call. | 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. |
| EC2 | EC2 Instances to Scaleway Instance | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 | EC2 Instances to Scaleway Instance | Instance and volume lifecycle admission | 20 ms monthly p99 | at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness separate. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 | EC2 Instances to Scaleway Instance | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| EC2 | EC2 Instances to Scaleway Instance | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | |
| EC2 | EC2 Instances to Scaleway Instance | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 | EC2 Instances to Scaleway Instance | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 | EC2 Instances to Virtual Machines | Local identity endpoint | 2 ms monthly p99 | One caller identity document; no provider call. | 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. |
| EC2 | EC2 Instances to Virtual Machines | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 | EC2 Instances to Virtual Machines | Instance and volume lifecycle admission | 20 ms monthly p99 | at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness separate. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 | EC2 Instances to Virtual Machines | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| EC2 | EC2 Instances to Virtual Machines | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | |
| EC2 | EC2 Instances to Virtual Machines | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 | EC2 Instances to Virtual Machines | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Droplet Autoscale Group | Fleet configuration and identity reads | 5 ms monthly p99 | One fleet; at most 20 zones/templates and at most 100 instances in returned status. | 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. |
| EC2 Auto Scaling | EC2 Auto Scaling to Droplet Autoscale Group | Fleet and scaling-policy mutation | 20 ms monthly p99 | One fleet and at most 20 policies/hooks; instance readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Auto Scaling | EC2 Auto Scaling to Droplet Autoscale Group | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Auto Scaling | EC2 Auto Scaling to Droplet Autoscale Group | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Minimum, maximum and desired capacity remain ordered and bounded. A successful mutation is durable, stale reconciliation cannot overwrite a newer generation, and target policy translation cannot silently change the metric or threshold. Replacement and drain preserve the declared availability policy. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Droplet Autoscale Group | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Droplet Autoscale Group | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Instance Pool | Fleet configuration and identity reads | 5 ms monthly p99 | One fleet; at most 20 zones/templates and at most 100 instances in returned status. | 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. |
| EC2 Auto Scaling | EC2 Auto Scaling to Instance Pool | Fleet and scaling-policy mutation | 20 ms monthly p99 | One fleet and at most 20 policies/hooks; instance readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Auto Scaling | EC2 Auto Scaling to Instance Pool | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Auto Scaling | EC2 Auto Scaling to Instance Pool | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Minimum, maximum and desired capacity remain ordered and bounded. A successful mutation is durable, stale reconciliation cannot overwrite a newer generation, and target policy translation cannot silently change the metric or threshold. Replacement and drain preserve the declared availability policy. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Instance Pool | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Instance Pool | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Managed Instance Group | Fleet configuration and identity reads | 5 ms monthly p99 | One fleet; at most 20 zones/templates and at most 100 instances in returned status. | 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. |
| EC2 Auto Scaling | EC2 Auto Scaling to Managed Instance Group | Fleet and scaling-policy mutation | 20 ms monthly p99 | One fleet and at most 20 policies/hooks; instance readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Auto Scaling | EC2 Auto Scaling to Managed Instance Group | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Auto Scaling | EC2 Auto Scaling to Managed Instance Group | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Minimum, maximum and desired capacity remain ordered and bounded. A successful mutation is durable, stale reconciliation cannot overwrite a newer generation, and target policy translation cannot silently change the metric or threshold. Replacement and drain preserve the declared availability policy. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Managed Instance Group | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Managed Instance Group | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Virtual Machine Scale Sets | Fleet configuration and identity reads | 5 ms monthly p99 | One fleet; at most 20 zones/templates and at most 100 instances in returned status. | 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. |
| EC2 Auto Scaling | EC2 Auto Scaling to Virtual Machine Scale Sets | Fleet and scaling-policy mutation | 20 ms monthly p99 | One fleet and at most 20 policies/hooks; instance readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Auto Scaling | EC2 Auto Scaling to Virtual Machine Scale Sets | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Auto Scaling | EC2 Auto Scaling to Virtual Machine Scale Sets | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Minimum, maximum and desired capacity remain ordered and bounded. A successful mutation is durable, stale reconciliation cannot overwrite a newer generation, and target policy translation cannot silently change the metric or threshold. Replacement and drain preserve the declared availability policy. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Virtual Machine Scale Sets | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 Auto Scaling | EC2 Auto Scaling to Virtual Machine Scale Sets | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Auto Scaling | EC2 Auto Scaling to VirtualMachinePool | Fleet configuration and identity reads | 5 ms monthly p99 | One fleet; at most 20 zones/templates and at most 100 instances in returned status. | 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. |
| EC2 Auto Scaling | EC2 Auto Scaling to VirtualMachinePool | Fleet and scaling-policy mutation | 20 ms monthly p99 | One fleet and at most 20 policies/hooks; instance readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Auto Scaling | EC2 Auto Scaling to VirtualMachinePool | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Auto Scaling | EC2 Auto Scaling to VirtualMachinePool | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Minimum, maximum and desired capacity remain ordered and bounded. A successful mutation is durable, stale reconciliation cannot overwrite a newer generation, and target policy translation cannot silently change the metric or threshold. Replacement and drain preserve the declared availability policy. | |
| EC2 Auto Scaling | EC2 Auto Scaling to VirtualMachinePool | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 Auto Scaling | EC2 Auto Scaling to VirtualMachinePool | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Control Plane | EC2 Control Plane to Compute Engine | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | 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. |
| EC2 Control Plane | EC2 Control Plane to Compute Engine | Instance and volume lifecycle admission | 20 ms monthly p99 | at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Control Plane | EC2 Control Plane to Compute Engine | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Control Plane | EC2 Control Plane to Compute Engine | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | |
| EC2 Control Plane | EC2 Control Plane to Compute Engine | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 Control Plane | EC2 Control Plane to Compute Engine | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Control Plane | EC2 Control Plane to DigitalOcean Droplet EC2 management adapter | Bounded managed-instance reads | 10 ms monthly p99 | Once the declared management endpoint is deployed: at most 100 adapter-managed instances or tags, 20 filters and 1 MiB response; foreign target-cloud resources excluded. This DigitalOcean EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | Deployment availability. This DigitalOcean EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. |
| EC2 Control Plane | EC2 Control Plane to DigitalOcean Droplet EC2 management adapter | Managed-instance lifecycle admission | 25 ms monthly p99 | Once the declared management endpoint is deployed: at most 20 instances, one supported image and subnet per request; durable intent included, native VM readiness and teardown excluded. This DigitalOcean EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | 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. |
| EC2 Control Plane | EC2 Control Plane to DigitalOcean Droplet EC2 management adapter | Tag and membership mutation | 18 ms monthly p99 | Once the declared management endpoint is deployed: at most 20 resources or tags; ModifyInstanceAttribute limited to security-group membership. This DigitalOcean EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Control Plane | EC2 Control Plane to DigitalOcean Droplet EC2 management adapter | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. This DigitalOcean EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Control Plane | EC2 Control Plane to DigitalOcean Droplet EC2 management adapter | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A launch must allocate stable instance IDs once, including on retried client tokens. Termination must refuse foreign resources; tags and security-group membership must not silently map to unsupported provider fields. An accepted mutation means durable intent, never that the target VM is already ready. | |
| EC2 Control Plane | EC2 Control Plane to DigitalOcean Droplet EC2 management adapter | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. This DigitalOcean EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | |
| EC2 Control Plane | EC2 Control Plane to DigitalOcean Droplet EC2 management adapter | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Control Plane | EC2 Control Plane to OCI Compute instance EC2 management adapter | Bounded managed-instance reads | 10 ms monthly p99 | Once the declared management endpoint is deployed: at most 100 adapter-managed instances or tags, 20 filters and 1 MiB response; foreign target-cloud resources excluded. This OCI EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | Deployment availability. This OCI EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. |
| EC2 Control Plane | EC2 Control Plane to OCI Compute instance EC2 management adapter | Managed-instance lifecycle admission | 25 ms monthly p99 | Once the declared management endpoint is deployed: at most 20 instances, one supported image and subnet per request; durable intent included, native VM readiness and teardown excluded. This OCI EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | 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. |
| EC2 Control Plane | EC2 Control Plane to OCI Compute instance EC2 management adapter | Tag and membership mutation | 18 ms monthly p99 | Once the declared management endpoint is deployed: at most 20 resources or tags; ModifyInstanceAttribute limited to security-group membership. This OCI EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Control Plane | EC2 Control Plane to OCI Compute instance EC2 management adapter | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. This OCI EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Control Plane | EC2 Control Plane to OCI Compute instance EC2 management adapter | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A launch must allocate stable instance IDs once, including on retried client tokens. Termination must refuse foreign resources; tags and security-group membership must not silently map to unsupported provider fields. An accepted mutation means durable intent, never that the target VM is already ready. | |
| EC2 Control Plane | EC2 Control Plane to OCI Compute instance EC2 management adapter | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. This OCI EC2 management mapping is declared, not a deployed production endpoint. These targets apply only after the exact management adapter and operations are deployed and named in a signed agreement; they do not time the separate in-guest self-discovery endpoint. | |
| EC2 Control Plane | EC2 Control Plane to OCI Compute instance EC2 management adapter | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Control Plane | EC2 Control Plane to Scaleway Instance | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | 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. |
| EC2 Control Plane | EC2 Control Plane to Scaleway Instance | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Control Plane | EC2 Control Plane to Scaleway Instance | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Control Plane | EC2 Control Plane to Scaleway Instance | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 Control Plane | EC2 Control Plane to Scaleway Instance | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EC2 Control Plane | EC2 Control Plane to Virtual Machines | Bounded self and fleet resource reads | 10 ms monthly p99 | at most 100 returned resources and at most 20 filters. | 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. |
| EC2 Control Plane | EC2 Control Plane to Virtual Machines | Instance and volume lifecycle admission | 20 ms monthly p99 | at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EC2 Control Plane | EC2 Control Plane to Virtual Machines | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EC2 Control Plane | EC2 Control Plane to Virtual Machines | Documented adapter behavior | Preserve the supported behavior documented for this adapter | IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes. | |
| EC2 Control Plane | EC2 Control Plane to Virtual Machines | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EC2 Control Plane | EC2 Control Plane to Virtual Machines | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| ECS | ECS Cluster to AKS Cluster | Cluster, workload and identity reads | 8 ms monthly p99 | One point read or at most 100 returned resources; manifest/status at most 1 MiB. | 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. |
| ECS | ECS Cluster to AKS Cluster | Cluster and workload desired-state admission | 20 ms monthly p99 | One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| ECS | ECS Cluster to AKS Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| ECS | ECS Cluster to AKS Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | |
| ECS | ECS Cluster to AKS Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| ECS | ECS Cluster to AKS Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| ECS | ECS Cluster to GKE Cluster | Cluster, workload and identity reads | 8 ms monthly p99 | One point read or at most 100 returned resources; manifest/status at most 1 MiB. | 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. |
| ECS | ECS Cluster to GKE Cluster | Cluster and workload desired-state admission | 20 ms monthly p99 | One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| ECS | ECS Cluster to GKE Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| ECS | ECS Cluster to GKE Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | |
| ECS | ECS Cluster to GKE Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| ECS | ECS Cluster to GKE Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| ECS | ECS Cluster to Kubernetes Cluster | Cluster, workload and identity reads | 8 ms monthly p99 | One point read or at most 100 returned resources; manifest/status at most 1 MiB. | 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. |
| ECS | ECS Cluster to Kubernetes Cluster | Cluster and workload desired-state admission | 20 ms monthly p99 | One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| ECS | ECS Cluster to Kubernetes Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| ECS | ECS Cluster to Kubernetes Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | |
| ECS | ECS Cluster to Kubernetes Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| ECS | ECS Cluster to Kubernetes Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| ECS | ECS Cluster to OKE Cluster | Cluster, workload and identity reads | 8 ms monthly p99 | One point read or at most 100 returned resources; manifest/status at most 1 MiB. | 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. |
| ECS | ECS Cluster to OKE Cluster | Cluster and workload desired-state admission | 20 ms monthly p99 | One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| ECS | ECS Cluster to OKE Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| ECS | ECS Cluster to OKE Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | |
| ECS | ECS Cluster to OKE Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| ECS | ECS Cluster to OKE Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| ECS | ECS Cluster to Scaleway Kapsule Cluster | Cluster and workload desired-state admission | 20 ms monthly p99 | One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness separate. | 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. |
| ECS | ECS Cluster to Scaleway Kapsule Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| ECS | ECS Cluster to Scaleway Kapsule Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| ECS | ECS Cluster to Scaleway Kapsule Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| ECS | ECS Cluster to Scaleway Kapsule Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EKS | EKS Cluster to AKS Cluster | Cluster, workload and identity reads | 8 ms monthly p99 | One point read or at most 100 returned resources; manifest/status at most 1 MiB. | 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. |
| EKS | EKS Cluster to AKS Cluster | Cluster and workload desired-state admission | 20 ms monthly p99 | One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EKS | EKS Cluster to AKS Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EKS | EKS Cluster to AKS Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | |
| EKS | EKS Cluster to AKS Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EKS | EKS Cluster to AKS Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EKS | EKS Cluster to GKE Cluster | Cluster, workload and identity reads | 8 ms monthly p99 | One point read or at most 100 returned resources; manifest/status at most 1 MiB. | 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. |
| EKS | EKS Cluster to GKE Cluster | Cluster and workload desired-state admission | 20 ms monthly p99 | One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EKS | EKS Cluster to GKE Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EKS | EKS Cluster to GKE Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | |
| EKS | EKS Cluster to GKE Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EKS | EKS Cluster to GKE Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EKS | EKS Cluster to Kubernetes Cluster | Not applicable | No numerical term | Applications use the target cluster’s Kubernetes API directly. This mapping does not expose an EKS management adapter endpoint. Kubernetes API availability and pod scheduling are not measured as service-adapter request latency. | |
| EKS | EKS Cluster to OKE Cluster | Cluster, workload and identity reads | 8 ms monthly p99 | One point read or at most 100 returned resources; manifest/status at most 1 MiB. | 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. |
| EKS | EKS Cluster to OKE Cluster | Cluster and workload desired-state admission | 20 ms monthly p99 | One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EKS | EKS Cluster to OKE Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EKS | EKS Cluster to OKE Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | |
| EKS | EKS Cluster to OKE Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EKS | EKS Cluster to OKE Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EKS | EKS Cluster to Scaleway Kapsule Cluster | Not applicable | No numerical term | Applications use the target cluster’s Kubernetes API directly. This mapping does not expose an EKS management adapter endpoint. Kubernetes API availability and pod scheduling are not measured as service-adapter request latency. | |
| EKS IRSA | EKS IRSA to Cedar | Workload identity binding | 10 ms monthly p99 | One association or at most 100 returned associations; token at most 16 KiB. | 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. |
| EKS IRSA | EKS IRSA to Cedar | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EKS IRSA | EKS IRSA to Cedar | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EKS IRSA | EKS IRSA to Cedar | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EKS IRSA | EKS IRSA to Cedar | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EKS IRSA | EKS IRSA to IAM | Not applicable | No numerical term | This mapping provisions native target-cloud permissions. Application authorization uses the target cloud’s identity system; requests do not pass through an IAM service adapter. The IAM-to-Cedar adapter has separate service levels. | |
| EKS Pod Identity | EKS Pod Identity to Cedar | Workload identity binding | 10 ms monthly p99 | One association or at most 100 returned associations; token at most 16 KiB. | 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. |
| EKS Pod Identity | EKS Pod Identity to Cedar | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EKS Pod Identity | EKS Pod Identity to Cedar | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EKS Pod Identity | EKS Pod Identity to Cedar | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EKS Pod Identity | EKS Pod Identity to Cedar | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EKS Pod Identity | EKS Pod Identity to IAM | Not applicable | No numerical term | This mapping provisions native target-cloud permissions. Application authorization uses the target cloud’s identity system; requests do not pass through an IAM service adapter. The IAM-to-Cedar adapter has separate service levels. | |
| EventBridge | EventBridge to Azure Event Grid | Not applicable | No numerical term | This mapping uses native Event Grid delivery rather than an EventBridge API endpoint. Event delivery follows the target service’s behavior; there is no EventBridge adapter request to measure. | |
| EventBridge | EventBridge to Cloud SQL for PostgreSQL | Bounded event acceptance and matching | 25 ms monthly p99 | At most 10 events and 40 KiB aggregate detail; at most 20 enabled rules per bus, 20 clauses per pattern and five targets per matching rule. Measures PutEvents acceptance, not destination completion. | 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. |
| EventBridge | EventBridge to Cloud SQL for PostgreSQL | Bus, rule and target configuration | 20 ms monthly p99 | One bus or rule, at most five targets and 32 KiB configuration, or a page of at most 100 records. Supported schedule syntax only; configuration response latency is not scheduled firing accuracy. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EventBridge | EventBridge to Cloud SQL for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EventBridge | EventBridge to Cloud SQL for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | PutEvents must retain per-entry failure reporting. Accepted delivery work must survive an adapter restart according to the documented durable-store design. A destination can receive duplicates if it accepts a call just before the worker loses its acknowledgement. Input selection, pattern matching, target permissions and schedule syntax must follow the profile. The latency row does not promise exactly-once delivery, arbitrary cron precision or end-to-end delivery within 25 ms. | |
| EventBridge | EventBridge to Cloud SQL for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EventBridge | EventBridge to Cloud SQL for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EventBridge | EventBridge to Container Apps | Not applicable | No numerical term | Scheduled jobs run as Container Apps jobs. This mapping does not expose an event bus or a PutEvents adapter endpoint; job execution is not fabric request latency. | |
| EventBridge | EventBridge to PostgreSQL | Bounded event acceptance and matching | 25 ms monthly p99 | At most 10 events and 40 KiB aggregate detail; at most 20 enabled rules per bus, 20 clauses per pattern and five targets per matching rule. Measures PutEvents acceptance, not destination completion. | 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. |
| EventBridge | EventBridge to PostgreSQL | Bus, rule and target configuration | 20 ms monthly p99 | One bus or rule, at most five targets and 32 KiB configuration, or a page of at most 100 records. Supported schedule syntax only; configuration response latency is not scheduled firing accuracy. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EventBridge | EventBridge to PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EventBridge | EventBridge to PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | PutEvents must retain per-entry failure reporting. Accepted delivery work must survive an adapter restart according to the documented durable-store design. A destination can receive duplicates if it accepts a call just before the worker loses its acknowledgement. Input selection, pattern matching, target permissions and schedule syntax must follow the profile. The latency row does not promise exactly-once delivery, arbitrary cron precision or end-to-end delivery within 25 ms. | |
| EventBridge | EventBridge to PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EventBridge | EventBridge to PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EventBridge | EventBridge to PostgreSQL Flexible Server | Bounded event acceptance and matching | 25 ms monthly p99 | At most 10 events and 40 KiB aggregate detail; at most 20 enabled rules per bus, 20 clauses per pattern and five targets per matching rule. Measures PutEvents acceptance, not destination completion. | 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. |
| EventBridge | EventBridge to PostgreSQL Flexible Server | Bus, rule and target configuration | 20 ms monthly p99 | One bus or rule, at most five targets and 32 KiB configuration, or a page of at most 100 records. Supported schedule syntax only; configuration response latency is not scheduled firing accuracy. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| EventBridge | EventBridge to PostgreSQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| EventBridge | EventBridge to PostgreSQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | PutEvents must retain per-entry failure reporting. Accepted delivery work must survive an adapter restart according to the documented durable-store design. A destination can receive duplicates if it accepts a call just before the worker loses its acknowledgement. Input selection, pattern matching, target permissions and schedule syntax must follow the profile. The latency row does not promise exactly-once delivery, arbitrary cron precision or end-to-end delivery within 25 ms. | |
| EventBridge | EventBridge to PostgreSQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| EventBridge | EventBridge to PostgreSQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| EventBridge | EventBridge to Pub/Sub | Not applicable | No numerical term | This mapping uses native Pub/Sub delivery rather than an EventBridge API endpoint. Event delivery follows the target service’s behavior; there is no EventBridge adapter request to measure. | |
| IAM | IAM to Cedar | IAM administration request fulfillment | 99.9% per calendar month | Only the 50 listed IAM administration operations, using supported request options. Measure each operation separately. | What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met. |
| IAM | IAM to Cedar | STS request fulfillment | 99.9% per calendar month | Only the three listed STS operations, using supported request options. Measure each operation separately. | Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA. |
| IAM | IAM to Cedar | Availability of in-adapter permission checks | 99.9% per calendar month | Only the authorization checks and operations listed in the agreement. A correct allow or deny is a successful check. If the adapter cannot access usable policies, that counts as an adapter failure. | Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment. |
| IAM | IAM to Cedar | Reachability | 99.9% per calendar month | Tests whether the covered IAM, STS and authorization services can be reached, separately from whether they handle requests correctly. | |
| IAM | IAM to Cedar | Time for an in-adapter permission check | 5 ms monthly p99 | Request context ≤4 KiB; ≤1,000 relevant policies and ≤1,000 entities; total policy/entity data ≤1 MiB. Policy complexity must stay within the limits in your agreement. | |
| IAM | IAM to Cedar | Administration latency | 20 ms monthly p99 | Only the 50 listed IAM operations. Request ≤16 KiB; response ≤64 KiB; each list page ≤100 entries. | |
| IAM | IAM to Cedar | GetCallerIdentity, AssumeRole, AssumeRoleWithWebIdentity latency | 50 ms monthly p99 | Request/input token ≤16 KiB. Use supported request options and token formats. | |
| IAM | IAM to Cedar | Authorization correctness | Never grant access because a check failed or is unsupported | An explicit deny overrides an allow; no matching allow means deny. Respect role/session permissions and expiry. Correct denials are successful checks; missing usable policies are failures. | |
| IAM | IAM to Cedar | Saving and applying policy updates | Save policies durably before confirming success | Check a complete policy update before installing it. Each adapter must switch to the full update at once, without mixing old and new policies. | |
| IAM | IAM to Cedar | Distributing policy updates | Updates reach other adapters, but no fixed deadline is promised | No fixed deadline for every adapter to receive a policy change or revoke access. One health check or Explain report cannot confirm that all adapters have updated. | |
| IAM | IAM to Cedar | Adapter autoscaling and limits | Automatic scaling within agreed traffic and deployment limits | Set separate limits for completed IAM operations, STS operations and authorization checks. Include policy/entity complexity, readiness to serve requests, policy-update traffic, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Target capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits. | |
| KMS | KMS Keys to Appliance-hosted software keys | Cryptographic operations | 5 ms monthly p99 | Input at most 64 KiB, at most 20 encryption-context entries, one key; provider crypto time separately spanned. | 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. |
| KMS | KMS Keys to Appliance-hosted software keys | Key metadata and bounded lists | 8 ms monthly p99 | at most 100 returned entries; policy at most 32 KiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| KMS | KMS Keys to Appliance-hosted software keys | Key, alias, policy and grant mutation | 15 ms monthly p99 | One key/alias/grant; at most 50 tags and grants; policy at most 32 KiB. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| KMS | KMS Keys to Appliance-hosted software keys | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| KMS | KMS Keys to Appliance-hosted software keys | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them. | |
| KMS | KMS Keys to Appliance-hosted software keys | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| KMS | KMS Keys to Appliance-hosted software keys | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| KMS | KMS Keys to Cloud KMS | Cryptographic operations | 5 ms monthly p99 | Input at most 64 KiB, at most 20 encryption-context entries, one key; provider crypto time separately spanned. | 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. |
| KMS | KMS Keys to Cloud KMS | Key metadata and bounded lists | 8 ms monthly p99 | at most 100 returned entries; policy at most 32 KiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| KMS | KMS Keys to Cloud KMS | Key, alias, policy and grant mutation | 15 ms monthly p99 | One key/alias/grant; at most 50 tags and grants; policy at most 32 KiB. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| KMS | KMS Keys to Cloud KMS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| KMS | KMS Keys to Cloud KMS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them. | |
| KMS | KMS Keys to Cloud KMS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| KMS | KMS Keys to Cloud KMS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| KMS | KMS Keys to HashiCorp Vault Transit | Cryptographic operations | 5 ms monthly p99 | Input at most 64 KiB, at most 20 encryption-context entries, one key; provider crypto time separately spanned. | 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. |
| KMS | KMS Keys to HashiCorp Vault Transit | Key metadata and bounded lists | 8 ms monthly p99 | at most 100 returned entries; policy at most 32 KiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| KMS | KMS Keys to HashiCorp Vault Transit | Key, alias, policy and grant mutation | 15 ms monthly p99 | One key/alias/grant; at most 50 tags and grants; policy at most 32 KiB. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| KMS | KMS Keys to HashiCorp Vault Transit | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| KMS | KMS Keys to HashiCorp Vault Transit | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them. | |
| KMS | KMS Keys to HashiCorp Vault Transit | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| KMS | KMS Keys to HashiCorp Vault Transit | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| KMS | KMS Keys to Key Vault | Cryptographic operations | 5 ms monthly p99 | Input at most 64 KiB, at most 20 encryption-context entries, one key; provider crypto time separately spanned. | 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. |
| KMS | KMS Keys to Key Vault | Key metadata and bounded lists | 8 ms monthly p99 | at most 100 returned entries; policy at most 32 KiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| KMS | KMS Keys to Key Vault | Key, alias, policy and grant mutation | 15 ms monthly p99 | One key/alias/grant; at most 50 tags and grants; policy at most 32 KiB. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| KMS | KMS Keys to Key Vault | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| KMS | KMS Keys to Key Vault | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them. | |
| KMS | KMS Keys to Key Vault | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| KMS | KMS Keys to Key Vault | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| KMS | KMS Keys to OCI KMS | Cryptographic operations | 5 ms monthly p99 | Input at most 64 KiB, at most 20 encryption-context entries, one key; provider crypto time separately spanned. | 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. |
| KMS | KMS Keys to OCI KMS | Key metadata and bounded lists | 8 ms monthly p99 | at most 100 returned entries; policy at most 32 KiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| KMS | KMS Keys to OCI KMS | Key, alias, policy and grant mutation | 15 ms monthly p99 | One key/alias/grant; at most 50 tags and grants; policy at most 32 KiB. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| KMS | KMS Keys to OCI KMS | Imported and replicated key coordination | 25 ms monthly p99 | One key and one bounded material/replica request; provider execution separately spanned. | |
| KMS | KMS Keys to OCI KMS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| KMS | KMS Keys to OCI KMS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them. | |
| KMS | KMS Keys to OCI KMS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| KMS | KMS Keys to OCI KMS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| KMS | KMS Keys to Scaleway Key Manager | Cryptographic operations | 5 ms monthly p99 | Input at most 64 KiB, at most 20 encryption-context entries, one key; provider crypto time separately spanned. | 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. |
| KMS | KMS Keys to Scaleway Key Manager | Key, alias, policy and grant mutation | 15 ms monthly p99 | One key/alias/grant; at most 50 tags and grants; policy at most 32 KiB. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| KMS | KMS Keys to Scaleway Key Manager | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| KMS | KMS Keys to Scaleway Key Manager | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them. | |
| KMS | KMS Keys to Scaleway Key Manager | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| KMS | KMS Keys to Scaleway Key Manager | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Azure Event Hubs | Small delivery-record acceptance | 3 ms monthly p99 | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | 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. |
| Kinesis Data Firehose | Kinesis Data Firehose to Azure Event Hubs | Bounded delivery-record batch acceptance | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion are separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Firehose | Kinesis Data Firehose to Azure Event Hubs | Delivery-stream configuration responses | 20 ms monthly p99 | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Firehose | Kinesis Data Firehose to Azure Event Hubs | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Azure Event Hubs | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Azure Event Hubs | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Azure Event Hubs | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Firehose | Kinesis Data Firehose to DigitalOcean Managed Kafka | Small delivery-record acceptance | 3 ms monthly p99 | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | 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. |
| Kinesis Data Firehose | Kinesis Data Firehose to DigitalOcean Managed Kafka | Bounded delivery-record batch acceptance | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion are separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Firehose | Kinesis Data Firehose to DigitalOcean Managed Kafka | Delivery-stream configuration responses | 20 ms monthly p99 | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Firehose | Kinesis Data Firehose to DigitalOcean Managed Kafka | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Firehose | Kinesis Data Firehose to DigitalOcean Managed Kafka | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | |
| Kinesis Data Firehose | Kinesis Data Firehose to DigitalOcean Managed Kafka | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Firehose | Kinesis Data Firehose to DigitalOcean Managed Kafka | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Firehose | Kinesis Data Firehose to OCI Streaming | Small delivery-record acceptance | 3 ms monthly p99 | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | 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. |
| Kinesis Data Firehose | Kinesis Data Firehose to OCI Streaming | Bounded delivery-record batch acceptance | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion are separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Firehose | Kinesis Data Firehose to OCI Streaming | Delivery-stream configuration responses | 20 ms monthly p99 | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Firehose | Kinesis Data Firehose to OCI Streaming | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Firehose | Kinesis Data Firehose to OCI Streaming | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | |
| Kinesis Data Firehose | Kinesis Data Firehose to OCI Streaming | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Firehose | Kinesis Data Firehose to OCI Streaming | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Pub/Sub | Small delivery-record acceptance | 3 ms monthly p99 | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | 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. |
| Kinesis Data Firehose | Kinesis Data Firehose to Pub/Sub | Bounded delivery-record batch acceptance | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion are separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Firehose | Kinesis Data Firehose to Pub/Sub | Delivery-stream configuration responses | 20 ms monthly p99 | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Firehose | Kinesis Data Firehose to Pub/Sub | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Pub/Sub | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Pub/Sub | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Pub/Sub | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Strimzi Kafka | Small delivery-record acceptance | 3 ms monthly p99 | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | 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. |
| Kinesis Data Firehose | Kinesis Data Firehose to Strimzi Kafka | Bounded delivery-record batch acceptance | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion are separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Firehose | Kinesis Data Firehose to Strimzi Kafka | Delivery-stream configuration responses | 20 ms monthly p99 | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Firehose | Kinesis Data Firehose to Strimzi Kafka | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Strimzi Kafka | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Strimzi Kafka | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Firehose | Kinesis Data Firehose to Strimzi Kafka | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Stream | Kinesis Data Stream to Azure Event Hubs | Small record append and iterator requests | 3 ms monthly p99 | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. | 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. |
| Kinesis Data Stream | Kinesis Data Stream to Azure Event Hubs | Bounded record batch and read page | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Stream | Kinesis Data Stream to Azure Event Hubs | Stream configuration requests | 20 ms monthly p99 | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Stream | Kinesis Data Stream to Azure Event Hubs | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Stream | Kinesis Data Stream to Azure Event Hubs | Documented adapter behavior | Preserve the supported behavior documented for this adapter | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities. | |
| Kinesis Data Stream | Kinesis Data Stream to Azure Event Hubs | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Stream | Kinesis Data Stream to Azure Event Hubs | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Stream | Kinesis Data Stream to DigitalOcean Managed Kafka | Small record append and iterator requests | 3 ms monthly p99 | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. | 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. |
| Kinesis Data Stream | Kinesis Data Stream to DigitalOcean Managed Kafka | Bounded record batch and read page | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Stream | Kinesis Data Stream to DigitalOcean Managed Kafka | Stream configuration requests | 20 ms monthly p99 | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Stream | Kinesis Data Stream to DigitalOcean Managed Kafka | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Stream | Kinesis Data Stream to DigitalOcean Managed Kafka | Documented adapter behavior | Preserve the supported behavior documented for this adapter | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities. | |
| Kinesis Data Stream | Kinesis Data Stream to DigitalOcean Managed Kafka | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Stream | Kinesis Data Stream to DigitalOcean Managed Kafka | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Stream | Kinesis Data Stream to Managed Service for Apache Kafka | Small record append and iterator requests | 3 ms monthly p99 | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. | 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. |
| Kinesis Data Stream | Kinesis Data Stream to Managed Service for Apache Kafka | Bounded record batch and read page | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Stream | Kinesis Data Stream to Managed Service for Apache Kafka | Stream configuration requests | 20 ms monthly p99 | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Stream | Kinesis Data Stream to Managed Service for Apache Kafka | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Stream | Kinesis Data Stream to Managed Service for Apache Kafka | Documented adapter behavior | Preserve the supported behavior documented for this adapter | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities. | |
| Kinesis Data Stream | Kinesis Data Stream to Managed Service for Apache Kafka | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Stream | Kinesis Data Stream to Managed Service for Apache Kafka | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Stream | Kinesis Data Stream to OCI Streaming | Small record append and iterator requests | 3 ms monthly p99 | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. | 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. |
| Kinesis Data Stream | Kinesis Data Stream to OCI Streaming | Bounded record batch and read page | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Stream | Kinesis Data Stream to OCI Streaming | Stream configuration requests | 20 ms monthly p99 | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Stream | Kinesis Data Stream to OCI Streaming | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Stream | Kinesis Data Stream to OCI Streaming | Documented adapter behavior | Preserve the supported behavior documented for this adapter | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities. | |
| Kinesis Data Stream | Kinesis Data Stream to OCI Streaming | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Stream | Kinesis Data Stream to OCI Streaming | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Stream | Kinesis Data Stream to Pub/Sub | Small record append and iterator requests | 3 ms monthly p99 | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. | 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. |
| Kinesis Data Stream | Kinesis Data Stream to Pub/Sub | Bounded record batch and read page | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Stream | Kinesis Data Stream to Pub/Sub | Stream configuration requests | 20 ms monthly p99 | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Stream | Kinesis Data Stream to Pub/Sub | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Stream | Kinesis Data Stream to Pub/Sub | Documented adapter behavior | Preserve the supported behavior documented for this adapter | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities. | |
| Kinesis Data Stream | Kinesis Data Stream to Pub/Sub | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Stream | Kinesis Data Stream to Pub/Sub | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Kinesis Data Stream | Kinesis Data Stream to Strimzi Kafka | Small record append and iterator requests | 3 ms monthly p99 | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. | 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. |
| Kinesis Data Stream | Kinesis Data Stream to Strimzi Kafka | Bounded record batch and read page | 10 ms monthly p99 | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Kinesis Data Stream | Kinesis Data Stream to Strimzi Kafka | Stream configuration requests | 20 ms monthly p99 | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Kinesis Data Stream | Kinesis Data Stream to Strimzi Kafka | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Kinesis Data Stream | Kinesis Data Stream to Strimzi Kafka | Documented adapter behavior | Preserve the supported behavior documented for this adapter | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities. | |
| Kinesis Data Stream | Kinesis Data Stream to Strimzi Kafka | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Kinesis Data Stream | Kinesis Data Stream to Strimzi Kafka | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to AKS function Deployments | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to AKS function Deployments | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to AKS function Deployments | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to AKS function Deployments | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to AKS function Deployments | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to Azure Container Apps | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to Azure Container Apps | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to Azure Container Apps | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to Azure Container Apps | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to Azure Container Apps | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to Azure Functions (Flex Consumption) | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to Azure Functions (Flex Consumption) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to Azure Functions (Flex Consumption) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to Azure Functions (Flex Consumption) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to Azure Functions (Flex Consumption) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to Azure Functions (Premium) | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to Azure Functions (Premium) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to Azure Functions (Premium) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to Azure Functions (Premium) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to Azure Functions (Premium) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to Cloud Run | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to Cloud Run | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to Cloud Run | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to Cloud Run | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to Cloud Run | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to Knative Service | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to Knative Service | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to Knative Service | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to Knative Service | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to Knative Service | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to Kubernetes Cluster | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to Kubernetes Cluster | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to Kubernetes Cluster | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to Kubernetes Cluster | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to Kubernetes Cluster | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to OCI Functions | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to OCI Functions | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to OCI Functions | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to OCI Functions | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to OCI Functions | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to OKE function Deployments | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to OKE function Deployments | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to OKE function Deployments | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to OKE function Deployments | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to OKE function Deployments | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Lambda | Lambda Function to Scaleway Serverless Containers | Unary function invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| Lambda | Lambda Function to Scaleway Serverless Containers | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Lambda | Lambda Function to Scaleway Serverless Containers | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Lambda | Lambda Function to Scaleway Serverless Containers | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Lambda | Lambda Function to Scaleway Serverless Containers | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Network Load Balancer | Network Load Balancer to Azure Load Balancer | Network and load-balancer state reads | 8 ms monthly p99 | One resource or at most 100 returned listeners, targets or rules. | 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. |
| Network Load Balancer | Network Load Balancer to Azure Load Balancer | Listener, target and topology mutation | 18 ms monthly p99 | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Network Load Balancer | Network Load Balancer to Azure Load Balancer | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Network Load Balancer | Network Load Balancer to Azure Load Balancer | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| Network Load Balancer | Network Load Balancer to Azure Load Balancer | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Network Load Balancer | Network Load Balancer to Azure Load Balancer | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Network Load Balancer | Network Load Balancer to Cloud Load Balancing | Network and load-balancer state reads | 8 ms monthly p99 | One resource or at most 100 returned listeners, targets or rules. | 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. |
| Network Load Balancer | Network Load Balancer to Cloud Load Balancing | Listener, target and topology mutation | 18 ms monthly p99 | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Network Load Balancer | Network Load Balancer to Cloud Load Balancing | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Network Load Balancer | Network Load Balancer to Cloud Load Balancing | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| Network Load Balancer | Network Load Balancer to Cloud Load Balancing | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Network Load Balancer | Network Load Balancer to Cloud Load Balancing | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Network Load Balancer | Network Load Balancer to DigitalOcean Load Balancer | Network and load-balancer state reads | 8 ms monthly p99 | One resource or at most 100 returned listeners, targets or rules. | 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. |
| Network Load Balancer | Network Load Balancer to DigitalOcean Load Balancer | Listener, target and topology mutation | 18 ms monthly p99 | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Network Load Balancer | Network Load Balancer to DigitalOcean Load Balancer | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Network Load Balancer | Network Load Balancer to DigitalOcean Load Balancer | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| Network Load Balancer | Network Load Balancer to DigitalOcean Load Balancer | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Network Load Balancer | Network Load Balancer to DigitalOcean Load Balancer | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Network Load Balancer | Network Load Balancer to OCI Network Load Balancer | Network and load-balancer state reads | 8 ms monthly p99 | One resource or at most 100 returned listeners, targets or rules. | 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. |
| Network Load Balancer | Network Load Balancer to OCI Network Load Balancer | Listener, target and topology mutation | 18 ms monthly p99 | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Network Load Balancer | Network Load Balancer to OCI Network Load Balancer | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Network Load Balancer | Network Load Balancer to OCI Network Load Balancer | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| Network Load Balancer | Network Load Balancer to OCI Network Load Balancer | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Network Load Balancer | Network Load Balancer to OCI Network Load Balancer | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Network Load Balancer | Network Load Balancer to Scaleway Load Balancer | Not applicable | No numerical term | This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply. | |
| RDS MySQL | RDS MySQL to Cloud SQL for MySQL | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS MySQL | RDS MySQL to Cloud SQL for MySQL | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS MySQL | RDS MySQL to Cloud SQL for MySQL | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS MySQL | RDS MySQL to Cloud SQL for MySQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS MySQL | RDS MySQL to Cloud SQL for MySQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS MySQL | RDS MySQL to Cloud SQL for MySQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS MySQL | RDS MySQL to Cloud SQL for MySQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS MySQL | RDS MySQL to DigitalOcean Managed MySQL | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS MySQL | RDS MySQL to DigitalOcean Managed MySQL | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS MySQL | RDS MySQL to DigitalOcean Managed MySQL | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS MySQL | RDS MySQL to DigitalOcean Managed MySQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS MySQL | RDS MySQL to DigitalOcean Managed MySQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS MySQL | RDS MySQL to DigitalOcean Managed MySQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS MySQL | RDS MySQL to DigitalOcean Managed MySQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS MySQL | RDS MySQL to MySQL Flexible Server | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS MySQL | RDS MySQL to MySQL Flexible Server | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS MySQL | RDS MySQL to MySQL Flexible Server | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS MySQL | RDS MySQL to MySQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS MySQL | RDS MySQL to MySQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS MySQL | RDS MySQL to MySQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS MySQL | RDS MySQL to MySQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS MySQL | RDS MySQL to OCI MySQL Database (HeatWave) | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS MySQL | RDS MySQL to OCI MySQL Database (HeatWave) | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS MySQL | RDS MySQL to OCI MySQL Database (HeatWave) | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS MySQL | RDS MySQL to OCI MySQL Database (HeatWave) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS MySQL | RDS MySQL to OCI MySQL Database (HeatWave) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS MySQL | RDS MySQL to OCI MySQL Database (HeatWave) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS MySQL | RDS MySQL to OCI MySQL Database (HeatWave) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS MySQL | RDS MySQL to Percona XtraDB Cluster (MySQL) | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS MySQL | RDS MySQL to Percona XtraDB Cluster (MySQL) | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS MySQL | RDS MySQL to Percona XtraDB Cluster (MySQL) | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS MySQL | RDS MySQL to Percona XtraDB Cluster (MySQL) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS MySQL | RDS MySQL to Percona XtraDB Cluster (MySQL) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS MySQL | RDS MySQL to Percona XtraDB Cluster (MySQL) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS MySQL | RDS MySQL to Percona XtraDB Cluster (MySQL) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS MySQL | RDS MySQL to Scaleway Managed Database for MySQL | Not applicable | No numerical term | This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA. | |
| RDS PostgreSQL | RDS PostgreSQL to Cloud SQL for PostgreSQL | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS PostgreSQL | RDS PostgreSQL to Cloud SQL for PostgreSQL | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS PostgreSQL | RDS PostgreSQL to Cloud SQL for PostgreSQL | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS PostgreSQL | RDS PostgreSQL to Cloud SQL for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS PostgreSQL | RDS PostgreSQL to Cloud SQL for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS PostgreSQL | RDS PostgreSQL to Cloud SQL for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS PostgreSQL | RDS PostgreSQL to Cloud SQL for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS PostgreSQL | RDS PostgreSQL to OCI Database with PostgreSQL | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS PostgreSQL | RDS PostgreSQL to OCI Database with PostgreSQL | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS PostgreSQL | RDS PostgreSQL to OCI Database with PostgreSQL | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS PostgreSQL | RDS PostgreSQL to OCI Database with PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS PostgreSQL | RDS PostgreSQL to OCI Database with PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS PostgreSQL | RDS PostgreSQL to OCI Database with PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS PostgreSQL | RDS PostgreSQL to OCI Database with PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL (CloudNativePG) | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL (CloudNativePG) | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL (CloudNativePG) | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL (CloudNativePG) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL (CloudNativePG) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL (CloudNativePG) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL (CloudNativePG) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL Flexible Server | Bounded database status responses | 20 ms monthly p99 | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | 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. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL Flexible Server | Database lifecycle request acceptance | 30 ms monthly p99 | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL Flexible Server | Bounded database parameter requests | 20 ms monthly p99 | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| RDS PostgreSQL | RDS PostgreSQL to PostgreSQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| RDS PostgreSQL | RDS PostgreSQL to Scaleway Managed Database for PostgreSQL | Not applicable | No numerical term | This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA. | |
| Route 53 | Route53 to Azure DNS | DNS management reads | 8 ms monthly p99 | One point read or at most 100 returned zones, records, checks, endpoints or rules. | 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. |
| Route 53 | Route53 to Azure DNS | Bounded zone and record mutation | 20 ms monthly p99 | One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Route 53 | Route53 to Azure DNS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Route 53 | Route53 to Azure DNS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior. | |
| Route 53 | Route53 to Azure DNS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Route 53 | Route53 to Azure DNS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Route 53 | Route53 to Cloud DNS | DNS management reads | 8 ms monthly p99 | One point read or at most 100 returned zones, records, checks, endpoints or rules. | 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. |
| Route 53 | Route53 to Cloud DNS | Bounded zone and record mutation | 20 ms monthly p99 | One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Route 53 | Route53 to Cloud DNS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Route 53 | Route53 to Cloud DNS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior. | |
| Route 53 | Route53 to Cloud DNS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Route 53 | Route53 to Cloud DNS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Route 53 | Route53 to Cloudflare DNS | DNS management reads | 8 ms monthly p99 | One point read or at most 100 returned zones, records, checks, endpoints or rules. | 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. |
| Route 53 | Route53 to Cloudflare DNS | Bounded zone and record mutation | 20 ms monthly p99 | One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Route 53 | Route53 to Cloudflare DNS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Route 53 | Route53 to Cloudflare DNS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior. | |
| Route 53 | Route53 to Cloudflare DNS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Route 53 | Route53 to Cloudflare DNS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Route 53 | Route53 to OCI DNS | DNS management reads | 8 ms monthly p99 | One point read or at most 100 returned zones, records, checks, endpoints or rules. | 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. |
| Route 53 | Route53 to OCI DNS | Bounded zone and record mutation | 20 ms monthly p99 | One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Route 53 | Route53 to OCI DNS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Route 53 | Route53 to OCI DNS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior. | |
| Route 53 | Route53 to OCI DNS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Route 53 | Route53 to OCI DNS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Route 53 | Route53 to Route 53 (any cloud) | DNS management reads | 8 ms monthly p99 | One point read or at most 100 returned zones, records, checks, endpoints or rules. | 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. |
| Route 53 | Route53 to Route 53 (any cloud) | Bounded zone and record mutation | 20 ms monthly p99 | One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Route 53 | Route53 to Route 53 (any cloud) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Route 53 | Route53 to Route 53 (any cloud) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior. | |
| Route 53 | Route53 to Route 53 (any cloud) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Route 53 | Route53 to Route 53 (any cloud) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Route 53 | Route53 to Scaleway Domains and DNS | Not applicable | No numerical term | DNS zones and records are provisioned through the target provider. This mapping has no Route 53 management adapter endpoint, and DNS lookups go directly to the provider’s name servers. | |
| S3 | S3 to Azure Blob Storage | Correct request handling | 99.9% per calendar month | Only the listed operations and supported request options. Larger requests are included for availability; the selected adapter’s documented limits still apply. | What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met. |
| S3 | S3 to Azure Blob Storage | Endpoint reachability | 99.9% per calendar month | Tests whether the endpoint can be reached, separately from whether requests complete correctly. | Covered S3 operations. Availability covers the operations with latency targets plus UploadPart, CopyObject, CreateMultipartUpload, AbortMultipartUpload, GetObjectTagging, PutObjectTagging, DeleteObjectTagging, CreateBucket, DeleteBucket and HeadBucket. Those additional operations have no latency target here. ListMultipartUploads and UploadPartCopy are not covered. Azure’s documented listing and version limits still apply; delimiter/CommonPrefixes requests are unsupported. A small range read must also fit the byte limit for all data the adapter reads or transfers. |
| S3 | S3 to Azure Blob Storage | GetObject, PutObject latency | 1 ms monthly p99 | Object ≤64 KiB; request metadata ≤8 KiB; bucket versioning disabled. Count all bytes the adapter reads or transfers, not just those returned to the application. Version bookkeeping needs a separate class. | Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA. |
| S3 | S3 to Azure Blob Storage | HeadObject, DeleteObject latency | 1 ms monthly p99 | Request and response metadata ≤8 KiB; delete targets an unversioned bucket and creates no delete marker. This limit does not restrict the stored object size. | Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment. |
| S3 | S3 to Azure Blob Storage | ListObjects, ListObjectsV2, ListObjectVersions, ListParts latency | 5 ms monthly p99 | One page with ≤1,000 entries or parts and ≤1 MiB of response data. The adapter’s documented listing and version limits still apply. | |
| S3 | S3 to Azure Blob Storage | DeleteObjects latency | 20 ms monthly p99 | ≤1,000 keys. Record the result for each key, including failures. | |
| S3 | S3 to Azure Blob Storage | CompleteMultipartUpload latency | 20 ms monthly p99 | ≤1,000 parts. Measure the time Azure spends committing blocks separately. | |
| S3 | S3 to Azure Blob Storage | Saving objects correctly | Save all required data before returning success | Keep object bytes, part order and required metadata intact. Reject unsupported request options and preserve the previous saved object if replacement fails. The provider’s own data-durability guarantee is separate. | |
| S3 | S3 to Azure Blob Storage | Adapter autoscaling and limits | Automatic scaling within agreed traffic and deployment limits | Agree limits for memory per request, bytes being transferred, copy bandwidth, work per object key, traffic growth and bursts, and spare capacity for failures. Adding adapter processes does not reduce the memory needed by one request. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Target capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits. | |
| S3 | S3 to DigitalOcean Spaces | Small object and metadata requests | 1 ms monthly p99 | One object; complete request and response bodies each at most 64 KiB, metadata at most 8 KiB. No archive restore or multipart completion. Larger streaming bodies need a byte-rate and completion budget in the agreement. | 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. |
| S3 | S3 to DigitalOcean Spaces | Bounded object copy | 3 ms monthly p99 | One source and destination, object at most 64 KiB, metadata at most 8 KiB. Only supported source conditions and ranges are covered. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| S3 | S3 to DigitalOcean Spaces | Bounded object and multipart listing | 3 ms monthly p99 | One page with at most 1,000 returned entries and 1 MiB of encoded response. No implicit traversal of later pages. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| S3 | S3 to DigitalOcean Spaces | Bounded multi-object deletion | 10 ms monthly p99 | At most 100 keys per request and at most 128 KiB of request and response metadata. Every key retains its individual success or error result. | |
| S3 | S3 to DigitalOcean Spaces | Multipart setup, parts and completion | 5 ms monthly p99 | At most 100 parts at completion; a part request carries at most 64 KiB for this latency class. The target’s supported multipart limits still apply. Larger parts are covered by a separately agreed streaming budget. | |
| S3 | S3 to DigitalOcean Spaces | Bucket configuration requests | 20 ms monthly p99 | One bucket; at most 32 KiB configuration and 50 policy or rule entries. Measures the API response, not asynchronous replication, lifecycle transitions or data migration. | |
| S3 | S3 to DigitalOcean Spaces | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| S3 | S3 to DigitalOcean Spaces | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful write must preserve the accepted bytes and supported metadata; a failed replacement must not be reported as successful. Version IDs, delete markers, conditional requests, ACLs and retention follow this directed profile, not an assumed universal S3 contract. Target storage durability remains the provider’s responsibility; Tensor9 is responsible for corrupting, misrouting or prematurely acknowledging a request in its own code. | |
| S3 | S3 to DigitalOcean Spaces | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| S3 | S3 to DigitalOcean Spaces | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| S3 | S3 to Google Cloud Storage | Correct request handling | 99.9% per calendar month | Only the listed operations and supported request options. Larger requests are included for availability; the selected adapter’s documented limits still apply. | What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met. |
| S3 | S3 to Google Cloud Storage | Endpoint reachability | 99.9% per calendar month | Tests whether the endpoint can be reached, separately from whether requests complete correctly. | Covered S3 operations. Availability covers the operations with latency targets plus UploadPart, CopyObject, CreateMultipartUpload, AbortMultipartUpload, GetObjectTagging, PutObjectTagging, DeleteObjectTagging, CreateBucket, DeleteBucket and HeadBucket. Those additional operations have no latency target here. ListMultipartUploads and UploadPartCopy are not covered. Azure’s documented listing and version limits still apply; delimiter/CommonPrefixes requests are unsupported. A small range read must also fit the byte limit for all data the adapter reads or transfers. |
| S3 | S3 to Google Cloud Storage | GetObject, PutObject latency | 1 ms monthly p99 | Object ≤64 KiB; request metadata ≤8 KiB; bucket versioning disabled. Count all bytes the adapter reads or transfers, not just those returned to the application. Version bookkeeping needs a separate class. | Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA. |
| S3 | S3 to Google Cloud Storage | HeadObject, DeleteObject latency | 1 ms monthly p99 | Request and response metadata ≤8 KiB; delete targets an unversioned bucket and creates no delete marker. This limit does not restrict the stored object size. | Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment. |
| S3 | S3 to Google Cloud Storage | ListObjects, ListObjectsV2, ListObjectVersions, ListParts latency | 5 ms monthly p99 | One page with ≤1,000 entries or parts and ≤1 MiB of response data. | |
| S3 | S3 to Google Cloud Storage | DeleteObjects latency | 20 ms monthly p99 | ≤1,000 keys. Record the result for each key, including failures. | |
| S3 | S3 to Google Cloud Storage | CompleteMultipartUpload latency | 20 ms monthly p99 | ≤1,000 parts. Measure the time GCS spends combining parts separately. | |
| S3 | S3 to Google Cloud Storage | Saving objects correctly | Save all required data before returning success | Keep object bytes, part order, required metadata and supported versions intact. A failed replacement must preserve the previous saved object. The provider’s own data-durability guarantee is separate. | |
| S3 | S3 to Google Cloud Storage | Adapter autoscaling and limits | Automatic scaling within agreed traffic and deployment limits | Agree limits for bytes, simultaneous transfers, target calls per request, shared metadata work, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Target capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits. | |
| S3 | S3 to MinIO Storage | Small object and metadata requests | 1 ms monthly p99 | One object; complete request and response bodies each at most 64 KiB, metadata at most 8 KiB. No archive restore or multipart completion. Larger streaming bodies need a byte-rate and completion budget in the agreement. | 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. |
| S3 | S3 to MinIO Storage | Object tagging | 3 ms monthly p99 | One object and at most 10 tags; total encoded tags at most 4 KiB. Only the tag characters and version-addressing forms listed by this target profile are covered. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| S3 | S3 to MinIO Storage | Bounded object copy | 3 ms monthly p99 | One source and destination, object at most 64 KiB, metadata at most 8 KiB. Only supported source conditions and ranges are covered. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| S3 | S3 to MinIO Storage | Bounded object and multipart listing | 3 ms monthly p99 | One page with at most 1,000 returned entries and 1 MiB of encoded response. No implicit traversal of later pages. | |
| S3 | S3 to MinIO Storage | Bounded multi-object deletion | 10 ms monthly p99 | At most 100 keys per request and at most 128 KiB of request and response metadata. Every key retains its individual success or error result. | |
| S3 | S3 to MinIO Storage | Multipart setup, parts and completion | 5 ms monthly p99 | At most 100 parts at completion; a part request carries at most 64 KiB for this latency class. The target’s supported multipart limits still apply. Larger parts are covered by a separately agreed streaming budget. | |
| S3 | S3 to MinIO Storage | Bucket configuration requests | 20 ms monthly p99 | One bucket; at most 32 KiB configuration and 50 policy or rule entries. Measures the API response, not asynchronous replication, lifecycle transitions or data migration. | |
| S3 | S3 to MinIO Storage | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| S3 | S3 to MinIO Storage | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful write must preserve the accepted bytes and supported metadata; a failed replacement must not be reported as successful. Version IDs, delete markers, conditional requests, ACLs and retention follow this directed profile, not an assumed universal S3 contract. Target storage durability remains the provider’s responsibility; Tensor9 is responsible for corrupting, misrouting or prematurely acknowledging a request in its own code. | |
| S3 | S3 to MinIO Storage | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| S3 | S3 to MinIO Storage | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| S3 | S3 to OCI Object Storage | Small object and metadata requests | 1 ms monthly p99 | One object; complete request and response bodies each at most 64 KiB, metadata at most 8 KiB. No archive restore or multipart completion. Larger streaming bodies need a byte-rate and completion budget in the agreement. | 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. |
| S3 | S3 to OCI Object Storage | Bounded object copy | 3 ms monthly p99 | One source and destination, object at most 64 KiB, metadata at most 8 KiB. Only supported source conditions and ranges are covered. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| S3 | S3 to OCI Object Storage | Bounded object and multipart listing | 3 ms monthly p99 | One page with at most 1,000 returned entries and 1 MiB of encoded response. No implicit traversal of later pages. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| S3 | S3 to OCI Object Storage | Bounded multi-object deletion | 10 ms monthly p99 | At most 100 keys per request and at most 128 KiB of request and response metadata. Every key retains its individual success or error result. | |
| S3 | S3 to OCI Object Storage | Multipart setup, parts and completion | 5 ms monthly p99 | At most 100 parts at completion; a part request carries at most 64 KiB for this latency class. The target’s supported multipart limits still apply. Larger parts are covered by a separately agreed streaming budget. | |
| S3 | S3 to OCI Object Storage | Bucket configuration requests | 20 ms monthly p99 | One bucket; at most 32 KiB configuration and 50 policy or rule entries. Measures the API response, not asynchronous replication, lifecycle transitions or data migration. | |
| S3 | S3 to OCI Object Storage | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| S3 | S3 to OCI Object Storage | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful write must preserve the accepted bytes and supported metadata; a failed replacement must not be reported as successful. Version IDs, delete markers, conditional requests, ACLs and retention follow this directed profile, not an assumed universal S3 contract. Target storage durability remains the provider’s responsibility; Tensor9 is responsible for corrupting, misrouting or prematurely acknowledging a request in its own code. | |
| S3 | S3 to OCI Object Storage | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| S3 | S3 to OCI Object Storage | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| S3 | S3 to Scaleway Object Storage | Small object and metadata requests | 1 ms monthly p99 | One object; complete request and response bodies each at most 64 KiB, metadata at most 8 KiB. No archive restore or multipart completion. Larger streaming bodies need a byte-rate and completion budget in the agreement. | 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. |
| S3 | S3 to Scaleway Object Storage | Bounded object copy | 3 ms monthly p99 | One source and destination, object at most 64 KiB, metadata at most 8 KiB. Only supported source conditions and ranges are covered. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| S3 | S3 to Scaleway Object Storage | Bounded object and multipart listing | 3 ms monthly p99 | One page with at most 1,000 returned entries and 1 MiB of encoded response. No implicit traversal of later pages. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| S3 | S3 to Scaleway Object Storage | Bounded multi-object deletion | 10 ms monthly p99 | At most 100 keys per request and at most 128 KiB of request and response metadata. Every key retains its individual success or error result. | |
| S3 | S3 to Scaleway Object Storage | Multipart setup, parts and completion | 5 ms monthly p99 | At most 100 parts at completion; a part request carries at most 64 KiB for this latency class. The target’s supported multipart limits still apply. Larger parts are covered by a separately agreed streaming budget. | |
| S3 | S3 to Scaleway Object Storage | Bucket configuration requests | 20 ms monthly p99 | One bucket; at most 32 KiB configuration and 50 policy or rule entries. Measures the API response, not asynchronous replication, lifecycle transitions or data migration. | |
| S3 | S3 to Scaleway Object Storage | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| S3 | S3 to Scaleway Object Storage | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful write must preserve the accepted bytes and supported metadata; a failed replacement must not be reported as successful. Version IDs, delete markers, conditional requests, ACLs and retention follow this directed profile, not an assumed universal S3 contract. Target storage durability remains the provider’s responsibility; Tensor9 is responsible for corrupting, misrouting or prematurely acknowledging a request in its own code. | |
| S3 | S3 to Scaleway Object Storage | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| S3 | S3 to Scaleway Object Storage | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| S3 Glacier | S3 Glacier to Scaleway Object Storage | Not applicable | No numerical term | This maps archive storage classes and lifecycle configuration. It is not a Glacier request-serving adapter or a promise about archive retrieval time. | |
| SNS | SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server | Bounded notification acceptance | 20 ms monthly p99 | One message at most 4 KiB, at most 20 subscriptions and 20 bounded filter clauses. Measures Publish acceptance, not downstream subscriber completion. | 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. |
| SNS | SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server | Bounded notification batch acceptance | 50 ms monthly p99 | At most 10 messages, 40 KiB aggregate bytes and 20 subscriptions per topic; per-entry results retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SNS | SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server | Topic and subscription configuration | 20 ms monthly p99 | One topic or subscription, at most 50 tags and 32 KiB settings. Subscribe and ConfirmSubscription retain their receiver-consent and protocol restrictions. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SNS | SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server | Bounded topic and subscription pages | 20 ms monthly p99 | One page with at most 100 entries and 128 KiB encoded response; no traversal of subsequent pages. | |
| SNS | SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SNS | SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row. | |
| SNS | SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SNS | SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SNS | SNS (Simple Notification Service) to Azure Service Bus Premium | Bounded notification acceptance | 3 ms monthly p99 | One message at most 4 KiB, at most 20 subscriptions and 20 bounded filter clauses. Measures Publish acceptance, not downstream subscriber completion. | 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. |
| SNS | SNS (Simple Notification Service) to Azure Service Bus Premium | Bounded notification batch acceptance | 10 ms monthly p99 | At most 10 messages, 40 KiB aggregate bytes and 20 subscriptions per topic; per-entry results retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SNS | SNS (Simple Notification Service) to Azure Service Bus Premium | Topic and subscription configuration | 20 ms monthly p99 | One topic or subscription, at most 50 tags and 32 KiB settings. Subscribe and ConfirmSubscription retain their receiver-consent and protocol restrictions. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SNS | SNS (Simple Notification Service) to Azure Service Bus Premium | Bounded topic and subscription pages | 20 ms monthly p99 | One page with at most 100 entries and 128 KiB encoded response; no traversal of subsequent pages. | |
| SNS | SNS (Simple Notification Service) to Azure Service Bus Premium | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SNS | SNS (Simple Notification Service) to Azure Service Bus Premium | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row. | |
| SNS | SNS (Simple Notification Service) to Azure Service Bus Premium | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SNS | SNS (Simple Notification Service) to Azure Service Bus Premium | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SNS | SNS (Simple Notification Service) to Google Cloud Pub/Sub | Bounded notification acceptance | 3 ms monthly p99 | One message at most 4 KiB, at most 20 subscriptions and 20 bounded filter clauses. Measures Publish acceptance, not downstream subscriber completion. | 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. |
| SNS | SNS (Simple Notification Service) to Google Cloud Pub/Sub | Bounded notification batch acceptance | 10 ms monthly p99 | At most 10 messages, 40 KiB aggregate bytes and 20 subscriptions per topic; per-entry results retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SNS | SNS (Simple Notification Service) to Google Cloud Pub/Sub | Topic and subscription configuration | 20 ms monthly p99 | One topic or subscription, at most 50 tags and 32 KiB settings. Subscribe and ConfirmSubscription retain their receiver-consent and protocol restrictions. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SNS | SNS (Simple Notification Service) to Google Cloud Pub/Sub | Bounded topic and subscription pages | 20 ms monthly p99 | One page with at most 100 entries and 128 KiB encoded response; no traversal of subsequent pages. | |
| SNS | SNS (Simple Notification Service) to Google Cloud Pub/Sub | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SNS | SNS (Simple Notification Service) to Google Cloud Pub/Sub | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row. | |
| SNS | SNS (Simple Notification Service) to Google Cloud Pub/Sub | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SNS | SNS (Simple Notification Service) to Google Cloud Pub/Sub | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SNS | SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL | Bounded notification acceptance | 20 ms monthly p99 | One message at most 4 KiB, at most 20 subscriptions and 20 bounded filter clauses. Measures Publish acceptance, not downstream subscriber completion. | 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. |
| SNS | SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL | Bounded notification batch acceptance | 50 ms monthly p99 | At most 10 messages, 40 KiB aggregate bytes and 20 subscriptions per topic; per-entry results retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SNS | SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL | Topic and subscription configuration | 20 ms monthly p99 | One topic or subscription, at most 50 tags and 32 KiB settings. Subscribe and ConfirmSubscription retain their receiver-consent and protocol restrictions. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SNS | SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL | Bounded topic and subscription pages | 20 ms monthly p99 | One page with at most 100 entries and 128 KiB encoded response; no traversal of subsequent pages. | |
| SNS | SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SNS | SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row. | |
| SNS | SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SNS | SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SNS | SNS (Simple Notification Service) to PostgreSQL | Bounded notification acceptance | 20 ms monthly p99 | One message at most 4 KiB, at most 20 subscriptions and 20 bounded filter clauses. Measures Publish acceptance, not downstream subscriber completion. | 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. |
| SNS | SNS (Simple Notification Service) to PostgreSQL | Bounded notification batch acceptance | 50 ms monthly p99 | At most 10 messages, 40 KiB aggregate bytes and 20 subscriptions per topic; per-entry results retained. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SNS | SNS (Simple Notification Service) to PostgreSQL | Topic and subscription configuration | 20 ms monthly p99 | One topic or subscription, at most 50 tags and 32 KiB settings. Subscribe and ConfirmSubscription retain their receiver-consent and protocol restrictions. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SNS | SNS (Simple Notification Service) to PostgreSQL | Bounded topic and subscription pages | 20 ms monthly p99 | One page with at most 100 entries and 128 KiB encoded response; no traversal of subsequent pages. | |
| SNS | SNS (Simple Notification Service) to PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SNS | SNS (Simple Notification Service) to PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row. | |
| SNS | SNS (Simple Notification Service) to PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SNS | SNS (Simple Notification Service) to PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Azure Service Bus | Small message send and settlement | 1 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Azure Service Bus | Bounded short-poll receive | 3 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Azure Service Bus | Bounded message batches | 10 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Azure Service Bus | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Azure Service Bus | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Azure Service Bus | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Azure Service Bus | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Azure Service Bus | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL | Small message send and settlement | 10 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL | Bounded short-poll receive | 10 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL | Bounded message batches | 100 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server | Small message send and settlement | 10 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server | Bounded short-poll receive | 10 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server | Bounded message batches | 100 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL | Small message send and settlement | 10 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL | Bounded short-poll receive | 10 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL | Bounded message batches | 100 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (FIFO) | SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Queue Storage | Small message send and settlement | 1 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Queue Storage | Bounded short-poll receive | 3 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Queue Storage | Bounded message batches | 10 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Queue Storage | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Queue Storage | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Queue Storage | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Queue Storage | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Queue Storage | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Service Bus | Small message send and settlement | 1 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Service Bus | Bounded short-poll receive | 3 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Service Bus | Bounded message batches | 10 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Service Bus | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Service Bus | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Service Bus | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Service Bus | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Azure Service Bus | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to OCI Queue | Small message send and settlement | 1 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to OCI Queue | Bounded short-poll receive | 3 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to OCI Queue | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to OCI Queue | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to OCI Queue | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to OCI Queue | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to OCI Queue | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL | Small message send and settlement | 3 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL | Bounded short-poll receive | 10 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL | Bounded message batches | 30 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL Flexible Server | Small message send and settlement | 3 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL Flexible Server | Bounded short-poll receive | 10 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL Flexible Server | Bounded message batches | 30 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL Flexible Server | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to PostgreSQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Pub/Sub | Small message send and settlement | 1 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Pub/Sub | Bounded short-poll receive | 3 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Pub/Sub | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Pub/Sub | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Pub/Sub | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Pub/Sub | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Pub/Sub | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Managed Database for PostgreSQL | Small message send and settlement | 3 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Managed Database for PostgreSQL | Bounded short-poll receive | 10 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Managed Database for PostgreSQL | Bounded message batches | 30 ms monthly p99 | At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Managed Database for PostgreSQL | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Managed Database for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Managed Database for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Managed Database for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Managed Database for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Queues (SQS-compatible) | Small message send and settlement | 1 ms monthly p99 | One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class. | 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. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Queues (SQS-compatible) | Bounded short-poll receive | 3 ms monthly p99 | WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Queues (SQS-compatible) | Queue configuration and discovery | 20 ms monthly p99 | One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Queues (SQS-compatible) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Queues (SQS-compatible) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Queues (SQS-compatible) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SQS (Standard) | SQS (Simple Queue Service, standard queues) to Scaleway Queues (SQS-compatible) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | Correct request handling | 99.9% per calendar month | Only the operations listed in this adapter’s latency rows, using supported request options. Measure each queue type separately. | What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met. |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | Endpoint reachability | 99.9% per calendar month | Tests whether the endpoint can be reached, separately from whether requests complete correctly. Measure each queue type separately. | How queue timing works. Time spent waiting for a message in an empty queue does not count as adapter delay. Adapter delays after a message becomes available, or after the requested wait ends, do count. The message-pickup target is not a deadline for clearing a backlog. Measure Standard and FIFO queues separately, and check each batch entry’s result. Empty receives and internal retries do not count as successfully delivered messages. |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | SendMessage, DeleteMessage, ChangeMessageVisibility latency | 10 ms monthly p99 | Message body ≤1 KiB and attributes ≤1 KiB. Use supported request options. | Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA. |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | SendMessageBatch, DeleteMessageBatch latency | 100 ms monthly p99 | ≤10 entries, each within the body, attribute and API limits. | Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment. |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | ReceiveMessage: ready-message pickup | 250 ms monthly p99 | One available message and one waiting request for a single message; body/attributes ≤1 KiB. No competing backlog, receiver, or earlier FIFO message blocking delivery. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | ReceiveMessage: delay after the requested wait | 250 ms monthly p99 | Count adapter delay after the requested waiting period ends, not the time spent waiting for a message. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | Saving messages and completed processing | Save the required data durably before returning success | Preserve confirmed sends, message visibility, expiration, completed processing and dead-letter handling after a failure. This is not a guarantee of the provider’s storage-durability percentage. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | Delivery, ordering and deduplication | Delivery behavior as documented for this adapter | Standard queues may deliver a message again. FIFO preserves the documented order and duplicate handling within each message group. Your application must still handle retries without repeating business actions. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cloud SQL PostgreSQL (SQS (Standard)) SQS to Cloud SQL PostgreSQL (SQS (FIFO)) | Adapter autoscaling and limits | Automatic scaling within agreed traffic and deployment limits | Set separate limits for Standard and FIFO queues. Include completed send/receive/delete cycles, message sizes and attributes, total connections, message claims and locks, FIFO groups, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Target capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | Correct request handling | 99.9% per calendar month | Only the operations listed in this adapter’s latency rows, using supported request options. Measure each queue type separately. | What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met. |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | Endpoint reachability | 99.9% per calendar month | Tests whether the endpoint can be reached, separately from whether requests complete correctly. Measure each queue type separately. | How queue timing works. Time spent waiting for a message in an empty queue does not count as adapter delay. Adapter delays after a message becomes available, or after the requested wait ends, do count. The message-pickup target is not a deadline for clearing a backlog. Measure Standard and FIFO queues separately, and check each batch entry’s result. Empty receives and internal retries do not count as successfully delivered messages. |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | SendMessage, DeleteMessage, ChangeMessageVisibility latency | 20 ms monthly p99 | Message body ≤1 KiB and attributes ≤1 KiB. Use supported request options. | Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA. |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | SendMessageBatch latency | 200 ms monthly p99 | ≤10 entries, each within the body, attribute and API limits. DeleteMessageBatch is not covered. | Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment. |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | ReceiveMessage: ready-message pickup | 500 ms monthly p99 | One available message and one waiting request for a single message; body/attributes ≤1 KiB. No competing backlog, receiver, or earlier FIFO message blocking delivery. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | ReceiveMessage: delay after the requested wait | 500 ms monthly p99 | Count adapter delay after the requested waiting period ends, not the time spent waiting for a message. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | Saving messages and completed processing | Save the required data durably before returning success | Safely assign messages to receivers and preserve visibility, expiration, completed processing and dead-letter handling after a failure. The adapter must not lose accepted messages. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | Delivery, ordering and deduplication | Delivery behavior as documented for this adapter | Standard queues may deliver a message again. FIFO preserves the documented order and duplicate handling within each message group. Your application must still handle retries without repeating business actions. | |
| SQS (Standard) / SQS (FIFO) | SQS to Cosmos DB (SQS (Standard)) SQS to Cosmos DB (SQS (FIFO)) | Adapter autoscaling and limits | Automatic scaling within agreed traffic and deployment limits | Set separate limits for Standard and FIFO queues. Include completed send/receive/delete cycles, message sizes and attributes, partitions, conditional message claims, FIFO groups, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Target capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits. | |
| SageMaker (Inference) | SageMaker to Your inference container | Endpoint invocation translation | 5 ms monthly p99 | Request and response each at most 64 KiB; inference time separately spanned; larger bodies use a separately qualified byte-throughput budget. | 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. |
| SageMaker (Inference) | SageMaker to Your inference container | Endpoint configuration mutation | 20 ms monthly p99 | One endpoint/model and at most 20 variants/containers; propagation readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| SageMaker (Inference) | SageMaker to Your inference container | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| SageMaker (Inference) | SageMaker to Your inference container | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The selected endpoint, variant, content types and custom attributes are preserved. A successful control mutation records complete desired state; a successful invocation returns exactly the target result or a typed failure. The adapter never routes to a different model merely to satisfy latency. | |
| SageMaker (Inference) | SageMaker to Your inference container | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| SageMaker (Inference) | SageMaker to Your inference container | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Secrets Manager | Secrets Manager to Key Vault | Secret point reads | 4 ms monthly p99 | Secret value at most 64 KiB; one secret/version; policy at most 32 KiB. | 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. |
| Secrets Manager | Secrets Manager to Key Vault | Bounded secret lists | 12 ms monthly p99 | at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Secrets Manager | Secrets Manager to Key Vault | Secret and policy mutation | 12 ms monthly p99 | One secret; value at most 64 KiB; at most 20 stages and tags. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Secrets Manager | Secrets Manager to Key Vault | Rotation and replication coordination | 25 ms monthly p99 | One secret and at most 5 replicas; callback/provider execution excluded by spans. | |
| Secrets Manager | Secrets Manager to Key Vault | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Secrets Manager | Secrets Manager to Key Vault | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version. | |
| Secrets Manager | Secrets Manager to Key Vault | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Secrets Manager | Secrets Manager to Key Vault | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Secrets Manager | Secrets Manager to Kubernetes Secret | Secret point reads | 4 ms monthly p99 | Secret value at most 64 KiB; one secret/version; policy at most 32 KiB. | 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. |
| Secrets Manager | Secrets Manager to Kubernetes Secret | Bounded secret lists | 12 ms monthly p99 | at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Secrets Manager | Secrets Manager to Kubernetes Secret | Secret and policy mutation | 12 ms monthly p99 | One secret; value at most 64 KiB; at most 20 stages and tags. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Secrets Manager | Secrets Manager to Kubernetes Secret | Rotation and replication coordination | 25 ms monthly p99 | One secret and at most 5 replicas; callback/provider execution excluded by spans. | |
| Secrets Manager | Secrets Manager to Kubernetes Secret | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Secrets Manager | Secrets Manager to Kubernetes Secret | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version. | |
| Secrets Manager | Secrets Manager to Kubernetes Secret | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Secrets Manager | Secrets Manager to Kubernetes Secret | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Secrets Manager | Secrets Manager to Kubernetes Secrets | Secret point reads | 4 ms monthly p99 | Secret value at most 64 KiB; one secret/version; policy at most 32 KiB. | 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. |
| Secrets Manager | Secrets Manager to Kubernetes Secrets | Bounded secret lists | 12 ms monthly p99 | at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Secrets Manager | Secrets Manager to Kubernetes Secrets | Secret and policy mutation | 12 ms monthly p99 | One secret; value at most 64 KiB; at most 20 stages and tags. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Secrets Manager | Secrets Manager to Kubernetes Secrets | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Secrets Manager | Secrets Manager to Kubernetes Secrets | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version. | |
| Secrets Manager | Secrets Manager to Kubernetes Secrets | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Secrets Manager | Secrets Manager to Kubernetes Secrets | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Secrets Manager | Secrets Manager to OCI Vault | Secret point reads | 4 ms monthly p99 | Secret value at most 64 KiB; one secret/version; policy at most 32 KiB. | 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. |
| Secrets Manager | Secrets Manager to OCI Vault | Bounded secret lists | 12 ms monthly p99 | at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Secrets Manager | Secrets Manager to OCI Vault | Secret and policy mutation | 12 ms monthly p99 | One secret; value at most 64 KiB; at most 20 stages and tags. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Secrets Manager | Secrets Manager to OCI Vault | Rotation and replication coordination | 25 ms monthly p99 | One secret and at most 5 replicas; callback/provider execution excluded by spans. | |
| Secrets Manager | Secrets Manager to OCI Vault | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Secrets Manager | Secrets Manager to OCI Vault | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version. | |
| Secrets Manager | Secrets Manager to OCI Vault | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Secrets Manager | Secrets Manager to OCI Vault | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Secrets Manager | Secrets Manager to Scaleway Secret Manager | Secret point reads | 4 ms monthly p99 | Secret value at most 64 KiB; one secret/version; policy at most 32 KiB. | 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. |
| Secrets Manager | Secrets Manager to Scaleway Secret Manager | Bounded secret lists | 12 ms monthly p99 | at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Secrets Manager | Secrets Manager to Scaleway Secret Manager | Secret and policy mutation | 12 ms monthly p99 | One secret; value at most 64 KiB; at most 20 stages and tags. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Secrets Manager | Secrets Manager to Scaleway Secret Manager | Rotation and replication coordination | 25 ms monthly p99 | One secret and at most 5 replicas; callback/provider execution excluded by spans. | |
| Secrets Manager | Secrets Manager to Scaleway Secret Manager | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Secrets Manager | Secrets Manager to Scaleway Secret Manager | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version. | |
| Secrets Manager | Secrets Manager to Scaleway Secret Manager | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Secrets Manager | Secrets Manager to Scaleway Secret Manager | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Secrets Manager | Secrets Manager to Secret Manager | Secret point reads | 4 ms monthly p99 | Secret value at most 64 KiB; one secret/version; policy at most 32 KiB. | 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. |
| Secrets Manager | Secrets Manager to Secret Manager | Bounded secret lists | 12 ms monthly p99 | at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Secrets Manager | Secrets Manager to Secret Manager | Secret and policy mutation | 12 ms monthly p99 | One secret; value at most 64 KiB; at most 20 stages and tags. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Secrets Manager | Secrets Manager to Secret Manager | Rotation and replication coordination | 25 ms monthly p99 | One secret and at most 5 replicas; callback/provider execution excluded by spans. | |
| Secrets Manager | Secrets Manager to Secret Manager | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Secrets Manager | Secrets Manager to Secret Manager | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version. | |
| Secrets Manager | Secrets Manager to Secret Manager | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Secrets Manager | Secrets Manager to Secret Manager | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Step Functions | Step Functions to Azure Durable Functions | Workflow and execution reads | 8 ms monthly p99 | at most 100 returned records/history events and at most 1 MiB payload. | 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. |
| Step Functions | Step Functions to Azure Durable Functions | Definition, version, alias and tag mutation | 15 ms monthly p99 | Definition at most 1 MiB and at most 100 states; one named resource. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Step Functions | Step Functions to Azure Durable Functions | Execution and task coordination | 12 ms monthly p99 | Payload at most 256 KiB; one execution/task token; customer task execution excluded. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Step Functions | Step Functions to Azure Durable Functions | Activity poll processing | 5 ms monthly p99 | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. | |
| Step Functions | Step Functions to Azure Durable Functions | Bounded synchronous workflow processing | 25 ms monthly p99 | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. | |
| Step Functions | Step Functions to Azure Durable Functions | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Step Functions | Step Functions to Azure Durable Functions | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. | |
| Step Functions | Step Functions to Azure Durable Functions | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Step Functions | Step Functions to Azure Durable Functions | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Step Functions | Step Functions to Cloud Workflows | Workflow and execution reads | 8 ms monthly p99 | at most 100 returned records/history events and at most 1 MiB payload. | 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. |
| Step Functions | Step Functions to Cloud Workflows | Definition, version, alias and tag mutation | 15 ms monthly p99 | Definition at most 1 MiB and at most 100 states; one named resource. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Step Functions | Step Functions to Cloud Workflows | Execution and task coordination | 12 ms monthly p99 | Payload at most 256 KiB; one execution/task token; customer task execution excluded. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Step Functions | Step Functions to Cloud Workflows | Activity poll processing | 5 ms monthly p99 | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. | |
| Step Functions | Step Functions to Cloud Workflows | Bounded synchronous workflow processing | 25 ms monthly p99 | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. | |
| Step Functions | Step Functions to Cloud Workflows | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Step Functions | Step Functions to Cloud Workflows | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. | |
| Step Functions | Step Functions to Cloud Workflows | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Step Functions | Step Functions to Cloud Workflows | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Workflow and execution reads | 8 ms monthly p99 | at most 100 returned records/history events and at most 1 MiB payload. | 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. |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Definition, version, alias and tag mutation | 15 ms monthly p99 | Definition at most 1 MiB and at most 100 states; one named resource. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Execution and task coordination | 12 ms monthly p99 | Payload at most 256 KiB; one execution/task token; customer task execution excluded. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Activity poll processing | 5 ms monthly p99 | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. | |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Bounded synchronous workflow processing | 25 ms monthly p99 | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. | |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. | |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Step Functions | Step Functions to Temporal (Self-Hosted) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Workflow and execution reads | 8 ms monthly p99 | at most 100 returned records/history events and at most 1 MiB payload. | 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. |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Definition, version, alias and tag mutation | 15 ms monthly p99 | Definition at most 1 MiB and at most 100 states; one named resource. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Execution and task coordination | 12 ms monthly p99 | Payload at most 256 KiB; one execution/task token; customer task execution excluded. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Activity poll processing | 5 ms monthly p99 | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. | |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Bounded synchronous workflow processing | 25 ms monthly p99 | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. | |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. | |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Step Functions | Step Functions to Temporal Cloud (Managed) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Step Functions State Machine | Step Functions State Machine to Azure Durable Functions | Workflow and execution reads | 8 ms monthly p99 | at most 100 returned records/history events and at most 1 MiB payload. | 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. |
| Step Functions State Machine | Step Functions State Machine to Azure Durable Functions | Definition, version, alias and tag mutation | 15 ms monthly p99 | Definition at most 1 MiB and at most 100 states; one named resource. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Step Functions State Machine | Step Functions State Machine to Azure Durable Functions | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Step Functions State Machine | Step Functions State Machine to Azure Durable Functions | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. | |
| Step Functions State Machine | Step Functions State Machine to Azure Durable Functions | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Step Functions State Machine | Step Functions State Machine to Azure Durable Functions | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Step Functions State Machine | Step Functions State Machine to Cloud Workflows | Workflow and execution reads | 8 ms monthly p99 | at most 100 returned records/history events and at most 1 MiB payload. | 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. |
| Step Functions State Machine | Step Functions State Machine to Cloud Workflows | Definition, version, alias and tag mutation | 15 ms monthly p99 | Definition at most 1 MiB and at most 100 states; one named resource. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Step Functions State Machine | Step Functions State Machine to Cloud Workflows | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Step Functions State Machine | Step Functions State Machine to Cloud Workflows | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. | |
| Step Functions State Machine | Step Functions State Machine to Cloud Workflows | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Step Functions State Machine | Step Functions State Machine to Cloud Workflows | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Step Functions State Machine | Step Functions State Machine to Temporal (Self-Hosted) | Workflow and execution reads | 8 ms monthly p99 | at most 100 returned records/history events and at most 1 MiB payload. | 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. |
| Step Functions State Machine | Step Functions State Machine to Temporal (Self-Hosted) | Definition, version, alias and tag mutation | 15 ms monthly p99 | Definition at most 1 MiB and at most 100 states; one named resource. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Step Functions State Machine | Step Functions State Machine to Temporal (Self-Hosted) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Step Functions State Machine | Step Functions State Machine to Temporal (Self-Hosted) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. | |
| Step Functions State Machine | Step Functions State Machine to Temporal (Self-Hosted) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Step Functions State Machine | Step Functions State Machine to Temporal (Self-Hosted) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Step Functions State Machine | Step Functions State Machine to Temporal Cloud (Managed) | Workflow and execution reads | 8 ms monthly p99 | at most 100 returned records/history events and at most 1 MiB payload. | 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. |
| Step Functions State Machine | Step Functions State Machine to Temporal Cloud (Managed) | Definition, version, alias and tag mutation | 15 ms monthly p99 | Definition at most 1 MiB and at most 100 states; one named resource. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Step Functions State Machine | Step Functions State Machine to Temporal Cloud (Managed) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Step Functions State Machine | Step Functions State Machine to Temporal Cloud (Managed) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. | |
| Step Functions State Machine | Step Functions State Machine to Temporal Cloud (Managed) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Step Functions State Machine | Step Functions State Machine to Temporal Cloud (Managed) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Azure App Configuration | Point parameter reads | 3 ms monthly p99 | Value at most 64 KiB; one named parameter and version. | 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. |
| Systems Manager (SSM) | Systems Manager (SSM) to Azure App Configuration | Bounded batch and path reads | 10 ms monthly p99 | at most 50 requested or returned parameters and at most 1 MiB total values. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Systems Manager (SSM) | Systems Manager (SSM) to Azure App Configuration | Parameter and version mutation | 10 ms monthly p99 | One parameter, at most 64 KiB value, at most 100 retained versions/labels. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Systems Manager (SSM) | Systems Manager (SSM) to Azure App Configuration | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Azure App Configuration | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Azure App Configuration | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Azure App Configuration | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Google Parameter Manager | Point parameter reads | 3 ms monthly p99 | Value at most 64 KiB; one named parameter and version. | 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. |
| Systems Manager (SSM) | Systems Manager (SSM) to Google Parameter Manager | Bounded batch and path reads | 10 ms monthly p99 | at most 50 requested or returned parameters and at most 1 MiB total values. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Systems Manager (SSM) | Systems Manager (SSM) to Google Parameter Manager | Parameter and version mutation | 10 ms monthly p99 | One parameter, at most 64 KiB value, at most 100 retained versions/labels. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Systems Manager (SSM) | Systems Manager (SSM) to Google Parameter Manager | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Google Parameter Manager | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Google Parameter Manager | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Google Parameter Manager | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Kubernetes Secrets | Point parameter reads | 3 ms monthly p99 | Value at most 64 KiB; one named parameter and version. | 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. |
| Systems Manager (SSM) | Systems Manager (SSM) to Kubernetes Secrets | Bounded batch and path reads | 10 ms monthly p99 | at most 50 requested or returned parameters and at most 1 MiB total values. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Systems Manager (SSM) | Systems Manager (SSM) to Kubernetes Secrets | Parameter and version mutation | 10 ms monthly p99 | One parameter, at most 64 KiB value, at most 100 retained versions/labels. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Systems Manager (SSM) | Systems Manager (SSM) to Kubernetes Secrets | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Kubernetes Secrets | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Kubernetes Secrets | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Kubernetes Secrets | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Systems Manager (SSM) | Systems Manager (SSM) to OCI Vault | Point parameter reads | 3 ms monthly p99 | Value at most 64 KiB; one named parameter and version. | 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. |
| Systems Manager (SSM) | Systems Manager (SSM) to OCI Vault | Bounded batch and path reads | 10 ms monthly p99 | at most 50 requested or returned parameters and at most 1 MiB total values. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Systems Manager (SSM) | Systems Manager (SSM) to OCI Vault | Parameter and version mutation | 10 ms monthly p99 | One parameter, at most 64 KiB value, at most 100 retained versions/labels. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Systems Manager (SSM) | Systems Manager (SSM) to OCI Vault | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Systems Manager (SSM) | Systems Manager (SSM) to OCI Vault | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access. | |
| Systems Manager (SSM) | Systems Manager (SSM) to OCI Vault | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Systems Manager (SSM) | Systems Manager (SSM) to OCI Vault | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Scaleway Secret Manager | Point parameter reads | 3 ms monthly p99 | Value at most 64 KiB; one named parameter and version. | 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. |
| Systems Manager (SSM) | Systems Manager (SSM) to Scaleway Secret Manager | Bounded batch and path reads | 10 ms monthly p99 | at most 50 requested or returned parameters and at most 1 MiB total values. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Systems Manager (SSM) | Systems Manager (SSM) to Scaleway Secret Manager | Parameter and version mutation | 10 ms monthly p99 | One parameter, at most 64 KiB value, at most 100 retained versions/labels. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Systems Manager (SSM) | Systems Manager (SSM) to Scaleway Secret Manager | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Scaleway Secret Manager | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Scaleway Secret Manager | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Scaleway Secret Manager | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Secret Manager | Point parameter reads | 3 ms monthly p99 | Value at most 64 KiB; one named parameter and version. | 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. |
| Systems Manager (SSM) | Systems Manager (SSM) to Secret Manager | Bounded batch and path reads | 10 ms monthly p99 | at most 50 requested or returned parameters and at most 1 MiB total values. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Systems Manager (SSM) | Systems Manager (SSM) to Secret Manager | Parameter and version mutation | 10 ms monthly p99 | One parameter, at most 64 KiB value, at most 100 retained versions/labels. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Systems Manager (SSM) | Systems Manager (SSM) to Secret Manager | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Secret Manager | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Secret Manager | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Systems Manager (SSM) | Systems Manager (SSM) to Secret Manager | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| VPC | VPC to Scaleway VPC | Not applicable | No numerical term | This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply. | |
| VPC | VPC to Tensor9 Trivial | Not applicable | No numerical term | This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply. | |
| VPC | VPC to Virtual Cloud Network | Bounded VPC management reads | 10 ms monthly p99 | One point read or at most 100 returned network objects and at most 20 filters. | 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. |
| VPC | VPC to Virtual Cloud Network | VPC topology and policy mutation | 25 ms monthly p99 | One object or at most 100 security, route, ACL, address, interface or tag entries; target readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| VPC | VPC to Virtual Cloud Network | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| VPC | VPC to Virtual Cloud Network | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| VPC | VPC to Virtual Cloud Network | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| VPC | VPC to Virtual Cloud Network | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| VPC | VPC to Virtual Network | Bounded VPC management reads | 10 ms monthly p99 | One point read or at most 100 returned network objects and at most 20 filters. | 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. |
| VPC | VPC to Virtual Network | VPC topology and policy mutation | 25 ms monthly p99 | One object or at most 100 security, route, ACL, address, interface or tag entries; target readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| VPC | VPC to Virtual Network | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| VPC | VPC to Virtual Network | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| VPC | VPC to Virtual Network | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| VPC | VPC to Virtual Network | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| VPC | VPC to Virtual Private Cloud (VPC) | Bounded VPC management reads | 10 ms monthly p99 | One point read or at most 100 returned network objects and at most 20 filters. | 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. |
| VPC | VPC to Virtual Private Cloud (VPC) | VPC topology and policy mutation | 25 ms monthly p99 | One object or at most 100 security, route, ACL, address, interface or tag entries; target readiness separate. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| VPC | VPC to Virtual Private Cloud (VPC) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| VPC | VPC to Virtual Private Cloud (VPC) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state. | |
| VPC | VPC to Virtual Private Cloud (VPC) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| VPC | VPC to Virtual Private Cloud (VPC) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
Google Cloud
| Origin service | Adapter | SLA | Service level | Conditions | Notes |
|---|---|---|---|---|---|
| Artifact Registry | Artifact Registry to Container Registry (ACR) | Bounded container manifest requests | 5 ms monthly p99 | One manifest of at most 64 KiB and at most 100 layer descriptors. Layer-byte transfer and complete image push/pull need separately agreed byte-rate limits. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Artifact Registry | Artifact Registry to Container Registry (ACR) | Repository administration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Artifact Registry | Artifact Registry to Container Registry (ACR) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Artifact Registry | Artifact Registry to Container Registry (ACR) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve content digests, manifest references and supported access scope. A successful push must not point to missing layers or a different repository. Native naming, immutable-tag, token and retention limits remain those in the target profile. Scanning completion and findings are separate from request handling, and unsupported registry tasks or non-container formats do not gain coverage here. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Artifact Registry | Artifact Registry to Container Registry (ACR) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Artifact Registry | Artifact Registry to Container Registry (ACR) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Artifact Registry | Artifact Registry to ECR (Elastic Container Registry) | Bounded container manifest requests | 5 ms monthly p99 | One manifest of at most 64 KiB and at most 100 layer descriptors. Layer-byte transfer and complete image push/pull need separately agreed byte-rate limits. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Artifact Registry | Artifact Registry to ECR (Elastic Container Registry) | Repository administration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Artifact Registry | Artifact Registry to ECR (Elastic Container Registry) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Artifact Registry | Artifact Registry to ECR (Elastic Container Registry) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve content digests, manifest references and supported access scope. A successful push must not point to missing layers or a different repository. Native naming, immutable-tag, token and retention limits remain those in the target profile. Scanning completion and findings are separate from request handling, and unsupported registry tasks or non-container formats do not gain coverage here. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Artifact Registry | Artifact Registry to ECR (Elastic Container Registry) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Artifact Registry | Artifact Registry to ECR (Elastic Container Registry) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud DNS | Cloud DNS to Azure DNS | DNS zone changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud DNS | Cloud DNS to Azure DNS | Bounded DNS record-set changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Cloud DNS | Cloud DNS to Azure DNS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud DNS | Cloud DNS to Azure DNS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve names, types, TTL values and supported record content without widening zone visibility. Target-specific apex aliases, routing policies, private-zone links and automatic registration retain their documented limits. A record accepted by the adapter must not silently refer to the wrong resource; propagation delay alone is not evidence of a bad mapping. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud DNS | Cloud DNS to Azure DNS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud DNS | Cloud DNS to Azure DNS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud DNS | Cloud DNS to Route53 | DNS zone changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud DNS | Cloud DNS to Route53 | Bounded DNS record-set changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Cloud DNS | Cloud DNS to Route53 | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud DNS | Cloud DNS to Route53 | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve names, types, TTL values and supported record content without widening zone visibility. Target-specific apex aliases, routing policies, private-zone links and automatic registration retain their documented limits. A record accepted by the adapter must not silently refer to the wrong resource; propagation delay alone is not evidence of a bad mapping. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud DNS | Cloud DNS to Route53 | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud DNS | Cloud DNS to Route53 | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud KMS | Cloud KMS to KMS Keys | Bounded symmetric cryptographic calls | 1 ms monthly p99 | At most 4 KiB plaintext/ciphertext and 4 KiB additional authenticated data, with an admitted algorithm and key state. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud KMS | Cloud KMS to KMS Keys | Key and version management | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Cloud KMS | Cloud KMS to KMS Keys | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud KMS | Cloud KMS to KMS Keys | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Never select a different key version or downgrade the requested protection/algorithm silently. Preserve authenticated-data and error semantics within the supported profile. Failed authorization must not become a successful cryptographic result. Secret/private-key material is not diagnostic evidence to share, and the target’s hardware/durability certification is not implied by a 1 or 3 ms adapter budget. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud KMS | Cloud KMS to KMS Keys | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud KMS | Cloud KMS to KMS Keys | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud KMS | Cloud KMS to Key Vault | Bounded asymmetric signing | 3 ms monthly p99 | One supported digest/algorithm and at most 4 KiB request and response material. Key generation and lifecycle changes use another row. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud KMS | Cloud KMS to Key Vault | Key and version management | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Cloud KMS | Cloud KMS to Key Vault | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud KMS | Cloud KMS to Key Vault | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Never select a different key version or downgrade the requested protection/algorithm silently. Preserve authenticated-data and error semantics within the supported profile. Failed authorization must not become a successful cryptographic result. Secret/private-key material is not diagnostic evidence to share, and the target’s hardware/durability certification is not implied by a 1 or 3 ms adapter budget. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud KMS | Cloud KMS to Key Vault | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud KMS | Cloud KMS to Key Vault | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud SQL for MySQL | Cloud SQL for MySQL to MySQL Flexible Server | Cloud SQL instance changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud SQL for MySQL | Cloud SQL for MySQL to MySQL Flexible Server | Database user changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Cloud SQL for MySQL | Cloud SQL for MySQL to MySQL Flexible Server | Connector certificate handshake | 20 ms monthly p99 | One connector handshake, at most 8 KiB public-key/certificate input and 32 KiB response; no bulk certificate issuance. Native SQL queries after connection are outside this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud SQL for MySQL | Cloud SQL for MySQL to MySQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud SQL for MySQL | Cloud SQL for MySQL to MySQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve the selected engine, supported flags and user identity without claiming unavailable extensions or authentication modes. Never acknowledge an invalid certificate or unsupported setting as successfully applied. Creating an instance does not migrate data, users or backup history. Database durability, SQL isolation and native failover duration do not become adapter promises through the control API. | |
| Cloud SQL for MySQL | Cloud SQL for MySQL to MySQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud SQL for MySQL | Cloud SQL for MySQL to MySQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud SQL for MySQL | Cloud SQL for MySQL to RDS MySQL | Cloud SQL instance changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud SQL for MySQL | Cloud SQL for MySQL to RDS MySQL | Database user changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Cloud SQL for MySQL | Cloud SQL for MySQL to RDS MySQL | Connector certificate handshake | 20 ms monthly p99 | One connector handshake, at most 8 KiB public-key/certificate input and 32 KiB response; no bulk certificate issuance. Native SQL queries after connection are outside this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud SQL for MySQL | Cloud SQL for MySQL to RDS MySQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud SQL for MySQL | Cloud SQL for MySQL to RDS MySQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve the selected engine, supported flags and user identity without claiming unavailable extensions or authentication modes. Never acknowledge an invalid certificate or unsupported setting as successfully applied. Creating an instance does not migrate data, users or backup history. Database durability, SQL isolation and native failover duration do not become adapter promises through the control API. | |
| Cloud SQL for MySQL | Cloud SQL for MySQL to RDS MySQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud SQL for MySQL | Cloud SQL for MySQL to RDS MySQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to PostgreSQL Flexible Server | Cloud SQL instance changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to PostgreSQL Flexible Server | Database user changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to PostgreSQL Flexible Server | Connector certificate handshake | 20 ms monthly p99 | One connector handshake, at most 8 KiB public-key/certificate input and 32 KiB response; no bulk certificate issuance. Native SQL queries after connection are outside this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to PostgreSQL Flexible Server | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to PostgreSQL Flexible Server | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve the selected engine, supported flags and user identity without claiming unavailable extensions or authentication modes. Never acknowledge an invalid certificate or unsupported setting as successfully applied. Creating an instance does not migrate data, users or backup history. Database durability, SQL isolation and native failover duration do not become adapter promises through the control API. | |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to PostgreSQL Flexible Server | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to PostgreSQL Flexible Server | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to RDS PostgreSQL | Cloud SQL instance changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to RDS PostgreSQL | Database user changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to RDS PostgreSQL | Connector certificate handshake | 20 ms monthly p99 | One connector handshake, at most 8 KiB public-key/certificate input and 32 KiB response; no bulk certificate issuance. Native SQL queries after connection are outside this row. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to RDS PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to RDS PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve the selected engine, supported flags and user identity without claiming unavailable extensions or authentication modes. Never acknowledge an invalid certificate or unsupported setting as successfully applied. Creating an instance does not migrate data, users or backup history. Database durability, SQL isolation and native failover duration do not become adapter promises through the control API. | |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to RDS PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud SQL for PostgreSQL | Cloud SQL for PostgreSQL to RDS PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud Storage | Cloud Storage to Blob Storage | Small object requests | 1 ms monthly p99 | At most 64 KiB full object data and 8 KiB metadata; supported preconditions only. The limit includes all bytes read or transferred, not only a requested range. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud Storage | Cloud Storage to Blob Storage | Bounded object composition | 20 ms monthly p99 | At most 32 source objects and 32 KiB composition metadata. Source parts must satisfy this target’s documented size rules. Measures adapter work, not separately measured native copy/commit waits. | 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. |
| Cloud Storage | Cloud Storage to Blob Storage | Bucket lifecycle requests | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud Storage | Cloud Storage to Blob Storage | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud Storage | Cloud Storage to Blob Storage | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve object bytes, supported metadata, source ordering and stale-write rejection. A failed compose must not be reported as a successfully committed destination. Generation identifiers are translated identities, not interchangeable native provider counters. Retention policy and notification features outside this directed profile receive no implied coverage. The target’s own durability commitment remains separate. | |
| Cloud Storage | Cloud Storage to Blob Storage | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud Storage | Cloud Storage to Blob Storage | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Cloud Storage | Cloud Storage to S3 | Small object requests | 1 ms monthly p99 | At most 64 KiB full object data and 8 KiB metadata; supported preconditions only. The limit includes all bytes read or transferred, not only a requested range. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Cloud Storage | Cloud Storage to S3 | Bounded object composition | 20 ms monthly p99 | At most 32 source objects and 32 KiB composition metadata. Source parts must satisfy this target’s documented size rules. Measures adapter work, not separately measured native copy/commit waits. | 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. |
| Cloud Storage | Cloud Storage to S3 | Bucket lifecycle requests | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Cloud Storage | Cloud Storage to S3 | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Cloud Storage | Cloud Storage to S3 | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve object bytes, supported metadata, source ordering and stale-write rejection. A failed compose must not be reported as a successfully committed destination. Generation identifiers are translated identities, not interchangeable native provider counters. Retention policy and notification features outside this directed profile receive no implied coverage. The target’s own durability commitment remains separate. | |
| Cloud Storage | Cloud Storage to S3 | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Cloud Storage | Cloud Storage to S3 | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Compute Engine | Compute Engine to EC2 Instances | Compute instance lifecycle | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Compute Engine | Compute Engine to EC2 Instances | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | 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. |
| Compute Engine | Compute Engine to EC2 Instances | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A retried create must not silently allocate duplicate machines or attach another instance’s disk. Preserve supported stop/start semantics and fail clearly on unrepresentable images or guest configuration. The customer owns application readiness, guest security and target compute capacity. Native infrastructure availability is not replaced by the adapter endpoint guarantee. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Compute Engine | Compute Engine to EC2 Instances | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Compute Engine | Compute Engine to EC2 Instances | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Compute Engine | Compute Engine to Virtual Machines | Compute instance lifecycle | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Compute Engine | Compute Engine to Virtual Machines | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | 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. |
| Compute Engine | Compute Engine to Virtual Machines | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A retried create must not silently allocate duplicate machines or attach another instance’s disk. Preserve supported stop/start semantics and fail clearly on unrepresentable images or guest configuration. The customer owns application readiness, guest security and target compute capacity. Native infrastructure availability is not replaced by the adapter endpoint guarantee. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Compute Engine | Compute Engine to Virtual Machines | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Compute Engine | Compute Engine to Virtual Machines | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Google Kubernetes Engine | Google Kubernetes Engine to Google GKE API on AWS EKS | Bounded cluster and pool reads | 10 ms monthly p99 | One object or at most 100 listed objects, 1 MiB response and 20 status entries per object. This GKE-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the gcp-gke enforcement-off acknowledgement. It is not general appliance injection or full GKE compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. | Deployment availability. This GKE-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the gcp-gke enforcement-off acknowledgement. It is not general appliance injection or full GKE compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. |
| Google Kubernetes Engine | Google Kubernetes Engine to Google GKE API on AWS EKS | Cluster and pool desired-state admission | 25 ms monthly p99 | One cluster or node pool, at most 20 pools, 1 MiB request and one durable desired-state generation; native readiness excluded. This GKE-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the gcp-gke enforcement-off acknowledgement. It is not general appliance injection or full GKE compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. | 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. |
| Google Kubernetes Engine | Google Kubernetes Engine to Google GKE API on AWS EKS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. This GKE-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the gcp-gke enforcement-off acknowledgement. It is not general appliance injection or full GKE compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Google Kubernetes Engine | Google Kubernetes Engine to Google GKE API on AWS EKS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful mutation preserves the source cluster and pool identity, records a complete desired generation and never reports readiness before EKS confirms it. Unknown fields or unsupported source features fail explicitly; stale reconciliation cannot overwrite a newer accepted generation. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Google Kubernetes Engine | Google Kubernetes Engine to Google GKE API on AWS EKS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. This GKE-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the gcp-gke enforcement-off acknowledgement. It is not general appliance injection or full GKE compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. | |
| Google Kubernetes Engine | Google Kubernetes Engine to Google GKE API on AWS EKS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Memorystore for Redis | Memorystore for Redis to Azure Managed Redis | Cache instance configuration | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Memorystore for Redis | Memorystore for Redis to Azure Managed Redis | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | 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. |
| Memorystore for Redis | Memorystore for Redis to Azure Managed Redis | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Apply the requested supported engine and security configuration, and reject unsupported modules, numbered databases or identity providers as documented. Never present a completed resize or failover before the target is ready. Access keys are secrets and must not enter diagnostic reports. Data persistence and eviction behavior belong to the selected cache configuration and native service commitment. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Memorystore for Redis | Memorystore for Redis to Azure Managed Redis | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Memorystore for Redis | Memorystore for Redis to Azure Managed Redis | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Memorystore for Redis | Memorystore for Redis to ElastiCache | Cache instance configuration | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Memorystore for Redis | Memorystore for Redis to ElastiCache | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | 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. |
| Memorystore for Redis | Memorystore for Redis to ElastiCache | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Apply the requested supported engine and security configuration, and reject unsupported modules, numbered databases or identity providers as documented. Never present a completed resize or failover before the target is ready. Access keys are secrets and must not enter diagnostic reports. Data persistence and eviction behavior belong to the selected cache configuration and native service commitment. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Memorystore for Redis | Memorystore for Redis to ElastiCache | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Memorystore for Redis | Memorystore for Redis to ElastiCache | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Secret Manager | Secret Manager to Key Vault | Bounded secret-version access | 1 ms monthly p99 | One version with at most 4 KiB secret payload and 4 KiB metadata. No implicit traversal of version history. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Secret Manager | Secret Manager to Key Vault | Secret and version changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Secret Manager | Secret Manager to Key Vault | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Secret Manager | Secret Manager to Key Vault | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Return the intended version’s bytes without silently substituting a newer or older secret. Preserve supported access denial and deletion state, and report native lifecycle limitations. Never include secret values in Explain evidence or support tickets. Provider storage durability and multi-region replication remain separate from the adapter request guarantee. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Secret Manager | Secret Manager to Key Vault | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Secret Manager | Secret Manager to Key Vault | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Secret Manager | Secret Manager to Secrets Manager | Bounded secret-version access | 1 ms monthly p99 | One version with at most 4 KiB secret payload and 4 KiB metadata. No implicit traversal of version history. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Secret Manager | Secret Manager to Secrets Manager | Secret and version changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Secret Manager | Secret Manager to Secrets Manager | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Secret Manager | Secret Manager to Secrets Manager | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Return the intended version’s bytes without silently substituting a newer or older secret. Preserve supported access denial and deletion state, and report native lifecycle limitations. Never include secret values in Explain evidence or support tickets. Provider storage durability and multi-region replication remain separate from the adapter request guarantee. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Secret Manager | Secret Manager to Secrets Manager | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Secret Manager | Secret Manager to Secrets Manager | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to VPC | Network lifecycle acceptance | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to VPC | Route and firewall changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to VPC | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to VPC | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Do not silently broaden an allow rule or discard a deny rule to achieve successful deployment. Unsupported cross-region and priority semantics must be rejected or handled exactly as documented. Retried changes must retain their target association. An accepted update must not be mistaken for immediate packet-level reachability everywhere. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to VPC | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to VPC | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to Virtual Network | Network lifecycle acceptance | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to Virtual Network | Route and firewall changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to Virtual Network | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to Virtual Network | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Do not silently broaden an allow rule or discard a deny rule to achieve successful deployment. Unsupported cross-region and priority semantics must be rejected or handled exactly as documented. Retried changes must retain their target association. An accepted update must not be mistaken for immediate packet-level reachability everywhere. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to Virtual Network | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Virtual Private Cloud (VPC) | Virtual Private Cloud (VPC) to Virtual Network | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
Microsoft Azure
| Origin service | Adapter | SLA | Service level | Conditions | Notes |
|---|---|---|---|---|---|
| Azure DNS | Azure DNS to Cloud DNS | DNS zone changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Azure DNS | Azure DNS to Cloud DNS | Bounded DNS record-set changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Azure DNS | Azure DNS to Cloud DNS | Private-zone and network-link changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Azure DNS | Azure DNS to Cloud DNS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Azure DNS | Azure DNS to Cloud DNS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve names, types, TTL values and supported record content without widening zone visibility. Target-specific apex aliases, routing policies, private-zone links and automatic registration retain their documented limits. A record accepted by the adapter must not silently refer to the wrong resource; propagation delay alone is not evidence of a bad mapping. | |
| Azure DNS | Azure DNS to Cloud DNS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Azure DNS | Azure DNS to Cloud DNS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Azure DNS | Azure DNS to Route53 | DNS zone changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Azure DNS | Azure DNS to Route53 | Bounded DNS record-set changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Azure DNS | Azure DNS to Route53 | Private-zone and network-link changes | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Azure DNS | Azure DNS to Route53 | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Azure DNS | Azure DNS to Route53 | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve names, types, TTL values and supported record content without widening zone visibility. Target-specific apex aliases, routing policies, private-zone links and automatic registration retain their documented limits. A record accepted by the adapter must not silently refer to the wrong resource; propagation delay alone is not evidence of a bad mapping. | |
| Azure DNS | Azure DNS to Route53 | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Azure DNS | Azure DNS to Route53 | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Azure Managed Redis | Azure Managed Redis to ElastiCache | Cache instance configuration | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Azure Managed Redis | Azure Managed Redis to ElastiCache | Cache database and access-key administration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Azure Managed Redis | Azure Managed Redis to ElastiCache | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Azure Managed Redis | Azure Managed Redis to ElastiCache | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Apply the requested supported engine and security configuration, and reject unsupported modules, numbered databases or identity providers as documented. Never present a completed resize or failover before the target is ready. Access keys are secrets and must not enter diagnostic reports. Data persistence and eviction behavior belong to the selected cache configuration and native service commitment. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Azure Managed Redis | Azure Managed Redis to ElastiCache | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Azure Managed Redis | Azure Managed Redis to ElastiCache | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Azure Managed Redis | Azure Managed Redis to Memorystore for Redis | Cache instance configuration | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Azure Managed Redis | Azure Managed Redis to Memorystore for Redis | Cache database and access-key administration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Azure Managed Redis | Azure Managed Redis to Memorystore for Redis | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Azure Managed Redis | Azure Managed Redis to Memorystore for Redis | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Apply the requested supported engine and security configuration, and reject unsupported modules, numbered databases or identity providers as documented. Never present a completed resize or failover before the target is ready. Access keys are secrets and must not enter diagnostic reports. Data persistence and eviction behavior belong to the selected cache configuration and native service commitment. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Azure Managed Redis | Azure Managed Redis to Memorystore for Redis | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Azure Managed Redis | Azure Managed Redis to Memorystore for Redis | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Blob Storage | Blob Storage to Cloud Storage | Small block-blob requests with lease checks | 20 ms monthly p99 | At most 64 KiB full object data and 8 KiB metadata; one blob and one applicable lease. The adapter-owned lease lookup remains timed, including when the blob has no active lease. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Blob Storage | Blob Storage to Cloud Storage | Bounded blob listing | 5 ms monthly p99 | One page of at most 1,000 entries and 1 MiB returned data; no paginator traversal. | 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. |
| Blob Storage | Blob Storage to Cloud Storage | Blob lease operations | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Blob Storage | Blob Storage to Cloud Storage | Storage container lifecycle | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Blob Storage | Blob Storage to Cloud Storage | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Blob Storage | Blob Storage to Cloud Storage | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Enforce acquire, renew, change, release and break consistently across instances. A stale lease ID must not authorize a write merely to meet a latency target. Preserve accepted bytes and supported conditional-write behavior. Append blobs, page blobs and tag-index queries remain outside this profile; whole-object read/modify/write is not a substitute for their atomicity. | |
| Blob Storage | Blob Storage to Cloud Storage | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Blob Storage | Blob Storage to Cloud Storage | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Blob Storage | Blob Storage to S3 | Small block-blob requests with lease checks | 20 ms monthly p99 | At most 64 KiB full object data and 8 KiB metadata; one blob and one applicable lease. The adapter-owned lease lookup remains timed, including when the blob has no active lease. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Blob Storage | Blob Storage to S3 | Bounded blob listing | 5 ms monthly p99 | One page of at most 1,000 entries and 1 MiB returned data; no paginator traversal. | 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. |
| Blob Storage | Blob Storage to S3 | Blob lease operations | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Blob Storage | Blob Storage to S3 | Storage container lifecycle | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Blob Storage | Blob Storage to S3 | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | |
| Blob Storage | Blob Storage to S3 | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Enforce acquire, renew, change, release and break consistently across instances. A stale lease ID must not authorize a write merely to meet a latency target. Preserve accepted bytes and supported conditional-write behavior. Append blobs, page blobs and tag-index queries remain outside this profile; whole-object read/modify/write is not a substitute for their atomicity. | |
| Blob Storage | Blob Storage to S3 | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Blob Storage | Blob Storage to S3 | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Container Registry (ACR) | Container Registry (ACR) to Artifact Registry | Bounded container manifest requests | 5 ms monthly p99 | One manifest of at most 64 KiB and at most 100 layer descriptors. Layer-byte transfer and complete image push/pull need separately agreed byte-rate limits. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Container Registry (ACR) | Container Registry (ACR) to Artifact Registry | Repository administration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Container Registry (ACR) | Container Registry (ACR) to Artifact Registry | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Container Registry (ACR) | Container Registry (ACR) to Artifact Registry | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve content digests, manifest references and supported access scope. A successful push must not point to missing layers or a different repository. Native naming, immutable-tag, token and retention limits remain those in the target profile. Scanning completion and findings are separate from request handling, and unsupported registry tasks or non-container formats do not gain coverage here. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Container Registry (ACR) | Container Registry (ACR) to Artifact Registry | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Container Registry (ACR) | Container Registry (ACR) to Artifact Registry | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Container Registry (ACR) | Container Registry (ACR) to ECR (Elastic Container Registry) | Bounded container manifest requests | 5 ms monthly p99 | One manifest of at most 64 KiB and at most 100 layer descriptors. Layer-byte transfer and complete image push/pull need separately agreed byte-rate limits. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Container Registry (ACR) | Container Registry (ACR) to ECR (Elastic Container Registry) | Repository administration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Container Registry (ACR) | Container Registry (ACR) to ECR (Elastic Container Registry) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Container Registry (ACR) | Container Registry (ACR) to ECR (Elastic Container Registry) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve content digests, manifest references and supported access scope. A successful push must not point to missing layers or a different repository. Native naming, immutable-tag, token and retention limits remain those in the target profile. Scanning completion and findings are separate from request handling, and unsupported registry tasks or non-container formats do not gain coverage here. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Container Registry (ACR) | Container Registry (ACR) to ECR (Elastic Container Registry) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Container Registry (ACR) | Container Registry (ACR) to ECR (Elastic Container Registry) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| MySQL Flexible Server | MySQL Flexible Server to Cloud SQL for MySQL | Flexible Server changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| MySQL Flexible Server | MySQL Flexible Server to Cloud SQL for MySQL | Database and server configuration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| MySQL Flexible Server | MySQL Flexible Server to Cloud SQL for MySQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| MySQL Flexible Server | MySQL Flexible Server to Cloud SQL for MySQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Return truthful accepted/pending/failed status and enforce the target’s allowed flags, versions and extension set. Azure-specific identity mechanisms outside the profile must not be presented as working logins. Database creation does not transfer source data or backup history. Configuration requests must apply to the intended server even after retries or name reuse. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| MySQL Flexible Server | MySQL Flexible Server to Cloud SQL for MySQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| MySQL Flexible Server | MySQL Flexible Server to Cloud SQL for MySQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| MySQL Flexible Server | MySQL Flexible Server to RDS MySQL | Flexible Server changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| MySQL Flexible Server | MySQL Flexible Server to RDS MySQL | Database and server configuration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| MySQL Flexible Server | MySQL Flexible Server to RDS MySQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| MySQL Flexible Server | MySQL Flexible Server to RDS MySQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Return truthful accepted/pending/failed status and enforce the target’s allowed flags, versions and extension set. Azure-specific identity mechanisms outside the profile must not be presented as working logins. Database creation does not transfer source data or backup history. Configuration requests must apply to the intended server even after retries or name reuse. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| MySQL Flexible Server | MySQL Flexible Server to RDS MySQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| MySQL Flexible Server | MySQL Flexible Server to RDS MySQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to Cloud SQL for PostgreSQL | Flexible Server changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to Cloud SQL for PostgreSQL | Database and server configuration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to Cloud SQL for PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to Cloud SQL for PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Return truthful accepted/pending/failed status and enforce the target’s allowed flags, versions and extension set. Azure-specific identity mechanisms outside the profile must not be presented as working logins. Database creation does not transfer source data or backup history. Configuration requests must apply to the intended server even after retries or name reuse. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to Cloud SQL for PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to Cloud SQL for PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to RDS PostgreSQL | Flexible Server changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to RDS PostgreSQL | Database and server configuration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to RDS PostgreSQL | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to RDS PostgreSQL | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Return truthful accepted/pending/failed status and enforce the target’s allowed flags, versions and extension set. Azure-specific identity mechanisms outside the profile must not be presented as working logins. Database creation does not transfer source data or backup history. Configuration requests must apply to the intended server even after retries or name reuse. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to RDS PostgreSQL | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| PostgreSQL Flexible Server | PostgreSQL Flexible Server to RDS PostgreSQL | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to EC2 Auto Scaling | Scale-set configuration acceptance | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to EC2 Auto Scaling | Rolling upgrade and reimage acceptance | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | 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. |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to EC2 Auto Scaling | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to EC2 Auto Scaling | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve supported desired capacity, machine configuration and rollout intent. Do not turn a partial rolling upgrade into a false all-instances-success result. Target-specific overprovisioning and image-update behavior must remain documented. The customer chooses workload health criteria and target capacity; the adapter must retain configuration and report failures accurately. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to EC2 Auto Scaling | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to EC2 Auto Scaling | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to Managed Instance Group | Scale-set configuration acceptance | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to Managed Instance Group | Rolling upgrade and reimage acceptance | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | 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. |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to Managed Instance Group | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to Managed Instance Group | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve supported desired capacity, machine configuration and rollout intent. Do not turn a partial rolling upgrade into a false all-instances-success result. Target-specific overprovisioning and image-update behavior must remain documented. The customer chooses workload health criteria and target capacity; the adapter must retain configuration and report failures accurately. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to Managed Instance Group | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Virtual Machine Scale Sets | Virtual Machine Scale Sets to Managed Instance Group | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Virtual Machines | Virtual Machines to Compute Engine | Azure VM lifecycle | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Virtual Machines | Virtual Machines to Compute Engine | VM command acceptance | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Virtual Machines | Virtual Machines to Compute Engine | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Virtual Machines | Virtual Machines to Compute Engine | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Retain resource identities and network associations through retries, deletion and recreation. Do not report unsupported disks, addresses or extensions as applied. A successful request acceptance is not proof that the guest command succeeded or that a workload is ready. Adapter-issued errors must identify unsupported request shapes rather than silently discarding fields. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Virtual Machines | Virtual Machines to Compute Engine | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Virtual Machines | Virtual Machines to Compute Engine | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Virtual Machines | Virtual Machines to EC2 Instances | Azure VM lifecycle | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Virtual Machines | Virtual Machines to EC2 Instances | VM command acceptance | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Virtual Machines | Virtual Machines to EC2 Instances | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Virtual Machines | Virtual Machines to EC2 Instances | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Retain resource identities and network associations through retries, deletion and recreation. Do not report unsupported disks, addresses or extensions as applied. A successful request acceptance is not proof that the guest command succeeded or that a workload is ready. Adapter-issued errors must identify unsupported request shapes rather than silently discarding fields. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Virtual Machines | Virtual Machines to EC2 Instances | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Virtual Machines | Virtual Machines to EC2 Instances | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Virtual Network | Virtual Network to VPC | Virtual-network and subnet changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Virtual Network | Virtual Network to VPC | Routing and security configuration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Virtual Network | Virtual Network to VPC | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Virtual Network | Virtual Network to VPC | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve network isolation, intended rule priority and supported service-tag interpretation. A stale retry must not detach another VM’s interface or delete a newly recreated subnet. Reject unsupported dynamic-address shapes explicitly. Report long-running status truthfully; successful acceptance alone does not establish connectivity. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Virtual Network | Virtual Network to VPC | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Virtual Network | Virtual Network to VPC | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| Virtual Network | Virtual Network to Virtual Private Cloud (VPC) | Virtual-network and subnet changes | 30 ms monthly p99 | One resource change and at most 32 KiB settings. Measures validation and durable acceptance, not completion of provisioning, restart, migration, failover or background reconciliation. | Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. |
| Virtual Network | Virtual Network to Virtual Private Cloud (VPC) | Routing and security configuration | 20 ms monthly p99 | One configuration object, at most 50 entries and 32 KiB request/response data. A list is one page of at most 100 records and 256 KiB, not a paginator traversing the whole account. | 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. |
| Virtual Network | Virtual Network to Virtual Private Cloud (VPC) | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| Virtual Network | Virtual Network to Virtual Private Cloud (VPC) | Documented adapter behavior | Preserve the supported behavior documented for this adapter | Preserve network isolation, intended rule priority and supported service-tag interpretation. A stale retry must not detach another VM’s interface or delete a newly recreated subnet. Reject unsupported dynamic-address shapes explicitly. Report long-running status truthfully; successful acceptance alone does not establish connectivity. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| Virtual Network | Virtual Network to Virtual Private Cloud (VPC) | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. | |
| Virtual Network | Virtual Network to Virtual Private Cloud (VPC) | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | |
| azure::1.0.0::aks | azure::1.0.0::aks to Azure AKS API on AWS EKS | Bounded cluster and pool reads | 10 ms monthly p99 | One object or at most 100 listed objects, 1 MiB response and 20 status entries per object. This AKS-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the azure-aks enforcement-off acknowledgement. It is not general appliance injection or full AKS compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. | Deployment availability. This AKS-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the azure-aks enforcement-off acknowledgement. It is not general appliance injection or full AKS compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. |
| azure::1.0.0::aks | azure::1.0.0::aks to Azure AKS API on AWS EKS | Cluster and pool desired-state admission | 25 ms monthly p99 | One cluster or node pool, at most 20 pools, 1 MiB request and one durable desired-state generation; native readiness excluded. This AKS-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the azure-aks enforcement-off acknowledgement. It is not general appliance injection or full AKS compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. | 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. |
| azure::1.0.0::aks | azure::1.0.0::aks to Azure AKS API on AWS EKS | Correct request handling | 99.9% per calendar month | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. This AKS-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the azure-aks enforcement-off acknowledgement. It is not general appliance injection or full AKS compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. | How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. |
| azure::1.0.0::aks | azure::1.0.0::aks to Azure AKS API on AWS EKS | Documented adapter behavior | Preserve the supported behavior documented for this adapter | A successful mutation preserves the source cluster and pool identity, records a complete desired generation and never reports readiness before EKS confirms it. Unknown fields or unsupported source features fail explicitly; stale reconciliation cannot overwrite a newer accepted generation. | Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. |
| azure::1.0.0::aks | azure::1.0.0::aks to Azure AKS API on AWS EKS | Endpoint reachability | 99.9% per calendar month | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider’s service. This AKS-to-EKS composition requires explicit sipsvr configuration, ReportOnly mode and the azure-aks enforcement-off acknowledgement. It is not general appliance injection or full AKS compatibility; terms apply only when this exact deployed composition and operations are named in a signed agreement. | |
| azure::1.0.0::aks | azure::1.0.0::aks to Azure AKS API on AWS EKS | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |