Supported environments
- Azure
- DigitalOcean
- Google Cloud
- OCI
- Scaleway
How the targets compare
Each row compares a capability of Application 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 Application Gateway. 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.
Application Gateway resources
An ALB maps to Application Gateway v2: listeners accept HTTP or HTTPS, backend pools represent target groups, and routing rules select a pool. The gateway needs a dedicated subnet. An ALB does not require a separate Azure Standard Load Balancer. HTTPS uses a certificate from Azure Key Vault, including multi-site setups, Server Name Indication (SNI), and the target’s mutual-TLS arrangement. An ACM ARN is a reference, not the certificate and private key; supply the certificate through the target arrangement.Routing and cookies
Host conditions map to multi-site listeners, and path conditions map to path rules. Header, method, query, source-IP conditions, weighted target groups, and fixed responses are outside this mapping. gRPC to backends is also outside this option. Cookie affinity keeps a session on a backend, but Application Gateway has no configured cookie lifetime: affinity lasts for the browser session. Listener-based OIDC or OAuth login is not mapped; handle login in your application or an identity-aware proxy.Frontend security
The service adapter enforces supported frontend security-group rules through a network security group (NSG) on the gateway’s dedicated subnet. Rules allow the selected IPv4 client ranges on the listener ports. The subnet also needs Azure’s GatewayManager control ports 65200-65535 and AzureLoadBalancer health traffic. Gateway requirements include unrestricted outbound access from that subnet. A dedicated subnet prevents those gateway rules from changing another workload’s access. Unsupported selectors are rejected; the frontend waits for its network security policy before becoming available.Backend health
Each backend setting has a health probe. The mapping preserves the path, expected status codes, interval, timeout, unhealthy threshold, and explicit port. Application Gateway also supports response-body matching, which is a target capability rather than an AWS setting that must be recreated.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.
Port forwarding and the backend pool
Each listener becomes a forwarding rule from a frontend protocol and port to a backend port. All rules use one Droplet pool, selected by tag or ID. The load balancer runs in one region and is sized by node count. This option does not reproduce path-, host-, header-, or query-based routing, or weighted target groups. It retains each listener’s default forwarding behavior. Move content-based routing into your application or an ingress proxy before using this target.TLS and session cookies
TLS can terminate at the load balancer using a managed certificate, including automatic Let’s Encrypt issuance, or pass through to a backend that terminates it. Choose the arrangement explicitly and prepare the required DNS and certificate configuration. An ACM ARN does not supply a transferable private key. Cookie stickiness is supported. Confirm that the selected forwarding mode and shared backend pool preserve the session behavior your application expects.Health checks and exposure
DigitalOcean uses one health check for the entire load balancer. The mapping takes it from the first target group and reports conflicting checks on other groups. Protocol, port, and path must work for every backend in the pool. DigitalOcean offers public and internal load balancers. This mapping requires an explicit check of the target’s exposure; the existence of a private target option does not establish that a translated deployment is private. Confirm the VPC and internal setting before cutover.Addresses and operational differences
The load balancer has a stable IP address, but this option does not provide an Elastic IP reserved before creation. Update client DNS and allowlists to the new address. AWS access-log settings, WAF attachment, and reserved-IP mappings are outside the profile.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 Cloud Load Balancing. 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.
Google resources
A forwarding rule receives traffic at the frontend address. A target proxy handles HTTP or HTTPS, a URL map chooses the backend, and a backend service represents each target group. Health checks belong to the backend services. HTTPS uses a Google-managed certificate for your DNS names, including multi-domain certificates and the target’s mutual-TLS arrangement; an ACM ARN does not contain certificate material that can be copied.Routing and session affinity
Path, host, header, query, and method conditions map to URL-map rules. Weighted target groups become weighted backend services. Rule priority determines match order. Source-IP conditions and fixed-response actions are outside this mapping. Lambda target groups are outside this mapping. A function deployed behind a separate HTTP or serverless backend does not become an AWS Lambda target registration. Cookie stickiness becomes generated-cookie affinity, with a maximum duration of one day. Review longer AWS cookie lifetimes before moving.Frontend security
The service adapter can translate attached security-group IPv4 client ranges into Cloud Armor policies. This requires your explicit choice to use the paid Cloud Armor service. Each listener has its own policy; a request outside the allowed ranges receives HTTP 403, whereas an AWS security group drops the connection. This enforcement path supports IPv4 HTTP listeners and at most 10 client CIDR ranges per listener. Redirect actions are refused because they can bypass backend policy evaluation. The policy is attached and observed before the frontend is made available. You can explicitly choose to omit frontend security-group enforcement, but must then supply and verify the intended access control separately.Health checks and authentication
Health checks use the target group’s path, port, interval, timeout, and thresholds. Google HTTP(S) health checks require status 200. An AWS matcher that accepts other codes or a range of codes needs a health endpoint that returns 200 when healthy; response-body matching does not replace that status requirement. Listener authentication maps to Identity-Aware Proxy on the backend service. Google identity is the direct case; an external identity provider or Cognito user pool needs the Identity Platform arrangement described by that authentication mapping. Check the login flow as well as the load balancer’s health.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 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 Flexible 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 and backend sets
One OCI listener represents each ALB listener, and one backend set represents each target group. The listener’s default action selects its backend set. The native load balancer uses a bandwidth range, initially 10-100 Mbps; adjust it for the deployment. The AWS multi-subnet layout becomes the target deployment’s network arrangement. Confirm whether the load balancer is public or private and whether its subnet and security rules admit the intended clients and backends.Request routing
Path, host, header, and query conditions map to a routing policy per listener, in rule-priority order. Method conditions, source-IP conditions, weighted target groups, and fixed-response actions are outside this mapping. OCI backend-set server weights do not reproduce a listener rule that splits traffic between target groups.HTTPS and certificates
The HTTPS mapping uses TLS on the OCI listener, with a certificate supplied through OCI Certificates or the load balancer’s certificate configuration. An ACM ARN identifies an AWS certificate; it does not supply the certificate and private key needed by OCI. Provision or import the target certificate and attach it before enabling the HTTPS frontend. The mapped arrangement uses one certificate per listener and does not reproduce an AWS listener’s SNI certificate list. Backend TLS is a separate setting; enabling it does not secure a frontend that is still configured for HTTP. Verify the client-facing handshake and the backend connection before cutover. OIDC and OAuth authenticate actions are outside this option; login belongs in the application or an identity-aware proxy.Health checks, cookies, and operations
Backend sets specify the health-check path, response codes, interval, timeout, port, and consecutive-failure count. The default path is /. The existing mapping turns HTTP and HTTPS probes into HTTP probes; other checks use TCP. Cookie persistence includes the configured duration. AWS access-log settings, idle timeout, deletion protection, and WAF attachment are outside this profile. Prepare the target logging and operational settings explicitly. Client DNS must resolve to the OCI address; an AWS hosted-zone ID is not an OCI resource identifier.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.Application 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.DescribeListeners, DescribeLoadBalancers, DescribeTargetGroups, DescribeTargetHealth. Bounded desired and observed status lookup.
Listener, target and topology mutation: 18 ms monthly p99. CreateListener, CreateTargetGroup, ModifyListener, ModifyTargetGroup. Validation and durable desired-state mutation.
Bounded routing and authorization policy: 25 ms monthly p99. CreateRule, DeleteRule, ModifyRule. Whole-policy validation and generation-ordered reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
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.
Application 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.
Application 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.DescribeListeners, DescribeLoadBalancers, DescribeTargetGroups, DescribeTargetHealth. Bounded desired and observed status lookup.
Listener, target and topology mutation: 18 ms monthly p99. CreateListener, CreateTargetGroup, ModifyListener, ModifyTargetGroup. Validation and durable desired-state mutation.
Bounded routing and authorization policy: 25 ms monthly p99. CreateRule, DeleteRule, ModifyRule. Whole-policy validation and generation-ordered reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
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.
Application Load Balancer to OCI 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::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.DescribeListeners, DescribeLoadBalancers, DescribeTargetGroups, DescribeTargetHealth. Bounded desired and observed status lookup.
Listener, target and topology mutation: 18 ms monthly p99. CreateListener, CreateLoadBalancer, CreateTargetGroup, DeregisterTargets, ModifyListener, ModifyTargetGroup, RegisterTargets. Validation and durable desired-state mutation.
Bounded routing and authorization policy: 25 ms monthly p99. CreateRule, DeleteRule, ModifyRule. Whole-policy validation and generation-ordered reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
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.
Application 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: