AWS ECS and Fargate

Pathrule2 Rules • 3 Memories • 1 Skill

ECS and Fargate remove host management but retain task definition, network, IAM, load-balancer, health, shutdown, secret, image, autoscaling, and deployment-overlap decisions that determine whether a service is safe and recoverable. This pattern constrains task identity and graceful lifecycle while recording task-definition, network, capacity, and rollout ownership decisions and providing a deployment verification workflow. It differs from Kubernetes and Lambda by focusing on ECS services, task definitions, awsvpc networking, task and execution roles, load-balancer draining, and Fargate resource shapes.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

verify-ecs-service-deployment

infra/

ecs/

Separate execution and task IAM roles

A task definition revision is an immutable release input

Task networking follows least exposure

Autoscaling is bounded by downstream capacity

deploy/

Drain traffic and work before task termination

Rules

Separate execution and task IAM roles/infra/ecshighstrictGive ECS infrastructure pull and logging access through the execution role, and grant application permissions only to the task role.

1	The agent that starts a task needs registry, secret injection, and logging permissions, while application code needs domain-specific AWS access. Combining them exposes infrastructure capabilities inside the container.
2
3	- Keep the execution role limited to the actions ECS needs to start and report the task.
4	- Attach least-privilege application permissions to the task role and scope resources, actions, conditions, and account boundaries.
5	- Do not place long-lived AWS access keys in environment variables or images; use the task-role credential path.
6	- Test denied actions from inside the running task and review role use through audit logs before expanding policy.
7
8	See /deploy for the adjacent decision or procedure that completes this constraint.

Drain traffic and work before task termination/deployhighstrictCoordinate load-balancer deregistration, readiness, container stop signal, application shutdown, and stop timeout.

1	During service replacement, old tasks can receive traffic until targets drain. If the container exits immediately on termination, active requests or consumers fail even though the deployment controller is operating normally.
2
3	- Make readiness fail before or as shutdown begins so new requests stop reaching the task.
4	- Handle the container stop signal in the application, stop intake, drain active requests or jobs, and close dependencies in order.
5	- Set target deregistration and task stop timeouts from measured maximum ordinary work, with a bounded forced path for stuck operations.
6	- Test rolling deployment with slow requests, keep-alive connections, queue work, and dependency closure while old and new tasks overlap.
7
8	See /ops/runbooks for the adjacent decision or procedure that completes this constraint.

Memories

A task definition revision is an immutable release input/infra/ecsVersion image digest, resources, ports, health, environment, secrets, logging, roles, and platform settings together.

1	A mutable image tag or console-edited task definition makes two tasks in the same service appear equivalent while running different bytes or configuration.
2
3	- Reference an immutable image digest or release identity and retain the source revision and build provenance.
4	- Declare CPU, memory, architecture, ephemeral storage, ports, health checks, logging, roles, environment, and secret references in versioned infrastructure.
5	- Register a new revision for every meaningful change and deploy it through the same review and rollback path.
6	- Compare the running task definition and image digest with the intended release after deployment instead of trusting service update success alone.
7
8	See /deploy for the rule or workflow that puts this decision into practice.

Task networking follows least exposure/infra/ecsPlace tasks in private network paths unless they must accept direct public traffic, and constrain security groups by service relationship.

1	With task-level networking, every task receives an interface and security boundary. Public addressing or broad security-group rules multiply exposure as the service scales.
2
3	- Use private subnets and controlled egress for tasks behind a public or internal load balancer unless direct public addressing is a product requirement.
4	- Allow inbound from the exact load-balancer or caller security group and service port, not broad network ranges.
5	- Constrain outbound access to required destinations where architecture supports it and provide private endpoints for AWS services with heavy or sensitive traffic.
6	- Account for one interface and IP per task in subnet capacity and deployment overlap before autoscaling into address exhaustion.
7
8	See /ops/runbooks for the rule or workflow that puts this decision into practice.

Autoscaling is bounded by downstream capacity/infra/ecsScale from demand signals that reflect work while capping task concurrency against database, queue, API, subnet, and account limits.

1	Adding tasks multiplies connection pools and outgoing calls. CPU can fall while a shared database or remote API becomes the real bottleneck, causing retries and further scale-out.
2
3	- Choose service metrics tied to request, queue, or latency demand and validate their behavior during dependency slowdown.
4	- Multiply per-task database pools and client concurrency by maximum tasks and rolling-deployment overlap.
5	- Set minimum, maximum, cooldown, and deployment percentages with subnet IP, load-balancer, quota, and cost capacity in mind.
6	- Use backpressure and admission limits inside tasks so autoscaling is not the only defense against sudden load or a failing dependency.
7
8	See /infra/ecs for the rule or workflow that puts this decision into practice.

Skills

verify-ecs-service-deployment/rootValidate an ECS task revision through identity, network, health, drain, capacity, rollback, and runtime evidence.

1	---
2	name: verify-ecs-service-deployment
3	description: Deploy or revise an ECS or Fargate service safely.
4	---
5
6	# Verify Ecs Service Deployment
7
8	Run this procedure when the affected surface changes, before the result is promoted to production. Record evidence for every step instead of accepting a plausible-looking result.
9
10	1. Resolve the task definition, immutable image, platform, roles, secrets, logging, CPU, memory, ports, health, and network settings from the reviewed release.
11	2. Launch a small deployment and verify task placement, image identity, application readiness, target registration, denied IAM actions, and required egress.
12	3. Exercise slow and failing requests, dependency loss, task stop, container crash, health failure, and log delivery while old and new tasks overlap.
13	4. Watch deployment progress, target health, restarts, latency, errors, saturation, connection pools, subnet capacity, and downstream limits.
14	5. Rollback to the prior task revision on acceptance failure and confirm old tasks become healthy before stopping investigation safeguards.
15
16	## Exit criteria
17
18	The change is complete only when the expected behavior, failure behavior, and rollback path have all been exercised with representative data. Preserve the evidence with the change so the next operator can repeat the same checks.

Why this pattern

AI agents often grant the execution role application permissions, expose tasks publicly without need, use one health check for startup and readiness, or ignore old-new task overlap during deploy.

Built for Platform teams operating container services and jobs on Amazon ECS with Fargate or mixed capacity.

Keeps your assistant from:

Giving application code infrastructure deployment credentials
Running private service tasks with public network exposure
Killing requests before load-balancer draining completes
Exhausting databases when autoscaling tasks multiply pools

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25