Migrate from Azure
to AWS
Azure-to-AWS represents the largest cloud-to-cloud migration path by market share, requiring systematic translation of Azure's resource management model, identity fabric, and managed services into AWS equivalents. Success depends on treating this as a platform re-architecture rather than a lift-and-shift, particularly for identity management where Azure AD's deep integration with Microsoft services must be replaced by a combination of AWS IAM Identity Center, Cognito, and AWS Organizations.
When Azure stops working
Azure stops being the right choice when your architecture increasingly depends on services where AWS has clear market leadership—such as Lambda for serverless compute, S3 for object storage with its unmatched ecosystem of integrations, or the breadth of purpose-built databases including DynamoDB, Aurora, Neptune, and Timestream. Organizations migrate when they find Azure's service reliability and regional availability don't meet their SLA requirements, or when Azure's managed Kubernetes offering (AKS) lacks the maturity of EKS's control plane management and Fargate integration. Teams building event-driven architectures often find AWS's EventBridge, Step Functions, and SNS/SQS ecosystem more cohesive than Azure's equivalent combination of Event Grid, Durable Functions, and Service Bus. The migration becomes compelling when your engineering team's expertise skews heavily toward AWS, recruitment is easier for AWS skills, and the broader AWS partner ecosystem provides better tooling support.
What AWS unlocks
AWS unlocks the broadest service catalog of any cloud provider with over 200 services, giving teams purpose-built options for nearly every workload pattern instead of general-purpose Azure services stretched to fit. EC2 provides the widest selection of instance types including Graviton ARM-based instances that deliver up to 40% better price-performance for compatible workloads. S3's durability guarantees (eleven nines), versioning, lifecycle policies, and ecosystem integration make it the industry standard for object storage. AWS's serverless ecosystem—Lambda, API Gateway, DynamoDB, Step Functions, and EventBridge—is the most mature in the industry, enabling event-driven architectures that reduce operational overhead. EKS with Fargate allows running Kubernetes pods without managing nodes, and App Runner provides a simpler container deployment model for teams that don't need full Kubernetes. AWS's Reserved Instance marketplace allows selling unused commitments, providing financial flexibility that Azure Reserved Instances lack.
Who should not migrate
Organizations that have built their entire identity and access management around Azure AD with conditional access, Privileged Identity Management (PIM), and deep Microsoft 365 integration should not migrate unless they're prepared to fundamentally rearchitect their identity layer. Enterprises running .NET workloads on Azure App Service with deployment slots, Azure Functions with .NET isolated worker model, and Azure SignalR Service benefit from first-party Microsoft platform optimization that AWS cannot match. Companies using Azure's sovereign cloud offerings (Azure Government, Azure China operated by 21Vianet) for compliance may not find equivalent AWS offerings in their required jurisdictions. Teams heavily invested in Power Platform (Power Apps, Power Automate, Power BI) with Azure data backends would lose critical low-code integration capabilities. Organizations using Azure Arc for hybrid and multi-cloud management have built operational patterns that would require significant rework with AWS Systems Manager and Outposts.
What usually goes wrong
The most frequent failure mode is attempting to replicate Azure's identity model in AWS without understanding the fundamental architectural differences. Azure AD is an identity platform that serves as both the enterprise directory and the cloud IAM layer, while AWS separates these concerns between IAM Identity Center (formerly SSO), IAM policies, and optionally Cognito for application identity. Teams map Azure RBAC roles to AWS IAM policies one-to-one and end up with an over-permissioned, unmanageable policy structure. Networking migrations fail because Azure VNets and AWS VPCs have subtly different behaviors around default routing, DNS resolution, and security group statefulness. Storage migrations from Azure Blob to S3 seem straightforward but break when applications depend on Azure-specific features like blob lease locks, append blobs, or Azure CDN token authentication. Cost estimation errors are common because Azure's and AWS's pricing models differ in unexpected ways—Azure charges for outbound data per-region while AWS charges per-service, Azure includes certain features (like DDoS protection basic) that are separate charges on AWS, and Reserved Instance mechanics differ significantly.
Risk Matrix: Azure to AWS
Azure AD conditional access policies, Privileged Identity Management, and managed identities have no one-to-one AWS equivalents. Teams often create overly broad IAM policies to avoid blocking migration progress, then never tighten them. Service principal credentials that were managed identities in Azure become long-lived access keys in AWS without proper rotation.
Implement AWS IAM Identity Center with SAML federation to Azure AD during the transition period. Map every Azure AD role assignment to an AWS IAM policy using the principle of least privilege, validated with IAM Access Analyzer. Replace managed identities with IAM roles for service accounts and enforce IMDSv2 on all EC2 instances. Use AWS Organizations SCPs to enforce guardrails equivalent to Azure Policy.
Azure Blob Storage features like blob leases, append blobs, page blobs, and immutability policies have different S3 equivalents or no direct equivalent. Applications using Azure Storage SDK-specific features like shared access signatures (SAS tokens) with IP restrictions must be rewritten for S3 presigned URLs. Container-level access policies differ from S3 bucket policies.
Audit every Azure Storage SDK call in application code and map to equivalent S3 SDK operations before data migration begins. Use AWS DataSync for bulk data transfer with integrity validation. Implement a storage abstraction layer if applications must temporarily operate against both platforms. Test presigned URL generation and CORS configurations thoroughly in staging.
Azure VM sizes don't map directly to EC2 instance types—vCPU and memory ratios differ, Azure temporary disk storage has no EC2 equivalent, and Azure Availability Sets behave differently from EC2 placement groups. AKS clusters with Azure-specific integrations (Azure Key Vault CSI driver, Azure Files storage class, Azure CNI networking) require significant reconfiguration for EKS.
Benchmark each workload on candidate EC2 instance types using production-representative load tests before committing to instance families. Use AWS Application Migration Service (MGN) for VM migrations with pre-migration testing. For Kubernetes, deploy EKS clusters with equivalent configurations validated in staging, replacing Azure-specific integrations with AWS equivalents (Secrets Manager CSI driver, EFS CSI driver, VPC CNI).
Azure SQL Database to Amazon RDS or Aurora migration requires handling Azure-specific features like elastic pools, geo-replication with automatic failover groups, and Transparent Data Encryption with customer-managed keys. Cosmos DB to DynamoDB migration requires fundamental data model rethinking since partition key strategies and consistency models differ significantly.
Use AWS Database Migration Service with continuous replication for homogeneous migrations. For Cosmos DB to DynamoDB, prototype the data model with production-scale data and validate query patterns before committing. Implement dual-write patterns during transition with conflict resolution logic. Schedule cutover during lowest-traffic windows with pre-tested rollback procedures.
Azure and AWS charge differently for the same conceptual resources—AWS charges for Elastic IPs when not attached, NAT Gateway per-GB processing fees are higher than Azure NAT Gateway, AWS data transfer between availability zones is charged while Azure doesn't charge for same-region transfers. Running both environments simultaneously easily doubles or triples infrastructure costs.
Build a granular cost model before migration using AWS Cost Explorer forecasting and Azure Cost Management data. Set AWS Budgets with alerts at aggressive thresholds. Establish a decommission schedule for Azure resources with named owners accountable for shutdown dates. Use AWS Cost Anomaly Detection to catch unexpected charges immediately.
What Must Not Change During This Migration
Every Azure AD identity with production access must have an equivalent AWS IAM principal with equal or tighter permissions verified by IAM Access Analyzer before workload migration
Network connectivity between Azure VNets and AWS VPCs must be established and validated with latency measurements before any application migration begins
All data migrations must be verified through automated reconciliation comparing record counts, checksums, and sample query results between source and target databases
Application health checks, monitoring dashboards, and alerting rules must be operational in AWS CloudWatch before any production traffic is routed to AWS resources
Each migration phase must have a documented and tested rollback procedure with a maximum execution time shorter than the agreed recovery time objective
Migration Process: Azure to AWS
Service inventory and dependency mapping
Export complete Azure resource inventory using Azure Resource Graph and tag each resource with its AWS equivalent service, migration approach (rehost, re-platform, refactor), and dependency chain. Document all Azure AD app registrations, enterprise applications, and their permission grants. Map Azure Policy assignments to equivalent AWS Organizations SCPs and IAM policies. Catalog all Azure DevOps projects, pipelines, and artifact feeds. Identify Azure-specific PaaS services that require re-architecture for AWS.
Identity and networking foundation
Deploy AWS Organizations with an account structure mirroring Azure subscription topology. Configure AWS IAM Identity Center with SAML federation to Azure AD for coexistence. Establish AWS VPCs in target regions with subnet designs matching workload isolation requirements. Deploy AWS Site-to-Site VPN or Direct Connect alongside existing ExpressRoute for hybrid connectivity. Implement security group and NACL rules equivalent to Azure NSGs. Set up AWS CloudTrail, Config, and GuardDuty for security monitoring parity with Azure Security Center.
Service mapping and platform translation
Map Azure services to AWS equivalents with configuration translation: Azure VMs to EC2 with instance type mapping validated by benchmarks, AKS to EKS with node group and add-on equivalence, Azure SQL to RDS or Aurora with feature parity validation, Cosmos DB to DynamoDB with partition strategy redesign, Azure Blob to S3 with lifecycle and access policy translation, Azure Functions to Lambda with runtime and trigger mapping, Azure Service Bus to SQS/SNS with message pattern validation. Build reusable Terraform or CloudFormation modules for each service translation.
Parallel deployment and data migration
Deploy AWS infrastructure using infrastructure-as-code alongside running Azure resources. Begin database migration using AWS DMS with continuous replication and validation. Migrate object storage using AWS DataSync with periodic integrity checks. Deploy application workloads to EKS or EC2 with configuration management (SSM Parameter Store replacing Azure App Configuration). Run comprehensive integration and load tests against AWS-hosted applications. Configure Route 53 health checks and failover routing for DNS-based traffic management.
Traffic migration and cutover
Implement weighted DNS routing using Route 53 to incrementally shift traffic from Azure to AWS. Start with 5% canary traffic to AWS with real-time monitoring of error rates, latency percentiles, and business metrics. Increase to 25% and 50% with mandatory 48-hour soak periods at each stage, with automated rollback triggers. For stateful services, perform final database sync and cutover during maintenance windows. Update all external API consumers and partner integrations to target AWS endpoints. Verify all webhook endpoints and callback URLs are updated.
Verification, optimization, and decommission
Execute full regression test suites against AWS-hosted applications and compare results with Azure baseline runs. Validate all monitoring, logging, and alerting in CloudWatch against operational runbooks. Verify compliance controls in AWS Config rules and Security Hub match Azure Policy and Security Center posture. Optimize costs by rightsizing EC2 instances using Compute Optimizer recommendations, purchasing Savings Plans for stable workloads, and enabling S3 Intelligent Tiering. Decommission Azure resources systematically, starting with compute and ending with identity federation. Terminate ExpressRoute and Azure AD federation only after confirming all workloads are fully operational on AWS.
How This Migration Changes at Scale
Organization operates more than 1,000 Azure VMs across multiple subscriptions and regions
Requires AWS Application Migration Service (MGN) with automated wave planning. Manual migration is infeasible at this scale. Organize VMs into migration waves by application stack, migrating complete application tiers together. Expect 6-12 months for compute migration with a dedicated cloud platform team of 8-12 engineers. Consider CloudEndure for continuous replication of critical workloads.
Azure AD serves as identity provider for more than 100 enterprise applications
Identity migration becomes a multi-month project requiring dedicated IAM engineering. Each application's authentication flow must be individually analyzed and migrated to AWS IAM Identity Center or Cognito. Plan for a 3-6 month coexistence period with SAML federation between Azure AD and AWS. Budget for application teams' effort to update authentication libraries and configurations.
Multiple Azure SQL elastic pools or Cosmos DB accounts with cross-region replication
Database migration becomes the longest critical path item, potentially 4-6 months including validation. Each database requires individual migration strategy assessment. Cross-region replication must be rebuilt using Aurora Global Database or DynamoDB Global Tables. Elastic pool consolidation must be decomposed into individual RDS instances or Aurora clusters with appropriate sizing.
Related Migration Paths
Organizations considering leaving Azure should evaluate both AWS and GCP as targets. The identity and networking migration patterns are similar but the target service mappings differ significantly, particularly for data analytics and Kubernetes workloads.
If the Azure environment includes Oracle Database on Azure VMs, migrating to AWS provides an opportunity to modernize onto Aurora PostgreSQL, combining the infrastructure migration with database platform modernization.
Teams running some workloads on Heroku alongside Azure can consolidate onto AWS, applying PaaS-to-IaaS migration patterns for Heroku workloads while simultaneously migrating Azure infrastructure.
If you're evaluating a migration from Azure to AWS, the first step is validating risk, scope, and invariants before any build work begins.