We run three Next.js applications on AWS App Runner and wrote an honest review after six months. The question we get most about that article isn't about timeouts or health checks. It's "isn't App Runner more expensive than Fargate?"
Per vCPU-hour, yes, by about 58 %. Per month, for most small teams, no. The difference is in what each service charges you for while nobody is using the app, and in the plumbing Fargate needs that App Runner includes. Below is the same application priced both ways, at list price in us-east-1, with every line that shows up on the bill.
The two price lists
| App Runner | Fargate (Linux, x86) | Fargate (Linux, ARM) | |
|---|---|---|---|
| vCPU | $0.064 per vCPU-hour, only while handling requests | $0.040478 per vCPU-hour, always | $0.03238 per vCPU-hour, always |
| Memory | $0.007 per GB-hour, always | $0.004446 per GB-hour, always | $0.00356 per GB-hour, always |
| Load balancer | Included | ALB: $0.0225/hour + $0.008 per LCU-hour | same |
| HTTPS endpoint, TLS certificate | Included | ACM certificate on the ALB (free) | same |
| Public IPv4 | Not billed to you | $0.005/hour per address (ALB and tasks) | same |
| Savings Plans / Spot | No | Compute Savings Plans, Fargate Spot | same |
Both bill per second with a one-minute minimum. The row that matters is the first one. App Runner splits an instance's life into two states: provisioned (it exists, it's warm, it's waiting) and active (it's processing at least one request). In the provisioned state you pay only for memory. Fargate has no such state: a running task pays for its vCPU and its memory every second it exists, whether it serves a thousand requests or none.
The app we priced
This is the public application from our AWS bill breakdown: a Next.js app for a US client, two always-on instances of 2 vCPU and 4 GB each, so a deploy or a crash never leaves it with zero capacity. 730 hours in a month.
App Runner. Memory is paid around the clock: 2 instances × 4 GB × $0.007 × 730 h = $40.88. vCPU is paid only while an instance is active: 2 instances × 2 vCPU × $0.064 × 730 h = $186.88 if both were busy every second of the month. The real number is $186.88 multiplied by the share of time the instances are handling requests. We'll call that share the busy fraction.
Fargate, x86. Each task costs 2 × $0.040478 + 4 × $0.004446 = $0.0987 per hour. Two tasks for a month: $144.16. Then the parts App Runner doesn't make you think about:
- An Application Load Balancer: $0.0225 × 730 = $16.43, plus about one LCU on average for modest traffic, $5.84. $22.27.
- Public IPv4 for the ALB, one per availability zone, two zones: $7.30.
- The tasks need a route out to call external APIs, pull images and send email. Either public subnets with a public IP per task ($7.30) or private subnets and a NAT gateway ($32.85 plus $3.65 for its address plus $0.045 per GB processed, ~$37).
Total for Fargate on x86: ~$181 with public subnets, ~$210 with private subnets and a NAT. The same setup on ARM (Graviton), public subnets: ~$152.
Where they cross
App Runner's bill is $40.88 plus $186.88 × busy fraction. Fargate's is a flat number. Put them on the same chart:
| Busy fraction | App Runner | Fargate ARM, public | Fargate x86, public | Fargate x86 + NAT |
|---|---|---|---|---|
| 10 % | $60 | $152 | $181 | $210 |
| 25 % | $88 | $152 | $181 | $210 |
| 50 % | $134 | $152 | $181 | $210 |
| 75 % | $181 | $152 | $181 | $210 |
| 100 % | $228 | $152 | $181 | $210 |
App Runner stays cheaper than x86 Fargate until the instances are busy three quarters of the time, and cheaper than the private-subnet setup almost always. Graviton moves the line to 60 %.
What "busy" really means
This is where people get the comparison wrong in both directions. Busy is not CPU utilisation. An App Runner instance is active, and billed for vCPU, whenever at least one request is in flight, with a one-minute minimum each time it wakes up. A single request every thirty seconds keeps an instance active continuously, even if the CPU sits at 2 %.
So the honest way to estimate your busy fraction is to look at when traffic exists at all, not at how heavy it is:
- A B2B app used in office hours in one or two time zones: busy roughly 10 to 12 hours on weekdays, idle nights and weekends. That's 30 to 40 %. This is our client's public app, and it's why App Runner is cheaper for it.
- A consumer app with global traffic, or anything polled by monitors, webhooks and bots around the clock: effectively 100 %. Here Fargate wins, clearly on ARM.
- Internal tools, admin panels, staging: busy a few percent of the time. App Runner at minimum size (0.25 vCPU, 0.5 GB) costs about $2.60 a month idle. The same Fargate task costs $9 a month whether anyone opens it or not.
Check your own number before deciding. The ALB or CloudFront request logs grouped by minute will tell you what share of minutes had any request.
The line most comparisons leave out
App Runner doesn't need a NAT gateway for outbound internet access on its default networking. The moment you add a VPC connector so the service can reach a private database, all outbound traffic goes through your VPC, and you need a NAT for anything on the internet: Stripe, an email API, an identity provider. That's our case: our App Runner services talk to Aurora, so the account already has a NAT.
When both options need the NAT, it cancels out of the comparison and the break-even goes back to about 75 % on x86. When App Runner doesn't need one and Fargate would, it's $37 a month per account that only one side pays. With three accounts (dev, staging, prod), that's over $100 a month, the third-largest line on our bill.
When Fargate is the right answer anyway
Cost isn't the only input, and there are cases where we'd pick Fargate at any busy fraction:
- Requests that run longer than 120 seconds. App Runner's gateway timeout is fixed. Exports, report generation and long AI calls either move to a queue or move to Fargate.
- You want commitments. Compute Savings Plans cover Fargate, not App Runner, and Fargate Spot takes up to 70 % off interruptible workers. At our bill size commitments aren't worth it yet; at ten times the size they are.
- You need control over the network path: sidecars, service mesh, specific security-group rules per task, several containers in one task. That's what ECS is for, and our Fargate guide covers the setup.
- Many services behind one ALB. The ALB's fixed cost is paid once. With ten services behind host-based listener rules, it becomes $2 per service and the comparison shifts toward Fargate for the busy ones.
What we'd do
For a small team shipping web applications, start on App Runner. It's cheaper at the traffic most young products actually have, there's no ALB, no target groups and no subnets to reason about, and moving to Fargate later is a change to the CDK stack, not to the application, since both run the same container image (keep it small either way).
Revisit when one service is busy most of the month or when its App Runner line passes a couple of hundred dollars. At that point, run that one service on Fargate with Graviton and leave the quiet ones where they are.
If you want the calculation done for your own traffic and architecture, talk to us. It's usually a one-hour exercise with your Cost Explorer open.