DEV Community

AWS Community Builders profile image Tapas SInghal
Tapas SInghal for AWS Community Builders

Posted on

Building a Secure Enterprise Developer Workspace on AWS

#aws #security #devops #workspace

I've spent the last few months working with enterprise clients who needed to lock down their developer environments without making life miserable for their engineering teams. The challenge? Give developers powerful workstations while keeping sensitive data and intellectual property locked down tight.

After trying various approaches, I landed on a solution using AWS WorkSpaces and Directory Services that actually works in the real world. Let me walk you through exactly how I built it.

Time to complete: 45-60 minutes

Cost: ~$25-35/month per WorkSpace (Standard bundle with AutoStop)

Prerequisites: AWS account with admin access

What You're Actually Building

Here's the setup we're going for:

  • Developers get full Windows desktops, but they live in AWS
  • Authentication ties into your enterprise identity system
  • Access only works from approved networks
  • Data stays on the desktop—no copying files out, no USB drives, nothing
  • Security policies roll out from a central place, not manually on each machine

This isn't theoretical. Companies use this exact pattern when they're serious about data protection.

Step 1: Pick Your Region and Stick With It

First things first—log into your AWS Console and pick a region. I usually go with something close to where my team actually sits to minimize latency.

For this example, let's use ap-south-1 (Mumbai).

Once you've selected it in that top-right dropdown, don't change it. I've seen too many people accidentally create resources across multiple regions and wonder why nothing works together.

Why this matters: WorkSpaces can only use directories in the same region. If you create your directory in Mumbai and try to launch WorkSpaces in Singapore, it simply won't work.

Step 2: Set Up Your Identity System

Every enterprise needs a proper identity system. We're going to use AWS Managed Microsoft AD because it integrates cleanly with WorkSpaces.

  1. Search for Directory Service in the AWS Console
  2. Click Set up directory
  3. Choose AWS Managed Microsoft AD
  4. Pick Standard Edition (unless you're managing thousands of users)
  5. Hit Next

Now configure it:

Directory DNS name:

enterprise.local
Enter fullscreen mode Exit fullscreen mode

Directory NetBIOS name:

ENTERPRISE
Enter fullscreen mode Exit fullscreen mode

Admin password: Create something strong (at least 8 characters with uppercase, lowercase, numbers, and symbols). Save it in your password manager.

For the VPC and subnet selection:

  • Use your default VPC
  • Select two subnets in different availability zones (AWS requires this for high availability)
  • Example: subnet-abc123 (us-east-1a) and subnet-def456 (us-east-1b)

Click through and Create directory.

Grab a coffee. This takes about 20-30 minutes. You'll know it's ready when the status shows Active in green.

Troubleshooting: If directory creation fails, check that your VPC has internet connectivity through an Internet Gateway or NAT Gateway. The directory service needs to reach AWS endpoints.

Step 3: Create Your First Developer User

Now that we've got our identity system running, let's create an actual user.

  1. Go back to Directory Service in the console
  2. Click on your enterprise.local directory
  3. In the directory details page, find the Actions dropdown
  4. You might need to note down the Directory ID (starts with d-) for later
  5. Navigate to the Users section in the left menu
  6. Click Create user

Fill in the details:

Username: dev.user

First name: Dev

Last name: User

Email: (optional but recommended for password resets)

Set a temporary password. Check User must change password at next sign-in if available.

This user represents one of your developers. In production, you'd probably sync users from your on-premise Active Directory using AWS AD Connector, but for this tutorial, we're keeping it simple.

Step 4: Launch Your First WorkSpace

Time to create the actual virtual desktop.

  1. Search for WorkSpaces in the console
  2. Open Amazon WorkSpaces
  3. Click Create WorkSpace

You'll see a wizard. Choose:

  • Personal (persistent) - each user gets their own desktop that persists
  • Windows as the OS

Click Next to move forward.

Step 5: Connect the User to Their Desktop

This part's straightforward:

  1. Select your directory: enterprise.local
  2. Click Next
  3. Pick the user: dev.user
  4. Click Next again

You're basically saying "this desktop belongs to this user." One-to-one mapping.

Step 6: Configure the Desktop Hardware

Now we choose what kind of machine this developer gets.

  1. Pick a Standard Windows bundle
    • 2 vCPU, 4 GB RAM, 80 GB storage
    • Costs about $25-35/month with AutoStop
    • Perfect for most development work (coding, git, basic IDEs)
  2. Set Running mode to AutoStop
  3. Configure AutoStop timeout to 1 hour

This last bit saves you money. If the developer walks away for lunch and forgets to log out, AWS automatically shuts down the WorkSpace after an hour of inactivity. You only pay for the hours it's actually running.

Storage settings:

  • Root volume: 80 GB (default)
  • User volume: 50 GB (default)
  • Leave these as-is unless you know developers need more space

Click Next, review everything, and hit Create WorkSpace.

Another waiting game—usually 10-15 minutes until the status shows Available.

What's happening: AWS is provisioning a Windows Server instance, joining it to your directory, installing the WorkSpaces agent, and configuring all the networking.

Step 7: Lock Down Network Access

Here's where we get serious about security. We only want developers connecting from approved networks—not from random coffee shops or compromised home networks.

  1. In WorkSpaces, go to IP Access Controls
  2. Click Create IP Access Control Group

Name it something obvious:

enterprise-trusted-network
Enter fullscreen mode Exit fullscreen mode

Add a description like:

Trusted enterprise network
Enter fullscreen mode Exit fullscreen mode

Now add your first rule. If you're testing from your office or home:

  1. Find your public IP: Google "what's my IP" or visit https://whatismyipaddress.com
  2. Note down the IPv4 address (looks like 49.204.123.45)
  3. In the IP Access Control Group, click Add Rule
  4. Enter your IP with /32 at the end

Example:

49.204.123.45/32
Enter fullscreen mode Exit fullscreen mode
  1. Add a description like "Home Office" or "Testing Location"
  2. Save the rule

That /32 means "only this exact IP address." In production, you'd use your office network's IP range.

For office networks:

203.0.113.0/24  (allows 203.0.113.0 to 203.0.113.255)
Enter fullscreen mode Exit fullscreen mode

Important: If you have a dynamic IP (changes every few days), you'll need to update this rule whenever your IP changes. Most ISPs offer static IP addresses for business accounts.

Step 8: Attach the Network Rules

Creating the rule isn't enough—we need to attach it to our directory.

  1. Go to WorkSpaces → Directories
  2. Select your enterprise.local directory
  3. Find IP access control groups
  4. Attach enterprise-trusted-network
  5. Save

Now anyone trying to connect from outside those approved IPs? They're blocked at the door.

Step 9: Disable Risky Access Methods

People love convenience, but browsers and mobile devices are security nightmares for enterprise VDI.

While you're in the directory settings:

  1. Find Platform access settings
  2. Turn OFF:
    • Web access
    • Mobile access
  3. Keep only the desktop client enabled

Why? Because the desktop client gives you way more control and security. Browser-based access is a bypass waiting to happen.

Step 10: Start Enforcing Real Security Policies

This is where we stop relying on user behavior and start enforcing rules they can't bypass.

First, you need to connect to the WorkSpace as an administrator:

  1. Download the WorkSpaces client from https://clients.amazonworkspaces.com
  2. Install it on your local machine
  3. Open the client and enter your registration code
    • Find this in the WorkSpaces console under your directory details
    • Looks like WSpdx+ABC123
  4. Log in with dev.user and the password you set earlier

Once you're in the WorkSpace:

  1. Press Win + R and type: 
   gpmc.msc
Enter fullscreen mode Exit fullscreen mode
  1. Press Enter (you'll need to be logged in as a domain admin—you may need to use "Run as different user" with the directory admin account)
  2. Expand Forest: enterprise.local → Domains → enterprise.local
  3. Right-click on Group Policy Objects and select New
  4. Name it: 
   Enterprise-VDI-Data-Restrictions
Enter fullscreen mode Exit fullscreen mode
  1. Right-click your new GPO and select Edit

Group Policy is how Windows administrators have been enforcing security for decades. It works, and users can't weasel around it (if you do it right).

Step 11: Block All the Data Leaks

Here's the meat of our security model. Inside that Group Policy Editor:

Navigate to:

Computer Configuration → Policies → Administrative Templates → 
Windows Components → Remote Desktop Services → 
Remote Desktop Session Host → Device and Resource Redirection
Enter fullscreen mode Exit fullscreen mode

Enable these policies:

  1. Do not allow Clipboard redirection

    • Set to: Enabled
    • Effect: Can't copy-paste between WorkSpace and local machine

  2. Do not allow drive redirection

    • Set to: Enabled
    • Effect: Can't access local drives from the WorkSpace

  3. Do not allow LPT port redirection

    • Set to: Enabled

  4. Do not allow COM port redirection

    • Set to: Enabled

  5. Do not allow client printer redirection

    • Set to: Enabled
    • Effect: Can't print to local printers or "print to PDF"

  6. Do not allow supported Plug and Play device redirection

    • Set to: Enabled
    • Effect: Can't use USB drives or other devices

Apply the changes:

  1. Close the Group Policy Editor
  2. In Group Policy Management, right-click the GPO
  3. Select Enforced to prevent overrides
  4. Link it to your WorkSpaces OU (usually under Computers)

On the WorkSpace, open PowerShell as administrator and run:

gpupdate /force
Enter fullscreen mode Exit fullscreen mode

You'll see output like:

Updating policy...
Computer Policy update has completed successfully.
User Policy update has completed successfully.
Enter fullscreen mode Exit fullscreen mode

Restart the WorkSpace for everything to take effect:

Restart-Computer -Force
Enter fullscreen mode Exit fullscreen mode

I know this sounds draconian, but this is how enterprises actually protect sensitive code and data. If developers need to move files around, they do it through approved channels like git repositories or internal file shares.

Step 12: Remove Local Admin Rights

By default, the first user on a WorkSpace gets local admin rights. That's fine for testing, but terrible for production.

  1. On the WorkSpace, press Win + R and type: 
   compmgmt.msc
Enter fullscreen mode Exit fullscreen mode
  1. Navigate to Local Users and Groups → Groups
  2. Double-click the Administrators group
  3. Select dev.user in the list
  4. Click Remove
  5. Click OK

Log out and log back in for the change to take effect.

Without admin rights, users can't disable the security policies we just set up. They can still install approved software through Software Center or SCCM if you set those up, but they can't bypass your security baseline.

Production tip: In real environments, you'd manage this through Group Policy Restricted Groups or use a privileged access management (PAM) solution where users can request temporary admin rights for specific tasks.

Step 13: Test Everything

Log in as dev.user and try to break your own security:

  • Try copying text from the WorkSpace and pasting it into Notepad on your laptop → Should fail
  • Try printing a document or using "Print to PDF" → Blocked
  • Plug in a USB drive (if you can access the WorkSpace physically) → Nothing happens
  • Try opening Local Group Policy Editor → Access denied

If all those things fail, congratulations. Your security is actually working.

Step 14: Mind Your Costs

Before you walk away, remember that WorkSpaces costs money while it's running.

  • Log out when you're done testing
  • Let AutoStop shut it down after the timeout
  • When you're completely finished with this tutorial, delete the WorkSpace and directory

I've seen too many people leave test WorkSpaces running for months and get surprised by the bill. Don't be that person.

What's Missing (On Purpose)

This tutorial covers the foundation, but real enterprise deployments usually add:

  • VPN requirements - users must connect to corporate VPN first
  • Device certificates - only company-managed devices can connect
  • MDM integration - works with Intune, Jamf, or other MDM platforms
  • Zero Trust architecture - continuous verification of user and device posture
  • CloudWatch monitoring - detailed logging of who accessed what and when
  • Multi-factor authentication (MFA) - requires additional verification
  • Session recording - records all sessions for compliance
  • Data loss prevention (DLP) - additional scanning for sensitive data

Those are all important, but they're layers you add once you've got this foundation solid. Walking before running, and all that.

What You've Actually Built

Take a step back and look at what you've created:

✅ Virtual desktops tied to enterprise identities

✅ Network access restricted to approved locations

✅ Data physically can't leave the environment

✅ Security policies that users can't bypass

✅ A design that scales from 10 users to 10,000

This isn't a toy project. This is the actual pattern companies use when they're handling sensitive intellectual property, financial data, or regulated information.

Final Thoughts

Building secure developer environments is always a balancing act. Lock things down too much and developers find workarounds (usually insecure ones). Too loose and you're one leaked credential away from a data breach.

This WorkSpaces approach isn't perfect, but it's proven. I've deployed variations of this for financial services companies, healthcare organizations, and startups dealing with sensitive customer data.

The key insight? Security works best when it's invisible to the user. Developers don't think about the directory service or the IP restrictions—they just log in and get work done. Meanwhile, your security team sleeps better at night.

If you end up implementing this in production, let me know how it goes. I'm always curious to hear what works (and what doesn't) in different environments.

🌐 My Socials

Feel free to connect with me or collaborate on other serverless & AI projects:

🔗 Portfolio: https://tapasenjinia.me

💼 LinkedIn: https://www.linkedin.com/in/tapas-singhal/

🧠 GitHub: https://github.com/its-tapas

Thanks for reading 🙌 — Tapas Singhal

Top comments (0)