Scheduled and Manual Scaling

A static fleet does not need the gateway’s internal auto-scaler. Keep hosts installed, then start and stop them on a schedule (or by hand), using the gateway’s drain and capacity APIs so sessions are never killed mid-flight.

Leave internal auto-scale off

For scheduled control of static nodes:

Internal auto-scale is the AMI-catalog path described under Infrastructure. This page covers the external / scheduled path for nodes you already installed.

Scheduler API

These routes live under the gateway HTTP port (default 9000):

MethodPathPurpose
GET/gateway/capacityCluster totals: availableCapacity, utilizationPercent, backendsAcceptingNewSessions, licence edition, absoluteMax.
GET/gateway/capacity/by-tag?tag=gpuCapacity filtered to backends that carry a tag.
GET/gateway/backends?tag=&state=Fleet list; filter by tag and state (draining, active, unhealthy).
GET/gateway/backends/status?backendUrl=Single backend, including activeSessions while draining.
POST/gateway/backends/drainBody { "backendUrl": "http://10.0.2.15:9005" }. Stays registered and heartbeating; no new sessions routed.
POST/gateway/backends/activateResume routing to a drained backend.
POST/gateway/backends/deregisterForce-remove from the registry. Orphans live sessions — drain and wait for zero first.
Warning

Routes under /gateway/* are not authenticated. Protection is network reachability only. Never expose port 9000 beyond the VPC (or a tightly controlled operations subnet). Pair this with the security-group design in AWS Security Groups and Ports.

Example: business-hours fleet with EventBridge

Goal: keep a core set of backends running overnight; start extra tagged instances before the working day; drain and stop them after hours.

  1. Install every backend once (see Installing Backend Nodes) and leave them stopped when not needed.
  2. Tag EC2 instances, for example webstream:role=backend and webstream:pool=daytime.
  3. Create two EventBridge Scheduler rules (or cron expressions):
    • 07:30 weekdays → scale-out Lambda
    • 19:00 weekdays → scale-in Lambda
  4. Attach each Lambda to a VPC subnet that can reach the gateway on port 9000, and grant IAM: ec2:DescribeInstances, ec2:StartInstances, ec2:StopInstances (scoped to the backend instances or tags).

Scale-out sequence (morning)

  1. DescribeInstances for the daytime pool tags; call StartInstances on those that are stopped.
  2. Wait until each node reappears in GET /gateway/stats or /gateway/backends (registration after boot).
  3. If a node was left in drain state, call POST /gateway/backends/activate with its advertised URL.
  4. Optionally confirm GET /gateway/capacity shows the expected availableCapacity.

Scale-in sequence (evening)

  1. Select the backends to retire (by EC2 tag and/or gateway tag).
  2. For each: POST /gateway/backends/drain with { "backendUrl": "..." }.
  3. Poll GET /gateway/backends/status?backendUrl=... until activeSessions is 0, or until a maximum wait you choose.
  4. Call StopInstances (do not stop while sessions remain). Prefer stop over terminate so pool accounts and Windows profiles survive for the next start.
Tip

If the drain wait can exceed the Lambda timeout, drive the poll loop from a Step Functions state machine that invokes short Lambdas, or from an SSM Automation document. The gateway API stays the same.

Why stop/start suits static nodes

Manual alternatives

Limitations