Amazon SAP-C02: 組織の複雑性とマルチアカウント戦略 — 学習ガイド

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Solutions Architect Professional SAP-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

マルチアカウント戦略とアカウント払い出し

マルチアカウント戦略は、責任の明確な分離から始まります。具体的には、セキュリティと監査、共有ネットワーク、本番ワークロード、サンドボックスまたは開発者アカウントを分離します。AWS OrganizationsをAWS Control Towerまたはカスタムのランディングゾーンと組み合わせて使用することで、この分離を初日から強制します。Control TowerのAccount Factoryは、アカウント作成、ベースラインのIAMロール、VPCテンプレート、ガードレールを自動化するアカウント払い出しパターンを提供します。一方、CloudFormation/CDKとService Catalogで構築されたカスタムランディングゾーンは、オーダーメイドのネットワークやガバナンスに対してより高い柔軟性を提供します。主なトレードオフは、運用オーバーヘッドと影響範囲（ブラスト半径）の縮小です。アカウントが増えると管理対象領域（自動化、クロスアカウントロール、請求の可視性）が拡大しますが、ドメイン侵害のリスクを限定し、アカウントごとのコンプライアンスを簡素化します。ネットワークの選択肢（AWS Resource Access ManagerによるVPC共有、Transit Gatewayのハブアンドスポーク、VPCピアリングによる分離されたVPC）は、コストとレイテンシーのトレードオフを決定します。共有サービス（DNS、NAT、Active Directory）は、多くの場合、ネットワークアカウントまたは共有サービスアカウントに配置されます。アカウント払い出しの仕組みは、新しいアカウントをこれらの共有リソースに自動的にアタッチするか、委任されたVPCをプロビジョニングするようにすべきです。クォータと自動化を計画し、ベースラインアーティファクト用のパイプラインを集中管理することで、アカウントのスケールによって手作業が倍増しないようにします。

ガバナンス: SCP、Control Towerガードレール、組織ポリシー

マルチアカウントのAWS環境におけるガバナンスは、組織レベルでのポリシー適用と、委任されたランタイムコントロールに依存します。Service Control Policy（SCP）は、アカウント全体で許可されるアクションの上限を設定します。これは強力ですが、融通が利きません。ルートOUでのdenyルールは、明示的に許可されていない限り、管理者であってもサービスにリンクされたロールの作成やサービスの利用を妨げます。Control Towerは、一般的なSCPとConfigルールを実装する事前構築されたガードレール（必須、強く推奨、選択的）を提供しますが、高度なサービスパターンにとっては制約が厳しい場合があります。設計上の決定は、集中型ガバナンスと委任型ガバナンスのどちらを中心にするかです。厳格なルートレベルの拒否リストはコンプライアンスを最大化しますが、製品チームや自動化にとっての摩擦を増大させます。一方、許可境界（permission boundary）とIAMロールコントロールを備えた寛容なベースラインは、開発者のベロシティを向上させます。ログ記録と監査のポリシー（組織のCloudTrail、AWS Configアグリゲーター、Security HubとGuardDutyの委任管理者）は、不変の監査証跡を確保するために、管理アカウントから強制する必要があります。現実的なアプローチは階層化されたガバナンスです。影響の大きい制限のための組織SCP、開発者のスコープのための許可境界、そして手動のゲートキーピングなしで一貫性を維持するためにランディングゾーンのCI/CDによって適用される自動化されたガードレールを組み合わせます。

セキュリティ境界: クロスアカウントロール、KMS、リソースポリシー

クロスアカウントアクセスは中心的なパターンであり、最小権限と強力な信頼制御で実装する必要があります。一般的なパターンは、信頼されたプリンシパルがSTSで引き受ける各アカウントのIAMロールを介してアクセスを委任するものです。CICDデプロイメント、モニタリング（CloudWatch/SSM）、サードパーティ統合のためのロールは、適切な場合にはMFAを要求し、パートナーアクセスには外部IDを使用すべきです。S3、SQS、KMSキーのリソースベースポリシーは、直接のクロスアカウントアクセスを可能にしますが、KMSは複雑さを増します。KMSキーポリシーは、信頼するアカウントのプリンシパルとサービスを明示的に許可する必要があり、一時的なアクセスにはグラントまたは制約付きのグラントが必要になる場合があります。ログ記録またはセキュリティアカウントで集中管理されたKMSキーを使用すると、集中型の暗号化は簡素化されますが、運用上の結合と可用性の考慮事項が生じます。アカウントごとのキーは影響範囲を縮小しますが、キーのローテーションとグラント管理を複雑にします。よくある落とし穴には、SCPが意図せずKMSやサービスにリンクされたロールの作成を拒否すること、SCPと競合するバケットポリシー、コレクターアカウントのConfig/CloudTrailに委任ロールを追加し忘れることなどがあります。設計上の決定は、管理の簡素さ、最小権限、クロスアカウントのレイテンシーを比較検討すべきです。

一元化されたロギング、請求、および自動化のパターン

一元化されたロギングと請求は、エンタープライズ全体の可視性を確保するための根幹です。組織のCloudTrailを、一元化されたセキュリティまたは監査アカウントのS3バケットに配信される証跡と共に設定することで、改ざん検出可能なイベントキャプチャが保証されます。これを補完するために、CloudWatch Logsのサブスクリプションフィルターを使用してKinesis Data Firehoseにデータを送り分析に利用し、アグリゲータを使用してConfigデータを同じアカウントに集約します。コストの可視化には、Organizationsでの一括請求、Cost Explorer、Budgets、そして一元的に配信されるCost and Usage Reportsが必要です。Configルールによるタグガバナンスと自動化されたタグ付け強制は、チャージバックの精度を向上させます。アカウントをまたいでスケールする自動化パターンでは、一般的に、クロスアカウントのデプロイメントロールを引き受ける共有CI/CDパイプラインまたはデプロイメントアカウント、あるいは一括プロビジョニングのための委任管理者を持つCloudFormation StackSetsを使用します。クロスアカウントのパッチ適用や設定にはSystems Manager AutomationとState Managerを使用しますが、各アカウントが必要なロールとSSMの権限を付与する必要があることを忘れないでください。トレードオフは、一元化とレイテンシーのバランスを取ることにあります。中央集約はストレージの重複を減らし、分析を簡素化しますが、ネットワークと可用性の依存関係を生み出します。一方、分散ロギングはデータを複製しますが、障害を分離します。コンプライアンス要件に沿った、保持期間、ライフサイクルルール、DRのためのクロスリージョンレプリケーション、および暗号化キー管理を計画してください。

実践的な問題：ユースケースシナリオ

シナリオ：Contoso Mediaは、OrganizationsとControl Towerを導入したエンタープライズAWS環境を運用しています。同社には、管理アカウント、共有サービス用のネットワークアカウント、そして2つのリージョンにまたがって本番、ステージング、開発のワークロードを実行する20のメンバーアカウントがあります。

課題：Contosoは、15の新しいプロジェクトアカウントを迅速にオンボーディングする必要があります。その際、一元化されたロギング、適切なSCPガードレール、Transit Gatewayを介した共有サービスアカウントへの自動化されたネットワーク接続、およびアカウントごとの手動IAM設定を必要としないデプロイメントパイプラインを確保しなければなりません。

推奨アプローチ：

Control TowerのAccount Factoryまたは自動化されたAWS Organizations APIワークフローを使用してアカウントをプロビジョニングし、ベースラインとなるCloudFormation/CDKテンプレートを適用します。このテンプレートは、アカウントをAWS Configに登録し、監査アカウントのS3バケットを指す組織のCloudTrailを有効にし、必要なタグを適用します。
影響の大きい拒否（例：クロスリージョンでのキー削除や許可されていないリージョンの拒否）を強制するSCPをOUレベルでアタッチします。一方で、開発権限を持つOUは制限を緩やかに保ちます。広範囲に適用する前に、サンドボックスでSCPを検証します。
共有サービス用のネットワークアカウントにTransit Gatewayを設定し、Infrastructure-as-Codeと、アカウントプロビジョニングプロセスが引き受ける委任管理者またはクロスアカウントロールを使用して、各新規アカウントのTransit Gateway VPCアタッチメントを作成し、アタッチメントの作成とルート伝播を自動化します。
ツールアカウントに一元化されたCI/CDデプロイメントパイプラインをプロビジョニングします。このパイプラインは、アカウントプロビジョニングプロセスによって作成されたクロスアカウントIAMロール（assume-role）を使用します。初期のベースラインプロビジョニングと継続的な更新には、CloudFormation StackSets（委任管理者）またはクロスアカウントのCodePipelineアクションを使用します。

理論的根拠：ベースラインのアーティファクトを用いてアカウントプロビジョニングを自動化することで、手動のステップを最小限に抑えながらガバナンスを強制します。クロスアカウントロールとTransit Gatewayを介してネットワークとデプロイメントのタスクを委任することで、共有サービスを一元化し、影響範囲（ブラスト半径）を縮小し、セキュリティや監査性を犠牲にすることなくオンボーディングをスケールさせることができます。

すべてのドメイン · ネットワーキングとハイブリッド接続 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →