AWS 159: Amazon ECS Express Mode and Elastic Beanstalk
Why this lesson matters
Compare the current guided ECS Express Mode experience with Elastic Beanstalk, and do not direct new customers to the closed App Runner onboarding path.
Both services reduce setup decisions while leaving visible billed infrastructure in your account. They package operational defaults, not free infrastructure or a transfer of application responsibility. Current new workloads must also account for AWS App Runner's closure to new customers and AWS's migration direction toward ECS Express Mode.
What you will be able to do
By the end, you can:
- explain amazon ecs express mode and elastic beanstalk in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Compare the current guided ECS Express Mode experience with Elastic Beanstalk, and do not direct new customers to the closed App Runner onboarding path. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon ECS Express Mode and Elastic Beanstalk. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon ECS Express Mode and Elastic Beanstalk. |
| Cost model | Fargate tasks, load balancer, public IPv4, logs, builds, data transfer, and Beanstalk underlying resources can charge even when the orchestration experience has no separate fee. |
| Safe rejection rule | Avoid teaching App Runner as available to a new personal account after March 31, 2026 or assuming guided setup removes infrastructure cost. |
How the request flows
+-------------------------------+
| Application source or image |
+-------------------------------+
|
v
+---------------------------------+
| Guided platform configuration |
+---------------------------------+
|
v
+------------------------------+
| ECS or Beanstalk resources |
+------------------------------+
|
v
+----------------------------------------------+
| URL, health, deployment, and cost evidence |
+----------------------------------------------+For Amazon ECS Express Mode and Elastic Beanstalk, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon ECS Express Mode and Elastic Beanstalk. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon ECS Express Mode and Elastic Beanstalk. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use a guided platform when speed and managed defaults matter and generated-resource ownership is understood. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid teaching App Runner as available to a new personal account after March 31, 2026 or assuming guided setup removes infrastructure cost. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
ECS Express Mode
An Express Mode service starts with a container image, task execution role and infrastructure role. ECS creates/configures an ECS service on Fargate, task definition, networking/security groups, HTTPS ALB/listener/target group, AWS-provided domain/certificate, deployment, auto scaling, log group and alarms. Compatible services with the same network configuration can share ALB infrastructure under current rules. Resources remain visible and customizable, which provides an escape path but also creates drift risk when engineers edit generated components directly.
Use it for stateless HTTP web apps/APIs when the standard topology fits and the team wants a short path to production-grade defaults. Inspect public versus private exposure, image digest, task/application roles, min/max tasks, three-AZ recommendation, health path, canary behavior, shared-ALB blast radius, secrets and every generated resource. There is no Express Mode service fee, but Fargate, ALB, logs/metrics, public IPv4/data transfer and supporting services charge even at low traffic. Current custom-task-definition support expands flexibility but means all custom sidecars/runtime settings become your responsibility.
Elastic Beanstalk
An application groups application versions; an environment runs one version on a selected managed platform branch/version. Web-server environments commonly create EC2 Auto Scaling, load balancing, security groups and monitoring; worker environments process SQS. Beanstalk orchestration is free, but every generated resource charges. The application bundle, .ebextensions/platform hooks, saved configuration and environment properties must be versioned; secrets should come from a secret service rather than source bundles.
Platform is OS + runtime + web/app server + Beanstalk components. Track supported/deprecated/retired branches and monthly/security releases. Routine same-branch updates and managed updates differ from major/OS migration, for which blue/green environment cloning, test and CNAME swap is safer. Deployment policies - All at once, rolling, rolling with additional batch, immutable and traffic splitting as supported - trade capacity, speed, cost and rollback. “Green” enhanced health reflects agents/load balancer signals, not business correctness.
Choose Beanstalk for supported language/Docker web/worker platforms when teams want EC2 access/configurability but not direct orchestration assembly. Choose Express for container-first stateless HTTPS with ECS/Fargate as the transparent foundation. Choose full ECS when topology, networking, service mesh, multiple containers, deployment or scaling needs exceed Express defaults. Do not direct a new customer to App Runner; existing users require a dated migration inventory and supported transition, not sudden deletion.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open ECS, Express Mode services, and Elastic Beanstalk Environments; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws ecs list-clusters --output table
aws ecs list-services --cluster replace-with-express-mode-cluster --output table
aws elasticbeanstalk describe-environments --query 'Environments[].{App:ApplicationName,Environment:EnvironmentName,Status:Status,Health:Health,Tier:Tier.Name}' --output tableExpected interpretation
Express Mode creates an ordinary ECS service and supporting infrastructure such as Fargate, load balancing, TLS, scaling, monitoring, and networking. Beanstalk environment health still needs application evidence.
Practical work
Compare a source or container web service on ECS Express Mode and Elastic Beanstalk. Record generated resources, customization boundary, deployment, scaling, health, logs, rollback, cost, and migration escape path.
Test bad health path, failed image pull/bundle, secret denial, min-task/ASG capacity, bad canary, platform retirement, shared-ALB dependency, one-AZ loss and teardown with retained S3/log/version artifacts. Model idle ALB/Fargate versus EC2/ALB and operational labor. Add an App Runner migration map from source/image, environment, VPC connector, autoscaling, domain/certificate, observability and IAM to Express/full ECS equivalents.
Diagnose this topic from its own evidence
For Express Mode, open the backing ECS deployment/events, task stop reason, target health, scaling and generated resource inventory. For Beanstalk, correlate environment events, deployment logs, EC2/ASG/ALB health, platform hooks and application logs. A top-level unhealthy state is a summary, not cause. If deletion leaves cost, inspect underlying stacks, load balancers, NAT/public IP, log groups, application versions/S3 bundles and retained policies before claiming cleanup.
Cost and cleanup
Fargate tasks, load balancer, public IPv4, logs, builds, data transfer, and Beanstalk underlying resources can charge even when the orchestration experience has no separate fee.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Compare the current guided ECS Express Mode experience with Elastic Beanstalk, and do not direct new customers to the closed App Runner onboarding path.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon ECS Express Mode and Elastic Beanstalk.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon ECS Express Mode and Elastic Beanstalk.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid teaching App Runner as available to a new personal account after March 31, 2026 or assuming guided setup removes infrastructure cost.
- Which cost dimensions and retained resources need an owner?
Expected direction: Fargate tasks, load balancer, public IPv4, logs, builds, data transfer, and Beanstalk underlying resources can charge even when the orchestration experience has no separate fee.
Lesson acceptance
Pass when the learner maps both abstractions to every generated resource and owner, chooses from workload/customization evidence, designs deploy/health/scale/upgrade/rollback, prices idle infrastructure and provides complete teardown/migration. Fail if Express/Beanstalk are called free/serverless without qualification, generated resources are ignored, retired platforms remain, or new users are sent to closed App Runner onboarding.