As of October 2025, you can upgrade AWS Managed Microsoft AD from Standard to Enterprise using the self-service UpdateDirectorySetup API - no support ticket required. The upgrade takes 4-5 hours, cannot be reverted, and unlocks support for up to 500,000 directory objects plus multi-region replication. Multi-region replication is not automatically enabled after upgrade - you must configure it separately.
Introduction
AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) offers two editions: Standard and Enterprise. As your organization grows, you may need to upgrade from Standard to Enterprise to support more directory objects or enable multi-region replication for disaster recovery.
Previously, upgrading required opening a support ticket and coordinating a maintenance window with AWS Support. As of October 2025, AWS now provides a self-service API that lets you perform the upgrade programmatically on your own schedule.
Edition Differences
Before upgrading, understand what each edition offers:
| Feature | Standard | Enterprise |
|---|---|---|
| Target organization size | Small/midsize (up to 5,000 employees) | Enterprise organizations |
| Directory objects | Up to ~30,000 | Up to ~500,000 |
| Multi-region replication | Not available | Available |
| Domain controllers | 2 (default) | 2 (default), scales higher |
Directory objects include users, groups, computers, and other AD objects. If you're approaching the 30,000 object limit or need multi-region replication for DR, it's time to consider the upgrade.
Prerequisites
AWS CLI Version Requirement
The update-directory-setup command with --directory-size-update-settings was added in October 2025. If you're running an older CLI version (e.g., 2.17.x from mid-2024), the command will fail with "Unknown options" errors.
Check your version:
aws --version
If your version is below 2.27, update the AWS CLI:
# Windows
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi
# macOS
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /
# Linux
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install --update
After updating, close and reopen your terminal/PowerShell window before running the upgrade command.
Get Your Directory ID
Before upgrading, identify your directory ID using this command:
aws ds describe-directories \
--query "DirectoryDescriptions[*].{ID:DirectoryId,Name:Name,Edition:Edition,Type:Type}" \
--output table
Example output:
------------------------------------------------------------------
| DescribeDirectories |
+---------------+---------------------------+----------+----------+
| ID | Name | Edition | Type |
+---------------+---------------------------+----------+----------+
| d-90661e5f28 | corp.example.com | Standard | MicrosoftAD |
+---------------+---------------------------+----------+----------+
How to Upgrade
You have three options for performing the upgrade:
Option 1: AWS API
Call the UpdateDirectorySetup API with the following payload:
{
"DirectoryId": "d-1234567890",
"UpdateType": "SIZE",
"DirectorySizeUpdateSettings": {
"DirectorySize": "Large"
}
}
Option 2: AWS CLI
aws ds update-directory-setup \
--directory-id d-1234567890 \
--update-type SIZE \
--directory-size-update-settings DirectorySize=Large
Option 3: PowerShell
Update-DSDirectorySetup `
-DirectoryId d-1234567890 `
-UpdateType SIZE `
-DirectorySizeUpdateSettings_DirectorySize Large
Replace d-1234567890 with your actual directory ID. You can find this in the AWS Directory Service console or by running the describe-directories command shown in the Prerequisites section.
Understanding the API Parameters
The API uses SIZE as the update type and Small/Large internally instead of "Standard"/"Enterprise":
| API Value | Console Name | Object Limit |
|---|---|---|
| Small | Standard Edition | ~30,000 |
| Large | Enterprise Edition | ~500,000 |
The UpdateDirectorySetup API also supports other update types:
| UpdateType | Settings Parameter | Purpose |
|---|---|---|
| SIZE | --directory-size-update-settings | Upgrade Standard to Enterprise |
| OS | --os-update-settings | Update Windows Server OS version |
| NETWORK | --network-update-settings | Update network config (IPv6, network type) |
Monitoring Upgrade Status
After initiating the upgrade, you can monitor its progress using the describe-update-directory command:
aws ds describe-update-directory \
--directory-id d-1234567890 \
--update-type SIZE
This returns the update activity including:
- Status -
Updating,Updated, orUpdateFailed - Start time - When the upgrade began
- Status reason - Details if the upgrade failed
You can also verify the directory's current edition:
aws ds describe-directories \
--directory-ids d-1234567890 \
--query "DirectoryDescriptions[0].{Edition:Edition,Size:Size,Stage:Stage}" \
--output table
Once the upgrade completes successfully, the edition will show as Enterprise and the size as Large.
Key Limitations and Considerations
Before initiating the upgrade, be aware of these important limitations:
| Consideration | Details |
|---|---|
| Irreversible | The upgrade cannot be reverted - once upgraded, you cannot go back to Standard |
| Snapshots | Previous snapshots cannot be used to restore the directory after the upgrade |
| Duration | The upgrade takes approximately 4-5 hours |
| Performance impact | Domain controllers are upgraded one at a time, which can cause performance impacts during the process |
| Hostnames | Domain controller hostnames will change, but IP addresses remain the same |
| LDAPS certificates | If using LDAPS, domain controllers will need new certificates after the upgrade |
| Automated snapshots | The API-driven approach includes automated pre-upgrade snapshots for data protection |
| Additional costs | Enterprise edition has higher hourly costs - check AWS Directory Service Pricing |
Plan for a maintenance window during the 4-5 hour upgrade period. While domain controllers are upgraded one at a time, downtime can occur - not just performance degradation. Schedule the upgrade during off-peak hours and notify all dependent applications and teams.
Critical Gotchas
Beyond the standard limitations, be aware of these common pitfalls:
1. Don't Use Static Domain Controller Addresses
Applications should never use hardcoded or static domain controller IP addresses or hostnames. Instead, use the Windows DC Locator service to dynamically discover available domain controllers. This ensures your applications can automatically reach an operational DC if one or more DCs are unavailable during the upgrade (or future patching).
2. Consider Adding Domain Controllers Before Upgrade
By default, AWS Managed Microsoft AD deploys two domain controllers across two Availability Zones. For critical production environments, consider adding additional managed domain controllers through the AWS Directory Service console or API before initiating the upgrade. This provides higher availability during the sequential upgrade process and reduces the risk of service interruption.
# Add domain controllers via AWS CLI
aws ds update-number-of-domain-controllers \
--directory-id d-1234567890 \
--desired-number 4
AWS automatically provisions and manages the additional DCs - you don't create EC2 instances manually.
3. LDAPS Certificate Renewal Options
If you're using LDAPS, you'll need new certificates after the upgrade because domain controller hostnames change. As of September 2025, AWS Private CA Connector for AD supports automatic LDAPS certificate enrollment for AWS Managed Microsoft AD domain controllers, which simplifies this process significantly.
4. Domain and Forest Functional Level Cannot Be Changed
AWS Managed Microsoft AD runs on Windows Server 2019, but operates at the Windows Server 2012 R2 functional level for both domain and forest. You cannot raise this functional level yourself - AWS controls this setting and restricts access to the required elevated privileges (Enterprise Admins / Schema Admins).
This means features that require higher functional levels (like Privileged Access Management with MIM, which requires 2016 level) are not available. If you need full control over functional levels, you would need to run self-managed domain controllers on EC2 instead of using the managed service.
Windows Server 2019 didn't introduce a new functional level - the highest available is still Windows Server 2016. You can open a support case with AWS to inquire about roadmap updates for the functional level.
5. Use the CreateSnapshotBeforeUpdate Parameter
The UpdateDirectorySetup API includes an optional CreateSnapshotBeforeUpdate parameter. While AWS creates automated pre-upgrade snapshots, explicitly setting this to true ensures you have a snapshot taken immediately before the upgrade begins:
{
"DirectoryId": "d-1234567890",
"UpdateType": "SIZE",
"CreateSnapshotBeforeUpdate": true,
"DirectorySizeUpdateSettings": {
"DirectorySize": "Large"
}
}
Remember that while snapshots are taken before the upgrade, they cannot be used to restore the directory after the upgrade completes. They're useful only if the upgrade fails and needs to be rolled back by AWS.
Multi-Region Replication
A common question after upgrading: Is multi-region replication automatically enabled?
No. Multi-region replication is not automatically enabled after upgrading to Enterprise. The upgrade simply unlocks the capability - you must configure it yourself.
Enabling Multi-Region Replication
- After the upgrade completes, go to the Directory Service console
- Select your directory and navigate to the Multi-Region replication section
- From the primary region (where the directory was originally created), choose Add Region
- Select the target region, pick a VPC and subnets in that region, and confirm
AWS then automatically:
- Configures inter-region networking
- Deploys two domain controllers in the new region
- Creates a new AD site named after the region
- Replicates all directory data (users, groups, GPOs, schema) to the new region
Multi-Region Considerations
| Consideration | Details |
|---|---|
| Global operations | Creating AD trusts or updating the schema can only be done from the primary region |
| Adding regions | New regions can only be added from the primary region |
| Directory sharing | Sharing configurations are not replicated automatically - set up per region |
| Opt-in regions | Multi-region replication is unavailable in opt-in regions (Africa/Cape Town, Asia Pacific/Hong Kong, etc.) |
| Costs | Pay per hour for domain controllers in each additional region, plus cross-region data transfer costs |
| Region limit | Default 5-region limit is a soft limit - request an increase through AWS Support if needed |
Pre-Upgrade Checklist
Before initiating the upgrade, complete these steps:
- Update AWS CLI - Ensure you have AWS CLI version 2.27+ installed (the upgrade API was added in October 2025)
- Review costs - Check AWS Directory Service Pricing for Enterprise edition costs
- Plan maintenance window - Schedule 4-5 hours during off-peak hours when downtime is acceptable
- Notify stakeholders - Inform teams that downtime and performance impacts may occur
- Audit applications for static DC references - Ensure no applications use hardcoded DC hostnames or IPs; switch to DC Locator service
- Consider adding domain controllers - For critical environments, add extra DCs before upgrade for higher availability
- Document LDAPS configuration - If using LDAPS, prepare to issue new certificates post-upgrade (consider AWS Private CA Connector for AD)
- Verify backups - Ensure you have recent manual snapshots (note: these won't be usable for restore after upgrade)
- Test in non-production - If possible, test the upgrade process in a non-production directory first
Official Documentation
For the latest information, refer to these AWS documentation links:
Conclusion
The self-service upgrade from Standard to Enterprise edition of AWS Managed Microsoft AD is a significant improvement over the previous support-ticket process. With a single API call, CLI command, or PowerShell cmdlet, you can unlock support for up to 500,000 directory objects and multi-region replication capabilities.
Remember that the upgrade is irreversible and takes 4-5 hours, so plan accordingly. And don't forget - multi-region replication is a separate configuration step after the upgrade completes; it's not automatically enabled.
If you're upgrading primarily for multi-region replication (disaster recovery), plan both the upgrade and the region addition as separate maintenance windows. This gives you time to verify the upgrade completed successfully before adding additional regions.