以下の形式で整理しました。
■問題文
ある会社は、手動で作成した VPC で AWS のソリューションを実行しています。同社は AWS CloudFormation を使用して、インフラストラクチャの他の部分(サーバー、データベース、ネットワーク構成など)をプロビジョニングしています。新しい要件によると、同社はすべてのインフラストラクチャを自動で管理する必要があります。
最小限の努力でこの新しい要件を満たす最適な方法を選択してください。
■選択肢
A. VPC を作成する新しい CloudFormation テンプレートを作成します。AWS Serverless Application Model (AWS SAM) CLI を使用して VPC をインポートします。
B. 既存の VPC リソースと構成を厳密にプロビジョニングする新しい AWS Cloud Development Kit (AWS CDK) スタックを作成します。AWS CDK を使用して、VPC をスタックにインポートし、VPC を管理します。
C. 既存の VPC リソースと構成を厳密にプロビジョニングする新しい CloudFormation テンプレートを作成します。CloudFormation コンソールから、既存のリソースをインポートして、新しいスタックを作成します。
D. VPC を作成する CloudFormation StackSet を作成します。StackSet を使用して、VPC をスタックにインポートします。
■問題文の要件の概要
- 手動作成した VPC を既存の CloudFormation 管理に組み込みたい
- 既存リソースを削除せずに IaC 化する必要がある
- 最小限の作業で自動管理に移行したい
■正解の選択肢と解説
正解:C
- CloudFormation のリソースインポート機能を利用し、既存の VPC を新しいスタックに取り込み、テンプレートで定義して管理可能にする。
- 既存リソースを再作成せずに IaC 配下に置けるため、ダウンタイムなしで移行可能。
- 他のリソース(EC2, RDS など)と同様に変更追跡・再デプロイが可能になり、インフラ全体の自動化が一貫する。
■不正解の選択肢の理由
- A(SAM CLI)
SAM はサーバーレス向けであり、VPC インポートを直接サポートせず追加作業と学習コストが増大。 - B(AWS CDK)
既存構成をコード化する必要があり、パラメータの再定義が必要になるため作業量が多い。 - D(StackSet)
StackSet はマルチアカウント・マルチリージョン展開用で、単一アカウント内 VPC インポートには不要で設定手間が増える。
■SAP試験で押さえておくべきポイント
- CloudFormation リソースインポートは既存リソースを削除せずにスタック管理下へ移行できる。
- リソースインポート時はテンプレートに DeletionPolicy を設定し、対象リソースの識別子を正しく指定する必要がある。
- SAM は Lambda や API Gateway などのサーバーレス特化ツールであり、VPC 管理には適さない。
- CDK は新規構築や大規模コード化に強いが、最小作業の要件には不向き。
- StackSet は複数アカウント展開向けで、単一アカウント移行には不要。
このパターンは**「既存リソースをIaCに取り込む最短ルート」を問う典型問題なので、本番で見たら即 CloudFormation のリソースインポート**を選べますね。
以下の形式で整理しました。
■問題文
ある企業では、公開されている Application Load Balancer (ALB) の背後にある Auto Scaling グループの Amazon EC2 インスタンス上で動作するウェブアプリケーションを開発しています。特定の国のユーザーのみがアプリケーションにアクセスできます。会社には、ブロックされたアクセス要求をログに記録する機能が必要です。
メンテナンスを最小限に抑える必要があります。これらの要件を満たすソリューションを選択してください。
■選択肢
A. 指定した国に属する IP 範囲のリストを含む IPSet を作成します。AWS WAF のウェブ ACL を作成します。IPSet 内の IP 範囲から発信されていないリクエストをブロックするルールを設定します。ルールをウェブ ACL に関連付けます。ウェブ ACL を ALB に関連付けます。
B. AWS WAF のウェブ ACL を作成します。指定した国から発信されていないリクエストをブロックするルールを設定します。そのルールをウェブ ACL に関連付けます。ウェブ ACL を ALB に関連付けます。
C. 指定した国から発信されていないリクエストをブロックするように AWS Shield を設定します。AWS Shield を ALB に関連付けます。
D. 指定した国に属する IP 範囲からのポート 80 と 443 を許可するセキュリティグループのルールを作成します。そのセキュリティグループを ALB に関連付けます。
■問題文の要件の概要
- 特定の国からのみアクセス許可
- ブロックされたアクセスのログ取得
- 運用負荷(メンテナンス)を最小化
- ALB 背後の Auto Scaling 環境
■正解の選択肢と解説
正解:B
- AWS WAF Geo match rule を使えば国単位でのアクセス制御が可能。
- ALB にウェブ ACL を関連付けることで、アプリケーション側やインスタンス側の設定変更不要で一元管理可能。
- AWS WAF はブロックしたリクエストも CloudWatch Logs や S3 に保存でき、ログ要件も満たす。
- IP範囲管理やサーバー運用が不要で、運用負荷が低い。
■不正解の選択肢の理由
- A(IPSet 利用)
IPSet は固定IPプレフィックスでの制御しかできず、国別割当の変更に対応するため頻繁な更新が必要。運用負荷が高く、要件の「メンテナンス最小化」に反する。 - C(AWS Shield)
AWS Shield は L3/L4 レベルのDDoS対策サービスで、国別アクセス制御や通常リクエストの詳細ログ取得は不可。 - D(セキュリティグループ)
SG は国単位での制御ができず、許可/拒否ログの取得もできない。IP範囲管理も手作業で運用負荷が高い。
■SAP試験で押さえておくべきポイント
- Geo match rule は AWS WAF のみが提供し、国単位での許可/拒否が可能。
- AWS WAF は ALB/CloudFront/API Gateway/AppSync と連携可能で、ブロックログも取得できる。
- AWS Shield は国別アクセス制御ではなく、DDoS防御専用。
- セキュリティグループやNACLはIP/CIDR単位での制御であり、Geo判定は不可。
- 「低運用負荷でのアクセス制御+ログ取得」という組み合わせは、AWS WAF + Geo match が模範解答。
この問題は 「サービスの役割の切り分け」 と 「メンテナンス負荷の低いアクセス制御方法」 を理解しているかを問う典型例です。
以下の通り整理しました。
■問題文
アプリケーションは、us-east-1 リージョンで Amazon RDS for MySQL マルチ AZ DB インスタンスを使用しています。フェイルオーバーのテスト後、アプリケーションはデータベースへの接続を失い、接続を再確立できませんでした。アプリケーションの再起動後、アプリケーションは接続を再確立しました。
ソリューションアーキテクトは、再起動せずにアプリケーションがデータベースへの接続を再確立できるように、ソリューションを実装する必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢
A. Amazon Aurora MySQL Serverless v1 DB インスタンスを作成します。RDS DB インスタンスを Aurora Serverless v1 DB インスタンスに移行します。アプリケーションの接続設定を更新して、Aurora リーダーエンドポイントを指すようにします。
B. RDS Proxy を作成します。既存の RDS エンドポイントをターゲットとして構成します。アプリケーションの接続設定を更新して、RDS Proxy エンドポイントを指すようにします。
C. 2 ノードの Amazon Aurora MySQL DB クラスターを作成します。RDS DB インスタンスを Aurora DB クラスターに移行します。RDS Proxy を作成します。既存の RDS エンドポイントをターゲットとして構成します。アプリケーションの接続設定を更新して、RDS Proxy エンドポイントを指すようにします。
D. Amazon S3 バケットを作成します。AWS Database Migration Service (AWS DMS) を使用して、Amazon S3 にデータベースをエクスポートします。データストアとして S3 バケットを使用するように Amazon Athena を構成します。アプリケーションの最新の ODBC ドライバをインストールします。アプリケーションの接続設定を更新して、Athena エンドポイントを指すようにします。
■問題文の要件の概要
- RDS for MySQL マルチAZ構成でフェイルオーバー後にアプリ接続が失われる
- 再起動せずに接続を復旧させたい
- アプリケーション側の改修は最小限にしたい
- 高可用性と接続の透過的な切り替えが必要
■正解の選択肢と解説
正解:B
- Amazon RDS Proxy は、RDS/Aurora の前段に配置して接続プーリングを行い、フェイルオーバー時に透過的に新しいプライマリDBに接続を切り替え可能。
- DNS再解決やクライアント側の再接続処理を待たずに、アプリ側は同一エンドポイントで接続を維持できる。
- 接続数の最適化、サージ吸収、IAM認証やSecrets Manager連携などの付加機能も提供。
- コード改修不要な場合が多く、既存環境に容易に追加できる。
■不正解の選択肢の理由
- A(Aurora Serverless v1 移行)
Aurora Serverlessはスケーリングや一時停止機能はあるが、フェイルオーバー時はDNS切り替えベース。アプリ側がDNS再解決をしない場合は接続は復旧しないため要件を満たさない。 - C(Aurora+RDS Proxy移行)
Aurora移行は大規模変更で移行コスト・リスクが高い。また、Auroraクラスターと既存RDSエンドポイントの組み合わせは整合性を欠く。要件に対して過剰かつ不適切。 - D(S3+DMS+Athena)
DMS+Athena構成は分析向けであり、OLTPのリアルタイム接続やフェイルオーバー復旧の要件を満たさない。
■SAP試験で押さえておくべきポイント
- RDS Proxyの役割:接続プーリング、透過的フェイルオーバー、認証情報管理、接続数制御。
- マルチAZ構成ではフェイルオーバー時にDNS変更が発生し、クライアントが再接続処理をしないと復旧しない。
- AuroraやServerless移行は機能やフェイルオーバー挙動が異なり、透過的接続維持は別の仕組みが必要。
- AthenaやDMSは分析・ETL用途であり、トランザクション処理向きではない。
- 「再起動なしで接続復旧」+「変更最小」 の条件では RDS Proxy がベストプラクティス。
この問題は 「フェイルオーバー時の接続維持方法」 と 「アプリ改修を最小限にするアーキテクチャ」 を問う典型例です。
以下の通り整理しました。
■問題文
ある会社は、単一の AWS アカウントで複数のワークロードを実行しています。新しい会社のポリシーは、エンジニアが承認されたリソースのみをプロビジョニングでき、エンジニアはこれらのリソースをプロビジョニングするために AWS CloudFormation を使用しなければなりません。ソリューションアーキテクトは、エンジニアがアクセスに使用する IAM ロールに新しい制限を強制するためのソリューションを作成する必要があります。
ソリューションを作成する最適な方法を選択してください。
■選択肢
A. 承認されたリソースを含む AWS CloudFormation のテンプレートを Amazon S3 バケットにアップロードします。エンジニアの IAM ロールの IAM ポリシーを更新して、Amazon S3 と AWS CloudFormation へのアクセスのみを許可します。AWS CloudFormation のテンプレートを使用してリソースをプロビジョニングします。
B. エンジニアの IAM ロールの IAM ポリシーを、承認されたリソースのプロビジョニングと AWS CloudFormation のみを許可する権限に更新します。AWS CloudFormation のテンプレートを使用して、承認されたリソースでスタックを作成します。
C. エンジニアの IAM ロールの IAM ポリシーを更新し、AWS CloudFormation のアクションのみを許可するアクセス許可を与えます。承認されたリソースをプロビジョニングするアクセス許可を持つ新しい IAM ポリシーを作成し、そのポリシーを新しい IAM サービス ロールに割り当てます。スタックの作成中に IAM サービスロールを AWS CloudFormation に割り当てます。
D. AWS CloudFormation のスタックにリソースをプロビジョニングします。エンジニアの IAM ロールの IAM ポリシーを更新し、自分の AWS CloudFormation スタックへのアクセスのみを許可します。
■問題文の要件の概要
- 単一AWSアカウントで複数ワークロードを運用
- 承認されたリソースのみプロビジョニング可能にする必要
- プロビジョニングは CloudFormation 経由のみ
- エンジニアのIAMロールに制限を課す
- ガバナンスと最小権限モデルの実現が必須
■正解の選択肢と解説
正解:C
- エンジニアのIAMロールには CloudFormation操作のみ許可 し、リソース作成権限は持たせない。
- 承認されたリソース作成権限を別の IAMサービスロール(CloudFormation実行ロール) に付与する。
- CloudFormationスタック作成時にそのサービスロールを指定することで、テンプレート内の許可リソースだけを作成できる。
- この方式により、エンジニアは直接リソースを作成できず、ポリシーに反するリソース作成が防止される。
- 最小権限設計、権限分離、監査証跡の明確化が可能。
■不正解の選択肢の理由
- A
S3にテンプレートを置いてアクセス制限しても、エンジニアは別テンプレートを使って任意リソースを作成できる。テンプレート内容の強制ができずガバナンス不足。 - B
IAMポリシーで承認リソース作成権限を直接エンジニアに付与すると、テンプレート改変で承認外リソースも作成可能になり、権限分離ができない。 - D
スタック単位でのアクセス制限はできても、テンプレート内のリソース種別を制御できないため、承認外リソースを混入される可能性が残る。
■SAP試験で押さえておくべきポイント
- CloudFormationサービスロールはスタック実行時の権限を委譲する仕組みで、ユーザーのIAMロールと分離できる。
- 最小権限モデルでは、ユーザーにCloudFormation操作権限だけを与え、リソース権限は実行ロール側で管理する。
- IAMポリシーだけでリソース種別の制御は難しく、サービスロールやガードレール(SCP・CloudFormationガード)を組み合わせる必要がある。
- 試験では 「直接権限付与」より「サービスロール経由」 の方がガバナンス面で正解になるケースが多い。
この問題は 「権限分離によるガバナンス」 と 「CloudFormationサービスロールの活用」 を理解しているかを問う典型例です。
了解しました。以下の通り、指定フォーマットに沿って整理しました。
■問題文
会社の工場の自動化アプリケーションは、単一の VPC で実行されています。20 以上のアプリケーションが、Amazon EC2、Amazon Elastic Container Service (Amazon ECS)、および Amazon RDS の組み合わせで実行されています。
同社では、ソフトウェアエンジニアが 3 つのチームに分かれています。3 つのチームのうち 1 チームが各アプリケーションを所有しており、各チームはそのアプリケーションのすべてのコストとパフォーマンスに責任を負っています。チームのリソースは、そのアプリケーションとチームを表すタグがあります。チームは日々の活動に IAM アクセスを使用しています。
会社は、毎月の AWS 請求書のどのコストが各アプリケーションやチームに起因するかを判断する必要があります。会社はまた、過去 12 ヶ月のコストを比較し、次の 12 ヶ月のコストを予測するのに役立つレポートを作成する必要があります。ソリューションアーキテクトは、これらのコストレポートを提供する AWS Billing and CostManagement ソリューションを推奨する必要があります。
これらの要件を満たすアクションの組み合わせを選択してください。 (3 つ選択)
■選択肢
A. アプリケーションとチームを表す、ユーザー定義のコスト配分タグをアクティブ化にします。
B. アプリケーションとチームを表す、AWS 生成コスト配分タグをアクティブ化にします。
C. AWS Billing and Cost Management コンソールで各アプリケーションのコストカテゴリを作成します。
D. AWS Billing and Cost Management コンソールへの IAM アクセスを有効にします。
E. AWS Budgets を作成します。
F. Cost Explorer を有効にします。
■問題文の要件の概要
- 各アプリケーション・チーム別のコスト可視化(タグで区分)
- 過去12ヶ月のコスト比較と次の12ヶ月のコスト予測
- AWS Billing and Cost Management を使ったレポート作成
■正解の選択肢と解説
A. ユーザー定義のコスト配分タグをアクティブ化
- リソースに付与した「アプリケーション」「チーム」タグを課金データに反映し、Cost ExplorerやCURで集計可能にする。
C. コストカテゴリを作成
- タグ値をもとに複数リソースをアプリケーション単位にグループ化し、レポートをわかりやすくする。
F. Cost Explorer を有効化
- 過去12ヶ月の履歴分析と12ヶ月先までのコスト予測を提供。タグやコストカテゴリでフィルタ可能。
■不正解の選択肢の理由
B. AWS 生成コスト配分タグのアクティブ化
- AWS側が自動付与する限定的なタグであり、カスタムの「アプリケーション」「チーム」区分を反映できない。
D. Billing and Cost Management への IAM アクセス有効化
- 権限付与設定であり、コスト可視化や予測レポート機能の有効化には直結しない。
E. AWS Budgets 作成
- 予算管理・アラート通知が目的であり、過去比較や将来予測の可視化には適さない。
■SAP試験で押さえておくべきポイント
- ユーザー定義コスト配分タグは課金データに連携し、タグ単位のコスト集計が可能。
- コストカテゴリはタグやアカウントを論理的にグループ化して管理しやすくする機能。
- Cost Explorerは過去分析+将来予測を提供する唯一の標準ツール。
- AWS 生成タグは限定的で、カスタム分析要件には向かない。
- Budgetsは予算・アラート用で、詳細分析はCost ExplorerやCURで行う。
この形式で続けて整理していけば、SAP試験対策用の自分専用問題集が作れます。
次の問題も同じフォーマットでまとめますか?
以下の通り、指定フォーマットで整理しました。
■問題文
ある企業のウェブアプリケーションに信頼性の問題があります。このアプリケーションは世界中のお客様にサービスを提供しています。アプリケーションは単一の Amazon EC2 インスタンスで実行され、Amazon RDS for MySQL データベースで読み取り集中型の操作を実行します。
高負荷時にはアプリケーションが応答しなくなり、EC2 インスタンスを手動で再起動する必要があります。ソリューションアーキテクトは、アプリケーションの信頼性を改善する必要があります。
最も少ない開発工数でこの要件を満たすソリューションを選択してください。
■選択肢
A. Amazon CloudFront ディストリビューションを作成します。ディストリビューションのオリジンとして EC2 インスタンスを指定します。RDS for MySQL データベースのマルチ AZ 配置を構成します。読み取り集中型の操作にはスタンバイ DB インスタンスを使用します。
B. Auto Scaling グループにある EC2 インスタンスでアプリケーションを実行します。EC2 インスタンスを Elastic Load Balancing (ELB) ロードバランサーの背後に配置します。データベースサービスを Amazon Aurora に置き換えます。読み取り集中型の操作には Aurora レプリカを使用します。
C. AWS Global Accelerator をデプロイします。RDS for MySQL データベースのマルチ AZ 配置を設定します。読み取り集中型操作にはスタンバイ DB インスタンスを使用します。
D. アプリケーションを AWS Lambda 関数に移行します。RDS for MySQL データベースのリードレプリカを作成します。読み取り集中型操作にはリードレプリカを使用します。
■問題文の要件の概要
- 単一EC2構成による信頼性不足を改善
- 高負荷時の自動スケールと冗長化
- 読み取り集中型ワークロードのDB性能向上
- 最小限の開発工数で実現
■正解の選択肢と解説
正解:B
- Auto Scaling + ELB により計算層を自動スケール・冗長化し、単一インスタンス障害や手動再起動を排除。
- Amazon Aurora はマルチAZ構成を標準搭載し、障害時のフェイルオーバーも高速。
- Aurora レプリカ により読み取り負荷を水平分散し、DBスループットを維持。
- 既存アプリの大幅改修不要で、信頼性・性能を短期間で向上可能。
■不正解の選択肢の理由
- A:CloudFrontは静的コンテンツ配信の高速化が目的。単一EC2構成の高負荷問題は解決しない。RDSマルチAZのスタンバイはフェイルオーバー用で読み取り負荷分散は不可。
- C:Global Acceleratorはトラフィック経路最適化サービスであり、計算層のスケールやDB性能向上は行えない。
- D:Lambdaへの全面移行はアプリ改修工数が大きく、短期間での信頼性改善要件に反する。
■SAP試験で押さえておくべきポイント
- 可用性向上とスケーラビリティはAuto Scaling+ELBが基本。
- Aurora レプリカは読み取り性能向上に有効、マルチAZは可用性向上が目的。
- CloudFront・Global Acceleratorはネットワーク経路や静的配信最適化が役割で、計算層のスケールアウトには直接寄与しない。
- 最小工数での改善=既存構成の拡張で解決できるマネージドサービス活用が有効。
この形式であと数問まとめていけば、試験直前の総復習資料としてかなり使える内容になります。
以下の通り、指定フォーマットで整理しました。
■問題文
スタートアップ企業が、最新の Amazon Linux 2 AMI を使用して、プライベートサブネットに Amazon EC2 インスタンスのフリートをホストしています。同社のエンジニアは、トラブルシューティングのためにインスタンスへの SSH アクセスに大きく依存しています。
同社の既存のアーキテクチャは次のとおりです。
- プライベートサブネットとパブリックサブネットを持つ VPC と NAT ゲートウェイ
- オンプレミス環境との接続のための Site-to-Site VPN
- オンプレミス環境から直接 SSH アクセス可能な EC2 セキュリティグループ
同社は、SSH アクセスに関するセキュリティ制御を強化し、エンジニアが実行するコマンドの監査を提供する必要があります。
要件を満たす最適な方法をを選択してください。
■選択肢
A. EC2 インスタンスのフリートに EC2 Instance Connect をインストールして構成します。ポート 22 のインバウンド TCP を許可する EC2 インスタンスにアタッチされたすべてのセキュリティグループのルールを削除します。エンジニアに、EC2 Instance Connect CLI を使用してインスタンスにリモートアクセスするようにアドバイスします。
B. EC2 のセキュリティグループを更新して、エンジニアのデバイスの IP アドレスへのポート 22 のインバウンド TCP のみを許可します。すべての EC2 インスタンスに Amazon CloudWatch エージェントをインストールし、オペレーティングシステムの監査ログを CloudWatch Logs に送信します。
C. EC2 のセキュリティグループを更新して、エンジニアのデバイスの IP アドレスへのポート 22 のインバウンド TCP のみを許可します。EC2 のセキュリティグループのリソース変更のために AWS Config を有効にします。AWS Firewall Manager を有効にして、ルールの変更を自動的に修正するセキュリティグループのポリシーを適用します。
D. AmazonSSMManagedInstanceCore 管理ポリシーがアタッチされた IAM ロールを作成します。すべての EC2 インスタンスに IAM ロールをアタッチします。ポート 22 のインバウンド TCP を許可する EC2 インスタンスにアタッチされているすべてのセキュリティグループのルールを削除します。エンジニアが自分のデバイスに AWS Systems Manager Session Manager プラグインをインストールし、Systems Manager から start-session API 呼び出しを使用してインスタンスにリモートアクセスするようにします。
■問題文の要件の概要
- SSHアクセスのセキュリティ強化(ポート22閉鎖含む)
- エンジニアの実行コマンドを監査可能にする仕組み
- プライベートサブネット内のEC2インスタンスへの安全なリモートアクセス方法
■正解の選択肢と解説
正解:D
- AWS Systems Manager Session Manager を利用することで、ポート22を閉じたまま安全なリモートシェルアクセスを提供可能。
- Session Managerは、CloudWatch LogsやS3へのセッション入出力記録を有効化することで、実行コマンドや出力を改ざん不可能な形で保存でき、監査要件を満たす。
- AmazonSSMManagedInstanceCore ポリシー付きIAMロールをアタッチすることで、アクセス権限の集中管理と最小権限の付与が可能。踏み台ホストやSSHキー管理が不要になる。
■不正解の選択肢の理由
- A:EC2 Instance ConnectはSSHポート22を利用するため、ポートを閉じると接続できない。またコマンド監査機能はない。
- B:CloudWatchエージェントのOS監査ログでは対話型セッション中のコマンドを網羅的に記録できない。IP制限のみではゼロトラスト要件も不十分。
- C:AWS ConfigやFirewall Managerはセキュリティグループ設定の逸脱修正は可能だが、ポート22を閉じず監査も行えないため要件を満たさない。
■SAP試験で押さえておくべきポイント
- Session Managerはポートを閉じたまま安全・監査可能なアクセスを提供できる唯一のマネージド機能。
- 踏み台サーバー不要・SSHキー管理不要・IAMベースのアクセス制御を実現できる。
- CloudWatch Logs/S3連携で改ざん不可能な操作履歴を長期保存可能。
- EC2 Instance Connectは監査目的には向かない。
- AWS ConfigやFirewall Managerは構成管理・逸脱修正が主目的であり、コマンド監査は別の仕組みが必要。
この整理の仕方なら、同系統の「安全なリモートアクセス+監査」系問題も一括で復習できます。
次の問題も同じフォーマットでまとめますか?