Building real-time applications with WebSocket using Amazon VPC Lattice

Building real-time applications with WebSocket requires persistent, low-latency, bidirectional connections between clients and servers. Routing these connections securely across multiple Amazon Virtual Private Cloud (Amazon VPC) and accounts adds complexity, especially when you need consistent security policies, simplified service discovery, and cross-account connectivity. Amazon VPC Lattice, a fully managed application networking service, can help you solve these challenges even though it does not natively support the WebSocket protocol. By leveraging TLS listeners for protocol passthrough or routing traffic through VPC Lattice resources, you can enable WebSocket connectivity for real-time applications such as chat systems, live dashboards, collaborative tools, and gaming backends.

In this post, we explore the architecture patterns and traffic flows for implementing WebSocket connectivity through VPC Lattice services with TLS listeners and resources. We cover both East-West (intra-AWS) and North-South (Internet-to-AWS) connectivity scenarios and compare the tradeoffs between the two approaches so you can choose the right one for your workload.

Prerequisites

We assume that you are familiar with networking constructs on AWS, including Amazon VPC, Application Load Balancer (ALB), Network Load Balancer (NLB), Amazon Route 53, and Amazon API Gateway. We do not focus on defining these services, but we do outline their capabilities and how you can use them to complement VPC Lattice in the highlighted WebSocket connectivity scenarios. We also assume you are familiar with Amazon VPC Lattice concepts, including service networks, services, target groups, TLS listeners, and VPC Resources. For additional background on Amazon VPC Lattice, we recommend reviewing the post Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice, and the collection of resources in the Amazon VPC Lattice Getting started guide.

WebSocket Support: TLS Listeners vs VPC Lattice Resources

VPC Lattice supports WebSocket connections through two approaches: Services with passthrough TLS listeners, or VPC Lattice Resource configurations. When choosing between them, consider the following:

Connection duration

• Services with TLS listeners have a maximum connection duration of 10 minutes and a configurable idle timeout between 60-600 seconds.
• Resources have no enforced maximum connection duration (it is controlled by your application) and a 350-second idle timeout.
• If your WebSocket application requires connections longer than 10 minutes, use a Resource configuration with a resource gateway.

Throughput

• Resources do not have throughput limits imposed by VPC Lattice.
• Services are subject to VPC Lattice service throughput quotas (default 10 Gbps bandwidth and 10,000 requests per second, per service per Availability Zone).

Load balancing

• Services with TLS listeners provide Layer 4 load balancing across targets in your target group, distributing connections to healthy targets.
• Resources route traffic through a resource gateway to a single destination (DNS name, IP, or ARN). For load balancing with Resources, place an ALB or NLB in front of your application.

Auth policies

• Services support auth policies, allowing you to control access at the service network level. At the time of this writing, auth policies for Services with TLS listeners are limited to anonymous principals.
• Resources do not currently support auth policies.

TLS handling

• With Services, TLS is negotiated between the consumer and provider in passthrough mode through the VPC Lattice listener.
• With Resources, TLS is negotiated directly between the consumer and the application, with VPC Lattice forwarding the raw TCP flow.

Configure application or protocol-level keepalives (WebSocket Ping/Pong frames) to maintain connections when traffic is not generated within the idle timeout period. At the time of this writing, the connection duration values and Resource Configuration idle timeout noted above are not adjustable.

Both the TLS listener and resource configuration paths through the VPC Lattice service network are depicted in the following figures:

Figure 1: VPC Lattice TLS Listener Path

In Figure 1, the Consumer connection is established to the TLS listener in the service network, and encrypted traffic is forwarded to a healthy member of the target group for the service in the provider VPC. The target group members can be an Amazon Elastic Compute Cloud (Amazon EC2) instance, an Amazon Elastic Container Service (Amazon ECS) task, an Amazon Elastic Kubernetes Service (Amazon EKS) pod (registered by IP address), or an ALB. AWS Lambda targets are not supported with TLS listeners. With VPC Lattice in passthrough mode, encrypted traffic is forwarded to the target, and TLS is negotiated directly between the consumer and the application.

Figure 2: VPC Lattice Resource Configuration Path

In Figure 2, the Consumer connection travels through the service network, where a resource configuration routes the request through a resource gateway in the provider VPC, which then delivers traffic to the target resource. The target resource can be a publicly or privately resolvable DNS name (depending on Resource Gateway configuration) or a private IP address. In this example, we route to an ALB that provides load balancing and TLS termination before forwarding traffic to the WebSocket application. TLS is negotiated directly between the consumer and the ALB.

WebSocket using VPC Lattice

For deploying WebSocket applications using VPC Lattice, we consider two connectivity patterns:

• WebSocket Client located in a consumer VPC in AWS communicating with a WebSocket application deployed in a provider VPC in AWS, i.e. an East-West traffic pattern.
• WebSocket Client located outside of AWS on the public Internet communicating with a WebSocket application deployed in a provider VPC in AWS and accessed via a centralized ingress VPC in AWS using an Internet Gateway (IGW), i.e. a North-South traffic pattern.

This guide does not cover on-premises connectivity via Site-to-Site VPN or Direct Connect. However, you can establish private connections from on premises to WebSocket applications deployed with VPC Lattice using Service Network Endpoints. For more details, see Amazon VPC Lattice: modernize and simplify your enterprise network architectures.

In both the East-West and North-South patterns, we deployed the WebSocket application as a VPC Lattice service with TLS Listeners in passthrough mode where the target of the listener is an instance that terminates TLS. In considering both traffic patterns, there is a set of common components as follows:

• Consumer/Ingress VPC: hosts a WebSocket client or serves as Internet ingress point; is associated with the service network.
• Provider VPC: hosts a WebSocket application.
• VPC Lattice service network: logical boundary for the collection of services and resource configurations and defines the authorization for discovery, connectivity, accessibility, and observability.
• VPC Lattice service: defines the WebSocket application with a TLS passthrough listener and a custom DNS name, app1.example.com. The service is associated with the service network. An instance in the provider VPC which serves as the TLS termination point on port 443 and is the target of the VPC Lattice listener.
• WebSocket application compute: in this example, EC2 instances.
• An Amazon Route 53 Private Hosted Zone (PHZ) : maps the custom DNS name app1.example.com to the VPC Lattice service FQDN app1-example-com-xxxxxxxxxxxxxxxxx.xxxxxxx.vpc-lattice-svcs.<region>.on.aws.

In our examples, we consider a multi-account and multi-VPC architecture pattern a best practice application deployment option, aligned with the AWS Well-Architected framework. Thus, we do not show account boundaries in the architecture diagrams and assume all resources may be deployed across multiple accounts using resource sharing.

East-West traffic pattern

Let’s look at the traffic flow from the client to the application as shown in Figure 3:

Figure 3: East-West traffic pattern within AWS

• Client requests a connection to the custom domain name app1.example.com. The VPC resolver will respond with an IP address in the IPv4 and/or IPv6 link local address range (169.254.0.0/16 or fd00::/7) that corresponds to the WebSocket application service.
• VPC Lattice receives the request and routes it to the service listener on port 443 for the WebSocket application where it establishes the connection in passthrough mode.
• The Lattice listener routes the connection to the target on port 443 based on the Server Name Indication (SNI) where TLS termination and negotiation then occur.
• After TLS negotiation, the WebSocket connection is negotiated between the client and the server over the TLS tunnel. Once complete, the WebSocket connection is established.

In the East-West pattern, both the client and the application reside within AWS. Communication flows from the consumer VPC’s private subnet IP address, through VPC Lattice, to the private subnet IP address of the EC2 instance(s). No additional components beyond VPC Lattice are needed for end-to-end connectivity.

North-South Traffic Pattern

In the East-West pattern, we’ve seen that communication is over private IP addresses through VPC Lattice. However, in the North-South pattern, the clients are outside of AWS on public IP addresses. In many organizations, a centralized ingress model is used so that dedicated networking or security teams can enforce consistent security policies and network controls across incoming Internet traffic, while application teams remain focused on their own services. In this pattern, you use VPC Lattice to forward the WebSocket traffic to the provider VPC from the ingress VPC. Accessing VPC Lattice services from outside AWS is covered in External Connectivity to Amazon VPC Lattice.

The introduction of an NLB and reverse proxy after the centralized inspection firewall serves as the entry point from the Internet to the VPC Lattice Service Network.

Let’s look at the traffic flow from the client to the application as shown in Figure 4:

Figure 4: North-South traffic pattern from Internet to AWS

• Client requests a connection to the public FQDN of the WebSocket application public-app1.example.com and receives back an IP address of the NLB in the ingress VPC.
• The client connection request is received in the ingress VPC where security controls are applied prior to forwarding to the NLB.
• The NLB receives the request and forwards it to a member of the reverse proxy fleet while preserving the original source IP of the client.
• The reverse proxy rewrites the SNI header to the custom domain name of the VPC Lattice service (app1.example.com) and requests a connection. The VPC resolver responds with an IP address in the link-local address range (169.254.0.0/16 or fd00::/7) that corresponds to the WebSocket application service.
• VPC Lattice receives the request, routes it to the service listener on port 443, and forwards the connection to the target instance based on the SNI in passthrough mode.
• TLS termination occurs on the instance, and the WebSocket connection is negotiated between the client and server over the TLS tunnel.

Conclusion

With Amazon VPC Lattice, you can build secure application networks that support real-time, bidirectional WebSocket communication over TLS listeners. This post walked through two connectivity approaches, each with distinct tradeoffs. TLS listeners in passthrough mode fit connections within a 10-minute maximum duration and a configurable 60-600 second idle timeout. VPC Lattice Resources support longer-lived connections, with duration determined by your application and a 350-second idle timeout. Whichever approach you choose, application-level keepalives are essential to maintain connections beyond the idle timeout.

This post also covered two architecture patterns for TLS listeners. The East-West pattern uses VPC Lattice native private connectivity for communication between services inside AWS. The North-South pattern extends this for external client access, adding an Internet gateway, NLB, and reverse proxy to bridge public and private address spaces while preserving connection integrity through SNI rewriting. Both patterns enable you to build scalable, low-latency WebSocket applications without managing complex networking infrastructure, letting you focus on your application logic rather than connectivity plumbing.

To get started, use the patterns and traffic flows described here to select the approach that matches your application’s requirements. For more information, visit the Amazon VPC Lattice documentation and explore the VPC Lattice resources configuration guide. You can also find VPC Lattice blueprints in this GitHub Repository.

About the authors