Short answer: inside a single flow run, your Prefect tasks already run “warm” in the same ECS task. Between separate flow runs, Prefect’s ECS worker launches a new ECS task each time; there’s no built‑in way to keep an ECS/Fargate task warm across flow runs in Prefect 3.x. Ways to reduce cold start time: - Keep work in one flow run - If you currently split work into multiple flows/subflows, combine steps into a single flow where possible so they share one ECS task. - Use EC2 capacity instead of Fargate - If you can run ECS tasks on EC2 (with a capacity provider and pre‑provisioned instances), task startup is typically faster than Fargate. - Prebuild and slim your image - Bake all dependencies into the image, push to ECR in the same region, and keep the image small to speed pulls. - Reuse a task definition - Configure your ECS work pool’s base job template to point at a pre‑registered

taskDefinitionArn

so Prefect doesn’t need to register a new revision at runtime. - Example base job template snippet:

{
      "taskDefinitionArn": "arn:aws:ecs:REGION:ACCOUNT_ID:task-definition/YOUR_TASK_DEF:REV",
      "cluster": "your-ecs-cluster",
      "launchType": "FARGATE",
      "networkConfiguration": {
        "awsvpcConfiguration": {
          "subnets": ["subnet-abc", "subnet-def"],
          "securityGroups": ["sg-123"],
          "assignPublicIp": "ENABLED"
        }
      },
      "overrides": {
        "containerOverrides": [
          {
            "name": "your-container",
            "command": []  // Prefect fills this in per run
          }
        ]
      }
    }

- Allocate a bit more CPU - A higher CPU allocation can speed image extraction and process startup. - Run a long‑lived worker on your own infrastructure - If avoiding cloud task cold‑starts is critical, run a Prefect Process or Docker worker on a long‑lived EC2 instance or in an ECS Service and let it execute flows locally/with Docker—this trades elastic scaling for consistently “warm” execution. Docs: ECS worker guide A couple clarifications that will help me tailor guidance: - Are you using Fargate or EC2 for ECS capacity? - Roughly how much startup time are you seeing per run and what’s your image size? - Are the steps you want to keep “warm” separate flows/subflows today, or just tasks within one flow?

Got it — you’re on Fargate and the blocker is the ECS RunTask rate limit, not cold-start latency. There isn’t a built-in “keep ECS tasks warm across flow runs” feature in Prefect 3.x. Each ECS flow run is a new

RunTask

call, so lots of small runs/subflows can run into the per‑second limit. Practical patterns to avoid RunTask throttling while keeping things warm: 1) Run subflows in-process under a single parent flow - In Prefect 3.x, calling an

@flow

from another

@flow

executes in the same process as the parent by default. That means one ECS task per parent flow run and all subflows share the same warm container. - If you’re currently triggering subflows with

run_deployment

(which creates separate flow runs/infrastructure), switch to direct subflow calls from the parent where possible. 2) Use long‑lived workers instead of per‑run ECS tasks - Run a long‑lived Process worker inside an ECS Service (Fargate). The worker will execute many flow runs in the same continuously running container, avoiding ECS

RunTask

calls per run. - How: - Create a Process work pool and deploy your flows to it. - Build an image that includes your code and Prefect. - Create an ECS Service (Fargate) running that image with the command:

prefect worker start -p <your-process-pool> -q <your-queue>

- Scale the Service’s desired count to the number of “warm slots” you want. You can even run one service per “subflow family” if you need dedicated warm lanes. - Tradeoffs: you lose the full isolation you get from one ECS task per run and must manage capacity in the service, but you eliminate the

RunTask

rate limit bottleneck. 3) Smooth burstiness with Prefect concurrency controls - Set a work pool concurrency limit to cap simultaneous starts and avoid bursting into ECS rate limits:

prefect work-pool set-concurrency-limit "<ecs-pool-name>" 20

- Use tag-based concurrency limits to throttle specific classes of flows: - Tag-based concurrency limits - This doesn’t keep tasks warm, but it prevents hitting the per‑second quota and smooths load. 4) If you must stay on ECS worker/Fargate - There’s no “warm pool” for ECS worker tasks today. If you have to keep using ECS worker, the only lever is throttling (via work-pool/tag concurrency, fewer workers, or application-level backoff) to stay under AWS limits. Docs: - ECS worker guide - Work pools overview A couple questions to tailor this: - Are you invoking those “separate subflows” via

run_deployment

, or are they nested

@flow

calls today? - Would running a long‑lived Process worker in an ECS Service fit your constraints (i.e., fewer

RunTask

calls, persistent warm slots, acceptable to trade isolation for consistency)?