1. Options
| Option | How | Good for |
|---|---|---|
| AWS Managed Microsoft AD + forest trust to on-premises AD | AWS runs domain controllers; users stay in on-premises AD | RDS (requires a managed or self-managed AD join), clean separation |
| Self-managed AD domain controllers on EC2 (extension of on-premises AD) | Your DCs in AWS | EC2-only estates; RDS also supports joining self-managed AD |
| SQL authentication only | Logins with passwords | Last resort for legacy apps |
2. Set up AWS Managed Microsoft AD
aws ds create-microsoft-ad --name aws.corp.local --short-name AWSCORP --password '...' \
--edition Standard --vpc-settings VpcId=vpc-0abc,SubnetIds=subnet-a,subnet-b
- Two DCs in two AZs (managed).
- Create a one-way or two-way forest trust with on-premises AD (needs DNS conditional forwarders both ways and ports open over Direct Connect/VPN).
3. Join RDS for SQL Server
- Create an IAM role with the
AmazonRDSDirectoryServiceAccessmanaged policy. - Modify the instance:
aws rds modify-db-instance --db-instance-identifier rds-sql-prod \
--domain d-1234567890 --domain-iam-role-name rds-directory-access --apply-immediately
- Create Windows logins with the master user (SQL login):
CREATE LOGIN [CORP\sql-sales-readers] FROM WINDOWS; -- on-premises group via the trust
USE Sales; CREATE USER [CORP\sql-sales-readers] FOR LOGIN [CORP\sql-sales-readers];
ALTER ROLE db_datareader ADD MEMBER [CORP\sql-sales-readers];
Connect using the domain-qualified endpoint for Kerberos (for example rds-sql-prod.aws.corp.local), not the default RDS DNS name, or clients fall back to NTLM.
4. EC2
Join instances to the domain (SSM AWS-JoinDirectoryServiceDomain document, or seamless domain join at launch). Register SPNs for the SQL service account (or use a gMSA):
setspn -S MSSQLSvc/sqlec2-01.aws.corp.local:1433 AWSCORP\svc-sql
5. Test Kerberos
SELECT auth_scheme, client_net_address FROM sys.dm_exec_connections WHERE session_id = @@SPID;
KERBEROS is what you want; NTLM means SPN or name issues (double-hop scenarios like linked servers and SSRS need Kerberos and delegation).
6. Longer term
Moving apps to IAM / Entra-like token-based identities isn't available for SQL Server on RDS the way it is in Azure SQL, so Windows auth via AD remains the main option. Keep groups tidy and use gMSAs for service accounts.
Tip
Most "login failed for user NT AUTHORITY\ANONYMOUS LOGON" errors after a move are Kerberos delegation problems (double-hop). Check SPNs and constrained delegation before changing SQL permissions.