The modernization of application delivery has shifted heavily toward containerization, and Amazon Elastic Container Service (ECS) stands as a primary pillar for managing these workloads within the AWS ecosystem. When implementing ECS, architects face a fundamental decision regarding the compute substrate: the EC2 launch type versus the Fargate serverless launch type. While Fargate offers a "hands-off" experience, the EC2 launch type provides an unparalleled level of granularity and control over the underlying infrastructure.

Using Terraform (or its open-source fork, OpenTofu), engineers can codify this infrastructure, ensuring that complex networking, auto-scaling groups, and container orchestration settings are reproducible and version-controlled. This guide provides a deep dive into the technical implementation of an ECS cluster utilizing the EC2 launch type, detailing the architectural components required to move from a blank slate to a production-ready container environment.

The Strategic Choice: EC2 vs. Fargate Launch Types

Choosing between EC2 and Fargate is not merely a matter of preference but a decision based on operational overhead, cost structures, and the specific requirements of the application.

The EC2 launch type puts the operator in the driver's seat. In this model, you provision and manage the underlying EC2 instances that form the capacity for your cluster. This means you have direct access to the operating system, the ability to customize instance types (such as choosing GPU-optimized instances for ML workloads), and full control over networking and scaling policies. This is particularly advantageous for long-running workloads where the cost of reserved or spot instances can significantly undercut the premium paid for serverless abstraction.

Conversely, Fargate is designed for teams that want to eliminate the "undifferentiated heavy lifting" of server infrastructure. It abstracts the EC2 layer entirely, allowing developers to define CPU and memory at the task level without ever seeing a virtual machine. While this reduces operational overhead, it removes the ability to tune the underlying kernel or use specific instance families.

The following table delineates the primary technical and operational differences between these two launch types.

Architectural Blueprint for ECS on EC2

Deploying an ECS cluster on EC2 is not a standalone action; it requires a cohesive network and compute ecosystem to function securely and reliably. A production-grade architecture typically involves several interdependent layers.

The Networking Foundation (VPC Setup)

Before a single container can run, a Virtual Private Cloud (VPC) must be established. The network acts as the isolation boundary for the cluster. A robust setup includes:
- Subnets: Distribution across multiple Availability Zones (AZs) to ensure high availability.
- Security Groups: These act as virtual firewalls. Specific rules must be configured to allow incoming traffic from the internet to the load balancer and internal traffic between the load balancer and the EC2 instances.
- Route Tables and Internet Gateways: These enable the EC2 instances to communicate with the outside world and allow the Application Load Balancer (ALB) to receive external requests.

The Compute Layer (EC2 Setup)

The "brains" of the EC2 launch type are the EC2 instances themselves, which are managed via Auto-Scaling Groups (ASG).
- Auto-Scaling Groups: These ensure that the cluster maintains the desired number of healthy instances. If an instance fails, the ASG replaces it automatically.
- Launch Templates: These define the AMI (Amazon Machine Image) used—which must include the ECS agent—as well as the instance type and IAM roles.
- ECS Capacity Providers: These bridge the gap between the ECS service and the ASG, allowing the cluster to scale its compute capacity based on the resource requirements of the running tasks.

Traffic Management and Service Discovery

To make the containers accessible to users, an Application Load Balancer (ALB) is deployed. The ALB sits in front of the EC2 instances across multiple availability zones. When a request hits the ALB, it distributes the traffic across the running containers based on the target group's health checks. While a load balancer is technically optional for a basic ECS service, it is mandatory for real-world workloads to ensure stability, as accessing containers via raw EC2 IP addresses is unsustainable due to the dynamic nature of container deployment and instance recycling.

Terraform Implementation Logic

Implementing this architecture in Terraform requires a modular approach to ensure that resources are created in the correct order of dependency.

Defining the Task Definition

The aws_ecs_task_definition resource is the blueprint for your application. It is the most critical piece of the configuration because it tells ECS exactly how to run your container. Within the task definition, you specify:
- The Docker image to be pulled (typically from Amazon ECR).
- CPU and memory allocations for the container.
- Port mappings (linking the container port to the host port).
- IAM execution roles that allow the ECS agent to pull images and write logs to CloudWatch.
- The operating system platform and logging configurations.

```hcl

Example structure for an ECS Task Definition

resource "awsecstaskdefinition" "apptask" {
family = "my-app-task"
networkmode = "bridge"
requirescompatibilities = ["EC2"]
cpu = "256"
memory = "512"

container_definitions = jsonencode([
{
name = "app-container"
image = "my-ecr-repo/app:latest"
cpu = 256
memory = 512
essential = true
portMappings = [
{
containerPort = 80
hostPort = 80
}
]
}
])
}
```

Orchestrating the ECS Service

Once the task definition is set, the aws_ecs_service resource is used to maintain the desired number of instances of that task. The service ensures that if a container crashes, it is automatically restarted on a healthy EC2 instance. The service links the task definition to the load balancer's target group, enabling the ALB to route traffic to the newly created containers.

Managing the Cluster and Capacity

The aws_ecs_cluster resource acts as the logical grouping of the EC2 instances. When using the EC2 launch type, the cluster doesn't "own" the instances; rather, the instances join the cluster via the ECS agent installed on the AMI. By linking the cluster to a Capacity Provider, Terraform can automate the scaling of the underlying EC2 fleet to match the demand of the services.

Verification and Testing the Deployment

Once the Terraform configuration is applied via terraform apply, the infrastructure must be validated through the AWS Management Console to ensure the desired state matches the actual state.

Networking and Security Validation

The first step is to verify the VPC environment. Users should navigate to the VPC dashboard to confirm:
- The existence of the VPC and associated subnets across the specified Availability Zones.
- Correct routing through the Internet Gateway.
- Security group rules that explicitly allow traffic on the required ports (e.g., port 80 for HTTP or port 22 for SSH).

Compute and Scaling Validation

Next, verify the health of the compute fleet:
- EC2 Dashboard: Ensure that the specified number of EC2 instances are in the running state and are associated with the correct subnets and security groups.
- Auto-Scaling Groups: Confirm that the ASG is healthy and that the desired, minimum, and maximum instance counts match the Terraform configuration.

Load Balancer and Container Health

Finally, validate the traffic flow:
- EC2 > Load Balancers: Check that the Application Load Balancer is active and associated with the correct VPC subnets.
- ECS Console: Navigate to the ECS cluster and verify that the services are running and that the tasks are successfully placed on the EC2 instances. If tasks are stuck in PENDING, it often indicates a lack of available CPU/Memory on the EC2 instances or a mismatch in the placement constraints.

Operational Considerations and Lifecycle Management

Managing an ECS cluster on EC2 introduces specific operational challenges that are not present in Fargate.

Task Placement Strategies and Constraints

Since you manage the instances, you can control exactly where containers land. ECS allows you to define:
- Placement Strategies: For example, binpack to maximize resource utilization or spread to distribute tasks across different availability zones for high availability.
- Placement Constraints: Ensuring that tasks only run on instances with specific attributes (e.g., specific instance types or operating system versions).

Resource Cleanup and Destruction

When decommissioning the environment, Terraform simplifies the process via terraform destroy. However, specific AWS protections can interfere with this. For instance, if "termination protection" is enabled on the EC2 instances, the Terraform destroy command will fail to remove the instances. In such cases, the instances must be stopped or termination protection must be disabled manually before the Terraform state can be fully cleaned.

OpenTofu as an Alternative

For organizations seeking a fully open-source alternative to HashiCorp's Terraform, OpenTofu is a viable option. Forked from Terraform version 1.5.6, OpenTofu maintains compatibility with existing Terraform concepts while expanding the ecosystem for community-driven development. It can be used to manage the same ECS-on-EC2 architecture with identical HCL (HashiCorp Configuration Language) logic.

Conclusion

Deploying Amazon ECS on EC2 using Terraform provides a powerful balance between the orchestration capabilities of containers and the granular control of virtual machine infrastructure. While the Fargate launch type is superior for teams prioritizing speed and reduced operational overhead, the EC2 launch type is the strategic choice for complex, high-scale, or cost-sensitive workloads.

By meticulously configuring the VPC for network isolation, utilizing Auto-Scaling Groups for resilience, and defining precise Task Definitions for workload consistency, engineers can build a robust environment capable of handling production traffic. The integration of an Application Load Balancer ensures that this environment remains available and scalable, while Terraform ensures that the entire stack remains documented as code. Ultimately, the shift to ECS on EC2 allows an organization to optimize its cloud spend through instance selection and scaling strategies while maintaining the agility provided by containerized microservices.

Sources

1. github.com/chinmayto/terraform-aws-ecs-cluster-on-ec2
2. folderit.net/deploying-an-ecs-cluster-on-ec2-instances-with-terraform/
3. spacelift.io/blog/terraform-ecs