Amazon Elastic Container Service (ECS) is a fully-managed cloud container orchestration service provided by Amazon Web Services (AWS). It is designed to run multiple Docker containers on a cluster using AWS EC2 instances. Optionally, these containers can also run on AWS Fargate, a serverless compute engine that manages the underlying infrastructure. As organizations scale their workloads, the number of deployed ECS clusters increases, leading to a significant rise in infrastructure management complexity. Deploying and scaling large clusters involves numerous repetitive tasks that, when performed manually, lead to human errors, configuration drift, and an elevated risk of security breaches. Managing AWS ECS directly from the AWS console can quickly become overwhelming. Setting up a cluster typically involves creating a Virtual Private Cloud (VPC), subnets, security groups, an Application Load Balancer (ALB), task definitions, and services. Each step requires multiple manual interactions, making it easy to overlook critical configurations. When replicating this setup for staging or production environments, manual repetition often results in mistakes, inconsistent environments, and wasted time.

Terraform provides a robust solution to these challenges by allowing infrastructure to be defined as code. Instead of manually creating resources in the console, engineers write configuration files that describe the desired state of the infrastructure. This approach ensures a consistent, repeatable, and version-controlled deployment process. By using Terraform to manage AWS ECS clusters, teams can automate the deployment of EC2-based or Fargate-based workloads, ensuring that the environment remains stable and secure. This guide details the technical implementation of the aws_ecs_service resource and related components, covering service deployment, auto-scaling, logging, security, and integration with service meshes.

Deployment Strategies: Fargate versus EC2 Instances

There are mainly two ways to deploy a service on ECS clusters: using AWS Fargate or EC2 instances. The choice depends on the underlying infrastructure used to run the container workloads of any ECS service. AWS Fargate represents a more cloud-native approach where the compute instances are automatically managed by AWS, removing the need to provision and manage servers. In contrast, running the ECS service on EC2 instances provides more granular control over the infrastructure, which is often required for performance tuning, specific hardware requirements, or cost optimization for long-running workloads.

A Terraform module designed for creating an ECS service typically supports both launch types. This flexibility allows the same service definition to be applied across different environments or teams with different infrastructure preferences. The module can run an ECS service with or without an AWS load balancer, providing options for both internal service-to-service communication and external-facing web traffic. When a load balancer is present, the module supports associating multiple target groups with both Network Load Balancers (NLB) and Application Load Balancers (ALB). This capability is crucial for architectures that require both HTTP/HTTPS routing via ALB and high-throughput TCP/UDP traffic via NLB.

Core Resource Configuration and Task Definitions

The aws_ecs_service resource in Terraform is the primary abstraction for running and maintaining task instances within a cluster. To properly configure this resource, it must be linked to a task definition, which serves as the blueprint for the software services on AWS. A task definition specifies the container images, environment variables, resource requirements, and networking modes for the application. In complex architectures, such as those involving service meshes, the task definition may include additional containers beyond the primary application container.

For example, when integrating Consul service mesh, the Terraform configuration must include specific modules that modify the task definition. The mesh-task module adds the Consul ECS control-plane and Consul dataplane containers to the task definition along with the application container. Within this configuration, Envoy, the proxy that handles traffic management, runs as a subprocess within the Consul dataplane container. The aws_ecs_service resource then uses this augmented task definition to spawn the necessary service instances.

Validating the initial infrastructure is a critical step in the deployment pipeline. A common practice is to create an initial task definition using a lightweight image, such as golang:alpine. This image can be used to validate that the infrastructure is working by serving a simple Go hello world page. This page typically listens on two configurable ports, allowing engineers to verify that network routing, load balancer health checks, and container port mappings are functioning correctly before deploying production workloads.

Auto-Scaling and High Availability Configuration

Ensuring high availability without over-provisioning resources requires the implementation of Application Auto Scaling. Terraform can manage the scaling policies and alarms that drive this behavior. The scaling configuration typically involves defining a target track and setting up CloudWatch alarms that trigger scaling actions based on specific metrics.

The following table outlines a standard auto-scaling configuration for an ECS service, detailing the parameters required to maintain an average CPU utilization of 50%.

In addition to the alarm-based scaling, a target tracking scaling policy is used to keep the average CPU around 50%. This policy is associated with the ECS service, which is defined as scalable with a minimum of 1 task and a maximum of 4 tasks. Cooldowns are enforced to prevent scaling too frequently, with a 60-second interval between adjustments. This configuration ensures that the service scales automatically based on load, maintaining performance during peak times while reducing costs during periods of low activity.

Preventing Unintentional Scaling and State Drift

One of the significant challenges when managing ECS services with Terraform is the potential for unintentional scaling events. Without proper handling, a terraform apply command could unintentionally scale down an ECS service, causing downtime or degraded performance. This occurs if the state file contains a desired_count that differs from the actual running tasks, perhaps due to manual interventions or auto-scaling adjustments that Terraform is unaware of.

To prevent this, Terraform provides lifecycle hooks that allow specific attributes to be ignored during plan and apply operations. The lifecycle block in the aws_ecs_service resource can be configured to ignore changes to the desired_count. This ensures that Terraform does not attempt to reconcile the desired number of tasks, thereby preventing unintended scale-downs.

```hcl
resource "awsecsservice" "example" {
name = "my-service"
cluster = awsecscluster.main.name
taskdefinition = awsecstaskdefinition.arn
desired_count = 2

lifecycle {
ignorechanges = [desiredcount]
}
}
```

This configuration is particularly effective when working with Application Auto Scaling or when performing manual scaling during incident response. It avoids surprises during terraform apply and works seamlessly with automated scaling mechanisms. By explicitly telling Terraform to ignore the desired_count, engineers can maintain stability in the production environment while still using Terraform to manage the static configuration of the service.

CloudWatch Log Group Management

ECS can automatically create CloudWatch log groups for tasks, but this default behavior limits control over important settings such as log retention, naming conventions, and cost management. Defining log groups explicitly in Terraform is a best practice that ensures consistency and predictability across all environments. By creating the log group as a separate resource, engineers can enforce retention policies and naming standards that align with organizational requirements.

The following table details the benefits of explicitly defining CloudWatch log groups in Terraform compared to automatic creation.

A typical Terraform configuration for a CloudWatch log group includes a name that follows a specific pattern and a retention period. For example, a log group might be named /ecs/my_log_group_name with a retention of 1 day, which is currently the minimum allowed value. This configuration controls log retention, avoids infinite log storage, and helps with cost optimization. Additionally, log streams can be streamed to a CloudWatch log group encrypted with a KMS key, enhancing the security of the logging infrastructure.

Service Mesh Integration with Consul

For workloads requiring advanced service-to-service communication, security, and observability, Consul service mesh can be integrated with ECS using Terraform. This integration involves deploying Consul server agents, which must run on another runtime, such as EKS, and be connected to the ECS workloads. Consul server agents do not run on ECS itself.

The Terraform configuration for Consul service mesh on ECS includes several key modules and resources. The mesh-task module adds the Consul ECS control-plane and Consul dataplane containers to the task definition. The aws_ecs_service resource is then used to run and maintain the task instances with these additional containers. The gateway-task module adds mesh gateway containers to the cluster. These gateways enable service-to-service communication across different types of network areas, which is essential for hybrid cloud or multi-cluster architectures.

To enable Consul security features for production workloads, the controller module must also be deployed. This module provisions ACL tokens for service mesh tasks. Enabling these security features requires specific prerequisites. First, TLS encryption must be enabled on the Consul servers so that they can communicate securely with Consul containers over gRPC. Second, access control lists (ACLs) must be enabled on the Consul servers. ACLs provide authentication and authorization for access to Consul servers on the mesh. If the gateway-task module is used to deploy mesh gateways, TLS must be enabled.

After defining the Terraform configuration, the terraform apply command is used to deploy Consul to the ECS cluster. This process provisions the necessary components and configures the mesh for secure, observable communication between services.

Deployment Workflow and Best Practices

The deployment of the ECS infrastructure using Terraform follows a standard workflow that ensures the configuration is valid and the changes are reviewed before application. The process involves initializing Terraform, validating the configuration, reviewing the execution plan, and applying the changes.

The following code block illustrates the standard commands used in this workflow:

```bash

Initialize Terraform (downloads providers & sets up backend)

terraform init

Validate configuration

terraform validate

Preview the changes

terraform plan -var-file="terraform.tfvars"

Apply the changes (creates infrastructure)

terraform apply -var-file="terraform.tfvars" -auto-approve
```

The terraform init command prepares the working directory by downloading provider plugins and configuring the remote backend. The terraform validate command checks for syntax errors and ensures that the configuration is valid. The terraform plan command shows a preview of resources that will be created, updated, or destroyed, allowing for a thorough review of the changes. Finally, terraform apply creates the infrastructure. The -auto-approve flag bypasses the interactive confirmation prompt, which is useful in automated CI/CD pipelines but should be used with caution in manual deployments.

Additional best practices include using ECS Exec, a feature that allows engineers to connect directly into a running container from the AWS Console or CLI. This capability eliminates the need for SSH or bastion hosts, simplifying debugging and troubleshooting in production environments.

Conclusion

Implementing AWS ECS services with Terraform transforms infrastructure management from a manual, error-prone process into a streamlined, automated workflow. By defining infrastructure as code, organizations can achieve consistency across environments, reduce the risk of configuration drift, and enhance security. The aws_ecs_service resource, when combined with appropriate modules and configurations, supports complex requirements such as auto-scaling, secure logging, and service mesh integration. Key strategies include using lifecycle hooks to prevent unintended scaling, explicitly defining CloudWatch log groups for cost control, and integrating Consul for advanced service mesh capabilities. The deployment workflow, utilizing terraform init, validate, plan, and apply, ensures that changes are reviewed and validated before being applied to the production environment. These practices, when combined, result in a resilient, scalable, and secure container orchestration platform that can handle the demands of modern cloud-native applications.

Sources

1. SpaceLift Blog
2. HashiCorp Developer
3. AWS on Plain English
4. Trussworks Terraform AWS ECS Service
5. AWS Builders on Dev.to