Heroku vs AWS cost comparison

Tapitalee was designed with the same mental model as Heroku, but the resources end up in your own AWS account, and you pay AWS for them directly.

Tapitalee hides the operational complexity of AWS behind a standard architecture: Apps and add-ons.

Below are three typical workloads, priced on Heroku and on AWS. The AWS figures are what you'd pay AWS; they exclude Tapitalee's monthly fee, which is a flat subscription with no markup on your AWS usage. See the Tapitalee pricing table for that part.

Where the numbers come from

Heroku prices are list prices from heroku.com/pricing. AWS prices are us-east-1 on-demand estimates at 730 hours per month, rounded to the nearest dollar. They leave out CloudWatch logs, snapshot storage and other small usage-based charges, which for these workloads add up to a few dollars rather than tens. Other AWS regions are a little more expensive; Sydney or São Paulo can add 20-40% to compute.

The Small SaaS and Enterprise examples use newer Fir dynos and each includes the full $1,000/month Private Space fee for one region. A Private Space can be shared across multiple apps, so you only pay that fee once for apps sharing the same space. The Hobby app uses Cedar Standard-2X dynos and does not require a Private Space.

The above table does not include Tapitalee's subscription. Tapitalee doesn't mark up your AWS bill, so the total cost of running on Tapitalee is the AWS column plus the flat fee from the pricing table.

Dynos become Fargate containers

Each dyno type in your Procfile becomes a process in Tapitalee, which in turn becomes a container running on ECS Fargate. Fargate bills per vCPU and per GB of memory, per second, so the price of a container is just its size multiplied by the hours it runs. The figures above are x86 on-demand. Graviton (ARM) containers are about 20% cheaper, and Fargate Spot is up to 70% cheaper for workers that can tolerate the occasional interruption; any process can mix spot containers in alongside on-demand ones.

The table uses matching memory sizes for web containers: 4 GB on both Fir and Fargate for Small SaaS, and 16 GB for Enterprise web containers and background workers. The Small SaaS background worker is 1 GB on both Fir and Fargate. Fargate memory comes in 1 GB steps at these CPU sizes, so you can pay just for what you use. That flexibility is worth a lot when you're tuning a memory-hungry Rails or Django app.

Heroku Postgres and Redis become RDS and ElastiCache

Heroku Postgres plans bundle RAM, storage, connection limits and high availability into a single name. On RDS those are separate knobs. You pick an instance class (which sets RAM and CPU), a storage size in GB, and whether you want Multi-AZ, which is for higher availability.

Redis maps to ElastiCache, running Valkey (the open-source Redis fork). A cache.t4g.micro gives you about 512 MB for around $10 a month, versus $120 for Heroku's Key-Value Store Premium-3 of the same size. Heroku offers smaller, cheaper sizes, but they are limited in CPU power and number of connections they can handle.

Bandwidth

Heroku doesn't bill for bandwidth, though dynos have a 2 TB per month soft limit. AWS does charge for data transferred out to the internet: the first 100 GB a month is free, then about $0.09 per GB. Inbound traffic is free. The traffic figures in the table are illustrative for each size of workload, so if your app serves a lot of images or video, add this line up carefully, or put a CDN in front of it.

What the totals don't show

• Scale to zero. Containers cost nothing when they're switched off. Fargate bills per second, so a preview app that lives for a two-hour code review costs cents.
• Savings plans. If you know a workload will run all year, an AWS Compute Savings Plan takes a further 20-50% off Fargate and there's a similar option for RDS reserved instances.

Tapitalee makes it easier

Compared to using AWS on its own, Tapitalee makes it easy. We show the monthly cost for containers and databases in real-time as you create or resize them.

If the numbers look interesting and you'd like to understand how the rest of your Heroku setup carries across, our post on Porting from Heroku walks through dynos, the Procfile, config vars, add-ons and Heroku Postgres one at a time and shows the Tapitalee equivalent of each.

For a real example, read our case study on moving a SaaS product from Heroku to AWS. And if you'd like help pricing your own workload, get in touch.