Skip to main content
On this page

Coverage by target cloud

How the targets compare

Each row compares a capability of Network 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 passthrough Network 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.

Regional forwarding resources

The load balancer uses a reserved address, forwarding rules, a regional backend service, and regional health checks. Each TCP or UDP listener becomes a forwarding rule with its protocol and port. A combined TCP+UDP listener can use L3_DEFAULT, which forwards all supported protocols on all ports. That forwarding rule is broader than the source listener; firewall rules must restrict traffic to the intended protocols and ports. A public frontend uses a regional external address; an internal frontend uses an address on the target subnet. The backend service can contain backends across the region’s zones. Confirm their placement and connectivity rather than assuming AWS availability-zone identifiers transfer.

Client addresses and TLS

Passthrough forwarding preserves the client’s source IP at the backend. Application allowlists and logs can read that address without X-Forwarded-For or a proxy-protocol header. A connection is assigned using its source and destination addresses, source and destination ports, and protocol. The target does not terminate TLS. An AWS TLS listener uses TCP passthrough, with TLS terminated by your backend. Configure the certificate there before switching traffic.

Health checks and observability

The target supports TCP, HTTP, HTTPS, SSL, and gRPC probes. Health checks belong to the backend service and use the configured path, port, interval, timeout, and thresholds. Permit both application traffic and health-check traffic in the target firewall. Flow and backend-service logs describe network connections. They do not reproduce AWS TLS access logs or application request logs; collect request-level information in the backend when required.

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

Frontend, rules, and backend pool

The Standard Load Balancer has a frontend address, a rule per listener, a backend address pool, and health probes. TCP and UDP listeners retain their protocol and port. Preserving a combined TCP+UDP listener on one port requires separate rules for the two protocols. Azure All-protocol rules are HA-port rules for an internal load balancer and cover all ports; they are not a port-scoped public listener. A public frontend uses a static Standard public IP. An internal frontend uses a private subnet address. A zone-redundant deployment can serve backends across the region’s zones; verify the selected frontend and backend placement for the customer’s network.

Client addresses and TLS

Azure forwards traffic while preserving the client’s source IP. Connection distribution uses the source and destination addresses, source and destination ports, and protocol. The backend can use the original address for access control and logging. Standard Load Balancer does not terminate TLS. An AWS TLS listener becomes TCP passthrough and your backend must terminate TLS. Prepare that endpoint and its certificate before cutover.

Health probes and logs

TCP, HTTP, or HTTPS probes are associated with load-balancing rules. The mapping preserves the applicable interval, port, path, and failure threshold. Allow AzureLoadBalancer health traffic as well as the intended client traffic in the backend network security rules. Azure Monitor provides metrics and health-event logs. Standard Load Balancer does not provide AWS-style per-request access logs; collect application request details at the backend.

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 Network 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, addresses, and placement

TCP, UDP, and mixed TCP+UDP listeners map to native OCI listeners and backend sets. Reserved IP addresses provide a stable frontend, and the target preserves the client’s source address at the backend. The network load balancer is regional. Its public or private subnet arrangement replaces the AWS multi-subnet layout; verify the selected network, frontend exposure, backend rules, and health-check access.

TLS and health checks

OCI Network Load Balancer does not terminate TLS. The TLS listener maps to TCP passthrough, and the backend must terminate the encrypted connection. This is different from provisioning an HTTP listener on an application load balancer. Health checks use the path, expected status, timeout, interval, and failure threshold. Test those checks and a client connection before relying on a newly registered backend.

Endpoint changes

Clients use the OCI address rather than the AWS load balancer hostname. Update external DNS and allowlists. In the infrastructure translation, an AWS-specific reference without a target equivalent causes a build error. The Max adapter retains AWS-shaped management identities separately from native resource identifiers.

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.