The short answer
Moving from Azure to AWS is straightforward for containerised and IaaS workloads, which map closely to equivalent services. The rework concentrates in identity (Entra ID to IAM Identity Center), platform-specific services such as Cosmos DB and Azure Functions, and licensing — because Azure Hybrid Benefit does not follow you, Windows and SQL Server workloads can become materially more expensive.
Key takeaways
- IaaS and containers transfer with modest effort
- Identity is usually the largest single workstream
- Losing Azure Hybrid Benefit can change the economics entirely
- Data egress from Azure is a real, budgetable line item
Part of our guide to AWS migration: a practical guide to getting it right.
Cloud-to-cloud migration gets described as lift-and-shift, which undersells it. The compute layer usually moves without much drama. The identity model, the managed services and the licensing position are where the work concentrates.
What maps cleanly
Virtual machines, load balancers, object storage and managed relational databases all have close equivalents. An Azure VM becomes an EC2 instance; Blob Storage becomes S3; Azure SQL Database becomes RDS or Aurora. Containerised workloads move most easily of all — AKS to EKS is largely a matter of re-pointing manifests, and anything already defined in Terraform needs provider changes rather than redesign.
What needs rebuilding
Identity. This is usually the biggest workstream. Entra ID and AWS IAM Identity Center are different models, not different implementations of the same model. Managed identities, service principals, conditional access policies and role assignments all need re-expressing. Plan for this to take longer than the compute migration.
Platform-specific services. Cosmos DB, Azure Functions with their binding model, Logic Apps, Service Bus topics and Azure AD B2C have AWS counterparts that behave differently enough to require code changes. DynamoDB is not Cosmos DB with a different name; the consistency model and partition key design differ in ways that affect application logic.
Monitoring and alerting. Azure Monitor queries, workbooks and alert rules do not transfer. Budget time to rebuild dashboards and, more importantly, to re-derive the alert thresholds that were tuned over time.
The licensing shift people miss
Azure Hybrid Benefit lets organisations apply existing Windows Server and SQL Server licences with Software Assurance to Azure compute, often removing a large share of the compute cost on Microsoft-heavy estates. That benefit does not follow you to AWS.
AWS has License Manager and supports bring-your-own-licence for some scenarios, but the terms differ and dedicated hosts may be required. Model the licensed workloads specifically and early. A migration that looks cost-neutral on compute can turn out materially more expensive once Windows and SQL Server licensing is priced properly — and that is a finding you want in week two, not month six.
Egress is a real number
Moving data out of Azure incurs egress charges. For a few terabytes this is a rounding error; for a large data platform it is a line item worth calculating before committing to a date. Where volumes are large, physical transfer appliances or a phased approach that lets data age out naturally are worth evaluating against a straight network transfer.
Deciding whether to move at all
Cloud-to-cloud migration is justified by a strategic reason — an acquisition, a consolidation, a commercial agreement, or genuine capability gaps for your workloads. It is rarely justified by a marginal price difference, because the migration cost plus the productivity dip while your team learns a second platform usually exceeds the saving.
If the driver is cost, model your actual top workloads on both platforms including licensing, support and data transfer before committing. If the driver is capability or commercial terms, the migration cost is a known and bounded price for a strategic outcome, which is a much easier decision to defend.
