Coverage by target cloud
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
Infrastructure-only adaptation
On Google Cloud
Managing the load balancer
Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to Google Cloud Load Balancing. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such asCreateLoadBalancer, CreateListener, and RegisterTargets. The cloud load balancer receives client connections and forwards them to your application.
A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
Google resources
A forwarding rule receives traffic at the frontend address. A target proxy handles HTTP or HTTPS, a URL map chooses the backend, and a backend service represents each target group. Health checks belong to the backend services. HTTPS uses a Google-managed certificate for your DNS names, including multi-domain certificates and the target’s mutual-TLS arrangement; an ACM ARN does not contain certificate material that can be copied.Routing and session affinity
Path, host, header, query, and method conditions map to URL-map rules. Weighted target groups become weighted backend services. Rule priority determines match order. Source-IP conditions and fixed-response actions are outside this mapping. Lambda target groups are outside this mapping. A function deployed behind a separate HTTP or serverless backend does not become an AWS Lambda target registration. Cookie stickiness becomes generated-cookie affinity, with a maximum duration of one day. Review longer AWS cookie lifetimes before moving.Frontend security
The 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
Managing the load balancer
Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to Azure Application Gateway. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such asCreateLoadBalancer, CreateListener, and RegisterTargets. The cloud load balancer receives client connections and forwards them to your application.
A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
Application Gateway resources
An ALB maps to Application Gateway v2: listeners accept HTTP or HTTPS, backend pools represent target groups, and routing rules select a pool. The gateway needs a dedicated subnet. An ALB does not require a separate Azure Standard Load Balancer. HTTPS uses a certificate from Azure Key Vault, including multi-site setups, Server Name Indication (SNI), and the target’s mutual-TLS arrangement. An ACM ARN is a reference, not the certificate and private key; supply the certificate through the target arrangement.Routing and cookies
Host conditions map to multi-site listeners, and path conditions map to path rules. Header, method, query, source-IP conditions, weighted target groups, and fixed responses are outside this mapping. gRPC to backends is also outside this option. Cookie affinity keeps a session on a backend, but Application Gateway has no configured cookie lifetime: affinity lasts for the browser session. Listener-based OIDC or OAuth login is not mapped; handle login in your application or an identity-aware proxy.Frontend security
The 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
Managing the load balancer
Your application and Terraform use the AWS Elastic Load Balancing API through the adapter. The adapter keeps AWS-shaped load balancer, listener, and target-group identities, records configuration changes, and applies them to OCI Flexible Load Balancer. A target group is the set of backends that a listener forwards traffic to. Management changes and traffic take different paths. The adapter handles calls such asCreateLoadBalancer, CreateListener, and RegisterTargets. The cloud load balancer receives client connections and forwards them to your application.
A successful management request can precede completion of the cloud change. Wait for the load balancer to become available and check the native resources before sending production traffic. The adapter retains the requested configuration while background work applies it.
Listeners and backend sets
One OCI listener represents each ALB listener, and one backend set represents each target group. The listener’s default action selects its backend set. The native load balancer uses a bandwidth range, initially 10-100 Mbps; adjust it for the deployment. The AWS multi-subnet layout becomes the target deployment’s network arrangement. Confirm whether the load balancer is public or private and whether its subnet and security rules admit the intended clients and backends.Request routing
Path, host, header, and query conditions map to a routing policy per listener, in rule-priority order. Method conditions, source-IP conditions, weighted target groups, and fixed-response actions are outside this mapping. OCI backend-set server weights do not reproduce a listener rule that splits traffic between target groups.HTTPS and certificates
The HTTPS mapping uses TLS on the OCI listener, with a certificate supplied through OCI Certificates or the load balancer’s certificate configuration. An ACM ARN identifies an AWS certificate; it does not supply the certificate and private key needed by OCI. Provision or import the target certificate and attach it before enabling the HTTPS frontend. The mapped arrangement uses one certificate per listener and does not reproduce an AWS listener’s SNI certificate list. Backend TLS is a separate setting; enabling it does not secure a frontend that is still configured for HTTP. Verify the client-facing handshake and the backend connection before cutover. OIDC and OAuth authenticate actions are outside this option; login belongs in the application or an identity-aware proxy.Health checks, cookies, and operations
Backend sets specify the health-check path, response codes, interval, timeout, port, and consecutive-failure count. The default path is /. The existing mapping turns HTTP and HTTPS probes into HTTP probes; other checks use TCP. Cookie persistence includes the configured duration. AWS access-log settings, idle timeout, deletion protection, and WAF attachment are outside this profile. Prepare the target logging and operational settings explicitly. Client DNS must resolve to the OCI address; an AWS hosted-zone ID is not an OCI resource identifier.Target registration and readiness
RegisterTargets and DeregisterTargets update target-group membership. Instance registrations resolve through the adapter’s EC2 inventory; IP registrations identify the backend address and port. The target group, load balancer, and backend must belong to a compatible network.
The adapter applies a listener after its target group and network dependencies are ready. Native health checks then determine which backends receive traffic. Verify the provider’s health status and test an application request: a registered target alone does not establish that its application is ready.
DescribeTargetHealth reports registration and zone eligibility from the adapter’s saved state. Its healthy result does not confirm that the native load balancer’s probe succeeded. Check native backend health and a complete application request before sending production traffic.
Drain connections before deregistering backends or deleting a load balancer. Removing configuration does not transfer active connections to a replacement.