Cloud environments on demand: disposable training labs and isolated per-customer hosting
Repeatable cloud environments that are isolated, reachable without public IP addresses, cheap between uses and safe through every lifecycle step.
Part design, not built
Problem
Two infrastructure problems of the same shape. Hands-on training needed realistic Windows desktops, one per trainee, but keeping a lab fleet running was costly, exposing remote desktop to the internet was risky, and building machines by hand was slow and inconsistent. And running a dedicated hosted AI assistant for each customer raised hard operating questions: how to isolate billing, access and data per customer, how to give secure access without exposing servers, how to name many services without certificate and collision problems, and how to pause or remove a customer cleanly while keeping the data recoverable.
Goal
Repeatable environments that are isolated, reachable without public IP addresses, cheap between uses and safe through every lifecycle step.
My role
For the training lab: designed the architecture and wrote all of the automation (golden-image build and capture scripts, the lifecycle command-line tool, first-boot configuration, the idle-shutdown task and the office-suite deployment configuration), and documented setup and operation. For per-customer hosting: designed the operating model and wrote the operational runbooks and deployment lessons. That half is design and runbooks, not built; the provisioning automation lived in separate tooling.
Solution
A disposable training lab: a golden machine image plus numbered, self-configuring Windows VMs, reachable only through an identity-aware tunnel, reaching the internet through NAT, shutting themselves down when idle and deleted after each session, leaving only the image.
An isolated per-customer hosting model (design, not built): each customer service in its own cloud project on a small VM, reachable only through an outbound tunnel with zero-trust sign-in, following a defined provision, suspend, reactivate and cancel lifecycle.
How it works
Training lab.
Build. A script creates a base Windows Server VM with no public IP address. An administrator connects through the tunnel and installs the training tools: the office suite through a deployment configuration, a browser, a remote-management agent, diagnostic utilities and the idle-shutdown task.
Capture. The VM is generalised with Sysprep and captured as a machine image.
Provision. A Bash command-line tool creates any number of numbered VMs in parallel from the image, and also starts, stops, lists and deletes them.
First boot. Each VM reads its own name from the metadata server, renames the host to match, creates a matching trainee account, resets the cloned management agent's device identity so every clone registers as a distinct device (or installs the agent if it is missing), pulls the current exercise scripts from object storage and reboots once.
Operate. Trainees connect through the tunnel; a scheduled task detects idle sessions through native Windows API calls and shuts the machine down; the VMs are deleted when the session ends.
Per-customer hosting (design).
Isolation. Each customer service gets its own cloud project, so billing, access control, quotas and deletion are separate per tenant.
Runtime. A small VM runs the assistant in Docker Compose under a system service manager.
Access. No inbound ports: the VM opens an outbound tunnel, and a zero-trust access application admits only the customer's email domain plus an administrator.
Naming. Single-level per-customer, per-service subdomains, so one free wildcard certificate covers every tenant and services never collide.
Lifecycle. Provision; suspend (stop the VM, keep the disk); reactivate; cancel (stop, take a final snapshot, hold it for a retention window, then remove the tunnel, DNS record and access application through APIs). The runbooks cover idempotent secret provisioning, per-tenant cost modelling and container security trade-offs.
Technical challenges
Cloned machines inheriting one management-agent identity and colliding in the console: reset per clone at first boot.
Identical clones configuring themselves with no human step.
Detecting genuine user idleness from a scheduled task.
Removing all public attack surface while keeping access simple.
Balancing strong tenant isolation against cost.
A naming scheme compatible with free wildcard certificates.
Cancellation that keeps data recoverable for a window before teardown.
Idempotent provisioning steps.
Capabilities
- Parallel provisioning of numbered lab machines
- Golden-image lifecycle
- No public IP addresses
- First-boot self-configuration
- Exercise content pulled at boot
- Idle auto-shutdown and per-session teardown
- Per-tenant project isolation (design)
- Tunnel-only access with domain-restricted zero-trust sign-in (design)
- Collision-free, certificate-friendly naming (design)
- Suspend, reactivate and cancel with snapshot-before-delete (design)
- Per-tenant cost model and operational runbooks
Technology
Impact
Lab setup went from a manual per-machine job to one repeatable command, with no exposed remote-desktop ports and near-zero cost between sessions. The hosting service gained a documented, repeatable way to run a dedicated AI assistant per customer with strong isolation, no exposed servers and a safe exit path. No metrics are claimed.
Skills demonstrated
- Cloud infrastructure automation
- Windows image engineering
- PowerShell and Bash
- Multi-tenant cloud architecture
- Zero-trust network design
- DNS and certificate strategy
- Lifecycle and data-retention design
- Cost engineering
- Operational documentation