@Marvin My Prefect worker for an ECS work pool produces the following warning:

WARNING | prefect_aws.observers.ecs - SQS queue '...' does not exist in region 'eu-central-1'...

. The queue name and region in the message are correct and the queue actually exists in the same account. How can I resolve this issue?

✅ thought for 709.5 seconds

does your worker process have the right creds?

That warning is emitted by the ECS observer inside the worker when it tries to resolve your SQS queue via the SQS GetQueueUrl API and gets “NonExistentQueue”. In practice, AWS returns that error not only when a queue is missing, but also when the caller lacks permission to access it. So the most common causes are: - The worker’s IAM task role does not have SQS permissions on that queue - The SQS queue policy does not allow the worker’s role - The queue is KMS-encrypted and the worker’s role lacks KMS permissions - A mismatch in what you pass for the queue identifier (name vs URL/ARN) or a missing .fifo suffix for FIFO queues - Region mismatch between the worker and the queue How to fix it 1) Ensure the worker container is running with an IAM task role that can access the queue - In ECS, the “task role” (not the execution role) is what your container uses for AWS API calls. - Attach a policy to the task role that includes at least: - sqs:GetQueueUrl - sqs:ReceiveMessage - sqs:DeleteMessage - sqs:GetQueueAttributes - sqs:ChangeMessageVisibility Example policy snippet (replace account, region, and queue name):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PrefectObserverSQSAccess",
      "Effect": "Allow",
      "Action": [
        "sqs:GetQueueUrl",
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueAttributes",
        "sqs:ChangeMessageVisibility"
      ],
      "Resource": "arn:aws:sqs:eu-central-1:123456789012:my-queue"
    }
  ]
}

2) If the queue is KMS-encrypted, grant KMS permissions to the task role - Add KMS permissions on the CMK used by the queue (and update the key policy if needed): - kms:Decrypt - kms:GenerateDataKey - kms:DescribeKey Example KMS permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PrefectObserverKMSAccess",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:eu-central-1:123456789012:key/<key-id>"
    }
  ]
}

3) Confirm the queue identifier and region are correct - Provide the queue name only (e.g.,

my-queue

or

my-queue.fifo

), not the full URL or ARN. - Make sure the

.fifo

suffix is included for FIFO queues. - Ensure the observer is targeting

eu-central-1

and the worker container has that region configured. In Prefect 3.x, the ECS observer (from prefect-aws) reads its SQS settings from the Prefect settings. You can set them as environment variables on the worker container, for example:

PREFECT_AWS__ECS_OBSERVER__SQS__QUEUE_NAME=my-queue
PREFECT_AWS__ECS_OBSERVER__SQS__QUEUE_REGION=eu-central-1

4) If your worker runs in private subnets, ensure network access to SQS - Configure an SQS VPC endpoint in the same region if there’s no internet egress. Without connectivity, you’d typically see connection errors, but it’s still worth verifying. After updating IAM/KMS and environment variables, restart the worker so it picks up the changes. Links - ECS guide for Prefect AWS integration: Prefect AWS ECS Guide - Prefect AWS integration repo (source for the ECS observer): prefect-aws on GitHub If you’re still seeing the warning after these changes, can you share: - Whether the queue is FIFO and how you’re specifying its name - The IAM role ARN your worker container runs with (task role), and whether that role has the policies above - Whether the queue uses KMS encryption and which key This will help narrow it down quickly.

@Nate Thank you! I created the policy but I did not actually attach it to the task role. 👍