AWS Bites Episode 143 Summary: "Is App Runner better than Fargate?"

May 8, 2025 | Hosts: Luciano Mammino & Conor

Episode Overview

In this episode, Luciano and Conor explore the real-world differences between AWS App Runner and ECS Fargate for containerized web application hosting. Drawing from a recent migration project and hands-on experimentation, they discuss where App Runner shines, where it falls short, and offer practical insights for AWS developers seeking simplicity or flexibility in container management. The episode is rich with candid assessments, technical deep-dives, and no-nonsense advice for choosing the right service for your workload.

Main Topics & Discussion Points

1. Setting the Stage: The Migration Use Case

• [00:00–04:06] Luciano describes the context: migrating a small, monolithic Rust web app (with a SolidJS SPA frontend) from on-prem to AWS. The team wants a no-fuss, minimal-effort migration, sparking curiosity about App Runner — AWS’s answer to Heroku-like deployment abstraction.
• Notable Quote:

  "What if there was a service that just took your code or your container...deployed it, scaled it, and just gave you a URL...and at that point you are just done. That's actually the promise of a service called AWS App Runner. And in this episode we are putting that promise to test."
  — Luciano [00:42]

2. What is AWS App Runner?

• [02:04–04:06] Conor gives an overview: App Runner, launched mid-2021, aims to let developers run web apps and APIs without the operational overhead of Fargate or ECS. Targets "throw your container over the wall" simplicity. Handles build, deploy, HTTPS, scaling, etc., and abstracts VPC, ALBs, etc.

• App Runner is primarily for HTTP workloads and promises a simple path from code/Dockerfile to live app.

• Notable Quote:

  "[App Runner] removes a lot of complexity...Apparently we can throw a container over the wall and make it AWS's problem. That's the dream."
  — Conor [02:55]

3. Comparing Fargate and App Runner: Operational Complexity

• [06:11–08:52]
  • Fargate: Familiar, flexible, but surprisingly complex (VPC, NAT, ALB, IAM, etc.), especially for small web apps.
  • App Runner: Hides nearly all infrastructure, offers auto-scaling to (almost) zero, and, crucially, no visible load balancer.
• Notable Quote:

  "It's very easy to forget the level of moving parts involved in Fargate just for a pretty straightforward web app."
  — Conor [07:02]

4. App Runner Pricing Model

• [08:52–14:07]
  • App Runner pricing is based on memory and vCPU, similar to Lambda, but there’s always at least one container running (doesn’t truly scale to zero).
  • Minimum baseline: ~$5/month for a dormant app + CPU charges when containers are active.
  • No separate charge for load balancers (unlike Fargate).
  • Build/deploy automation has additional (minor) costs ($1/month + $0.005/min build time).
  • Comparison Caveat: At scale, App Runner may be more expensive than Fargate due to resource premiums.

5. Networking Nuances

• [14:07–16:40]
  • App Runner abstracts VPCs, reminiscent of legacy EC2 Classic or Lambda outside VPC.
  • For database access in your own VPC: use an App Runner-specific “VPC Connector” (backed by PrivateLink), but at this point, the usual AWS networking complexity re-emerges (routing tables, NAT, etc.).
• Notable Quote:

  "I think for most serious use cases, you still need to understand a little bit of networking and make sure you understand how to connect App Runner to your own VPC."
  — Luciano [16:37]

6. Auto-Scaling & Instance Configuration

• [16:58–20:00]
  • Scaling is based on max concurrency (1–200 requests per instance; 200 is the hard limit), and you define min/max container counts.
  • Only a small set of compute choices: vCPU (0.25, 0.5, 1, 2, 4) and RAM (2, 3, 4 GB).
• Frustration: 200 req/sec per instance may be low for efficient runtimes (e.g., Rust), leading to forced over-scaling.
• Notable Quote:

  "I was actually a bit disappointed...the maximum is 200, because my benchmark shows that it can easily handle much more than that with one container. But AWS is forcing me to have that as a maximum."
  — Luciano [31:18]

7. Security & Operations

• [20:00–22:48]
  • GitHub integration via AWS Connector — supports fine-grained repo access.
  • Secrets: Both Secrets Manager and SSM Parameter Store are supported as env vars.
  • Instance roles (like ECS/Fargate task roles) are available.
  • WAF supported; good Terraform coverage.
• Opinion: App Runner is "not just a click-ops solution" — can be integrated into mature IaC workflows.

8. Background Jobs & Limitations

• [22:48–26:00]
  • Due to container freezing, background jobs within the container (as in Rails/Laravel) may never run if traffic is sparse.
  • Solution: Use external event-driven AWS services (EventBridge, Lambda) for background processing.
• Notable Quote:

  "[W]e didn't expect to...have to do some rework on the application to kind of adjust for this particular use case."
  — Luciano [25:23]

9. Other Frictions: Migrations and Lifecycle Hooks

• [25:30–27:45]
  • No obvious support for 'run-once' hooks or database migrations (no proper App Runner lifecycle hooks).
  • Solutions include app-level distributed locks or custom Lambda solutions, which can be awkward with standard frameworks.

10. The Good, The Bad, and The Confusing (The Summary Section)

• [27:45–37:27]
  The Good

  • Simplicity reminiscent of Heroku, Fly.io, Railway.
  • Fast deployments, nice auto-scaling abstraction.
  • Multiple scaling config profiles (e.g., for seasonal events).

• The Bad/Ugly

  • IaC Support (CDK, CloudFormation): Poor. Many features not exposed (e.g., custom domains). Workarounds require custom resources (see [33:01–34:45]), adding complexity.
  • Docs Bias: Heavily click-ops oriented, unsupportive for infra-as-code workflows.
  • Log Group Sprawl: Each deployment creates a new log group leading to cost and management headaches.
  • Product Investment: Unclear AWS commitment; some bugs/rough edges have lingered for years.

• Notable Quote:

  "My general worry is that...I found posts that were like three years old where people already complained about these issues and they are still open. So I'm just a little bit concerned...what is the level of investment for AWS on this service?"
  — Luciano [36:41]

• Humor:

  "I look forward to the blog post 'Migrating your AWS App Runner apps to ECS Fargate' that will be published in 2029."
  — Conor [37:27]

11. Final Comparison & Recommendations

• [38:15–end]
  • App Runner is ideal for:
    • Hobby projects, prototypes, feature branch deployments.
    • Developers wanting minimal AWS experience for simple web workloads.
    • Apps with infrequent usage and low cost sensitivity to idle instances.
  • Fargate is preferable when:
    • Resource usage is high/complex.
    • You need fine-grained infrastructure control, custom networking, or have scale requirements where unit pricing matters.
    • You need feature completeness with IaC tools.
  • Pricing Consideration: App Runner can be cheaper at low scale (no ALB!), but at high load the premium may tip back in favor of Fargate.
  • "It depends" is the answer: App Runner enters the containerization decision tree, sitting between Lambda and Fargate.

Memorable Quotes & Timestamps

• "That's the dream. So focus on building your app. You know, App Runner will has a build process." — Conor [02:38]
• "It's very easy to forget the level of moving parts involved in Fargate just for a pretty straightforward web app." — Conor [07:02]
• "There is always one container at least sleeping there. So your memory cost in a way...has a baseline that is fixed." — Luciano [09:08]
• "I think for most serious use cases, you still need to understand a little bit of networking and make sure you understand how to connect App Runner to your own VPC." — Luciano [16:37]
• "Auto scaling...you can actually create multiple configurations...you could have, I don't know, a Christmas event configuration..." — Luciano [28:32]
• "I was actually a bit disappointed...the maximum is 200, because my benchmark shows that it can easily handle much more than that with one container. But AWS is forcing me to have that as a maximum." — Luciano [31:18]
• "If you are a cloud practitioner...please use infrastructure as code and AWS, please support people more to be able to use [it]." — Luciano [34:03]
• "My general worry is that...I found posts that were like three years old where people already complained about these issues and they are still open." — Luciano [36:41]
• "It depends, right? Are we allowed to say that on the podcast as consultants?" — Luciano [38:15]
• "For me it's definitely a service that is worth [a] look and it's definitely something I'll be playing around with..." — Conor [39:52]

Key Takeaways (TL;DR)

• App Runner excels at simplicity and speed for web app deployments, especially for small-scale or non-critical workloads. It's a credible AWS answer to the "Heroku for containers" dream, as long as you need only HTTP workloads.
• Fargate retains the upper hand for feature-completeness, scalability, and infrastructure as code friendliness.
• App Runner's abstraction hides most AWS infrastructure, but advanced networking (databases, VPC) and certain ops patterns (migrations, background jobs) require extra care, and sometimes convoluted AWS glue.
• IaC and custom domain support are major pain points in App Runner today.
• Pricing can be attractive for low-usage apps, but may skew higher for always-on or high-load services.
• Recommendation: Start with App Runner when you want fast, managed HTTP workloads with minimal AWS knowledge, and switch to Fargate as your needs outgrow its abstractions or when you hit rough IaC edges.

Table of Main Segments & Timestamps

| Segment | Timestamps | Speakers | |-----------------------------------------------|--------------|---------------| | App Context & Problem Setup | 00:00–04:06 | Luciano | | What is App Runner? | 02:04–04:06 | Conor | | App Runner vs Fargate (Complexity) | 06:11–08:52 | Conor | | App Runner Pricing Model | 08:52–14:07 | Luciano | | Networking Intricacies | 14:07–16:40 | Both | | App Runner Auto-scaling & Config | 16:58–20:00 | Both | | Security, GitHub, Secrets, IaC | 20:00–22:48 | Conor | | Background Jobs, Migrations, Lifecycle | 22:48–27:45 | Both | | Good, Bad, and Ugly (Summary) | 27:45–37:27 | Both | | Final Analysis: Which to Choose & When | 38:15–End | Both |

Closing Words

Both hosts encourage listeners to experiment with App Runner, share stories, and contribute to improvement by voicing feedback. While App Runner isn’t perfect — notably around infrastructure as code and advanced use cases — for many developer-centric scenarios, it dramatically lowers the AWS learning curve and “just works” feeling.

Links promised in the show (not listed here):

• Open Github discussion about scaling to zero
• Mark van Holstein's custom domain IaC workaround
• Route53 Alias config workaround for App Runner
• App Runner/CDK/CloudFormation documentation

Sponsor shout-out:
Thanks to FourTheorem for supporting this episode and helping teams build simple, scalable, cost-effective serverless solutions on AWS.

End of summary.