Most real-time architecture problems on AWS do not start in application code. They start at the network boundary, where a well-intentioned gateway decides it knows better than your connection.
If you have ever debugged a WebSocket that works perfectly in local development, survives staging, and then dies quietly in production behind a managed service layer, this is probably what happened. Something in the path terminated TLS, re-inspected the traffic at layer 7, and either refused the upgrade or silently dropped the long-lived connection after a timeout it never told you about.
Amazon VPC Lattice recently added TLS Passthrough support, and it changes the calculus for teams building service-to-service real-time communication inside private AWS networks. Here is why that matters more than the headline suggests.
The Core Problem With Layer-7 Gateways and WebSockets
WebSocket connections start life as an HTTP request. The client sends an Upgrade header, the server agrees, and from that point forward the connection becomes a persistent, bidirectional TCP stream. The protocol is clever, but it creates a real problem when a gateway or load balancer is doing TLS termination.
When TLS terminates at the gateway, the gateway decrypts the traffic, inspects it, then re-encrypts it before forwarding. For short-lived request-response cycles, this is fine. For WebSocket connections, it introduces fragility. The gateway now owns the session state. It decides when the connection is idle. It decides when to close it. And it does this based on HTTP semantics that stop applying the moment the upgrade completes.
If your gateway has an idle timeout of 60 seconds and your WebSocket clients send a heartbeat every 90 seconds, you are going to see intermittent disconnects that look random and are very hard to reproduce in tests.
What TLS Passthrough Actually Does
TLS Passthrough routes the encrypted traffic directly to your target without decrypting it at the gateway layer. The gateway reads the SNI field in the TLS ClientHello to decide where to send traffic, but it never sees the payload. From the connection's perspective, the gateway is transparent.
For WebSocket connections, this is significant. The TLS tunnel persists end-to-end between the client and your service. The gateway is not managing session state. It is not making decisions based on HTTP headers, because it cannot see them. The connection lives or dies based on what your application does, not what the gateway decides after a timeout or a re-inspection.
This also means you can implement your own mTLS between services without fighting the gateway's certificate handling. If you have a backend service that requires client certificates for authentication, TLS Passthrough lets that handshake happen directly between services rather than requiring you to configure the gateway to forward client cert headers as some X-Forwarded-Client-Cert workaround.
How VPC Lattice Fits Into This
VPC Lattice is AWS's managed service networking layer. It handles service discovery, routing, and authorization across VPCs and accounts without requiring you to manage VPN tunnels or complex peering arrangements. Before TLS Passthrough support, there was a real tension: you could get the service networking benefits of Lattice, or you could have clean end-to-end encryption with WebSocket support, but getting both at the same time required uncomfortable compromises.
With TLS listeners configured for passthrough, Lattice routes traffic based on SNI rather than HTTP host headers. Your WebSocket upgrade travels intact to a TCP target, and Lattice handles the service discovery and routing policy without touching the connection itself.
A minimal listener configuration for this looks roughly like:
listener:
port: 443
protocol: TLS
tlsConfig:
mode: PASSTHROUGH
defaultAction:
forward:
targetGroups:
- targetGroupId: your-tcp-target-group
weight: 100
The target group here needs to be TCP-based, not HTTP. That is a common mistake when setting this up for the first time. If you configure an HTTP target group with a TLS passthrough listener, the traffic will arrive at your targets encrypted and your application will not know what to do with it.
What This Means for Real-Time Architecture
The practical implication is that teams running real-time backends on AWS now have a cleaner path. You do not have to choose between:
- Service-level networking and auth policies via Lattice
- Persistent, unbroken WebSocket connections
- Your own mTLS implementation between services
You can have all three. Lattice manages discovery and routing. TLS Passthrough keeps the connection intact. Your services handle their own certificate exchange and session management.
This is the configuration that makes sense for internal real-time systems: event streaming backends, collaborative editing infrastructure, live data feeds between microservices. Anywhere you have services that need to maintain long-lived connections to each other inside a private network, and you also need the operational benefits of a managed service mesh.
The takeaway is straightforward: if you have been avoiding VPC Lattice for WebSocket workloads because of how it handled TLS, TLS Passthrough removes that blocker. The configuration is not complex, but you do need to get the target group protocol right from the start, because debugging encrypted traffic that arrived at the wrong protocol handler is not a good afternoon.
