SAP-C02 · LESSON 1
複雑な組織に対応するソリューションの設計26% · 5項目
複雑な組織に向けた、ネットワーク接続、セキュリティの管理策、信頼性、マルチアカウント環境、コストの可視化の設計を学びます。
1.1ネットワーク接続の戦略を設計する
1.1 ネットワーク接続戦略を設計する。
概念
大規模な組織では、Transit Gateway をハブにして多数の VPC・VPN・Direct Connect を接続し、ルートテーブルで経路を分離します(本番と開発を分ける、検査用 VPC を通すなど)。オンプレミスとの名前解決は Route 53 Resolver のインバウンド・アウトバウンドエンドポイント、サービスの公開は PrivateLink(重複する CIDR でも接続できる)を使います。Direct Connect は回復性の推奨(複数のロケーション・複数の接続)に従います。
仕組み・手順
- VPC の CIDR を重複しないように計画する(重複する場合は PrivateLink)
- Transit Gateway のルートテーブルで環境ごとに経路を分ける
- Direct Connect を 2 つのロケーションに冗長化し、バックアップに Site-to-Site VPN を置く
- Route 53 Resolver のエンドポイントとルールでオンプレミスと双方向の名前解決をする
- 共有のネットワークは RAM(Resource Access Manager)で他のアカウントに共有する
業務での例
200 個の VPC を Transit Gateway に集約し、全ての外部向けの通信を検査用 VPC の Network Firewall に通す。オンプレミスの社内ドメインはアウトバウンドエンドポイントの転送ルールで解決する。
紛らわしい点・試験の注意
- VPC ピアリングは推移的ではなく、数が増えると管理が難しい
- Direct Connect の最大の回復性には、別々のロケーションに 2 本ずつ
- PrivateLink は特定のサービスの公開で、VPC 全体の接続ではない
ミニクイズ
Q1. オンプレミスのサーバーから、Direct Connect 経由でインターネットを通らずに S3 へ大量のファイルを送りたい。最も適切な構成はどれか。
- S3 のゲートウェイ VPC エンドポイントを作り、オンプレミスのルーターのルートテーブルからそのエンドポイントを指定する
- VPC に NAT ゲートウェイを作り、オンプレミスからの通信を Direct Connect 経由で NAT ゲートウェイに向けて送る
- S3 のインターフェイス VPC エンドポイントを作り、オンプレミスから Direct Connect 経由でそのエンドポイントに接続する
- オンプレミスのサーバーにパブリック IP を割り当てて、インターネット経由で S3 のパブリックエンドポイントに送る
答えと解説を見る
正解:C S3 のインターフェイス VPC エンドポイントを作り、オンプレミスから Direct Connect 経由でそのエンドポイントに接続する
ゲートウェイエンドポイントは VPC 内のルートテーブルでしか使えず、オンプレミスからは到達できない。オンプレミスから使うには、プライベート IP を持つインターフェイスエンドポイントを Direct Connect や VPN 経由で利用する。
Q2. Transit Gateway に VPC A と VPC B をアタッチし、Transit Gateway のルートテーブルには両方の経路が伝播している。しかし A の EC2 から B の EC2 に通信できない。次に確認すべきこととして最も適切なものはどれか。
- Transit Gateway のアタッチメントで、アプライアンスモードが有効になっているか
- Transit Gateway のルートテーブルに、静的なルートも追加されているか
- A と B の VPC で、DNS の解決と DNS ホスト名が有効になっているか
- A と B の各サブネットのルートテーブルに、相手の CIDR を Transit Gateway に向けるルートがあるか
答えと解説を見る
正解:D A と B の各サブネットのルートテーブルに、相手の CIDR を Transit Gateway に向けるルートがあるか
Transit Gateway 側の経路だけでなく、各 VPC のサブネットのルートテーブルにも相手の CIDR を Transit Gateway に向けるルートが必要。その後、セキュリティグループとネットワーク ACL も確認する。 【他の選択肢】アプライアンスモードは検査用のアプライアンスの経路のための設定。経路はすでに伝播しているため静的なルートは要らない。DNS の設定は IP アドレスでの通信には関係しない。
参考リンク
1.2セキュリティコントロールを規定する
1.2 セキュリティコントロールを規定する。
概念
組織のセキュリティの管理策は、予防(SCP・RCP・IAM・権限の境界)、検出(GuardDuty・Security Hub・Config・CloudTrail の組織の証跡)、対応(EventBridge と自動修復)の組み合わせです。SCP はプリンシパル(IAM ユーザー・ロール)の権限の上限、RCP(リソースコントロールポリシー)はリソースへのアクセスの上限を組織全体で設定します。セキュリティのサービスは委任管理者のアカウントで一元管理します。
仕組み・手順
- セキュリティ・ログ専用のアカウントを用意する
- GuardDuty・Security Hub・Config の委任管理者を設定し、全アカウントで自動で有効にする
- SCP で危険な操作を禁止し、RCP で組織外からのリソースへのアクセスを制限する
- 権限の境界で、開発者が作るロールの権限の上限を決める
- 検出結果を EventBridge で自動修復の処理につなぐ
業務での例
組織外のプリンシパルが S3 バケットにアクセスできないように RCP を設定し、どのアカウントでも GuardDuty を無効にできないよう SCP で禁止する。
紛らわしい点・試験の注意
- SCP は管理アカウントには適用されない
- RCP はリソースへの、SCP はプリンシパルからのアクセスを制限する
- 権限の境界は IAM のエンティティごと、SCP はアカウント・OU ごと
ミニクイズ
Q1. AWS Organizations の OU(組織単位)の構成を見直している。AWS の推奨に最も沿った考え方はどれか。
- セキュリティ・インフラ・ワークロード(本番/開発)など、統制の要件が似たアカウントを同じ OU にまとめる
- 会社の組織図と同じ階層で OU を作り、部署の異動や組織変更のたびに OU の構成とアカウントを移動させる
- すべてのアカウントを1つの OU に入れ、SCP はアカウントごとに個別に作って直接アタッチして管理する
- 本番と開発のワークロードを同じアカウントに入れ、アカウントの数を増やさないように OU は作らない
答えと解説を見る
正解:A セキュリティ・インフラ・ワークロード(本番/開発)など、統制の要件が似たアカウントを同じ OU にまとめる
OU はポリシーを適用する単位なので、組織図ではなく統制の要件(本番・開発・セキュリティなど)で分ける。組織変更のたびに OU を動かす必要がない。
Q2. サービスコントロールポリシー(SCP)の説明として誤っているものはどれか。
- SCP で明示的に拒否したアクションは、メンバーアカウントの IAM ポリシーで許可していても実行できない
- SCP は管理アカウントのユーザーやロールには適用されない
- SCP で許可したアクションは、IAM ポリシーで許可していなくてもアカウントのユーザーが実行できる
- SCP はメンバーアカウントのルートユーザーにも適用される
答えと解説を見る
正解:C SCP で許可したアクションは、IAM ポリシーで許可していなくてもアカウントのユーザーが実行できる
SCP は権限の上限を決めるだけで、権限を与えない。実際に実行するには IAM ポリシーなどでの許可も必要。
参考リンク
1.3信頼性とレジリエンスに優れたアーキテクチャを設計する
1.3 信頼性とレジリエンスに優れたアーキテクチャを設計する。
概念
組織の重要なシステムは、RTO・RPO に応じた DR 戦略(バックアップと復元・パイロットライト・ウォームスタンバイ・マルチサイト)と、リージョン間のレプリケーション(Aurora グローバルデータベース・DynamoDB グローバルテーブル・S3 クロスリージョンレプリケーション)で設計します。AWS Elastic Disaster Recovery はサーバーの継続的なレプリケーションで、低コストで短い RPO を実現します。
仕組み・手順
- システムごとに RTO・RPO を決め、重要度で分類する
- 重要度に合う DR の戦略を選ぶ
- データはリージョン間で継続的にレプリケーションする
- Route 53 の ARC(Application Recovery Controller)などで切り替えを制御する
- DR の訓練を定期的に行う
業務での例
オンプレミスの重要サーバー 50 台を Elastic Disaster Recovery で AWS に継続的に複製し、災害時は数分で起動する。普段は軽量のステージング領域だけを動かす。
紛らわしい点・試験の注意
- Elastic Disaster Recovery はステージングの費用だけで、復旧時に本番の容量を起動する
- グローバルデータベースのセカンダリは読み取り専用(切り替えで昇格)
- DR の手順は訓練しないと、実際には動かないことがある
ミニクイズ
Q1. VPC ピアリングの説明として誤っているものはどれか。
- ピアリング接続を作成したあと、双方のルートテーブルにルートを追加する必要がある
- A と B、B と C をそれぞれピアリングすれば、A から B を経由して C と通信できる
- CIDR が重複している VPC 同士はピアリングできない
- 異なるリージョン、異なるアカウントの VPC ともピアリングできる
答えと解説を見る
正解:B A と B、B と C をそれぞれピアリングすれば、A から B を経由して C と通信できる
VPC ピアリングは推移的ルーティングをサポートしない。A と C を通信させるには A と C を直接ピアリングするか、Transit Gateway を使う。
Q2. グループの全アカウントで、新しく作る VPC の CIDR がオンプレミスや他の VPC と重ならないようにしたい。運用の負荷が最も小さい方法はどれか。
- IPAM でアドレスプールを作り、組織のアカウントに CIDR を割り当てて重複を監視する
- 共有のスプレッドシートに使用中の CIDR を書き、VPC を作る担当者が手作業で確認して記入する
- すべての VPC で同じ 10.0.0.0/16 を使い、重複した場合は NAT で変換して通信させる
- 各アカウントの管理者が自由に CIDR を決め、重複したら後から VPC を作り直す運用にする
答えと解説を見る
正解:A IPAM でアドレスプールを作り、組織のアカウントに CIDR を割り当てて重複を監視する
IPAM は組織全体の IP アドレスの計画・割り当て・監視を自動化する。手作業の台帳は誤りや更新漏れが起きやすい。
参考リンク
1.4マルチアカウントの AWS 環境を設計する
1.4 マルチアカウント AWS 環境を設計する。
概念
マルチアカウントは、AWS Organizations の OU(組織単位)でアカウントを分類し(セキュリティ・インフラ・ワークロード・サンドボックスなど)、AWS Control Tower でランディングゾーン(ログアーカイブ・監査のアカウント、コントロール(ガードレール)、Account Factory)を自動で構築します。人のアクセスは IAM Identity Center、共有のリソースは RAM で配ります。
仕組み・手順
- OU の構造を、目的と適用するポリシーで設計する
- Control Tower でランディングゾーンを作り、ログと監査のアカウントを分ける
- 予防・検出のコントロールを OU ごとに有効にする
- Account Factory(または AFT)で新しいアカウントを標準の設定で発行する
- IAM Identity Center の許可セットで、アカウントごとのアクセスを管理する
業務での例
新しいプロジェクトのアカウントを Account Factory で発行すると、自動で CloudTrail・Config・ネットワークが設定され、開発の OU のガードレールが適用される。
紛らわしい点・試験の注意
- 1 つのアカウントにすべてを入れると、権限・コスト・障害の分離が難しい
- Control Tower のコントロールの中身は SCP や Config ルール
- 管理アカウントにはワークロードを置かない
ミニクイズ
Q1. 組織の全アカウントの API の操作記録を、改ざんされない形で1か所に長期保管したい。最も適切な構成はどれか。
- 本番アカウントの S3 バケットに保存し、バケットポリシーで全社員がログを読めるようにして透明性を高める
- 各アカウントの管理者に、毎月 CloudTrail のイベント履歴を CSV でダウンロードさせ、本社の共有フォルダに日付ごとに置かせる
- 各アカウントで個別に CloudTrail の証跡を作り、それぞれのアカウントの S3 バケットに保存しておく
- 組織の CloudTrail 証跡を作り、ログアーカイブ用アカウントの S3 バケットにオブジェクトロックを有効にして保存する
答えと解説を見る
正解:D 組織の CloudTrail 証跡を作り、ログアーカイブ用アカウントの S3 バケットにオブジェクトロックを有効にして保存する
組織の証跡を使うと全アカウントのイベントを1つの S3 バケットに集約できる。ログ専用のアカウントに分離し、オブジェクトロックで削除や上書きを防ぐ。
Q2. 社員は Microsoft Entra ID で認証している。全アカウントへのアクセスを社員の ID で管理し、入社・退職の反映を自動化したい。最も適切な方法はどれか。
- Entra ID のパスワードと同じ文字列を IAM ユーザーに設定するよう、社員に入社時に依頼しておく
- 共有の IAM ユーザーを部署ごとに1つ作り、パスワードを部署内で共有して定期的に変更していく
- IAM Identity Center の ID ソースに Entra ID を設定し、SCIM でユーザーとグループを自動で同期する
- 各アカウントに社員ごとの IAM ユーザーを作り、人事部から退職の連絡を受けたら手作業で削除する
答えと解説を見る
正解:C IAM Identity Center の ID ソースに Entra ID を設定し、SCIM でユーザーとグループを自動で同期する
外部 IdP を ID ソースにすると社員は社内の ID でサインインでき、SCIM の自動プロビジョニングで入社・退職がすぐに反映される。
参考リンク
1.5コスト最適化と可視化の戦略を決定する
1.5 コスト最適化と可視化の戦略を決定する。
概念
組織全体のコストの可視化には、一括請求、コスト配分タグ(タグポリシーで標準化)、AWS Cost Categories(部門・製品などのルールでコストを分類)、Cost and Usage Report(CUR)と Athena・QuickSight の分析を使います。Savings Plans とリザーブドインスタンスの割引は組織内で共有され、AWS Budgets と Cost Anomaly Detection で予算超過や異常を検知します。
仕組み・手順
- タグの標準(cost-center・env など)を決め、タグポリシーで強制する
- Cost Categories で、アカウントやタグから部門別のコストを定義する
- CUR を S3 に出力し、Athena・QuickSight で分析する
- Savings Plans を管理アカウントで購入し、組織で共有する(必要なら共有を制限)
- Budgets と Cost Anomaly Detection で通知する
業務での例
事業部ごとの AWS の費用を毎月配賦するため、アカウントとタグのルールで Cost Categories を定義し、QuickSight のダッシュボードで各部長に共有する。
紛らわしい点・試験の注意
- タグは付ける前の費用には遡って適用されない
- Cost Categories は既存のデータにもルールを適用できる(タグとの違い)
- 割引の共有は請求の設定で無効にもできる
ミニクイズ
Q1. 全アカウントを Control Tower の管理下に置いた。事業部別の費用配賦を始めるために、次に行うべきことはどれか。
- グループ全体の費用を、各社の売上の比率で機械的に按分しておく
- タグの付け方をタグポリシーで統一し、コスト配分タグを有効にする
- 全社のアカウントを1つに統合して、事業部の区別そのものをなくす
- 各社の請求書の PDF を、経理部が毎月表計算ソフトに手で転記する
答えと解説を見る
正解:B タグの付け方をタグポリシーで統一し、コスト配分タグを有効にする
タグを費用の集計に使うには、タグの付け方を統一し、コスト配分タグとして有効にする必要がある。その後 Cost Categories や Cost Explorer で事業部別に集計する。
Q2. 組織全体のガードレールを設計している。メンバーアカウントの誰であっても、CloudTrail の証跡を停止・削除できないようにしたい。管理者権限を持つユーザーも含める。最も適した仕組みはどれか。
- リソースコントロールポリシー(RCP)
- サービスコントロールポリシー(SCP)
- Organizations のタグポリシー
- IAM のアクセス許可の境界
答えと解説を見る
正解:B サービスコントロールポリシー(SCP)
SCP はメンバーアカウントの IAM ユーザー・ロール(ルートユーザーを含む)が実行できる操作の上限を決める。拒否は IAM ポリシーの許可より優先される。
参考リンク
レッスンは当サイトがAWS 認定の公式ページと公式試験ガイドをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。
ご利用上の注意(非公式・独自問題・合格保証なし)
- 本サイトの問題は、公式に公開されているスキル概要・試験ガイドをもとに当サイトが独自に作成した練習問題であり、実際の試験問題ではありません。
- Amazon Web Services、AWS、および関連するマークは、米国その他の国における Amazon.com, Inc. またはその関連会社の商標です。本サイトは AWS(Amazon Web Services)と提携しておらず、AWS による承認・推奨を受けたものではありません。
- 本コンテンツは学習の補助であり、合格を保証するものではありません。試験の内容・形式・前提条件は予告なく変更されます。受験前に必ず公式ページで最新情報を確認してください。
- 本模擬試験の正答率は、公式試験の換算(スケール)スコア(合格 750)とは換算できず、合否を予測するものではありません。
- 未ログイン時の進捗はこのブラウザ内(localStorage)に保存します。Google でログインすると学習記録をアカウントに同期します。端末内の記録とサーバー上の記録は別に削除します。詳しくは保存・同期の説明とCookie・保存設定をご確認ください。