Ecs Operation Review

ECS Operation Review

This skill performs a structured, evidence-based operational-excellence assessment of a live Amazon ECS estate — clusters, capacity providers, services, task definitions, and their supporting AWS resources — and produces a rated report (GREEN / AMBER / RED / UNKNOWN / N/A) with prioritized, cited recommendations.

It is the umbrella Day-2 audit that walks the major domains of the Amazon ECS Best Practices Guide (ecs-best-practices.html). It is evaluative (it grades what exists), not generative — it does not design or build new environments, and it defers to the deep ECS skills for remediation depth rather than duplicating them (see "Defers to deep skills").

This skill is for Amazon ECS only. Skip it for EKS / Kubernetes estates — use eks-operation-review instead.

Scope & limitations (known blind spots)

This review is deliberately bounded. It does not currently assess, and should state as out-of-scope in the report:

• Scheduled and standalone tasks — the audit enumerates workloads via list-services; EventBridge-scheduled tasks and one-off run-task workloads are not examined.
• ECS Express Mode services — their ALB, security groups, and deployment config are auto-managed by AWS, so checks 2.2 / 4.x / 5.2 would mis-rate them. Mark N/A.
• Windows and ECS Anywhere (EXTERNAL) workloads — several container-hardening and runtime-monitoring checks (3.x, 7.3, 7.4) assume Linux on Fargate/EC2 and would false-RED Windows or external tasks. Note their presence and mark the affected items N/A.
• API throttling on large estates — when iterating over many services/task definitions, expect ECS API throttling; paginate and back off (see the pagination note in references/operational-processes.md).

State any of these that apply to the estate explicitly in the report's Scope block rather than silently omitting them.

When to use

Activate for any request to audit, review, health-check, or score an ECS estate's operational posture:

• "Run an operational review on my ECS cluster / estate"
• "ECS health check", "score my ECS posture", "GREEN/AMBER/RED my ECS services"
• "Review my ECS deployment safety / capacity / networking / observability / security posture"
• Section-scoped reviews of a single domain (e.g., "check my ECS capacity-provider scale-in", "review connection draining on my services", "audit my task-definition hygiene")

Don't use for (route elsewhere)

The deep ECS sibling skills named above (ecs-architect, ecs-recon, ecs-security, ecs-cost-intelligence, ecs-observability, ecs-devops, ecs-modernize) are part of the ECS skill family and may be rolled out over time; route to them by name where relevant, and if one is not yet available, note that and fall back to the AWS CLI / this skill's audit-depth guidance. General container questions, one-off aws ecs commands, and cluster creation should be handled directly without this skill.

Defers to deep skills

This review scores each domain at audit depth — enough to rate it and flag the top gaps — then hands off. When a finding warrants deeper work, name the sibling skill in the recommendation rather than reproducing its guidance here:

• Security posture findings (Section 07) → ecs-security for role-trust hardening, secrets, compliance scope.
• Cost / capacity-efficiency angles surfaced during the capacity review (Section 01) → ecs-cost-intelligence for $-denominated TCO.
• Observability findings (Section 06) → ecs-observability for stack design.
• Deployment / release-engineering findings (Section 04) → ecs-devops for pipeline and rollout-strategy design.

The review's own output is an assessment report. Acting on it (mutations, pipeline changes) is a separate, deliberate step the user chooses.

Access model — READ-ONLY

This skill is strictly read-only. It CAN issue read-only calls (aws ecs describe-*/list-*, sts get-caller-identity, application-autoscaling describe-*, autoscaling describe-*, cloudwatch describe-*, ec2 describe-*, ecr describe-*, iam get-*/list-*, elbv2 describe-*, logs describe-*, events list-*, backup list-*, guardduty list-*/get-*, service-quotas get-*/list-*) to discover estate state, and CAN write a markdown/HTML report to the workspace. It CANNOT mutate any resource (no create, update, delete, register, deregister, run-task, or scale operations). Operational reviews are discovery activities; remediation belongs to whatever path the user chooses afterward.

Prerequisites

• AWS credentials with ECS read access (and read access to CloudWatch, ECR, IAM, ELBv2, Application Auto Scaling, GuardDuty for full coverage). ReadOnly/least-privilege credentials are preferred.
• AWS CLI v2 configured with a default Region (aws configure get region).
• Python 3.10+ for the optional HTML report conversion.
• Optional: the Amazon ECS MCP server (preview) for richer live-estate inspection. If configured, its read tools may be used; the skill works fully with the AWS CLI alone. See ECS MCP server docs. The ECS MCP server is in preview and subject to change — do not depend on it; the AWS CLI is the reliable primary path.

Tool usage rules (invariants)

1. Do NOT call any tools when this skill is first activated. Wait for the user to explicitly ask for a review.
2. Do NOT hardcode or guess cluster/service names. Always discover them by listing first.
3. Do NOT read config files as a connectivity "check". Verify access by making one real read call.
4. Do NOT retry a failed call more than once. If it fails twice, mark the affected items UNKNOWN with the failure reason and continue.
5. Always load the relevant references/ file before executing that section's checks.
6. Never mutate. Only describe/list/get verbs. If a check would require a write, mark UNKNOWN and note it for manual investigation.
7. Only rate on observed evidence. If a check returns no data, mark UNKNOWN — never assume.

Methodology

Step 0 — Pre-flight

Action 1 — List clusters.

aws ecs list-clusters --output json

• Success → show the list. If one cluster, confirm: "I found one cluster: . Assess this one?" If many, ask which cluster(s) or whether to assess the whole estate.
• Failure → STOP (do not retry more than once). Show:

  Cannot list ECS clusters. Check: (1) aws sts get-caller-identity, (2) aws configure get region, (3) that the credentials have ecs:ListClusters.

Action 2 — Describe the selected cluster(s).

aws ecs describe-clusters --clusters <name> --include SETTINGS CONFIGURATIONS TAGS STATISTICS ATTACHMENTS --output json

Show: cluster name, Region, account ID, status, registered capacity providers, default capacity-provider strategy, containerInsights setting, running/pending task counts, and tags.

Action 3 — Enumerate services and capacity providers (verifies read access).

aws ecs list-services --cluster <name> --output json
aws ecs describe-capacity-providers --output json

• Success → proceed. Failure → mark the affected sections UNKNOWN and continue.

Action 4 — Confirm. Ask: "Ready to start the operational review on ( services)?" Proceed only after the user confirms.

Steps 1–8 — Run the assessment

For each domain, in section order, read the corresponding references/ file first, then execute its checks and rate each item with the rubric below. If a whole section fails (permissions, timeouts), mark all its items UNKNOWN with a note and continue — one failed section must not block the rest.

Section-scoped requests load only the matching file(s) and produce a focused report.

Step 9 — Generate the report

Read references/report-generation.md and follow it exactly. See references/scoring-rubric.md for the full rating rules and the mandatory consistency contract.

Rating rubric (summary)

Prioritize by blast radius: security > availability > cost. Every RED must carry a specific, cited, actionable recommendation. Full rules: references/scoring-rubric.md.