EC2: connecting to a DynamoDB table on the canvas ALWAYS generates a scoped dynamodb:GetItem/PutItem/Query/Scan policy at export time, regardless of edge direction, connected-role presence, or how the canvas was built. You should not see this warning for EC2; if you do, it is a real bug. Lambda↔DynamoDB can mean two different things — the table triggering the function via DynamoDB Streams, or the function reading/writing the table via the SDK — so CloudStack Canvas only generates the CRUD policy once you tell it which one you mean: click the edge label and choose "Read/Write Access" (every direction defaults to the Streams-trigger meaning until you explicitly pick access). ECS has no built-in compute→DynamoDB connection at all (no "DynamoDB Access" edge exists for an ECS Service or Task Definition) — for ECS, the manual policy below is the only path.
Paste into this field
IAM Role → permissions policy (or draw the edge on the canvas)Output looks like
Canvas edge: Lambda → DynamoDB (auto-generates a dynamodb:GetItem/PutItem policy)Click the edge label between the Lambda and the table and choose "Read/Write Access" in the chooser. Re-open Export and the warning is gone.
Replace REGION, ACCOUNT, and MyTable. The /index/* resource line is needed only if your code queries a Global or Local Secondary Index.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem", "dynamodb:PutItem",
"dynamodb:UpdateItem", "dynamodb:DeleteItem",
"dynamodb:Query", "dynamodb:Scan",
"dynamodb:BatchGetItem", "dynamodb:BatchWriteItem"
],
"Resource": [
"arn:aws:dynamodb:REGION:ACCOUNT:table/MyTable",
"arn:aws:dynamodb:REGION:ACCOUNT:table/MyTable/index/*"
]
}]
}Name it AllowDynamoDBAccess and click "Create policy".
Once you have the value, go back to CloudStack Canvas and paste it into the highlighted field.
CloudStack Canvas · Validation Guide