How we stand up a full, multi-region Amazon DCV estate (session brokers, connection gateways, an access portal, and autoscaling GPU desktop fleets) in hours instead of weeks, and the engineering decisions behind it.
Standing up GPU-accelerated virtual desktops on AWS is usually a multi-week project: bespoke networking, hand-built golden images, domain join that breaks in subtle ways, certificates, autoscaling that doesn't understand sessions, and a fresh round of yak-shaving for every new region. We kept ending up there too, so we built our way out of it.
Today we provision a full, multi-region Amazon DCV estate, including session brokers, connection gateways, an access portal, and autoscaling GPU desktop fleets, in hours, not weeks. Here's what makes that possible.
The whole platform is driven by small YAML config files that deep-merge from environment to region to tier. Adding a region is a config directory and a pipeline run, not a refactor. There are no copy-pasted stacks to drift apart, and most values are derived rather than hand-set.
Images are built as an inheritance chain (hardened base, then platform, then product, then workload layers), each baked once and reused. Change a component in one layer and it flows everywhere downstream automatically.
Using AWS Image Builder and AWSTOE as the substrate and Claude Code agents running unattended, we produced our CIS-hardened Linux and Windows base images and 54 validated software packages, with repeatable recipes, in about 48 hours: work normally measured in weeks. (Deep-dive coming.)
Images are built in a single region and promoted (copied and re-encrypted under each destination's keys) across regions and accounts by an automated, gated pipeline.
Wrestling with GPU VDI on AWS? Book a 30-minute call with our team →
GPUs are scarce right now. The cards can't be made fast enough, and the popular fractional-GPU instance families are heavily oversubscribed. Running in multiple regions lets the access portal place a session wherever GPU capacity actually exists, transparently: the difference between "no capacity, try later" and "connected in seconds." And because the user's files and Windows profile follow them across regions, they never know which region served them. (Deep-dive coming.)
A small always-on "hot buffer" means users connect immediately; a cheap, pre-joined warm pool replenishes that buffer in about a minute rather than a several-minute cold boot. Instant experience, a fraction of always-on cost, and it's a tunable trade-off you can dial toward "cheapest" or "most instant." (Deep-dive coming.)
None of this is magic. It's a series of specific engineering decisions, each of which we'll unpack:
Amazon DCV is a small world, and getting it right at multi-region scale is rarer still.
If you're wrestling with GPU VDI on AWS, let's talk: book a call with CloudLife →.
.png)
