Scale to zero without giving up control
An on-demand server still needs durable identity, narrow access, and one authority for its lifecycle.
“Run it only when someone needs it” sounds like a cost optimization.
For a game server, it is also a control-plane problem. The machine can disappear, but its identity, data, access policy, and lifecycle decisions cannot disappear with it.
RS Platform keeps those concerns separate.
The instance is not the service
The game server runs on a dedicated on-demand EC2 instance rather than inside the always-on Kubernetes cluster. Game workloads have different CPU, memory, storage, networking, and interruption expectations from small platform services. Packing them together would make the cluster absorb a burst profile it was not sized to carry.
The instance may stop. Its encrypted persistent volume, launch contract, overlay address, approved image, and backup policy remain.
Starting the service means reconciling that contract into a running machine, not waking a pet server that has accumulated private knowledge.
One component owns lifecycle
The console may request start, stop, status, backup, or restore. It does not gain general-purpose EC2 authority.
A narrow runtime identity validates the requested transition and records the result. Repeated requests are idempotent, concurrent starts do not create two servers, and failure leaves a state the reconciler can understand.
This matters because on-demand systems spend much of their life between states. “Stopped,” “starting,” “running,” “stopping,” and “failed to converge” are control-plane facts, not labels inferred from a button click.
Access should not scale out with compute
The server receives no public game port. Traffic arrives over the existing human WireGuard overlay.
Every user already has the base egress permission. A games capability adds
one destination and one declared port for that user’s /32. Starting a server
does not expose a subnet; granting a player access does not require a new VPN
profile.
Because the gateway preserves the user’s overlay address, network policy can enforce the same permission even after the instance behind it is replaced.
Stopping is an operation too
A safe stop needs more than an EC2 API call. The application must quiesce, state must flush to persistent storage, health and player activity need a bounded drain window, and the result must be observable.
If those steps fail, “leave it running and report why” is often safer than forcing a shutdown and claiming savings.
Scale-to-zero is not the absence of infrastructure. It is infrastructure that can preserve authority and state while compute is absent.