AWS App Runner Pricing Guide: When It Pays Back vs Fargate and Lambda

App Runner gets one or zero conversations in most EDP renewal cycles because it is dwarfed by EC2 and Fargate spend. That is a mistake at scale. We have seen App Runner bills above $50K per month at customers running 30+ services, and the savings against equivalent Fargate are real for the right traffic pattern.

App Runner's two-rate pricing model

App Runner charges two separate hourly rates per instance, and understanding the split is the entire optimisation.

• Provisioned instance rate. Approximately $0.007 per vCPU-hour and $0.0008 per GB-hour. Bills whenever an instance is provisioned but not actively serving traffic.
• Active instance rate. Approximately $0.064 per vCPU-hour and $0.007 per GB-hour. Bills only when the instance is actively processing a request.

The ratio is roughly 9x between active and provisioned. App Runner can therefore keep a service warm for 11 percent of the cost of an always-active container.

Scale-to-zero versus minimum provisioned instances

The minimum provisioned instance count is the most important App Runner setting from a cost perspective.

If your service can tolerate a 3 to 10 second cold start on the first request after idle (typical for internal tools, admin panels, or low-priority APIs), set minimum to zero and save the provisioned hours.

App Runner versus Fargate: head-to-head

Same workload, both services, 1 vCPU, 2 GB, sustained traffic varying from 0 to 100 RPS.

App Runner wins when total active hours per month are below approximately 350 hours per instance (about 50 percent duty cycle). Above that, Fargate is cheaper, particularly with a Compute Savings Plan.

Where App Runner does not apply

• Workloads needing GPUs. App Runner does not support GPU instances.
• Stateful workloads. App Runner is request-scoped; persistent connections beyond HTTP/2 streaming have limits.
• VPC-only services. App Runner VPC connector adds latency and complexity; ECS or EKS may be cleaner.
• Background workers. App Runner is HTTP-driven. SQS-consumer workloads belong on Lambda, Fargate, or ECS.
• Very high-throughput APIs (above 1,000 RPS sustained). Pricing crossover with Fargate plus Savings Plan goes against App Runner.

Optimisation playbook

1. Set minimum provisioned to zero for any service that can tolerate a 3 to 10 second cold start.
2. Right-size CPU and memory. App Runner supports 0.25 vCPU through 4 vCPU. Many teams over-provision out of habit. Test the smallest size that meets latency.
3. Use auto-deployment carefully. Each ECR push triggers a deployment if auto-deployment is on. Deployments incur minimal cost but add request latency briefly.
4. Consolidate microservices. 30 small App Runner services each at minimum=1 carry 30x the idle cost of consolidating to 5 services at minimum=1.
5. Match concurrency to instance size. Default concurrency is 100; for low-CPU workloads, increasing concurrency reduces instance count.
6. Tag for cost allocation. App Runner supports cost allocation tags. Use them to attribute spend to product lines.

Migration patterns

Common migration paths we have run for clients:

• ECS Fargate to App Runner. For services with intermittent traffic, particularly internal tools and admin dashboards. Migration effort: under 1 week per service.
• Lambda to App Runner. For services hitting Lambda's 15-minute timeout or memory limits. Migration effort: 1 to 3 weeks depending on framework changes.
• App Runner to Fargate. When a service crosses the 350 active-hour threshold and Savings Plans become attractive. Migration effort: 1 to 2 weeks.

Cost monitoring specifics

App Runner billing line items in Cost Explorer break out as:

• Active vCPU-hours, billed per second
• Active GB-hours, billed per second
• Provisioned vCPU-hours, billed per second
• Provisioned GB-hours, billed per second
• Build runtime (if using AWS CodeBuild integration), billed per minute

Set CloudWatch alarms on active vCPU-hours to detect runaway scaling, and on provisioned vCPU-hours to detect overprovisioned minimum settings.

Action checklist

1. Inventory every App Runner service. Record minimum provisioned, concurrency, CPU and memory size.
2. For services with under 30% duty cycle, set minimum to zero.
3. For services above 50% duty cycle, model migration to Fargate or ECS on EC2.
4. Set CloudWatch alarms on active and provisioned hours.
5. Apply cost allocation tags to attribute spend to product lines.
6. Scope App Runner discounts in your next EDP negotiation.
7. Contact our advisory team for an App Runner audit benchmarked against $2.4B+ of reviewed AWS spend.

See our AWS serverless cost guide, serverless vs containers cost piece, and Lambda pricing optimization guide for the broader runtime selection picture.

Cold start mitigation without paying full provisioned cost

For services that need consistent low latency but also have idle periods, App Runner's two-rate model still offers meaningful savings if you accept a partial mitigation strategy. The pattern: set minimum provisioned to 1 instance during business hours and 0 outside business hours via CloudWatch Events triggering a deployment configuration change.

Implementation: AWS does not provide a native scheduler for App Runner minimum-provisioned settings, but a Lambda function on EventBridge schedule can call the UpdateService API to switch the minimum at scheduled times. The cost: a few cents per month in Lambda invocations to save tens of dollars per month per service.

This pattern works particularly well for internal tools and admin panels with predictable business-hours traffic.

App Runner concurrency tuning

The concurrency setting on App Runner controls how many simultaneous requests each instance can handle before App Runner spawns another. Default is 100. For CPU-bound workloads, 100 is too high; for low-CPU IO-bound workloads, 100 is too low.

Tuning concurrency upward on IO-bound workloads is the single fastest way to reduce App Runner instance hours.

Build-time costs and CI/CD integration

App Runner supports direct ECR image deployment and source-code-based deployment via AWS CodeBuild integration. The CodeBuild path bills per-minute build runtime separately. For monorepos with 30+ services rebuilding on every commit, CodeBuild charges can easily exceed App Runner runtime charges.

Optimisation: pre-build images in your existing CI/CD pipeline (GitHub Actions, GitLab CI, Buildkite), push to ECR, and deploy App Runner from ECR. Eliminates the CodeBuild line item entirely. App Runner's CodeBuild integration is convenient but rarely the cheapest path at scale.

App Runner with custom domains and TLS

App Runner provides a default *.awsapprunner.com URL at no additional cost. Custom domains require a DNS configuration change but do not add direct App Runner charges. TLS certificates from AWS Certificate Manager are free.

Indirect costs to watch:

• Route 53 hosted zone: $0.50/month per zone.
• Route 53 queries: per million; usually negligible for app traffic.
• If you front App Runner with CloudFront, full CloudFront pricing applies on top.

The App Runner versus Elastic Beanstalk question

Elastic Beanstalk is App Runner's predecessor in spirit: opinionated, environment-managed compute. The differences:

For most green-field deployments today, App Runner is the better choice unless you specifically need EC2-level control. For existing Beanstalk environments with significant Savings Plan coverage, migration may not pay back.