WorkSpaces Personal: Entra ID & Intune Integration

Deploying WorkSpaces Personal with Microsoft Entra ID requires configuring IAM Identity Center, MS Graph API permissions, Windows Autopilot, and AWS Secrets Manager across three admin portals. This guide simplifies the process with step-by-step instructions, CloudFormation templates, CLI and architecture diagrams—everything you need to get Entra ID-joined WorkSpaces running in your environment.

Elcio Mello

Solutions Architect - End User Computing

Published Apr 13, 2026

Last modified Jun 26, 2026

Introduction

Amazon WorkSpaces Personal now supports a native Microsoft Entra ID joined directory type, allowing organizations to use their existing Microsoft 365 identity infrastructure to authenticate and manage cloud virtual desktops on AWS — without deploying or maintaining any Active Directory domain controllers.

This guide walks through the complete integration: setting up AWS IAM Identity Center as the identity bridge, federating it with Microsoft Entra ID via SAML and SCIM, configuring Windows Autopilot to automatically enroll WorkSpaces into Microsoft Intune on first login, and deploying the AWS-side infrastructure with CloudFormation and the AWS CLI.

Architecture Overview

Data flow summary:

Users are mastered in Entra ID and synced to IAM Identity Center via SCIM
WorkSpaces authenticates users via IAM Identity Center (SAML federation to Entra ID)
On first login, the WorkSpace (Windows VM) runs Windows Autopilot OOBE — it joins Entra ID and enrolls in Intune automatically
Intune applies device configuration and compliance policies to the WorkSpace

Prerequisites

Complete this checklist before starting. All items are required.

Additionally, use the Deployment Checklist at the end of this guide to validate each phase before proceeding to the next.

Microsoft Licensing

[ ] Microsoft Entra ID P1 or higher (P2 for Conditional Access features)
[ ] Windows 10/11 VDA E3 or E5 per-user subscription licenses
[ ] Microsoft Intune licenses assigned to target users

Microsoft Admin Roles

[ ] Intune Administrator — to create Autopilot profiles and device groups
[ ] Global Administrator — to grant tenant-wide admin consent for API permissions

AWS Account

[ ] BYOL is enabled for WorkSpaces in your AWS account
[ ] A valid Windows 10 or 11 BYOL image has been imported
- Reference: Bring Your Own Windows Desktop Licenses
[ ] AWS Organizations is in place with an organization-level IAM Identity Center instance not yet configured (or configured but using internal users — we will change the identity source)
[ ] A VPC with at least two subnets in different Availability Zones, with outbound internet access (for Autopilot and Intune endpoints)
[ ] AWS CLI installed and configured with sufficient permissions to call workspaces:RegisterWorkspaceDirectory and cloudformation:CreateStack

Supported Windows Versions

Version	Build
Windows 10	21H2 (Dec 2021), 22H2 (Nov 2022)
Windows 11	22H2, 23H2, 24H2, 25H2

Regional Availability

This integration is supported in all WorkSpaces regions except: af-south-1 (Africa/Cape Town), il-central-1 (Israel/Tel Aviv), cn-northwest-1 (China/Ningxia).

Section 1: Enable IAM Identity Center

IAM Identity Center is the identity broker between AWS and Entra ID. For organizations using AWS Organizations, you enable an organization instance from the management account.

IAM Identity Center instance types: AWS supports the following instance types:* An organization instance Enabled from the management account spans all accounts in your AWS Organization and is recommended for this integration.* A member account instance covers only that single account member of the organization.* Standalone accounts can use either of above.
See Enabling IAM Identity Center for the full compatibility matrix.Note: Each WorkSpaces directory can be associated with one IAM Identity Center instance, organization or account.If you are using an organization instance and trying to create a WorkSpaces directory in one of the member accounts, make sure you have the following IAM Identity Center permissions.* "sso:DescribeInstance"* "sso:CreateApplication"* "sso:PutApplicationGrant"* "sso:PutApplicationAuthenticationMethod"* "sso:DeleteApplication"
"sso:DescribeApplication"
"sso:getApplicationGrant"For more information, see Overview of managing access permissions to your IAM Identity Center resources . Also, ensure that no Service Control Policies (SCPs) are blocking these permissions. To learn more about SCPs, see Service control policies (SCPs) .

Steps using Organization (recommended) type of IAM Identity Center instance

Sign in to the AWS Management Console using your management account credentials
Navigate to IAM Identity Center
If not already enabled, choose Enable IAM Identity Center
When prompted, choose Enable with AWS Organizations to create an organization-level instance
Note the IAM Identity Center instance ARN from the Settings page — you will need this later
- Format: arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxxx

Do not navigate to the identity source settings yet. You must first add the enterprise application in Entra ID (Section 2.1) before you change the identity source in IAM Identity Center. Leave this browser tab open.

Section 2: Configure SAML Federation and SCIM Provisioning

This section connects Entra ID to IAM Identity Center using two protocols:

SAML 2.0 — for authentication (single sign-on)
SCIM — for automatic user and group provisioning

Order matters. Complete SAML federation fully (Sections 2.1–2.3) before configuring SCIM (Section 2.4). The SCIM endpoint credentials are only available after the identity source has been changed to External IdP.

2.1 Add the AWS IAM Identity Center Enterprise App in Entra ID

Sign in to the Microsoft Entra admin center at https://entra.microsoft.com
Navigate to Identity → Applications → Enterprise applications
Choose + New application
In the search box, type AWS IAM Identity Center and select it from the gallery
Choose Create — this provisions the pre-integrated application template

2.2 Download AWS Service Provider Metadata

Return to the AWS IAM Identity Center console (the tab you left open)
Navigate to Settings → Identity source tab
Choose Actions → Change identity source
Select External identity provider and choose Next
On the Configure external identity provider page:
- Choose Download metadata file to download the AWS Service Provider (SP) metadata XML
- Copy the AWS access portal sign-in URL shown on this page
Leave this browser tab open — you will return here to upload the Entra metadata

2.3 Configure SAML in the Entra ID Enterprise App

Switch to the Entra admin center tab
Open the AWS IAM Identity Center enterprise application you created in 2.1
Choose Single sign-on in the left menu, then select SAML
Choose Upload metadata file and select the AWS SP metadata file downloaded in step 10
Verify the Basic SAML Configuration is populated correctly
In the Sign on URL field, paste the AWS access portal sign-in URL from step 10
Choose Save
In the SAML Certificates section, choose Download next to Federation Metadata XML
- This is the Entra ID IdP metadata — save this file

2.4 Complete the Identity Source Change in AWS

Return to the AWS IAM Identity Center browser tab (still on the Configure external identity provider page)
Under Identity provider metadata, use Choose file to upload the Federation Metadata XML downloaded from Entra in step 19
Choose Next
Read the disclaimer carefully. Type ACCEPT in the confirmation field
Choose Change identity source

This change is permanent without AWS Support involvement. After this step, all IAM Identity Center sign-ins are handled by Entra ID via SAML. Ensure the Entra ID enterprise app is correctly configured before confirming.

2.5 Enable SCIM Automatic Provisioning

SCIM syncs users and groups from Entra ID to IAM Identity Center. You must configure this after completing the SAML identity source change.

In AWS IAM Identity Center:

Navigate to Settings → Identity source tab
In the Automatic provisioning box, choose Enable
In the dialog that appears:
- Copy the SCIM endpoint URL
- Choose Show token and copy the Access token

Copy both values immediately. The access token is shown only once. If you close this dialog without copying it, you must disable and re-enable provisioning to generate a new token.

Choose Close
Verify that Provisioning method now shows SCIM

In the Entra admin center:

Open the AWS IAM Identity Center enterprise application
Choose Provisioning in the left menu
Set Provisioning Mode to Automatic
Under Admin Credentials:
- Tenant URL: Paste the SCIM endpoint URL from step 27
- Secret Token: Paste the Access token from step 27
Choose Test Connection and confirm it succeeds
Choose Save
Choose Users and groups → + Add user/group to assign the users or groups you want to sync
Choose Overview → Start provisioning

Verify synchronization:

Wait approximately 40 minutes for the initial provisioning cycle to complete
In AWS IAM Identity Center, navigate to Users
Confirm that your Entra ID users appear, with SCIM in the Created by column
If users are missing, check that Entra ID user accounts have First name, Last name, and Display name populated, and that the UPN does not exceed 63 characters

Section 3: Register Entra ID Application for Autopilot

WorkSpaces uses a separate Entra ID application (distinct from the SSO enterprise app) to call the Microsoft Graph API for Windows Autopilot operations — including registering the WorkSpace as an Autopilot device on creation, and removing it from Entra ID and Intune when the WorkSpace is terminated.

3.1 Create the App Registration

In the Entra admin center, navigate to Identity → Applications → App registrations
Choose + New registration
Configure:
- Name: AWS WorkSpaces Autopilot Integration (or a name meaningful to your organization)
- Supported account types: Accounts in this organizational directory only (Single tenant)
- Redirect URI: Leave blank
Choose Register
On the Overview page, copy and save the Application (client) ID — you will need this in Section 5

3.2 Configure API Permissions

In your app registration, choose API permissions → + Add a permission
Select Microsoft Graph → Application permissions
Add each of the following permissions:

Permission	Required for
`DeviceManagementServiceConfig.ReadWrite.All`	Creating WorkSpaces (Autopilot registration)
`Device.ReadWrite.All`	Terminating/rebuilding — removes device from Entra ID
`DeviceManagementManagedDevices.ReadWrite.All`	Terminating/rebuilding — removes device from Intune

Choose Add permissions
Choose Grant admin consent for [Your Tenant Name] — this requires the Global Administrator role

3.3 Create a Client Secret

Choose Certificates & secrets → + New client secret
Enter a description (e.g., AWS WorkSpaces Integration)
Set an expiration period — 24 months is a reasonable balance of security and operational overhead
Choose Add
Immediately copy the secret Value — this is the only time it is displayed

Save these three values before continuing to Section 5:* Application (client) ID — from step 5* Client secret value — from step 15* Directory (tenant) ID — found on the Overview page of your Entra ID tenant in the Entra admin center

Secret rotation: When the client secret approaches expiry, create a new secret in the Entra admin center, then update the Secrets Manager secret value in AWS (see Section 5 teardown/update guidance) and re-register the directory if required.

Section 4: Configure Intune and Windows Autopilot

Autopilot automates the out-of-box experience (OOBE) for the WorkSpace. When a user logs in for the first time, the WorkSpace runs the Autopilot OOBE process, joins Entra ID, and enrolls in Intune — without any manual IT intervention.

4.1 Enable Automatic MDM Enrollment

Sign in to the Microsoft Intune admin center at https://intune.microsoft.com
Navigate to Devices → Windows → Enrollment
Under Enrollment Options, choose Automatic Enrollment
Set MDM user scope to All (or select specific groups if you want to scope enrollment)
Choose Save

4.2 Create a Dynamic Device Group for WorkSpaces

This security group automatically includes any device that Autopilot registers with the WorkSpaces directory tag.

Critical dependency: The WorkSpacesDirectoryName value in the query below must exactly match the WorkSpaces directory name you will use in Section 5. Decide on that name now before creating this group.

In the Intune admin center, navigate to Groups → + New group
Configure:
- Group type: Security
- Group name: AWS WorkSpaces Autopilot Devices (or similar)
- Membership type: Dynamic Device
Choose Add dynamic query
Enter the following rule, replacing WorkSpacesDirectoryName with your chosen directory name:

1
(device.devicePhysicalIds -any (_ -eq "[OrderID]:WorkSpacesDirectoryName"))

Example — if your directory name will be WorkSpacesEntraDir:

1
(device.devicePhysicalIds -any (_ -eq "[OrderID]:WorkSpacesEntraDir"))

Choose Save, then Create

4.3 Create an Autopilot Deployment Profile

Navigate to Devices → Windows → Windows enrollment → Deployment profiles
Choose Create profile → Windows PC
On the Basics tab, enter a name (e.g., AWS WorkSpaces Autopilot Profile), choose Next
On the Out-of-box experience (OOBE) tab, configure:
- Deployment mode: User-driven
- Join to Microsoft Entra ID as: Microsoft Entra joined
- Apply device name template: Optional — using WS-%SERIAL% creates names like WS-<DeviceSerialNumber> (the hardware serial reported by the VM)
On the Assignments tab:
- Select Selected groups
- Add the dynamic device group created in 4.2
Review and choose Create

Section 5: Deploy AWS Infrastructure

The AWS-side infrastructure consists of three resources:

A KMS Customer Managed Key (CMK) to encrypt the Secrets Manager secret at rest
A Secrets Manager secret storing the Entra ID application credentials
A WorkSpaces Entra ID directory tying everything together

The first two are deployed via a CloudFormation stack. The directory registration is a separate AWS CLI step because neither CloudFormation nor any IaC provider currently supports the Entra ID directory type natively.

Prerequisites before starting this section:* Application (client) ID, client secret value, and tenant ID from Section 3* IAM Identity Center instance ARN from Section 1* VPC ID and two subnet IDs in different Availability Zones* AWS CLI installed, configured, and authenticated

Step 1 — Deploy the CloudFormation Stack

The CloudFormation template below creates the KMS CMK and Secrets Manager secret. Copy the full template and save it as a .yaml file before proceeding.

CloudFormation Template

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
AWSTemplateFormatVersion: '2010-09-09'

Description: >

  WorkSpaces Entra ID Integration — KMS CMK and Secrets Manager secret for

  Entra ID application credentials used by WorkSpaces Autopilot operations.

  Deploy this stack before running the AWS CLI directory registration command.



Parameters:



  DirectoryName:

    Type: String

    Description: >

      WorkSpaces directory name. Must exactly match the OrderID value in

      the Intune dynamic device group membership rule (Section 4.2).

    AllowedPattern: '^[a-zA-Z0-9_-]{1,64}$'

    ConstraintDescription: 1–64 alphanumeric characters, hyphens, and underscores.



  EntraTenantId:

    Type: String

    Description: Microsoft Entra ID Tenant ID (GUID) — from Section 3.

    AllowedPattern: '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$'

    ConstraintDescription: Must be a valid GUID (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).



  EntraAppClientId:

    Type: String

    Description: Entra ID Application (client) ID — from Section 3, step 5.

    AllowedPattern: '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$'

    ConstraintDescription: Must be a valid GUID.



  EntraAppClientSecret:

    Type: String

    Description: Entra ID client secret value — from Section 3, step 15.

    NoEcho: true



  Environment:

    Type: String

    Default: poc

    AllowedValues: [poc, dev, staging, prod]

    Description: Deployment environment tag.



  Project:

    Type: String

    Default: workspaces-entraid

    Description: Project tag applied to all resources.



Resources:



  # ---------------------------------------------------------------------------

  # KMS Customer Managed Key

  #

  # Key policy grants:

  #   - Root account: full management (required by KMS)

  #   - workspaces.amazonaws.com: Decrypt + DescribeKey only (least privilege)

  # ---------------------------------------------------------------------------

  EntraCredentialsKey:

    Type: AWS::KMS::Key

    Properties:

      Description: Encrypts WorkSpaces Entra ID integration credentials in Secrets Manager

      EnableKeyRotation: true

      PendingWindowInDays: 7

      KeyPolicy:

        Version: '2012-10-17'

        Id: workspaces-entraid-key-policy

        Statement:

          - Sid: EnableRootAccountManagement

            Effect: Allow

            Principal:

              AWS: !Sub 'arn:aws:iam::${AWS::AccountId}:root'

            Action: 'kms:*'

            Resource: '*'

          - Sid: AllowWorkSpacesDecrypt

            Effect: Allow

            Principal:

              Service: workspaces.amazonaws.com

            Action:

              - kms:Decrypt

              - kms:DescribeKey

            Resource: '*'

      Tags:

        - Key: Name

          Value: !Sub '${DirectoryName}-entra-secret-key'

        - Key: Project

          Value: !Ref Project

        - Key: Environment

          Value: !Ref Environment

        - Key: ManagedBy

          Value: cloudformation



  EntraCredentialsKeyAlias:

    Type: AWS::KMS::Alias

    Properties:

      AliasName: !Sub 'alias/workspaces-entraid-${DirectoryName}'

      TargetKeyId: !Ref EntraCredentialsKey



  # ---------------------------------------------------------------------------

  # Secrets Manager Secret

  #

  # Stores the Entra ID app credentials as JSON:

  #   { "application_id": "...", "application_password": "..." }

  #

  # Resource policy grants workspaces.amazonaws.com GetSecretValue only.

  # The secret is encrypted with the CMK above.

  # ---------------------------------------------------------------------------

  EntraCredentialsSecret:

    Type: AWS::SecretsManager::Secret

    Properties:

      Name: !Sub 'workspaces/entraid-credentials-${DirectoryName}'

      Description: Entra ID application credentials used by WorkSpaces for Autopilot operations

      KmsKeyId: !Ref EntraCredentialsKey

      SecretString: !Sub '{"application_id":"${EntraAppClientId}","application_password":"${EntraAppClientSecret}"}'

      Tags:

        - Key: Name

          Value: !Sub '${DirectoryName}-entraid-credentials'

        - Key: Project

          Value: !Ref Project

        - Key: Environment

          Value: !Ref Environment

        - Key: ManagedBy

          Value: cloudformation



  EntraCredentialsSecretResourcePolicy:

    Type: AWS::SecretsManager::ResourcePolicy

    Properties:

      SecretId: !Ref EntraCredentialsSecret

      ResourcePolicy:

        Version: '2012-10-17'

        Statement:

          - Sid: AllowWorkSpacesGetSecret

            Effect: Allow

            Principal:

              Service: workspaces.amazonaws.com

            Action: 'secretsmanager:GetSecretValue'

            Resource: '*'



Outputs:



  KMSKeyArn:

    Description: ARN of the KMS CMK encrypting the Entra ID credentials secret

    Value: !GetAtt EntraCredentialsKey.Arn

    Export:

      Name: !Sub '${AWS::StackName}-KMSKeyArn'



  KMSKeyAlias:

    Description: Alias name of the KMS CMK

    Value: !Ref EntraCredentialsKeyAlias



  SecretArn:

    Description: >

      ARN of the Secrets Manager secret containing Entra ID app credentials.

      Pass this value as ApplicationConfigSecretArn in the directory registration CLI command.

    Value: !Ref EntraCredentialsSecret

    Export:

      Name: !Sub '${AWS::StackName}-SecretArn'

Deploy via the AWS Console:

Open the CloudFormation console and choose Create stack → With new resources
Select Upload a template file and upload the template saved above
Choose Next and fill in the parameters:

Parameter	Value
Stack name	`workspaces-entraid-<your-directory-name>`
`DirectoryName`	The name you will use for the WorkSpaces directory — must exactly match the `OrderID` value in the Intune dynamic group rule (Section 4.2)
`EntraTenantId`	Directory (tenant) ID from Section 3
`EntraAppClientId`	Application (client) ID from Section 3
`EntraAppClientSecret`	Client secret value from Section 3 (marked `NoEcho` — not shown after entry)
`Environment`	`poc`, `dev`, `staging`, or `prod`
`Project`	Tag value — default `workspaces-entraid`

Choose Next → Next → Submit
Wait for the stack status to reach CREATE_COMPLETE (typically under 2 minutes)
On the Outputs tab, copy the values of KMSKeyArn and SecretArn for reference

Or deploy via the AWS CLI (example command):

1
2
3
4
5
6
7
8
9
10
aws cloudformation deploy \

  --template-file workspaces-entraid.yaml \

  --stack-name workspaces-entraid-<your-directory-name> \

  --parameter-overrides \

      DirectoryName=<your-directory-name> \

      EntraTenantId=<tenant-id> \

      EntraAppClientId=<client-id> \

      EntraAppClientSecret=<client-secret> \

      Environment=poc \

  --region <your-region>

Security note: Avoid passing EntraAppClientSecret as a plain CLI argument in shared or logged environments. Prefer the console entry (which uses NoEcho) or retrieve the value from a secrets store at pipeline time.

Step 2 — Register the WorkSpaces Entra ID Directory

Run the following AWS CLI commands to register the directory (example commands):

2.1. Retrieve the Secret ARN from the CloudFormation stack output

1
2
3
4
5
SECRET_ARN=$(aws cloudformation describe-stacks \

  --stack-name workspaces-entraid-<your-directory-name> \

  --query "Stacks[0].Outputs[?OutputKey=='SecretArn'].OutputValue" \

  --output text \

  --region <your-region>)

2.2. Register the directory

1
2
3
4
5
6
7
8
9
10
aws workspaces register-workspace-directory \

  --workspace-directory-name '<your-directory-name>' \

  --workspace-directory-description '<your-description>' \

  --user-identity-type AWS_IAM_IDENTITY_CENTER \

  --idc-instance-arn 'arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxxx' \

  --microsoft-entra-config "{\"TenantId\":\"<tenant-id>\",\"ApplicationConfigSecretArn\":\"$SECRET_ARN\"}" \

  --workspace-type PERSONAL \

  --tenancy DEDICATED \

  --subnet-ids '<subnet-id-1>' '<subnet-id-2>' \

  --region <your-region>

2.3. They previous command should show "REGISTERED" as output. If not, use the follogin script to check the status until the directory reaches REGISTERED.

1
2
3
4
5
6
7
8
9
10
11
# Poll until the directory reaches REGISTERED state (up to 10 minutes)

for i in $(seq 1 20); do

  STATE=$(aws workspaces describe-workspace-directories \

    --region <your-region> \

    --query "Directories[?WorkspaceDirectoryName=='<your-directory-name>'].State | [0]" \

    --output text)

  echo "Attempt $i/20 — State: $STATE"

  [ "$STATE" = "REGISTERED" ] && echo "Directory registered successfully." && break

  [ "$i" -eq 20 ] && echo "ERROR: Timed out waiting for REGISTERED state." && exit 1

  sleep 30

done

2.4 Use following command to etrive the directory ID

1
2
3
4
5
# Record the directory ID

aws workspaces describe-workspace-directories \

  --region <your-region> \

  --query "Directories[?WorkspaceDirectoryName=='<your-directory-name>'].DirectoryId" \

  --output text

Section 6: Launch a Test WorkSpace

Open the WorkSpaces console at https://console.aws.amazon.com/workspaces/v2/home
Choose Create WorkSpaces
For Directory, select the Entra ID directory created in Section 5
Select a user from the list of synchronized Entra ID users
Select a Windows 10 or 11 BYOL bundle
Configure WorkSpace options as needed
Choose Create WorkSpaces
Wait for the WorkSpace status to become Available (typically 10–20 minutes for first-time provisioning)

Section 7: Verify the Integration

7.1 Verify Autopilot Device Registration

In the Intune admin center, navigate to Devices → Windows → Windows enrollment → Devices
Confirm the WorkSpace appears in the Autopilot devices list with the correct group tag matching your directory name

7.2 User First-Login Experience

When the user connects to their WorkSpace for the first time:

User downloads and installs the WorkSpaces client on their endpoint
User enters their registration code (or email) to find their WorkSpace
User authenticates with Entra ID credentials via the IAM Identity Center SAML flow
Windows Autopilot runs the OOBE process on the WorkSpace:
- The WorkSpace VM joins Microsoft Entra ID
- The WorkSpace VM enrolls in Microsoft Intune
- Intune applies configuration profiles and compliance policies
User arrives at the Windows desktop, fully managed

7.3 Verify in Entra ID and Intune

In the Entra admin center:

Navigate to Devices — confirm the WorkSpace appears as an Entra joined device
Verify the device owner matches the assigned user

In the Intune admin center:

Navigate to Devices → All devices — confirm the WorkSpace shows as Managed
Verify compliance policies and configuration profiles show as Applied

Well-Architected Considerations

Operational Excellence

IaC first: The KMS CMK and Secrets Manager secret are defined in CloudFormation. Avoid manual console changes after stack creation; they will cause stack drift.
Secret rotation: Rotate the Entra ID client secret in the Entra admin center before it expires. Update the Secrets Manager secret value by redeploying the CloudFormation stack with the new EntraAppClientSecret parameter value.
SCIM token rotation: If the SCIM token is ever compromised, disable and re-enable Automatic Provisioning in IAM Identity Center to generate a new token, then update the Entra ID provisioning configuration.

Security

Least privilege: The KMS key policy grants workspaces.amazonaws.com only kms:Decrypt and kms:DescribeKey. The Secrets Manager resource policy grants only secretsmanager:GetSecretValue. Neither uses wildcard principals.
Secrets in CloudFormation: The Entra ID client secret is passed as a NoEcho CloudFormation parameter. It is stored encrypted in the CloudFormation stack's parameter store and in Secrets Manager. Restrict access to the CloudFormation stack via IAM policies to limit who can retrieve parameter history.

Reliability

Two subnets, two AZs: WorkSpaces requires subnets in two different Availability Zones. Single-AZ subnet configurations will fail at directory creation.
SCIM provisioning delay: Initial user sync takes up to 40 minutes. Plan accordingly for day-one user onboarding.
Directory name immutability: The directory name is embedded in the CloudFormation stack parameters and the CLI registration command. Changing it requires deregistering the old directory and re-registering with the new name. Autopilot devices enrolled under the old name will lose their dynamic group membership. Treat the directory name as immutable post-deployment.

Performance Efficiency

IAM Identity Center region alignment: Deploy the IAM Identity Center instance in the same AWS region as your WorkSpaces for lowest authentication latency. If cross-region is unavoidable (e.g., org-level instance already exists in a different region), test authentication latency before production rollout.
WorkSpaces bundle right-sizing: Start with a lower-cost bundle (e.g., Standard) for pilots; scale up to Performance or Power bundles based on measured user experience.

Cost Optimization

Auto-stop vs. always-on: Use Auto-Stop billing mode for knowledge workers who do not need 24/7 access. Always-on is appropriate for shift workers or users who need persistent state.
BYOL licensing cost: Windows 10/11 VDA E3/E5 licenses are a significant cost line. Verify your Microsoft license agreement covers VDA for cloud-hosted virtual desktops.
Secrets Manager pricing: At ~$0.40/month per secret plus $0.05 per 10,000 API calls, this is negligible. KMS CMK costs $1/month plus $0.03 per 10,000 requests.

Sustainability

Serverless and managed services: This architecture uses no self-managed infrastructure. IAM Identity Center, Secrets Manager, and KMS are fully managed — no idle compute to right-size.
Auto-stop WorkSpaces: Auto-stop suspends the WorkSpace VM when idle, reducing energy consumption compared to always-on VMs.

Deployment Checklist

Use this checklist to validate each phase before proceeding to the next.

Phase 1 — IAM Identity Center

[ ] IAM Identity Center enabled as an organization-level instance
[ ] Instance ARN noted
[ ] Identity source changed to External identity provider (Entra ID)
[ ] SAML exchange complete (AWS SP metadata → Entra; Entra IdP metadata → AWS)
[ ] SCIM endpoint and access token copied
[ ] SCIM provisioning configured in Entra ID and status is Running
[ ] Target users visible in IAM Identity Center with SCIM as source

Phase 2 — Entra ID App Registration (Autopilot)

[ ] App registration created
[ ] All three Microsoft Graph API permissions added
[ ] Admin consent granted for all three permissions
[ ] Client secret created and value copied securely

Phase 3 — Intune and Autopilot

[ ] Automatic MDM enrollment enabled (MDM user scope = All or scoped group)
[ ] Dynamic device group created with correct [OrderID]:DirectoryName query
[ ] Autopilot deployment profile created (User-driven, Entra joined)
[ ] Deployment profile assigned to dynamic device group

Phase 4 — AWS Infrastructure

[ ] CloudFormation stack deployed with DirectoryName matching the OrderID value in the Intune dynamic group query exactly
[ ] CloudFormation stack status is CREATE_COMPLETE
[ ] Directory registration CLI command completed with state REGISTERED
[ ] WorkSpaces directory status is Active

Phase 5 — Launch and Verify

[ ] Test WorkSpace launched and status is Available
[ ] WorkSpace appears in Autopilot devices list in Intune
[ ] User authenticated successfully via Entra ID
[ ] Autopilot OOBE completed without errors
[ ] Device appears as Entra joined in Entra admin center
[ ] Device appears as managed and compliant in Intune

Reference Documentation

AWS Documentation

Microsoft Documentation

AWS Infrastructure

# end-user-computing # amazon-workspaces # workspaces

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

WorkSpaces Personal: Entra ID & Intune Integration

Elcio Mello

Introduction

Architecture Overview

Prerequisites

Microsoft Licensing

Microsoft Admin Roles

AWS Account

Supported Windows Versions

Regional Availability

Section 1: Enable IAM Identity Center

Steps using Organization (recommended) type of IAM Identity Center instance

Section 2: Configure SAML Federation and SCIM Provisioning

2.1 Add the AWS IAM Identity Center Enterprise App in Entra ID

2.2 Download AWS Service Provider Metadata

2.3 Configure SAML in the Entra ID Enterprise App

2.4 Complete the Identity Source Change in AWS

2.5 Enable SCIM Automatic Provisioning

Section 3: Register Entra ID Application for Autopilot

3.1 Create the App Registration

3.2 Configure API Permissions

3.3 Create a Client Secret

Section 4: Configure Intune and Windows Autopilot

4.1 Enable Automatic MDM Enrollment

4.2 Create a Dynamic Device Group for WorkSpaces

4.3 Create an Autopilot Deployment Profile

Section 5: Deploy AWS Infrastructure

Step 1 — Deploy the CloudFormation Stack

Step 2 — Register the WorkSpaces Entra ID Directory

2.1. Retrieve the Secret ARN from the CloudFormation stack output

2.2. Register the directory

2.3. They previous command should show "REGISTERED" as output. If not, use the follogin script to check the status until the directory reaches REGISTERED.

2.4 Use following command to etrive the directory ID

Section 6: Launch a Test WorkSpace

Section 7: Verify the Integration

7.1 Verify Autopilot Device Registration

7.2 User First-Login Experience

7.3 Verify in Entra ID and Intune

Well-Architected Considerations

Operational Excellence

Security

Reliability

Performance Efficiency

Cost Optimization

Sustainability

Deployment Checklist

Phase 1 — IAM Identity Center

Phase 2 — Entra ID App Registration (Autopilot)

Phase 3 — Intune and Autopilot

Phase 4 — AWS Infrastructure

Phase 5 — Launch and Verify

Reference Documentation

AWS Documentation

Microsoft Documentation

AWS Infrastructure