> ## 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
> AWS Application Load Balancer. Distributes HTTP and HTTPS requests across target groups at layer 7, choosing targets by host, path, header or query string.
**On this page**
* [Coverage by target cloud](#coverage-by-target-cloud)
* [How the targets compare](#how-the-targets-compare)
* [Max adaptation](#max-adaptation)
* [Infrastructure-only adaptation](#infrastructure-only-adaptation)
* [On Google Cloud](#on-google-cloud)
* [On Azure](#on-azure)
* [On OCI](#on-oci)
## Coverage by target cloud
| Target | Available |
| ------------------ | --------- |
| Google Cloud | โ |
| Azure | โ |
| OCI | โ |
| Private Kubernetes | - |
## How the targets compare
Each row compares a capability of Application Load Balancer with its adaptation on each target.
A dash means this row is not stated for that target.
### Max adaptation
| Capability | Application Load Balancer | Google Cloud | Azure | OCI |
| ----------------------------------------------------- | ---------------------------------------------- | ----------------------------------------------------- | --------------------------- | ---------------------------------------------- |
| Traffic path | AWS load balancer | Google Cloud Load Balancing | Azure Application Gateway | OCI Flexible Load Balancer |
| Request routing | ALB listener conditions | Path, host, header, query, method; weights | Host and path | Path, host, header, query |
| TLS termination | ALB certificate | Google-managed certificate | Azure Key Vault certificate | OCI certificate and listener TLS configuration |
| Health checks | Per target group | Per backend service | Per backend setting | Per backend set |
| Session stickiness | Configured cookie lifetime | Cookie duration up to one day | Browser-session affinity | Cookie duration preserved |
| Client endpoint | AWS hostname | Target cloud address | Target cloud address | Target cloud address |
| Login at the load balancer ยท OIDC / OAuth termination | Yes - authenticate-oidc / authenticate-cognito | Partial - Identity-Aware Proxy on the backend service | - | - |
| API coverage | full | partial | partial | partial |
### Infrastructure-only adaptation
| Capability | Application Load Balancer | OCI |
| ------------------ | -------------------------- | ---------------------------------------------- |
| Traffic path | AWS load balancer | OCI Flexible Load Balancer |
| Request routing | ALB listener conditions | Path, host, header, query |
| TLS termination | ALB certificate | OCI certificate and listener TLS configuration |
| Health checks | Per target group | Per backend set |
| Session stickiness | Configured cookie lifetime | Cookie duration preserved |
| Client endpoint | AWS hostname | Target cloud address |
| API coverage | full | partial |
## On Google Cloud
| 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.
#### 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 Azure
| 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.
#### 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 OCI
| 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.
#### 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.
[Service Catalog](/service-adapters/catalog).
