Gaming Cloud Costs: Spot Game Servers, GPUs and Sessions

In most workloads a lost instance is a retry. In a multiplayer game it is a match that ends for every player on that server. That makes the game session, not the instance, the unit a studio’s capacity planning has to protect, and it changes how discounted capacity and GPUs can be used.

How much warning each cloud gives

Spot and preemptible capacity is the obvious lever for game servers and build farms, but the notice windows differ, and all three are best effort:

• AWS: a Spot interruption notice arrives two minutes before the instance is stopped or terminated, via EventBridge and instance metadata. AWS recommends checking for it every 5 seconds.
• Google Cloud: the default preemption notice duration is 0 seconds, followed by a best-effort shutdown period of up to 30 seconds. A 120-second notice can be configured (in Preview). Spot VMs have no minimum or maximum runtime, and GPUs can be attached to them.
• Azure: eviction comes with 30 seconds’ notice through Scheduled Events, and Spot VMs carry no SLA. Evicted VMs are either deallocated (disks still billed) or deleted with their disks, depending on the eviction policy you set.

What a game-server fleet does with that notice

Amazon GameLift Servers shows what session-aware Spot handling looks like. It scores Spot instance types and locations against historical interruption rates, stops placing new game sessions on combinations it judges at risk, and drains those locations. With game session protection on, instances shut down only after their active sessions finish. AWS’s own design guidance warns that longer sessions carry more interruption risk, and recommends placement queues that span several fleets, with at least one On-Demand fleet as backup.

GPUs have their own availability rule

On Google Cloud, instances with attached GPUs cannot live-migrate. They must be set to stop for host maintenance, with about one hour’s notice for most GPU types, and any Local SSD data is unrecoverable when that happens. A GPU build or render box on GCP therefore needs its work checkpointed off local disk, whether or not you ever schedule it.

Where ZopNight fits

ZopNight gives cost visibility, scheduling, recommendations and showback across AWS, GCP and Azure. For a studio:

• Spot recommendations with vetoes. Spot rules cover EC2 (RC-097), GCP VMs (RC-111), Azure VMs (RC-210) and EKS, GKE and AKS node pools (RC-040, RC-114, RC-250). The EC2 rule never recommends Spot for bastion or jump hosts, and the Spot rules skip resources whose names or tags indicate stateful databases. Treat a Spot recommendation as an input to your session placement design, not a switch.
• Idle GPU detection. RC-1500 flags AWS GPU instances whose windowed average GPU utilization is below 20%, once at least 7 days of history exist, using the NVIDIA-SMI metric from the CloudWatch agent. Without that metric it abstains rather than guess.
• Playtest and build estates on a clock. EC2, GCE and Azure VMs, plus Kubernetes namespaces on EKS, GKE and AKS, can be stopped and started on a schedule in your time zone. Namespace stops scale Deployments and StatefulSets to zero and restore them on start. See namespace-level scheduling.
• Launch-day capacity. Event Readiness pre-scales Auto Scaling groups, managed instance groups and scale sets for a known date, then restores the original sizes. See pre-scaling for a launch.

For the pricing mechanics behind all of this, read Spot instances.