🧐 ECS Express Mode vs Traditional ECS: A Hands-on Comparison with Terraform

Hola Amigos 👋 Welcome to the world of Cloud and Automation! AWS launched ECS Express Mode in late 2025, and in today’s blog, we will understand how it compares to traditional AWS ECS. We will use a basic Flask portfolio website with three versions to illustrate how both approaches handle infrastructure operations with Terraform. Prerequisites Before we start, make sure you have the following requirements met on your system: - Terraform: Installed and configured with an AWS IAM account that has AdministratorAccess . This is just for the sake of the blog and is not recommended in a production environment. Always follow the principle of least privilege. - Basic understanding of Python and Docker, along with AWS ECS. Once the above requirements are met, we are good to go with our project! What is ECS Express Mode? On November 21, 2025, AWS introduced ECS Express Mode, allowing developers to launch containerized applications with secure HTTPS endpoints within minutes. It is similar to traditional ECS, but without a lot of the manual configuration required for things like load balancers, target groups, scaling policies, and more. By providing your container image and an infrastructure role, you can create a complete ECS Fargate-based deployment. Express Mode automatically creates resources such as a Virtual Private Cloud (VPC), subnets, security groups, a load balancer with listener rules, HTTPS configuration, auto-scaling policies, metrics, alarms, and health checks. The best part is that there is no additional charge for using ECS Express Mode itself. You pay for the AWS resources that are provisioned and used by your application. Another interesting feature is that a single Application Load Balancer can be shared by up to 25 Express Mode services, which can help reduce the cost of running multiple services. Practical Demonstration We are going to use a Flask portfolio website with three versions: - v1 - Foundation - v2 - Advanced - v3 - Production We will deploy the application using both a traditional ECS architecture and ECS Express Mode and see the difference between them. To get started, clone the repository using the following command: git clone https://github.com/Pravesh-Sudha/terra-projects.git Navigate inside the ecs-express directory. Inside it, you will find two directories: ecs-express/ ├── traditional/ └── express/ Let's start with the traditional approach. Traditional ECS Navigate inside the traditional directory. Here, you will find a bunch of Terraform configurations for ECS: - main.tf - Specifies AWS as the cloud provider. - values.tf - Gets the default VPC and its subnets, along with a security group with port5000 open. Our Flask portfolio runs on this port. - ecs.tf - Creates our ECS cluster, required IAM roles and policy attachments, task definition, and ECS service. - get_ip.sh - A shell script that uses AWS CLI commands to retrieve the public IP of the task's network interface and generates the URL with port5000 . One thing to note here is that with the traditional approach, we have already created quite a few resources, but we still have only a bare-minimum infrastructure rather than a recommended production-grade setup. For example, we haven't configured things like an Application Load Balancer, HTTPS, production-grade monitoring, alarms, or scaling policies. A note about architecture For this project, my Docker image is built for the AMD64 architecture. If you want to try another Docker image, make sure it is also built for AMD64. If you are building the image on an ARM64 machine, such as an Apple Silicon Mac, you can build it for AMD64 by specifying the target platform in your Docker build command. If you want to use an ARM64 image instead, you will need to make sure the ECS task configuration supports that architecture. Getting ARM64 working with ECS Express Mode can be more complicated depending on the configuration, so for this demonstration, I am keeping things simple and using AMD64. Deploying Traditional ECS To apply the configuration, navigate inside the directory and run: cd ecs-express/traditional terraform init terraform plan terraform apply After a minute or two, the infrastructure should be up and running. To get the URL of the website, use the following commands: chmod u+x get_ip.sh ./get_ip.sh Open the URL in your browser, and you should see the application up and running. Updating the Application Version Now imagine you want to update your application to a newer version. We can do this simply by updating the Docker image version inside the ECS task definition. For this demonstration, I initially deployed v2 and then switched the application back to v1. This was actually a small mistake while capturing the screenshots, but it also demonstrates something useful: the infrastructure doesn't really care whether you're moving forward or backward between image tags - Terraform will deploy the version you specify. For example: image = "pravesh2003/flask-portfolio:v1" Now apply the configuration: terraform apply --auto-approve Once the deployment is completed, use the shell script again: ./get_ip.sh Head over to the URL, and you should see the updated version of your application. ECS Express Mode With the traditional approach, we created a bare-minimum infrastructure for hosting our application. And even after writing quite a bit of Terraform code, we are still missing production-oriented features such as: - Metrics - Alarms - Scaling policies - Application Load Balancer - Secure HTTPS connection - Target groups - Health checks But this is where ECS Express Mode comes in. To see it in action, head over to the express directory. You will find the following Terraform configurations: - provider.tf - Specifies that we are using AWS as our cloud provider. - express.tf - Contains theaws_ecs_express_gateway_service resource. This is where most of the Express Mode configuration happens. - vars.tf - Contains variables such as the default VPC and its subnets. - iam.tf - Contains the execution role and infrastructure role required by Express Mode. - outputs.tf - Provides useful outputs, including the application URL. Deploying ECS Express Mode To apply the configuration, run: cd ecs-express/express terraform init terraform plan terraform apply This deployment takes a little longer than the traditional deployment. In my case, it took around 8-10 minutes. Once the deployment is complete, Terraform will provide the URL where the application is live. Open it in your browser, and you should see the same Flask portfolio application running through ECS Express Mode. Updating the Application Version Just like with traditional ECS, we can update the application without rebuilding the infrastructure. Go to express.tf and change the Docker image version. For example: image = "pravesh2003/flask-portfolio:v3" Then simply run: terraform apply ECS Express Mode will handle the deployment of the new version. This gives us a simple progression: v1 → v2 → v3 Foundation → Advanced → Production And because the application itself changes between these versions, we can actually see the deployment update in the browser. Traditional ECS vs ECS Express Mode Now that we have deployed the same application using both approaches, let's compare them. With traditional ECS, we had to explicitly configure the different pieces required to run our application. With Express Mode, we only needed to create an aws_ecs_express_gateway_service , provide the required configuration, and let Express Mode take responsibility for much of the underlying infrastructure. Express Mode provisions and manages supporting components such as the Application Load Balancer, target group, security groups, HTTPS configuration, scaling policies, metrics, alarms, and health checks. On top of that, we get a much higher level of abstraction over the infrastructure, which makes the architecture significantly simpler. And this is where the main difference becomes clear: Traditional ECS gives you more control, while ECS Express Mode gives you more abstraction. My Personal Verdict Even though I think ECS Express Mode is better than traditional ECS when it comes to simplicity and ease of deployment, especially for beginners, I would still recommend learning and using traditional ECS first if your goal is to properly understand ECS. With traditional ECS, you are forced to understand the underlying components and how they work together. You learn about task definitions, services, networking, security groups, load balancers, target groups, scaling, and all the other pieces that make an ECS deployment work. Once you understand those fundamentals, Express Mode becomes much easier to appreciate because you know what it is actually abstracting away. So, for me: Learning ECS → Traditional ECS 🧠 Quick and simplified deployments → ECS Express Mode 🚀 Cleanup Once you are done experimenting with the project, make sure to delete the resources to avoid unwanted AWS costs. First, destroy the Express Mode deployment: cd ecs-express/express terraform destroy --auto-approve Then destroy the traditional ECS deployment: cd ../traditional/ terraform destroy --auto-approve Make sure both deployments are destroyed successfully before finishing. Conclusion ECS Express Mode is an interesting addition to the ECS ecosystem because it changes how much infrastructure you need to think about when deploying a containerized application. With traditional ECS, you have much more control, but that also means more configuration and more AWS components to understand. With Express Mode, AWS takes care of a large portion of that infrastructure for you, allowing you to focus more on your application rather than wiring everything together. After building the same Flask application with both approaches, my biggest takeaway is that Express Mode isn't really replacing traditional ECS - it is providing another level of abstraction on top of it. If you are new to ECS, Express Mode can be a great way to ge