Why does the Realtime API create more infrastructure risk for serverless applications?

The Realtime API depends on WebSockets and direct connectivity patterns that many serverless platforms do not support natively. That often forces teams to add a separate relay server, which increases operational complexity, adds scaling pressure, and creates another place where secrets and session handling must be protected. The main risk is architectural sprawl, not model capability.

Why serverless changes the risk profile of real-time connectivity

Serverless applications are designed around short-lived, stateless execution, while the Realtime API expects long-lived network state and bidirectional transport. That mismatch matters because the application can stop being “just serverless” once a team introduces a connection broker, relay, or session layer to bridge the gap. The resulting design is no longer a simple managed function flow; it becomes a multi-component integration that must be secured, monitored, and operated like a small distributed system.

That shift increases exposure in places teams often underestimate: connection management, retry behaviour, timeout handling, and the boundaries between the function runtime and the stateful relay. It also changes where trust lives, because the system now depends on a component that can observe, forward, and sometimes hold sensitive session context. For a broad resilience lens, the NIST Cybersecurity Framework 2.0 is useful because it frames the problem as a combination of governance, protection, detection, and recovery rather than as a single integration choice. In practice, many teams discover the operational risk only after the first scaling or incident exercise exposes the relay as the real bottleneck.

How the relay pattern changes ownership, scaling, and failure modes

The core issue is not that the Realtime API is inherently unsafe. The issue is that serverless platforms usually optimise for event-driven, bursty work, while real-time traffic needs persistent sockets, state continuity, and predictable backpressure handling. If a platform cannot host that connection directly, the team usually inserts a proxy or relay service that terminates WebSockets and forwards traffic to the function layer or application backend.

That relay creates several operational consequences. First, it becomes the place where session state, token handling, and connection metadata concentrate. Second, it adds another deployment surface that must be patched, observed, and capacity-planned. Third, it can undermine one of serverless’s main benefits, because a “stateless” architecture now depends on a stateful intermediary that must remain available for the whole user interaction.

Connection lifecycle becomes an operational concern, not just an implementation detail.
Load spikes can hit the relay before they reach the function runtime.
Timeouts, reconnect loops, and idle socket limits can create brittle user behaviour.
Secrets and session context may move through an extra component that now needs hardening.

Where teams get caught out is assuming the provider abstraction removes infrastructure responsibility. It does not; it changes which layer owns the risk. If the relay cannot be scaled, rotated, observed, and recovered quickly, the architecture fails as a whole.

The guidance breaks down when teams try to treat a persistent-connection workload like a normal request-response serverless workload, because the control model and failure model are fundamentally different.

When the serverless pattern is still acceptable, and when it stops being a good fit

Adding a relay is not automatically a mistake, but it does create a tradeoff. Tighter functional decomposition can preserve developer speed, yet it often increases system complexity and makes the real-time path harder to reason about end to end. The practical question is whether the relay is a small, well-bounded edge service or the beginning of a broader architecture split that starts to absorb auth, routing, buffering, and retry logic.

Teams should treat the pattern differently when the workload is user-facing, latency-sensitive, or expected to maintain many concurrent connections. In those cases, the additional hop may be acceptable only if the organisation can operate it as a first-class component. Guidance is not fully settled across the industry on exactly where that boundary sits, because acceptable complexity depends on traffic profile, platform limits, and recovery objectives. What is clear is that the architecture becomes less “serverless-native” as soon as the relay starts carrying state that the platform itself cannot manage.

A useful rule is that if the relay exists only to compensate for protocol mismatch, the design deserves scrutiny; if it also becomes the place where business logic, session continuity, or trust decisions accumulate, the risk has moved beyond convenience and into architecture governance.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OC-01 — Organizational Context	Serverless real-time design choices change operational context and dependency exposure.
	PR.AA-01 — Identity Management, Authentication and Access Control	Relay patterns often concentrate session and token handling in one component.
	RC.RP-01 — Recovery Plan Execution	A stateful relay can become the single point that determines reconnect and service recovery.
Recommendation — Map the relay dependency into governance decisions and define ownership for its availability and trust boundaries. Restrict relay access paths and authenticate every hop that handles session context. Test relay recovery and reconnect behaviour under failure before relying on it for production traffic.
CIS Controls v8	6.3 — Secure Configuration for Enterprise Assets and Software	Relay services introduce additional infrastructure that must be hardened and maintained.
	16.12 — Coordinate Response and Recovery Planning	Operational failure of a relay affects service continuity and incident response.
Recommendation — Harden the relay configuration and remove unnecessary network exposure. Include the relay in incident and recovery exercises so failures do not stall the real-time path.
MITRE ATT&CK	T1021 — Remote Services	Persistent connectivity patterns expand the attack surface for remote access abuse.
Recommendation — Monitor the relay and surrounding services for suspicious remote-session activity.

Practitioner Guidance

What to prioritise: Treat the relay or broker as a production dependency, not a helper service. Ownership should be explicit, because once it mediates real-time traffic it inherits availability, scaling, and trust responsibilities that serverless abstractions do not remove.

What to verify: Confirm where session state lives, how reconnects are handled, and which component holds or forwards sensitive context. Verify that failure of the relay degrades gracefully rather than breaking every active interaction at once.

Decision rule: If the real-time path requires persistent state, long-lived sockets, or custom connection management, do not assume a pure function-only design is still the right architecture. At that point, evaluate whether a purpose-built service is simpler and safer than layering more infrastructure around serverless.

Practitioner takeaway: The main risk is not the API itself but the hidden infrastructure you add to make it work; once that supporting layer exists, it must be governed like any other critical stateful service.