Ecs Architect

Amazon ECS Deployment-Model Design and Selection

Choose the right Amazon ECS compute/launch model for a workload, architect the cluster + services around it, and plan the transition when a customer is moving off an older topology. This is the anchor ECS skill — the decision framework every other ECS skill leans on. It answers two coupled questions:

1. Selection — Which of Fargate, ECS on EC2, ECS Managed Instances, ECS Express Mode, or ECS Anywhere/External fits this workload, and what capacity-provider strategy backs it?
2. Design + migration — How is the task sized, how is the network laid out (awsvpc/ENI density), what service parameters are set, and — if an estate already exists — how does it move from EC2 launch type to capacity providers / Managed Instances, or from Service Discovery to Service Connect?

When to Use

• Picking a compute model for a new containerized workload on ECS ("Fargate or EC2?", "should I use Managed Instances?", "is Express Mode right for this?").
• Designing a capacity-provider strategy (Fargate / FARGATE_SPOT / EC2 ASG / Managed Instances mixes) and base/weight ratios.
• Sizing tasks (CPU/memory combinations, ephemeral storage) and planning awsvpc ENI density on EC2.
• Choosing a networking model (awsvpc, task ENI, load-balancer placement) and core service parameters (min/max healthy percent, health-check grace period, placement).
• Planning a launch-type or topology migration: EC2 launch type → capacity providers or Managed Instances; Service Discovery (Cloud Map) → Service Connect.
• Answering "which model + how to architect it, by criteria" for hybrid/edge (ECS Anywhere) or air-gapped constraints.

Don't Use

• Existing application you want to replatform or refactor onto ECS (assess app → replatform vs refactor → target design) — use the ecs-modernize skill once available. This skill is greenfield model selection; ecs-modernize starts from an app and adds the assessment + replatform/refactor decision on top, then leans on this skill for the target design.
• Auditing / scoring a live estate GREEN/AMBER/RED across best-practices domains — use the ecs-operation-review skill once available (Day-2 evaluative). This skill is Day-0 generative.
• Dollar-denominated cost / TCO analysis (Fargate vs EC2 vs Spot economics, Savings Plans, right-sizing with $ findings) — use the ecs-cost-intelligence skill once available. This skill covers cost posture as a selection criterion, not quantified TCO.
• Discovering what is already running (inventory launch types, capacity providers, task defs) — use the ecs-recon skill once available (until then, inventory with aws ecs list-* / describe-*).
• Security / compliance hardening (task-role trust, secrets injection, GuardDuty, PCI/HIPAA/FedRAMP scope) — use ecs-security.
• Deployment strategy + CI/CD (rolling/blue-green/canary mechanics, circuit breaker, pipelines) — use the ecs-devops skill once available. This skill names which deployment controller a model supports; ecs-devops designs the release process.
• Observability stack (FireLens vs awslogs, Container Insights vs Prometheus/ADOT vs 3rd-party) — use the ecs-observability skill once available.
• GPU / ML / inference workload design — use ecs-genai. This skill states only the Fargate-has-no-GPU boundary; the GPU launch-type choice itself (EC2 vs Managed Instances, instance families, Capacity Blocks) and the workload design are ecs-genai's — defer "which ECS launch type for GPU" there.
• App Runner ("should I use App Runner instead?", App Runner→ECS migration) — App Runner is moving to maintenance (no new customers as of April 30, 2026); route the migration design here (target is usually Express Mode; ecs-build renders it).
• Kubernetes / EKS — use eks-design / eks-best-practices. ECS is AWS-proprietary orchestration; if the customer needs the Kubernetes API or cross-cloud portability, ECS is the wrong service.

How This Skill Works

This skill is advisory and generative. It produces recommendations, decision tables, ASCII/Mermaid architecture sketches, and migration plans — WHAT to build and WHY. It does not generate production IaC — once the design is settled, hand it to ecs-build for Terraform generation; for CDK shops, point at the ecs-patterns L3 constructs.

Tech-currency is mandatory. The ECS surface moves fast (e.g. Managed Instances went GA Sept 2025 and keeps adding purchase options; Express Mode and native blue/green are both recent; Fargate PV 1.3.0 and the AWS Copilot CLI both hit end of support in 2026). The full, dated fact list — GA status, Region availability, purchase-option and lifecycle dates, each with its exact AWS URL — is maintained in the reference files, not here, to avoid drift. Before asserting any such claim, read the relevant reference and re-verify it against the live AWS docs. Never state a preview feature as GA, and name lifecycle status precisely.

Discovery-Driven Decision Framework

Do not recommend a model before you have the answers to these. If the workload is an existing estate rather than greenfield, run a discovery/inventory pass first (the ecs-recon skill once available, or aws ecs describe-*), then return here.

First-cut selection heuristic

Need Kubernetes API / cross-cloud portability?      -> Wrong service. Use EKS (eks-design).
Runs on-prem / edge / another cloud?                -> ECS Anywhere (EXTERNAL launch type).
Simple web app/API + want HTTPS URL fast?           -> ECS Express Mode (managed ALB + ACM + autoscaling).
Needs GPU / custom AMI / privileged / host access?  -> ECS on EC2  (Fargate has NO GPU).
Wants EC2 instance flexibility, zero lifecycle ops? -> ECS Managed Instances (AWS provisions + patches EC2).
Serverless, no instance management, standard sizes? -> AWS Fargate (default for most services).

Full criteria matrix, per-model deep dives, and the exact GA/Region/pricing facts (each cited): references/model-selection-framework.md.

The Five Deployment Models (at a glance)

Isolation is also a security selection criterion. Fargate runs one task per microVM, so a container escape is contained to a single task. Managed Instances by default bin-packs multiple tasks onto a shared instance — the docs state plainly there is no task isolation in that default mode; its optional single-task mode places each task on its own dedicated instance for a VM-level isolation boundary equivalent to Fargate's default model. ECS on EC2 with dense bin-packing likewise shares one kernel across many tasks, widening the container-escape blast radius. For multi-tenant or regulated workloads this can favor Fargate (or MI single-task mode) over shared-instance density regardless of cost — take the hardening decision to ecs-security. (MI security — single-task mode · MI shared responsibility — no task isolation by default)

Read the deep dive before recommending: references/model-selection-framework.md.

Capacity-Provider Strategy

Capacity providers decouple where tasks run from how the underlying capacity scales. They apply to Fargate (FARGATE, FARGATE_SPOT), EC2 Auto Scaling groups (with managed scaling + managed termination protection), and Managed Instances.

Key correctness facts (verified — see reference for citations):

• A task/service uses either a launch type OR a capacity-provider strategy, never both in the same call.
• Managed scaling with a mixed-instance-type ASG is supported but constrained: ECS bin-packs against the smallest instance type in the ASG, so tasks whose resource requirements exceed the smallest instance stay stuck in PROVISIONING. Best practice: one resource profile per ASG + capacity provider, not one giant mixed ASG. (This is the precise form of the common "capacity providers don't support mixed ASGs" claim.)
• FARGATE_SPOT gives interruption-tolerant capacity at a discount; combine with a FARGATE base for resilience via base/weight. Managed Instances also supports Spot (capacityOptionType: spot, Dec 2025) and Capacity Reservations (reserved, Feb 2026).
• Bin-pack on memory, not CPU, on EC2 (field heuristic): container-level cpu is a soft share (containers burst into unused CPU, so overcommit is invisible), whereas the container memory hard limit OOM-kills on breach. Note that task-level cpu is a hard ceiling for the whole task — the softness is at the container-share level. Memory bin-packing gives a predictable, safe density guarantee. The binpack/spread strategy configuration applies to EC2/ASG capacity only — Managed Instances does not support task placement strategies (it places for you: best-effort AZ spread, driven by launch-template/task requirements and placement constraints). (task definition CPU/memory · task placement)

Strategy design, base/weight math, scale-in edge cases, and the CapacityProviderReservation metric: references/capacity-and-scaling.md.

Architecture Design

Once the model is chosen, design the task and service:

• Task sizing — valid Fargate CPU/memory combinations (0.25 vCPU up to 16 vCPU / 120 GB, and 32 vCPU with 60/120/244 GB on platform 1.4.0+), ephemeral storage, when to split into sidecars.
• Networking — awsvpc task ENIs, ENI density and trunking on EC2 (awsvpcTrunking), subnet/SG placement, load-balancer choice (ALB/NLB), Service Connect vs Service Discovery.
• Service parameters — deployment min/max healthy percent, health-check grace period, deployment controller choice, placement strategies/constraints (strategies are EC2-only; Fargate and Managed Instances place for you).

Design deep dive: references/architecture-design.md · Networking + ENI density: references/networking-and-eni-density.md.

Launch-Type and Topology Migration

Folded into this skill because "should I move off EC2 launch type?" is the same decision surface as "which model should I be on?".

• EC2 launch type → capacity providers / Managed Instances — how to transition, and the immutability trap: launchType cannot be changed on an existing service via update, so switching from a launch type to a capacity-provider strategy through CloudFormation/CDK replaces (deletes + recreates) the service unless you use the documented escape hatch. The UpdateService API does support launch-type → capacity-provider transitions directly (the reverse is mostly unsupported — you can only revert to the launch type the service was originally created with; see reference).
• Service Discovery (Cloud Map DNS) → Service Connect — why Service Connect is the recommended target, and how the cutover works (config changes apply at deployment, connection draining).

Migration playbook with exact supported transitions and citations: references/launch-type-migration.md.

Shared ECS Best-Practices Corpus

The "what good looks like" knowledge that this skill, ecs-operation-review, and ecs-cost-intelligence all draw on — task-definition hygiene, image/SOCI, capacity correctness, deployment safety, health checks, and the shared-responsibility split per model. Factor-out to a standalone skill is deferred; it lives here as the shared design baseline — deep domains (security, cost, observability) own the depth in their own references: references/best-practices-corpus.md.

Output Discipline

• Recommend, then justify against the customer's stated criteria — never lead with a model before the discovery table is answered.
• Cite every GA/Region/quota/date claim to an AWS doc URL (the references carry them). If you cannot verify a fast-moving claim live, say so explicitly rather than asserting it.
• State constraints precisely: "Fargate has no GPU", "Managed Instances is not available in the China Regions" (it is in GovCloud (US) since Nov 2025), "PV 1.3.0 reaches end of support June 30, 2026" — exact, not hand-wavy.
• Produce decision tables, an architecture sketch, a capacity-provider strategy, and (when migrating) a step-ordered transition plan. Hand off cost to ecs-cost-intelligence, security to ecs-security, deployment mechanics to ecs-devops.

Detailed References

Progressive disclosure — essential guidance is above; load a reference when the task needs it:

• references/model-selection-framework.md — Read when choosing the compute/launch model. Full criteria matrix; per-model deep dives (Fargate, ECS on EC2, Managed Instances, Express Mode, ECS Anywhere) with GA/Region/pricing facts, each cited.
• references/capacity-and-scaling.md — Read when designing capacity-provider strategy or cluster auto scaling. Base/weight, managed scaling, mixed-ASG constraint, scale-in edge cases, Spot.
• references/networking-and-eni-density.md — Read when planning task networking. awsvpc, task ENIs, ENI trunking on EC2, subnet/SG design, ALB vs NLB, Service Connect vs Service Discovery.
• references/architecture-design.md — Read when sizing tasks and setting service parameters. Fargate CPU/memory table, ephemeral storage, deployment percentages, health-check grace period, placement.
• references/launch-type-migration.md — Read when moving off EC2 launch type or from Service Discovery to Service Connect. Supported transitions, the launchType-immutability trap, cutover steps.
• references/best-practices-corpus.md — Read for the shared "what good looks like" knowledge. Task-def hygiene, images/SOCI, deployment safety, health, shared responsibility per model.

Sources

• Amazon ECS Developer Guide
• Amazon ECS Best Practices Guide
• Amazon ECS FAQs