You can't always get a GPU, so we made the desktop appear where you can

GPUs are the scarce resource of the moment. The cards can't be manufactured fast enough, and the popular fractional-GPU instance families are heavily oversubscribed, so "launch a GPU desktop in your home region, right now" is increasingly a request AWS can't always satisfy. For interactive VDI, "no capacity, try again later" isn't an acceptable answer.

So we stopped treating a region as a fixed home and started treating GPU capacity as a pool to be found. If the preferred region is out of the instance type a user needs, the access portal transparently places their Amazon DCV session in another region that has capacity. From the user's point of view, they click connect and get a desktop. They never learn which region served it.

The compute side of that is the easy half: one golden image, baked once and promoted (copied and re-encrypted under each region's keys) so every region runs the identical desktop, with autoscaling fleets ready to serve.

The hard half is data gravity.

The problem: big, chatty files

A desktop in another region is useless if the user's data isn't there too. Our users work with multi-gigabyte creative files (think 10 GB Adobe project files) using applications that are notoriously chatty over the network: lots of small reads and metadata operations, not one clean streaming transfer. Reaching back across a WAN to the home region would make the session unusable. Pre-copying everything to every region would be slow, expensive, and a consistency nightmare. Which copy is authoritative when someone edits in two places?

Wrestling with GPU capacity across regions? Book a DCV consultation →

The solution: ONTAP + FlexCache

We solved it with Amazon FSx for NetApp ONTAP and FlexCache. The files live on an origin volume; each region runs a FlexCache in front of it. Three behaviors make this work:

• Fetch once, then local-speed. The first time a file is opened in a region, FlexCache pulls it from the origin into the regional cache. Every access after that behaves like a local file, exactly what chatty applications need to stay responsive on a 10 GB asset. You pay the WAN cost once, not on every operation.
• Write-back to the origin. ONTAP syncs changes back to the source of truth, so the origin stays authoritative no matter which region the work happened in.
• Distributed file locking. ONTAP enforces coherent locking across caches and origin, so two regions can't both "win" a write on the same file. No last-writer-wins data loss, the failure you'd most fear when the same data is reachable from multiple places.

The net effect: a user gets a GPU desktop in whatever region has capacity, and their work-product is right there, behaving like local storage, with integrity preserved.

Profiles travel the same rails

There's a second, easy-to-miss requirement: the Windows user profile. A lot of application configuration (preferences, workspace layout, per-app settings) lives in the profile, not the file share. If the profile doesn't follow the user into another region, the desktop is technically available but feels wrong: their settings are gone.

Because the profile is just another dataset, the same ONTAP + FlexCache architecture makes it available in every region. The user's profile, and everything persisted in it, follows them wherever the session lands, through exactly the mechanism already carrying their work-product. One architecture, both problems.

Why this matters

Multi-region is usually pitched as resilience or latency. For GPU VDI right now it's also a capacity strategy: the difference between "no GPUs available" and "connected in seconds." But it only delivers if the user's data and the identity of their environment move with them. Pairing transparent cross-region session placement with ONTAP + FlexCache for both work-product and profiles is what turns "multi-region" from an architecture diagram into something users never have to think about.

‍

Part of our Amazon DCV series. See also: JIT VDI, instant desktops without an idle fleet and A production DCV environment in hours, not weeks.

Fighting the GPU shortage? Book a DCV consultation with CloudLife →