SQS Consumer (Single Queue)

Receive, process, and delete messages from one queue — no SendMessage, no queue-config changes.

Policy

Replace the placeholder ARNs (YOUR-BUCKET-NAME, ACCOUNT_ID, REGION, etc.) with your real resource identifiers before use.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ConsumeFromOneQueue",
      "Effect": "Allow",
      "Action": [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueAttributes"
      ],
      "Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:YOUR-QUEUE-NAME"
    }
  ]
}

Why it's scoped this way

• No sqs:SendMessage — a pure consumer role should not be able to inject messages back into its own queue, which prevents a compromised consumer from feeding itself attacker-controlled input.
• sqs:GetQueueAttributes is included because most SDK long-polling / visibility-timeout logic calls it implicitly; omitting it causes cryptic failures rather than a clean AccessDenied on the actual intended call.
• No sqs:SetQueueAttributes, sqs:DeleteQueue, or sqs:PurgeQueue — this role cannot change the queue's configuration or discard unprocessed messages.

Hardening it further

• If the queue has a dead-letter queue, this role typically does not need any permissions on the DLQ ARN — grant those separately to whatever process inspects failed messages.
• For a producer role, mirror this pattern with only sqs:SendMessage and sqs:GetQueueAttributes.

Paste your finished policy into the free AI-Powered IAM analyzer to catch anything you loosened while filling it in.

Related templates

• DynamoDB CRUD (Single Table)
• S3 Read-Only Access

Amazon Web Services (AWS) is a trademark of Amazon.com, Inc. Shieldly is not affiliated with, endorsed by, or sponsored by Amazon Web Services.