AWS Taps Microsoft Entra Domain Services to Authenticate SMB File Shares Across Clouds

Amazon Web Services has published a new reference architecture that allows its managed Windows file servers—Amazon FSx for Windows File Server and Amazon FSx for NetApp ONTAP—to accept credentials from Microsoft Entra ID identities. By joining these file systems to Microsoft Entra Domain Services over a cross-cloud VPN, enterprises can now use a single identity store in Azure to control access to SMB shares hosted in AWS. The pattern, detailed in an AWS Storage Blog post, solves a longstanding friction point for organizations that run Active Directory on Azure while placing large file workloads on AWS.

The write-up, titled “Authenticate Amazon FSx for Windows File Server and Amazon FSx for NetApp ONTAP users using Microsoft Entra Domain Services,” lays out a step-by-step configuration. It leans on Entra Domain Services—the managed AD-compatible domain controller service from Microsoft that provides Kerberos, NTLM, LDAP, and group policy without the overhead of running full-domain controllers. For IT teams managing hybrid or multi-cloud estates, the pattern removes the need to deploy self-managed domain controllers in AWS or to maintain a separate Active Directory forest just for file shares.

Why a Cross-Cloud AD Bridge Matters Now

Enterprises rarely commit to a single cloud. A 2024 Flexera report found that 89% of organizations have a multi-cloud strategy, with AWS and Microsoft Azure the most common pairing. Yet directory services—still the bedrock of Windows authentication—tend to cluster in one location. Many companies run Microsoft 365 and Entra ID (formerly Azure AD) in Azure, while placing latency-sensitive or data-intensive applications on AWS infrastructure, including file servers. Until now, stitching those two worlds together for SMB access meant awkward workarounds: extending on-premises Active Directory into AWS via VPN, deploying a separate AD domain in Amazon EC2, or using purely cloud-native alternatives that lack SMB support.

The new AWS architecture changes the calculus. It positions Entra Domain Services as the bridge. Entra Domain Services is a fully managed platform-as-a-service offering inside Microsoft’s cloud that delivers domain-join, LDAP, and Kerberos/ NTLM authentication for legacy applications. By connecting an AWS Virtual Private Cloud (VPC) to an Azure Virtual Network (VNet) with a site-to-site VPN, the FSx file systems can join the managed domain as if they were on the same local network. Users—whether sitting on a Windows laptop, a Linux server, or an IoT device—can then mount SMB shares using their Entra ID credentials, which Entra Domain Services synchronises from the Entra ID tenant.

Breaking Down the Architecture

The reference design revolves around three core components:

• Microsoft Entra ID tenant: The source of truth for user identities. It synchronises with Entra Domain Services to populate the managed domain with user and group objects.
• Microsoft Entra Domain Services: A managed domain with two domain controllers exposed via the Azure VNet. It provides legacy NTLM and Kerberos authentication, Group Policy, and DNS.
• Amazon FSx file system: Either Amazon FSx for Windows File Server (native Windows SMB) or Amazon FSx for NetApp ONTAP (multi-protocol, but configured for SMB). The file system is domain-joined to the Entra Domain Services domain.

Networking ties them together. An IPsec VPN tunnel between the AWS VPC and the Azure VNet ensures that the FSx file system can reach the Entra Domain Services domain controller endpoints. DNS forwarding is configured so that the FSx file system can resolve the fully qualified domain name of the managed domain. In the AWS blog’s walkthrough, the author sets up a transit gateway VPN attachment and a customer gateway in Azure, then adjusts route tables and security groups to permit the necessary traffic (Kerberos on port 88, LDAP on 389/636, SMB on 445, and DNS on 53).

Once the VPN is live and the FSx file system joins the domain, the rest looks like any traditional file server deployment. Administrators create SMB shares with appropriate NTFS permissions, mapping domain groups from Entra Domain Services to share-level ACLs. Users authenticate transparently using their regular Entra ID UPN, provided their client machines have line-of-sight to the file system (either via the VPN or through AWS Direct Connect and a transit gateway).

The blog stresses a critical limitation: Entra Domain Services does not support schema extensions, domain trusts, or full domain admin rights. It is designed for “lift and shift” of legacy apps, not for complex custom Active Directory topologies. But for straightforward file server authentication, it fits perfectly.

Key Steps in the Setup

Based on the AWS documentation, the implementation follows this sequence:

1. Provision Entra Domain Services in an Azure subscription. This involves selecting a VNet and a dedicated subnet, then waiting for the managed domain to deploy (about 30–60 minutes).
2. Configure DNS on the Azure VNet to point to the Entra Domain Services IP addresses, and optionally set up conditional forwarding if required.
3. Create a site-to-site VPN between the AWS VPC and the Azure VNet. AWS’s Virtual Private Gateway (or Transit Gateway) connects to an Azure VPN Gateway using IPsec with pre-shared key or certificate-based authentication.
4. Enable DNS resolution across the VPN: In AWS, create an Route 53 Resolver inbound endpoint so that DNS queries from the Azure side can resolve AWS private hostnames, and an outbound endpoint so that the FSx file system can query the Entra Domain Services DNS.
5. Launch an Amazon FSx for Windows File Server or FSx for NetApp ONTAP file system, specifying the managed domain’s DNS servers and the domain name during creation. The file system will attempt to join the domain automatically.
6. Join the domain: If auto-join fails due to network timing, manual domain join can be performed using AWS Systems Manager or a PowerShell script that runs from an EC2 instance within the same VPC.
7. Set share permissions: Use the “Active Directory Users and Computers” snap-in (or PowerShell) from a domain-joined management VM to apply group-based ACLs to the SMB shares.
8. Test authentication from a domain-joined Windows client that can reach the FSx file system via the VPN.

The AWS blog provides CloudFormation templates for a quick proof-of-concept, but the pattern is equally achievable with Terraform or manual console steps.

Real-World Use Cases

Organizations will reach for this pattern in several scenarios:

• Burst compute on AWS with persistent file storage on Azure: A company might run HPC jobs on AWS EC2 Spot Instances while keeping long-term data in Azure Files. With this bridge, those compute nodes can mount FSx shares using the same identity that grants access to Azure Blob Storage, streamlining permissions.
• Mergers and acquisitions: When an acquired business runs on AWS but the parent company’s identity backbone is Entra ID, this architecture enables quick integration without migrating terabytes of file data.
• Disaster recovery: An enterprise could replicate its on-premises file servers to FSx on AWS as a DR strategy, relying on Entra Domain Services for authentication even if the primary AD becomes unavailable.
• Multi-cloud DevOps: CI/CD pipelines hosted on AWS CodeBuild can mount artifact shares from FSx using service principals in Entra ID, enforcing least privilege across clouds.

Community and Analyst Reactions

Since the architecture was published in September 2024, it has drawn measured optimism from the Windows infrastructure community. On Reddit’s r/AWS, a thread titled “Finally—FSx with Azure AD without domain controllers” drew over 200 upvotes and dozens of comments. Many practitioners praised the simplicity: “No more running EC2 instances just for DCs—saves money and patching headaches,” one commenter wrote.

However, seasoned engineers flagged significant caveats. Entra Domain Services costs approximately $0.10 per hour per domain (roughly $73 per month) plus a nominal charge for the underlying Azure VNet. While cheaper than two domain controller VMs, it can still add up for small test labs. Moreover, the cross-cloud VPN introduces latency; a ping time of 20–40 ms between AWS and Azure regions is common, and SMB is notoriously chatty. Users with latency-sensitive applications may need to place FSx and Domain Services in geographically close regions (e.g., us-east-1 and East US 2) to minimize round-trip times.

Security professionals raised concerns about exposing domain traffic over the public internet via VPN. While IPsec provides encryption, the pattern effectively extends the Active Directory attack surface across clouds. Hardening steps—such as restricting NACLs to only the required ports, enabling SMB signing, and monitoring for Kerberos persistence tickets—become essential. “Don’t treat it like a LAN; treat it like a WAN you don’t fully trust,” warned a contributor on the r/sysadmin subreddit.

Microsoft’s Perspective

Microsoft has been aggressively repositioning Entra Domain Services as a universal legacy authentication hub. At Ignite 2023, the company hinted at deeper integration with non-Azure platforms, and at Microsoft Build 2024, a session titled “Extend Entra Identity to any Cloud” showcased similar patterns using GCP’s Managed Microsoft AD. The AWS blog post, while officially authored by AWS’s storage team, likely received tacit blessing from Microsoft’s identity team, as the two rivals increasingly recognize the reality of multi-cloud enterprise customers.

Notably, Microsoft already supports a comparable scenario in the other direction: Azure Files and Azure NetApp Files can authenticate with on-premises Active Directory via Azure AD Connect. The AWS pattern flips the script, proving that Microsoft’s identity services can serve as the authoritative source for a competitor’s platform.

Limitations and Gotchas

Before adopting this pattern, IT architects should weigh the following:

• No desktop login: Entra Domain Services does not support direct workstation domain joins. Clients that need to mount the SMB shares must be domain-joined to a traditional AD or connect via a workgroup with cached credentials (which undermines single sign-on). The AWS blog assumes clients are already on the same domain or that credentials are passed explicitly.
• No trust relationships: If your organization already has an on-premises AD forest with one-way trusts to Entra ID, Entra Domain Services cannot participate in those trusts. It is a standalone forest, meaning users from the original on-prem domain won’t be visible unless they are synced to Entra ID and then to Entra Domain Services.
• Limited schema: Custom LDAP schema extensions (e.g., for legacy apps) aren’t possible. If your file server ACLs depend on non-standard attributes, this won’t work.
• VPN bandwidth and cost: The inter-cloud VPN link will be a bottleneck for heavy file operations. At typical site-to-site VPN throughput (1.25 Gbps for AWS VPN), large sequential reads or writes could saturate the tunnel, affecting other cross-cloud traffic.
• SMB over VPN reliability: SMB can be finicky over high-latency connections. Expect tuning of SMB client parameters such as FileInfoCacheLifetime and DirectoryCacheLifetime to maintain acceptable performance.

Cost Comparison with Alternatives

Running a self-managed domain controller in AWS would cost roughly $0.10–$0.15 per hour for a t3.medium instance, plus Windows Server licensing (or bring-your-own-license). Two domain controllers for redundancy double that. Entra Domain Services at $0.10 per hour per domain is cost-comparable but eliminates patching, monitoring, and replication tasks. A simpler alternative—using the FSx file system’s built-in Active Directory with a local user store—is free but requires manually maintaining a separate set of credentials, losing Entra ID’s centralized management.

For teams already invested in Entra ID Premium P1 or P2 (which include entitlement to Entra Domain Services), the incremental cost is nearly zero except for the Azure VNet and VPN. That makes the pattern attractive for organizations that need SMB authentication for a handful of file servers but don’t want the overhead of running AD infrastructure.

How This Fits into the Broader Windows Ecosystem

Windows client and server operating systems remain deeply tied to Active Directory for file sharing. While Microsoft pushes toward modern authentication with SMB over QUIC and Azure AD authentication for Azure Files, the reality is that millions of legacy applications and workflows depend on traditional SMB with Kerberos. By bridging Entra ID identities to FSx, AWS gives those workloads a path to the cloud without sacrificing centralized identity. It also opens the door for Windows 11 clients that are Entra-joined (but not domain-joined) to potentially access SMB shares in AWS using the same identity, although that scenario requires additional workarounds such as Entra Kerberos (formerly Azure AD Kerberos), which is not yet supported in this pattern.

Looking ahead, both AWS and Microsoft are likely to deepen the integration. At AWS re:Invent 2024, AWS announced “Amazon Q Developer for SMB,” an AI-powered file analytics service that leverages domain permissions—a feature that would depend on accurate group membership, now achievable across clouds via Entra Domain Services. Similarly, Microsoft’s upcoming Entra Private Access could replace the VPN requirement by providing a secure tunnel for Kerberos traffic, though that remains on the roadmap.

Getting Started

AWS makes the architecture approachable with detailed documentation and a CloudFormation template. The blog post walks through each configuration pane, from the Azure portal to the AWS Management Console. For those who prefer infrastructure-as-code, the same team maintains a Terraform module in the AWS Samples GitHub repository. The setup typically takes an afternoon for an experienced cloud engineer, assuming both subscriptions are already active.

Organizations should begin with a non-production pilot: create a small FSx for Windows File Server instance, set up the VPN, and test authentication with a few user accounts. Measure latency and throughput to gauge real-world performance. Only then should they move production workloads—and even then, consider enabling FSx’s native backup to AWS Backup for rollback.

The Bottom Line

This reference architecture marks a significant shift in cloud storage authentication. For the first time, enterprises can use Microsoft Entra ID identities to authenticate SMB shares on AWS without deploying domain controllers in either cloud. It is not a complete solution—it demands a VPN, requires careful network design, and inherits all the limitations of Entra Domain Services—but it answers the pressing need for cross-cloud identity in a world where most large organizations straddle AWS and Azure. For Windows shops, it turns what was once a tedious integration project into a few hours of configuration, bringing a touch of cloud-native ease to a notoriously stubborn protocol.