エンタープライズクラウドガバナンスの概要
最終更新日: 2026年9月13日
1. このセクションで扱う課題
これまでの EKS、ネットワーキング、セキュリティのドキュメントでは、「クラスター 1 つ、VPC 1 つ」を前提に、その上で個別の機能を説明してきました。しかし、複数のブランド、ドメイン、サービスにまたがり、数十のチームと数百人のエンジニアが働く大規模なエンタープライズ組織では、検討事項が変わります。
- アカウントをいくつ作成すべきか？
- VPC は共有すべきか、それとも分割すべきか？
- EKS クラスターはチーム専用にすべきか、それとも共有すべきか？
- Account/VPC/EKS の 3 つの境界とデータ境界を、1 対 1 で一致させるべきか？
このセクションでは、複数アカウント、複数 EKS の大規模環境における標準化の判断を扱います。サービス上の制約はリンク先の AWS ドキュメントに照らして確認します。ハイブリッド設計、分割基準、PoC のしきい値は、組織内で検証するための提案です。特定企業の非公開レビュー結果や本番環境での成功を証明するものではありません。
2. Account、VPC、EKS、データの境界を個別に検討すべき理由
よくある間違いは、チームやブランドごとに Account を作成し、各 Account に専用 VPC と専用 EKS クラスターを自動的に割り当てることです。これは固定の 1 対 1 方式です。ルールは単純ですが、小さなワークロードでもクラスター全体の固定費がかかり、組織の再編が起きるたびにインフラストラクチャの移行が必要になります。
このセクションでは、代わりに境界ごとに独立して判断する方法を提案します。
| 境界 | 判断基準 |
|---|---|
| Account | セキュリティ要件、サービスクォータ、コスト/所有者、ライフサイクル |
| VPC | ネットワークポリシー、信頼ゾーン、接続要件 |
| EKS | ランタイムの障害影響範囲、テナント分離要件、SLO |
| データ | データ所有者、規制上の境界、バックアップ/復旧の責任 |
この方法では、「このワークロードは専用 VPC を必要としないが、規制上の要件により専用 Account が必要」といった細かな判断が可能になります。一方でコストも生じます。境界ごとの判断基準を維持する必要があり、例外が増える可能性があります。
3. 境界を接続する際に確認すべきサービスの制約
個別に判断する場合でも、サービスの配置と認可に関する制約を考慮する必要があります。これらの制約から、必須の組織構造が自動的に決まるわけではありません。
- EKS クラスターに構成するサブネットは、1 つの VPC に属している必要があります。 2 つの独立したクラスターを同じ VPC で実行できます。VPC を分けることは、ルーティング、DNS、アドレス空間の障害ドメインを共有するかどうかについての追加判断です。
- Pod Identity 関連付けのプライマリ IAM ロールは、クラスターの Account 内に存在する必要があります。 ターゲットロール機能では、関連付けロール → ターゲットロールのチェーンを使います。S3 などのサービスにリソースポリシーで直接アクセスする方法や、ターゲット Account のロールへの IRSA フェデレーションを直接構成する方法もあります。すべてのクロスアカウントリクエストに 2 つのロールが必須というわけではありません。
- Shared VPC では、クラスターを作成する参加 Account を中心に、EKS クラスター/ノードの IAM ロールと関連する SG を設計してください。 データベースやキューを所有する Workload Account とは異なる場合があります。サブネットを共有しても、リソースの所有者が移るわけではありません。
- データ境界はサービスごとに異なります。 RDS インスタンスは VPC サブネットを使用しますが、S3 バケットはサブネットに配置されません。Shared VPC のサポート一覧には明示的に対象外があり、記載がないだけでは非サポートとは判断できません (データとセキュリティの境界)。
4. 共有優先と専用優先
境界を個別に判断すると決めた後、分離する理由がないワークロードについては、共有リソースと専用リソースのどちらをデフォルトにするかが次の論点になります。
- 共有優先: 小規模なワークロードは、まず共有 Account/VPC/クラスターに受け入れます。プロビジョニングが速く、インフラストラクチャの重複も減りますが、ノイジーネイバー問題や、所有者不在の共有リソースが時間とともに蓄積するリスクがあります。
- 専用優先: 分離が必要かどうか曖昧な場合は、まず専用の境界を検討します。コスト、所有者、障害影響範囲が明確になりますが、固定費は急速に増加します。
実務では、共有優先で開始し、規制、独立したクォータ、厳格な SLO の要件が確認されたら専用に切り替えるハイブリッド方式が、妥当な出発点です。この判断を毎回議論し直さなくて済むよう、このセクション後半の意思決定フレームワークと PoC 設計では、再現可能な意思決定マトリックスの構築方法を扱います。
5. 安定したワークロード ID と変更可能なメタデータ
組織再編、ブランド統合、チーム名の変更は今後も発生します。Account や VPC の境界をチーム名やブランド名に直接結び付けると、組織再編のたびにインフラストラクチャの移行が必要になります。
推奨する方法は、安定した Workload ID を 1 つ維持し、ドメイン、ブランド、チーム、CUJ (重要なユーザージャーニー)、環境、データクラス、SLO を、その ID に付随する変更可能なメタデータとして管理することです。組織再編でチームが変わることはありますが、ドメイン (ビジネス機能) は比較的安定しているため、チームよりも Account の境界を考える基準として適しています。
6. このセクションの内容
| ドキュメント | 内容 |
|---|---|
| ランディングゾーン、OU、組織の制御 | Control Tower の基盤依存関係、OU 設計、SCP/RCP/Tag Policy の役割 |
| Account 構造と IAM の境界 | Account の分割、人間/ワークロードの IAM、Kubernetes API アクセス |
| 複数 Account、複数クラスターの EKS アーキテクチャ | 共有/専用クラスター、A/B EKS Runtime の冗長性を実現する実際の条件 |
| Shared VPC と接続性 | Shared VPC で実際にボトルネックとなるクォータの連鎖、TGW/PrivateLink/Lattice の組み合わせ |
| データとセキュリティの境界 | クロスアカウントのバックアップ/復旧に関する制約、PII データ層の分離 |
| 意思決定フレームワークと PoC 設計 | 意思決定マトリックスの構築、見落としやすい判断要因、PoC の測定メトリクス |
各ドキュメントでは、意見よりも検証済みの事実 (「この条件では AWS サービスは実際にこう動作する」) を優先し、組織としての判断がまだ必要な部分を明確に示します。