# ECS Fargate Service Safety Guide

Use this reference for Amazon ECS/Fargate platform reviews covering services, task definitions, task role vs execution role, capacity providers, load balancers, deployment circuit breakers, blue/green, autoscaling, health checks, logs, secrets, networking, and rollback.

## What people get wrong

The lazy story is:

> ECS service stable means the platform is healthy.

Wrong. Stable desired count can hide overprivileged task roles, broken health checks, missing circuit breakers, wrong image tags, secret exposure, capacity-provider drift, and weak rollback.

Common bad assumptions:

- Task role and execution role can share permissions.
- Latest task definition revision is safe.
- Fargate removes capacity and networking concerns.
- ALB health checks prove application correctness.
- Circuit breaker is enough without alarms and rollback validation.
- Secrets in task definition references are safe without IAM/KMS review.

## ECS/Fargate failure modes

- Execution role cannot pull images, publish logs, or fetch secrets; task role has broad app permissions.
- Task definition changes CPU/memory, ports, env vars, logging, secrets, or image tag unexpectedly.
- Deployment min/max healthy percent, circuit breaker, or CodeDeploy blue/green settings cause outage or no rollback.
- Target group health check path/port/grace period hides app startup failure.
- Subnet/security group/assignPublicIp/service discovery settings expose or isolate tasks incorrectly.
- Autoscaling follows CPU while bottleneck is queue depth, latency, memory, or downstream throttling.

## Minimum safe workflow

1. Identify cluster, service, launch type, deployment controller, task definition family, target groups, and capacity provider strategy.
2. Review task definition diffs: image digest/tag, CPU/memory, ports, env/secrets, logs, roles, health checks, and platform version.
3. Separate execution role from task role and verify least privilege for ECR, CloudWatch Logs, Secrets Manager, SSM, KMS, and app APIs.
4. Check deployment safety: circuit breaker, alarms, desired count, min/max healthy percent, blue/green hooks, and rollback revision.
5. Review networking and exposure: subnets, security groups, public IPs, load balancer, service discovery, and VPC endpoints.
6. Validate observability: service events, stopped task reasons, target health, logs, metrics, and deployment state changes.
7. Require approval before update-service, force-new-deployment, task definition registration, or scaling changes.

## Verification targets

- ECS service definition, deployments, events, desired/running/pending counts, deployment controller, and circuit breaker
- task definition image digest, CPU/memory, roles, secrets, logging, health checks, ports, volumes, and platform version
- task execution role and task role IAM/KMS/Secrets Manager/ECR/CloudWatch Logs permissions
- ALB/NLB target groups, health check path/port/grace, listener rules, and target health
- capacity providers, Fargate/Fargate Spot mix, autoscaling policies, CloudWatch alarms, and queue/business metrics
- CodeDeploy AppSpec, lifecycle hooks, alarms, rollback config, and previous task definition target

## When to push back

Push back if the user asks to:

- force new deployment without root-cause evidence
- widen task or execution role blindly
- deploy mutable image tags without digest/provenance
- disable health checks or circuit breakers to reach steady state
- scale desired count to hide crash loops
- treat service stable as proof of security or readiness

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html
- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html
- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html
- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- Fargate for ECS provides serverless container management with task definitions, platform versions, capacity providers, service load balancing, and usage metrics.
- The ECS task execution role lets the ECS agent perform AWS API calls such as pulling ECR images, retrieving Secrets Manager or Systems Manager values, and accessing configured storage; it is distinct from the application task role.

Sampled live evidence:
- Read-only regional availability sampling reported Amazon ECS and AWS Fargate as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `ECS+DescribeServices` and `ECS+DescribeTasks` were reported `isAvailableIn` in those regions.

Review implications:
- Require evidence for task role vs execution role separation, image-pull path, secrets access, network mode/security groups, load balancer health, deployment controller, circuit breaker/rollback, logs, and autoscaling.
- Fargate availability does not prove platform-version compatibility, quota, subnet capacity, or service health in the user's account.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Cluster/service/task definition, launch type, deployment controller, load balancer, target groups, and capacity provider
- Task role, execution role, secret access, image source, logging driver, network mode, security groups, and IAM boundaries
- Deployment strategy, circuit breaker, CloudWatch alarms, blue/green hooks, health checks, desired count, and rollback state
- Capacity, autoscaling, CPU/memory, platform version, quotas, observability, and failure event evidence

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS ECS Fargate Platform Operator: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```