Heroku vs AWS: PaaS convenience vs IaaS control

Who should operate your runtime?

Heroku and AWS answer one question differently, and everything else follows from it: who is responsible for the machine your code runs on? Heroku says nobody on your team is, because the platform builds the application, provisions the container, routes traffic to it, terminates TLS, restarts it when it dies and rotates the underlying host without telling you. AWS says you are, and hands you an extraordinary toolkit for doing the job properly.

The comparison is unusual because Heroku runs on AWS infrastructure. You are not choosing between two data center operators; you are choosing between two levels of abstraction over largely the same physical estate. What you buy from Heroku is the removal of decisions. What you buy from AWS is the ability to make them.

This page works through that trade for developers, for businesses and for infrastructure teams, and it is honest about where each model stops making sense. AllCloudShop supplies a Heroku account and an AWS account, each operated by the buyer under that provider's terms of service.

Abstraction levels, side by side

What you gain and what you give up

The twelve-factor contract

Heroku popularized the twelve-factor application style, and its platform enforces it. Configuration comes from environment variables, logs go to standard output, the filesystem is ephemeral, and processes are disposable. Applications written that way deploy with almost no friction. Applications that expect local disk, long-lived in-process state or background threads running between requests need rework before they will behave.

Operational surface

On Heroku there is no host to patch, no load balancer to configure, no certificate to renew and no operating system to harden. That eliminates entire categories of work, and it also eliminates the ability to tune them. On AWS you own the kernel version, the instance family, the placement, the network path and the failover behavior, which is exactly what some workloads require and exactly what many teams do not want to think about.

Cost shape rather than cost level

Heroku charges for a managed runtime, so the platform work is embedded in what you pay. AWS charges for resources and leaves the platform work to your payroll. Comparing invoices without counting engineering hours produces misleading conclusions in both directions, which is why the comparison usually turns on team size rather than arithmetic.

Escape velocity

Leaving Heroku is a well-trodden path because applications there are usually portable by construction: a container image, environment variables and a managed Postgres database. Leaving a deeply integrated AWS design is harder, because Lambda functions, DynamoDB tables and IAM-based access patterns have no direct equivalents elsewhere. The Heroku migration guide covers the first case in detail.

Day-to-day development

Heroku's workflow is famously short. Commit, push, watch the build log, and the application is live behind HTTPS with logs streaming. Review Apps spin up a full environment per pull request, Pipelines promote a tested slug from staging to production without rebuilding, and add-ons attach a database or a monitoring tool by setting a config variable. For a small team, this is an enormous amount of delivery machinery for no setup effort.

AWS gives you the parts to build the same thing, better suited to your situation and considerably slower to assemble. CodePipeline, GitHub Actions or your own runners handle delivery, ECS or EKS runs containers, Application Load Balancers route traffic, ACM issues certificates and CloudWatch collects logs. Once built, it is yours to tune; before it is built, it is a project.

• Adding a queue: a Heroku add-on with a config variable, versus SQS with an IAM policy and a consumer.
• Scheduled work: Heroku Scheduler or a clock process, versus EventBridge rules triggering Lambda or ECS tasks.
• Secrets: config variables on the app, versus Secrets Manager or Parameter Store with role-based access.
• Zero-downtime releases: preboot on Heroku, versus rolling or blue-green deployments you configure yourself.

Anyone unfamiliar with the dyno model should start with the dynos and buildpacks explainer, and the service model primer is useful for framing the wider category difference.

Business considerations

The strongest business case for Heroku is headcount. A team without a dedicated infrastructure engineer can ship and operate a production application, because the platform covers the roles nobody was hired for. That advantage narrows as the team grows, because at some point you have people who could do the work and workloads that reward doing it.

The strongest business case for AWS is optionality. Nothing you might need later is unavailable, enterprise procurement processes already accommodate it, compliance coverage is unusually broad, and the hiring market is deep. For companies whose customers audit their suppliers, that combination often settles the question before technical merit is discussed.

There is also a middle path worth naming. Running containers on AWS App Runner or ECS with Fargate removes server management while keeping you inside the AWS ecosystem. It is less automatic than Heroku and less manual than EC2, and it suits teams that want managed runtime without leaving the platform their data already lives on.

What sits underneath

Heroku's Common Runtime places applications in shared infrastructure in the United States and Europe, with routing, isolation and host management handled by the platform. Private Spaces provide a dedicated network environment in additional regions, with stable outbound addresses and the ability to peer with your own network, which is how larger customers satisfy connectivity and compliance requirements.

AWS gives you the raw geography instead: regions on every populated continent, multiple availability zones per region, edge locations, Local Zones and private interconnects. If your application must serve users on several continents with low latency, or survive the loss of a data center automatically, you can express that directly rather than asking a platform to do it for you.

Storage is the clearest structural difference. Heroku's filesystem is ephemeral by design, so uploads and generated files belong in object storage regardless of platform. On AWS you choose between block volumes, shared file systems and S3 depending on access pattern. The block versus object storage article explains which one a given workload actually needs.

What each does best

Heroku

Compressing the distance between a commit and a running service. Buildpacks handle language runtimes, dependency installation and process types without a Dockerfile, Review Apps give every pull request a live environment, and Pipelines make promotion a single action. Heroku Postgres is a genuinely good managed database with forks, followers and point-in-time recovery, and the add-on marketplace turns most infrastructure needs into a configuration change.

AWS

Covering every requirement you might develop later. Compute options range from serverless functions to bare metal, storage from object to block to archival, and data services from relational to key-value to warehouse scale. Fine-grained permissions, multi-account governance and broad compliance coverage make it acceptable to the most demanding buyers, and the ecosystem of tooling, training and expertise is unmatched.

Where each model breaks down

Heroku

The abstraction is a boundary as well as a convenience. You cannot choose instance types, tune the kernel, run privileged workloads or place capacity in an arbitrary region on the Common Runtime. Long-running requests conflict with the router's behavior, the ephemeral filesystem surprises newcomers, and heavy background processing often needs restructuring. As traffic grows, the cost of a managed runtime becomes more visible against equivalent raw capacity.

AWS

Everything is your responsibility, including the parts you forget. Teams routinely underestimate the ongoing work of patching, monitoring, certificate management, access reviews and cost control. IAM is powerful and unforgiving, service choices overlap confusingly, and technical support requires a paid plan. A small team can absolutely run on AWS, but only if someone owns the platform as an actual job.

Picking the right level

Heroku is the right call for small teams shipping conventional web applications, for products where time to market outweighs unit economics, for prototypes that need to be credible immediately, and for organizations with no appetite for infrastructure work. It is also excellent for staging and review environments even when production lives elsewhere.

AWS is the right call when workloads are unusual, when regulatory or contractual requirements dictate control, when multi-region resilience is required, when specialized compute or data services are central, or when infrastructure spend is large enough that optimization pays a salary.

A common and sensible pattern is starting on Heroku and moving the heaviest components to AWS once scale justifies the operational investment, keeping the rest where it is. Related comparisons include Heroku against DigitalOcean, Heroku against Vultr and AWS against DigitalOcean.

Documentation: the Heroku Dev Center and the AWS documentation.

Questions developers ask