AWSサービス間連携における権限設計の原則
AWSサービス間連携の権限設計は、最小権限の原則に基づき実施する。以下の優先順位で検討することで、一貫性のある適切な権限設計を実現できる。
１．実行ロールによる権限付与【基本原則】
同一アカウント内の連携では、連携元サービスが実行ロールを引き受けて実行することを原則とする。実行ロールには連携に必要な最小権限のみを付与する。
- サービスロール: ユーザーが明示的に作成・管理
- サービスリンクロール（SLR）: AWSが自動作成・管理
２．リソースベースポリシーによる補完
実行ロールのみでは実現できない場合、連携先リソースのリソースベースポリシーで補完的にアクセスを許可する。設定は必要最小限の範囲に限定する。
３．クロスアカウント連携における権限付与
クロスアカウント連携では、以下の優先順位で実装する
クロスアカウントロールの引き受け（推奨）
リソースベースポリシーによる許可（ロールが使用できない場合のみ）
１．実行ロールによる権限付与【基本原則】
実行ロール（ユーザー管理）を使用する典型的なサービス
| 実行ロールを使用するサービス | 実行ロール／インスタンスプロファイル |
|---|---|
| EC2 | インスタンスプロファイル |
| Lambda | 実行ロール |
| ECS | 実行ロール |
| EKS | 実行ロール |
| Batch | 実行ロール |
| Step Functions | 実行ロール |
| EventBridge Scheduler | 実行ロール |
| EventBridge EventBus | 実行ロール |
| API Gateway | 実行ロール |
| Kinesis Firehose | 実行ロール |
| Glue | 実行ロール |
| EMR | 実行ロール |
| Redshift | 実行ロール |
| SageMaker | 実行ロール |
| Bedrock | 実行ロール |
| IoT Core | 実行ロール |
| CodeBuild | 実行ロール |
| CodePipeline | 実行ロール |
| SSM Automation | 実行ロール |
| CloudFormation | 実行ロール |
SLR（AWS管理）が作成される主要サービス
| SLR が作成される主要サービス | SLR名 |
|---|---|
| Auto Scaling | AWSServiceRoleForAutoScaling |
| Application Auto Scaling | AWSServiceRoleForApplicationAutoScaling_* |
| ECS | AWSServiceRoleForECS |
| EKS | AWSServiceRoleForAmazonEKS |
| RDS | AWSServiceRoleForRDS |
| ElastiCache | AWSServiceRoleForElastiCache |
| Lambda（VPC設定時） | AWSServiceRoleForLambdaReplicator |
| CloudFormation | AWSServiceRoleForCloudFormationStackSetsOrgAdmin AWSServiceRoleForCloudFormationStackSetsOrgMember |
| SSM | AWSServiceRoleForAmazonSSM |
| Backup | AWSServiceRoleForBackup |
| GuardDuty | AWSServiceRoleForAmazonGuardDuty |
| Security Hub | AWSServiceRoleForSecurityHub |
| Organizations | AWSServiceRoleForOrganizations |
| ELB | AWSServiceRoleForElasticLoadBalancing |
２．リソースベースポリシーによる補完
実行ロールでは対応できず、リソースベースポリシーで補う必要がある典型的なパターン
| リソースベースポリシーが必要となるサービス | リソースベースポリシー |
|---|---|
| EventBridge | イベントバスポリシー |
| SNS | トピックポリシー |
| SQS | キューポリシー |
| CloudWatch Logs | リソースポリシー |
| KMS | キーポリシー |
| Lambda | 関数ポリシー |
| S3 | バケットポリシー |