Azure Databases vs AWS Databases

The Database Mapping

Azure	AWS	Compatibility
Azure SQL / SQL Server Managed Instance	RDS SQL Server, Aurora PostgreSQL	Direct (RDS SQL Server) or re-platform (Aurora PG)
Cosmos DB	DynamoDB	Conceptual (both NoSQL, different APIs)
Azure Cache for Redis	ElastiCache for Valkey/Redis	Near-identical (same protocol)
Azure Database for PostgreSQL	Aurora PostgreSQL, RDS PostgreSQL	Direct migration
Azure Database for MySQL	Aurora MySQL, RDS MySQL	Direct migration

Azure SQL → Aurora PostgreSQL (Recommended)

The biggest win in most migrations. Azure SQL is SQL Server-compatible, which means licensing costs. Aurora PostgreSQL eliminates the license entirely.

Why switch to PostgreSQL instead of RDS SQL Server?

• Cost: Aurora PostgreSQL is 40-60% cheaper than RDS SQL Server (no license fees)
• Serverless scaling: Aurora Serverless v2 scales to near-zero. RDS SQL Server can't.
• Graviton support: Aurora PostgreSQL runs on ARM64 (20% cheaper). SQL Server doesn't.
• Open ecosystem: No Microsoft licensing dependency

What changes

• T-SQL syntax → PostgreSQL syntax (mostly compatible, some differences in functions and date handling)
• Entity Framework Core works with both — change the provider from UseSqlServer() to UseNpgsql()
• Stored procedures need rewriting (if you have them; most modern apps don't)
• SSMS → pgAdmin or DBeaver

What stays the same

• Relational model, joins, transactions
• EF Core migrations, LINQ queries
• Connection pooling (RDS Proxy works like Azure SQL's built-in pooling)

Migration effort

For a modern .NET app with EF Core: 2-4 weeks for a typical service. The schema migrates automatically via EF Core migrations. The pain points are: custom T-SQL, SQL Agent jobs (no equivalent; use Lambda + EventBridge), and SSRS reports (no equivalent; use QuickSight or a reporting tool).

If you can't leave SQL Server, RDS SQL Server is a direct lift-and-shift. Same engine, same tools. You just lose the Graviton and Serverless advantages.

Cosmos DB → DynamoDB

Both are managed NoSQL databases, but the data models and APIs are very different.

Key differences

	Cosmos DB	DynamoDB
Data model	Document (JSON), multi-model	Key-value + document
Query	SQL-like syntax, LINQ support	Key-based queries, limited filtering
Partition key	Partition key per container	Partition key + sort key per table
Consistency	5 consistency levels	Eventually consistent or strongly consistent
Pricing	RU/s (request units)	On-demand (per-request) or provisioned
Global	Multi-region writes (expensive)	Global Tables (simpler, cheaper)

When the switch works well

• Your Cosmos DB usage is primarily key-value lookups and partition-scoped queries
• You're paying for more RU/s than you need (DynamoDB on-demand can be cheaper for variable workloads)
• You want simpler pricing (Cosmos DB's RU model is notoriously hard to predict)

When it's painful

• You rely heavily on Cosmos DB's SQL query syntax for ad-hoc queries
• You use Cosmos DB's change feed with complex filters (DynamoDB Streams are simpler but less flexible)
• Your data model assumes multi-model (graph, column-family). DynamoDB is key-value only

Migration approach

Don't try to migrate Cosmos DB → DynamoDB 1:1. Instead:

1. Map your access patterns (how do you query this data?)
2. Design DynamoDB keys around those patterns
3. Migrate data with a one-time ETL job
4. This is a re-design, not a port

Azure Cache for Redis → ElastiCache for Valkey

This is the easiest database migration. After Redis changed its license in 2024, the clouds diverged: AWS adopted Valkey (the open-source fork backed by AWS, Google, and the Linux Foundation), while Azure partnered with Redis Inc. to build "Azure Managed Redis" on Redis Enterprise.

The good news: Valkey uses the same protocol as Redis. Your application code barely changes. And Valkey isn't standing still. AWS has contributed major performance improvements (multi-threaded I/O, optimized memory allocation) that make it faster than the last open-source Redis release for standard workloads.

What changes

• Connection string (Azure endpoint → ElastiCache endpoint)
• Networking (Azure Private Endpoint → VPC subnet placement)
• TLS configuration may differ slightly
• Some Redis Enterprise-specific features (like RedisJSON, RediSearch modules) don't have Valkey equivalents. If you use those, evaluate carefully

What stays the same

• StackExchange.Redis client works identically
• All core data structures (strings, hashes, sorted sets, streams)
• All standard commands
• Performance characteristics

Migration effort

Days, not weeks. Stand up the ElastiCache cluster, update the connection string, verify. The data is ephemeral (it's a cache) so you don't even need to migrate data. Just let the cache warm up organically.

PostgreSQL / MySQL (Direct Migration)

If you're already on Azure Database for PostgreSQL or MySQL, the migration to Aurora is simple:

1. Use AWS Database Migration Service (DMS) for continuous replication
2. DMS replicates from Azure to Aurora with minimal downtime
3. When ready, cut over by pointing your application to the Aurora endpoint
4. Near-zero downtime migration for most workloads

Data Migration Principles

• Migrate data last. Get your compute layer running on AWS first, pointing back at Azure databases during transition. Cut over data stores individually.
• Use DMS for relational databases. It handles ongoing replication so you can validate before cutting over.
• For NoSQL, redesign. Don't try to replicate Cosmos DB's data model in DynamoDB. Redesign access patterns for DynamoDB's strengths.
• Cache migration is trivial. Redis/Valkey is ephemeral. Stand up the new cluster and let it warm.
• Test with production-like data volumes. Migration tools work great on 1GB but may need tuning for 100GB+.

Further Reading

• AWS Database Migration Service
• Aurora PostgreSQL overview: Serverless v2, read replicas, RDS Proxy
• DynamoDB overview: key design, single-table patterns
• Using DynamoDB with .NET: SDK options, FluentDynamoDB, CDK
• Using Aurora with .NET: EF Core, IAM auth, connection management