TL;DR: App Runner normally bills provisioned compute 24/7 whether or not anyone hits it. Turn on Automatic Pausing and an idle service scales to zero — code stays deployed, config preserved, compute charge stops — waking in 2–5 seconds on the next request. It converts App Runner from always-on rental into Lambda-style pay-per-use. Business-hours apps drop 60–70%; sporadic ones 80–95%. The whole cost is that first-request cold start.
The numbers
| Traffic shape | Compute you pay for | Typical saving |
|---|---|---|
| Steady 24/7 | ~168 hrs/wk | little — rightsize instead |
| Business hours (idle nights/weekends) | ~50 hrs/wk | 60–70% |
| Sporadic (silent for hours/days) | near-zero | 80–95% |
- With pausing you pay for provisioned instances only during active periods, plus a small per-request fee and build time.
- Field examples: a 12-person team's business-hours support dashboard went from 168 to ~50–60 billed hours/week (~65% cut, zero code change). An investor-demo app used ~5×/week for 20 min dropped from ~$50/mo to under $5/mo (>98%).
Do this
- Enable it in the console (or API/CDK): check "Pause service when inactive." That's the whole switch.
- Tune the inactivity timeout (default ~5 min): spiky/webhook bursts → shorter (1–3 min) so you don't pay through the lulls; steady-with-gaps → longer (5–10 min) to avoid pause/resume thrashing; mostly idle → shorter.
- Turn it on everywhere non-prod by default — there is almost no reason a dev or staging service runs 24/7.
- Segment production by latency tolerance: internal tools, admin panels, webhook receivers, batch APIs → pause; customer-facing latency-SLA paths → leave provisioned.
- Watch resume time in CloudWatch — if cold starts creep past ~5s, your container image is too large; slim it down.
Gotchas
- The cold start is real: the first request after idle waits 2–5s while an instance spins up. Requests aren't dropped (no 503, no standby tier) — they're held. Fine for internal tools; a dealbreaker for checkout and real-time paths.
- Steady 24/7 traffic saves almost nothing — the service rarely enters the paused state, so you pay for compute nearly all the time anyway.
- Pairs with autoscaling, doesn't replace it: App Runner scales 1→N during active periods; pausing just adds the →0 step when idle.
Skip this if
- The service is customer-facing with a strict latency SLA (payments, real-time chat, live dashboards) — keep it provisioned and instead rightsize the instance class and tune min/max instances.
- Traffic is genuinely steady 24/7 — pausing never triggers; rightsizing is your lever.
- You want the simpler pay-only-when-active endpoint model without a container — see AWS Lambda Function URLs.