Joining EC2 fleets to a customer's existing AD: no AD Connector, across regions

When you run Windows VDI for an enterprise, the desktops almost always need to join the customer's existing Active Directory so users sign in as themselves, Group Policy applies, and Kerberos works for file shares and profiles. On AWS, the well-trodden paths are AWS Managed Microsoft AD or an AD Connector proxying back to the customer's directory. Both add a managed component, cost, and another thing to operate.

For a fleet that scales up and down all day, we wanted something leaner: join the customer's domain controllers directly, with no intermediary, and have it work across regions.

Connectionless direct join

Each DCV server, on first boot, performs a direct domain join straight against the customer's domain controllers. No AWS Directory Service object, no AD Connector in the path. DNS resolution for the domain (for example corp.example.com) is handled by a Route 53 outbound resolver forwarding the domain's lookups to the customer DCs, and the join uses a delegated service account (stored as a secret) scoped to create computer objects in a specific OU.

The interesting twist is cross-region. The customer's domain controllers live in one region; desktops in other regions join those same DCs over the internal network. With the right routing and the AD service ports open, a fleet thousands of miles from the controllers joins the domain just as cleanly as one next door. We validated reachability for the full set of AD ports before relying on it.

Need EC2 fleets on your existing AD without extra managed components? Book a DCV consultation →

The part everyone forgets: cleanup

A scaling fleet has a dirty secret: every instance that joins AD leaves a computer object behind. Scale up and down a few hundred times and the directory fills with stale objects, an operational mess and a security smell. So join is only half the job; clean removal is the other half.

We handle it in two layers:

• On scale-in: a termination lifecycle hook fires a cleanup routine that removes the instance's computer object from the OU as it goes away. Best-effort, and deliberately never blocking the scale-in itself.
• A scheduled sweep: because the per-instance hook can miss objects (an instance that was already gone, or a moment when AD was briefly unreachable), a periodic job reconciles the OU against live instances and removes orphans that no longer correspond to anything running. It ships in a dry-run mode so you can watch what it would delete before arming it, with a guard that refuses to act if it suddenly finds an implausible number of orphans.

That combination, a best-effort hook for the common case plus a reconciling sweep for the tail, keeps the customer's directory clean without ever risking a stuck scale-in.

Why this matters

Direct domain join isn't novel on its own, but doing it connectionless, across regions, for an autoscaling fleet, with disciplined cleanup is a combination most teams either avoid (and pay for Managed AD / AD Connector) or get wrong (and litter the directory). For the right customer, one with an established AD they want desktops to live in, it's leaner, cheaper, and entirely under their control.

‍

Part of our Amazon DCV series. See also: A production DCV environment in hours, not weeks.

Bringing AWS desktops into your AD? Book a DCV consultation with CloudLife →