Heroku vs AWS: when to stay, and when to move.

IThey are not the same product: a PaaS vs a cloud

Heroku is a platform built on top of AWS. AWS is the cloud itself. Comparing them is like comparing a furnished apartment to a hardware store.

Heroku is a platform as a service (PaaS). You give it code and a Procfile that names your process types. Heroku handles everything below the application: runtime, build, operating system patches, load balancing, TLS, logs, health checks and scaling. You reason about "dynos", not servers, VPCs or IAM policies.

AWS gives you the parts: EC2, ECS and Fargate, Lambda, RDS and Aurora, S3, VPC networking, IAM and roughly two hundred other services. You compose them into a system and you operate it. So the real question is not "which is better". It is whether Heroku's abstraction is still worth its premium for your workload, team and stage.

IIDeveloper experience: Heroku's early lead

On developer experience alone, Heroku wins. It made git-push deploys normal and is still one of the fastest ways to get an app to a public URL.

git push heroku main builds your app with a buildpack and releases it behind a managed router with TLS. Managed Postgres or Redis is one command. Scaling is heroku ps:scale web=3. Review apps give every pull request its own environment. A three-person team can run a real SaaS this way and never touch an operating system.

Matching that on raw AWS takes real setup: a VPC, an ECS service on Fargate, a load balancer, a certificate, an image registry, a CI/CD pipeline, IAM roles, secrets, logs and alarms, and an RDS instance. AWS has narrowed the gap with Amazon ECS Express Mode, which creates the Fargate service, load balancer, scaling and networking from one container image. Note that App Runner closed to new customers on April 30, 2026; AWS points new users to ECS Express Mode instead.

The price of Heroku's simplicity is control. You accept its limits: a 30-second router timeout, Postgres connection caps tied to your plan, daily dyno restarts, and autoscaling only on Performance dynos. Most apps never notice them early. They become visible as you grow.

IIICost: list prices, and how to find your own break-even

Per unit, AWS is cheaper. All-in, it depends on how much engineering time the move and the upkeep take. Here are published prices and a formula you can run with your own numbers.

List prices (checked October 10, 2026). Heroku charges $25 a month for a Standard-1X dyno (0.5 GB), $50 for Standard-2X (1 GB), $250 for Performance-M (2.5 GB) and $500 for Performance-L (14 GB). Data add-ons are billed on top. On AWS Fargate in us-east-1, a task with 1 vCPU and 2 GB running all month costs about $36. Savings Plans lower that further if you commit.

Engineering time is the other half. Heroku's price includes platform work: patching, certificates, load balancers, log routing, replacing failed dynos. On AWS your team or a partner does that work. If your bill is a few hundred dollars a month, the hours to build and run AWS will cost more than any saving. Staying is the rational choice.

The break-even formula. Monthly saving = (Heroku bill) minus (AWS bill after right-sizing) minus (extra monthly ops time at your hourly cost). Months to break even = one-time migration cost divided by monthly saving. If the saving is zero or negative, stay. If break-even is under about a year and the bill is growing, moving starts to make sense.

IVControl, scale and service breadth: AWS's later lead

Past a certain size, the argument moves from price to capability. AWS runs workloads Heroku cannot.

Scale and control. On AWS you pick instance sizes, spread across Availability Zones and Regions, autoscale on any metric (CPU, memory, queue depth, requests), and run long connections without a 30-second wall. You also get private networking, fine-grained IAM, your choice of OS, and GPUs. Compliance work for SOC 2, HIPAA or PCI is easier when you own IAM, encryption, logging and network isolation. Heroku has its own Shield tier for regulated apps, but the deepest control is on AWS.

Service breadth. Heroku gives you compute plus a curated set of data add-ons. AWS gives you managed databases of every kind (RDS, Aurora, DynamoDB), analytics (Redshift, Athena, Glue, Kinesis, OpenSearch), machine learning and generative AI (SageMaker, Amazon Bedrock), queues and events (SQS, SNS, EventBridge) and a CDN (CloudFront). When the roadmap needs a warehouse, streaming, GPU inference or Bedrock, Heroku has no answer.

VOps burden: who runs the platform

The visible cost is dynos vs Fargate tasks. The deciding cost is who runs the platform: Heroku, or you.

On Heroku, Heroku is your platform team. Your engineers do application work only. For most early teams that is worth a lot: no platform hire, and no product engineers pulled into infrastructure incidents.

On AWS, someone has to own the landing zone (accounts, networking, IAM), the CI/CD pipeline, image patching, autoscaling and alarms, database upgrades and backups, incidents and security posture. That is a part-time to full-time DevOps role. The upside: that cost stays roughly flat as usage grows, while Heroku's bill grows with every dyno. Two ways keep it light: use managed AWS services (ECS Express Mode, Aurora Serverless v2, managed pipelines), or have a partner operate the platform for you.

VIMiddle grounds, and when to stay or move

The choice is not "stay on Heroku" or "rebuild everything on raw AWS". There are steps in between, and plenty of teams should not move at all.

Middle grounds on AWS. ECS Express Mode gives you a Heroku-like "image in, URL out" setup on Fargate with no extra charge beyond the resources it creates. Elastic Beanstalk is an older, more configurable PaaS layer. Aurora Serverless v2 removes most database sizing work. AWS also has a free planning tool, AWS Startup Advisor, whose IDE plugin maps Heroku dynos, Postgres and add-ons to AWS services and produces a migration plan. Outside AWS, Render, Railway and Fly.io copy the Heroku model at lower prices, with smaller ecosystems.

Stay on Heroku when the break-even math says no, your team has little ops capacity and no plan to add it, your app fits Heroku's model (web plus workers, Postgres, Redis, no request over 30 seconds, no GPU or warehouse needs), and you are still finding product-market fit.

Move when two or more of these are true: the bill is large and growing, you hit Heroku's limits often enough to shape your engineering, the roadmap needs AWS-only services, or you already have (or are hiring) platform capacity.

VIIWho runs the move, and who can fund it

Once moving makes sense, two costs remain: the engineering time to migrate, and running the platform afterwards. A partner can carry both.

A vetted AWS partner can run the migration end to end: the landing zone, containerising the app (buildpack to Dockerfile), the database cutover (Heroku Postgres to RDS or Aurora; classic Heroku plans mean a planned dump and restore), supporting services such as ElastiCache and Secrets Manager, and cost tuning. Many partners can also operate the platform afterwards, so leaving Heroku does not force a platform hire.

Partner-filed funding: the AWS Migration Acceleration Program (MAP) helps offset initial migration costs. Your matched partner files it when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. MAP is built for migrations with meaningful ongoing AWS spend, so a small Heroku app may not qualify. The partner checks before filing.

AWS Activate: you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000. Activate Portfolio gives up to $200,000 with the Org ID from your VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.