導入
「EC2インスタンスにアクセスキーを設定してS3にアクセスする」——これはよくある初心者の実装ですが、SAAでは不正解です。正解は「ロールを付与する」ことです。なぜロールが安全なのかを理解しましょう。
説明
IAMロール は、ユーザーではなく「誰か・何かが一時的に引き受ける権限のセット」です。ロール自体はパスワードやアクセスキーを持たず、STS（Security Token Service） が発行する 一時的な認証情報（有効期限付きのアクセスキー・シークレットキー・セッショントークン）を使って権限を行使します。
ロールを引き受ける操作を AssumeRole と呼びます。
sequenceDiagram
participant E as "EC2インスタンス"
participant S as "STS"
participant B as "S3バケット"
E->>S: "AssumeRole（ロールを引き受ける）"
S-->>E: "一時的な認証情報（有効期限あり）"
E->>B: "一時的な認証情報でアクセス"
代表的な使い方が インスタンスプロファイル です。EC2インスタンスにIAMロールを直接アタッチすると、インスタンス内のアプリはアクセスキーを一切持たずに、自動的に一時認証情報を取得してAWSサービスを呼び出せます。
| 方式 | アクセスキーの管理 | 有効期限 | SAAでの評価 |
|---|---|---|---|
| アクセスキーを埋め込む | 手動（漏洩リスク・ローテーション必要） | 恒久（自分で失効させない限り有効） | 原則不正解 |
| ロール（インスタンスプロファイル） | 不要（AWSが自動管理） | 一時的（自動更新） | 推奨される正解パターン |
同じ理由で、Lambda関数には 実行ロール、ECSタスクには タスクロール を付与し、いずれもアクセスキーを持たせません。
読んでみよう
「EC2/Lambda/ECSがAWSサービスにアクセスする必要がある」という問題文が出たら、反射的に「ロールを付与する」を選んでください。アクセスキーの直接管理が選択肢にあっても、それは不正解を誘う”引っ掛け”だと考えて構いません。