> ## 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. # Application Load Balancer > Application Load Balancer APIs with Cloud Adapter. This page describes how Application Load Balancer maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior. ## Supported environments | Environment | Mapping | | ------------ | -------------------- | | Azure | API | | DigitalOcean | API + Infrastructure | | Google Cloud | API | | OCI | API + Infrastructure | | Scaleway | Infrastructure | API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on. ## How the targets compare Each row compares a capability of Application Load Balancer with its adaptation on each target. A dash means this profile does not state the capability for that target. ### Cloud Adapter | Capability | Application Load Balancer | Azure | DigitalOcean | Google Cloud | OCI | Scaleway | | ----------------------------------------------------- | ---------------------------------------------- | --------------------------- | ---------------------------------- | ----------------------------------------------------- | ---------------------------------------------- | -------- | | Traffic path | AWS load balancer | Azure Application Gateway | DigitalOcean Load Balancer | Google Cloud Load Balancing | OCI Flexible Load Balancer | - | | Request routing | ALB listener conditions | Host and path | Port forwarding only | Path, host, header, query, method; weights | Path, host, header, query | - | | TLS termination | ALB certificate | Azure Key Vault certificate | Managed certificate or passthrough | Google-managed certificate | OCI certificate and listener TLS configuration | - | | Health checks | Per target group | Per backend setting | One per load balancer | Per backend service | Per backend set | - | | Session stickiness | Configured cookie lifetime | Browser-session affinity | Cookie affinity | Cookie duration up to one day | Cookie duration preserved | - | | Client endpoint | AWS hostname | Target cloud address | Target cloud address | Target cloud address | Target cloud address | - | | API coverage | full | partial | partial | partial | partial | partial | | Login at the load balancer ยท OIDC / OAuth termination | Yes - authenticate-oidc / authenticate-cognito | - | - | Partial - Identity-Aware Proxy on the backend service | - | - | ## On Azure ### Azure Load Balancer | Operation | Area | Support | Depth | Notes | | ----------------------------- | -------------- | ------------ | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Authentication (OIDC / OAuth) | Access control | Out of scope | Most usage | Listener-based OIDC or OAuth login is outside this option. Handle authentication in the application or an identity-aware proxy. | | Health checks | Backends | Supported | Common | Health probes belong to backend settings. Azure also offers response-body matching as a target capability. | | Session stickiness | Backends | Supported | Most usage | Cookie affinity lasts for the browser session; Azure has no configured cookie-duration setting. | | gRPC backends | Backends | Out of scope | Most usage | This option does not provide gRPC to backends. | | 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 Application Gateway v2 receives HTTP or HTTPS traffic and forwards it to the backends. | | HTTPS / TLS termination | Listeners | Supported | Common | The gateway uses Azure Key Vault certificates, including multi-site setups. | | Listeners & target groups | Listeners | Supported | Common | Application Gateway listeners and backend pools represent AWS listeners and target groups. | | Routing rules (path / host) | Routing | Partial | Most usage | Host and path conditions map to multi-site listeners and path rules. Header, method, query, and source-IP conditions are outside this mapping. | | Weighted target groups | Routing | Out of scope | Most usage | Weighted target-group forwarding is outside the Application Gateway mapping. | #### Managing the load balancer Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to Azure Application Gateway. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such as `CreateLoadBalancer`, `CreateListener`, and `RegisterTargets`. The cloud load balancer receives client connections and forwards them to your application. A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
AWS management calls go through the adapter to cloud configuration. Client traffic goes through the cloud load balancer to application backends. AWS management calls go through the adapter to cloud configuration. Client traffic goes through the cloud load balancer to application backends.
#### Application Gateway resources An ALB maps to Application Gateway v2: listeners accept HTTP or HTTPS, backend pools represent target groups, and routing rules select a pool. The gateway needs a dedicated subnet. An ALB does not require a separate Azure Standard Load Balancer. HTTPS uses a certificate from Azure Key Vault, including multi-site setups, Server Name Indication (SNI), and the target's mutual-TLS arrangement. An ACM ARN is a reference, not the certificate and private key; supply the certificate through the target arrangement. #### Routing and cookies Host conditions map to multi-site listeners, and path conditions map to path rules. Header, method, query, source-IP conditions, weighted target groups, and fixed responses are outside this mapping. gRPC to backends is also outside this option. Cookie affinity keeps a session on a backend, but Application Gateway has no configured cookie lifetime: affinity lasts for the browser session. Listener-based OIDC or OAuth login is not mapped; handle login in your application or an identity-aware proxy. #### Frontend security The Max adapter enforces supported frontend security-group rules through a network security group (NSG) on the gateway's dedicated subnet. Rules allow the selected IPv4 client ranges on the listener ports. The subnet also needs Azure's GatewayManager control ports 65200-65535 and AzureLoadBalancer health traffic. Gateway requirements include unrestricted outbound access from that subnet. A dedicated subnet prevents those gateway rules from changing another workload's access. Unsupported selectors are rejected; the frontend waits for its network security policy before becoming available. #### Backend health Each backend setting has a health probe. The mapping preserves the path, expected status codes, interval, timeout, unhealthy threshold, and explicit port. Application Gateway also supports response-body matching, which is a target capability rather than an AWS setting that must be recreated. #### Target registration and readiness `RegisterTargets` and `DeregisterTargets` update target-group membership. Instance registrations resolve through the adapter's EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network. The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider's health status and test an application request: a registered target alone does not establish that its application is ready. `DescribeTargetHealth` reports registration and zone eligibility from the adapter's saved state. Its `healthy` result does not confirm that the native load balancer's probe succeeded. Check native backend health and a complete application request before sending production traffic. Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement. #### Deployment and cutover Deploy the adapter with permission to manage load balancers and their network dependencies in the customer's cloud account. AWS-facing credentials authorize management calls; the adapter uses the target cloud's credentials to apply changes. Configure public or private exposure, frontend access rules, backend access, and health-check access together. Prepare DNS and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build; external DNS and clients still need a cutover. At Max, the adapter also maintains the AWS resource identities used by management calls. Check certificates, routing, native health checks, and a complete client request before changing DNS. Keep the old load balancer available while existing connections drain. Application sessions and active connections are not copied by this adapter. ## On DigitalOcean ### DigitalOcean Load Balancer | Operation | Area | Support | Depth | Notes | | ------------------------------------ | ------------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Health checks | Backends | Partial | Common | One health check serves the entire load balancer. The mapping uses the first target group and reports conflicts with other checks. | | Session stickiness | Backends | Supported | Most usage | Cookie stickiness is supported on the shared backend pool. | | Target registration | Backends | Partial | Most usage | Register the target backends through the adapter; AWS registrations are not copied. | | Access logs / WAF / reserved IPs | Configuration | Out of scope | Full surface | These AWS settings are outside this load-balancer mapping. | | Network placement | Configuration | Partial | Full surface | DigitalOcean offers internal load balancers. Confirm the target VPC and public or internal setting; this mapping requires exposure review. | | Load balancer address | Consumers | Partial | Common | Clients use the load balancer's IP. The infrastructure translation updates supported hostname references and rejects identifiers without an equivalent. | | Traffic forwarding | Data plane | Supported | Common | DigitalOcean forwards traffic through one native load balancer, with a rule per listener. | | HTTPS / TLS termination | Listeners | Supported | Common | Terminate TLS with a managed certificate, including automatic Let's Encrypt issuance, or pass the encrypted connection through to a backend that terminates it. | | Routing rules (path / host / header) | Routing | Out of scope | Most usage | This option forwards by port and retains the default backend. Content-based listener rules are outside the mapping. | #### Managing the load balancer Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to DigitalOcean Load Balancer. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such as `CreateLoadBalancer`, `CreateListener`, and `RegisterTargets`. The cloud load balancer receives client connections and forwards them to your application. A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
AWS management calls go through the adapter to cloud configuration. Client traffic goes through the cloud load balancer to application backends. AWS management calls go through the adapter to cloud configuration. Client traffic goes through the cloud load balancer to application backends.
#### Port forwarding and the backend pool Each listener becomes a forwarding rule from a frontend protocol and port to a backend port. All rules use one Droplet pool, selected by tag or ID. The load balancer runs in one region and is sized by node count. This option does not reproduce path-, host-, header-, or query-based routing, or weighted target groups. It retains each listener's default forwarding behavior. Move content-based routing into your application or an ingress proxy before using this target. #### TLS and session cookies TLS can terminate at the load balancer using a managed certificate, including automatic Let's Encrypt issuance, or pass through to a backend that terminates it. Choose the arrangement explicitly and prepare the required DNS and certificate configuration. An ACM ARN does not supply a transferable private key. Cookie stickiness is supported. Confirm that the selected forwarding mode and shared backend pool preserve the session behavior your application expects. #### Health checks and exposure DigitalOcean uses one health check for the entire load balancer. The mapping takes it from the first target group and reports conflicting checks on other groups. Protocol, port, and path must work for every backend in the pool. DigitalOcean offers public and internal load balancers. This mapping requires an explicit check of the target's exposure; the existence of a private target option does not establish that a translated deployment is private. Confirm the VPC and internal setting before cutover. #### Addresses and operational differences The load balancer has a stable IP address, but this option does not provide an Elastic IP reserved before creation. Update client DNS and allowlists to the new address. AWS access-log settings, WAF attachment, and reserved-IP mappings are outside the profile. #### Target registration and readiness `RegisterTargets` and `DeregisterTargets` update target-group membership. Instance registrations resolve through the adapter's EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network. The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider's health status and test an application request: a registered target alone does not establish that its application is ready. `DescribeTargetHealth` reports registration and zone eligibility from the adapter's saved state. Its `healthy` result does not confirm that the native load balancer's probe succeeded. Check native backend health and a complete application request before sending production traffic. Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement. #### Deployment and cutover Deploy the adapter with permission to manage load balancers and their network dependencies in the customer's cloud account. AWS-facing credentials authorize management calls; the adapter uses the target cloud's credentials to apply changes. Configure public or private exposure, frontend access rules, backend access, and health-check access together. Prepare DNS and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build; external DNS and clients still need a cutover. At Max, the adapter also maintains the AWS resource identities used by management calls. Check certificates, routing, native health checks, and a complete client request before changing DNS. Keep the old load balancer available while existing connections drain. Application sessions and active connections are not copied by this adapter. ## On Google Cloud ### Cloud Load Balancing | Operation | Area | Support | Depth | Notes | | -------------------------------------------- | -------------- | --------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Authentication (OIDC / OAuth) | Access control | Partial | Most usage | Listener authentication maps to Identity-Aware Proxy on the backend service. External identity providers and Cognito need the Identity Platform arrangement. | | Health checks | Backends | Supported | Common | Checks belong to each backend service. Google HTTP(S) checks require status 200; AWS matchers accepting other codes need a compatible health endpoint. | | Session stickiness | Backends | Supported | Most usage | Generated-cookie affinity is supported, with a maximum duration of one day. | | 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 Cloud Load Balancing receives client connections and forwards requests to the backends. | | HTTPS / TLS termination | Listeners | Supported | Common | Google-managed certificates provide HTTPS, including multiple domains. | | Listeners & target groups | Listeners | Supported | Common | Listeners map to forwarding rules and proxies; target groups map to backend services selected by URL maps. | | Routing rules (path / host / header / query) | Routing | Partial | Most usage | URL maps handle path, host, header, query, and method conditions. Source-IP conditions and fixed responses are outside this mapping. | | Weighted target groups | Routing | Supported | Most usage | Weighted target groups become weighted backend services. | #### Managing the load balancer Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to Google Cloud Load Balancing. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such as `CreateLoadBalancer`, `CreateListener`, and `RegisterTargets`. The cloud load balancer receives client connections and forwards them to your application. A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
AWS management calls go through the adapter to cloud configuration. Client traffic goes through the cloud load balancer to application backends. AWS management calls go through the adapter to cloud configuration. Client traffic goes through the cloud load balancer to application backends.
#### Google resources A forwarding rule receives traffic at the frontend address. A target proxy handles HTTP or HTTPS, a URL map chooses the backend, and a backend service represents each target group. Health checks belong to the backend services. HTTPS uses a Google-managed certificate for your DNS names, including multi-domain certificates and the target's mutual-TLS arrangement; an ACM ARN does not contain certificate material that can be copied. #### Routing and session affinity Path, host, header, query, and method conditions map to URL-map rules. Weighted target groups become weighted backend services. Rule priority determines match order. Source-IP conditions and fixed-response actions are outside this mapping. Lambda target groups are outside this mapping. A function deployed behind a separate HTTP or serverless backend does not become an AWS Lambda target registration. Cookie stickiness becomes generated-cookie affinity, with a maximum duration of one day. Review longer AWS cookie lifetimes before moving. #### Frontend security The Max adapter can translate attached security-group IPv4 client ranges into Cloud Armor policies. This requires your explicit choice to use the paid Cloud Armor service. Each listener has its own policy; a request outside the allowed ranges receives HTTP 403, whereas an AWS security group drops the connection. This enforcement path supports IPv4 HTTP listeners and at most 10 client CIDR ranges per listener. Redirect actions are refused because they can bypass backend policy evaluation. The policy is attached and observed before the frontend is made available. You can explicitly choose to omit frontend security-group enforcement, but must then supply and verify the intended access control separately. #### Health checks and authentication Health checks use the target group's path, port, interval, timeout, and thresholds. Google HTTP(S) health checks require status 200. An AWS matcher that accepts other codes or a range of codes needs a health endpoint that returns 200 when healthy; response-body matching does not replace that status requirement. Listener authentication maps to Identity-Aware Proxy on the backend service. Google identity is the direct case; an external identity provider or Cognito user pool needs the Identity Platform arrangement described by that authentication mapping. Check the login flow as well as the load balancer's health. #### Target registration and readiness `RegisterTargets` and `DeregisterTargets` update target-group membership. Instance registrations resolve through the adapter's EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network. The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider's health status and test an application request: a registered target alone does not establish that its application is ready. `DescribeTargetHealth` reports registration and zone eligibility from the adapter's saved state. Its `healthy` result does not confirm that the native load balancer's probe succeeded. Check native backend health and a complete application request before sending production traffic. Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement. #### Deployment and cutover Deploy the adapter with permission to manage load balancers and their network dependencies in the customer's cloud account. AWS-facing credentials authorize management calls; the adapter uses the target cloud's credentials to apply changes. Configure public or private exposure, frontend access rules, backend access, and health-check access together. Prepare DNS and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build; external DNS and clients still need a cutover. At Max, the adapter also maintains the AWS resource identities used by management calls. Check certificates, routing, native health checks, and a complete client request before changing DNS. Keep the old load balancer available while existing connections drain. Application sessions and active connections are not copied by this adapter. ## On OCI ### OCI Load Balancer | Operation | Area | Support | Depth | Notes | | ------------------------------------------------ | -------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Authentication (OIDC / OAuth) | Access control | Out of scope | Most usage | Listener authentication is outside this option. Handle login in the application or an identity-aware proxy. | | WAF attachment | Access control | Out of scope | Most usage | WAF attachment is outside this option. | | Health checks | Backends | Supported | Common | The backend-set check uses the path, expected status, timeout, interval, port, and consecutive-failure count. | | Session stickiness | Backends | Supported | Most usage | Cookie persistence on the backend set includes the configured duration. | | Target registration | Backends | Partial | Most usage | Register backends through the adapter; existing AWS target registrations are not copied. | | Access logs / idle timeout / deletion protection | Configuration | Out of scope | Full surface | These AWS settings are outside the mapping and are reported for review. | | Bandwidth | Configuration | Partial | Full surface | The flexible load balancer starts with a 10-100 Mbps bandwidth range, adjustable for the deployment. | | Network placement | Configuration | Partial | Full surface | The target network replaces the AWS multi-subnet layout. Verify public or private exposure and backend connectivity. | | Load balancer address | Consumers | Partial | Common | Clients use the target OCI load-balancer address. The original AWS-managed hostname is not retained; infrastructure references to AWS-specific identifiers without a target equivalent are rejected or removed from outputs with a reported issue. | | Traffic forwarding | Data plane | Supported | Common | Oracle operates the native load balancer that receives client requests. | | HTTPS / TLS termination | Listeners | Partial | Common | HTTPS requires an OCI listener certificate and its TLS configuration. Supply or provision that certificate; an ACM reference alone does not provide it. The mapping does not reproduce the AWS SNI certificate list. | | Listeners & target groups | Listeners | Supported | Common | Each listener selects an OCI backend set representing its target group. An unresolved default target group is rejected. | | Routing rules (path / host / header / query) | Routing | Partial | Most usage | Path, host, header, and query conditions map to OCI routing policies. Method and source-IP conditions, weighted target groups, and fixed responses are outside this mapping. | #### Managing the load balancer Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to OCI Flexible Load Balancer. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such as `CreateLoadBalancer`, `CreateListener`, and `RegisterTargets`. The cloud load balancer receives client connections and forwards them to your application. A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
AWS management calls go through the adapter to cloud configuration. Client traffic goes through the cloud load balancer to application backends. AWS management calls go through the adapter to cloud configuration. Client traffic goes through the cloud load balancer to application backends.
#### Listeners and backend sets One OCI listener represents each ALB listener, and one backend set represents each target group. The listener's default action selects its backend set. The native load balancer uses a bandwidth range, initially 10-100 Mbps; adjust it for the deployment. The AWS multi-subnet layout becomes the target deployment's network arrangement. Confirm whether the load balancer is public or private and whether its subnet and security rules admit the intended clients and backends. #### Request routing Path, host, header, and query conditions map to a routing policy per listener, in rule-priority order. Method conditions, source-IP conditions, weighted target groups, and fixed-response actions are outside this mapping. OCI backend-set server weights do not reproduce a listener rule that splits traffic between target groups. #### HTTPS and certificates The HTTPS mapping uses TLS on the OCI listener, with a certificate supplied through OCI Certificates or the load balancer's certificate configuration. An ACM ARN identifies an AWS certificate; it does not supply the certificate and private key needed by OCI. Provision or import the target certificate and attach it before enabling the HTTPS frontend. The mapped arrangement uses one certificate per listener and does not reproduce an AWS listener's SNI certificate list. Backend TLS is a separate setting; enabling it does not secure a frontend that is still configured for HTTP. Verify the client-facing handshake and the backend connection before cutover. OIDC and OAuth authenticate actions are outside this option; login belongs in the application or an identity-aware proxy. #### Health checks, cookies, and operations Backend sets specify the health-check path, response codes, interval, timeout, port, and consecutive-failure count. The default path is /. The existing mapping turns HTTP and HTTPS probes into HTTP probes; other checks use TCP. Cookie persistence includes the configured duration. AWS access-log settings, idle timeout, deletion protection, and WAF attachment are outside this profile. Prepare the target logging and operational settings explicitly. Client DNS must resolve to the OCI address; an AWS hosted-zone ID is not an OCI resource identifier. #### Target registration and readiness `RegisterTargets` and `DeregisterTargets` update target-group membership. Instance registrations resolve through the adapter's EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network. The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider's health status and test an application request: a registered target alone does not establish that its application is ready. `DescribeTargetHealth` reports registration and zone eligibility from the adapter's saved state. Its `healthy` result does not confirm that the native load balancer's probe succeeded. Check native backend health and a complete application request before sending production traffic. Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement. #### Deployment and cutover Deploy the adapter with permission to manage load balancers and their network dependencies in the customer's cloud account. AWS-facing credentials authorize management calls; the adapter uses the target cloud's credentials to apply changes. Configure public or private exposure, frontend access rules, backend access, and health-check access together. Prepare DNS and firewall allowlists for the new address. In an infrastructure-only deployment, references inside the translated stack are updated during the build; external DNS and clients still need a cutover. At Max, the adapter also maintains the AWS resource identities used by management calls. Check certificates, routing, native health checks, and a complete client request before changing DNS. Keep the old load balancer available while existing connections drain. Application sessions and active connections are not copied by this adapter. ## On Scaleway ### Scaleway Load Balancer | Operation | Area | Support | Depth | Notes | | ---------------------------------------------- | -------- | ------------ | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sizing | Capacity | Partial | Common | This needs a decision from you. An ALB or NLB autoscales by capacity unit and carries 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 rather than assuming the default is sized for your traffic. | | A single origin check across several listeners | Health | Partial | Most usage | If your origin declares one health check and several listeners, that check is applied to every emitted backend and reported. Because the checks are now per-backend, you can tune them independently after cutover -- which you could not do on the origin. | | Per-target-group health checks | Health | Supported | Common | Each listener keeps its OWN health check, because the check lives on the backend. That matches what an AWS target group actually models -- on a cloud whose load balancer allows only one check for the whole thing, the checks after the first are lost. Here they are not. | | Exposure of an internal load balancer | Security | Partial | Common | An INTERNAL ALB (internal = true) becomes a PUBLIC Scaleway load balancer: it takes a flexible IP so that references to its DNS name have an address to resolve to, and nothing restricts who can reach its frontends. A private Scaleway load balancer is a different shape -- no flexible IP, attached to a Private Network the workload also sits on -- and this mapping does not build it. The build reports the widening; restrict exposure at the frontend or replace the load balancer with a private one before cutover. | | TLS termination | Security | Partial | Common | An HTTPS or TLS listener is carried as TCP PASSTHROUGH -- encrypted end to end, with the BACKEND terminating TLS. ACM certificates are not moved onto the load balancer (scaleway\_lb\_certificate is out of scope), so a listener that terminated TLS at the ALB now expects the target to hold the certificate. 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. A generated load balancer, target group or listener would silently collapse a fleet of N into one, and emitting one load balancer where you declared several is worse than refusing. | | Listeners | Topology | Supported | Common | Each listener becomes its own frontend and backend pair. Scaleway decomposes a load balancer into separate frontend and backend resources rather than inlining rules, so your listeners stay separate objects you can address individually. | | Placement | Topology | Supported | Common | A Scaleway load balancer is ZONAL rather than regional -- fr-par-1, not fr-par. The zone is derived from the region your Cloud Adapter deployment runs in; a bare region is never passed through, because it is rejected at apply rather than at build. | | Public address | Topology | Supported | Common | The load balancer takes a flexible IP, which is what the origin's DNS name references resolve to after translation. | | The load balancer | Topology | Supported | Common | Your ALB becomes a Scaleway Load Balancer. One Scaleway LB serves both layer 4 and layer 7, so an application and a network load balancer map onto the same product. | ## 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](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.