Overview and Topology
A multi-node deployment separates the control plane from the session hosts. One gateway node terminates browser traffic and hosts IAM, metrics, and the database; one or more static backend nodes run the Windows applications and stream them back through the gateway.
What a static backend node is
A static backend node is a Windows server you install once and leave running. At startup it registers with the gateway over HTTP, then sends heartbeats so the gateway knows it is healthy and how many sessions it can accept. This is different from an auto-scale-managed instance, which the gateway (or an external scheduler) launches from a worker AMI on demand and terminates when idle.
The fleet is populated by registration, not by a static list. The <gateway><backends><backend> entries in app.config.xml accept only a URL and maxSessions and act as an optional seed; live capacity comes from backends that call POST /gateway/register.
Topology
| Node | Role | Typical services |
|---|---|---|
| Gateway node | Control plane and public entry point | Gateway (443 / 9000), Access Management, Metrics Engine (9009), PostgreSQL |
| Backend node | Session host / worker | Backend HTTP API (9005), streamer WebSockets and HTTP file servers (9010–9251 for a 25-session pool) |
- Clients connect to the gateway on HTTPS 443.
- Backends register and heartbeat to the gateway on port 9000, and post metrics and activity events directly to port 9009.
- The gateway probes each backend on port 9005 and proxies session traffic to the per-session streamer ports.
When to choose static backends
| Choose static backends when… | Prefer auto-scale when… |
|---|---|
| You have a predictable fleet size and want full control over each host (GPU drivers, licensed apps, local data). | Demand varies widely and you want the gateway to launch and terminate workers from an AMI catalog. |
| You schedule capacity by time of day (for example EventBridge start/stop) rather than by live utilization. | You need launch-on-zero and utilization-driven scale-up without keeping idle hosts running. |
| Pool accounts, profiles, and application installs are expensive to rebuild on every launch. | A golden worker AMI already contains the pool and applications, and first-boot registration is reliable. |
Static and auto-scaled backends can coexist in the same registry. This section focuses on the static path; the broader topology ladder is in AWS Deployment Patterns (pattern 3).
Sizing and licence caps
Two independent ceilings apply:
- Per-node capacity — the operator sets
gateway/backend/maxSessions(and a matching session pool ofwebs01…websNN). Effective capacity on that host ismin(maxSessions, licence AbsoluteMax). - Fleet / streamer cap — the licence entitlement
maxBackendAppHostsis enforced against registered backend URLs and against per-session streamer check-ins. Size the licence to total concurrent sessions across the fleet, not just the number of backend hosts.
A Professional key with maxBackendAppHosts = 5 will accept several backends but reject streamer check-ins once five concurrent sessions are active. Confirm entitlements with GET /gateway/license/entitlements before load testing.
What this section covers
- Installing the Gateway Node — WebStream installer in Gateway + IAM/Metrics mode.
- Installing Backend Nodes — Backend Only mode, session pool, tags, and verification.
- AWS Security Groups and Ports — paired security groups sized for up to 25 sessions per backend.
- Backend Tags and Placement Bias — how workspaces select hosts.
- Scheduled and Manual Scaling — EventBridge start/stop and the drain API.
Use the full WebStream installer (WebStreamACP-Setup-*.exe), not the Core / Marketplace installer. Core is single-server only and does not offer Gateway or Backend install modes.