Lambda Execution Role (Logs Only)

The minimum a Lambda function needs to write its own CloudWatch Logs — nothing else.

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": "WriteOwnLogGroup",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:REGION:ACCOUNT_ID:log-group:/aws/lambda/YOUR-FUNCTION-NAME:*"
    }
  ]
}

Why it's scoped this way

• This is the entire permission set AWS's own AWSLambdaBasicExecutionRole grants — reproduced here scoped to one function's log group instead of Resource: "*".
• Any permission your function actually needs (reading a table, calling another service) belongs in a separate, equally-scoped statement — resist the urge to widen this one.
• The trust policy (not shown — attach separately) should restrict sts:AssumeRole to Service: lambda.amazonaws.com with an aws:SourceArn condition if you want to prevent confused-deputy reuse across functions.

Hardening it further

• If the function reads/writes other AWS resources, add scoped statements per resource rather than reusing this log statement's Resource.
• Set a log retention policy on the log group — a scoped IAM policy does not expire old logs by itself.

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

Related templates

• CloudWatch Logs Write (Scoped Log Group)
• DynamoDB CRUD (Single Table)

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