判断フレームワークと PoC 設計
最終更新日: 2026年10月12日
ここまで扱ってきたランディングゾーン、アカウント／IAM、EKS、VPC、データ／セキュリティの各境界は、それぞれ独立に評価する必要があります。ただし実際には、すべての判断を1つの判断マトリクスから再現できる必要があります。このドキュメントでは、そのマトリクスの設計方法と、PoC で実測しなければならない部分の検証方法を説明します。
1. 見落としやすい判断要素
境界、アカウント、ネットワーク構造をどれだけ慎重に設計しても、次の要素がなければ設計の正しさを判断できません。
CUJ レベルの RTO／RPO 目標: 最大の不足要素
CUJ（重要なユーザージャーニー）ごとに RTO（目標復旧時間）／RPO（目標復旧時点）が定義されていないと、次の点を判断できません。
- A／B の EKS ランタイムフェイルオーバーが十分に速いか（DNS TTL + エッジの伝播 + Route 53 の伝播 + ヘルス検出の遅延の合計）
- データ所有モデルとして一元管理とワークロード所有のどちらが実際に復旧可能か（スナップショットのコピー時間を RTO に含めるか）
- 2 AZ と3 AZ の違いが重要か（N-1 状態でも SLO を維持できるか）
- セル単位の分離による追加コストが妥当か
最初に、CUJ ごとの RTO／RPO／許容エラー率の目標を表に定義してください。
インシデント発生時のオンコール責任者
セキュリティ、クォータ、コスト、ライフサイクル、影響範囲を境界の判断にすべて反映していても、「最初に誰が対応するか」を定義していなければ、Shared Cluster の問題が CNI なのかアプリケーションなのか分からず、午前2時のインシデントで時間を失います。判断マトリクスに「主担当の対応者」と「エスカレーション経路」の列を追加し、主担当が複数いる境界は、分割を検討する候補とするルールを採用してください。
対象 Kubernetes バージョンとアップグレード戦略
trafficDistribution フィールドの値、Karpenter の ARC ゾーンシフト統合（1.12 以降）、EKS Auto Mode の採用有無（ノードライフサイクルの所有者）、アドオン互換性マトリクスは、いずれも EKS のバージョンに依存します。A／B の EKS ランタイムを実行する理由がアップグレードの分離にあるなら、許容するバージョンのずれ、必ず先にアップグレードする側のルール、延長サポートを使うかどうかを正式に定める必要があります。
重み付き転送とターゲットグループの fail-open を区別する
重み付き転送アクションでは、重み付きグループが空または unhealthy だからといって、別のターゲットグループへ自動的にフェイルオーバーするわけではありません。選択されたグループ内の fail-open は別の動作です。正常なターゲットがしきい値を下回ると、ロードバランサーノードが到達可能な unhealthy ターゲットへルーティングする場合があります。次の属性で DNS とルーティングのフェイルオーバーを確認してください。
target_group_health.unhealthy_state_routing.minimum_healthy_targets.count（または.percentage）target_group_health.dns_failover.minimum_healthy_targets.count（または.percentage）
統合設定では、両方のアクションに同じしきい値が適用されます。DNS フェイルオーバーのしきい値は、ルーティングフェイルオーバーのしきい値以上である必要があります。両方を設定した場合は、件数または割合のどちらでもアクションが発生します。割合の計算対象は登録済みターゲット数であり、CUJ のスループットや N-1 状態の SLO キャパシティが実証されているわけではありません。重みの変更を行う際は、実際の負荷、エラー率、レイテンシも条件にしてください。
未使用リージョンを制御する
単一リージョンの判断とは別に、次の点にも対応する必要があります。
- 予防: グローバルサービス用の例外リストを含む SCP
aws:RequestedRegionDeny - 検出: 許可／利用可能なリージョンで、CloudTrail、GuardDuty、Security Hub CSPM のカバレッジを確認する。1つの製品を無効にしても、すべてのアクティビティが検出不能になるわけではない。
- オプトインリージョン: 使用しないオプトインリージョンは無効化できますが、デフォルトで有効なリージョンは無効化できません。リージョンを無効化しても、既存リソースは削除されず、料金も停止しません。クリーンアップ、SCP、検出を組み合わせてください。
コストの可観測性とタグ適用のタイミング
Flow Logs、ENI／IP の対応、Kubernetes ワークロード ID、CUR の請求カテゴリを結合して、AZ 間のコスト帰属を検証します。すべての ENI で、作成時のユーザータグや RequestTag 条件がサポートされるわけではありません。サービス固有のカバレッジに合わせて、タグポリシー、IaC、サポート対象の SCP 条件を適用してください。
2. 判断マトリクスの設計
これらのドキュメントで扱った選択肢（独立した境界判断、ハイブリッド型アカウントポートフォリオ、共有＋専用 EKS、信頼ゾーン混在 VPC、ハイブリッドデータ、ハイブリッドキー所有権）は、すべて妥当性の条件として「判断マトリクスによる再現性」を掲げています。判断マトリクスがなければ、PoC の結果を標準に反映できません。
判断マトリクスに推奨する列:
| 列 | 目的 |
|---|---|
| EKS が必要か | EKS の境界が VPC の境界に従属するかどうかを判断する |
| クロスアカウントのリソースアクセス | 要件に応じてターゲットロールチェーン、リソースポリシー、IRSA を選ぶ |
| 共有サブネットでサポートされないサービスを利用するか | 共有 VPC の局所配置戦略から除外するかを判断する |
| Permission Set／アカウントの組み合わせごとのグループ数 | 実際の上限100と増加率を確認する。50は任意のローカル警告値 |
| 主担当の対応者／エスカレーション経路 | 主担当が複数いる境界は分割候補とする |
| CUJ の RTO／RPO | データ設計と可用性設計全体を判断する基準 |
3. PoC の設計パターン
机上では最終決定できず、実測が必要な項目があります。以下の PoC は優先度順に並べています。
PoC-0: 判断マトリクスの試行（他の PoC より先に実施）
- 入力: 代表的なワークロードを10～15件（CUJ、少なくとも1つの PII ワークロード、少なくとも1つの共通ドメインのワークロード、少なくとも2つの小規模な社内ツール、少なくとも1つの外部パートナー連携を含む）
- 手順: 2人がそれぞれ独立に判断マトリクスを適用し、結果を比較する
- 成功基準の例: 不一致が20%未満、例外が15%未満。これらの仮説はローカル要件に合わせて調整する
- 副産物: 判断結果からアカウント／VPC／クラスターのおおよその数が分かり、残りの PoC で測定するクォータの対象を決められる
PoC-1: 共有クラスター + ワークロードアカウント
| 測定項目 | 成功基準 |
|---|---|
| Pod Identity／リソースポリシー／IRSA の権限経路 | ソース／ターゲットの再利用、スコープ、失効、KMS、リソースポリシーを検証する。固定の「ロール2つ」式は使わない |
| 共有サブネットでの ALB Controller サブネット自動検出 | タグによる自動検出が失敗するかを確認し、失敗する場合は明示的な annotation を標準にする |
| アクセスエントリの増加率 | （ワークロード追加ごとの増加数）× 目標ワークロード数 < 3,000 |
| マネージドノードグループ数 | デフォルト30および適用済みクォータに対する余裕を確認し、配置とセキュリティ分離を区別する |
| クラスターアカウントとワークロードアカウント間の一次対応時間 | 「CNI の問題かアプリケーションの問題か」を判断するまでの時間 |
| 参加者 SG の広すぎる Allow ルールの検出／遮断時間 | Firewall Manager の監査ポリシーによる検出から遮断までの時間 |
PoC-2: A／B EKS ランタイムと AZ 設定（前提条件: CUJ レベルの RTO／RPO が定義済み）
| 測定項目 | 成功基準 |
|---|---|
| 第3章の一覧から3つ以上の障害を注入する | 各障害が実際に1つのクラスターに封じ込められることを確認する |
| ARC ゾーン自動シフトの訓練 | A／B の各クラスターが、それぞれ独立して N-1 AZ のピーク負荷を処理できることを確認する |
| CoreDNS の N-1 スループット／レイテンシ | レイテンシ増加率と、ENI あたり毎秒1,024パケットの上限に達するかどうか |
| CUJ サービスグラフの AZ カバレッジ | 依存先への到達性、キャパシティ、生存 AZ からのフォールバックを検証する |
| ステートフルな復旧 | EBS の AZ 制約、代替ストレージ／レプリケーション、復旧時間、データ損失を検証する |
| A から B へのエンドツーエンドフェイルオーバー時間 | エッジのフェイルオーバーと Route 53 レコード変更を分けて測定する |
| ロールバック時間 | フェイルオーバー時間とは別に測定する |
| AZ 間のバイト数 | Flow Logs を基にし、最適化前後を比較する |
| 事前プロビジョニングされたキャパシティの倍率 | 実測値と、2倍／1.5倍という仮説を比較する |
PoC-3: 最小構成の共有 VPC／共有 VPC プール
| 測定項目 | 成功基準 |
|---|---|
| TGW／VPC のルート数（現在／3年後の予測） | TGW テーブル全体の10,000、VPC の未伝播ルート500／引き上げ可能な1,000、VGW の100を区別する |
| 参加アカウントの増加率 | 目標チーム数に対して上限100を超えない |
| アカウントあたりの共有サブネット数 | AZ × 信頼ゾーン × 用途の組み合わせを100と比較する |
| NAU 使用量 | Pod 密度を反映し、64,000 から256,000への引き上げが必要になるタイミングを判断する |
| ルート／DNS 変更依頼から所有者による対応までの時間 | ボトルネックを数値化する |
| Flow Logs の根拠の完全性 | 所有者と参加者のログを合わせてフロー全体を再現できるか |
| 最小構成と専用構成の両方における、不適切な中央ルート変更の検出／復旧時間 | 両方の選択肢を測定する（これが実際の判断材料） |
| TGW アタッチメントのスループット | AZ あたり100 Gbps／750万 PPS に対する余裕を確認する |
4. AI を利用した運用との関係
このフレームワークは、アカウント／VPC／EKS などのトポロジー選択に限られません。すべての ADR（アーキテクチャ決定記録）に適用する運用原則にも拡張できます。インフラストラクチャ変更の実行経路は、一般に次のように分類できます。
- IaC のみ: 人が作成し、人がレビューした IaC のみで変更する。再現性は最も高い一方、緊急対応や探索的作業には時間がかかる。
- AI 支援 IaC: エージェントが IaC の変更案を生成し、既存のレビュー → plan → apply の手順を通じて実行する。作成コストを抑えられるが、生成差分が大きくなることや、実際の状態から drift するリスクがある。
- ポリシー／意図 + 生成プラン: エージェントが現在の状態を読み、実行プランを作成する。意図とバックエンドを分離できる一方、意図のスキーマや状態の調整が弱いと結果が一致しなくなる。
- エージェントによる MCP／CLI／API の直接操作: 承認済みエージェントが直接変更し、検証する。最も速いが、過度に広い権限、部分的な失敗、プロンプトインジェクションのリスクがある。
- リスク別ハイブリッド: 高リスクで永続的な構成変更には IaC を使い、低リスクで元に戻せる作業には限定的なエージェントの直接実行を使う。多くの組織にとって、これが現実的な方向性です。
各実行経路のリスクに合わせて、機械可読な意図、実行前スナップショット、プラン、決定論的なポリシーチェック、承認、スコープを限定した一時的な ID、実行後チェック、CloudTrail ログ記録、実際の状態との照合、復旧契約を定義してください。
AWS MCP Server の範囲: 2026年10月12日時点で、エンドポイントの一覧には8リージョン（us-east-1、us-west-2、ap-northeast-1、ap-southeast-1／2、eu-central-1、eu-west-1／2）があり、ソウル（ap-northeast-2）のエンドポイントはありません。エンドポイントの所在地と、管理対象リソースのリージョンは異なります。API の実行には IAM と後続サービスの権限が使われ、CloudTrail の記録をレビューできます。組織要件に照らして、エンドポイント、認証、ログ記録、データ経路を評価してください。ソウルのエンドポイントがないことだけでは、規制違反とは判断できません。
関連ドキュメント
- エンタープライズクラウドガバナンスの概要
- ランディングゾーン、OU、組織制御
- アカウント構造と IAM の境界
- マルチアカウント・マルチクラスター EKS アーキテクチャ
- 共有 VPC と接続
- データとセキュリティの境界