Supported environments
- Azure
- DigitalOcean
- Google Cloud
- OCI
- Scaleway
How the targets compare
Each row compares a capability of Network Load Balancer with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
On Azure
Azure Load Balancer
Managing the load balancer
Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to Azure Standard Load Balancer. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such asCreateLoadBalancer, CreateListener, and RegisterTargets. The cloud load balancer receives client connections and forwards them to your application.
A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
Frontend, rules, and backend pool
The Standard Load Balancer has a frontend address, a rule per listener, a backend address pool, and health probes. TCP and UDP listeners retain their protocol and port. Preserving a combined TCP+UDP listener on one port requires separate rules for the two protocols. Azure All-protocol rules are HA-port rules for an internal load balancer and cover all ports; they are not a port-scoped public listener. A public frontend uses a static Standard public IP. An internal frontend uses a private subnet address. A zone-redundant deployment can serve backends across the region’s zones; verify the selected frontend and backend placement for the customer’s network.Client addresses and TLS
Azure forwards traffic while preserving the client’s source IP. Connection distribution uses the source and destination addresses, source and destination ports, and protocol. The backend can use the original address for access control and logging. Standard Load Balancer does not terminate TLS. An AWS TLS listener becomes TCP passthrough and your backend must terminate TLS. Prepare that endpoint and its certificate before cutover.Health probes and logs
TCP, HTTP, or HTTPS probes are associated with load-balancing rules. The mapping preserves the applicable interval, port, path, and failure threshold. Allow AzureLoadBalancer health traffic as well as the intended client traffic in the backend network security rules. Azure Monitor provides metrics and health-event logs. Standard Load Balancer does not provide AWS-style per-request access logs; collect application request details at the backend.Target registration and readiness
RegisterTargets and DeregisterTargets update target-group membership. Instance registrations resolve through the adapter’s EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network.
The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider’s health status and test an application request: a registered target alone does not establish that its application is ready.
DescribeTargetHealth reports registration and zone eligibility from the adapter’s saved state. Its healthy result does not confirm that the native load balancer’s probe succeeded. Check native backend health and a complete application request before sending production traffic.
Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement.
Deployment and cutover
Deploy the adapter with permission to manage load balancers and their network dependencies in the customer’s cloud account. AWS-facing credentials authorize management calls; the adapter uses the target cloud’s credentials to apply changes. Configure public or private exposure, frontend access rules, backend access, and health-check access together. Prepare DNS and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build; external DNS and clients still need a cutover. With Cloud Adapter, the adapter also maintains the AWS resource identities used by management calls. Check certificates, routing, native health checks, and a complete client request before changing DNS. Keep the old load balancer available while existing connections drain. Application sessions and active connections are not copied by this adapter.On DigitalOcean
DigitalOcean Load Balancer
Managing the load balancer
Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to DigitalOcean Load Balancer. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such asCreateLoadBalancer, CreateListener, and RegisterTargets. The cloud load balancer receives client connections and forwards them to your application.
A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
Forwarding rules and health checks
TCP and UDP listeners map to forwarding rules over a single Droplet pool. Every rule shares one load-balancer health check. The mapping uses the first target group’s check and reports differences on other groups; choose a probe that works for all backends.TLS and client addresses
This NLB option uses TCP passthrough for a TLS listener, so the backend terminates TLS. The profile does not provide native client-IP preservation. Review any backend access rules, rate limits, or logging that depend on the original client address.Addressing and exposure
The load balancer receives a stable IP, but an AWS Elastic IP reserved before creation has no equivalent in this option. Prepare external DNS and allowlists after the address is allocated. DigitalOcean supports internal load balancers. Confirm the target VPC and public or internal setting explicitly; the mapping does not establish private exposure from the AWS setting alone.Target registration and readiness
RegisterTargets and DeregisterTargets update target-group membership. Instance registrations resolve through the adapter’s EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network.
The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider’s health status and test an application request: a registered target alone does not establish that its application is ready.
DescribeTargetHealth reports registration and zone eligibility from the adapter’s saved state. Its healthy result does not confirm that the native load balancer’s probe succeeded. Check native backend health and a complete application request before sending production traffic.
Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement.
Deployment and cutover
Deploy the adapter with permission to manage load balancers and their network dependencies in the customer’s cloud account. AWS-facing credentials authorize management calls; the adapter uses the target cloud’s credentials to apply changes. Configure public or private exposure, frontend access rules, backend access, and health-check access together. Prepare DNS and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build; external DNS and clients still need a cutover. With Cloud Adapter, the adapter also maintains the AWS resource identities used by management calls. Check certificates, routing, native health checks, and a complete client request before changing DNS. Keep the old load balancer available while existing connections drain. Application sessions and active connections are not copied by this adapter.On Google Cloud
Cloud Load Balancing
Managing the load balancer
Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to Google passthrough Network Load Balancer. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such asCreateLoadBalancer, CreateListener, and RegisterTargets. The cloud load balancer receives client connections and forwards them to your application.
A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
Regional forwarding resources
The load balancer uses a reserved address, forwarding rules, a regional backend service, and regional health checks. Each TCP or UDP listener becomes a forwarding rule with its protocol and port. A combined TCP+UDP listener can use L3_DEFAULT, which forwards all supported protocols on all ports. That forwarding rule is broader than the source listener; firewall rules must restrict traffic to the intended protocols and ports. A public frontend uses a regional external address; an internal frontend uses an address on the target subnet. The backend service can contain backends across the region’s zones. Confirm their placement and connectivity rather than assuming AWS availability-zone identifiers transfer.Client addresses and TLS
Passthrough forwarding preserves the client’s source IP at the backend. Application allowlists and logs can read that address without X-Forwarded-For or a proxy-protocol header. A connection is assigned using its source and destination addresses, source and destination ports, and protocol. The target does not terminate TLS. An AWS TLS listener uses TCP passthrough, with TLS terminated by your backend. Configure the certificate there before switching traffic.Health checks and observability
The target supports TCP, HTTP, HTTPS, SSL, and gRPC probes. Health checks belong to the backend service and use the configured path, port, interval, timeout, and thresholds. Permit both application traffic and health-check traffic in the target firewall. Flow and backend-service logs describe network connections. They do not reproduce AWS TLS access logs or application request logs; collect request-level information in the backend when required.Target registration and readiness
RegisterTargets and DeregisterTargets update target-group membership. Instance registrations resolve through the adapter’s EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network.
The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider’s health status and test an application request: a registered target alone does not establish that its application is ready.
DescribeTargetHealth reports registration and zone eligibility from the adapter’s saved state. Its healthy result does not confirm that the native load balancer’s probe succeeded. Check native backend health and a complete application request before sending production traffic.
Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement.
Deployment and cutover
Deploy the adapter with permission to manage load balancers and their network dependencies in the customer’s cloud account. AWS-facing credentials authorize management calls; the adapter uses the target cloud’s credentials to apply changes. Configure public or private exposure, frontend access rules, backend access, and health-check access together. Prepare DNS and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build; external DNS and clients still need a cutover. With Cloud Adapter, the adapter also maintains the AWS resource identities used by management calls. Check certificates, routing, native health checks, and a complete client request before changing DNS. Keep the old load balancer available while existing connections drain. Application sessions and active connections are not copied by this adapter.On OCI
OCI Network Load Balancer
Managing the load balancer
Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to OCI Network Load Balancer. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such asCreateLoadBalancer, CreateListener, and RegisterTargets. The cloud load balancer receives client connections and forwards them to your application.
A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
Listeners, addresses, and placement
TCP, UDP, and mixed TCP+UDP listeners map to native OCI listeners and backend sets. Reserved IP addresses provide a stable frontend, and the target preserves the client’s source address at the backend. The network load balancer is regional. Its public or private subnet arrangement replaces the AWS multi-subnet layout; verify the selected network, frontend exposure, backend rules, and health-check access.TLS and health checks
OCI Network Load Balancer does not terminate TLS. The TLS listener maps to TCP passthrough, and the backend must terminate the encrypted connection. This is different from provisioning an HTTP listener on an application load balancer. Health checks use the path, expected status, timeout, interval, and failure threshold. Test those checks and a client connection before relying on a newly registered backend.Endpoint changes
Clients use the OCI address rather than the AWS load balancer hostname. Update external DNS and allowlists. In the infrastructure translation, an AWS-specific reference without a target equivalent causes a build error. The service adapter retains AWS-shaped management identities separately from native resource identifiers.Target registration and readiness
RegisterTargets and DeregisterTargets update target-group membership. Instance registrations resolve through the adapter’s EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network.
The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider’s health status and test an application request: a registered target alone does not establish that its application is ready.
DescribeTargetHealth reports registration and zone eligibility from the adapter’s saved state. Its healthy result does not confirm that the native load balancer’s probe succeeded. Check native backend health and a complete application request before sending production traffic.
Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement.
Deployment and cutover
Deploy the adapter with permission to manage load balancers and their network dependencies in the customer’s cloud account. AWS-facing credentials authorize management calls; the adapter uses the target cloud’s credentials to apply changes. Configure public or private exposure, frontend access rules, backend access, and health-check access together. Prepare DNS and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build; external DNS and clients still need a cutover. With Cloud Adapter, the adapter also maintains the AWS resource identities used by management calls. Check certificates, routing, native health checks, and a complete client request before changing DNS. Keep the old load balancer available while existing connections drain. Application sessions and active connections are not copied by this adapter.On Scaleway
Scaleway Load Balancer
Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.Network Load Balancer to Azure Load Balancer
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Network control calls validate AWS-shaped topology, record desired state and reconcile native networking on azure::1.0.0::lb. Application packets, load-balancer forwarding and health-probe network time are not adapter request latency. Local graph validation, rule translation, admission, status lookup and response encoding remain covered.How the latency targets were chosen
Network and load-balancer state reads: 8 ms monthly p99.DescribeLoadBalancers, DescribeTargetHealth. Bounded desired and observed status lookup.
Listener, target and topology mutation: 18 ms monthly p99. CreateListener, CreateLoadBalancer, ModifyListener, ModifyTargetGroup. Validation and durable desired-state mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent load balancers, networks and flow-log records reconcile concurrently; changes to one object serialize by generation. Qualification fixes listeners, rules, target groups, routes, security rules, tags and returned page size. Large rule trees receive their own bounded group rather than inheriting a point-write estimate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
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.Example and diagnosis
Adding one HTTPS listener with ten routing rules is a bounded policy mutation. The adapter target covers validation, durable recording and native-plan construction; provider provisioning and certificate readiness are separate. The response cannot claim ACTIVE until the native listener is observed. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Network Load Balancer to DigitalOcean Load Balancer
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Network control calls validate AWS-shaped topology, record desired state and reconcile native networking on digitalocean::1.0.0::lb. Application packets, load-balancer forwarding and health-probe network time are not adapter request latency. Local graph validation, rule translation, admission, status lookup and response encoding remain covered.How the latency targets were chosen
Network and load-balancer state reads: 8 ms monthly p99.DescribeLoadBalancers, DescribeTargetHealth. Bounded desired and observed status lookup.
Listener, target and topology mutation: 18 ms monthly p99. CreateListener, CreateLoadBalancer, DeregisterTargets, ModifyListener, ModifyTargetGroup, RegisterTargets. Validation and durable desired-state mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent load balancers, networks and flow-log records reconcile concurrently; changes to one object serialize by generation. Qualification fixes listeners, rules, target groups, routes, security rules, tags and returned page size. Large rule trees receive their own bounded group rather than inheriting a point-write estimate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
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.Example and diagnosis
Adding one HTTPS listener with ten routing rules is a bounded policy mutation. The adapter target covers validation, durable recording and native-plan construction; provider provisioning and certificate readiness are separate. The response cannot claim ACTIVE until the native listener is observed. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Network Load Balancer to Cloud Load Balancing
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Network control calls validate AWS-shaped topology, record desired state and reconcile native networking on google::1.0.0::lb. Application packets, load-balancer forwarding and health-probe network time are not adapter request latency. Local graph validation, rule translation, admission, status lookup and response encoding remain covered.How the latency targets were chosen
Network and load-balancer state reads: 8 ms monthly p99.DescribeLoadBalancers, DescribeTargetHealth. Bounded desired and observed status lookup.
Listener, target and topology mutation: 18 ms monthly p99. CreateListener, CreateLoadBalancer, ModifyListener, ModifyTargetGroup. Validation and durable desired-state mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent load balancers, networks and flow-log records reconcile concurrently; changes to one object serialize by generation. Qualification fixes listeners, rules, target groups, routes, security rules, tags and returned page size. Large rule trees receive their own bounded group rather than inheriting a point-write estimate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
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.Example and diagnosis
Adding one HTTPS listener with ten routing rules is a bounded policy mutation. The adapter target covers validation, durable recording and native-plan construction; provider provisioning and certificate readiness are separate. The response cannot claim ACTIVE until the native listener is observed. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Network Load Balancer to OCI Network Load Balancer
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Network control calls validate AWS-shaped topology, record desired state and reconcile native networking on oci::1.0.0::nlb. Application packets, load-balancer forwarding and health-probe network time are not adapter request latency. Local graph validation, rule translation, admission, status lookup and response encoding remain covered.How the latency targets were chosen
Network and load-balancer state reads: 8 ms monthly p99.DescribeLoadBalancers, DescribeTargetHealth. Bounded desired and observed status lookup.
Listener, target and topology mutation: 18 ms monthly p99. CreateListener, CreateLoadBalancer, DeregisterTargets, ModifyListener, ModifyLoadBalancerAttributes, ModifyTargetGroup, RegisterTargets. Validation and durable desired-state mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent load balancers, networks and flow-log records reconcile concurrently; changes to one object serialize by generation. Qualification fixes listeners, rules, target groups, routes, security rules, tags and returned page size. Large rule trees receive their own bounded group rather than inheriting a point-write estimate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
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.Example and diagnosis
Adding one HTTPS listener with ten routing rules is a bounded policy mutation. The adapter target covers validation, durable recording and native-plan construction; provider provisioning and certificate readiness are separate. The response cannot claim ACTIVE until the native listener is observed. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Network Load Balancer to Scaleway Load Balancer
SLA status: Not applicable 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.Install and run
The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. SetT9_API_KEY as described in Install and Authenticate, then list the adapters your account may use with this origin: