The connection can be present in multiple availability zones, though the service does need to decide which ones it will support at setup time. One simple approa

The connection can be present in multiple availability zones, though the service does need to decide which ones it will support at setup time. One simple approach is for the service to accept connections in many or all AZs, allowing the client to decide which ones are relevant to it. From the endpoint service documentation [1]: > For low latency and fault tolerance, we recommend using a Network Load Balancer with targets in every Availability Zone of the AWS Region. To help achieve high availability (...) you can enable cross-zone load balancing. Cross-zone load balancing enables the load balancer to distribute traffic across the registered targets in all enabled Availability Zones. For more information, see Cross-Zone Load Balancing in the User Guide for Network Load Balancers. When establishing a connection, the client can specify multiple subnets in which it would like to create an endpoint [2], and those subnets can be in any AZs supported by the service, if I recall correctly. The client can thus establish a connection that spans multiple AZ by requesting endpoints in subnets in those AZs. In most scenarios it's fine if client/service traffic can cross between AZs; I've only found it necessary to partition traffic by AZ in specialized applications (usually applications that are themselves trying to provide a zonal availability model, or that follow cell-based architecture at the zone level -- most business services don't fall into these categories, though low-level infrastructure services sometimes do). [1] https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-se... [2] https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_C...