Elastic Beanstalk and App Runner
AWS App Runner is closed to new customers as of 30 April 2026. Existing customers can continue to use it as normal, including creating new services, and AWS continues to fund its security and availability, but no new features are planned. AWS’s recommended destination for both migrations and new workloads is Amazon ECS Express Mode, which provisions an ECS service on Fargate, an Application Load Balancer, auto scaling and networking from a single API call at no additional charge over the underlying resources.
This page is therefore relevant in two situations: an estate that already runs App Runner services alongside Elastic Beanstalk, and a migration off App Runner. For a new container workload, the choice is between Elastic Beanstalk, Amazon ECS (including Express Mode) and Amazon EKS.
How they differ
Section titled “How they differ”Both services are “bring code, get a running web application”. The difference is what the unit of deployment is.
| Elastic Beanstalk | App Runner | |
|---|---|---|
| Unit | An application containing several environments | Independent services |
| Environment management | Built in — dev, staging and prod under one application | Manual — one service per environment |
| Cloning | Environments can be cloned | Each service is created separately |
| Configuration | Per environment, through option settings | Per service |
| Environment separation | First-class | By naming and tags |
| Rollback | Redeploy a stored version, or swap environment URLs | Redeploy a previous image or commit |
| URLs | One per environment, swappable | One per service |
| Underlying resources | Visible and modifiable in your account | Fully abstracted |
Elastic Beanstalk suits applications that need control over the runtime environment, or that carry legacy configuration requirements. App Runner suited teams that wanted no infrastructure surface at all — which is precisely the gap Amazon ECS Express Mode now fills.
Running both in one architecture
Section titled “Running both in one architecture”Where both already exist, they interoperate through ordinary AWS mechanisms rather than anything special. A typical split puts a container front end on App Runner and a JVM back end on Elastic Beanstalk, sharing:
- A database, usually Amazon RDS or Aurora
- A message queue, usually Amazon SQS
- API Gateway in front of one or both
- A VPC, with App Runner reaching private resources through a VPC connector
Networking
Section titled “Networking”Give both sides connectivity into the same VPC and let security groups do the access control:
- Elastic Beanstalk instances sit in private subnets, with a load balancer in public subnets.
- An App Runner VPC connector attaches the service to the same private subnets for outbound traffic to the database and the back end.
- The back-end security group accepts traffic from the App Runner connector’s security group, and the database security group accepts traffic from both application tiers. No CIDR ranges, only security group references.
Authentication between services
Section titled “Authentication between services”Service-to-service calls inside AWS should use IAM, not a bearer token. The calling service assumes a task or instance role, and the request is signed with SigV4 — either through API Gateway with IAM authorisation in front of the callee, or by fronting the back end with an ALB and authorising at the application layer against an identity the caller proves through Cognito or OIDC.
A hand-rolled Authorization: Bearer <token> header between two services in the same account
adds a secret to distribute and rotate, and buys nothing IAM does not already provide.
Observability
Section titled “Observability”Send both services’ logs to CloudWatch Logs, enable AWS X-Ray on both so a single request can be traced end to end, and build one dashboard covering both rather than one per service. A cross-service latency problem is invisible in two separate dashboards.
Migrating off App Runner
Section titled “Migrating off App Runner”AWS documents a blue-green migration to ECS Express Mode using Route 53 weighted routing:
- Record the existing service’s container image, port, environment variables, custom domain and ACM certificate.
- Create an ECS Express Mode service from the same container image.
- Attach the same custom domain to the new service’s load balancer, using the same ACM certificate.
- Shift traffic gradually with weighted DNS records — 10/90, then 25/75, 50/50, 75/25, 100/0 — validating at each step.
- Keep the App Runner service running for a validation period, then remove the DNS record and delete the service.
If the App Runner service deploys from source rather than from an image, a containerisation step has to be added first: a Dockerfile, a build that pushes to Amazon ECR, and a deployment step. That reproduces App Runner’s deploy-on-push behaviour with about twenty lines of CI configuration.
Both services bill for the resources they run rather than for the abstraction. App Runner scales compute down between requests, which suited spiky workloads; Elastic Beanstalk runs the instances you configure, which is cheaper for steady, predictable load. ECS Express Mode inherits the Fargate billing model, and Express Mode itself carries no additional charge.
The recurring mistake when two platforms run side by side is duplicated always-on baseline — two load balancers, two NAT gateways, two minimum instance counts — which can cost more than the workload. Share what can be shared, and consolidate once the migration completes.