> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Network Load Balancer

> Network Load Balancer APIs with Cloud Adapter.

This page describes how Network Load Balancer maps to services in the environment where the application runs, including backend choices, supported operations and service-specific behavior.

## Supported environments

* Azure
* DigitalOcean
* Google Cloud
* OCI
* Scaleway

Check the operation and capability tables for the behavior your application depends on. A supported environment does not imply that every operation of the origin service is available.

## How the backends compare

Each row compares a capability of Network Load Balancer with its adaptation on each backend.
A dash means this profile does not state the capability for that backend.

### Cloud Adapter

| Capability | Network Load Balancer | Azure | DigitalOcean | Google Cloud | OCI | Scaleway |
| - | - | - | - | - | - | - |
| Traffic path | AWS network load balancer | Azure Standard Load Balancer; Application Gateway with a TLS listener | DigitalOcean Load Balancer | Google passthrough Network Load Balancer | OCI Network Load Balancer | - |
| TLS termination | Optional TLS listener | Application Gateway TLS proxy | Backend termination | Native TCP passthrough; global TLS proxy on the runtime API path | Backend termination | - |
| Static addressing | Elastic IP | Static Standard public IP | Stable allocated IP; not pre-reserved | Regional reserved address | OCI reserved addresses | - |
| Client address | Client-IP preservation | Preserved, except behind the TLS proxy | Native preservation unavailable | Native passthrough preserves it; a runtime TLS proxy does not | Client IP preserved | - |
| Health checks | Per target group | TCP or HTTP(S) probes | One per load balancer | Native: one shared probe; runtime API: per backend service | Per backend set | - |
| Client endpoint | AWS hostname | Target cloud address | Target cloud address | Target cloud address | Target cloud address | - |
| API coverage | full | partial | partial | partial | partial | partial |

## On Azure

### Azure Load Balancer

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Client IP preservation | Addressing | Partial | Most usage | Standard Load Balancer passes the original client source address to the backend. On a load balancer with a TLS listener, the Application Gateway proxy connects to the backends, so they see the gateway's address. |
| Static addresses | Addressing | Supported | Most usage | Static Standard public addresses provide a stable frontend. |
| Health checks | Backends | Supported | Common | TCP or HTTP(S) probes are associated with load-balancing rules. |
| Access logs | Configuration | Out of scope | Full surface | Azure Monitor provides metrics and health-event logs; this load balancer does not provide AWS-style per-request access logs. |
| Load balancer address | Consumers | Supported | Common | Clients use the Azure address. Supported references in an infrastructure translation are updated during the build. |
| Traffic forwarding | Data plane | Supported | Common | Azure Standard Load Balancer forwards traffic directly to the backends. |
| TCP / UDP listeners | Listeners | Supported | Common | TCP and UDP use native rules. Preserving a combined listener on one port requires rules for both protocols; Azure All is an internal HA-ports mode, not a port-scoped public rule. A UDP or TCP\_UDP listener on a load balancer that also has a TLS listener is rejected. |
| TLS listeners | Listeners | Partial | Most usage | A TLS listener moves the load balancer onto an Azure Application Gateway TLS proxy, which ends TLS with the listener's certificate from Key Vault. All of the load balancer's listeners move with it, and backends see the gateway's address instead of the client's. |

#### 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 Standard 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.

![Your AWS load-balancing API calls go to the Tensor9 adapter, which saves them and applies them to the cloud resources. Client traffic goes straight to the cloud load balancer, which forwards it to your backends.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NjAiIGhlaWdodD0iMjM2IiB2aWV3Qm94PSIwIDAgNzYwIDIzNiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJZb3VyIEFXUyBsb2FkLWJhbGFuY2luZyBBUEkgY2FsbHMgZ28gdG8gdGhlIFRlbnNvcjkgYWRhcHRlciwgd2hpY2ggc2F2ZXMgdGhlbSBhbmQgYXBwbGllcyB0aGVtIHRvIHRoZSBjbG91ZCByZXNvdXJjZXMuIENsaWVudCB0cmFmZmljIGdvZXMgc3RyYWlnaHQgdG8gdGhlIGNsb3VkIGxvYWQgYmFsYW5jZXIsIHdoaWNoIGZvcndhcmRzIGl0IHRvIHlvdXIgYmFja2VuZHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImxiLXJ1bnRpbWUtYXJyb3ciIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIHJlZlg9IjYiIHJlZlk9IjMiIG9yaWVudD0iYXV0byI+PHBhdGggZD0iTTAgMCBMNiAzIEwwIDYiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxnIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNsYi1ydW50aW1lLWFycm93KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIj48cGF0aCBkPSJNMjIyIDY2IEgyNzAiLz48cGF0aCBkPSJNNDkwIDY2IEg1MzgiLz48cGF0aCBkPSJNMjIyIDE3NiBIMjcwIi8+PHBhdGggZD0iTTQ5MCAxNzYgSDUzOCIvPjwvZz4KPGcgc3R5bGU9InN0cm9rZTojY2JkNWUxIj48cmVjdCB4PSIxNiIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjUzOCIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjE2IiB5PSIxNDIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjUzOCIgeT0iMTQyIiB3aWR0aD0iMjA2IiBoZWlnaHQ9IjY4IiByeD0iMTAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz48L2c+CjxnIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyI+PHJlY3QgeD0iMjcwIiB5PSIzMiIgd2lkdGg9IjIyMCIgaGVpZ2h0PSI2OCIgcng9IjEwIiBzdHlsZT0iZmlsbDojZWNmZGY1Ii8+PHJlY3QgeD0iMjcwIiB5PSIxNDIiIHdpZHRoPSIyMjAiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2VjZmRmNSIvPjwvZz4KPGcgZm9udC1mYW1pbHk9IkludGVyLCBzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZmlsbDojMGYxNzJhIj48dGV4dCB4PSIxMTkiIHk9IjYwIj5BcHBsaWNhdGlvbiAvIFRlcnJhZm9ybTwvdGV4dD48dGV4dCB4PSIxMTkiIHk9IjgxIj5BV1MgbG9hZC1iYWxhbmNpbmcgQVBJPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iNjAiPlRlbnNvcjkgYWRhcHRlcjwvdGV4dD48dGV4dCB4PSIzODAiIHk9IjgxIj5TYXZlcyBhbmQgYXBwbGllcyBjaGFuZ2VzPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iNjAiPkNsb3VkIHJlc291cmNlczwvdGV4dD48dGV4dCB4PSI2NDEiIHk9IjgxIj5MaXN0ZW5lcnMgYW5kIGJhY2tlbmRzPC90ZXh0Pjx0ZXh0IHg9IjExOSIgeT0iMTgxIj5DbGllbnRzPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iMTgxIj5DbG91ZCBsb2FkIGJhbGFuY2VyPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iMTgxIj5BcHBsaWNhdGlvbiBiYWNrZW5kczwvdGV4dD48L2c+Cjwvc3ZnPg==)

![Your AWS load-balancing API calls go to the Tensor9 adapter, which saves them and applies them to the cloud resources. Client traffic goes straight to the cloud load balancer, which forwards it to your backends.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NjAiIGhlaWdodD0iMjM2IiB2aWV3Qm94PSIwIDAgNzYwIDIzNiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJZb3VyIEFXUyBsb2FkLWJhbGFuY2luZyBBUEkgY2FsbHMgZ28gdG8gdGhlIFRlbnNvcjkgYWRhcHRlciwgd2hpY2ggc2F2ZXMgdGhlbSBhbmQgYXBwbGllcyB0aGVtIHRvIHRoZSBjbG91ZCByZXNvdXJjZXMuIENsaWVudCB0cmFmZmljIGdvZXMgc3RyYWlnaHQgdG8gdGhlIGNsb3VkIGxvYWQgYmFsYW5jZXIsIHdoaWNoIGZvcndhcmRzIGl0IHRvIHlvdXIgYmFja2VuZHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImxiLXJ1bnRpbWUtYXJyb3ciIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIHJlZlg9IjYiIHJlZlk9IjMiIG9yaWVudD0iYXV0byI+PHBhdGggZD0iTTAgMCBMNiAzIEwwIDYiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxnIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNsYi1ydW50aW1lLWFycm93KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ij48cGF0aCBkPSJNMjIyIDY2IEgyNzAiLz48cGF0aCBkPSJNNDkwIDY2IEg1MzgiLz48cGF0aCBkPSJNMjIyIDE3NiBIMjcwIi8+PHBhdGggZD0iTTQ5MCAxNzYgSDUzOCIvPjwvZz4KPGcgc3R5bGU9InN0cm9rZTojNDc1NTY5Ij48cmVjdCB4PSIxNiIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjUzOCIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjE2IiB5PSIxNDIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjUzOCIgeT0iMTQyIiB3aWR0aD0iMjA2IiBoZWlnaHQ9IjY4IiByeD0iMTAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz48L2c+CjxnIHN0eWxlPSJzdHJva2U6IzZlZTdiNyI+PHJlY3QgeD0iMjcwIiB5PSIzMiIgd2lkdGg9IjIyMCIgaGVpZ2h0PSI2OCIgcng9IjEwIiBzdHlsZT0iZmlsbDojMDY0ZTNiIi8+PHJlY3QgeD0iMjcwIiB5PSIxNDIiIHdpZHRoPSIyMjAiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzA2NGUzYiIvPjwvZz4KPGcgZm9udC1mYW1pbHk9IkludGVyLCBzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZmlsbDojZjFmNWY5Ij48dGV4dCB4PSIxMTkiIHk9IjYwIj5BcHBsaWNhdGlvbiAvIFRlcnJhZm9ybTwvdGV4dD48dGV4dCB4PSIxMTkiIHk9IjgxIj5BV1MgbG9hZC1iYWxhbmNpbmcgQVBJPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iNjAiPlRlbnNvcjkgYWRhcHRlcjwvdGV4dD48dGV4dCB4PSIzODAiIHk9IjgxIj5TYXZlcyBhbmQgYXBwbGllcyBjaGFuZ2VzPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iNjAiPkNsb3VkIHJlc291cmNlczwvdGV4dD48dGV4dCB4PSI2NDEiIHk9IjgxIj5MaXN0ZW5lcnMgYW5kIGJhY2tlbmRzPC90ZXh0Pjx0ZXh0IHg9IjExOSIgeT0iMTgxIj5DbGllbnRzPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iMTgxIj5DbG91ZCBsb2FkIGJhbGFuY2VyPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iMTgxIj5BcHBsaWNhdGlvbiBiYWNrZW5kczwvdGV4dD48L2c+Cjwvc3ZnPg==)

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

#### Frontend, rules and backend pool

The Standard Load Balancer has a frontend address, one load-balancing rule per listener, a backend address pool and health probes. TCP and UDP listeners keep their protocol and port. A public frontend uses a static Standard public IP; an internal frontend uses a private address in your subnet. A zone-redundant deployment can reach backends in all of the region's zones; check the frontend and backend placement for your network.

Azure keeps the client's source IP, so your backend can use the original address for access control and logging. Connections are spread by source and destination address, source and destination port, and protocol.

TCP, HTTP or HTTPS probes are attached to the load-balancing rules and keep the interval, port, path and failure threshold. Allow AzureLoadBalancer health traffic, as well as client traffic, in the backends' network security rules. Azure Monitor provides load balancer metrics and health-event logs.

#### 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

* **TLS listeners behave differently: they move the load balancer onto Application Gateway.** Standard Load Balancer does not end TLS, so a TLS listener puts every listener of that load balancer on an Application Gateway TLS proxy, which ends TLS with the certificate from Key Vault. Backends then see the gateway's address, not the client's.
* **UDP listeners beside a TLS listener are not supported.** The Application Gateway TLS proxy carries only TCP and TLS, so a UDP or TCP\_UDP listener on a load balancer that also has a TLS listener is rejected.
* **Combined TCP+UDP listeners behave differently: they need two rules.** A TCP\_UDP listener on one port becomes separate TCP and UDP rules. Azure's All-protocol rule is an HA-ports rule for internal load balancers that covers every port, not a public listener on one port.
* **Security groups on the load balancer are not enforced.** Standard Load Balancer has no firewall of its own and passes each client's own address to the backend. A request that attaches security groups is rejected unless you tag the load balancer `t9:ack:degradation` = `load-balancer.firewall-policy-attachment`.
* **A backend rule that names the load balancer's security group is rejected.** On AWS such a rule admits what the load balancer forwards. Here that traffic arrives from the clients' addresses, so the rule would match none of it.
* **Per-request access logs are not supported.** Azure Monitor gives metrics and health events only. Collect request details at your backend.

#### 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 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

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

Feature: Load balancer data plane (NLB).

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.

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/bd16f382fbb12a90787fec8806aa47962f7e3ca225896de50b05441eef025724-light.svg)

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/ae9976505eda0a8444ba887ad2e5541bba6df9b052308abc4ba8dc4f28451507-dark.svg)

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.

| Processed load-balancer GiB per month (GiB/month) | Network Load Balancer | Azure Load Balancer | Difference |
| -: | -: | -: | -: |
| 0 | 16.43 | 18.25 | 1.83 |
| 100 | 17.03 | 18.75 | 1.73 |
| 1,000 | 22.43 | 23.25 | 0.83 |
| 10,000 | 76.43 | 68.25 | -8.18 |
| 100,000 | 616.43 | 518.25 | -98.18 |
| 1,000,000 | 6,016.43 | 5,018.25 | -998.18 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.005 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.025 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* 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](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](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-5bc3717e8cc96c99c769a6310d429e8864680a20` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [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).

**Load balancer data plane (NLB) → 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.

| Monthly component | USD |
| - | -: |
| Origin: Allocated load-balancer hours | 16.43 |
| Origin: Load-balancer processed bytes | 6.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 5.00 |
| Target: Independent native resources | 18.25 |
| Target: Independent native resources | 0.00 |
| **Origin service subtotal** | **22.43** |
| **Target service subtotal** | **23.25** |

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**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.005 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.025 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Allocated load-balancer hours | 730 | load-balancer-hour |
| Load-balancer processed bytes | 1,000 | GiB |

* 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-5bc3717e8cc96c99c769a6310d429e8864680a20` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [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).

## On DigitalOcean

### DigitalOcean Load Balancer

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Client IP preservation | Addressing | Out of scope | Most usage | This option does not preserve the client source IP natively. |
| Static addresses | Addressing | Out of scope | Most usage | The allocated IP is stable, but this option does not provide an Elastic IP reserved before creation. |
| Health checks | Backends | Partial | Common | One health check serves all backends. The mapping uses the first target group and reports conflicting checks. |
| Target registration | Backends | Partial | Most usage | Translated instance attachments populate one Droplet pool. Referenced target groups must have identical members, and every listener needs one uniform effective target port, including attachment overrides. Fleet attachments are not supported; runtime registration requires a deployment serving that API. |
| Network placement | Configuration | Partial | Full surface | DigitalOcean supports internal load balancers. Confirm the VPC and exposure explicitly; the AWS setting alone does not establish privacy. |
| Load balancer address | Consumers | Partial | Common | Clients use the load balancer IP. Supported hostname references are updated in the infrastructure translation. |
| Traffic forwarding | Data plane | Supported | Common | DigitalOcean forwards traffic through one native load balancer. |
| TCP / UDP listeners | Listeners | Supported | Common | TCP and UDP listeners each become a forwarding rule. |
| TLS listeners | Listeners | Out of scope | Most usage | This NLB option passes TLS through over TCP; the backend terminates the encrypted connection. |

#### 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 a DigitalOcean 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.

![Your AWS load-balancing API calls go to the Tensor9 adapter, which saves them and applies them to the cloud resources. Client traffic goes straight to the cloud load balancer, which forwards it to your backends.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NjAiIGhlaWdodD0iMjM2IiB2aWV3Qm94PSIwIDAgNzYwIDIzNiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJZb3VyIEFXUyBsb2FkLWJhbGFuY2luZyBBUEkgY2FsbHMgZ28gdG8gdGhlIFRlbnNvcjkgYWRhcHRlciwgd2hpY2ggc2F2ZXMgdGhlbSBhbmQgYXBwbGllcyB0aGVtIHRvIHRoZSBjbG91ZCByZXNvdXJjZXMuIENsaWVudCB0cmFmZmljIGdvZXMgc3RyYWlnaHQgdG8gdGhlIGNsb3VkIGxvYWQgYmFsYW5jZXIsIHdoaWNoIGZvcndhcmRzIGl0IHRvIHlvdXIgYmFja2VuZHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImxiLXJ1bnRpbWUtYXJyb3ciIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIHJlZlg9IjYiIHJlZlk9IjMiIG9yaWVudD0iYXV0byI+PHBhdGggZD0iTTAgMCBMNiAzIEwwIDYiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxnIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNsYi1ydW50aW1lLWFycm93KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIj48cGF0aCBkPSJNMjIyIDY2IEgyNzAiLz48cGF0aCBkPSJNNDkwIDY2IEg1MzgiLz48cGF0aCBkPSJNMjIyIDE3NiBIMjcwIi8+PHBhdGggZD0iTTQ5MCAxNzYgSDUzOCIvPjwvZz4KPGcgc3R5bGU9InN0cm9rZTojY2JkNWUxIj48cmVjdCB4PSIxNiIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjUzOCIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjE2IiB5PSIxNDIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjUzOCIgeT0iMTQyIiB3aWR0aD0iMjA2IiBoZWlnaHQ9IjY4IiByeD0iMTAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz48L2c+CjxnIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyI+PHJlY3QgeD0iMjcwIiB5PSIzMiIgd2lkdGg9IjIyMCIgaGVpZ2h0PSI2OCIgcng9IjEwIiBzdHlsZT0iZmlsbDojZWNmZGY1Ii8+PHJlY3QgeD0iMjcwIiB5PSIxNDIiIHdpZHRoPSIyMjAiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2VjZmRmNSIvPjwvZz4KPGcgZm9udC1mYW1pbHk9IkludGVyLCBzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZmlsbDojMGYxNzJhIj48dGV4dCB4PSIxMTkiIHk9IjYwIj5BcHBsaWNhdGlvbiAvIFRlcnJhZm9ybTwvdGV4dD48dGV4dCB4PSIxMTkiIHk9IjgxIj5BV1MgbG9hZC1iYWxhbmNpbmcgQVBJPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iNjAiPlRlbnNvcjkgYWRhcHRlcjwvdGV4dD48dGV4dCB4PSIzODAiIHk9IjgxIj5TYXZlcyBhbmQgYXBwbGllcyBjaGFuZ2VzPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iNjAiPkNsb3VkIHJlc291cmNlczwvdGV4dD48dGV4dCB4PSI2NDEiIHk9IjgxIj5MaXN0ZW5lcnMgYW5kIGJhY2tlbmRzPC90ZXh0Pjx0ZXh0IHg9IjExOSIgeT0iMTgxIj5DbGllbnRzPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iMTgxIj5DbG91ZCBsb2FkIGJhbGFuY2VyPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iMTgxIj5BcHBsaWNhdGlvbiBiYWNrZW5kczwvdGV4dD48L2c+Cjwvc3ZnPg==)

![Your AWS load-balancing API calls go to the Tensor9 adapter, which saves them and applies them to the cloud resources. Client traffic goes straight to the cloud load balancer, which forwards it to your backends.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NjAiIGhlaWdodD0iMjM2IiB2aWV3Qm94PSIwIDAgNzYwIDIzNiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJZb3VyIEFXUyBsb2FkLWJhbGFuY2luZyBBUEkgY2FsbHMgZ28gdG8gdGhlIFRlbnNvcjkgYWRhcHRlciwgd2hpY2ggc2F2ZXMgdGhlbSBhbmQgYXBwbGllcyB0aGVtIHRvIHRoZSBjbG91ZCByZXNvdXJjZXMuIENsaWVudCB0cmFmZmljIGdvZXMgc3RyYWlnaHQgdG8gdGhlIGNsb3VkIGxvYWQgYmFsYW5jZXIsIHdoaWNoIGZvcndhcmRzIGl0IHRvIHlvdXIgYmFja2VuZHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImxiLXJ1bnRpbWUtYXJyb3ciIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIHJlZlg9IjYiIHJlZlk9IjMiIG9yaWVudD0iYXV0byI+PHBhdGggZD0iTTAgMCBMNiAzIEwwIDYiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxnIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNsYi1ydW50aW1lLWFycm93KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ij48cGF0aCBkPSJNMjIyIDY2IEgyNzAiLz48cGF0aCBkPSJNNDkwIDY2IEg1MzgiLz48cGF0aCBkPSJNMjIyIDE3NiBIMjcwIi8+PHBhdGggZD0iTTQ5MCAxNzYgSDUzOCIvPjwvZz4KPGcgc3R5bGU9InN0cm9rZTojNDc1NTY5Ij48cmVjdCB4PSIxNiIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjUzOCIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjE2IiB5PSIxNDIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjUzOCIgeT0iMTQyIiB3aWR0aD0iMjA2IiBoZWlnaHQ9IjY4IiByeD0iMTAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz48L2c+CjxnIHN0eWxlPSJzdHJva2U6IzZlZTdiNyI+PHJlY3QgeD0iMjcwIiB5PSIzMiIgd2lkdGg9IjIyMCIgaGVpZ2h0PSI2OCIgcng9IjEwIiBzdHlsZT0iZmlsbDojMDY0ZTNiIi8+PHJlY3QgeD0iMjcwIiB5PSIxNDIiIHdpZHRoPSIyMjAiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzA2NGUzYiIvPjwvZz4KPGcgZm9udC1mYW1pbHk9IkludGVyLCBzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZmlsbDojZjFmNWY5Ij48dGV4dCB4PSIxMTkiIHk9IjYwIj5BcHBsaWNhdGlvbiAvIFRlcnJhZm9ybTwvdGV4dD48dGV4dCB4PSIxMTkiIHk9IjgxIj5BV1MgbG9hZC1iYWxhbmNpbmcgQVBJPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iNjAiPlRlbnNvcjkgYWRhcHRlcjwvdGV4dD48dGV4dCB4PSIzODAiIHk9IjgxIj5TYXZlcyBhbmQgYXBwbGllcyBjaGFuZ2VzPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iNjAiPkNsb3VkIHJlc291cmNlczwvdGV4dD48dGV4dCB4PSI2NDEiIHk9IjgxIj5MaXN0ZW5lcnMgYW5kIGJhY2tlbmRzPC90ZXh0Pjx0ZXh0IHg9IjExOSIgeT0iMTgxIj5DbGllbnRzPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iMTgxIj5DbG91ZCBsb2FkIGJhbGFuY2VyPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iMTgxIj5BcHBsaWNhdGlvbiBiYWNrZW5kczwvdGV4dD48L2c+Cjwvc3ZnPg==)

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

#### Forwarding rules and the Droplet pool

TCP and UDP listeners become forwarding rules over a single Droplet pool. The load balancer gets a stable IP address once it is created. DigitalOcean supports internal load balancers; confirm the target VPC and the public or internal setting yourself, because the AWS setting alone does not make the translated load balancer private.

#### Targets in a translated stack

Supported instance attachments add the migrated Droplets to one native pool. All referenced target groups must have identical members. Each listener can keep one uniform effective backend port, including a shared attachment override; mixed target ports or different target-group membership are refused. The whole load balancer still has one health check, selected from the first target group, so its protocol, path and port must work for every Droplet. 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

* **TLS termination is not supported.** A TLS listener uses TCP passthrough, so your backend terminates TLS.
* **Combined TCP+UDP listeners behave differently: they become TCP.** When your stack is translated, a TCP\_UDP listener becomes a TCP forwarding rule, and the change is reported.
* **Client IP preservation is not supported.** Backends do not see the original client address natively. Review access rules, rate limits and logging that depend on it.
* **Health checks behave differently: one check for the whole load balancer.** Every rule shares one health check, taken from the first target group, and differences on other groups are reported. Choose a probe that works for all backends.
* **A pre-reserved Elastic IP is not supported.** The address is allocated when the load balancer is created. Prepare external DNS and allowlists after that.

#### 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 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

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

Feature: Load balancer data plane (NLB).

Estimated monthly service charges by Processed load-balancer GiB per month. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD.

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/322c4240f69718709807ef5d984a8ad2bda51b34e601f07c825a240f5352ad80-light.svg)

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/b87c9ab816754bff6cfc8583825d0c5202eb371ccf32f99c913ae13025ba6cc3-dark.svg)

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.

| Processed load-balancer GiB per month (GiB/month) | Network Load Balancer | DigitalOcean Load Balancer | Difference |
| -: | -: | -: | -: |
| 0 | 16.43 | 12.00 | -4.43 |
| 100 | 17.03 | 12.00 | -5.03 |
| 1,000 | 22.43 | 12.00 | -10.43 |
| 10,000 | 76.43 | 12.00 | -64.43 |
| 100,000 | 616.43 | 12.00 | -604.43 |
| 1,000,000 | 6,016.43 | 12.00 | -6,004.43 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.0164384 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* 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 → nyc, 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. Each regional node adds 10,000 requests/s and 10,000 connections; there is no per-GB processing charge.
* AWS Price List API, AWSELB offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json)
* DigitalOcean Load Balancer pricing: [https://www.digitalocean.com/pricing/load-balancers](https://www.digitalocean.com/pricing/load-balancers)

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-0fca853a6ed94af9771dc5aa5059424214ad1e65` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AWSELB offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json), [DigitalOcean Load Balancer pricing](https://www.digitalocean.com/pricing/load-balancers).

**Load balancer data plane (NLB) → DigitalOcean 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: nyc. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Allocated load-balancer hours | 16.43 |
| Origin: Load-balancer processed bytes | 6.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 12.00 |
| Target: Independent native resources | 0.00 |
| **Origin service subtotal** | **22.43** |
| **Target service subtotal** | **12.00** |

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**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.0164384 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Allocated load-balancer hours | 730 | load-balancer-hour |
| Load-balancer processed bytes | 1,000 | GiB |

* 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. Each regional node adds 10,000 requests/s and 10,000 connections; there is no per-GB processing charge.

List prices read: 2026-10-22. Model: `plan-0fca853a6ed94af9771dc5aa5059424214ad1e65` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AWSELB offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json), [DigitalOcean Load Balancer pricing](https://www.digitalocean.com/pricing/load-balancers).

## On Google Cloud

### Cloud Load Balancing

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Client IP preservation | Addressing | Partial | Most usage | Passthrough forwarding preserves the client source address at the backend. On the runtime API path, a TLS listener uses Google's proxy and backends see its address. A translated TLS listener remains TCP passthrough. |
| Static addresses | Addressing | Supported | Most usage | Google regional reserved addresses provide a stable frontend. A runtime API load balancer with a TLS proxy cannot use one; native translated TLS passes through without that proxy. |
| Health checks | Backends | Supported | Common | The runtime API supports TCP and HTTP health checks; HTTPS, SSL and gRPC are not offered. Native translation creates HTTP probes for HTTP/HTTPS settings and TCP probes otherwise; it does not reproduce every runtime probe protocol. |
| Targets in a translated stack | Backends | Partial | Common | Direct instance attachments and supported Auto Scaling groups join native backends. Referenced target groups must have identical members. Passthrough preserves destination ports, so listener and registered backend ports must match. Health checks use the effective traffic port unless an explicit literal port is supplied. |
| Load balancer address | Consumers | Supported | Common | Clients use the Google address. Supported references in an infrastructure translation are updated during the build. |
| Traffic forwarding | Data plane | Supported | Common | Google's passthrough load balancer forwards client traffic directly to the backends. |
| TCP / UDP listeners | Listeners | Partial | Common | TCP listeners map to forwarding rules with the same port. On the runtime API path, UDP and TCP\_UDP listeners are rejected by the adapter. A Terraform translation without the adapter maps them to forwarding rules; TCP\_UDP then uses L3\_DEFAULT, which forwards all protocols on all ports. |
| TLS listeners | Listeners | Partial | Most usage | For a runtime API deployment, Google's global TLS proxy ends TLS with the listener's Certificate Manager certificate. A TLS listener moves the whole load balancer onto Google's global proxy load balancer, so backends see the proxy's addresses instead of the client's and a reserved regional address cannot be used. A Terraform translation without the adapter passes TLS through as TCP, with a build warning. |

#### 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's passthrough Network 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.

![Your AWS load-balancing API calls go to the Tensor9 adapter, which saves them and applies them to the cloud resources. Client traffic goes straight to the cloud load balancer, which forwards it to your backends.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NjAiIGhlaWdodD0iMjM2IiB2aWV3Qm94PSIwIDAgNzYwIDIzNiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJZb3VyIEFXUyBsb2FkLWJhbGFuY2luZyBBUEkgY2FsbHMgZ28gdG8gdGhlIFRlbnNvcjkgYWRhcHRlciwgd2hpY2ggc2F2ZXMgdGhlbSBhbmQgYXBwbGllcyB0aGVtIHRvIHRoZSBjbG91ZCByZXNvdXJjZXMuIENsaWVudCB0cmFmZmljIGdvZXMgc3RyYWlnaHQgdG8gdGhlIGNsb3VkIGxvYWQgYmFsYW5jZXIsIHdoaWNoIGZvcndhcmRzIGl0IHRvIHlvdXIgYmFja2VuZHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImxiLXJ1bnRpbWUtYXJyb3ciIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIHJlZlg9IjYiIHJlZlk9IjMiIG9yaWVudD0iYXV0byI+PHBhdGggZD0iTTAgMCBMNiAzIEwwIDYiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxnIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNsYi1ydW50aW1lLWFycm93KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIj48cGF0aCBkPSJNMjIyIDY2IEgyNzAiLz48cGF0aCBkPSJNNDkwIDY2IEg1MzgiLz48cGF0aCBkPSJNMjIyIDE3NiBIMjcwIi8+PHBhdGggZD0iTTQ5MCAxNzYgSDUzOCIvPjwvZz4KPGcgc3R5bGU9InN0cm9rZTojY2JkNWUxIj48cmVjdCB4PSIxNiIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjUzOCIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjE2IiB5PSIxNDIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjUzOCIgeT0iMTQyIiB3aWR0aD0iMjA2IiBoZWlnaHQ9IjY4IiByeD0iMTAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz48L2c+CjxnIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyI+PHJlY3QgeD0iMjcwIiB5PSIzMiIgd2lkdGg9IjIyMCIgaGVpZ2h0PSI2OCIgcng9IjEwIiBzdHlsZT0iZmlsbDojZWNmZGY1Ii8+PHJlY3QgeD0iMjcwIiB5PSIxNDIiIHdpZHRoPSIyMjAiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2VjZmRmNSIvPjwvZz4KPGcgZm9udC1mYW1pbHk9IkludGVyLCBzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZmlsbDojMGYxNzJhIj48dGV4dCB4PSIxMTkiIHk9IjYwIj5BcHBsaWNhdGlvbiAvIFRlcnJhZm9ybTwvdGV4dD48dGV4dCB4PSIxMTkiIHk9IjgxIj5BV1MgbG9hZC1iYWxhbmNpbmcgQVBJPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iNjAiPlRlbnNvcjkgYWRhcHRlcjwvdGV4dD48dGV4dCB4PSIzODAiIHk9IjgxIj5TYXZlcyBhbmQgYXBwbGllcyBjaGFuZ2VzPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iNjAiPkNsb3VkIHJlc291cmNlczwvdGV4dD48dGV4dCB4PSI2NDEiIHk9IjgxIj5MaXN0ZW5lcnMgYW5kIGJhY2tlbmRzPC90ZXh0Pjx0ZXh0IHg9IjExOSIgeT0iMTgxIj5DbGllbnRzPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iMTgxIj5DbG91ZCBsb2FkIGJhbGFuY2VyPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iMTgxIj5BcHBsaWNhdGlvbiBiYWNrZW5kczwvdGV4dD48L2c+Cjwvc3ZnPg==)

![Your AWS load-balancing API calls go to the Tensor9 adapter, which saves them and applies them to the cloud resources. Client traffic goes straight to the cloud load balancer, which forwards it to your backends.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NjAiIGhlaWdodD0iMjM2IiB2aWV3Qm94PSIwIDAgNzYwIDIzNiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJZb3VyIEFXUyBsb2FkLWJhbGFuY2luZyBBUEkgY2FsbHMgZ28gdG8gdGhlIFRlbnNvcjkgYWRhcHRlciwgd2hpY2ggc2F2ZXMgdGhlbSBhbmQgYXBwbGllcyB0aGVtIHRvIHRoZSBjbG91ZCByZXNvdXJjZXMuIENsaWVudCB0cmFmZmljIGdvZXMgc3RyYWlnaHQgdG8gdGhlIGNsb3VkIGxvYWQgYmFsYW5jZXIsIHdoaWNoIGZvcndhcmRzIGl0IHRvIHlvdXIgYmFja2VuZHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImxiLXJ1bnRpbWUtYXJyb3ciIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIHJlZlg9IjYiIHJlZlk9IjMiIG9yaWVudD0iYXV0byI+PHBhdGggZD0iTTAgMCBMNiAzIEwwIDYiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxnIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNsYi1ydW50aW1lLWFycm93KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ij48cGF0aCBkPSJNMjIyIDY2IEgyNzAiLz48cGF0aCBkPSJNNDkwIDY2IEg1MzgiLz48cGF0aCBkPSJNMjIyIDE3NiBIMjcwIi8+PHBhdGggZD0iTTQ5MCAxNzYgSDUzOCIvPjwvZz4KPGcgc3R5bGU9InN0cm9rZTojNDc1NTY5Ij48cmVjdCB4PSIxNiIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjUzOCIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjE2IiB5PSIxNDIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjUzOCIgeT0iMTQyIiB3aWR0aD0iMjA2IiBoZWlnaHQ9IjY4IiByeD0iMTAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz48L2c+CjxnIHN0eWxlPSJzdHJva2U6IzZlZTdiNyI+PHJlY3QgeD0iMjcwIiB5PSIzMiIgd2lkdGg9IjIyMCIgaGVpZ2h0PSI2OCIgcng9IjEwIiBzdHlsZT0iZmlsbDojMDY0ZTNiIi8+PHJlY3QgeD0iMjcwIiB5PSIxNDIiIHdpZHRoPSIyMjAiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzA2NGUzYiIvPjwvZz4KPGcgZm9udC1mYW1pbHk9IkludGVyLCBzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZmlsbDojZjFmNWY5Ij48dGV4dCB4PSIxMTkiIHk9IjYwIj5BcHBsaWNhdGlvbiAvIFRlcnJhZm9ybTwvdGV4dD48dGV4dCB4PSIxMTkiIHk9IjgxIj5BV1MgbG9hZC1iYWxhbmNpbmcgQVBJPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iNjAiPlRlbnNvcjkgYWRhcHRlcjwvdGV4dD48dGV4dCB4PSIzODAiIHk9IjgxIj5TYXZlcyBhbmQgYXBwbGllcyBjaGFuZ2VzPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iNjAiPkNsb3VkIHJlc291cmNlczwvdGV4dD48dGV4dCB4PSI2NDEiIHk9IjgxIj5MaXN0ZW5lcnMgYW5kIGJhY2tlbmRzPC90ZXh0Pjx0ZXh0IHg9IjExOSIgeT0iMTgxIj5DbGllbnRzPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iMTgxIj5DbG91ZCBsb2FkIGJhbGFuY2VyPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iMTgxIj5BcHBsaWNhdGlvbiBiYWNrZW5kczwvdGV4dD48L2c+Cjwvc3ZnPg==)

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

#### Forwarding rules and addresses

The following applies to a deployment serving the runtime API. The load balancer uses a reserved address, forwarding rules, a regional backend service and regional health checks. Each TCP listener becomes a forwarding rule with the same port. A public frontend uses a regional external address; an internal frontend uses an address on your subnet. The backend service can hold backends in all of the region's zones. AWS Availability Zone names do not carry over, so confirm placement and connectivity.

Traffic is passed straight through, so the backend sees the client's source IP without `X-Forwarded-For` or a proxy-protocol header. Connections are spread by source and destination address, source and destination port, and protocol.

The runtime API path supports TCP and HTTP health checks, retaining their supported port, path, interval, timeout and thresholds. HTTPS, SSL and gRPC checks are not offered by this adapter mapping. Allow both application traffic and health-check traffic in your firewall rules.

#### Targets in a translated stack

Direct instance attachments join the native instance group, and supported Auto Scaling groups join the backend service through their managed instance groups. Google passthrough preserves the destination port: each listener must use the effective registered target port, including any attachment override. All referenced target groups must register identical members; distinct membership is refused. The health check uses the registered traffic port unless you supply an explicit literal port. Fleet membership does not add application autohealing or establish that the application is ready. TLS listeners pass through over TCP with a build warning; the backend must terminate TLS. UDP listeners use passthrough forwarding, while a combined TCP\_UDP listener uses an all-protocol forwarding rule on all ports, so review its exposure. Native HTTP and HTTPS health-check settings become HTTP probes; other check protocols become TCP probes.

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` 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

These limits describe the runtime adapter. The translated-stack path above has its own listener and health-check behavior; it does not gain a TLS proxy or runtime management API from this description.

* **TLS listeners behave differently: they move the load balancer onto Google's global proxy.** Google's global TLS proxy ends TLS with the listener's Certificate Manager certificate. The whole load balancer moves with it, so backends see the proxy's address, not the client's, and a reserved regional address cannot be used.
* **UDP listeners are not supported.** The adapter rejects UDP and TCP\_UDP listeners on Google Cloud. Use TCP, or carry UDP traffic another way.
* **Security groups on the load balancer are not enforced.** Google firewall rules cannot express both the load balancer's and the backends' groups for passthrough traffic. A request that attaches security groups is rejected unless you tag the load balancer `t9:ack:degradation` = `load-balancer.firewall-policy-attachment`.
* **A backend rule that names the load balancer's security group is rejected.** On AWS such a rule admits what the load balancer forwards. Here that traffic arrives from the clients' own addresses, so the rule would match none of it.
* **Request-level logs are not supported.** Flow logs and backend-service logs describe network connections. They do not reproduce AWS TLS access logs or application request logs; collect those in your backend.

#### 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 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

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

Feature: Load balancer data plane (NLB).

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.

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/41a049ee0d79b29bb47202f452a0f13d5dc51b148b2b67cc72e10b0a973c3f4a-light.svg)

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/4f42869f7a7d0ea30c5aa8cae5f7261963094ed85f3c0d811d3054aabee9b808-dark.svg)

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.

| Processed load-balancer GiB per month (GiB/month) | Network Load Balancer | Cloud Load Balancing | Difference |
| -: | -: | -: | -: |
| 0 | 16.43 | 18.25 | 1.83 |
| 100 | 17.03 | 19.05 | 2.03 |
| 1,000 | 22.43 | 26.25 | 3.83 |
| 10,000 | 76.43 | 98.25 | 21.83 |
| 100,000 | 616.43 | 818.25 | 201.83 |
| 1,000,000 | 6,016.43 | 8,018.25 | 2,001.83 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.008 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.025 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* 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](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](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-aeadb280a6ff17d4b64eb541aed9fddde748c762` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [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).

**Load balancer data plane (NLB) → 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.

| Monthly component | USD |
| - | -: |
| Origin: Allocated load-balancer hours | 16.43 |
| Origin: Load-balancer processed bytes | 6.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 8.00 |
| Target: Independent native resources | 18.25 |
| Target: Independent native resources | 0.00 |
| **Origin service subtotal** | **22.43** |
| **Target service subtotal** | **26.25** |

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**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.008 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.025 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Allocated load-balancer hours | 730 | load-balancer-hour |
| Load-balancer processed bytes | 1,000 | GiB |

* 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-aeadb280a6ff17d4b64eb541aed9fddde748c762` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [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).

## On OCI

### OCI Network Load Balancer

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Client IP preservation | Addressing | Supported | Most usage | The backend receives the original client source address. |
| Static addresses | Addressing | Supported | Most usage | OCI reserved addresses provide a stable frontend. |
| Health checks | Backends | Supported | Common | Checks use the path, expected status, timeout, interval, and failure threshold. |
| Target registration | Backends | Partial | Most usage | Translated instance attachments register native backends at their private addresses and effective ports. Health checks following traffic use each registered backend's port. Fleet attachments are not supported. Runtime registration requires a deployment serving that API. |
| Cross-zone load balancing | Configuration | Supported | Full surface | The OCI load balancer is regional; backend placement spans the selected regional network. |
| Network placement | Configuration | Partial | Full surface | The target subnet arrangement replaces AWS multi-subnet placement. Verify public or private exposure. |
| Load balancer address | Consumers | Partial | Common | Clients use the OCI load-balancer address. The original AWS-managed hostname is not retained; infrastructure references to AWS-specific identifiers without an OCI equivalent are rejected or removed from outputs with a reported issue. |
| Traffic forwarding | Data plane | Supported | Common | OCI Network Load Balancer forwards traffic to the application backends. |
| TCP / UDP listeners | Listeners | Supported | Common | TCP, UDP, and mixed TCP+UDP listeners map to native OCI listeners. |
| TLS listeners | Listeners | Out of scope | Most usage | The network load balancer does not terminate TLS. Use TCP passthrough with TLS terminated by the backend. |

#### 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 OCI Network 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.

![Your AWS load-balancing API calls go to the Tensor9 adapter, which saves them and applies them to the cloud resources. Client traffic goes straight to the cloud load balancer, which forwards it to your backends.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NjAiIGhlaWdodD0iMjM2IiB2aWV3Qm94PSIwIDAgNzYwIDIzNiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJZb3VyIEFXUyBsb2FkLWJhbGFuY2luZyBBUEkgY2FsbHMgZ28gdG8gdGhlIFRlbnNvcjkgYWRhcHRlciwgd2hpY2ggc2F2ZXMgdGhlbSBhbmQgYXBwbGllcyB0aGVtIHRvIHRoZSBjbG91ZCByZXNvdXJjZXMuIENsaWVudCB0cmFmZmljIGdvZXMgc3RyYWlnaHQgdG8gdGhlIGNsb3VkIGxvYWQgYmFsYW5jZXIsIHdoaWNoIGZvcndhcmRzIGl0IHRvIHlvdXIgYmFja2VuZHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImxiLXJ1bnRpbWUtYXJyb3ciIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIHJlZlg9IjYiIHJlZlk9IjMiIG9yaWVudD0iYXV0byI+PHBhdGggZD0iTTAgMCBMNiAzIEwwIDYiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxnIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNsYi1ydW50aW1lLWFycm93KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIj48cGF0aCBkPSJNMjIyIDY2IEgyNzAiLz48cGF0aCBkPSJNNDkwIDY2IEg1MzgiLz48cGF0aCBkPSJNMjIyIDE3NiBIMjcwIi8+PHBhdGggZD0iTTQ5MCAxNzYgSDUzOCIvPjwvZz4KPGcgc3R5bGU9InN0cm9rZTojY2JkNWUxIj48cmVjdCB4PSIxNiIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjUzOCIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjE2IiB5PSIxNDIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPjxyZWN0IHg9IjUzOCIgeT0iMTQyIiB3aWR0aD0iMjA2IiBoZWlnaHQ9IjY4IiByeD0iMTAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz48L2c+CjxnIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyI+PHJlY3QgeD0iMjcwIiB5PSIzMiIgd2lkdGg9IjIyMCIgaGVpZ2h0PSI2OCIgcng9IjEwIiBzdHlsZT0iZmlsbDojZWNmZGY1Ii8+PHJlY3QgeD0iMjcwIiB5PSIxNDIiIHdpZHRoPSIyMjAiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6I2VjZmRmNSIvPjwvZz4KPGcgZm9udC1mYW1pbHk9IkludGVyLCBzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZmlsbDojMGYxNzJhIj48dGV4dCB4PSIxMTkiIHk9IjYwIj5BcHBsaWNhdGlvbiAvIFRlcnJhZm9ybTwvdGV4dD48dGV4dCB4PSIxMTkiIHk9IjgxIj5BV1MgbG9hZC1iYWxhbmNpbmcgQVBJPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iNjAiPlRlbnNvcjkgYWRhcHRlcjwvdGV4dD48dGV4dCB4PSIzODAiIHk9IjgxIj5TYXZlcyBhbmQgYXBwbGllcyBjaGFuZ2VzPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iNjAiPkNsb3VkIHJlc291cmNlczwvdGV4dD48dGV4dCB4PSI2NDEiIHk9IjgxIj5MaXN0ZW5lcnMgYW5kIGJhY2tlbmRzPC90ZXh0Pjx0ZXh0IHg9IjExOSIgeT0iMTgxIj5DbGllbnRzPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iMTgxIj5DbG91ZCBsb2FkIGJhbGFuY2VyPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iMTgxIj5BcHBsaWNhdGlvbiBiYWNrZW5kczwvdGV4dD48L2c+Cjwvc3ZnPg==)

![Your AWS load-balancing API calls go to the Tensor9 adapter, which saves them and applies them to the cloud resources. Client traffic goes straight to the cloud load balancer, which forwards it to your backends.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NjAiIGhlaWdodD0iMjM2IiB2aWV3Qm94PSIwIDAgNzYwIDIzNiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJZb3VyIEFXUyBsb2FkLWJhbGFuY2luZyBBUEkgY2FsbHMgZ28gdG8gdGhlIFRlbnNvcjkgYWRhcHRlciwgd2hpY2ggc2F2ZXMgdGhlbSBhbmQgYXBwbGllcyB0aGVtIHRvIHRoZSBjbG91ZCByZXNvdXJjZXMuIENsaWVudCB0cmFmZmljIGdvZXMgc3RyYWlnaHQgdG8gdGhlIGNsb3VkIGxvYWQgYmFsYW5jZXIsIHdoaWNoIGZvcndhcmRzIGl0IHRvIHlvdXIgYmFja2VuZHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImxiLXJ1bnRpbWUtYXJyb3ciIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIHJlZlg9IjYiIHJlZlk9IjMiIG9yaWVudD0iYXV0byI+PHBhdGggZD0iTTAgMCBMNiAzIEwwIDYiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxnIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNsYi1ydW50aW1lLWFycm93KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ij48cGF0aCBkPSJNMjIyIDY2IEgyNzAiLz48cGF0aCBkPSJNNDkwIDY2IEg1MzgiLz48cGF0aCBkPSJNMjIyIDE3NiBIMjcwIi8+PHBhdGggZD0iTTQ5MCAxNzYgSDUzOCIvPjwvZz4KPGcgc3R5bGU9InN0cm9rZTojNDc1NTY5Ij48cmVjdCB4PSIxNiIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjUzOCIgeT0iMzIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjE2IiB5PSIxNDIiIHdpZHRoPSIyMDYiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPjxyZWN0IHg9IjUzOCIgeT0iMTQyIiB3aWR0aD0iMjA2IiBoZWlnaHQ9IjY4IiByeD0iMTAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz48L2c+CjxnIHN0eWxlPSJzdHJva2U6IzZlZTdiNyI+PHJlY3QgeD0iMjcwIiB5PSIzMiIgd2lkdGg9IjIyMCIgaGVpZ2h0PSI2OCIgcng9IjEwIiBzdHlsZT0iZmlsbDojMDY0ZTNiIi8+PHJlY3QgeD0iMjcwIiB5PSIxNDIiIHdpZHRoPSIyMjAiIGhlaWdodD0iNjgiIHJ4PSIxMCIgc3R5bGU9ImZpbGw6IzA2NGUzYiIvPjwvZz4KPGcgZm9udC1mYW1pbHk9IkludGVyLCBzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZmlsbDojZjFmNWY5Ij48dGV4dCB4PSIxMTkiIHk9IjYwIj5BcHBsaWNhdGlvbiAvIFRlcnJhZm9ybTwvdGV4dD48dGV4dCB4PSIxMTkiIHk9IjgxIj5BV1MgbG9hZC1iYWxhbmNpbmcgQVBJPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iNjAiPlRlbnNvcjkgYWRhcHRlcjwvdGV4dD48dGV4dCB4PSIzODAiIHk9IjgxIj5TYXZlcyBhbmQgYXBwbGllcyBjaGFuZ2VzPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iNjAiPkNsb3VkIHJlc291cmNlczwvdGV4dD48dGV4dCB4PSI2NDEiIHk9IjgxIj5MaXN0ZW5lcnMgYW5kIGJhY2tlbmRzPC90ZXh0Pjx0ZXh0IHg9IjExOSIgeT0iMTgxIj5DbGllbnRzPC90ZXh0Pjx0ZXh0IHg9IjM4MCIgeT0iMTgxIj5DbG91ZCBsb2FkIGJhbGFuY2VyPC90ZXh0Pjx0ZXh0IHg9IjY0MSIgeT0iMTgxIj5BcHBsaWNhdGlvbiBiYWNrZW5kczwvdGV4dD48L2c+Cjwvc3ZnPg==)

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

#### Listeners, addresses and health checks

TCP, UDP and combined TCP+UDP listeners become OCI listeners and backend sets. A reserved IP address gives a stable frontend, and the backend sees the client's source address.

The network load balancer is regional. Its public or private subnet replaces the AWS multi-subnet layout; check the network, frontend exposure, backend rules and health-check access.

Health checks keep the path, expected status, timeout, interval and failure threshold. Test them and a client connection before relying on a newly registered backend.

#### 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

* **TLS termination is not supported.** OCI Network Load Balancer does not end TLS. An AWS TLS listener becomes TCP passthrough, and your backend must terminate the encrypted connection.
* **The AWS hostname is not kept.** Clients use the OCI address, so update external DNS and allowlists. When your stack is translated, an AWS-specific reference with no OCI equivalent stops the build with an error.

#### 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 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

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

Feature: Load balancer data plane (NLB).

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.

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/d0dd1a45e467d39846b583b32f7c9e5faffe2028df7e125b6c736079bd08ba8e-light.svg)

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/fa4fa6abd34483879760eed027810d89efd090eb15bbde7267d5b67a5b44b700-dark.svg)

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.

| Processed load-balancer GiB per month (GiB/month) | Network Load Balancer | OCI Network Load Balancer | Difference |
| -: | -: | -: | -: |
| 0 | 16.43 | 0.00 | -16.43 |
| 100 | 17.03 | 0.00 | -17.03 |
| 1,000 | 22.43 | 0.00 | -22.43 |
| 10,000 | 76.43 | 0.00 | -76.43 |
| 100,000 | 616.43 | 0.00 | -616.43 |
| 1,000,000 | 6,016.43 | 0.00 | -6,016.43 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* 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's Flexible Network Load Balancer is free.
* AWS Price List API, AWSELB offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json)
* OCI price list: [https://www.oracle.com/cloud/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-72d022a04625c2e640d1ba0a2deb0da1503af3e2` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [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](https://www.oracle.com/cloud/price-list/).

**Load balancer data plane (NLB) → OCI Network 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.

| Monthly component | USD |
| - | -: |
| Origin: Allocated load-balancer hours | 16.43 |
| Origin: Load-balancer processed bytes | 6.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| **Origin service subtotal** | **22.43** |
| **Target service subtotal** | **0.00** |

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**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Allocated load-balancer hours | 730 | load-balancer-hour |
| Load-balancer processed bytes | 1,000 | GiB |

* 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's Flexible Network Load Balancer is free.

List prices read: 2026-10-22. Model: `plan-72d022a04625c2e640d1ba0a2deb0da1503af3e2` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [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](https://www.oracle.com/cloud/price-list/).

## On Scaleway

### Scaleway Load Balancer

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Instance targets | Backends | Out of scope | Common | Translated instance attachments are not registered on Scaleway; the build names each missing target. Configure native backends before expecting traffic or health checks. |
| Sizing | Capacity | Partial | Common | The same decision as for an application load balancer: an NLB autoscales by capacity unit with no fixed size, and a Scaleway LB requires a type with no default. The build picks the SMALLEST and reports it; tune it to your expected bandwidth. |
| Per-target-group health checks | Health | Supported | Common | Each listener keeps its own check, because the check lives on the backend rather than on the load balancer. |
| Exposure of an internal load balancer | Security | Partial | Common | An INTERNAL NLB becomes a PUBLIC Scaleway load balancer with a flexible IP, exactly as the application-load-balancer mapping does; the build reports the widening, and a private Scaleway load balancer (no flexible IP, on a Private Network shared with the workload) is not built by this mapping. |
| TLS termination | Security | Partial | Common | A TLS listener is carried as TCP passthrough with the backend terminating; certificates are not moved onto the load balancer. The build reports the collapse (one row per load balancer, not per listener). |
| A load balancer built with count or for\_each | Topology | Out of scope | Most usage | Stops the build rather than collapsing a declared fleet of N into one. |
| Listeners | Topology | Supported | Common | Each listener becomes its own frontend and backend pair, with the forwarded port and protocol carried onto the backend. |
| Placement | Topology | Supported | Common | Zonal rather than regional, derived from the region your Cloud Adapter deployment runs in. |
| Public address | Topology | Supported | Common | The load balancer takes a flexible IP, which is what the origin's DNS name references resolve to. |
| The load balancer | Topology | Supported | Common | Your NLB becomes a Scaleway Load Balancer -- the same product that serves application load balancers, since one Scaleway LB covers both layer 4 and layer 7. |

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

**Native or deployment mapping.** 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. Cost estimates describe the selected service resources; operation coverage remains separate.

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

Feature: Load balancer data plane (NLB).

Estimated monthly service charges by Processed load-balancer GiB per month. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD.

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/97007df316bbc02fec35ee7d60919de80082c342ab62fd764181fedc08a3c665-light.svg)

![Load balancer data plane (NLB) · Processed load-balancer GiB per month: monthly service charges by Processed load-balancer GiB per month. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/08aaacc8e329c297d5ac56eb7d21543fecae0e200b9c65830b2e33603e6203af-dark.svg)

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.

| Processed load-balancer GiB per month (GiB/month) | Network Load Balancer | Scaleway Load Balancer | Difference |
| -: | -: | -: | -: |
| 0 | 16.43 | 18.81 | 2.39 |
| 100 | 17.03 | 18.81 | 1.79 |
| 1,000 | 22.43 | 18.81 | -3.61 |
| 10,000 | 76.43 | 18.81 | -57.61 |
| 100,000 | 616.43 | 18.81 | -597.61 |
| 1,000,000 | 6,016.43 | 18.81 | -5,997.61 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.0257715 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* 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 → fr-par, 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.
* Native/deployment comparison scope: 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.
* 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. LB-S (200 Mbps) traffic is unlimited with no per-GB charge.
* AWS Price List API, AWSELB offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json)
* Scaleway Network pricing: [https://www.scaleway.com/en/pricing/network/](https://www.scaleway.com/en/pricing/network/)

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-44b63796ef24553cba24ed2ca78ac604e8bc3db6` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AWSELB offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json), [Scaleway Network pricing](https://www.scaleway.com/en/pricing/network/).

**Load balancer data plane (NLB) → Scaleway 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: fr-par. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Allocated load-balancer hours | 16.43 |
| Origin: Load-balancer processed bytes | 6.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 18.81 |
| Target: Independent native resources | 0.00 |
| **Origin service subtotal** | **22.43** |
| **Target service subtotal** | **18.81** |

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**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Allocated load-balancer hours | 0.0225 | USD/load-balancer-hour |
| Origin list price · Load-balancer processed bytes | 0.006 | USD/GiB |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.0257715 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Allocated load-balancer hours | 730 | load-balancer-hour |
| Load-balancer processed bytes | 1,000 | GiB |

* 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.

* Native/deployment comparison scope: 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.

* 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. LB-S (200 Mbps) traffic is unlimited with no per-GB charge.

List prices read: 2026-10-22. Model: `plan-44b63796ef24553cba24ed2ca78ac604e8bc3db6` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AWSELB offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/us-east-1/index.json), [Scaleway Network pricing](https://www.scaleway.com/en/pricing/network/).

## 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](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method, what the estimates include and how to read their qualifications.

| Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping |
| - | - | - | -: | -: | -: | - |
| Azure Load Balancer | Processed load-balancer GiB per month: 10,000 GiB/month | Cited list prices, 2026-10-22 | 76.43 | 68.25 | -8.18 | Service adapter |
| Cloud Load Balancing | Processed load-balancer GiB per month: 10,000 GiB/month | Cited list prices, 2026-10-22 | 76.43 | 98.25 | +21.83 | Service adapter |
| DigitalOcean Load Balancer | Processed load-balancer GiB per month: 10,000 GiB/month | Cited list prices, 2026-10-22 | 76.43 | 12.00 | -64.43 | Service adapter |
| OCI Network Load Balancer | Processed load-balancer GiB per month: 10,000 GiB/month | Cited list prices, 2026-10-22 | 76.43 | 0.00 | -76.43 | Service adapter |
| Scaleway Load Balancer | Processed load-balancer GiB per month: 10,000 GiB/month | Cited list prices, 2026-10-22 | 76.43 | 18.81 | -57.61 | Native or deployment |

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: [Network Load Balancer costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/additional-services/aws-nlb).

## Service level agreements

> [!WARNING]
>
> These tables show Tensor9's standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.

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](https://docs.tensor9.com/cloud-adapter-early-access/support/service-adapter-slas.md), [measurement rules](https://docs.tensor9.com/cloud-adapter-early-access/support/service-levels.md), and [scaling conditions](https://docs.tensor9.com/cloud-adapter-early-access/support/scaling-and-limits.md).

### Network Load Balancer to Azure Load Balancer

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Network and load-balancer state reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::elbv2`: `DescribeLoadBalancers`, `DescribeTargetHealth` | One resource or at most 100 returned listeners, targets or rules. |
| Listener, target and topology mutation adapter-added latency | +18 ms monthly p99 | `aws::1.0.0::elbv2`: `CreateListener`, `CreateLoadBalancer`, `ModifyListener`, `ModifyTargetGroup` | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::elbv2`: `DescribeLoadBalancers`, `DescribeTargetHealth`, `CreateListener`, `CreateLoadBalancer`, `ModifyListener`, `ModifyTargetGroup` | 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. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**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).** `DescribeLoadBalancers`, `DescribeTargetHealth`. Bounded desired and observed status lookup.

**Listener, target and topology mutation: +18 ms monthly p99 (adapter-added).** `CreateListener`, `CreateLoadBalancer`, `ModifyListener`, `ModifyTargetGroup`. Validation and durable desired-state mutation.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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.

### Network Load Balancer to DigitalOcean Load Balancer

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Network and load-balancer state reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::elbv2`: `DescribeLoadBalancers`, `DescribeTargetHealth` | One resource or at most 100 returned listeners, targets or rules. |
| Listener, target and topology mutation adapter-added latency | +18 ms monthly p99 | `aws::1.0.0::elbv2`: `CreateListener`, `CreateLoadBalancer`, `DeregisterTargets`, `ModifyListener`, `ModifyTargetGroup`, `RegisterTargets` | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::elbv2`: `DescribeLoadBalancers`, `DescribeTargetHealth`, `CreateListener`, `CreateLoadBalancer`, `DeregisterTargets`, `ModifyListener`, `ModifyTargetGroup`, `RegisterTargets` | 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. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**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 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 (adapter-added).** `DescribeLoadBalancers`, `DescribeTargetHealth`. Bounded desired and observed status lookup.

**Listener, target and topology mutation: +18 ms monthly p99 (adapter-added).** `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.

#### 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.

### Network Load Balancer to Cloud Load Balancing

**SLA status:** Pending

Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service's latency budget. Your signed agreement sets the applicable terms.

### Network Load Balancer to OCI Network Load Balancer

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Network and load-balancer state reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::elbv2`: `DescribeLoadBalancers`, `DescribeTargetHealth` | One resource or at most 100 returned listeners, targets or rules. |
| Listener, target and topology mutation adapter-added latency | +18 ms monthly p99 | `aws::1.0.0::elbv2`: `CreateListener`, `CreateLoadBalancer`, `DeregisterTargets`, `ModifyListener`, `ModifyLoadBalancerAttributes`, `ModifyTargetGroup`, `RegisterTargets` | One load balancer/network; at most 20 listeners and at most 100 targets; readiness separate. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::elbv2`: `DescribeLoadBalancers`, `DescribeTargetHealth`, `CreateListener`, `CreateLoadBalancer`, `DeregisterTargets`, `ModifyListener`, `ModifyLoadBalancerAttributes`, `ModifyTargetGroup`, `RegisterTargets` | 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. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**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::nlb. Application packets, load-balancer forwarding and health-probe network time are not adapter request latency. Local graph validation, rule translation, admission, status lookup and response encoding remain covered.

#### How the latency targets were chosen

**Network and load-balancer state reads: +8 ms monthly p99 (adapter-added).** `DescribeLoadBalancers`, `DescribeTargetHealth`. Bounded desired and observed status lookup.

**Listener, target and topology mutation: +18 ms monthly p99 (adapter-added).** `CreateListener`, `CreateLoadBalancer`, `DeregisterTargets`, `ModifyListener`, `ModifyLoadBalancerAttributes`, `ModifyTargetGroup`, `RegisterTargets`. Validation and durable desired-state mutation.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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.

### Network Load Balancer to Scaleway Load Balancer

**SLA status:** Not applicable

This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider's networking terms apply.

## Install and run

The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. Set `T9_API_KEY` as described in [Install and Authenticate](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate.md), then list the adapters your account may use with this origin:

```sh theme={null}
tensor9 adapt svc list \
  -origin aws::1.0.0::nlb
```

The result is limited to directed mappings for this origin that your account is entitled to use. Use a returned backend identifier when configuring the adapter or investigating a request.

Request binary access from [hello@tensor9.com](mailto:hello@tensor9.com) if your account does not yet include this direction.

## Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

## Configure, tune and debug

Start with [setup](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/overview.md) and [configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md). Use [tuning](https://docs.tensor9.com/cloud-adapter-early-access/tuning/overview.md) to understand supported request tags, [debugging](https://docs.tensor9.com/cloud-adapter-early-access/debugging/overview.md) to investigate a request, and [High Fidelity Cloud Emulators](https://docs.tensor9.com/cloud-adapter-early-access/local-testing/overview.md) to validate a bounded reproduction.

For requests that go through an entitled service adapter, use [tensor9 explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain.md) and [x-t9-explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md) to inspect the selected mapping.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.