AWS App Runner Deprecation — ECS vs. Cloud Run vs. Lambda Migration Guide

April 30, 2026 — From this date forward, AWS App Runner will stop accepting new workloads and transition into maintenance mode. While running services will not shut down immediately, its role as "the managed AWS service for casually running production containers" has effectively come to an end.

Alongside simultaneous announcements like the sunset of Amazon RDS Custom for Oracle in one year, AWS has accelerated moves in recent years to streamline niche services whose alternatives have matured across the broader ecosystem. SaaS operators, internal tool maintainers, and staging environment managers who adopted App Runner in the early 2020s must now decide where to migrate and when while they still have time to spare.

This article clarifies the background and implications of App Runner's retirement, then evaluates four realistic migration candidates—ECS/Fargate, Google Cloud Run, AWS Lambda (with API Gateway), and AWS Lightsail Containers—across operational burden, cost structures, and workload fit. Later sections explain the three phases of running a migration project and key estimation checkpoints clients should know at an operational level.

---

The role App Runner played — Why it is "disappearing"

Launched in 2021, App Runner was a managed service designed to deploy applications instantly from container images or GitHub repositories. Although built atop Fargate, it allowed users to expose a single container over HTTPS without having to manage VPCs, clusters, services, or task definitions. It occupied a distinct niche answering the demand for "the fastest container deployment," serving those for whom ECS/Fargate was too complex and Lambda posed hurdles with runtime limits or cold starts.

However, several years after its launch, three major structural shifts unfolded:

1. Substantial UX improvements in ECS/Fargate: With the arrival of ECS console wizards and the Copilot CLI, users could easily say, "Handle the VPC and load balancer for me."
2. Growing prominence of Google Cloud Run: Cloud Run seized leadership in the "container × event-driven" space through per-request billing, Pub/Sub integrations, and Eventarc.
3. Maturing container image support in Lambda: Support for images up to 10GB and SnapStart alleviated cold starts, while the managed AWS Lambda Web Adapter made hosting HTTP services straightforward.

Consequently, App Runner's unique selling points—a welcoming on-ramp for beginners, casual production operations, and effortless CI/CD—were absorbed by the broader ecosystem. Its retirement was an inevitable outcome.

What actually happens during maintenance mode

During what AWS designates as "maintenance mode," services are handled as follows:

• Suspension of new service creation: Creating new services via the AWS Management Console and APIs is blocked
• Existing services continue running: Workloads will not be terminated, but low-priority feature enhancements will cease
• Security patches remain supported: Critical vulnerabilities are expected to be patched
• Official End of Life (EOL) will be announced separately: Historically, around 1 to 2 years out

In short, workloads will not stop tomorrow; rather, they sit in a state where functionality slowly decays against a defined expiration date. Minor inconveniences will accumulate—password reset emails failing to send, or being unable to deploy in newly launched AWS regions.

---

Comparing four migration candidates from a practical perspective

When migrating from App Runner, the following four options are the top candidates.

ECS on Fargate: The rightful successor to App Runner

Because App Runner utilized Fargate under the hood, it can be viewed as a successor operating at the "same layer with richer functionality."

• Strengths: Seamless integration with other AWS services such as ALB, CloudFront, Route 53, and Secrets Manager. Using ECS Copilot CLI or Blueprints for ECS enables one-shot deployments on par with App Runner.
• Weaknesses: Adds an extra abstraction layer involving task definitions, services, and clusters. Requires explicitly configuring load balancers and IAM roles.
• Estimated cost: Around 15–20 USD per month for an always-on 0.5 vCPU / 1 GB configuration (Tokyo region). Roughly equivalent to identical specs on App Runner.

Recommended for teams that: Already maintain AWS-centric infrastructure, require fronting with an ALB or integration with an internal VPC RDS, and want to leverage observability via CloudWatch and X-Ray.

Google Cloud Run: The closest concept to App Runner

In terms of developer experience—simply exposing a single container—Cloud Run provides the experience closest to App Runner.

• Strengths: Per-request billing keeps idle costs minimal. Canary releases come standard via revision-based traffic splitting. Strong handling of asynchronous processing through integration with Eventarc and Pub/Sub.
• Weaknesses: Integrating with AWS internal resources like RDS and S3 requires self-managed solutions equivalent to VPC Peering or PrivateLink. Being multi-cloud also means maintaining two separate access management tracks.
• Estimated cost: Around 5–10 USD per month for 1 million requests and 500,000 vCPU-seconds. Drastically cheaper in low-traffic environments.

Recommended for teams that: Are not tied to AWS for databases or storage, or are launching new services that plan to leverage GCP services like BigQuery or Vertex AI.

AWS Lambda + API Gateway: The optimal choice for lightweight APIs

If your application is simple—receiving an HTTP request and returning a response—Lambda is an excellent choice.

• Strengths: Zero idle costs. Cold starts are mitigated with SnapStart. Frameworks like Express, Flask, and Django can be run with minimal modifications using Lambda Web Adapter.
• Weaknesses: A 15-minute maximum execution time, a 10 GB memory limit, and concurrency limits require management. Always-on WebSockets are not natively supported (requires API Gateway WebSocket API separately).
• Estimated cost: Around 1–3 USD per month for 1 million requests with an average processing time of 200 ms. Unbeatable for spiky workloads.

Recommended for teams that: Build internal tools, form processors, or applications with unpredictable request volumes where running a server 24/7 is unnecessary.

AWS Lightsail Containers: When you need straightforward, predictable monthly pricing

While often overlooked, Lightsail also provides container hosting.

• Strengths: Fixed monthly billing provides outstanding budget predictability. The console is simple and approachable even for team members without infrastructure experience.
• Weaknesses: Limited scaling capabilities. Weak VPC integration means private connectivity to services like RDS requires extra workarounds.
• Estimated cost: 7 USD per month for Nano (0.25 vCPU / 512 MB). Even Large is around 90 USD per month.

Recommended for teams that: Run internal landing pages or low-traffic SaaS products where cloud spending faces strict corporate approvals and internal approval requires a fixed price.

Reference: Making a choice from a startup perspective

When developing an MVP for a startup, balancing cost minimization with future scalability is particularly challenging. In the projects our company built over the past year, as discussed in the Startup MVP Development Cost Guide, a migration path of Cloud Run during validation followed by ECS/Fargate during scaling is increasingly proving to be the most cost-effective approach. Furthermore, pairing this with the approach in the Jamstack × Headless CMS Implementation Case Study—which offloads the frontend to SSG + CDN to minimize container loads on the backend—helps compress container uptime itself.

---

How to choose: Three decision axes

After laying out the four options, practical decision-making becomes much clearer when evaluated across the following three axes.

Axis 1: Traffic characteristics (constant vs. bursty)

• Always-on, steady load → ECS/Fargate or Lightsail
• Request-driven, unexpected spikes → Cloud Run or Lambda

Because App Runner sat midway between the two, this axis represents the first fork in the road. Start by measuring idle duration by pulling average, maximum, and minimum RPS from your monthly CloudWatch metrics.

Axis 2: Operational team structure (internal skills × observability)

• AWS-centric operations team available → ECS/Fargate
• Container beginners or lean operational staffing → Cloud Run or Lightsail
• Desire to unify observability on CloudWatch / X-Ray → ECS/Fargate or Lambda

If you plan to incorporate AI agents into your operational support, as covered in Explaining Multi-Cloud Support in AWS DevOps Agent, we have entered an era where resources outside AWS (including GCP) can also be monitored. The necessity to stay strictly confined to AWS has diminished compared to the past.

Axis 3: Cost predictability

• Need to process accounting at a fixed rate → Lightsail Containers
• Pay-as-you-go while minimizing absolute spend → Cloud Run or Lambda
• Scale specs up with an emphasis on stability → ECS/Fargate

The biggest pitfall in any migration is costs surging unexpectedly on the target platform. Always treat the last 30 days of invoices from your source environment as a baseline and run estimates for two to three scenarios using the target platform's pricing calculator.

---

Executing the migration project: Staying safe across three phases

Migrating away from App Runner is not merely a technical replacement; it is a project that encompasses transferring operational processes. Following these three phases will keep execution smooth.

Phase 1: Assessment (1–2 weeks)

• Audit existing App Runner services: Number of services, CPU/memory configurations, connected resources, CI/CD hooks, custom domains, and SSL certificates.
• Select migration targets: Pick primary and secondary options among the four candidates using the three axes above.
• Risk assessment: Database connectivity, static IP requirements, cold-start tolerance, and log retention requirements.

For deliverables in the assessment phase, a 1–2 page document contrasting the current architecture against the target architecture is sufficient. Services you are uncertain about at this stage (such as batch jobs run only at month-end) should be classified as secondary targets and deferred.

Phase 2: Design and implementation (2–4 weeks)

• Adopt IaC: Define infrastructure as code using Terraform or AWS CDK. Building the target environment manually will only repeat the same struggles when the next EOL arrives.
• Redesign CI/CD: When using GitHub Actions, switch to official OIDC integration for operations without static secrets.
• Run staging environments in parallel: Run App Runner and the new environment side-by-side for 1–2 weeks to compare application logs and response latencies.

Pay special attention to App Runner's distinctive environment variable management (configured per auto-scaling configuration) and health check paths/intervals. Failing to replicate identical behavior in the new environment will result in an alert storm during initial deployment.

Phase 3: Cutover and decommissioning (1–2 weeks)

• DNS cutover: Use Route 53 weighted routing to transition traffic incrementally: 10% → 50% → 100%.
• Monitoring period: Run both environments in parallel for at least one week, followed by a two-week observation period.
• Decommission legacy environment: Delete App Runner services and clean up associated records in ACM and Route 53.

While running dual environments temporarily incurs costs, it serves as cheap insurance compared to the downtime losses of an immediate 100% cutover followed by rollback upon discovering an issue.

Three common pitfalls

1. Differences in health check specifications: App Runner defaults to a TCP check against /. ALB and Cloud Run inspect detailed HTTP status codes, requiring you to reimplement /healthz on the application side.
2. Oversights in CI/CD permission design: Many teams forget to configure GitHub Actions OIDC and leave access keys embedded in Secrets indefinitely. Neglecting CI/CD pipelines in this manner is a classic security debt in migration projects, alongside third-party dependency incidents summarized in our 2026 Supply Chain Attack Overview. We recommend taking the migration as an opportunity to rebuild CI/CD permissions around least privilege and short-lived tokens.
3. Log and metric formats: Structured log JSON keys differ slightly between CloudWatch Logs and GCP Cloud Logging. Always factor the effort needed to rebuild dashboards into your estimates.

---

Summary: Three reasons you should act within 2026

AWS App Runner will discontinue onboarding new accounts and services on April 30, 2026, making a migration to ECS/Fargate, Google Cloud Run, AWS Lambda, or Lightsail Containers necessary.

There are three reasons to hurry.

1. Features will no longer be updated: You will not benefit from new AWS regions or deeper ecosystem integrations.
2. The talent market perspective: "App Runner operational experience" will cease to serve as a hiring qualification in a few years, and junior engineers will lose interest.
3. Migration projects consistently take longer than expected: Planning a 4–6 week project and completing it with ample time is a realistic milestone to hit by late 2026.

At GleamHub, we provide end-to-end support for migration projects from App Runner to ECS/Fargate and Cloud Run, spanning auditing existing configurations, architectural design, IaC implementation, CI/CD setup, through to cutover operations. Simultaneously, as highlighted in How Amazon S3 Files Changes SMB File Management, we can propose holistic optimizations including migrating the storage layer to the cloud.

Before defaulting to "it still works, so let's leave it as is" turns into the most expensive choice possible, we strongly recommend initiating at least the assessment phase.