Introduction
AWS provides a wide range of Amazon Machine Images (AMIs) for Windows Server operating systems, enabling organizations to quickly deploy supported Windows workloads on Amazon EC2. However, not every Windows operating system is available as a native AWS-provided AMI. There are unsupported operating systems, such as Windows 10 Enterprise.
In addition, organizations that want to preserve existing Microsoft licenses through Bring Your Own License (BYOL) must consider Microsoft's licensing requirements for Windows desktop operating systems which cannot use AWS shared infrastructure of EC2 instances.
This article demonstrates a migration pattern for unsupported Windows desktop operating systems on AWS using Windows 10 Enterprise as a practical example. Using AWS VM Import/Export and EC2 Dedicated Hosts, you'll learn how to import an existing virtual machine, create a custom AMI, and maintain license portability. The same approach can be applied to other unsupported Windows desktop images.
Design Decisions and Key Considerations
Why VM Import/Export instead of AWS Application Migration Service (MGN)?
AWS MGN is the recommended migration path for most workloads. It provides continuous replication and minimal cutover time. However, AWS MGN only supports for existing AMI on AWS Marketplace.
Dedicated Host vs. Dedicated Instance:
Both provide single-tenant hardware, but they differ in granularity and licensing compliance. Dedicated Instances run on hardware dedicated to your account but you do not control which physical host they land on. For Microsoft BYOL compliance, Dedicated Hosts are required — they provide host affinity (an instance can be pinned to a specific physical host), which is what Microsoft's licensing audit requires to verify single-tenant usage.
Choosing the Approach: Current solution (VM Import & Dedicated Host) vs. Amazon WorkSpaces
Before reaching for VM Import/Export, it is worth asking the obvious question: AWS already has a managed Windows desktop service, Amazon WorkSpaces. Why not just use that? The answer comes down to one hard constraint and one cost trade-off, and understanding it is what justifies the more hands-on EC2 path.
Both run on dedicated hardware, but the management model and cost differ.
WorkSpaces BYOL also runs on dedicated, single-tenant infrastructure (Microsoft's licensing requires it, just as it does for EC2). The difference is who manages it:
| Aspect | Amazon WorkSpaces (BYOL) | EC2 Dedicated Host (this guide) |
|---|---|---|
| Underlying host management | Fully managed by AWS | Customer allocates and manages the host |
| User access model | Directory-based (AD / AD Connector) | Direct (SSM / VNC / console) — no directory required |
| Dedicated hardware | Yes (managed) | Yes (self-managed) |
| Cost driver | Per-WorkSpace + dedicated infra; BYOL has scale minimums | Dedicated Host hourly rate |
So WorkSpaces trades control for convenience: AWS manages the host, but you must accept its OS-edition and directory requirements, and you still pay the dedicated-hardware premium. The managed model adds directory setup overhead that is unnecessary for a few machines.
Architecture Overview
Source Virtual Machine Preparation: Create and prepare a Windows 10 Enterprise virtual machine in VMware or VirtualBox. Configure the VM to use BIOS boot mode and optionally run Sysprep to remove machine-specific identifiers before export.
Export the VM as an OVA Image: Export the virtual machine as an OVA file, which serves as the source image for the migration process.
Upload the OVA to Amazon S3: Upload the OVA file to an Amazon S3 bucket dedicated to VM imports. The bucket should remain private and accessible only through the required IAM permissions.
Configure the
vmimportIAM Role: Create an IAM role namedvmimportwith the required trust policy forvmie.amazonaws.comand permissions to read objects from Amazon S3 and create AWS resources during the import process. AWS VM Import/Export uses this role to access the uploaded image.Import the Image Using VM Import/Export: Run the
aws ec2 import-imagecommand with the BYOL license option. During the import process, AWS converts the uploaded virtual machine image into a format compatible with Amazon EC2 and creates the associated resources.Create a Custom AMI: After the import completes, AWS generates a custom Amazon Machine Image (AMI) that appears under the account-owned AMIs and can be used for future instance launches.
Launch the Workload Using BYOL: Allocate an EC2 Dedicated Host and launch an EC2 instance from the imported AMI. For Windows desktop operating systems such as Windows 10 Home, Dedicated Hosts are required to satisfy Microsoft's BYOL licensing requirements.
Manage and Access the Instance: administrative access can be performed through AWS Systems Manager Session Manager, EC2 Serial Console, or third-party remote access tools such as VNC or TeamViewer. Systems Manager can also be used to execute administrative actions and troubleshooting tasks remotely.
Implementation
Step 1: Prepare the Windows 10 Enterprise VM for Export
1a. Create a Clean Windows 10 Enterprise 22H2 VM
Create a Windows 10 Enterprise 22H2 virtual machine in VMware or VirtualBox. Before exporting:
- Install any required software and drivers.
- Run Windows Update to apply all patches.
- Boot mode: keep the VM on BIOS (legacy) boot — Windows 10 imports cleanly with BIOS, whereas UEFI is required only for newer Windows 11 images.
-
Sysprep the VM (optional but recommended for clean import): Run
C:\Windows\System32\Sysprep\sysprep.exe, select Generalize, shutdown mode Shut down. This removes machine-specific identifiers and prepares the image for cloud deployment.
Why Sysprep? VM Import can process non-sysprepped images, but sysprepping avoids hardware ID conflicts when the VM boots on different virtual hardware in AWS. It also resets the SID, which is important if multiple instances will be launched from the same AMI.
1b. Export the VM as OVA
In VMware: File → Export to OVF → select OVA format.
In VirtualBox: File → Export Appliance → OVA format.
If the appliance is exported with an .ovf/.ova chooser, set the file extension to .ova and save.
Step 2: Upload the OVA to Amazon S3
Step 1: Create an S3 bucket in the target AWS region (or use an existing one). Turn off public access.
aws s3 mb s3://your-vmimport-bucket --region us-east-1
Step 2: Upload the OVA file. For large files, use multipart upload via the AWS CLI:
aws s3 cp Windows10Enterprise22H2.ova s3://your-vmimport-bucket/Windows10Enterprise22H2.ova \
--region us-east-1
Step 3: Create the vmimport IAM Role
VM Import/Export requires an IAM service role named exactly vmimport. The name is hardcoded in the VMIE service — a role with a different name will not work.
Step 1: Create the trust policy file trust-policy.json:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "vmie.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "vmimport"
}
}
}
]
}
Step 2: Create the role:
aws iam create-role --role-name vmimport \
--assume-role-policy-document file://trust-policy.json
Step 3: Create the permissions policy file role-policy.json (replace the bucket name):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-vmimport-bucket",
"arn:aws:s3:::your-vmimport-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifySnapshotAttribute",
"ec2:CopySnapshot",
"ec2:RegisterImage",
"ec2:Describe*"
],
"Resource": "*"
}
]
}
Step 4: Attach the policy to the role:
aws iam put-role-policy --role-name vmimport \
--policy-name vmimport \
--policy-document file://role-policy.json
Common failure: If the trust policy uses
"Service": "ec2.amazonaws.com"instead of"Service": "vmie.amazonaws.com", the import job will fail with an authorization error. The correct principal isvmie.amazonaws.com.
Step 4: Run the Import Job
Step 1: Start the import (replace the bucket name and OVA key):
aws ec2 import-image \
--description "Windows 10 Enterprise 22H2 BYOL" \
--license-type BYOL \
--disk-containers Format=ova,UserBucket="{S3Bucket=your-vmimport-bucket,S3Key=Windows10Enterprise22H2.ova}"
The command returns an ImportTaskId (e.g., import-ami-0a1b2c3d4e5f6a7b8).
Step 2: The process can take ~30 minutes. Check progress periodically:
aws ec2 describe-import-image-tasks \
--import-task-ids import-ami-0a1b2c3d4e5f6a7b8
The import goes through stages: pending → converting → updating → booting → preparing AMI → completed. AWS automatically converts the OVA to VMDK during this process.
--license-type BYOL: This flag is critical. It tells AWS that you are bringing your own Windows license rather than using an AWS-provided one. Without this flag, the import may default to using an AWS license, which changes the billing model and may violate Microsoft's licensing terms for your specific agreement.
Step 3: When finished, open the EC2 console → AMIs, filter "Owned by me", to see the imported AMI.
Step 5: Allocate an EC2 Dedicated Host
Microsoft's BYOL terms for Windows 10 desktop operating systems require the EC2 instance to run on a Dedicated Host, physical hardware dedicated to your AWS account.
Step 1: Ensure you have quota for the EC2 Dedicated Host. Open Service Quotas → EC2 and check the quota for your target host family (here, t3). If it is zero, request an increase — AWS may take a few days to provision.
Step 2: Allocate the Dedicated Host. Navigate to EC2 → Dedicated Hosts → Allocate Dedicated Host.
Step 3: Configure the host:
-
Instance family / type: the
t3family (e.g.,t3.medium). Not all instance types are available on Dedicated Hosts — check the AWS documentation for supported types. - Availability Zone: the AZ where you will run the instance.
- Leave the remaining parameters at their defaults (name as you like).
Step 4: Click Allocate and wait for the host status to become Available.
Cost consideration: Dedicated Hosts are billed per hour regardless of whether instances are running on them. A
t3family Dedicated Host costs on the order of a few USD per hour. This is the trade-off for BYOL compliance — you pay for the physical isolation that Microsoft's licensing requires.
Step 6: Launch the EC2 Instance on the Dedicated Host
Step 1: Navigate to EC2 → AMIs. Select the AMI created by the import job and click Launch instance from AMI.
Step 2: Choose the instance type — t3.medium (2 vCPU, 4 GB RAM — minimum recommended for Windows 10).
Step 3: Select an instance profile (for simplicity an admin-capable profile is used here. Not best practice).
Step 4: Set tenancy:
- Tenancy: Dedicated Host
- Target host by: Host ID
- Tenancy host ID: the ID of the Dedicated Host allocated in Step 5.
Step 5: Click Launch instance. Wait for the instance to reach the Running state and pass both status checks.
Step 7: Access the Instance
You can use VNC or TeamViewer for a desktop session, or access the instance through the EC2 console:
Step 1: Select the instance → Connect to instance → Connect.
Alternatively, use an AWS Systems Manager (SSM) document to control the instance indirectly — for example, to disable the Windows Firewall:
Verification
After access/configuration, confirm network reachability — for example, ping the instance's private IP from another instance in the same VPC:
ping <private-ip-of-windows-10-instance>
A successful reply confirms the instance is running and reachable.
Conclusion
This guide covered the full path to running a BYOL Windows 10 Enterprise workload on AWS:
In this article, we demonstrated a migration pattern for unsupported Windows desktop operating systems on AWS using Windows 10 Enterprise as an example. The process begins by preparing and sysprepping the source virtual machine, exporting it as an OVA from VMware or VirtualBox, and uploading the image to Amazon S3. AWS VM Import/Export then uses the vmimport IAM role to access the uploaded image and convert it into a custom AMI through the aws ec2 import-image --license-type BYOL workflow. To comply with Microsoft's BYOL licensing requirements for Windows desktop operating systems, the imported AMI must be launched on an EC2 Dedicated Host rather than shared tenancy infrastructure. Once deployed, the instance can be managed through AWS Systems Manager Session Manager, VNC, or other supported remote access methods
This approach provides a practical path for migrating unsupported Windows desktop workloads to AWS while maintaining license portability and minimizing changes to the original operating system environment.
Author:
Anh Pham
Cloud Consultant, G-AsiaPacific Vietnam
AWS Community Builder




















Top comments (0)