EC2 and ECS: connecting to an SQS queue on the canvas ALWAYS generates a scoped sqs:SendMessage/ReceiveMessage(/DeleteMessage for ECS) policy at export time, regardless of edge direction, connected-role presence, or how the canvas was built. For ECS specifically, connect the queue to the SERVICE node — the Task Definition node has no SQS connection rule of its own, so a queue connected only there gets neither a grant nor a warning. You should not see this warning for an ECS Service or an EC2 instance; if you do, it is a real bug. Lambda↔SQS can mean two different things — the queue triggering the function (an event source mapping) or the function sending/receiving messages via the SDK — so CloudStack Canvas only generates the send/receive/delete policy once you tell it which one you mean: click the edge label and choose "Send/Receive Access" (every direction defaults to the queue-trigger meaning until you explicitly pick access).
Paste into this field
IAM Role → permissions policy (or draw the edge on the canvas)Output looks like
Canvas edge: Lambda → SQS (auto-generates an sqs:ReceiveMessage/DeleteMessage policy)Click the edge label between the Lambda and the queue and choose "Send/Receive Access" in the chooser. Re-open Export and the warning is gone.
CONSUMER (Lambda event source / polling the queue): use the policy below. PRODUCER (only sending): replace the actions with just "sqs:SendMessage" and "sqs:GetQueueAttributes". Replace REGION, ACCOUNT, my-queue.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"sqs:ReceiveMessage",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes"
],
"Resource": "arn:aws:sqs:REGION:ACCOUNT:my-queue"
}]
}Name it AllowSQSAccess and click "Create policy". Note: if the Lambda is triggered by the queue, an event source mapping also requires these same receive/delete permissions.
Once you have the value, go back to CloudStack Canvas and paste it into the highlighted field.
CloudStack Canvas · Validation Guide