Application Load Balancer

On this page

• Coverage by target cloud
• How the backends compare
  • Max adaptation
  • Infrastructure-only adaptation
• On Google Cloud
• On Azure
• On OCI
• Costs
• Service level agreements
  • Application Load Balancer to Azure Load Balancer
  • Application Load Balancer to Cloud Load Balancing
  • Application Load Balancer to OCI Load Balancer
  • Application Load Balancer to Scaleway Load Balancer
• Debug this service

​

Coverage by target cloud

​

How the backends compare

Each row compares a capability of Application Load Balancer with its adaptation on each backend. A dash means this row is not stated for that backend.

​

Max adaptation

​

Infrastructure-only adaptation

​

On Google Cloud

​

How it works

When a deployment provides the runtime AWS load-balancing API, your application and Terraform keep using that API. The Tensor9 adapter answers those calls (CreateLoadBalancer, CreateListener, RegisterTargets and the rest), keeps the AWS load balancer, listener and target group identities, saves each change and applies it to Google Cloud Load Balancing. A target group is the set of backends a listener forwards traffic to. That runtime design is separate from translating a stack to native load-balancer resources. A designed runtime model does not establish that the deployment can serve it, and a missing native mapping does not silently select a runtime fallback. Confirm the selected deployment supports the required path. Client traffic does not pass through the adapter. Clients connect to the cloud load balancer, which forwards requests to your backends. A management call can return success before the cloud change has finished; the adapter keeps the requested configuration and finishes applying it in the background. Wait until the load balancer is available and check the cloud resources before sending production traffic.

Management calls go through the adapter; client traffic goes straight to the cloud load balancer.

​

Google resources and routing

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 stands in for each target group, with its own health check. HTTPS uses a Google-managed certificate for your DNS names, including certificates for several domains and the load balancer’s mutual TLS. Path, host, header, query and method conditions become URL-map rules, matched in rule-priority order. Weighted target groups become weighted backend services. Cookie stickiness becomes generated-cookie affinity. Health checks keep the target group’s path, port, interval, timeout and thresholds. Listener authentication maps to Identity-Aware Proxy on the backend service. Google sign-in works directly; an external identity provider or a Cognito user pool needs Google Identity Platform. Test the login flow as well as the load balancer’s health.

​

Client access and Cloud Armor

Security groups on an ALB have no direct Google equivalent, so you choose how they are handled. Either opt in to Cloud Armor, a separately billed Google service, by tagging the load balancer t9:ack:degradation = load-balancer.firewall-cloud-armor; or choose to leave the security groups unenforced with load-balancer.firewall-policy-attachment and provide access control yourself. If a security group is attached and you choose neither, or both, the request is rejected. With Cloud Armor, the adapter turns the security groups’ IPv4 client ranges into one Cloud Armor policy per listener. The policy is attached and confirmed before the frontend becomes available.

​

Deployment availability

This runtime design does not establish a working native stack translation or an available runtime deployment. A stack combining this load balancer, EC2 instances and a VPC is not currently available on this target. A missing native mapping does not automatically enable the runtime API. Use a supported configuration or author the native load-balancer resources separately.

​

Targets and health checks

For a deployment that serves the runtime API, RegisterTargets and DeregisterTargets add and remove backends from a target group. An instance ID is resolved from the EC2 instances the adapter knows about; an IP registration names the backend’s address and port. The target group, the load balancer and the backend must be on networks that can reach each other. The adapter applies a listener only after its target group and network are ready. The cloud load balancer’s own health checks decide which backends receive traffic. A registered target is not proof that its application is ready: check the cloud provider’s health status and send a real application request first. DescribeTargetHealth reports the cloud load balancer’s probe results, read once per health-check interval, in AWS’s states and reason codes: initial while checks start, then healthy or unhealthy. If the adapter has not been able to read health for three intervals, it reports unavailable. Drain connections before you deregister backends or delete a load balancer. Removing configuration does not move active connections to a replacement.

​

Limitations

• Source-IP conditions and fixed-response actions are not supported. Listener rules that match on the client address, or answer with a fixed response, have no URL-map mapping.
• Lambda target groups are not supported. A function deployed behind a separate HTTP or serverless backend does not become an AWS Lambda target registration.
• Cookie stickiness behaves differently: affinity lasts at most one day. Generated-cookie affinity has a one-day maximum. Review any longer AWS cookie lifetime before moving.
• Health checks behave differently: Google requires 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 the status requirement.
• Blocked clients behave differently: Cloud Armor answers HTTP 403. An AWS security group drops the connection; a request outside the allowed ranges here receives a 403 response instead.
• Cloud Armor enforcement supports only IPv4 HTTP listeners and 10 client ranges. Each listener may allow at most 10 client CIDR ranges. Redirect actions are rejected on a protected listener, because a redirect would be answered without the policy being checked.
• You must provide access control if you leave security groups unenforced. With that choice, the security groups do not filter clients at the load balancer. Supply and verify the access control you need separately.

​

Other considerations

Before going live. Deploy the adapter with permission to manage load balancers and their network resources in the customer’s cloud account. Your AWS credentials authorize the management calls; the adapter uses the target cloud’s credentials to apply them. Set public or private exposure, client access rules, backend access and health-check access together. Moving from AWS. Prepare DNS records and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build, but external DNS and clients still need to be switched. At the Max tier the adapter also keeps the AWS identities your management calls use. Check certificates, routing, health checks and a complete client request before changing DNS, and keep the old load balancer running while existing connections drain. Application sessions and active connections are not copied.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

Load balancer data plane (ALB) · Processed load-balancer GiB per month

Feature: Load balancer data plane (ALB). Estimated monthly service charges by Processed load-balancer GiB per month. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
• This is an explicit data-plane workload comparison; the ELB management adapter alone cannot measure traffic.
• The selected per-GiB rate is a traffic-dominated ALB/NLB capacity assumption and does not reproduce multi-dimensional AWS LCU/NLCU billing.
• Load-balancer hours and processed GiB are billed as listed; connection, rule and capacity-unit dimensions beyond the base allocation need separate qualification. The base hour covers the first 5 forwarding rules (0.01/hour each after); Google bills processed GiB both inbound and outbound, so count both directions. Regional Application Load Balancers add 0.025/hour per proxy instance.
• AWS Price List API, AWSELB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json
• Cloud Load Balancing pricing: https://cloud.google.com/load-balancing/pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Connection/rule-driven capacity premiums, certificates, DNS, WAF, backend compute and separate internet egress.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-22dda3d1cf87f24c8e4d619aea8e5b01902ddd3c / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSELB offer, Cloud Load Balancing pricing. Load balancer data plane (ALB) → Cloud Load Balancing: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Connection/rule-driven capacity premiums, certificates, DNS, WAF, backend compute and separate internet egress.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 0 operations.
• Translated writes: 0 operations.
• Translated resident physical data: 0 GiB-month.
• Native provider operations: 0 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 730 resource-hour.
• Independent inventory: 0 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 1,000 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
• This is an explicit data-plane workload comparison; the ELB management adapter alone cannot measure traffic.
• The selected per-GiB rate is a traffic-dominated ALB/NLB capacity assumption and does not reproduce multi-dimensional AWS LCU/NLCU billing.
• Load-balancer hours and processed GiB are billed as listed; connection, rule and capacity-unit dimensions beyond the base allocation need separate qualification. The base hour covers the first 5 forwarding rules (0.01/hour each after); Google bills processed GiB both inbound and outbound, so count both directions. Regional Application Load Balancers add 0.025/hour per proxy instance.

List prices read: 2026-10-22. Model: plan-22dda3d1cf87f24c8e4d619aea8e5b01902ddd3c / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AWSELB offer, Cloud Load Balancing pricing.

​

On Azure

​

How it works

When a deployment provides the runtime AWS load-balancing API, your application and Terraform keep using that API. The Tensor9 adapter answers those calls (CreateLoadBalancer, CreateListener, RegisterTargets and the rest), keeps the AWS load balancer, listener and target group identities, saves each change and applies it to Azure Application Gateway. A target group is the set of backends a listener forwards traffic to. That runtime design is separate from translating a stack to native load-balancer resources. A designed runtime model does not establish that the deployment can serve it, and a missing native mapping does not silently select a runtime fallback. Confirm the selected deployment supports the required path. Client traffic does not pass through the adapter. Clients connect to the cloud load balancer, which forwards requests to your backends. A management call can return success before the cloud change has finished; the adapter keeps the requested configuration and finishes applying it in the background. Wait until the load balancer is available and check the cloud resources before sending production traffic.

Management calls go through the adapter; client traffic goes straight to the cloud load balancer.

​

Application Gateway resources

An ALB maps to Application Gateway v2. Its listeners accept HTTP or HTTPS, backend pools stand in for target groups, and routing rules choose a pool: host conditions become multi-site listeners and path conditions become path rules. The gateway runs in its own subnet. An ALB does not also need an Azure Standard Load Balancer. HTTPS uses a certificate stored in Azure Key Vault. Multi-site setups, Server Name Indication (SNI) and Application Gateway’s mutual TLS work with it. Each backend setting has a health probe, which keeps the target group’s path, expected status codes, interval, timeout, unhealthy threshold and explicit port. Application Gateway can also match on the response body; that is an extra Azure option, not an AWS setting you need to recreate.

​

Client access

The adapter enforces the supported rules of the security groups on the load balancer through a network security group (NSG) on the gateway’s subnet. The NSG allows the security groups’ IPv4 client ranges on the listener ports. Azure also requires the subnet to allow GatewayManager traffic on ports 65200-65535, AzureLoadBalancer health traffic, and unrestricted outbound access. Because the subnet holds only the gateway, these rules do not change any other workload’s access. A security group rule the NSG cannot express is rejected. The gateway becomes available only after its NSG is in place.

​

Deployment availability

This runtime design does not establish a working native stack translation or an available runtime deployment. A stack combining this load balancer, EC2 instances and a VPC is not currently available on this target. A missing native mapping does not automatically enable the runtime API. Use a supported configuration or author the native load-balancer resources separately.

​

Targets and health checks

For a deployment that serves the runtime API, RegisterTargets and DeregisterTargets add and remove backends from a target group. An instance ID is resolved from the EC2 instances the adapter knows about; an IP registration names the backend’s address and port. The target group, the load balancer and the backend must be on networks that can reach each other. The adapter applies a listener only after its target group and network are ready. The cloud load balancer’s own health checks decide which backends receive traffic. A registered target is not proof that its application is ready: check the cloud provider’s health status and send a real application request first. DescribeTargetHealth reports the cloud load balancer’s probe results, read once per health-check interval, in AWS’s states and reason codes: initial while checks start, then healthy or unhealthy. If the adapter has not been able to read health for three intervals, it reports unavailable. Drain connections before you deregister backends or delete a load balancer. Removing configuration does not move active connections to a replacement.

​

Limitations

• Header, method, query and source-IP conditions are not supported. Only host and path conditions are mapped to Application Gateway routing rules.
• Weighted target groups and fixed responses are not supported. A listener rule that splits traffic between target groups by weight, or answers with a fixed response, has no Application Gateway mapping.
• gRPC to backends is not supported. Application Gateway forwards HTTP and HTTPS to the backend pools; gRPC backends are not part of this mapping.
• Cookie stickiness behaves differently: affinity lasts for the browser session. Application Gateway has no setting for the cookie’s lifetime, so an AWS stickiness duration is not kept.
• Login at the load balancer is not supported. Listener OIDC or OAuth authenticate actions are not mapped. Handle login in your application or an identity-aware proxy.
• You must put the certificate in Azure Key Vault. An ACM certificate ARN is only a reference; it does not carry the certificate and private key. Import or issue the certificate in Key Vault for the gateway to use.
• You must give the gateway its own subnet. The subnet must allow the Azure management and health traffic above and unrestricted outbound access, so it cannot be shared with other workloads.

​

Other considerations

Before going live. Deploy the adapter with permission to manage load balancers and their network resources in the customer’s cloud account. Your AWS credentials authorize the management calls; the adapter uses the target cloud’s credentials to apply them. Set public or private exposure, client access rules, backend access and health-check access together. Moving from AWS. Prepare DNS records and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build, but external DNS and clients still need to be switched. At the Max tier the adapter also keeps the AWS identities your management calls use. Check certificates, routing, health checks and a complete client request before changing DNS, and keep the old load balancer running while existing connections drain. Application sessions and active connections are not copied.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

Load balancer data plane (ALB) · Processed load-balancer GiB per month

Feature: Load balancer data plane (ALB). Estimated monthly service charges by Processed load-balancer GiB per month. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: Global; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → Global, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
• This is an explicit data-plane workload comparison; the ELB management adapter alone cannot measure traffic.
• The selected per-GiB rate is a traffic-dominated ALB/NLB capacity assumption and does not reproduce multi-dimensional AWS LCU/NLCU billing.
• Load-balancer hours and processed GiB are billed as listed; connection, rule and capacity-unit dimensions beyond the base allocation need separate qualification. The base hour includes 5 rules; each additional rule lists USD 0.01/hour.
• AWS Price List API, AWSELB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Connection/rule-driven capacity premiums, certificates, DNS, WAF, backend compute and separate internet egress.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-7ab742b570a9e0cea8d6cac36a5f6827160a3584 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSELB offer, Azure Retail Prices API. Load balancer data plane (ALB) → Azure Load Balancer: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: Global. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Connection/rule-driven capacity premiums, certificates, DNS, WAF, backend compute and separate internet egress.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 0 operations.
• Translated writes: 0 operations.
• Translated resident physical data: 0 GiB-month.
• Native provider operations: 0 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 730 resource-hour.
• Independent inventory: 0 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 1,000 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
• This is an explicit data-plane workload comparison; the ELB management adapter alone cannot measure traffic.
• The selected per-GiB rate is a traffic-dominated ALB/NLB capacity assumption and does not reproduce multi-dimensional AWS LCU/NLCU billing.
• Load-balancer hours and processed GiB are billed as listed; connection, rule and capacity-unit dimensions beyond the base allocation need separate qualification. The base hour includes 5 rules; each additional rule lists USD 0.01/hour.

List prices read: 2026-10-22. Model: plan-7ab742b570a9e0cea8d6cac36a5f6827160a3584 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AWSELB offer, Azure Retail Prices API.

​

On OCI

​

How it works

When a deployment provides the runtime AWS load-balancing API, your application and Terraform keep using that API. The Tensor9 adapter answers those calls (CreateLoadBalancer, CreateListener, RegisterTargets and the rest), keeps the AWS load balancer, listener and target group identities, saves each change and applies it to an OCI Flexible Load Balancer. A target group is the set of backends a listener forwards traffic to. That runtime design is separate from translating a stack to native load-balancer resources. A designed runtime model does not establish that the deployment can serve it, and a missing native mapping does not silently select a runtime fallback. Confirm the selected deployment supports the required path. Client traffic does not pass through the adapter. Clients connect to the cloud load balancer, which forwards requests to your backends. A management call can return success before the cloud change has finished; the adapter keeps the requested configuration and finishes applying it in the background. Wait until the load balancer is available and check the cloud resources before sending production traffic.

Management calls go through the adapter; client traffic goes straight to the cloud load balancer.

​

Listeners, backend sets and routing

Each ALB listener becomes an OCI listener, and each target group becomes a backend set. The listener’s default action selects its backend set. Path, host, header and query conditions become a routing policy per listener, matched in rule-priority order. The load balancer’s bandwidth starts at a range of 10-100 Mbps; adjust it for your traffic. The target network replaces the AWS multi-subnet layout, so confirm whether the load balancer is public or private and that its subnet and security rules let the intended clients and backends through. Backend sets keep the health-check path, response codes, interval, timeout, port and consecutive-failure count; the default path is /. Cookie persistence keeps the configured duration.

​

HTTPS and certificates

An ACM certificate ARN identifies an AWS certificate; it does not carry the certificate and private key that OCI needs. When your stack is translated, an HTTPS listener is therefore created as an HTTP listener. To serve HTTPS, provision or import the certificate in OCI (OCI Certificates or the load balancer’s certificate settings) and attach it to the listener before you send HTTPS traffic. Backend TLS is a separate setting: enabling it does not secure a frontend that is still HTTP. Test the client TLS handshake and the backend connection before cutover.

​

Targets in a translated stack

Supported instance attachments become native OCI backends using each migrated instance’s private address and effective registered port. The load balancer uses the compiled subnet where that network mapping is available; otherwise review the supplied native subnet and reachability. A health check set to follow traffic uses each registered backend’s traffic port, while an explicit literal health port is kept. Auto Scaling replicas are not attached by this mapping. A supported target is a direct reference to the ID of an instance translated in this stack. IP and Lambda targets, conditional or computed target selection, unmapped instances and unsupported fleet attachments are reported and left unwired; those targets receive no traffic or health checks. A computed or invalid attachment or health-check port is refused rather than replaced with a default. Check every warning and send a complete application request before switching traffic. Scaleway load balancers and Akamai NodeBalancers do not receive translated instance targets through this mapping. Their missing attachments are reported; configure the native backends before expecting them to serve traffic.

​

Targets and health checks

For a deployment that serves the runtime API, RegisterTargets and DeregisterTargets add and remove backends from a target group. An instance ID is resolved from the EC2 instances the adapter knows about; an IP registration names the backend’s address and port. The target group, the load balancer and the backend must be on networks that can reach each other. The adapter applies a listener only after its target group and network are ready. The cloud load balancer’s own health checks decide which backends receive traffic. A registered target is not proof that its application is ready: check the cloud provider’s health status and send a real application request first. DescribeTargetHealth answers from the adapter’s saved records of registration and zone eligibility. A healthy result does not mean the cloud load balancer’s probe succeeded, so check the backend health in the cloud provider’s console or API as well. Drain connections before you deregister backends or delete a load balancer. Removing configuration does not move active connections to a replacement.

​

Limitations

• HTTPS listeners behave differently: they start as HTTP. An HTTP listener cannot accept a TLS connection. HTTPS works only after you attach an OCI certificate to the listener.
• SNI certificate lists are not supported. Each listener uses one certificate. Additional certificates on an AWS listener are reported and not carried over.
• Method and source-IP conditions, weighted target groups and fixed responses are not supported. OCI backend-set server weights do not reproduce a listener rule that splits traffic between target groups.
• Login at the load balancer is not supported. Listener OIDC and OAuth authenticate actions are not mapped. Handle login in your application or an identity-aware proxy.
• HTTPS health checks behave differently: they probe over HTTP. HTTP and HTTPS health checks become HTTP probes; other checks use TCP.
• Access logs, idle timeout, deletion protection and WAF attachment are not supported. These AWS settings are reported for review. Set up logging and the other settings on the OCI side yourself.
• The AWS hostname is not kept. Clients must resolve to the OCI address. An AWS hosted-zone ID is not an OCI identifier, and stack references to AWS-specific identifiers with no OCI equivalent are rejected or removed with a reported issue.

​

Other considerations

Before going live. Deploy the adapter with permission to manage load balancers and their network resources in the customer’s cloud account. Your AWS credentials authorize the management calls; the adapter uses the target cloud’s credentials to apply them. Set public or private exposure, client access rules, backend access and health-check access together. Moving from AWS. Prepare DNS records and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build, but external DNS and clients still need to be switched. At the Max tier the adapter also keeps the AWS identities your management calls use. Check certificates, routing, health checks and a complete client request before changing DNS, and keep the old load balancer running while existing connections drain. Application sessions and active connections are not copied.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

Load balancer data plane (ALB) · Processed load-balancer GiB per month

Feature: Load balancer data plane (ALB). Estimated monthly service charges by Processed load-balancer GiB per month. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
• This is an explicit data-plane workload comparison; the ELB management adapter alone cannot measure traffic.
• The selected per-GiB rate is a traffic-dominated ALB/NLB capacity assumption and does not reproduce multi-dimensional AWS LCU/NLCU billing.
• Load-balancer hours and processed GiB are billed as listed; connection, rule and capacity-unit dimensions beyond the base allocation need separate qualification. OCI bills no per-GB data on the load balancer; one Always Free load balancer (744 hours, 10 Mbps) is not applied.
• AWS Price List API, AWSELB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json
• OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/
• OCI price list: https://www.oracle.com/cloud/price-list/

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Connection/rule-driven capacity premiums, certificates, DNS, WAF, backend compute and separate internet egress.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-0f66cd013083c87f34306b14f0781fe947bf1e76 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSELB offer, OCI price list API, OCI price list. Load balancer data plane (ALB) → OCI Load Balancer: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-ashburn-1. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Connection/rule-driven capacity premiums, certificates, DNS, WAF, backend compute and separate internet egress.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 0 operations.
• Translated writes: 0 operations.
• Translated resident physical data: 0 GiB-month.
• Native provider operations: 0 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 730 resource-hour.
• Independent inventory: 0 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 1,000 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
• This is an explicit data-plane workload comparison; the ELB management adapter alone cannot measure traffic.
• The selected per-GiB rate is a traffic-dominated ALB/NLB capacity assumption and does not reproduce multi-dimensional AWS LCU/NLCU billing.
• Load-balancer hours and processed GiB are billed as listed; connection, rule and capacity-unit dimensions beyond the base allocation need separate qualification. OCI bills no per-GB data on the load balancer; one Always Free load balancer (744 hours, 10 Mbps) is not applied.

List prices read: 2026-10-22. Model: plan-0f66cd013083c87f34306b14f0781fe947bf1e76 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AWSELB offer, OCI price list API, OCI price list.

​

Costs

Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model’s cost curve. Adapter hosting and Tensor9 fees are excluded. How Tensor9 estimates costs explains the method, what the estimates include and how to read their qualifications. Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row’s difference at its stated workload rather than charges across rows. Cost curves across workload sizes, with every assumption and exclusion: Application Load Balancer costs.

​

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

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. 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 (adapter-added). DescribeListeners, DescribeLoadBalancers, DescribeTargetGroups, DescribeTargetHealth. Bounded desired and observed status lookup. Listener, target and topology mutation: +18 ms monthly p99 (adapter-added). CreateListener, CreateTargetGroup, ModifyListener, ModifyTargetGroup. Validation and durable desired-state mutation. Bounded routing and authorization policy: +25 ms monthly p99 (adapter-added). 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.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

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. Use tensor9 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

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. 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 (adapter-added). DescribeListeners, DescribeLoadBalancers, DescribeTargetGroups, DescribeTargetHealth. Bounded desired and observed status lookup. Listener, target and topology mutation: +18 ms monthly p99 (adapter-added). CreateListener, CreateTargetGroup, ModifyListener, ModifyTargetGroup. Validation and durable desired-state mutation. Bounded routing and authorization policy: +25 ms monthly p99 (adapter-added). 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.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

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. Use tensor9 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

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. 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 (adapter-added). DescribeListeners, DescribeLoadBalancers, DescribeTargetGroups, DescribeTargetHealth. Bounded desired and observed status lookup. Listener, target and topology mutation: +18 ms monthly p99 (adapter-added). CreateListener, CreateLoadBalancer, CreateTargetGroup, DeregisterTargets, ModifyListener, ModifyTargetGroup, RegisterTargets. Validation and durable desired-state mutation. Bounded routing and authorization policy: +25 ms monthly p99 (adapter-added). 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.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

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. Use tensor9 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.

​

Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.