ECS Fargate in Production: A Complete Configuration Guide With QuickInfra

ECS Fargate removes the EC2 instance management layer entirely — you define a task (which container to run, how much CPU/memory it needs), and Fargate runs it. No servers to patch, no capacity to manage. For containerised web applications and APIs, this is usually the right production choice when Kubernetes complexity isn't justified.

Task Definition

The ECS Task Definition is the core configuration unit: container image, CPU/memory allocation, environment variables, port mappings, logging configuration, and IAM task role. QuickInfra generates the task definition from your project configuration and manages revisions — every update to your container image or configuration creates a new task definition revision.

Critical configurations QuickInfra enforces:

• Task role with least-privilege IAM permissions (not the task execution role — the role the container code uses)
• Secrets from Secrets Manager injected as environment variables via the secrets configuration, not as plain-text environment variables
• CloudWatch Logs configured as the log driver with a dedicated log group

Networking

Fargate tasks run in awsvpc networking mode — each task gets its own elastic network interface with its own security group. This is distinct from EC2 launch type where containers share the host's network.

QuickInfra places Fargate tasks in private subnets with outbound internet access through a NAT Gateway. The security group allows inbound only from the Application Load Balancer security group — no direct internet access to tasks.

Service Configuration

An ECS Service maintains the desired number of task instances, handles health checking, integrates with the load balancer, and manages rolling deployments. QuickInfra configures the service with:

• Minimum healthy percent: 50% (allows rolling deployments without over-provisioning)
• Maximum percent: 200% (new tasks start before old ones stop)
• Health check grace period: 60 seconds (prevents premature health check failures during startup)
• Circuit breaker with rollback (if a new deployment fails health checks, automatically roll back to the previous revision)

Auto Scaling

Fargate services scale based on Application Auto Scaling policies. QuickInfra configures target tracking on CPU utilisation (target 60%) and optionally on ALB request count per target. Scale-in cooldown is set to 300 seconds to prevent thrashing.

Cost Optimisation for Fargate

Fargate pricing is based on vCPU and memory per second. Right-sizing Fargate task CPU and memory to your actual requirements has a direct cost impact — a task configured for 1 vCPU and 2GB that only needs 0.25 vCPU and 512MB is costing 4x more than necessary. QuickInfra's monitoring layer tracks per-task CPU and memory utilisation and surfaces right-sizing recommendations.