About This Project
As a Cloud Engineer, I’m all for going fully cloud. But in the real world, you’ve got those beloved (ahem, ancient) on-premises AD setups with older protocols. They can’t just vanish overnight, so Hybrid Active Directory is sometimes the hero we need. I’ve done similar migrations in Azure with Azure Files, Azure Virtual Desktop, and Entra ID Domain Services—but I wanted to flex my AWS muscles, too. That’s where Adrian Cantrill’s lab came in!
1. Lab Architecture Overview
Connectivity
In production, you’d either set up a Site-to-Site VPN (cheaper, easier) or an AWS Direct Connect (for those with deeper pockets and a pressing need for low latency). In this lab, a simple VPC Peering simulates the on-prem environment.
JumpBoxes
Each VPC has a publicly accessible RDP JumpBox (gasp!). Please don’t do that in the real world without MFA, IP restrictions, and maybe a goat sacrifice—kidding on the last one. Just secure it.
2. Step-by-Step Project Implementation
Step 1: Deploy the CloudFormation Stack
Create a Key Pair (so you can actually log in).
Deploy the template using this link. You'll need to provide the Key Pair name and a domain admin password.
Prepare coffee—this can take a while.
Step 2: Health Checks
RDP into both JumpBoxes (using the key pair to decrypt the passwords).
Make sure each JumpBox can see stuff in its own VPC. If something’s amiss, now’s a great time for a troubleshooting-induced caffeine boost.
Step 3: Create an AWS Managed AD Directory
Go to Directory Services > Create Directory > AWS Managed Microsoft AD.
Fill in details, pick the right subnets, click Create, then wait another 30–40 minutes (another coffee break?).
Once done, spawn a second JumpBox in AWS that’s domain-joined to this new AD. Install RSAT to manage AD.
Step 4: Trust Between the Two Domains
Why Domain Trust Matters
Setting up a two-way trust between your on-prem AD and AWS Managed AD saves you from juggling multiple sets of credentials. This means you don’t have to create (and manage) brand-new usernames and passwords in AWS; users can keep their existing on-prem credentials. Fewer credentials also means fewer helpdesk tickets for password resets—so your support team might actually survive the quarter without quitting.
How the Trust Works
When you enter on-prem credentials to access AWS resources, the trust relationship validates you. That doesn’t automatically grant you full access, though—you still need the right permissions on your on-prem account to be added to the correct groups in AWS. With a two-way trust, AWS-to-on-prem authentication is also possible, though from an end-user standpoint, most folks will stick to on-prem credentials unless you specifically create AWS-based accounts.
To set it up:
DNS Conditional Forwarders: On-prem DNS → add a conditional forwarder for the AWS AD domain. The conditional forwarder should be pointing to the AWS AD DNS IPs, available in your directory service resource in AWS Console.
On-Prem AD Trust: In Active Directory Domains and Trusts, create a two-way forest trust with the AWS domain. Keep track of your trust password— you will need it in the next step.
AWS AD Trust: In AWS Managed AD, set up the two-way trust for your on-prem domain. Use the same password for Trust password in the previous step. For conditional forwarders, add the private IP addresses of on-premise domain controllers.
Test by adding the on-prem admin to an AWS AD group. If you can do that without the system exploding, you’re good.
(Side note: the whole point of trust is so users don’t juggle 2 sets of credentials. Because let’s be honest—nobody likes 100 password resets a day.)
Step 5: File Share in AWS (Amazon FSx)
Create FSx for Windows File Server, linking it to AWS Managed AD and the same subnets. Grab yet another cup of coffee while it provisions (~30 minutes).
From your on-prem JumpBox, map the share via \DNSNAME\share. If it works, hooray!
Realistically, you’d do a more elegant rollout with DFS Namespaces and replication, so people don’t lose their minds when data shifts from on-prem to AWS.
Step 6: AWS WorkSpaces
Go to WorkSpaces, register your AWS Managed AD.
Deploy a Workspace and pick an on-prem user account (this works because we set up that two-way trust).
Download the WorkSpaces Client and log in with on-prem credentials. If you see your brand-new desktop, success!
3. Final Words
At this point, you’ve laid the groundwork for migrating on-prem file services to AWS FSx, enabling on-prem creds in AWS, and replacing local RDP with Amazon WorkSpaces. In a real-world scenario, you’d perform a more careful, phased cutover (especially for file server migrations), install necessary applications that existed on RDP to the new Workspace environment, and migrate user profile data. Still, this demo shows the basic steps—enough to give you a feel for how on-prem-to-AWS migration can look in practice.
I hope you enjoyed this article and learned something new along the way.
Feel free to reach out with any questions!
Happy building! :)
Top comments (0)