A senior engineer's guide to migrating off Azure onto AWS: the service-by-service equivalents (AKS→EKS, Azure SQL→RDS/Aurora, Blob→S3, Functions→Lambda, App Service→App Runner/ECS, Cosmos DB→DynamoDB, Synapse→Redshift, Entra ID→IAM Identity Center), the networking and identity differences that actually break things, what egress will cost you on the way out, a phased cutover plan, and how to convert ARM/Bicep to Terraform or CDK. The migration itself is usually MAP-funded — a vetted partner runs it at low-to-no cost.
People search "azure to aws" for one of three reasons: a parent-company or acquirer standardized on AWS, the team wants AWS's breadth in a specific area (Bedrock, the maturity of EKS, the data-and-analytics stack), or an EA renewal made the all-in Azure commit look worse than a clean AWS landing zone. Whatever the trigger, the engineering work is the same.
Start by classifying every workload against the 7 Rs (Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor). An Azure estate splits cleanly: stateless web/app tiers and containers are rehost/replatform (lift to EC2/ECS/EKS), managed databases are replatform (Azure SQL → RDS or Aurora), and the cloud-native services (Functions, Cosmos DB, Service Bus, Synapse) are where you choose between a faithful 1:1 mapping and a selective refactor. Most teams rehost/replatform first to get off Azure, then refactor the few services that benefit.
The most important early decision is the landing zone — a multi-account AWS Organizations structure (management, security/log-archive, shared-services, per-environment workload accounts), a network baseline, guardrails (SCPs), and centralized logging. This is what the MAP "Mobilize" phase funds, and it is the thing teams most often skip and most regret — a clean landing zone is the difference between a migration and a mess you re-migrate in 18 months.
The second decision is the data path. Azure charges for egress; AWS does not charge for ingress, so the cost and timeline of the whole project are dominated by how you move the data — public internet, a dedicated circuit (ExpressRoute peered to Direct Connect), or physically via Snowball (section VI). Everything else — service mapping, IaC rewrite, identity federation — is detail work a partner has done dozens of times. The rest of this page is that detail, honestly.
This is the core of the migration. Below is the mapping for the nine service categories that cover the overwhelming majority of an Azure estate, with the honest "how hard is it" verdict for each. The condensed table is in the comparison section; here is the reasoning.
A note on the verdicts: "mechanical" means tooling does most of the work and the risk is operational, not architectural; "re-engineering" means the data or programming model differs enough that a lift-and-shift fails or carries the wrong cost profile. Treat the re-engineering items as the critical path.
Kubernetes is Kubernetes. Your Deployments, Services, ConfigMaps, and Helm charts move almost verbatim. The work is at the edges: ingress (Azure Application Gateway / AGIC → AWS Load Balancer Controller provisioning ALBs/NLBs), storage (Azure Disk/Files CSI → EBS/EFS CSI drivers), identity (AKS workload identity → IRSA or EKS Pod Identity), secrets (Key Vault CSI → Secrets Manager / SSM via the secrets-store CSI driver), and registry (ACR → ECR — repoint and re-push, or use pull-through cache).
Verdict: a few days to a couple of weeks per cluster, dominated by re-testing ingress, autoscaling (Cluster Autoscaler/Karpenter), and the IRSA wiring. The manifests themselves rarely change.
Azure SQL is SQL Server under the hood, so the lowest-risk path is RDS for SQL Server — same engine, minimal app change, you keep T-SQL and your schema. Use AWS DMS for the data with near-zero-downtime CDC (change data capture) replication, validated with DMS data-validation. To drop SQL Server licensing, the bigger play is converting to Aurora PostgreSQL with the AWS Schema Conversion Tool (SCT) plus DMS — but heterogeneous conversion means stored procedures, T-SQL functions, and identity columns need rework. SCT auto-converts the bulk and produces an action report for the rest.
Verdict: RDS for SQL Server is mechanical. The Aurora conversion is the single highest-effort line item in many Azure migrations, because the app's SQL-dialect coupling runs deeper than anyone admits. Budget real time for it, or rehost to RDS for SQL Server now and refactor to Aurora later.
Object store to object store. Concepts map directly: containers → buckets, blobs → objects, access tiers (Hot/Cool/Archive) → S3 storage classes (Standard/Standard-IA/Glacier). Move the data with AWS DataSync (it speaks Azure Blob as a source), `azcopy` out / S3 CLI in, or Snowball for very large sets. Application changes are SDK swaps — Azure Storage SDK calls become S3 SDK calls — plus re-doing SAS-token access as S3 pre-signed URLs and bucket policies.
Verdict: mechanical for the data, light code change for the access layer. Watch lifecycle policies; S3 is strongly read-after-write consistent in 2026, so old eventual-consistency assumptions are rarely an issue.
The serverless models are close but not identical. The function body usually ports with modest changes; the work is in the triggers and bindings. Azure's declarative input/output bindings have no Lambda equivalent — you replace them with explicit SDK calls in the handler. HTTP triggers → API Gateway (or a Lambda Function URL); Blob triggers → S3 event notifications; Queue/Service Bus triggers → SQS/SNS/EventBridge sources; Timer triggers → EventBridge Scheduler. Durable Functions map to AWS Step Functions — a genuine rewrite of the orchestration logic.
Verdict: simple HTTP/queue functions are a quick replatform; binding-heavy or Durable Functions are re-engineering. Cold-start and concurrency behavior differ, so re-test latency-sensitive paths.
Azure App Service is a managed app-hosting PaaS. For a single containerized web app or API, AWS App Runner is the closest like-for-like — push an image or point at a repo, get a managed, autoscaling, HTTPS endpoint. For anything with multiple services, sidecars, or finer networking control, ECS on Fargate is the right target (you manage task definitions and an ALB, with full control). Deployment slots map to blue-green/CodeDeploy canary deployments; App Service built-in auth maps to Cognito or ALB OIDC.
Verdict: containerize first if you aren't already, then App Runner for simple, ECS Fargate for real. Mechanical once containerized; the containerization step is the variable.
This is the one people underestimate. If you used Cosmos DB's Mongo API, the cleaner target is often Amazon DocumentDB (faithful) rather than DynamoDB. If you used the core SQL/NoSQL API, DynamoDB is the target — but its single-table design, partition-key/sort-key modeling, and GSIs are a different mental model from Cosmos's containers and index-everything default. You don't migrate the data so much as remodel it, then load it (DMS supports DynamoDB as a target, or a custom loader). Multi-region writes and tunable consistency map to DynamoDB Global Tables and its consistency options, but the access patterns must be designed up front.
Verdict: re-engineering. Get the DynamoDB data model right before writing any migration code, or you pay for it in throttling and hot partitions forever. For Mongo-API Cosmos, strongly consider DocumentDB to avoid a remodel.
Service Bus queues map to Amazon SQS (use FIFO queues where you relied on sessions/ordering). Topics + subscriptions map to SNS fan-out, or EventBridge for content-based routing and richer event buses. Dead-letter queues exist on both sides. Semantics differ in the details — message size limits (256 KB on SQS, with the S3 extended-client pattern for large payloads), visibility-timeout vs lock-duration, and at-least-once delivery.
Verdict: replatform. The wiring is straightforward; re-validate ordering and exactly-once expectations, because naive Service Bus code sometimes assumes guarantees that need FIFO/idempotency work on SQS.
Synapse dedicated SQL pools map to Amazon Redshift; Synapse Spark maps to EMR or Glue; serverless SQL over the lake maps to Athena. The warehouse conversion uses SCT to translate DDL and Synapse-specific T-SQL to Redshift's PostgreSQL-derived dialect, then DMS or a bulk unload-to-S3-and-COPY for the data. Distribution keys, sort keys, and Redshift's columnar/zone-map model need deliberate design — a 1:1 schema port performs badly.
Verdict: re-engineering for the warehouse design; mechanical for bulk data movement once the target schema is right. ETL/orchestration (Synapse pipelines / ADF → Glue / Step Functions / MWAA) is a parallel workstream.
Identity is the migration's connective tissue and the part most likely to block go-live if left late. AWS IAM Identity Center (formerly AWS SSO) is the front door for human access; you keep Entra ID as the identity provider and federate it via SAML 2.0, with SCIM provisioning to sync users and groups. Map Entra groups to permission sets that resolve to IAM roles per account. For workloads, Azure managed identities → IAM roles (IRSA on EKS, instance roles on EC2, task roles on ECS); for customer-facing auth, Entra External ID / B2C → Amazon Cognito.
Verdict: re-engineering, but well-trodden. Stand up Identity Center and the SAML+SCIM federation in the Mobilize phase, before workloads move. RBAC role mapping is the fiddly part — inventory your Entra app registrations and group-based access early.
The service mapping is the easy mental model. The differences that cause go-live incidents are in the networking and identity primitives, where Azure and AWS made different design choices that don't translate one-to-one.
On networking, the biggest shift is the security model. Azure leans on Network Security Groups (NSGs) on subnets or NICs, with a relatively flat VNet model and system routes that "just work" for most east-west traffic. AWS splits the job: security groups (stateful, ENI-level, the workhorse), network ACLs (stateless, subnet-level, easy to misconfigure), and route tables you manage explicitly per subnet. Teams from Azure routinely trip on three things: NACLs being stateless (you must allow ephemeral return ports), under-using security-group references (allowing "from this SG" rather than CIDR ranges, which Azure has no clean equivalent of), and forgetting that every subnet needs an explicit route to an internet or NAT gateway.
The second gotcha is NAT and egress. In Azure, outbound internet from a VM often works by default; in AWS, a private subnet has no internet path until you add a NAT gateway — which costs money (hourly + per-GB processing) and becomes a single point of cost if every workload routes through it. Plan NAT placement and VPC endpoints (so traffic to S3/DynamoDB/ECR stays on the AWS network and skips NAT charges) as part of the landing zone. Hybrid connectivity also differs: ExpressRoute → Direct Connect, VPN Gateway → Site-to-Site VPN, VNet peering → VPC peering or Transit Gateway (the right answer for any non-trivial multi-VPC topology); Azure Private DNS → Route 53 private hosted zones, with Resolver endpoints for hybrid resolution during the parallel-run window.
On identity, beyond the Entra→Identity Center federation above, the trap is the workload-identity model. Azure managed identities are attached to a resource and "just there." AWS uses scoped IAM roles assumed via STS, and the least-privilege expectation is much stronger. A lift-and-shift that recreates Azure's broad permissions as one wide IAM role will pass a pre-audit and fail a real one. Map each workload's actual permission needs — tedious, and exactly where a partner earns their fee, because they know the common Entra-to-IAM over-grants.
(1) NACL return traffic — stateless NACLs blocking ephemeral ports, so connections open but responses never arrive. (2) Missing NAT/route — private workloads with no outbound path, failing on package pulls and API calls. (3) Security-group default-deny surprise — AWS SGs deny all inbound by default, so a service that worked in Azure's more permissive model goes dark until the rule is added. All three are trivial once you know them and painful at 2am if you don't.
Your Azure infrastructure is (hopefully) defined in ARM templates or Bicep. The instinct is to "convert" it. The better instinct is to re-author it against AWS primitives, because a literal translation carries Azure's resource model into a cloud that models things differently.
There is no clean automated ARM/Bicep → Terraform converter that produces idiomatic AWS code, and you shouldn't want one. ARM/Bicep describes Azure resource types (Microsoft.Web/sites, Microsoft.Sql/servers) with no one-to-one AWS analog — an App Service isn't an ECS service plus an ALB plus a target group, it's a different abstraction, and a converter would emit a literal, awkward shape. Instead, use your Bicep as the specification of intent (what exists, how it's wired, the sizing) and re-express it in Terraform (cloud-agnostic, the common migration choice because the team often already knows HCL) or AWS CDK (if the team prefers TypeScript/Python and wants AWS-native constructs).
A pragmatic pattern: the partner stands up the landing zone as modular Terraform (network, EKS, RDS, IAM/Identity-Center modules) with S3-backend state and DynamoDB locking from day one, then builds each workload's resources as it migrates. CDK's higher-level constructs (an ECS Fargate service in one construct) get you to a working stack faster, at the cost of some magic.
Either way the deliverable is the same: a peer-reviewable, version-controlled definition of the AWS estate that a CI/CD pipeline applies — not console click-ops. The migration is the right moment to get this discipline in place, since you're building the AWS side from scratch anyway. Azure DevOps Pipelines map to CodePipeline/CodeBuild or GitHub Actions with AWS OIDC — a parallel workstream, not a blocker.
A good Azure→AWS cutover is boring. You move in waves, run both clouds in parallel for the data-heavy services, and keep a tested rollback for every wave. The "big-bang weekend" cutover works until it doesn't — and then you're debugging networking, identity, and data sync at once under a downtime clock. Here is the shape of a typical 10–22 week migration.
Waves isolate failure: each is small enough to validate and roll back independently, and the order is deliberate — landing zone first, stateless tiers next, data last.
Discovery and TCO. Inventory every Azure resource (Azure Resource Graph export + Application Discovery Service / Migration Hub on the AWS side), map dependencies, classify each workload against the 7 Rs, and produce a target architecture and a costed business case. This is the MAP "Assess" deliverable and AWS typically funds it — you finish with a plan and a number, not an invoice.
Build the landing zone: AWS Organizations, accounts, network baseline (VPCs, Transit Gateway, Direct Connect or VPN back to Azure for the parallel-run window), guardrails, centralized logging, and IAM Identity Center federated to Entra ID. Run a pilot — migrate one low-risk, representative workload end-to-end to prove the toolchain (MGN/DMS/DataSync), the pipelines, and the runbook. This phase is also MAP-funded.
Move web/app/container tiers first because they're stateless and reversible. Rehost VMs with AWS Application Migration Service (MGN) — agent-based continuous block-level replication, so you replicate live and cut over with minutes of downtime. Containers go to EKS/ECS. Run AWS in parallel behind a weighted DNS record (Route 53) so you can shift traffic 5% → 25% → 100% and roll back instantly by reverting the weight.
Databases cut over last and most carefully. Stand up the AWS target (RDS/Aurora/DynamoDB/Redshift), seed a full load, then run DMS CDC to keep it continuously in sync with the live Azure source, validated with DMS data-validation. The cutover is a short maintenance window: stop writes to Azure, let CDC drain the last changes, flip the connection string, verify, open writes on AWS. Keep the Azure database read-only as a rollback target for a defined window.
Run the full test suite against AWS, watch CloudWatch and cost for a billing cycle, right-size based on real usage, then decommission Azure once you're confident — which also stops the Azure bill. This is where MAP "Modernize" credits often fund the optimization work (e.g. moving rehosted VMs to containers or serverless). Don't skip the decommission step: a half-shut-down Azure estate is pure cost.
Every wave has a tested rollback: stateless tiers roll back by reverting the Route 53 weight; databases roll back by keeping the Azure source read-only and re-pointing the connection string. A migration without a rollback plan is a bet, not a plan. The partner writes and rehearses the runbook before the window, not during it.
Azure charges you to leave. AWS doesn't charge you to arrive. That asymmetry — egress out of Azure is billed, ingress into AWS is free — dominates the cost and the schedule of any data-heavy migration, so price it before you commit to a path.
Azure outbound data-transfer pricing is roughly $0.087/GB after the first 100 GB/month for North America and Europe (higher from some regions, tiering down at very large volumes) — about $87 per TB. So 10 TB out is ~$870, 50 TB ~$4,300, 100 TB ~$8,700; AWS ingress for that same data is $0. These are representative 2026 list figures — your contract, region, and any Microsoft "data-out for migration" waiver may change them — but the order of magnitude is what drives the decision.
For large estates, three things change the math. AWS Snowball: for tens of terabytes and up, shipping a physical device can be cheaper and faster than the wire, and it sidesteps your circuit's throughput ceiling. A dedicated circuit: peering ExpressRoute to Direct Connect gives predictable throughput and lower per-GB transit than the public internet, which matters during the parallel-run window when DMS is continuously replicating. And selective migration: don't pay egress on data you're about to archive — retire cold data to Azure Archive or simply don't migrate it.
The practical rule: estimate total data volume early, multiply by ~$0.087/GB for a worst-case all-over-the-wire figure, and use it to choose between internet, Direct Connect, and Snowball. For most mid-size estates the egress bill is a four-figure line item, not a project-killer — but it surprises teams who didn't budget it, and it interacts with the timeline (a 50 TB push over a saturated link can take days).
These are the items that don't show up in the service-mapping table but reliably cost teams a day each. A partner who has done Azure→AWS before front-loads all of them; a first-time team discovers them one incident at a time.
You can run an Azure→AWS migration in-house. Most teams shouldn't, for the same reason most people don't do their own dental surgery: the failure modes are expensive and the people who do it daily are faster and safer. The better question is who runs it and who pays.
The mechanism that makes this nearly free is the AWS Migration Acceleration Program (MAP). MAP runs in three phases — Assess (TCO and readiness, often fully funded), Mobilize (landing zone + pilot, funded), and Migrate & Modernize (production cutover, where AWS credits a meaningful share of the cost). The partner is paid through MAP and AWS engagement funding, and credits scale with migration size. Honest framing: MAP funding applies to qualifying migrations — typically tied to a committed level of post-migration AWS spend, not a blank check. But for a real Azure estate moving to AWS, the assessment is commonly free and a large share of the migration cost is covered.
This is where CloudRoute fits. We don't run migrations — we route you to a vetted, MAP-eligible AWS partner who does, matched to your stack (containers, .NET/SQL Server, data-warehouse), region, and timeline. You get a partner who has done the Entra→IAM translation and the Cosmos→DynamoDB remodel before, the migration is largely MAP-funded, and CloudRoute is paid by the partner — so the routing costs you nothing. The same MAP/credits machinery underpins our AWS credits work and the POC-funding path, and the partner's landing zone is exactly the kind covered in AWS landing zone. For the full done-for-you picture — assessment, landing zone, cutover, and the funding mechanics — the migration persona page walks through how an engagement runs end to end.
The condensed mapping for the nine categories that cover most of an Azure estate. "Effort" is the honest verdict — mechanical, replatform, or re-engineer.
| Azure service | AWS equivalent | Primary tool | Effort |
|---|---|---|---|
| AKS | Amazon EKS | kubectl / Helm + ALB Controller, EBS/EFS CSI, IRSA | Mechanical |
| Azure SQL Database | RDS for SQL Server (like-for-like) or Aurora PostgreSQL | DMS (+ SCT for Aurora) | Replatform → re-engineer |
| Blob Storage | Amazon S3 | DataSync / azcopy + S3 CLI / Snowball | Mechanical |
| Azure Functions | AWS Lambda | Code port + trigger/binding rewrite; Step Functions for Durable | Replatform |
| App Service | App Runner (simple) or ECS Fargate (complex) | Containerize + push to ECR | Replatform |
| Cosmos DB | DynamoDB (SQL API) or DocumentDB (Mongo API) | DMS / custom loader after data remodel | Re-engineer |
| Service Bus | SQS (queues) + SNS/EventBridge (topics) | Re-wire producers/consumers | Replatform |
| Synapse Analytics | Amazon Redshift (+ EMR/Glue, Athena) | SCT + DMS / unload-to-S3 + COPY | Re-engineer |
| Entra ID (Azure AD) | IAM Identity Center (humans) + IAM roles (workloads); Cognito (customers) | SAML 2.0 federation + SCIM | Re-engineer |
Situation: Acquirer standardized on AWS; the team had 12 months left on an Azure EA they wanted out of. Stack: AKS (28 services), three Azure SQL databases, a Cosmos DB store behind the activity feed, Blob document storage (~22 TB), and Azure Functions for webhooks. No one in-house had run an AWS migration, the cloud lead was at capacity on product work, and they were worried about Cosmos→DynamoDB and the SQL Server licensing.
What CloudRoute did: Routed within 24 hours to a MAP-eligible partner with .NET + data-migration track record. MAP Assess (AWS-funded) produced the target architecture and TCO in 2 weeks. Mobilize built a multi-account landing zone with Entra ID federated to IAM Identity Center and a Direct Connect circuit for the parallel run. AKS→EKS rehosted in waves behind Route 53 weighting; Azure SQL→RDS for SQL Server via DMS CDC (Aurora refactor deferred); Cosmos→DynamoDB remodeled around the feed's access patterns; 22 TB Blob→S3 over Direct Connect plus a Snowball for the cold archive; Functions→Lambda with EventBridge.
Outcome: Full cutover in 16 weeks, zero unplanned downtime (database windows under 10 minutes each). MAP funded Assess + Mobilize and credited ~45% of the migrate-and-modernize cost against a post-migration AWS commitment; egress came in around $1,900. Azure decommissioned in week 18, ending the EA spend. CloudRoute was paid by the partner — the customer paid $0 for the routing.
timeline: 16 weeks · downtime: <10 min/db · MAP-funded: ~45% of migrate cost · egress: ~$1,900 · routing cost to customer: $0
CloudRoute routes you to a MAP-eligible AWS partner matched to your stack and region. Assessment is often free; the migration is largely MAP-funded on qualifying workloads. Customer pays $0 for the routing — no procurement, no discovery theater.