# Pathrule Pattern: AWS ECS and Fargate (1.0.0) # ::pathrule:package:aws-ecs-fargate ### [RULE] Separate execution and task IAM roles (path: /infra/ecs) 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. - Keep the execution role limited to the actions ECS needs to start and report the task. - Attach least-privilege application permissions to the task role and scope resources, actions, conditions, and account boundaries. - Do not place long-lived AWS access keys in environment variables or images; use the task-role credential path. - Test denied actions from inside the running task and review role use through audit logs before expanding policy. See /deploy for the adjacent decision or procedure that completes this constraint. --- ### [RULE] Drain traffic and work before task termination (path: /deploy) 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. - Make readiness fail before or as shutdown begins so new requests stop reaching the task. - Handle the container stop signal in the application, stop intake, drain active requests or jobs, and close dependencies in order. - Set target deregistration and task stop timeouts from measured maximum ordinary work, with a bounded forced path for stuck operations. - Test rolling deployment with slow requests, keep-alive connections, queue work, and dependency closure while old and new tasks overlap. See /ops/runbooks for the adjacent decision or procedure that completes this constraint. --- ### [MEMORY] A task definition revision is an immutable release input (path: /infra/ecs) A mutable image tag or console-edited task definition makes two tasks in the same service appear equivalent while running different bytes or configuration. - Reference an immutable image digest or release identity and retain the source revision and build provenance. - Declare CPU, memory, architecture, ephemeral storage, ports, health checks, logging, roles, environment, and secret references in versioned infrastructure. - Register a new revision for every meaningful change and deploy it through the same review and rollback path. - Compare the running task definition and image digest with the intended release after deployment instead of trusting service update success alone. See /deploy for the rule or workflow that puts this decision into practice. --- ### [MEMORY] Task networking follows least exposure (path: /infra/ecs) 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. - Use private subnets and controlled egress for tasks behind a public or internal load balancer unless direct public addressing is a product requirement. - Allow inbound from the exact load-balancer or caller security group and service port, not broad network ranges. - Constrain outbound access to required destinations where architecture supports it and provide private endpoints for AWS services with heavy or sensitive traffic. - Account for one interface and IP per task in subnet capacity and deployment overlap before autoscaling into address exhaustion. See /ops/runbooks for the rule or workflow that puts this decision into practice. --- ### [MEMORY] Autoscaling is bounded by downstream capacity (path: /infra/ecs) 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. - Choose service metrics tied to request, queue, or latency demand and validate their behavior during dependency slowdown. - Multiply per-task database pools and client concurrency by maximum tasks and rolling-deployment overlap. - Set minimum, maximum, cooldown, and deployment percentages with subnet IP, load-balancer, quota, and cost capacity in mind. - Use backpressure and admission limits inside tasks so autoscaling is not the only defense against sudden load or a failing dependency. See /infra/ecs for the rule or workflow that puts this decision into practice. --- ### [SKILL] verify-ecs-service-deployment (path: /) --- name: verify-ecs-service-deployment description: Deploy or revise an ECS or Fargate service safely. --- # Verify Ecs Service Deployment 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. 1. Resolve the task definition, immutable image, platform, roles, secrets, logging, CPU, memory, ports, health, and network settings from the reviewed release. 2. Launch a small deployment and verify task placement, image identity, application readiness, target registration, denied IAM actions, and required egress. 3. Exercise slow and failing requests, dependency loss, task stop, container crash, health failure, and log delivery while old and new tasks overlap. 4. Watch deployment progress, target health, restarts, latency, errors, saturation, connection pools, subnet capacity, and downstream limits. 5. Rollback to the prior task revision on acceptance failure and confirm old tasks become healthy before stopping investigation safeguards. ## Exit criteria 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.