What this prompt does
This prompt drives the AI to design an ECS Fargate deployment for [application_type] running [container_count] containers. It builds a task definition with [task_cpu] CPU, [task_memory] memory, [log_driver] logging, secrets from [secrets_source], and health checks; an ECS Service with [desired_count] tasks and zero-downtime deployment percentages; an ALB with health-check path [health_path]; VPC networking using [subnet_strategy]; auto-scaling on [scaling_metric] between [min_tasks] and [max_tasks]; service discovery via [service_mesh]; a CI/CD workflow to ECR and ECS; and a Fargate-versus-Spot comparison for [spot_eligible] workloads.
The structure works because it pins the details that make container deploys predictable — deployment percentages (minimumHealthyPercent 100, maximumPercent 200), health checks, and a Spot split — early. Putting tasks in private subnets behind an ALB and restricting traffic to ALB-to-task keeps the network surface tight. The Spot split lets cost-tolerant workloads run cheaper without risking the latency-sensitive ones. Sizing [task_cpu] and [task_memory] together up front matters because Fargate only accepts specific CPU/memory pairings, and getting the combination wrong is the kind of error that surfaces only at deploy time.
When to use it
- You want zero-downtime container deploys without managing the underlying nodes.
- You need a task definition with the right
[task_cpu]/[task_memory]split and proper health checks. - You want auto-scaling on
[scaling_metric]between[min_tasks]and[max_tasks]configured correctly. - You need ALB load balancing with a sensible
[health_path]and deregistration delay. - You want a CI/CD workflow that builds, pushes to ECR, and triggers a rolling ECS deployment.
- You want to run
[spot_eligible]workloads on Fargate Spot to cut cost without risking critical tasks.
Example output
Expect a deployment spec: a task definition with container definitions, [log_driver] logging, secrets from [secrets_source], and health checks; an ECS Service config with deployment percentages for zero downtime; an ALB and target-group setup with [health_path]; a VPC layout following [subnet_strategy] with tight security groups; an Application Auto Scaling policy on [scaling_metric]; a Cloud Map service-discovery config; a CI/CD workflow; and a Fargate-vs-Spot cost comparison for [spot_eligible].
Pro tips
- Pin deployment percentages to minimumHealthyPercent 100 and maximumPercent 200 for true zero-downtime rolling deploys; lower minimums risk a brief capacity dip.
- Set
[health_path]to a real readiness endpoint and tune the deregistration delay so in-flight requests drain before a task is killed. - Put tasks in private subnets per
[subnet_strategy]and allow only ALB-to-task traffic in the security group; do not expose tasks directly. - Right-size
[task_cpu]and[task_memory]together — Fargate only allows valid CPU/memory combinations, so an arbitrary pair will be rejected. - Run
[spot_eligible]background workers on Fargate Spot but keep latency-sensitive tasks on regular Fargate, since Spot capacity can be reclaimed. - Pull secrets from
[secrets_source]rather than baking them into the task definition environment, which keeps them out of plaintext task config. - Wire the CI/CD workflow to build, push to ECR, and trigger the rolling deployment in one pipeline so a deploy is a single tracked action rather than a manual sequence of steps.
