Uncategorized

#22

以下は、問題1の整理・解説です。


■ 問題文

ある企業が、米国に拠点を置くパートナー 6 社と情報を共有するための REST API を作成しています。同社は Amazon API Gateway リージョンエンドポイントを作成しました。6 社のパートナーはそれぞれ 1 日 1 回 API にアクセスし、日々の売上を投稿します。

初期導入後、同社は世界中の 500 の異なる IP アドレスから発信される毎秒 1,000 のリクエストを観測しました。同社は、このトラフィックはボットネットから発信されていると考えており、コストを最小限に抑えながら API を保護したいと考えています。

API を保護する最適な方法を選択してください。


■ 選択肢

  • A. API をオリジンとして Amazon CloudFront ディストリビューションを作成します。AWS WAF のウェブ ACL を作成し、1 日に 5 回以上のリクエストを送信するクライアントをブロックするルールを設定します。ウェブ ACL を CloudFront に関連付け、OAC 経由で API Gateway に制限をかけます。
  • B. CloudFront を介し API キー付きのカスタムヘッダーを追加し、POST メソッドに API キーを要求するよう API を構成します。
  • C. AWS WAF で 6 社の IP を許可するルールを設定し、リソースポリシーで制限をかけ、API キーを要求します。
  • D. AWS WAF で 6 社の IP を許可し、使用量プランを作成して API キーを制御する。(✅ 正解)

■ 問題文の要件の概要

  • 正規ユーザーは 6社のみ(=明確なホワイトリスト管理が可能)
  • 不正アクセス元は世界中の多数のIPアドレスからの高頻度アクセス
  • コスト最小化が必要(無駄なAPI呼び出しを防ぎたい)
  • APIを防御し、リクエスト頻度を制御する必要がある

✅ 正解の選択肢と解説

  • 正解:D

理由:

  • WAFのIP許可リストで、6社以外のアクセスを根本的にブロック
  • API Gatewayの使用量プラン(Usage Plan)とAPIキーを組み合わせることで、各社ごとの**リクエスト制限(スロットリング)**が可能
  • APIキーの管理により、想定以上のアクセスを拒否
  • この構成により、ボットによるDoSや不正利用を回避しつつ、必要最低限のリソースでセキュアな運用が実現

❌ 不正解の選択肢の理由

A. CloudFront + OAC + WAF(リクエスト5回超でブロック)

  • OAC(オリジンアクセスコントロール)はS3やALB向けであり、API Gateway には非対応
  • WAFで「1日5回以上」でブロックというルールは粗すぎて無力。1秒1,000リクエストという高頻度攻撃に対応不可
  • API GatewayとWAFの制御粒度の違いを誤解している構成

B. CloudFront + APIキー付きカスタムヘッダー

  • CloudFrontはAPIキーの検証を行わない
  • API Gateway側が正しいAPIキーであるかを確認する保証がなく、セキュリティに不安
  • さらに、ボット対策(IP制限)にもなっていない

C. WAF + IP制限 + リソースポリシー

  • IP制限は適切だが、リソースポリシーでは使用量制限ができない
  • 結果として、APIキーを発行してもスロットリングや上限が効かないため不正リクエストが防げない

🎯 SAP試験で押さえておくべきポイント

  • API Gatewayを保護する構成では、以下の組み合わせが有効:
    • AWS WAF:IP制限、ボット対策、悪意あるリクエストブロック
    • API Gateway Usage Plan + API Key:クライアントごとのリクエスト制御、スロットリング
  • CloudFrontはAPI Gatewayとの直接統合が難しいケースがあるため、構成適用には注意が必要
  • リソースポリシーはIP許可などのアクセス許可には使えるが、レート制限は不可
  • APIキーを利用する場合は、必ず使用量プランと組み合わせることで有効化
  • ボットネット対策には「防御の層」が必要であり、IP制限+スロットリングの併用がベストプラクティス

次の問題も続けて送ってください!同様の形式で分析いたします。

以下は、問題2の整理・解説です。


■ 問題文

ある企業は、開発用にいくつかの AWS アカウントを持っており、本番アプリケーションを AWS に移行したいと考えています。同社は、Amazon Elastic Block Store (Amazon EBS) の暗号化を、現在の本番アカウントと将来の本番アカウントのみに適用する必要があります。同社は、組み込みのブループリントとガードレールを含むソリューションを必要としています。

これらの要件を満たす手順の組み合わせを選択してください。(3 つ選択)


■ 選択肢

  • A. AWS CloudFormation StackSets を使用して、本番アカウントに AWS Config ルールをデプロイします。
  • B. 既存の開発者アカウントで新しい AWS Control Tower ランディングゾーンを作成します。アカウントの OU を作成します。本番アカウントと開発アカウントをそれぞれ本番 OU と開発 OU に追加します。
  • C. 会社の管理アカウントに新しい AWS Control Tower ランディングゾーンを作成します。本番アカウントと開発アカウントをそれぞれ本番 OU と開発 OU に追加します。
  • D. 既存のアカウントを AWS Organizations の組織に招待します。SCP を作成し、コンプライアンスを確保します。
  • E. EBS 暗号化を検出するために、管理アカウントからガードレールを作成します。
  • F. EBS 暗号化を検出するために、本番 OU のガードレールを作成します。

■ 問題文の要件の概要

  • EBS 暗号化を本番アカウントのみに強制したい
  • 将来の本番アカウントにも適用される構成にしたい
  • 組み込みのブループリントとガードレールが必要(=Control Towerの利用を示唆)

✅ 正解の選択肢と解説

✅ C. 管理アカウントに新しい AWS Control Tower ランディングゾーンを作成

  • Control Tower は 組織の管理アカウントでのみセットアップ可能。
  • ランディングゾーンには OU(組織単位)を作成し、それぞれにアカウントを配置可能。
  • 組み込みガードレールを OU 単位で適用できる。

✅ D. AWS Organizations に既存アカウントを招待し、SCP を作成

  • AWS Organizations にアカウントを統合することで、SCP(Service Control Policy)を使用してアクセス制御が可能。
  • たとえば、EBS 作成時に暗号化を強制するような SCP を設定可能。
  • OU に対して適用できるため、本番 OU にだけ制限をかけることも可能

✅ F. 本番 OU のガードレールを作成

  • Control Tower のガードレールは OU 単位で適用可能。
  • 本番 OU にだけ暗号化の強制ルール(例:EBS must be encrypted)を適用することで、要件を満たす。
  • 将来 OU に追加されるアカウントにも 自動適用される。

❌ 不正解の選択肢の理由

❌ A. StackSets で AWS Config ルールを配布

  • AWS Config は検出(監視)ツールであり、強制ガードレールにはならない。
  • StackSets はテンプレートの配布には便利だが、将来のアカウントに自動適用されない

❌ B. 開発者アカウントで Control Tower を作成

  • Control Tower のセットアップは 管理アカウントのみ可能
  • 開発アカウントから OU 管理やガードレール適用はできないため誤り。

❌ E. 管理アカウントからガードレールを作成

  • 管理アカウント全体にガードレールを適用すると、開発 OU にも影響してしまい、
    本番アカウントのみに適用」という要件を満たせない。

🎯 SAP試験で押さえておくべきポイント

  • AWS Control Tower を使うと、組織に基づいた OU 単位で自動的にベストプラクティス(ガードレール)を適用できる。
  • OU (Organizational Unit) ごとに設定を変えることで、本番と開発で異なるルールを適用できる。
  • SCP(Service Control Policies) を使用すると、ルートユーザーを含むすべての IAM エンティティに対して制限を強制できる。
  • ガードレール ≠ AWS Config:Config はルール違反を「検出」するだけ、ガードレールや SCP は「強制」できる。

続きの問題があれば、また同じ形式で整理いたします!

以下は、問題3の整理・解説です。


■ 問題文

ある企業は、データセンターと AWS の間のハイブリッドソリューションを開発しました。同社は、Amazon VPC と、アプリケーションログを Amazon CloudWatch に送信する Amazon EC2 インスタンスを使用しています。EC2 インスタンスは、オンプレミスでホストされている複数のリレーショナルデータベースからデータを読み取ります。

同社は、どの EC2 インスタンスがデータベースに接続されているかをほぼリアルタイムで監視したいと考えています。同社はすでにオンプレミスで Splunk を使用する監視ソリューションを導入しています。ソリューションアーキテクトは、ネットワークトラフィックを Splunk に送信する方法を決定する必要があります。

これらの要件を満たす最適な方法を選択してください。


■ 選択肢

  • A. VPC フローログを有効にし、CloudWatch に送信。Lambda 関数を使って CloudWatch Logs を S3 にエクスポートし、Splunk が S3 からログを取得。
  • B. Kinesis Data Firehose ストリームを作成し、CloudWatch Logs のサブスクリプションからログを流し、Lambda を使って Splunk 向けに整形して送信。(✅ 正解)
  • C. EC2 のログを S3 に出力 → Athena でクエリ → 結果を S3 に → Lambda で Splunk へ送信。
  • D. Apache Flink で異常検出しつつ Kinesis Data Streams でデータ処理、結果を Firehose で Splunk へ送信。

■ 問題文の要件の概要

  • VPC フローログを使って EC2 の通信を追跡したい
  • Splunk に統合済み
  • リアルタイムで EC2 → データベースの接続状況を可視化したい
  • 最小構成かつ適切な AWS サービス統合

✅ 正解の選択肢と解説

  • 正解:B

解説:

  • VPC フローログを CloudWatch Logs に送信し、CloudWatch Logs のサブスクリプションフィルターでリアルタイムに Kinesis Data Firehose へ転送。
  • Firehose は Splunk へのネイティブサポート(HTTP Event Collector, HEC)を持ち、Lambda ストリームプロセッサで必要に応じてログ整形も可能。
  • 構成がシンプルかつリアルタイム性があり、完全マネージドで運用負荷が低い。
  • Splunk 側は HEC トークンを設定するだけで受信でき、セキュリティ上も安全。

❌ 不正解の選択肢の理由

A. S3 にエクスポートし Splunk が取得

  • バッチ処理構成であり、リアルタイム性を満たさない
  • ACCESS_KEY / SECRET_KEY による認証もセキュリティリスクを伴う。
  • 不必要に構成が複雑。

C. Athena → Lambda → Splunk

  • Athena や S3 は分析には適するが、リアルタイム監視には不向き
  • 「どのEC2が接続しているか」を即時に把握したい要件に対して、バッチ的な遅延処理では対応不可

D. Apache Flink + Firehose

  • 過剰な構成でコストと設計負荷が高い
  • Flink は高度なリアルタイム処理や異常検出には有効だが、
    本設問ではシンプルにフローログを可視化したいだけなのでオーバーエンジニアリング。

🎯 SAP試験で押さえておくべきポイント

  • **CloudWatch Logs + Kinesis Data Firehose + Splunk(HEC)**はリアルタイム監視の王道構成。
  • Firehose は Splunk のネイティブターゲットとして最適化されており、Lambda を間に挟んで整形可能
  • **バッチ(S3 / Athena) vs ストリーミング(Firehose / Logs サブスクリプション)**の違いを明確に。
  • 高度な分析が必要でなければ Flink や Kinesis Data Streams は過剰。コスト効率と目的に合った構成を選ぶべき。

次の問題もあれば、どうぞお送りください!同じフォーマットで続けて対応いたします。

以下は、問題4の整理・解説です。


■ 問題文

企業はオンプレミスのデータセンターから AWS への接続を確立する必要があります。同社は、VPC ネットワーク間の推移的なルーティング機能を使用して、異なる AWS リージョンにあるすべての VPC を接続する必要があります。
また、以下の追加要件があります:

  • ネットワークのアウトバウンドトラフィックのコストを削減
  • 帯域幅のスループットを向上
  • エンドユーザーに一貫したネットワークエクスペリエンスを提供

■ 選択肢(文字列そのまま)

  • A. オンプレミスのデータセンターと新しい中央 VPC の間に AWS Site-to-Site VPN 接続を作成します。中央 VPC から他のすべての VPC への VPC ピアリング接続を作成します。
  • B. オンプレミスのデータセンターと AWS の間に AWS Direct Connect 接続を作成します。トランジット VIF をプロビジョニングし、Direct Connect ゲートウェイに接続します。各リージョンの Transit Gateway を使用して、Direct Connect ゲートウェイを他のすべての VPC に接続します。
  • C. オンプレミスのデータセンターと新しい中央 VPC の間に AWS Site-to-Site VPN 接続を作成します。動的ルーティングを備えた Transit Gateway を使用します。Transit Gateway を他のすべての VPC に接続します。
  • D. オンプレミスのデータセンターと AWS の間に AWS Direct Connect 接続を作成します。各リージョンのすべての VPC 間に AWS Site-to-Site VPN 接続を確立します。中央 VPC から他のすべての VPC への VPC ピアリング接続を作成します。

■ 問題文の要件の概要

  • オンプレミスと AWS 間の高速・低遅延・安定した通信(=Direct Connect)
  • 複数リージョンにある VPC 間を接続(=Transit Gateway + Direct Connect Gateway)
  • 推移的ルーティングが必要(=VPC Peering では不可能)
  • コスト削減・一貫した体験・スループット向上(=Site-to-Site VPN では不十分)

✅ 正解の選択肢と解説

  • 正解:B

理由:

  • AWS Direct Connect:専用線による低レイテンシ・高帯域な通信。インターネットを経由しないため、コスト・品質面で VPN に勝る
  • Transit VIF(仮想インターフェース)+ Direct Connect Gateway:リージョンをまたいで VPC や Transit Gateway と接続可能。
  • Transit Gateway:リージョン内の複数 VPC を接続し、推移的ルーティングを実現
  • この構成により、グローバルで一貫したネットワーク構成と最適なパフォーマンスを確保

❌ 不正解の選択肢の理由

A. Site-to-Site VPN + VPC ピアリング

  • VPN はインターネット経由のトンネルであり、帯域・安定性が劣る
  • VPC ピアリングは推移的ルーティング非対応(A→B→Cは不可)。
  • すべての VPC 間に直接接続が必要になり、運用負荷が高い・非スケーラブル

C. VPN + Transit Gateway

  • Transit Gateway の導入は正しいが、Site-to-Site VPN がボトルネック
  • 高スループット・低レイテンシという要件に対して、VPN は不適
  • Direct Connect を使わずにこの要件を満たすのは難しい。

D. Direct Connect + VPC ピアリング + VPN

  • Direct Connect の選択は正しいが、それ以外が不適切。
  • VPC ピアリングは推移的ルーティング非対応。
  • 各リージョンのすべての VPC 間に VPN を貼る構成は複雑で非効率

🎯 SAP試験で押さえておくべきポイント

観点VPC PeeringTransit GatewayDirect Connect
推移的ルーティング-(Gateway構成次第)
複数リージョン対応✅(+Direct Connect GW)✅(DCGW+Transit GWで)
帯域・遅延普通良い優秀(最大100Gbps)
コスト安いがスケールしない適切初期費用は高いが転送料安
  • VPC Peering → 小規模構成での直接接続向け
  • Transit Gateway → 中〜大規模構成に対応、推移的通信が可能
  • Direct Connect + Transit Gateway(+DCGW) → 高速・高可用性・マルチリージョン対応の最適解

次の問題もあれば送ってください!
同じフォーマットでわかりやすく整理します。

以下は、問題5の整理・解説です。


■ 問題文

ある企業が事業を拡大しています。同社は、リソースを複数の AWS リージョンにおける数百の異なる AWS アカウントに分離することを計画しています。ソリューションアーキテクトは、特別に指定されたリージョン以外のオペレーションへのアクセスを拒否するソリューションを推奨する必要があります。


■ 選択肢(※編集せずそのまま)

  • A. アカウントごとに IAM ロールを作成します。アカウントに対して承認されたリージョンのみを含む、条件付きの許可権限を持つ IAM ポリシーを作成します。
  • B. AWS Organizations で組織を作成します。各アカウントに IAM ユーザーを作成します。各ユーザーにポリシーをアタッチして、アカウントがインフラストラクチャをデプロイできないリージョンへのアクセスをブロックします。
  • C. AWS Control Tower ランディングゾーンを起動します。OU を作成し、承認されたリージョン以外でのサービス実行へのアクセスを拒否する SCP をアタッチします。
  • D. 各アカウントで AWS Security Hub を有効にします。アカウントがインフラストラクチャをデプロイできるリージョンを指定するコントロールを作成します。

■ 問題文の要件の概要

  • 複数の AWS アカウント・複数リージョンを一元管理したい
  • 指定されたリージョン以外でのリソース操作を防ぎたい
  • スケーラブルで中央集権的な強制アクセス制御が必要

✅ 正解の選択肢と解説

  • 正解:C

理由:

  • AWS Control Tower を使えば、OU(組織単位)単位で SCP(Service Control Policy)を使って制限が可能。
  • aws:RequestedRegion 条件キーを使って「指定されたリージョン以外での操作」を明示的に Deny することで、全アカウント・全ユーザーに強制適用可能。
  • Control Tower により、Landing Zone の構築・アカウント作成・ポリシー適用を自動化でき、スケーラビリティと統制力が高い。
  • 数百アカウント規模でも、管理の一貫性と運用効率が維持される

❌ 不正解の選択肢の理由

A. IAM ロール + 条件付きポリシー

  • IAM ポリシーは許可モデル(Allowベース)。誤って明示的に許可されるとブロックできない。
  • root や AdministratorAccess を持つユーザーには強制不可
  • 各アカウントに個別設定が必要で運用負荷が高く、漏れの可能性あり

B. IAM ユーザーに制限付きポリシー

  • IAM ユーザー中心の管理は、数百アカウントでの運用にはスケーラビリティがない
  • 「誰が何をどこで」行えるかを一括で制御できず、一貫性の確保が困難
  • SCPのような強制力を持たないため要件未達。

D. AWS Security Hub による検出ベース

  • Security Hub は監視・可視化ツールであり、ブロック機能は持たない
  • 検出後の対応が必要な**事後的制御(Detective control)であり、要件の事前拒否(Preventive control)**を満たさない。

🎯 SAP試験で押さえておくべきポイント

制御手法特徴適用範囲強制力スケーラビリティ
IAM ポリシーAllow ベース、ユーザー単位の柔軟な制御アカウント内の IAM エンティティ△(誤設定のリスク)×(アカウントごとに管理必要)
SCP(Service Control Policy)Deny ベースの強制制御AWS Organizations の OU 単位✅(すべてのユーザー/ロールに強制)✅(数百アカウントに一括適用可)
Control TowerSCP 適用+自動アカウント作成+統制パターンの自動適用OU 管理に最適
Security Hub違反検出と可視化全体的な監視向け○(組織全体に可視化展開は可能)

✅ まとめ

「複数アカウント・複数リージョンでのガバナンス強制」には、Control Tower + SCP が最適解。
IAM ベースは柔軟性が高いが誤設定リスクが高く、Security Hub はあくまで検出用途。
SCP と IAM の違いを押さえ、ガバナンス設計時に適切な役割分担ができるかが SAP 試験の重要ポイントです。


次の問題もあれば送ってください!同じ形式で続けて解説いたします。

以下は、問題6の整理・解説です。


■ 問題文

ある企業は多数の個別の AWS アカウントを持っており、一元的な請求や管理を行っていません。各 AWS アカウントは、社内の異なる部門のサービスをホストしています。Microsoft Azure Active Directory が導入されています。

ソリューションアーキテクトは、同社の AWS アカウントの請求と管理を一元化する必要があります。同社は、手動によるユーザー管理の代わりに ID フェデレーションの利用を開始したいと考えています。同社はまた、有効期間の長いアクセスキーの代わりに一時的な認証情報を使用したいと考えています。

これらの要件を満たす手順の組み合わせを選択してください。(3つ選択)


■ 選択肢(文字列はそのまま)

  • A. 管理アカウントとして機能する新しい AWS アカウントを作成します。AWS Organizations に組織をデプロイします。既存の各 AWS アカウントを組織に参加するように招待します。各アカウントが招待を受け入れることを確認します。
  • B. 各 AWS アカウントのメールアドレスを aws+@example.com に設定し、アカウント管理メールメッセージと請求書が同じ場所に送信されるようにします。
  • C. 管理アカウントに AWS IAM Identity Center (AWS Single Sign-On) をデプロイします。IAM Identity Center を Azure Active Directory に接続します。ユーザーとグループを自動的に同期するように IAM Identity Center を構成します。
  • D. 管理アカウントに AWS Managed Microsoft AD ディレクトリをデプロイします。AWS Resource Access Manager (AWS RAM) を使用して、組織内の他のすべてのアカウントとディレクトリを共有します。
  • E. AWS IAM Identity Center (AWS Single Sign-On) の権限セットを作成します。適切な IAM Identity Center のグループと AWS アカウントに権限セットをアタッチします。
  • F. 各 AWS アカウントで AWS Identity and Access Management (IAM) を設定し、認証と承認に AWS Managed Microsoft AD を使用します。

■ 問題文の要件の概要

  • 請求とアカウント管理の一元化
  • Azure AD を使った ID フェデレーションの導入
  • アクセスキーの代わりに一時的な認証情報を使用

✅ 正解の選択肢と解説

✅ A. AWS Organizations による管理統合

→ 各アカウントを「管理アカウント」配下の組織に統合することで、**一括請求(コンソリデーティッドビリング)**や OU 単位でのガバナンス管理が可能になる。

✅ C. IAM Identity Center + Azure AD 連携

SCIM + SAML による Azure AD フェデレーションとユーザー同期を自動化。一時的な認証情報(STS)を利用し、長期アクセスキー不要。

✅ E. 権限セットの定義と割当

→ 権限セットは Identity Center における「ロールテンプレート」。これをアカウントとグループに紐づけることで、適切な最小権限アクセスと統制が実現される。


❌ 不正解の選択肢の理由

❌ B. メールアドレス統一では請求管理はできない

→ メールの送信先を共通にしても、一括請求や組織管理にはまったく関与しない。本質的な統合管理は不可。

❌ D. AWS Managed Microsoft AD + RAM は不適

→ Azure AD を活用したいのに、AD を AWS 上に別途構築しても意味がない。また、RAM はディレクトリ共有には使えない

❌ F. IAM + AWS Managed Microsoft AD

→ IAM 単体では Azure AD と直接連携できず、一時的な認証情報発行や自動同期も不可。Identity Center を使うべき。


🎯 SAP試験で押さえておくべきポイント

要件推奨サービス理由
請求・アカウント統合AWS Organizationsコンソリデーティッドビリング + OU 管理可能
ID フェデレーションIAM Identity Center + Azure ADSAML + SCIM による連携・同期が可能
一時認証情報使用IAM Identity Center + STS長期アクセスキー不要・セキュアなログイン実現
ポリシー割当の統制権限セット (IAM Identity Center)グループ/アカウントに基づくロール自動割当

✅ まとめ

AWS Organizations × IAM Identity Center × Azure AD 連携が王道のベストプラクティス。
本問は、SAP試験でも頻出の「マルチアカウント統合・ID管理戦略」の基本設計に関わる重要論点です。


次の問題もあれば、引き続き同様のフォーマットで解説します!

以下は、問題7の整理・解説です。


■ 問題文(そのまま)

ある企業は、Linux ベースの Amazon EC2 インスタンスを持っています。ユーザーは、EC2 の SSH キーペアを使用して SSH でインスタンスにアクセスする必要があります。
各マシンには一意の EC2 キーペアが必要です。同社は、リクエストに応じてすべての EC2 キーペアを自動的にローテーションし、キーを安全に暗号化された場所に保管するキーローテーションポリシーを実装したいと考えています。キーのローテーション中に発生するダウンタイムは 1 分以内とします。

これらの要件を満たすソリューションを選択してください。


■ 選択肢(そのまま)

  • A. すべてのキーを AWS Secrets Manager に保存します。Secrets Manager のローテーションスケジュールを定義して、AWS Lambda 関数を呼び出して新しいキーペアを生成します。EC2 インスタンスの公開キーを交換します。Secrets Manager でシークレットキーを更新します。
  • B. AWS Systems Manager の機能である Parameter Store に、すべてのキーを文字列として保存します。Systems Manager のメンテナンスウィンドウを定義して、AWS Lambda 関数を呼び出して新しいキーペアを生成します。EC2 インスタンスの公開キーを交換します。Parameter Store のシークレットキーを更新します。
  • C. EC2 キーペアを AWS Key Management Service (AWS KMS) にインポートします。これらのキーペアの自動キーローテーションを構成します。Amazon EventBridge のスケジュールされたルールを作成して、AWS Lambda 関数を呼び出し、AWS KMS でキーのローテーションを開始します。
  • D. すべての EC2 インスタンスを、AWS Systems Manager の機能である Fleet Manager に追加します。Systems Manager のメンテナンスウィンドウを定義し、Systems Manager Run Command ドキュメントを発行して、新しいキーペアを生成し、Fleet Manager のすべてのインスタンスに公開キーをローテーションします。

■ 問題文の要件の概要

  • 各 EC2 インスタンスに一意の SSH キーペアが必要
  • すべてのキーペアを 安全に保管したい
  • 自動ローテーションを実装したい
  • ダウンタイムは 1 分以内

✅ 正解の選択肢と解説

  • 正解:A

A. Secrets Manager + Lambda による自動ローテーション

  • AWS Secrets Manager は「シークレット(秘密情報)」をKMS で暗号化して安全に保管し、Lambda による自動ローテーションが可能
  • Lambda 関数は定期的に呼び出され、新しいキーペアを生成し、EC2 インスタンスの公開鍵を交換、Secrets Manager に秘密鍵を保存する処理を自動化できる。
  • この一連の流れにより、ダウンタイムを最小限(1分以内)に抑えつつ、安全・自動なキーローテーションを実現できる。

❌ 不正解の選択肢の理由

B. Parameter Store を使用する構成

  • Parameter Store は Secrets Manager のように自動ローテーション機能はなく、Lambda やメンテナンスウィンドウによる手動的構成になる。
  • 暗号化やアクセス管理はできるが、セキュリティ強度や自動化レベルが劣る

C. KMS にキーペアをインポートする構成

  • KMS はEC2 キーペア(SSH鍵)を直接管理対象としない
  • KMS は「対称鍵」や「非対称暗号鍵」を管理するサービスだが、SSHログイン鍵のローテーションや保存には非対応

D. Fleet Manager を利用した構成

  • Fleet Manager は可視化と操作管理が目的のGUIツールであり、キーペアの生成・ローテーション機能はない
  • Run Command を使えば手動対応は可能だが、Secrets Managerのようなセキュアな一貫管理は不可能

🎯 SAP試験で押さえておくべきポイント

要素適したサービス備考
セキュアなキーペア保存AWS Secrets ManagerKMS で暗号化、自動ローテーション対応
自動ローテーション実行AWS LambdaSecrets Manager による自動実行
手動 or 簡易な保存SSM Parameter Store簡易構成可だが自動ローテーション不可
キー管理外AWS KMSSSH キー保存用途ではない
管理GUI補助Fleet Manager運用支援用途、ローテーション不可

✅ まとめ

EC2 SSH キーペアの自動・安全なローテーションには Secrets Manager + Lambda がベストプラクティス。
SAP試験では、「セキュリティ」「可用性」「自動化」の観点を満たす構成を選ぶことが重要です。


次の問題もあれば、引き続き同じ形式で解説いたします!