Complete Resource Overview for ECS Fargate

When building applications with ECS Fargate, you might feel uncertain: "Do I have all the configurations I need?" With so many related resources, it's hard to tell what's essential versus optional.

This article comprehensively organizes the resources needed for ECS Fargate, giving you a clear picture of the whole system. The goal is to reach a state where you can confidently build from scratch.

Understanding the Three-Layer Structure

ECS Fargate resources become easier to understand when divided into three layers.

• Foundation Layer: Network, permissions, image storage—the base for containers to run
• Container Layer: ECS-specific resources handling task definition and execution
• Traffic Layer: The path that delivers external requests to containers

Build from the bottom up. When writing CloudFormation, keeping this order in mind helps manage dependencies effectively.

Overall Architecture Diagram

Here's a practical web application configuration visualized:

Solid lines represent traffic flow, dotted lines represent resource references.

Foundation Layer Resources

VPC / Subnet / Internet Gateway / NAT Gateway

The network foundation resource group.

Configuration Points:

• Public Subnet: Place ALB and NAT Gateway here. Has route to Internet Gateway
• Private Subnet: Place ECS tasks here. External communication via NAT Gateway

Why place tasks in private subnets? For security. While you can assign public IPs directly to tasks, production environments typically allow access only through ALB.

Multi-AZ Configuration: Deploy subnets in at least 2 AZs for availability. This is also an ALB requirement.

Security Group

Required Security Groups:

1. ALB Security Group:

   • Inbound: 80/443 from 0.0.0.0/0
   • Outbound: Traffic to ECS task SG

2. ECS Task Security Group:

   • Inbound: Container port (e.g., 8080) from ALB SG
   • Outbound: 0.0.0.0/0 (external API calls, ECR image pulls, etc.)

Using security group references (specifying SG IDs) enables flexible configuration without depending on IP addresses.

IAM Role

ECS uses two types of IAM roles. This is a common point of confusion.

Policies needed for Task Execution Role:

• AmazonECSTaskExecutionRolePolicy (AWS managed policy)
• When using Secrets Manager: secretsmanager:GetSecretValue
• When using Systems Manager Parameter Store: ssm:GetParameters

Policies needed for Task Role:

• Access permissions for AWS resources your application needs
• Design following the principle of least privilege

ECR (Elastic Container Registry)

URI format when specifying images in task definitions:

ECR is referenced directly from task definitions and pulled using Task Execution Role permissions.

CloudWatch Logs

Specify in logConfiguration within the task definition. Create log groups in advance or use the autoCreateGroup option.

"logConfiguration": {
    "logDriver": "awslogs",
    "options": {
        "awslogs-group": "/ecs/my-app",
        "awslogs-region": "ap-northeast-1",
        "awslogs-stream-prefix": "ecs"
    }
}

Container Layer Resources

ECS Cluster

A cluster is like a "box"—it doesn't have many configuration options itself. For Fargate, FARGATE and FARGATE_SPOT automatically become available as capacity providers.

Container Insights: Enabling this enhances metrics and logs but incurs additional costs.

Task Definition

Task definitions are the core ECS resource. Here are the key configuration items:

Task-level settings:

Container definition settings:

CPU/Memory combination constraints:

Fargate has fixed valid combinations. For example:

• 256 CPU: 512, 1024, 2048 MB
• 512 CPU: 1024–4096 MB
• 1024 CPU: 2048–8192 MB
• Increases progressively thereafter

Service

A service is responsible for "keeping the specified number of tasks running." Key settings:

networkConfiguration:

"networkConfiguration": {
    "awsvpcConfiguration": {
        "subnets": ["subnet-xxx", "subnet-yyy"],
        "securityGroups": ["sg-xxx"],
        "assignPublicIp": "DISABLED"
    }
}

Use assignPublicIp: DISABLED when placing in private subnets.

Traffic Layer Resources

Application Load Balancer

Configuration relationship:

Target Group configuration points:

ECS Service references the Target Group and automatically registers/deregisters task IP addresses.

Route53 / ACM

For HTTPS support:

1. Issue certificate with ACM (DNS validation is easiest)
2. Associate certificate with ALB HTTPS listener
3. Create Alias record to ALB in Route53

Use Case Configuration Variations

Web Application (Primary)

The configuration explained so far. Receives HTTP requests via ALB.

Required resources: VPC suite, ALB suite, ECS suite, IAM, ECR, CloudWatch Logs

Batch Processing (Scheduled Execution)

Schedule execution pattern using EventBridge (formerly CloudWatch Events).

Differences from web app:

• ALB and Target Group not needed
• Call RunTask directly from EventBridge instead of ECS Service
• IAM role needed for EventBridge Rule to execute ECS tasks

Additional resources needed:

Internal API (Service Connect / Cloud Map)

Internal API pattern accessed only from other ECS services.

Differences from web app:

• ALB not needed (or use Internal ALB)
• Use Service Connect or Cloud Map (Service Discovery)
• Communication within same VPC

Service Connect: ECS Service Connect (introduced 2022) simplifies service-to-service communication. Enables access by service name.

Additional resources needed:

Worker (SQS Integration)

Pattern for retrieving and processing messages from SQS.

Differences from web app:

• ALB not needed
• Task Role needs SQS access permissions
• Application needs SQS polling logic
• Auto Scaling adjusts task count based on queue depth

Additional resources needed:

Resource Dependencies

When building with CloudFormation, you need to be aware of resource creation order. Here's a diagram showing the main dependencies:

Reading the dependency diagram: Resources at the arrow's origin are referenced by resources at the arrow's destination. This means the origin resource must be created first.

Checklist

A checklist to verify "Do I have everything I need?"

Foundation Layer

• Created VPC
• Created Public Subnets (2+ AZs)
• Created Private Subnets (2+ AZs)
• Created Internet Gateway and attached to VPC
• Created NAT Gateway (or NAT Instance)
• Configured route tables correctly
  • Public Subnet → Internet Gateway
  • Private Subnet → NAT Gateway
• Created ALB security group
• Created ECS task security group
• Created Task Execution Role
• Created Task Role (if needed)
• Created ECR repository
• Created CloudWatch Logs log group

Container Layer

• Created ECS cluster
• Created task definition
  • CPU/memory combination is valid
  • Container image URI is correct
  • Configured port mappings
  • Added log configuration
  • Set required environment variables/secrets
• Created ECS service
  • Specified correct subnets
  • Specified correct security groups
  • Configured Target Group association

Traffic Layer (for web apps)

• Created ALB
• Created Target Group (targetType: ip)
• Created Listener
• For HTTPS support:
  • Issued ACM certificate
  • Associated certificate with HTTPS listener
• Created Route53 record (for custom domains)

Summary

This article organized ECS Fargate application resources into a three-layer structure.

• Foundation Layer: VPC, Subnet, Security Group, IAM Role, ECR, CloudWatch Logs
• Container Layer: Cluster, Task Definition, Service
• Traffic Layer: ALB, Target Group, Listener, Route53, ACM

Particularly confusing points:

1. Two IAM Roles: Distinguishing Task Execution Role (for ECS agent) from Task Role (for app)
2. Target Group Type: Use ip type for Fargate
3. Network Configuration: Private subnet + NAT Gateway configuration is production-ready

Use the checklist to verify you have all necessary resources as you build.