Short answer: Prefect won’t auto-scale your ECS capacity for you. The Prefect ECS worker just submits RunTask requests to ECS. If ECS can’t place the task due to insufficient EC2 capacity, the worker will retry task creation a few times with backoff, but it will not add instances or change your cluster size. What to use for autoscaling with EC2 launch type: - Use an Auto Scaling Group (ASG) behind your ECS cluster. Then either: - Capacity providers (preferred for services): Create an ECS Capacity Provider linked to the ASG and attach it to the cluster. Note: managed scaling on capacity providers primarily targets ECS services; one-off RunTask jobs (what Prefect launches) do not reliably trigger scale-out on their own. - ASG policies on cluster reservation metrics: Add ASG target-tracking/step scaling policies using CloudWatch ECS cluster metrics (e.g., CPUReservation/MemoryReservation) so the ASG scales when the cluster is constrained. This works for both services and standalone tasks. - If you stick to a single EC2 host, there’s nothing to “auto-scale”—tasks will remain PENDING if they don’t fit. In that case, either increase the instance size or move to an ASG with >1 instances. How Prefect interacts with ECS: - Prefect’s ECS worker submits RunTask with your work pool variables (cluster, image, CPU/memory, networking, etc.). If placement fails (e.g., “RESOURCEMEMORY”/“RESOURCECPU”), the worker will retry a handful of times with jitter. If capacity appears during that window (because your ASG scaled up), the task will start. - You can set EC2 launch type and capacity provider strategy via the ECS work pool variables. Use one or the other: - launch_type: EC2 - or capacity_provider_strategy: [{"name": "MyEc2CP", "weight": 1, "base": 0}] - You can also set per-task CPU/memory so they fit your instances. For your POC, something small like CPU 512 and memory 1024 MiB is fine. Example work pool variables (EC2 launch type):

{
  "cluster": "my-ecs-cluster",
  "launch_type": "EC2",
  "subnets": [
    "subnet-xxxxx"
  ],
  "security_groups": [
    "sg-xxxxxx"
  ],
  "task_role_arn": "arn:aws:iam::123456789012:role/PrefectTaskRole",
  "execution_role_arn": "arn:aws:iam::123456789012:role/PrefectTaskExecutionRole",
  "image": "<http://123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/myimage:latest|123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/myimage:latest>",
  "cpu": 512,
  "memory": 1024
}

Example using a capacity provider strategy instead of launch_type (don’t set both):

{
  "cluster": "my-ecs-cluster",
  "capacity_provider_strategy": [
    {
      "name": "MyEc2CapacityProvider",
      "weight": 1,
      "base": 0
    }
  ],
  "subnets": [
    "subnet-xxxxx"
  ],
  "security_groups": [
    "sg-xxxxxx"
  ],
  "task_role_arn": "arn:aws:iam::123456789012:role/PrefectTaskRole",
  "execution_role_arn": "arn:aws:iam::123456789012:role/PrefectTaskExecutionRole",
  "image": "<http://123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/myimage:latest|123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/myimage:latest>",
  "cpu": 512,
  "memory": 1024
}

Given your setup: - Running Prefect Server + worker + ECS on a single EC2 instance in ap-southeast-1 means you won’t get autoscaling unless you introduce an ASG-backed ECS cluster. If you want the cluster to grow when jobs queue up, set up an ASG and either capacity providers (for services) or ASG scaling on ECS cluster reservation metrics for RunTask patterns. Helpful docs: - Prefect ECS guide: Prefect AWS ECS guide - AWS ECS capacity providers overview: AWS: Capacity providers - ECS cluster auto scaling considerations: AWS: Cluster Auto Scaling Questions to tailor the setup:

- Are you open to putting your ECS cluster instances in an ASG so it can scale beyond your single EC2 host? - Do you want me to suggest a minimal ASG + capacity provider configuration for ap-southeast-1 and small POC CPU/memory?

Short answer: ECS can’t “resize” a running task. Prefect’s ECS worker sets CPU/memory at launch; if utilization later hits 80%, ECS won’t auto-bump that task to 4GB. You must start a new task with larger resources. A couple of practical patterns to get what you want: 1) Route runs to “small” vs “large” deployments - Create two ECS deployments of the same flow with different job variables (2GB and 4GB). - Add a light “router” step (upstream flow or a pre-check in your flow) that decides which deployment to trigger based on inputs, historical size, or a quick probe. This gives you vertical scaling between runs. Example deployments (Prefect 3.x):

from prefect import flow
from prefect.deployments import run_deployment

@flow
def my_flow(...):
    ...

# Small
my_flow.deploy(
    name="ecs-small",
    work_pool_name="my-ecs-pool",
    job_variables={
        "launch_type": "EC2",
        "cpu": 1024,          # example
        "memory": 2048,       # 2GB
        "cluster": "my-ecs-cluster",
        "subnets": ["subnet-xxx"],
        "security_groups": ["sg-xxx"],
        "image": "<http://123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/myimage:latest|123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/myimage:latest>",
    },
)

# Large
my_flow.deploy(
    name="ecs-large",
    work_pool_name="my-ecs-pool",
    job_variables={
        "launch_type": "EC2",
        "cpu": 2048,          # example
        "memory": 4096,       # 4GB
        "cluster": "my-ecs-cluster",
        "subnets": ["subnet-xxx"],
        "security_groups": ["sg-xxx"],
        "image": "<http://123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/myimage:latest|123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/myimage:latest>",
    },
)

# Optional: a simple router flow
@flow
def router(should_use_large: bool, params: dict=None):
    target = "my_flow/ecs-large" if should_use_large else "my_flow/ecs-small"
    return run_deployment(name=target, parameters=params or {})

2) Abort-and-retry with a larger size (advanced) - Monitor your own process memory (e.g., psutil) early in the run. If you detect you’ll exceed 2GB, programmatically launch the “large” deployment and exit the current run. - Caveat: you’ll lose partial work unless you checkpoint or make your flow idempotent. Why ECS service autoscaling won’t help here - Service autoscaling changes the number of tasks, not the memory size of an existing task. - Vertical “autoscaling” (changing CPU/memory of a running task) isn’t supported by ECS; you must start a new task definition/revision with higher resources. Fit with your environment - You’re on a single EC2 host (~8GB RAM) running Prefect Server + worker. A 4GB task may fail placement if the host is busy. If you plan to run both 2GB and 4GB tasks, consider: - Keep concurrency low (maybe 1 ECS task at a time), or - Move the ECS cluster into an Auto Scaling Group so capacity can grow when needed. Helpful docs - Prefect AWS ECS guide: Prefect AWS ECS guide - Customize job variables (per-deployment): Customize job variables A quick question to tailor this: do you want to upscale mid-run when utilization crosses 80%, or is scaling between runs acceptable? If between runs is fine, I’ll sketch a minimal “router” that bases the decision on recent run metadata or input size.