What Changed on July 28
AWS expanded Enhanced mode in DataSync on July 28, 2026. Three source types now qualify: Hadoop Distributed File Systems (HDFS), Microsoft Azure Blob Storage, and self-managed object storage. Separately, DataSync agents can now be deployed on Microsoft Hyper-V.
The capability is available in all AWS Regions where DataSync is offered.
Before this update, Enhanced mode covered a narrower set of locations. Enhanced mode was available for transfers between Amazon S3 locations, between other clouds and Amazon S3, and between on-premises NFS or SMB file servers and Amazon S3. HDFS, Azure Blob in agent-based configurations, and self-managed object storage fell outside that scope.
Teams relying on those sources were limited to Basic mode, which sequentially prepares, transfers, and verifies files and is subject to quotas on file and object counts.
Why This Matters for Your Migration Stack
Enhanced mode changes three things that matter at scale: parallelism, object count limits, and observability. Enhanced mode provides parallelism, unlimited file counts, and detailed metrics. Basic mode does not offer those characteristics for the same workloads.
For Hadoop environments specifically, the stakes are higher. Enhanced mode HDFS support includes multiple NameNode configurations for high availability and Transparent Data Encryption (TDE) with Kerberos authentication. That combination targets regulated industries directly. Organizations that could not move encrypted Hadoop data without risking availability or breaking compliance controls now have a supported path, at least in principle. AWS frames this as enabling petabyte-scale encrypted Hadoop data migration without sacrificing availability.
For Azure-to-AWS transfers, the picture is more nuanced. Transfers between Azure Blob and Amazon S3 using Enhanced mode do not require an agent. If your migration runs Azure Blob directly to Amazon S3 in Enhanced mode, you may already have a supported path without deploying a new agent. Agent-based configurations remain available for other transfer destinations.
Metrotechs analysis: Hyper-V agent support matters most when your architecture keeps the agent on-premises or when your destination is an AWS storage service other than Amazon S3.
For self-managed object storage, the prerequisite is S3 API compatibility. Your object storage system must support a specific list of Amazon S3 API operations for DataSync to connect, including AbortMultipartUpload, ListObjectsV2, PutObject, and others. If your on-premises object store does not implement all required operations, the transfer will fail at connection time, not at cutover.
Hyper-V agent support removes a virtualization constraint. The announcement does not enumerate which hypervisors or deployment targets were previously supported. It does not state specific Hyper-V version requirements or resource minimums either. Treat those details as unknown until confirmed in the DataSync documentation.
The maximum throughput per task for transfers using a DataSync agent is 10 Gbps, and that ceiling is not adjustable. For petabyte-scale migrations under time pressure, that cap determines minimum task count. Metrotechs analysis: at 10 Gbps (1.25 GB/s), transferring 1 PB takes roughly 222 hours per task assuming sustained throughput, so plan your task topology around that ceiling. Pricing adds a per-execution fee on top of the per-gigabyte rate.
Tasks configured for Enhanced mode are charged a flat per-gigabyte fee plus a fee per task execution. The announcement does not state whether new location types carry different rates. Check the pricing page directly before building a cost model.
What to Verify Before a Pilot
Infrastructure, cloud, and data platform leaders should run through five checks before committing resources to a pilot.
HDFS and Kerberos readiness. Confirm that your Kerberos realm is reachable from the DataSync agent host. Verify that TDE keys are accessible and that the NameNode high-availability configuration matches what DataSync expects. The announcement confirms HA and TDE support but does not enumerate every supported configuration variant.
Azure Blob SAS token permissions. Not having the correct permissions can cause your transfer to fail. For transfers from Azure Blob, the token needs Read and List access at minimum. For transfers to Azure Blob, it needs Read, Write, and List at minimum. Delete is also required if you want DataSync to remove files that aren't in your transfer source.
Transfers from blob storage via archive access tier are blocked, and objects must be rehydrated to hot or cool tier first. Audit access tier distribution before scheduling cutover.
Object storage S3 API surface. DataSync requires a specific set of S3 API operations from your self-managed object store. Pull the API compatibility list from the DataSync documentation and run it against your storage vendor's supported operations list. Any gap blocks the transfer.
Hyper-V agent requirements. The announcement does not state minimum Hyper-V version, vCPU count, or RAM allocation. Tasks transferring more than 20 million files or objects require a minimum of 64 GB of RAM on the DataSync agent. Confirm your Hyper-V host meets that threshold if your dataset approaches that size.
Task quota and throughput math. Basic mode tasks between self-managed storage or other clouds and AWS services are capped at 50 million objects per task execution. Enhanced mode removes that cap for the new location types. But the 10 Gbps per-task throughput ceiling remains. Size your task count to the dataset and your migration window before finalizing the architecture.
Start in the AWS DataSync console and review the documentation for each new location type before provisioning agents or scheduling production transfers.