Why migrate to AWS — the real drivers, the honest counter-case, and the funding that makes it cheap.

IThe real question isn't "is AWS good" — it's "does the move pay for itself"

Almost every workload can run on AWS. That was never in doubt. The decision that actually matters is whether migrating a specific workload returns more than it costs — in money, in engineering time, and in risk — over a horizon you can defend to a CFO.

Most "why migrate to AWS" content is a feature list dressed as an argument. It tells you AWS has more services than anyone else and leaves the implication hanging that more is better. That is not how a serious infrastructure decision gets made. The right frame is a business case: what does staying cost over the next three years, what does moving cost (net of funding), and what does the company gain that it cannot get where it is today.

This page is built around that frame. The next eight sections are the drivers that actually move the decision — each with the substance and the numbers a skeptical reader needs, not adjectives. Then comes the section most vendor pages refuse to write: the cases where the honest answer is "don't migrate this." After that, the funding angle that quietly changes the math, and a concrete playbook for building the internal case.

A note on who this is for. If you are a founder weighing a Heroku or DigitalOcean bill that has stopped scaling economically, a platform lead whose Azure or GCP commitment is expiring, an engineering director staring at an on-prem hardware refresh or a colo lease renewal, or a CTO with a board mandate to consolidate on one cloud — this is the page that turns "we should probably look at AWS" into a decision with a number attached. The mechanics of how the move is executed — the 7 Rs, the tooling, the cutover — live in the sibling pages linked throughout.

IICost and TCO at scale — where the money actually is

The headline reason most teams cite is cost, and it is real — but the savings are not where beginners expect. They are not in the per-hour compute price; they are in total cost of ownership: the people, the over-provisioning, the hardware refresh, and the pricing models you can only access at scale.

Start with the part that does not show up on an invoice: undifferentiated operational labor. Running your own database failover, patching OS images, swapping failed disks, capacity-planning for a launch, and carrying a pager for the datacenter are all work that produces no product value. On AWS, managed services absorb most of it — RDS handles failover and patching, S3 has no capacity to plan, Fargate removes the host fleet entirely. For a typical mid-size team, this is the single largest TCO line, and it is the one on-prem and bare-PaaS comparisons routinely ignore.

Then the over-provisioning tax. A datacenter or a fixed reserved fleet is sized for peak plus a safety margin, and that margin runs 24/7 whether traffic does or not. Elastic scaling (the focus of driver 6) lets capacity track demand, so you stop paying for headroom you use a few hours a week. Teams that rightsize and add auto-scaling during a migration commonly cut steady-state compute spend by 30–50% versus a like-for-like static fleet.

The pricing models are the lever most people underuse. On-demand is the most expensive way to buy AWS. Savings Plans and Reserved Instances cut compute by up to ~72% for committed usage; Spot cuts it up to ~90% for fault-tolerant and batch workloads; S3 Intelligent-Tiering and Glacier move cold data to a fraction of hot-storage cost automatically. A workload that looks expensive on the public on-demand sticker is often dramatically cheaper once a partner applies the right commitment mix.

The honest caveat, stated plainly: a naive lift-and-shift with no rightsizing can cost more than the source environment, because you have moved the same oversized boxes onto metered infrastructure and added data-transfer charges. The TCO win comes from the replatform and the rightsizing, not the relocation by itself. This is exactly why the execution-side pages on cost ([[/migrate/aws-migration-cost]]) and on-prem economics ([[/migrate/on-premise-vs-cloud-cost]]) matter — the savings are engineered, not automatic.

IIIService breadth — building instead of operating plumbing

AWS offers roughly 240 services spanning compute, storage, databases, analytics, machine learning, networking, security, and developer tooling. Breadth is not about bragging rights; it is about how much undifferentiated infrastructure your team gets to stop building and maintaining.

The practical value of breadth is that the building block you need usually already exists, managed and integrated, instead of being a service you have to stand up and operate yourself. Need a queue? SQS, not a self-hosted RabbitMQ cluster. Event bus? EventBridge. Managed Kafka? MSK. A graph, time-series, or wide-column database? Neptune, Timestream, Keyspaces. A data warehouse? Redshift. A search cluster? OpenSearch Service. Each of those is a system a smaller team would otherwise run, patch, scale, and back up by hand.

Breadth also compounds through integration. Services share IAM for permissions, CloudWatch for metrics and logs, CloudTrail for audit, KMS for encryption, and VPC for networking. That shared substrate is why wiring Lambda to DynamoDB to S3 to Bedrock is configuration rather than a systems-integration project. On a PaaS with a narrow primitive set, you bolt on third-party SaaS for each gap and stitch the seams yourself; the breadth is what removes the seams.

The honest counter to "more services is better" is that breadth is also surface area — more services means more to learn, more ways to misconfigure, and more cost lines to watch. Breadth pays off when you actually consume it. A static marketing site does not benefit from 240 services; a product with queues, analytics, ML inference, and global delivery does. The value of breadth scales with how composite your system is. The partner CloudRoute routes you to maps your specific workload to the minimum set of services that does the job, so breadth is leverage, not sprawl.

IVGlobal reach and reliability — the SLAs you can actually point to

Two drivers sit close together because they share an architecture: AWS's global footprint and the redundancy that footprint enables. Reach lets you put workloads near users and inside data-residency borders; reliability is the redundancy that turns that footprint into uptime you can put in a contract.

The footprint, in numbers: 36 launched Regions and 114 Availability Zones worldwide, plus 600+ CloudFront edge locations for content delivery. Each Region is a cluster of physically separate Availability Zones — independent data centers with their own power, cooling, and networking, close enough for synchronous replication but far enough to fail independently. That is the structural basis for high availability: you spread across AZs so the loss of one building is a non-event.

Reach matters for two concrete reasons beyond latency. First, data residency: regulations like GDPR, and sovereignty rules across the EU, UK, UAE, Saudi Arabia, India, and others, often require data to stay in-country or in-region — and AWS gives you a Region to satisfy that without standing up your own data center. Second, user-perceived performance: placing compute and CloudFront edges near your users cuts round-trip latency in a way a single-region PaaS deployment structurally cannot.

Reliability is where AWS converts that footprint into commitments you can show a board. S3 is designed for 99.999999999% (eleven nines) of object durability — statistically, you would not expect to lose a single object across tens of millions over millions of years. The S3 Standard availability SLA is 99.9%; EC2 and many core services carry a 99.99% Region-level availability SLA when deployed across multiple AZs. These are contractual, with service-credit remedies — not marketing numbers. The catch is that you only inherit them if you architect for them: a single-AZ deployment forfeits the multi-AZ SLA. That architecture is part of what a migration partner sets up via a landing zone ([[/devops/aws-landing-zone]]).

VSecurity and compliance — what you inherit vs. what you still own

For many regulated companies this is the driver that decides it. AWS holds 140+ compliance certifications and operates the physical and platform security to a standard almost no individual company can match — but it works under a shared-responsibility model, so it is worth being precise about what transfers and what does not.

AWS maintains attestations and certifications across the frameworks buyers actually get audited against: SOC 1 / SOC 2 / SOC 3, ISO 27001 / 27017 / 27018, PCI DSS Level 1, HIPAA eligibility, FedRAMP (Moderate and High), GDPR alignment, and region-specific regimes. When AWS is certified for a control, you inherit the underlying control for the layers AWS operates — the data centers, the hypervisor, the physical network, the hardware lifecycle. For a startup chasing SOC 2, inheriting the entire physical-security and infrastructure-control set is a large fraction of the audit handed to you on day one.

The shared-responsibility line is the part teams get wrong. AWS is responsible for security of the cloud — the global infrastructure and the managed-service internals. You remain responsible for security in the cloud — your IAM policies, your data classification and encryption choices, your network rules, your patching of anything you run on EC2, and your application code. Migrating does not outsource your security posture; it gives you a far stronger floor and a toolkit (IAM, KMS, GuardDuty, Security Hub, Config, CloudTrail, WAF) to build the rest on.

The migration is also a natural moment to fix posture, because you are rebuilding the environment anyway. Greenfield IAM with least-privilege, encryption-by-default via KMS, centralized audit via CloudTrail, and guardrails via Control Tower are dramatically easier to establish during a migration than to retrofit onto a sprawled legacy estate. Several CloudRoute-routed migrations have doubled as the engagement that closed a SOC 2 pre-audit gap — the move and the compliance work funded together, which is part of why the funding angle below matters so much.

VIScaling on demand — capacity that tracks the business, not a forecast

Elasticity is the driver everyone names and few quantify. The point is not "AWS can scale" — it is that capacity becomes a variable that follows demand in minutes, which changes both your cost curve and your ability to survive a spike without a fire drill.

On fixed infrastructure, capacity is a bet placed weeks or months ahead. You forecast peak, buy for peak plus margin, and carry that margin permanently. Get the forecast wrong high and you have burned money on idle iron; get it wrong low and you fall over during the exact event — a launch, a press hit, Black Friday — when uptime matters most. AWS removes the bet: Auto Scaling groups add and remove EC2 instances against real load, ECS and EKS scale tasks and pods, Aurora Serverless v2 scales database capacity in fine-grained increments, and Lambda scales to thousands of concurrent executions with zero pre-provisioning.

The economic consequence is that you pay for the area under your actual demand curve instead of the area under a flat line drawn at peak. For any workload with real variability — diurnal traffic, weekly cycles, seasonal spikes, bursty batch jobs — that is a structural cost reduction on top of the rate discounts from driver 1. For genuinely spiky workloads, serverless and Spot can collapse steady-state cost because you are billed only for execution.

The honest counter: if your load is genuinely flat and predictable, elasticity buys you less, and a fixed reserved fleet or even a fixed-price host can be competitive. Elasticity is a lever proportional to variability. But "flat forever" is rarer than teams assume — most products that are growing or seasonal benefit, and the option value of being able to absorb a 10x spike without a procurement cycle is worth something even in the months you do not use it.

VIIThe data and GenAI ecosystem — why proximity to your data wins

In 2026 this is the driver pulling the most net-new migrations. The center of gravity is Amazon Bedrock for generative AI, surrounded by a data stack — Redshift, Athena, Glue, SageMaker — that sits next to where your data already lives. The advantage is gravity: AI and analytics are cheapest, fastest, and most secure when they run beside the data, not across an egress boundary.

Bedrock is the anchor: a single managed API onto frontier models — Anthropic's Claude, Meta's Llama, Mistral, Cohere, Stability, and Amazon's own Nova and Titan families — plus Knowledge Bases for retrieval-augmented generation, Agents for tool-using workflows, and Guardrails for safety and PII handling. You get model choice without running GPU fleets, and inference that stays inside your AWS account and VPC rather than shipping your proprietary data to a third-party endpoint. For a regulated company, "the data never leaves our boundary" is frequently the line that makes a GenAI feature shippable at all.

The data services around it are why the AI is useful. Redshift for the warehouse, Athena for serverless SQL straight over S3, Glue for ETL and the data catalog, OpenSearch for vector and keyword search, and SageMaker for custom model training and hosting — all reading the same S3 data lake your applications already write to. Build a RAG application and the documents, the vector store, the inference, and the application tier are co-located; there is no cross-cloud data shuttle, no second egress bill, and one IAM and encryption boundary to reason about.

This is also a forward-looking reason to consolidate. A team scattered across a PaaS for compute, one SaaS vendor for search, another for analytics, and a separate AI API is paying an integration and egress tax on every data-hungry feature it ships. Putting the data and the things that act on it in one place is what makes the next two years of AI and analytics features cheap to build instead of a standing systems-integration project. The Bedrock cluster ([[/bedrock]]) covers the model and cost mechanics; here it is simply one of the strongest reasons to move.

VIIIEnding hardware and single-vendor constraints

The last driver is subtraction, not addition — what you stop being limited by. Two specific constraints push teams to AWS: the hardware refresh cycle on-prem, and the ceiling of a single opinionated PaaS or a narrow legacy vendor relationship.

On-prem, hardware is a recurring capital and operational anchor. Servers reach end-of-life on a 3–5 year cycle and must be re-bought, re-racked, and re-migrated; capacity is a procurement lead time, not a console action; a datacenter or colo carries power, cooling, space, and physical-security cost whether you are at 20% or 95% utilization. Migrating converts that capital expenditure and refresh treadmill into metered operating expenditure that tracks usage, and hands the hardware lifecycle to AWS entirely. The colo lease renewal or the looming server refresh is one of the most common concrete triggers we see.

The PaaS ceiling is the other. A platform like Heroku is excellent for getting started and genuinely painful to outgrow — pricing that stops scaling economically past a point, limited control over networking and compliance, a fixed set of primitives, and a single vendor holding the whole stack. Legacy database licensing (Oracle and SQL Server in particular) is a related constraint: renewal costs that can exceed the cost of the migration itself, which is why moves like [[/migrate/oracle-to-aws]] and [[/migrate/heroku-vs-aws]] are so often economically driven rather than technically forced.

A fair clarification: "ending vendor lock-in" does not mean AWS has none — committing to a cloud is a commitment, and deep use of proprietary services raises switching cost. The honest framing is that you are trading a constraint that limits you today (a PaaS you have outgrown, a datacenter you cannot scale, a license you cannot afford to renew) for a platform whose ceiling is far higher and whose primitives are largely open standards (Linux, Postgres, Kubernetes, S3-compatible APIs). For most teams hitting a real ceiling, that trade is the point.

IXWhen NOT to migrate to AWS

A business case is only credible if it can say no. There are workloads where migrating to AWS is the wrong call — and naming them is how you earn the right to recommend it everywhere else. If your situation is on this list, the responsible answer is "not yet" or "not this one."

• The workload is being sunset within ~12 months — If an application is scheduled for retirement or replacement inside a year, migrating it rarely pays back the engineering time and cutover risk before it disappears. Retire or retain it where it is and spend the migration budget on what survives. (This is literally the "Retire/Retain" branch of the 7 Rs.)
• A stable monolith with flat, predictable load and no growth — A mature internal app with steady traffic, no scaling pressure, and no roadmap gains little from elasticity, breadth, or the GenAI stack. If it runs fine on cheap fixed infrastructure and nothing is pushing it, the migration cost may never be recovered. Elasticity is proportional to variability — flat load is where the cloud premium is hardest to justify.
• Hard data-residency or ultra-low-latency to a place AWS serves poorly — If regulation pins data to a jurisdiction AWS does not have a Region in, or you need sub-millisecond latency to a factory floor or trading venue better served by on-prem or edge hardware, AWS may not fit that specific workload. (A hybrid Outposts or Local Zones design sometimes resolves this — but verify before assuming.)
• A small, simple app where a $25/month managed host is genuinely cheaper — For a single small service with light traffic, the AWS-equivalent stack (compute + managed DB + load balancer + NAT + data transfer) can cost more than a $20–$40/month PaaS or VPS. Below a certain size, simplicity wins and the AWS premium is real. Migrate when you are hitting a ceiling, not preemptively.
• You can't resource the migration and there is no funding path — A migration done with no senior ownership, no rollback plan, and no slack on the team is how you get a bad cutover. If you cannot staff it and the workload does not qualify for MAP funding or a partner, the right move is to wait until you can — or route it to a partner who supplies the senior team (the case below).
• Lift-and-shift with no intention to rightsize — If the plan is to move oversized servers as-is and never replatform or rightsize, the bill can go up, not down. Either commit to the optimization that produces the savings, or do not expect the cost driver to materialize. A move without a replatform is a relocation, not an improvement.

XThe funding angle — MAP makes the move cheap

The business case improves sharply once you account for funding, which most internal models leave out. The AWS Migration Acceleration Program (MAP) is designed to remove cost as the reason a qualifying migration does not happen — AWS pays for the assessment and credits a large share of the migration and modernization work.

MAP runs in three phases. Assess produces a TCO model and a readiness/discovery view and is typically funded outright by AWS — you get the business case quantified at little to no cost. Mobilize builds the landing zone and runs a pilot. Migrate & Modernize executes the production cutover. Across Mobilize and Migrate, AWS provides credits scaled to migration size, and the partner doing the work is paid through MAP. The practical effect: a qualifying migration's direct cost to you can land at or near $0, with any non-funded remainder routinely recovered inside the first month or two from the lower post-migration cloud bill.

Stated honestly, MAP funding applies to qualifying migrations — generally those above a meaningful AWS-spend threshold with a post-migration commitment. Smaller migrations may not clear the bar. In that case the value is not the credits; it is the vetted-partner referral itself, which de-risks the cutover by putting a senior team with a documented track record and a tested rollback plan on the work. MAP also ties directly to the broader AWS credits picture ([[/aws-credits/100k-aws-credits]], [[/aws-credits/aws-poc-funding-explained]]), so a single engagement can stack migration funding with general Activate credits where a distinct workload justifies it.

For the business case, this is the line that changes the conclusion: the cost side of "does the move pay for itself" is, for qualifying migrations, substantially or entirely offset by AWS. You are comparing the ongoing cost of staying against a move that is largely funded — which is a very different calculation from the unfunded one most teams run by default. The migration-funding mechanics in detail live at [[/migrate/aws-migration-funding]] and the program itself at [[/migrate/aws-migration-acceleration-program]].

XIHow to build the internal business case

A migration gets approved when someone can hand a CFO a one-page case with a number on it. Here is the structure that works — five inputs and the comparison they produce — so "we should look at AWS" becomes a defensible decision.

The case is a comparison of two three-year cost paths plus the strategic gains that do not fit in a spreadsheet. Build it in this order, and let the partner-run Assess phase supply the hard numbers for the cost side.