iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
ECS Express Mode vs traditional ECS: which should I use with Terraform? Choose Express Mode when you want ECS to create and manage a conventional Fargate web service’s supporting infrastructure through a dedicated Terraform resource. Choose a traditional ECS service when you need more direct control over deployment behavior, load balancing, networking, or the supporting AWS resources. Express Mode reduces infrastructure assembly; it does not remove the need to choose task sizing, IAM permissions, network exposure, health checks, scaling limits, and observability.
This is a configuration comparison, not a report of a completed deployment or performance test. The reproducible test plan below shows how to compare both paths without treating expected defaults as measured results.
What does ECS Express Mode create?
Express Mode is a managed path for deploying containerized web applications on Amazon ECS. AWS describes its purpose as reducing deployment complexity by supplying defaults and automating configuration of supporting services. In Terraform, its dedicated resource is aws_ecs_express_gateway_service.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →The service is not just a single resource in the AWS account. ECS provisions and coordinates supporting infrastructure, including an Application Load Balancer (ALB), target groups, security groups, scaling, logs, and a certificate. You can inspect and access the resulting AWS resources, but direct edits made outside Express Mode can affect ECS’s ability to manage them.
#1 Best Overall
Can I use ECS Express Mode with Terraform?
Yes. The AWS provider documents aws_ecs_express_gateway_service. Its required role arguments are execution_role_arn and infrastructure_role_arn. Depending on the design, the resource also supports settings such as a cluster, CPU and memory, health check, network configuration, scaling, service name, tags, and task role. Consult the current provider documentation for exact syntax and schema before applying a configuration, because provider versions can change.
Understand the three IAM roles
- Infrastructure role: lets ECS create and manage the service’s supporting infrastructure.
- Task execution role: supports task operations such as pulling container images and publishing logs.
- Task role: grants permissions to application code running in the container. It is distinct from the execution role.
Do not grant application permissions through the infrastructure or execution role simply because those roles are required to deploy or start the service. Keep each role scoped to its purpose.
What the traditional Terraform path entails
A traditional configuration generally defines an aws_ecs_service alongside a task definition and whichever supporting resources the architecture needs. These may include networking, load balancing, IAM, logging, and scaling resources. The precise resource set depends on the design; a like-for-like comparison should count only the infrastructure required for the same workload and features.
Rank #2
How do the two Terraform approaches compare?
| Area | ECS Express Mode | Traditional ECS service | What to compare |
|---|---|---|---|
| Terraform surface | aws_ecs_express_gateway_service, plus roles and optional settings |
aws_ecs_service, task definition, and separately configured resources as needed |
Compare configuration size only when both sides provide equivalent features. |
| Infrastructure ownership | ECS provisions and coordinates managed supporting resources | You select and compose the resources in the design | Inspect Terraform plans and state, then confirm the resources in AWS. |
| Ingress and network | ECS manages an ALB and related configuration; subnet choice affects reachability | You configure the selected load-balancer and service-networking design | Check public or internal reachability, subnets, Availability Zones, security groups, DNS, and certificate needs. |
| Deployment | Canary deployment by default; Express Mode manages rollout behavior | Deployment behavior is configured through ECS and related tooling | Inspect rollout settings and rollback signals; do not infer downtime without testing. |
| Scaling | Target tracking with documented defaults and task bounds | Scaling resources and policies are configured as required | Compare metric, target, minimum and maximum tasks, and behavior under load. |
| Flexibility | Some settings, including deployment strategy and load-balancer configuration, cannot be changed through Express Mode | Broader configuration across ECS and related AWS resources | List required capabilities first, then verify they are supported by the current Express Mode and provider interfaces. |
| Cost model | No separate Express Mode fee; underlying AWS resources are billable | Charges come from the underlying resources you configure | Price the complete design, including idle capacity, logs, traffic, and any shared resources. |
What are the defaults and limitations?
AWS documents Express Mode services as Fargate-based. Its documented target-tracking defaults are 60% CPU utilization, a minimum of one task, and a maximum of 20 tasks. These are defaults, not universal recommendations; the maximum can be changed. Choose task bounds and a CPU target for the workload rather than assuming the defaults are suitable.
Express Mode uses canary deployment by default. AWS says the deployment strategy cannot be updated on an Express Mode service. Load-balancer configuration is also handled by ECS and cannot be updated through Express Mode. If either setting is a hard requirement, check the current supported configuration before committing to this path; a traditional service may be the better fit when it needs direct control.
Terraform provider details matter during operations as well as creation. The provider documentation describes importing by service ARN with Terraform 1.5 or later import blocks, and default create, update, and delete timeouts of 30, 30, and 20 minutes. It also notes an IAM policy dependency-ordering concern during deletion. Verify these behaviors against the provider version selected for your project.
Rank #3
How does Express Mode affect networking and cost?
Subnet selection determines the kind of access
If you do not supply subnets, Express Mode uses the default public subnets in the default VPC. AWS’s documented prerequisite for that default VPC is at least two public subnets across two Availability Zones, with at least eight free IP addresses per assigned CIDR block in each subnet.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesWith custom public subnets, Express Mode provisions an internet-facing ALB and assigns public IP addresses to tasks. With private subnets, it provisions an internal ALB. Decide whether the service should be reachable from the internet or only from inside the network before selecting subnets, and verify the associated security-group and routing requirements.
The first Express Mode service in a VPC establishes load-balancer and subnet characteristics that matter to later services. Subsequent services need subnet and Availability Zone compatibility with the existing load balancer. Plan VPC layout before adding services rather than treating each service as an isolated choice. AWS documents that as many as 25 Express Mode services in the same VPC can share an ALB, with additional ALBs as needed; this is a possible resource-sharing arrangement, not a guaranteed per-service saving.
There is no separate Express Mode fee, but the stack is not free
AWS does not charge a separate Express Mode fee, but the underlying Fargate tasks, ALB, CloudWatch logs and metrics, and data transfer can incur charges. A cost comparison must include the whole architecture over a defined time window. Shared load balancers can affect how costs are allocated among services, and a minimum running task can contribute to ongoing cost even when traffic is low. No dollar estimate follows from the configuration defaults alone.
Which approach should you choose?
Choose Express Mode when
- You are deploying a conventional HTTP(S) web application or API on Fargate.
- The managed ALB, certificate, canary rollout, and target-tracking behavior suit the service.
- You want less infrastructure assembly and can work within the supported configuration surface.
Choose traditional ECS when
- You need direct control over deployment strategy or load-balancer configuration.
- Your service depends on network or supporting-resource behavior that Express Mode does not expose.
- You want to compose and own the service’s supporting AWS resources explicitly.
Neither path decides whether a workload is correctly sized, securely exposed, or observable. Those choices remain part of the service design.
How to make a fair Terraform comparison
Use a disposable AWS account and the same region and VPC for both configurations. Define the workload and comparison conditions before deploying so a shorter configuration is not mistaken for a better equivalent architecture.
- Fix the workload inputs. Use the same container image, task CPU and memory, health endpoint, minimum and maximum task counts, logging needs, and intended public or private reachability.
- Record the environment. Note the Terraform and AWS provider versions, AWS region, date, subnet and Availability Zone layout, IAM assumptions, and deployment expectations.
- Build both configurations. Use
aws_ecs_express_gateway_servicefor Express Mode. For the traditional baseline, defineaws_ecs_service, its task definition, and the resources needed to match the same networking, ingress, health-check, scaling, deployment, and logging requirements. - Review plans before applying. Compare Terraform plans and resource ownership. Check which parts Express Mode will manage, which resources the traditional configuration creates directly, and whether the two designs actually meet the same requirements.
- Deploy and inspect. Confirm created resources through Terraform state and AWS interfaces. Check reachability, TLS, health-check behavior, rollout and rollback signals, scaling response, and CloudWatch outputs. Record apply and deletion times only if you measure them; do not treat them as inherent properties of either approach.
- Remove both stacks and compare cost. Delete the disposable resources, check for leftovers, and use actual billing data or a clearly defined pricing estimate for the same observation window. Account for shared resources, logs, traffic, and idle tasks.
AWS recommends right-sizing, load testing, bounded scaling, and meaningful lightweight health checks. For production after initial testing, AWS guidance recommends three Availability Zones; adapt that guidance to the application’s availability requirements and regional design.
Keep resource ownership clear after deployment
Express Mode’s underlying resources are accessible, but making direct changes to them through another AWS interface can affect ECS’s management behavior. Keep Terraform ownership clear and avoid split-brain edits to resources managed by the Express service. When a change is needed, use the supported Express Mode configuration surface or deliberately move to an ownership model that can manage the desired settings.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
