Short answer: No. SQS and EventBridge are not required for ECS workers. What you likely saw applies to AWS “push work pools” and/or event‑driven architectures. In the standard ECS worker (pull) model, a Prefect worker polls your ECS work pool and starts ECS tasks; there’s no dependency on SQS or EventBridge. Given your setup (Prefect Server on an EC2 host, ECS launch type EC2), you can run an ECS work pool with a long‑lived worker and skip SQS/EventBridge entirely. What you do need for ECS workers (EC2 launch type): - ECS cluster with EC2 capacity (container instances registered) - Container image registry (e.g., ECR) - IAM - Task execution role (AmazonECSTaskExecutionRolePolicy) for pulling images/logging - Task role for your flow permissions (e.g., access to RDS if needed) - The credential used by the Prefect worker must be able to run tasks and pass the above roles (see sample below) - Networking - Subnets/Security Groups so ECS tasks can reach RDS (allow inbound from task SG to RDS SG) - Optional: CloudWatch Logs for task logs Example minimal IAM permissions for the identity your Prefect worker uses to submit tasks (adjust ARNs and narrow resources as needed):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecs:RunTask",
        "ecs:DescribeTasks",
        "ecs:DescribeTaskDefinition",
        "ecs:StopTask"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::<ACCOUNT_ID>:role/<YourECSTaskExecutionRole>",
        "arn:aws:iam::<ACCOUNT_ID>:role/<YourECSTaskRole>"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecs:RegisterTaskDefinition",
        "ecs:DeregisterTaskDefinition"
      ],
      "Resource": "*"
    }
  ]
}

Docs: see the ECS guide for Prefect 3.x ECS guide Notes: - If you provide a pre‑created task definition ARN in your work pool, you can drop Register/DeregisterTaskDefinition from the worker’s permissions. - Push work pools (which can involve SQS/EventBridge) are generally a Prefect Cloud feature; since you’re on Prefect Server, you’ll use workers (pull) and don’t need those services. If you want, I can help tailor a minimal IAM policy for your EC2 launch type and RDS access.

Got it — if you’re running Prefect Server and an ECS worker as two Fargate services and just need to update IAM (no SQS/EventBridge), here’s a clean setup. You’ll typically have three IAM roles: 1) One execution role (shared) for all ECS tasks to pull images and write logs 2) A task role for the ECS worker (to call ECS APIs and launch flow-run tasks) 3) A task role for the flow-run tasks themselves (what your user code runs with) Below are the trust policies and permissions. Replace placeholders like <ACCOUNT_ID>, <REGION>, <CLUSTER_NAME>, and role ARNs. 1) Execution role (shared) - Attach trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "<http://ecs-tasks.amazonaws.com|ecs-tasks.amazonaws.com>"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

- Attach AWS managed policy: - AmazonECSTaskExecutionRolePolicy - Optional inline policy (lets tasks create the log group if it doesn’t exist):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "logs:CreateLogGroup",
      "Resource": "*"
    }
  ]
}

Attach this execution role to: - Your Prefect Server Fargate service task - Your ECS worker Fargate service task - Flow-run tasks launched by the worker (via the work pool settings) 2) ECS worker task role (launches tasks) - Trust policy (same as above):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "<http://ecs-tasks.amazonaws.com|ecs-tasks.amazonaws.com>"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

- Permissions policy (minimal to run/deregister/describe tasks and pass roles). You can start permissive and tighten later:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EcsControl",
      "Effect": "Allow",
      "Action": [
        "ecs:RunTask",
        "ecs:StopTask",
        "ecs:DescribeTasks",
        "ecs:DescribeTaskDefinition",
        "ecs:RegisterTaskDefinition",
        "ecs:DeregisterTaskDefinition",
        "ecs:ListTasks",
        "ecs:TagResource"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PassRolesToFlowTasks",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": [
        "arn:aws:iam::<ACCOUNT_ID>:role/PrefectFargateExecutionRole",
        "arn:aws:iam::<ACCOUNT_ID>:role/PrefectFlowRunTaskRole"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "<http://ecs-tasks.amazonaws.com|ecs-tasks.amazonaws.com>"
        }
      }
    }
  ]
}

Optional tightening for RunTask/StopTask to a specific cluster (if you want):

{
  "Sid": "RestrictToCluster",
  "Effect": "Allow",
  "Action": [
    "ecs:RunTask",
    "ecs:StopTask"
  ],
  "Resource": "*",
  "Condition": {
    "ArnEquals": {
      "ecs:cluster": "arn:aws:ecs:<REGION>:<ACCOUNT_ID>:cluster/<CLUSTER_NAME>"
    }
  }
}

Attach this worker task role to: - Your ECS worker Fargate service (this is the role the worker container uses) 3) Flow-run task role (what your flows run as) - Trust policy (same as above):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "<http://ecs-tasks.amazonaws.com|ecs-tasks.amazonaws.com>"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

- Permissions policy: - If your flows only need to reach RDS via username/password (managed by Prefect) and no AWS APIs, you can keep this empty (no inline permissions). Networking to RDS is handled by your VPC/subnet/SG config, not IAM. - If flows need AWS APIs (e.g., S3), add those here later. How to wire this in Prefect (no SQS/EventBridge): - Prefect Server service task: use the shared execution role; task role can be minimal/empty unless Server needs AWS APIs. - ECS worker service task: use the shared execution role + the ECS worker task role (above). - Prefect ECS work pool base job template (in the UI): set the executionRoleArn to the shared execution role and the taskRoleArn to PrefectFlowRunTaskRole. Also set cluster, subnets, security groups, and launch type FARGATE. Reference docs:

- Prefect ECS guide (3.x): ECS guide Notes: - Make sure the CloudWatch Logs log groups you reference exist (or keep logs:CreateLogGroup in the execution role). - If you pre-create and pin a Task Definition ARN in your work pool, you can remove ecs:RegisterTaskDefinition and ecs:DeregisterTaskDefinition from the worker role. - No SQS/EventBridge needed with the worker (pull) model. If you share your cluster name and role names, I can fill the ARNs precisely for ap-southeast-1.

Here’s a concise breakdown of pull vs push in Prefect 3.x: Pull (worker-based) - How it works: You run a long-lived Prefect worker that continuously polls a work pool and launches infrastructure (e.g., ECS tasks) for flow runs. - Infra you need: A worker process (e.g., Fargate service or EC2), plus your target runtime (ECS EC2/Fargate). No SQS/EventBridge required. - Typical IAM: The worker’s task role needs to call ECS APIs (RunTask/Describe/Stop, optional Register/DeregisterTaskDefinition) and pass your task/execution roles. Flow-run tasks use their own task role for AWS access if needed. - When to use: You want full control, already have always-on capacity (like a worker service), need tighter customization, or you’re using Prefect Server (self-hosted). Push (serverless, no worker) - How it works: Prefect pushes flow runs directly to cloud-native/serverless infra without a persistent worker. On AWS this often involves provisioning AWS services to broker/run work. - Infra involved: Typically requires AWS services like SQS and EventBridge to coordinate/run tasks (depending on provider implementation). - Typical IAM: Prefect Cloud provisions and uses AWS resources/roles to submit jobs on demand (no worker to manage). - When to use: You want zero always-on worker processes, prefer fully on-demand/serverless execution, and you’re using Prefect Cloud. Given your setup (Prefect Server + ECS worker as Fargate services), stick with pull. You do not need SQS or EventBridge. Helpful links - ECS worker guide (Prefect 3.x): ECS guide - Background on push vs pull (blog): Work pools and workers and Event-driven serverless pipelines If you’d like, I can double-check your ECS work pool template and worker task role to ensure it’s aligned with the pull model and doesn’t assume SQS/EventBridge.