アカウント構造と IAM の境界
最終更新日: 2026年9月13日
1. アカウントの分割: 何を基準にするか
アカウントの分割方法としてよく候補に挙がるのは、チーム、ブランド、ドメイン、環境（本番／非本番）です。ただし、アカウントはチーム名ではなく、関連するワークロードが共有するセキュリティ要件、サービスクォータ、コストと所有権、ライフサイクルを基準に判断します。 チームは組織再編で頻繁に変わりますが、ドメイン（ビジネス機能）は比較的安定しており、アカウント分割の候補になりやすい単位です。
| 選択肢 | 構成 | メリット | デメリット |
|---|---|---|---|
| ドメイン × 環境 | ドメインごとに本番／非本番のアカウントを分ける | コスト、クォータ、権限、所有権をドメインに結び付けやすい | 小規模なドメインにも固定コストが発生し、ドメイン再編がそのまま移行につながる |
| ブランド × 環境 | ブランドと環境ごとにアカウントを分け、その中に複数のドメインを配置する | アカウント境界を使って、ブランド単位のコスト、クォータ、権限、分離、譲渡を管理できる | ブランド間で共有する機能の所有権が曖昧になる。ブランドのライフサイクル変更がアカウント再編に直結する |
| 少数の中央ワークロードアカウント | 複数のドメインやチームのワークロードを、少数の共有アカウントに配置する | 初期運用が簡単で、小規模なワークロードを導入しやすい | クォータ、権限、影響範囲が拡大し、後から分割しにくくなる |
| ハイブリッド型ポートフォリオ | 小規模なワークロードは共有アカウントに置き、強いドメイン／規制／クォータ上の境界があるワークロードには専用アカウントを割り当てる | 要件に応じて、共有、ドメイン単位、専用の各アカウントを組み合わせられる | 判断基準が曖昧だと例外が急増する |
実際には、ハイブリッド型ポートフォリオから始め、再現可能な判断マトリクスを使って共有か専用かを都度決定する方法が一般的です（マトリクスの設計方法は判断フレームワークを参照してください）。
コスト分離だけが目的なら、ブランドはメタデータとして扱います。規制、独立したクォータや権限、事業分離の可能性など、強い境界がある場合に限り、ブランドをアカウント分割の軸にします。複数のドメインのデータを集約して API で提供するワークロードは、独立した SLO、クォータ、データアクセス、ライフサイクルを持つなら、専用のワークロードアカウントの候補になります。アカウントを分けても、EKS クラスターまで別にする必要があるとは限りません。
事業分離への備え: サブネット共有は同一の Organization 内で利用できます。Organization から離脱する前に、独立したネットワークへの移行を準備してください。共有を解除した後も既存リソースが引き続き動作する場合がありますが、新しいリソースの作成や、マネージドサービスの置き換え／スケーリングに影響する可能性があります。共有を解除しても、すべてのリソースが直ちに削除または停止されるわけではありません。
2. アカウントと EKS ランタイムの関係
アカウントの分割を決めたら、Kubernetes ワークロードをどのアカウントの EKS クラスターで実行するかを決めます。
| 選択肢 | 構成 | メリット | デメリット |
|---|---|---|---|
| ワークロードアカウントごとに専用 EKS | 各ワークロードアカウントが独自の EKS クラスターを所有する | アカウントの所有権とランタイムの所有権／影響範囲が一致する | 小規模なワークロードにもクラスターが必要になり、管理対象クラスター数と遊休キャパシティが増える |
| ワークロードアカウント + 共有クラスターアカウント | Lambda、SQS、DB などのリソースは各ワークロードアカウントに置き、Kubernetes ワークロードは別のクラスターアカウントにある共有 EKS で実行する | アカウント境界と、管理する EKS クラスター数を別々に決められる | クロスアカウントの ID、ネットワーク、クラスター所有権が複雑になる |
2つ目のパターンでは、クラスターアカウントの IAM ロールと、別のアカウントにあるデータへのアクセスを区別してください。共有 VPC を使う場合、EKS を作成する参加アカウントがクラスターアカウントです。データベースやキューだけを所有するワークロードアカウントとは異なることがあります。要件に応じて、Pod Identity のターゲットロールチェーン、サービスのリソースポリシー、IRSA を選択します。
EKS 関連クォータ: 余裕がある項目と実際に上限に達する項目
| クォータ | デフォルト | 引き上げ可能 |
|---|---|---|
| クラスター / リージョン | 100 | はい |
| マネージドノードグループ / クラスター | 30 | はい |
| ノード / ノードグループ | 450 | はい |
| コントロールプレーンのセキュリティグループ / クラスター | 4 | いいえ |
| パブリックエンドポイントへのアクセスを許可する CIDR / クラスター | 40 | いいえ |
| アクセスエントリ / クラスター | 3,000 | いいえ |
多くの EKS クォータには余裕がありますが、クラスターあたり3,000件のアクセスエントリ上限（引き上げ不可）は、数十のチームがワークロード × 環境ごとに CI/CD ロールを個別に発行すると、すぐに到達し得る実際の制限です。アクセス経路を Permission Set またはチーム単位のロールに集約し、アクセスエントリをプリンシパルの種類ごとにまとめることを推奨します。
マネージドノードグループの「30」は引き上げ可能なデフォルト値であり、テナント数を固定する上限ではありません。Karpenter の NodePool や taint/toleration による配置制御だけでは、強いセキュリティ境界にはなりません。適用されるクォータ、権限、共有カーネル、ノードエージェントの特権を合わせて評価してください。
3. AWS への人間のアクセス（Workforce IAM）
| 選択肢 | 構成 | メリット | デメリット |
|---|---|---|---|
| Identity Center + RBAC | ユーザーは Identity Center 経由でログインし、ロールベースの Permission Set を使ってアカウントにアクセスする | 一時的な認証情報を使え、中央で失効や監査を行える | チーム × ドメイン × 環境の組み合わせごとに Permission Set が増える場合がある |
| RBAC + 限定的な ABAC | RBAC のロール単位の権限上限の範囲内で、タグを使ってリソース範囲をさらに絞る | 権限上限と拡張性を組み合わせられる | RBAC と ABAC の両方をテストし、タグの発行者を管理する必要がある |
| ABAC 中心 | ユーザーとリソースのタグが一致した場合を主な許可条件とする | アカウントやワークロードが増えた際のポリシー重複を減らせる | タグの管理権限が弱いと、権限の拡大やデバッグの難しさが増す |
通常の選択肢から、アカウントごとの IAM ユーザーは除外することを推奨します。Identity Center が利用できない緊急時のアクセスに限り例外として認め、その目的、所有者、利用条件、認証情報の保管方法、定期レビュー、終了条件を明記してください。
IAM Identity Center の実際の上限
| クォータ | デフォルト | 引き上げ可能 |
|---|---|---|
| Permission Set の合計数 | 3,500 | はい |
| アカウントごとのプロビジョニング済み Permission Set | 500 | はい |
| Permission Set あたりの管理ポリシー | 25。別途、IAM ロールのデフォルト値10は必要に応じて引き上げる | Permission Set の上限: いいえ |
| Permission Set あたりのインラインポリシー | 32,768 バイト、空白文字を除くと10,240バイト | いいえ |
| 1つのアカウントで1つの Permission Set に割り当てられるグループ数 | 100 | いいえ |
| 設定可能なアカウント数 | 7,000 | はい |
| Identity Center API のスロットリング | 合計20 TPS。読み取りの上限はサポート経由で引き上げ可能 | API ごとの追加制限を確認 |
100グループの制限が適用されるのは、特定の Permission Set とアカウントの組み合わせであり、アカウント内のすべてのグループではありません。異なる Permission Set に割り当てたグループを合算して、アカウント全体の RBAC 上限が100だと判断しないでください。
設計案: RBAC の簡素化、ABAC、アカウント分離を比較する前に、Permission Set ごとの割り当て数とポリシー重複を測定してください。50件を警告しきい値とするのは任意のローカル設定であり、AWS の要件でも ABAC への必須の切り替え条件でもありません。
4. ワークロード（アプリケーション／自動化）から AWS へのアクセス
以下は相互排他的な選択肢ではありません。実行環境とクロスアカウントアクセスの要否に応じて組み合わせるパターンです。
| 方法 | 構成 | 適する対象 |
|---|---|---|
| ランタイムロール | 実行環境（EC2、Lambda、ECS など）に IAM ロールをアタッチする | EKS 以外のワークロード |
| EKS Pod Identity | Pod Identity association を通じて Pod を IAM ロールに関連付ける | 対応する EKS ワークロード（推奨する方向性） |
| IRSA | Kubernetes サービスアカウントトークンと IAM OIDC プロバイダーを使う | 互換性が必要な既存クラスター／ツールチェーン |
| クロスアカウントのターゲットロール | ソースロールがターゲットアカウントのロールを引き受ける | ターゲットロールの権限で実行する必要がある経路 |
静的アクセスキーを許可するのは、ロールやフェデレーションに対応していないレガシー連携の例外に限ります。その場合も、目的、所有者、有効期限、ローテーションを明記してください。
Pod Identity association のプライマリロールはクラスターアカウントにあります。targetRoleArn を設定すると2つのロールが連鎖しますが、対応するリソースポリシーでそのソースロールを直接許可する方法もあります。IRSA はターゲットアカウントの OIDC プロバイダー／ロールと直接フェデレーションすることもできます。ロールの再利用やセッションタグ／ポリシーの設計でロール数は変わるため、「ワークロードごとに必ず2つ」というわけではありません。AWS API 用のワークロードロールは、Kubernetes API アクセス用のアクセスエントリとは別に数えます。
5. Kubernetes API へのアクセス
| 方法 | 構成 | 状況 |
|---|---|---|
| EKS アクセスエントリ | Access Entry を使い、Access Policy または RBAC 用の Kubernetes グループマッピングで IAM プリンシパルごとのクラスターアクセスを管理する | 推奨する方向性 |
| aws-auth ConfigMap | クラスターの aws-auth ConfigMap を使い、IAM プリンシパルと Kubernetes ID の対応を管理する | レガシークラスターの移行時の例外としてのみ維持する |
権限の合算: Access Policy と Kubernetes RBAC による許可は合算され、どちらかがもう一方を制限することはありません。各プリンシパルの主要なアクセス経路と、意図的に追加した権限を記録し、重複を確認してください。自動チェックは実装上有用な選択肢ですが、API を利用するための前提条件ではありません。
次のステップ
アカウントと IAM の境界を決めたら、次は EKS クラスターの数と可用性の実現方法を決めます → マルチアカウント・マルチクラスター EKS アーキテクチャ