DEV Community

Cover image for Simplifying Container Ops: What ECS Express Mode Brings to the Table
AWS Community Builders profile image Tanushree Aggarwal
Tanushree Aggarwal for AWS Community Builders

Posted on

Simplifying Container Ops: What ECS Express Mode Brings to the Table

#aws #cloud #containers #ecs

Introduction

In an era where shipping software often feels like wrestling a hydra of YAML files, security groups, load balancers, and networking rules, Amazon ECS Express Mode arrives like a well-timed plot twist. Announced in November-2025, it promises what developers have wanted for a decade: production-grade containers without the ceremony, the toil, or the infrastructure-induced existential dread.

ECS Express Mode takes the idea of “simple deployment” and pushes it to its logical extreme. Bring a container image and two IAM roles, and with one command or a casual click, AWS conjures an entire, operationally sound architecture. We’re talking Fargate tasks, VPC wiring, security groups, an Application Load Balancer with proper health checks, autoscaling that isn’t an afterthought, and even a ready-to-use domain or public URL.

Unlike many “easy mode” cloud abstractions, Express Mode doesn’t trap you in a sandbox! All the resources it creates live fully within your AWS account, totally visible, totally tweakable.

That's quite a big sell. Isn't it?
In today's blog we are going to cover the first impressions of this offering and see if it really lives up to the hype!

Proposed Demo Application

The project demonstrates a complete ECS Express Mode workflow from containerization to deployment and cleanup using a simple Express.js web server.

Core Functionality

Web Server:
• Runs on port 3000 (configurable via PORT environment variable)
• Serves JSON responses instead of HTML pages

Two Endpoints:
• GET / - Returns a JSON object with:
• Welcome message ("ECS Express Mode Test")
• Current timestamp
• Container hostname (useful for identifying which container instance is responding)
• GET /health - Health check endpoint returning {"status": "healthy"}

Purpose

This is a demonstration application designed to:
• Show how to containerize a Node.js app for ECS
• Test ECS Express Mode deployment capabilities
• Provide observable outputs (timestamp, hostname) to verify the service is running
• Include health checks for container orchestration

Technical Stack

• Runtime: Node.js 18
• Framework: Express.js web framework
• Container: Dockerized for deployment on AWS Fargate
• Logging: Outputs to CloudWatch via ECS logging configuration

The application itself is intentionally simple - it's meant to be a working example of deploying containerized applications using ECS Express Mode rather than a complex business application. The real value is
in the deployment infrastructure and automation scripts that surround it.

Files created:

  1. app.js - Simple Express.js web server with two endpoints:
    • / - Returns JSON with message, timestamp, and hostname
    • /health - Health check endpoint returning status

  2. package.json - Node.js project configuration defining dependencies (Express.js) and start script

  3. *Dockerfile * - Container build instructions:
    • Uses Node.js 18 Alpine base image
    • Installs dependencies and copies application code
    • Exposes port 3000 and runs the app

  4. task-definition.json - ECS task configuration specifying:
    • Fargate compatibility with 256 CPU/512MB memory
    • Container image location and port mapping
    • CloudWatch logging configuration
    • Task execution role for permissions

  5. deploy.sh - Automated deployment script that:
    • Creates ECR repository
    • Builds and pushes Docker image
    • Updates task definition with account details
    • Creates ECS cluster and service with Express Mode
    • Sets up CloudWatch logging

  6. • test-express-mode.sh - Testing script that validates:
    • Service status and task counts
    • Task details and network configuration
    • Auto-scaling settings
    • Recent service events

  7. cleanup.sh - Resource cleanup script that:
    • Scales service to 0 and deletes it
    • Removes ECS cluster
    • Deletes ECR repository

The link to this code is provided below, so you can easily follow along in your personal AWS account.

Prerequisites ⚠

  1. AWS CLI configured
  2. Docker installed

Cost Warning 📊💰

This demo could cost you $0.05-0.10 per hour apprx. while running (Fargate pricing for 0.25 vCPU, 0.5 GB memory).

Breakdown of IAM Permissions and Policies used in this demo 🔏

Primary IAM Role
ecsTaskExecutionRole - This is the main IAM role referenced in the task definition that ECS Fargate uses to:

• Pull container images from ECR
• Write logs to CloudWatch
• Manage task lifecycle
Enter fullscreen mode Exit fullscreen mode

Required Permissions
The demo requires your AWS user/role to have permissions for:

ECR (Elastic Container Registry):
• ecr:CreateRepository
• ecr:GetAuthorizationToken
• ecr:BatchCheckLayerAvailability
• ecr:GetDownloadUrlForLayer
• ecr:BatchGetImage

ECS (Elastic Container Service):
• ecs:CreateCluster
• ecs:CreateService
• ecs:RegisterTaskDefinition
• ecs:DescribeTasks
• ecs:ListTasks

CloudWatch Logs:
• logs:CreateLogGroup
• logs:DescribeLogStreams

EC2 (for networking):
• ec2:DescribeVpcs
• ec2:DescribeSubnets
• ec2:DescribeSecurityGroups
• ec2:DescribeNetworkInterfaces
• ec2:AuthorizeSecurityGroupIngress

STS (Security Token Service):
• sts:GetCallerIdentity
Enter fullscreen mode Exit fullscreen mode

Task Execution Role Permissions
The ecsTaskExecutionRole needs the AWS managed policy:

• AmazonECSTaskExecutionRolePolicy
This policy provides the minimum permissions required for ECS tasks
to pull images and write logs.
Enter fullscreen mode Exit fullscreen mode

Well-Architected Framework 🔒🛡️⚡💰♻️

This demo incorporates basic elements from well-architected pillars as listed below. For a production implementation, you would want to enhance security (eg: secrets management, network segmentation) and reliability (multi-AZ deployment, backup strategies).

🔧 Operational Excellence:
• CloudWatch logging configuration for monitoring
• Health check endpoint (/health) for service monitoring
• Automated deployment scripts for consistent operations

Security🔒 :
• IAM execution role for task permissions
• VPC networking with security groups
• Container isolation through Fargate

Reliability🛡️ :
• ECS service with desired count for high availability
• Auto-scaling capabilities (referenced in test script)
• Health checks for automatic recovery

Performance Efficiency⚡ :
• Fargate serverless compute (no infrastructure management)
• Right-sized CPU/memory allocation (256 CPU, 512 MB memory)
• Express Mode optimizations for faster startup

Cost Optimization💰 :
• Fargate pay-per-use model
• Minimal resource allocation
• Auto-scaling to match demand

Sustainability♻️ :
• Serverless architecture reduces idle resources
• Container efficiency
• Right-sizing to minimize waste

Implementation ✍

Step 1: Update Configuration

Before deploying, we will need to update the subnet and security group IDs in deploy.sh script.

For this, we will fetch our VPC information from our AWS account.

# Find your default VPC
aws ec2 describe-vpcs --filters "Name=is-default,Values=true" --query 'Vpcs[0].VpcId' --output text

# Find subnets in your VPC (replace vpc-xxxxx with your VPC ID)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-xxxxx" --query 'Subnets[0].SubnetId' --output text

# Find default security group
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=vpc-xxxxx" "Name=group-name,Values=default" --query 'SecurityGroups[0].GroupId' --output text
Enter fullscreen mode Exit fullscreen mode

• Replace subnet-xxxxxx and sg-xxxxxx in the deploy script with actual values from your VPC
• Ensure your AWS credentials have the necessary ECS, ECR, and CloudWatch permissions

Edit deploy.sh and replace:

  • subnet-xxxxxx with your actual subnet ID
  • sg-xxxxxx with your actual security group ID

make sure that the Security Group has an inbound rule for port 3000

Step 2: Deploy the Application

Run ./deploy.sh to deploy your Express Mode service.
This will:

  • Create a container registry
  • Build and upload your app
  • Create an ECS cluster
  • Start your service

Check in the AWS Management Console:

It worked! And just like that, our cluster is running!

Step 3: Test the Deployment

Use ./test-express-mode.sh to validate the deployment.



Step 4: Find Your Application URL 

# Get task details to find public IP
aws ecs describe-tasks --cluster express-mode-cluster --tasks $(aws ecs list-tasks --cluster express-mode-cluster --service-name express-mode-service --query 'taskArns[0]' --output text) --query 'tasks[0].attachments[0].details[?name==`networkInterfaceId`].value' --output text

# Get public IP (replace eni-xxxxx with the network interface ID from above)
aws ec2 describe-network-interfaces --network-interface-ids eni-xxxxx --query 'NetworkInterfaces[0].Association.PublicIp' --output text
Enter fullscreen mode Exit fullscreen mode

Visit http://YOUR-PUBLIC-IP:3000 in your browser.

Perfect! It loads!

Step 5: Clean Up Resources

Run ./cleanup.sh when done testing to avoid further billing on resources.

./cleanup.sh
Enter fullscreen mode Exit fullscreen mode

Github Repository

GitHub logo aggarwal-tanushree / amazon-ecs-express-mode-demo

The project demonstrates a complete ECS Express Mode workflow from containerization to deployment and cleanup using a simple Express.js web server

ECS Express Mode Demo - Complete Beginner's Guide

What is ECS Express Mode?

Amazon ECS Express Mode is a simplified way to run containerized applications without managing servers. It automatically handles scaling, networking, and infrastructure.

Prerequisites

1. Install Required Tools

# Install AWS CLI
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# Install Docker
sudo apt update
sudo apt install docker.io
sudo usermod -aG docker $USER
Enter fullscreen mode Exit fullscreen mode

2. Configure AWS Credentials

aws configure
Enter fullscreen mode Exit fullscreen mode

Enter your:

  • AWS Access Key ID
  • AWS Secret Access Key
  • Default region (e.g., us-east-1)
  • Output format (json)

3. Get Your VPC Information

# Find your default VPC
aws ec2 describe-vpcs --filters "Name=is-default,Values=true" --query 'Vpcs[0].VpcId' --output text
# Find subnets in your VPC (replace vpc-xxxxx with your VPC ID)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-xxxxx" --query 'Subnets[0].SubnetId' --output text

# Find default security group
aws ec2 describe-security-groups
…
Enter fullscreen mode Exit fullscreen mode
View on GitHub

Amazon ECS v/s Amazon ECS Express Mode

Key Differences 🚀⭐

Feature / Aspect Traditional Amazon ECS Amazon ECS Express Mode
Networking Setup Manual VPC, subnet, and security group configuration Automatic networking setup
Load Balancing Must create & manage ALB/NLB separately Built-in load balancing (no ALB/NLB required)
Service Discovery Manual configuration required Automatic service discovery
Complexity Requires deeper networking & infra knowledge Minimal configuration, simplified deployment
Control Level High granular control Abstracts away infrastructure complexity

Benefits of Express Mode 💪

Benefit Category Advantages of ECS Express Mode
Faster Time to Market Deploy in minutes; no custom networking; automatic scaling
Reduced Ops Overhead AWS manages infra; auto security groups; built-in logging/observability
Cost Optimization No idle load balancers; automatic right-sizing; no extra networking fees
Developer-Friendly Focus on code; simplified CLI; less AWS expertise needed

When to Use Each 💡

Use Case Type Use Express Mode For… Use Traditional ECS For…
Application Complexity Simple apps, APIs, prototypes Complex multi-tier architectures
Networking Requirements Standard networking Custom networking needs
Team Skill Level Teams new to AWS/containers Teams with advanced AWS/networking expertise
Security Requirements Standard default configurations Advanced/custom security configurations
Load Balancer Needs Basic built-in LB is sufficient Need advanced ALB/NLB features

Express Mode essentially provides a "serverless container" experience similar to how Lambda abstracts server management, but for containerized applications that need more control than Lambda functions provide.

Conclusion ✍

Amazon ECS Express Mode feels like AWS acknowledging a universal truth: most developers want to build features, not infrastructures . By letting teams deploy robust, scalable containerized services in minutes instead of weeks, AWS has delivered something refreshingly pragmatic!

For those building microservices, internal tools, or rapid prototypes, or simply looking to ship faster — Express Mode is a powerful ally.

Whether you’re racing a deadline, experimenting with a new idea, or assembling a constellation of microservices, Express Mode isn’t just a convenience — it’s a genuine accelerator.

Have you tried this offering yet? Let me know your thoughts in the comments!

References 📝

https://aws.amazon.com/about-aws/whats-new/2025/11/announcing-amazon-ecs-express-mode/

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-overview.html

Bonus 🔓

Install Required Tools 

##### Install AWS CLI
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

##### Install Docker
sudo apt update
sudo apt install docker.io
sudo usermod -aG docker $USER
Enter fullscreen mode Exit fullscreen mode

Configure AWS Credentials 

aws configure

Enter your:
- AWS Access Key ID
- AWS Secret Access Key
- Default region (e.g., us-east-1)
- Output format (json)
Enter fullscreen mode Exit fullscreen mode

Troubleshooting

Here are some troubleshooting steps in case you run into issues

"Permission denied" errors:

sudo chmod +x *.sh
Enter fullscreen mode Exit fullscreen mode

"No default VPC" error:
Create a VPC or use an existing one's subnet/security group IDs.

Container won't start:
Check CloudWatch logs:

aws logs describe-log-streams --log-group-name "/ecs/express-mode-test"
Enter fullscreen mode Exit fullscreen mode

Can't access the application:
Ensure your security group allows inbound traffic on port 3000:

aws ec2 authorize-security-group-ingress --group-id sg-xxxxx --protocol tcp --port 3000 --cidr 0.0.0.0/0
Enter fullscreen mode Exit fullscreen mode

Next Steps

  1. Modify app.js to add new features
  2. Update the container and redeploy
  3. Explore ECS auto-scaling features
  4. Add a load balancer for production use

Top comments (0)