JIT VDI: instant GPU desktops without paying for an idle fleet

Interactive virtual desktops have a brutal constraint: the user expects to click "connect" and be working seconds later. With GPU-backed Windows desktops, that's in direct tension with cost. GPU instances are expensive and scarce, and you can't just leave a big fleet running on the off chance someone shows up.

There are two naive answers, and both are bad:

• Always-on fleet sized for peak: instant for users, but you pay for idle GPUs around the clock.
• Cold-boot on demand: cheap at rest, but the user waits. A cold start (launch, Windows OOBE, machine rename, domain join, and the reboots in between) runs to several minutes. No one waits several minutes for a desktop.

We wanted instant and cheap. The key that unlocks both is making the slow part fast.

Pre-pay the domain join

The slow part of a Windows desktop start isn't the OS booting. It's the first-boot ceremony: OOBE, rename plus reboot, domain join plus reboot. So we do all of it before the instance is ever needed.

A launch lifecycle hook holds each new instance in a pending state until its full first-boot configuration completes and signals done. Only then does it enter a stopped warm pool. Every warm instance is therefore already domain-joined and fully prepared. Bringing one into service is just a power-on.

The result: a warm instance comes to life in a little over a minute, versus several minutes cold. That's several times faster, and it's what makes just-in-time capacity viable.

Sizing GPU desktops for instant-and-cheap? Book a DCV consultation →

Two ways to spend the warm-up window

That's fast enough to use two different ways, and the right one is a cost/UX decision, not a technical limit:

• Option A, JIT (warm pool only). No standing hot capacity. When a session is requested, promote a warm instance on the spot. At a little over a minute the start feels close to on-demand, and for many workloads that's perfectly acceptable. It's also the cheapest option, since you pay compute only for sessions actually in use.
• Option B, hot buffer replenished by the warm pool. Keep a small always-on hot buffer so users wait essentially zero seconds; the warm pool's job is then to refill that buffer in about a minute after each allocation. You pay compute for the buffer, but you get instant sessions.

For this customer we chose Option B: the better user experience was worth the extra cost. The elegant part is that the always-on buffer can stay small. Because it refills in about a minute from cheap stopped instances, a small buffer rarely runs dry under normal demand. You're not sizing for peak; you're sizing for "how fast can I top up."

Warm-pool instances are stopped, so you pay only for EBS storage, not compute: a fraction of the running cost. For most organizations, that storage cost is far less than either over-provisioning a hot fleet or making users eat a cold boot.

The bug that nearly sank it

It didn't work the first time. When we first enabled the warm pool, the initial fill launched before the lifecycle hook was in place, so those first instances were stopped mid-OOBE and came back as corrupted, unrecoverable desktops.

The fix is a two-phase enable: stand up the lifecycle hook first (with the warm pool disabled), confirm it's active, then turn on the warm pool so every instance, including the initial fill, is held until it's fully prepared. A small ordering detail with a big blast radius, and exactly the kind of thing that only shows up in production.

Takeaway

Instant GPU desktops and a lean bill aren't mutually exclusive. Move the slow first-boot work off the critical path (pre-pay the domain join) and the only thing left when a user needs a desktop is a power button. From there it's a dial: spend the warm-up window as a near-on-demand wait (cheapest), or hide it entirely behind a small hot buffer (instant). Either way, you stop paying for idle GPUs.

‍

Next in the series: beating the GPU shortage with multi-region session placement.

Part of our Amazon DCV series; start with A production DCV environment in hours, not weeks.

Want this dialed in for your fleet? Book a DCV consultation with CloudLife →