Lambda実行ロールとリソースポリシー — 2種類の権限モデルの使い分け

2種類の権限モデル

Lambda関数には2種類の権限設定が存在する。

実行ロール（Execution Role）:
  → Lambda関数が「何をできるか」を定義
  → Lambda関数→AWSサービスへのアクセス権限

リソースベースポリシー（Resource-based Policy）:
  → 「誰がLambdaを呼び出せるか」を定義
  → AWSサービス/アカウント→Lambda関数への呼び出し権限

実行ロールの設定

// Lambda実行ロールに付与するポリシー例
{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:UpdateItem"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/Orders"
    }
  ]
}

# 実行ロールの作成
aws iam create-role \
  --role-name LambdaExecutionRole \
  --assume-role-policy-document '{
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "lambda.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# 基本実行ポリシーのアタッチ（CloudWatchログの書き込み）
aws iam attach-role-policy \
  --role-name LambdaExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

リソースベースポリシーの設定

他のAWSサービスがLambdaを呼び出すには、Lambda側のリソースポリシーにAllow設定が必要だ。

# S3からの呼び出しを許可
aws lambda add-permission \
  --function-name image-processor \
  --statement-id allow-s3-invoke \
  --action lambda:InvokeFunction \
  --principal s3.amazonaws.com \
  --source-arn arn:aws:s3:::my-uploads-bucket \
  --source-account 123456789012

# EventBridgeからの呼び出しを許可
aws lambda add-permission \
  --function-name scheduled-task \
  --statement-id allow-eventbridge \
  --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn arn:aws:events:ap-northeast-1:123456789012:rule/my-rule

# API Gatewayからの呼び出しを許可
aws lambda add-permission \
  --function-name api-handler \
  --statement-id allow-apigw \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:ap-northeast-1:123456789012:abc123/*/POST/orders"

クロスアカウントでのLambda呼び出し

アカウントBのLambdaをアカウントAから呼び出す場合：

# アカウントBのLambdaにアカウントAからの呼び出しを許可（リソースポリシー）
aws lambda add-permission \
  --function-name my-function \
  --statement-id cross-account-invoke \
  --action lambda:InvokeFunction \
  --principal arn:aws:iam::111111111111:role/InvokerRole

// アカウントAのIAMポリシー（InvokerRoleに付与）
{
  "Statement": [{
    "Effect": "Allow",
    "Action": "lambda:InvokeFunction",
    "Resource": "arn:aws:lambda:ap-northeast-1:222222222222:function:my-function"
  }]
}

VPCアクセスとの組み合わせ

Lambda関数をVPCに配置する場合、追加の権限が必要だ。

// VPC内のLambdaに必要なENI作成権限
{
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ec2:CreateNetworkInterface",
      "ec2:DescribeNetworkInterfaces",
      "ec2:DeleteNetworkInterface",
      "ec2:AssignPrivateIpAddresses",
      "ec2:UnassignPrivateIpAddresses"
    ],
    "Resource": "*"
  }]
}
// または マネージドポリシー:
// arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole

Lambda実行ロールのベストプラクティス

# ❌ 過剰な権限（S3全操作 + 全バケット）
{
  "Action": "s3:*",
  "Resource": "*"
}

# ✅ 最小権限（必要な操作と特定バケットのみ）
{
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/data/*"
}

リソースポリシーの確認

# Lambda関数のリソースポリシーを確認
aws lambda get-policy \
  --function-name my-function \
  --query 'Policy' | python3 -m json.tool

# リソースポリシーから特定のStatementを削除
aws lambda remove-permission \
  --function-name my-function \
  --statement-id allow-s3-invoke

試験頻出ポイント

シナリオ	回答
S3イベントでLambdaを起動したい	S3通知設定 + Lambda側にリソースポリシー追加
LambdaがDynamoDBに書き込みたい	実行ロールにDynamoDB権限を付与
クロスアカウントからLambdaを呼び出す	Lambda側にリソースポリシー + 呼び出し元にIAMポリシー
Lambda VPC設定でENI作成エラー	実行ロールにEC2 ENI権限が不足
API GatewayへのLambdaの許可	add-permissionでAPIGatewayプリンシパルを許可

まとめ

Lambdaの権限設計は「実行ロール（Lambda→外部サービスへの権限）」と「リソースポリシー（外部→Lambdaへの呼び出し権限）」の2つを分けて考えることが重要だ。特にS3やEventBridgeからのトリガー設定時はリソースポリシーの追加を忘れやすいので注意。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感