以下は問題1の出力結果です。
■ 問題文（編集せずに出力）
ある会社はクイックサービスのレストランを経営しています。レストランは予測可能なモデルに従っており、毎日 4 時間は売上が高いです。ピーク時間外では販売トラフィックは減少します。
POS と管理プラットフォームは AWS クラウドにデプロイされ、Amazon DynamoDB に基づくバックエンドを備えています。データベーステーブルは、既知のピークリソース消費量に一致するように、100,000 RCU と 80,000 WCU のプロビジョニングされたスループットモードを使用します。
同社は、DynamoDB のコストを削減し、IT スタッフの運用オーバーヘッドを最小限に抑えたいと考えています。
これらの要件を最もコスト効率よく満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. プロビジョニングされた RCU と WCU を減らします。
- B. オンデマンドキャパシティを使用するように DynamoDB テーブルを変更します。
- C. テーブルの Dynamo DB Auto Scaling を有効にします。
- D. 毎日 4 時間のピーク負荷をカバーするのに十分な 1 年間のリザーブドキャパシティを購入します。
■ 問題文の要件の概要
- 毎日決まった時間に4時間だけトラフィックが増える（ピークが予測可能）
- ピーク時間以外はトラフィックが少ない
- DynamoDBを使っており、現在は固定のプロビジョンドキャパシティ
- コスト削減したい
- ITの運用負荷を減らしたい（手動変更は避けたい）
✅ 正解の選択肢と解説
- 正解：C. テーブルの DynamoDB Auto Scaling を有効にします。
解説：
- DynamoDB Auto Scaling を使えば、CloudWatch メトリクスに基づいて RCU/WCU を自動でスケール。
- ピーク時にはスループットを上げ、アイドル時には下げることで、無駄なコストを防ぐ。
- 完全にマネージドで手動運用不要のため、ITスタッフの負担も減らせる。
- プロビジョンドモードを維持しつつも、オンデマンドよりも低コストでコントロール可能。
❌ 不正解の選択肢の理由
A. プロビジョニングされた RCU と WCU を減らします。
- ピーク時に処理能力が不足してスロットリングが発生し、売上機会を逃す。
- 日次で変更が必要になり、IT運用の手間が増える。
B. オンデマンドキャパシティを使用するように DynamoDB テーブルを変更します。
- リクエストごとの課金が高く、トラフィックが予測できる場合は非効率。
- ピークが毎日起きるようなケースでは、プロビジョンド+Auto Scalingの方が安く済む。
D. 1 年間のリザーブドキャパシティを購入します。
- 1日4時間しか使わないのに、24時間365日分のキャパシティを予約するのはコスト非効率。
- 柔軟性がなく、需要変動にも対応しづらい。
■ SAP試験で押さえておくべきポイント
- DynamoDB Auto Scalingは、プロビジョンドモードでスループットを自動調整する仕組み。
- ピーク時間が予測可能かつ短時間であれば、Auto Scalingによりコスト最適化が可能。
- オンデマンドモードはトラフィックが読めないケース向け。
- リザーブドキャパシティは長時間・常に一定トラフィックがある場合に向いており、本件のような4時間ピークには不向き。
- 手動変更は運用負荷が高く、可能な限り避けるのが設計の基本。
次の問題もあればお送りください。引き続き整理してお伝えします。
以下は問題2の出力結果です。
■ 問題文（編集せずに出力）
企業は、e コマースウェブサイト用の災害復旧 (DR) ソリューションを構築する必要があります。このウェブアプリケーションは、t3.large Amazon EC2 インスタンスのフリートでホストされ、Amazon RDS for MySQL DB インスタンスを使用しています。EC2 インスタンスは、複数のアベイラビリティーゾーンに配置される Auto Scaling グループ内にあります。
災害時には、RPO 30 秒、RTO 10 分でセカンダリ環境にフェイルオーバーする必要があります。
これらの要件を最もコスト効率よく満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. コードとしてのインフラストラクチャ (IaC) を使用して、DR リージョンに新しいインフラストラクチャをプロビジョニングします。DB インスタンスのクロスリージョンリードレプリカを作成します。AWS Backup でバックアップ計画を設定し、EC2 インスタンスと DB インスタンスのクロスリージョンバックアップを作成します。EC2 インスタンスと DB インスタンスを 30 秒ごとに DR リージョンにバックアップする cron 式を作成します。最新の EC2 バックアップから EC2 インスタンスを復元します。Amazon Route 53 位置情報ルーティングポリシーを使用して、災害時に DR リージョンに自動的にフェイルオーバーします。
- B. コードとしてのインフラストラクチャ (IaC) を使用して、DR リージョンに新しいインフラストラクチャをプロビジョニングします。DB インスタンスのクロスリージョンリードレプリカを作成します。AWS Elastic Disaster Recovery を設定して、EC2 インスタンスを DR リージョンに継続的にレプリケートします。EC2 インスタンスを DR リージョンの最小キャパシティで実行します。Amazon Route 53 フェイルオーバールーティングポリシーを使用して、災害時に DR リージョンに自動的にフェイルオーバーします。Auto Scaling グループの希望するキャパシティを増やします。
- C. AWS Backup でバックアップ計画を設定し、EC2 インスタンスと DB インスタンスのクロスリージョンバックアップを作成します。EC2 インスタンスと DB インスタンスを 30 秒ごとに DR リージョンにバックアップする cron 式を作成します。コードとしてのインフラストラクチャ (IaC) を使用して、DR リージョンに新しいインフラストラクチャをプロビジョニングします。バックアップされたデータを新しいインスタンスに手動で復元します。Amazon Route 53 シンプルルーティングポリシーを使用して、災害時に DR リージョンに自動的にフェイルオーバーします。
- D. コードとしてのインフラストラクチャ (IaC) を使用して、DR リージョンに新しいインフラストラクチャをプロビジョニングします。Amazon Aurora Global Database を作成します。AWS Elastic Disaster Recovery を設定して、EC2 インスタンスを DR リージョンに継続的にレプリケートします。EC2 インスタンスの Auto Scaling グループを DR リージョンのフルキャパシティで実行します。Amazon Route 53 フェイルオーバールーティングポリシーを使用して、災害時に DR リージョンに自動的にフェイルオーバーします。
■ 問題文の要件の概要
- 対象：EC2 + RDS for MySQL によるeコマースアプリケーション
- DR要件：RPO 30秒以内、RTO 10分以内
- 低コストでのDR設計が求められている
- フェイルオーバー自動化も含む
✅ 正解の選択肢と解説
- 正解：B
理由：
- RDSのクロスリージョンリードレプリカ：MySQLのトランザクションをほぼリアルタイムでDRリージョンに反映可能（RPOを満たす）
- AWS Elastic Disaster Recovery (DRS)：ブロックレベルでEC2の継続レプリケーション → 数分で起動可能（RTOを満たす）
- DR側の最小キャパシティ稼働 + Auto Scaling 拡張：コスト効率と復旧スピードを両立
- Route 53 フェイルオーバーポリシー：ヘルスチェック失敗で自動DNS切替（自動フェイルオーバーを実現）
❌ 不正解の選択肢の理由
A.
- AWS Backupでは30秒ごとのバックアップ不可（最小1時間間隔） → RPO 30秒を満たせない
- Route 53 位置情報ポリシーはヘルスチェックによる自動切替に非対応 → RTOを満たせない
C.
- バックアップからの手動リストアは時間がかかる → RTO 10分以内は困難
- Route 53 シンプルポリシーは自動切替に非対応
D.
- Aurora Global DatabaseはRDS for MySQLとは互換性がなく、移行コスト/期間が必要
- DR側をフルキャパシティで常時稼働は高コスト → 「コスト効率的に」という要件に反する
■ SAP試験で押さえておくべきポイント
- Elastic Disaster Recovery (DRS) は、低コストかつ高速なDRソリューション。秒単位のRPOと10分未満のRTOに最適
- クロスリージョンリードレプリカ：MySQLやPostgreSQLのRDSにおいて、高速フェイルオーバーとデータ整合性確保に有効
- Route 53 フェイルオーバーポリシー：DR自動化の基本。必ず「ヘルスチェックと組み合わせ」で自動切替
- AWS BackupとDRは別物：Backupはアーカイブ用途向けで、RTO/RPO要件が厳しい災害復旧には不向き
- Aurora Global DBはAurora専用。RDS for MySQLとの違いに注意
- DR環境では“最小キャパシティ待機”と“スケールアップ”戦略がコスト最適化の鍵
次の問題もあれば続けて整理しますので、お送りください。
以下は問題3の出力結果です。
■ 問題文（編集せずに出力）
ある企業は AWS クラウドでアプリケーションを実行しています。コアのビジネスロジックは、Auto Scaling グループ内の一連の Amazon EC2 インスタンス上で実行されています。Application Load Balancer (ALB) が EC2 インスタンスにトラフィックを分散します。Amazon Route 53 のレコード api.example.com は ALB を指しています。
会社の開発チームは、ビジネスロジックを大幅に更新しました。同社には、変更がデプロイされたとき、テスト期間中に新しいロジックを受け取れるのはお客様の 10% だけというルールがあります。お客様はテスト期間中に同じバージョンのビジネスロジックを使用する必要があります。
これらの要件を満たすために、企業は更新プログラムをどのようにデプロイする必要がありますか?
■ 選択肢（編集せずに出力）
- A. 2 番目の ALB を作成し、新しいロジックを新しい Auto Scaling グループ内の一連の EC2 インスタンスにデプロイします。EC2 インスタンスにトラフィックを分散するように ALB を構成します。加重ルーティングを使用するように Route 53 レコードを更新し、そのレコードが両方の ALB を指すようにします。
- B. ALB が参照する 2 つ目のターゲットグループを作成し、この新しいターゲットグループ内の EC2 インスタンスに新しいロジックをデプロイします。加重ターゲットグループを使用するように、ALB リスナールールを更新します。ALB のターゲットグループのスティッキーネスを設定します。
- C. Auto Scaling グループの新しい起動設定を作成します。AutoScalingRollingUpdate ポリシーを使用するように起動設定を指定し、MaxBatchSize オプションを 10 に設定します。Auto Scaling グループの起動設定を置き換えます。変更をデプロイします。
- D. ALB によって参照される 2 番目の Auto Scaling グループを作成します。この新しい Auto Scaling グループ内の一連の EC2 インスタンスに新しいロジックをデプロイします。ALB ルーティングアルゴリズムを最小未処理リクエスト (LOR) に変更します。ALB セッションのスティッキーネスを構成します。
■ 問題文の要件の概要
- テスト期間中は全ユーザーのうち10%だけが新ロジックを受け取る
- テスト期間中に同じユーザーが常に同じバージョンのロジックを使用する必要がある
- トラフィック制御とユーザーごとの一貫性（スティッキーネス）が求められる
✅ 正解の選択肢と解説
- 正解：B
解説：
- Application Load Balancer（ALB） の**複数ターゲットグループ + 重み付けルール（Weighted Target Groups）**により、トラフィックの割合（例：90%旧、10%新）を精密に制御可能
- **スティッキーネス（Stickiness）**設定を有効にすると、ALBが発行するクッキーにより同一ユーザーを常に同じターゲットグループにルーティング可能 → バージョンの一貫性を保持
- DNS（Route 53）側の設定を変更せずに、ALBレイヤーで完結するためシンプルかつ信頼性が高い
❌ 不正解の選択肢の理由
A.
- Route 53の加重ルーティングはDNSレベルの制御であり、ユーザーのセッション一貫性（スティッキーネス）を維持できない
- DNSキャッシュのばらつきにより、正確な10%の制御ができず、テスト要件を満たせない
C.
- Auto Scalingのローリング更新はインスタンス単位の更新制御しかできず、トラフィックの割合やユーザーの一貫性を制御できない
- 結果として、ユーザーごとに受け取るバージョンが混在するリスクあり
D.
- LOR（Least Outstanding Requests）ルーティングは負荷分散最適化が目的で、割合制御やユーザー一貫性には不向き
- ターゲットグループを跨いだスティッキーネスは無効なため、ユーザーが旧・新ロジックを跨ぐ可能性あり
■ SAP試験で押さえておくべきポイント
- ALBの加重ターゲットグループ機能は、A/Bテストやカナリアリリースに有効。トラフィックを精密に割合分岐可能
- ターゲットグループのスティッキーネスを設定すると、ユーザーを特定のターゲットグループに固定できる（Cookieベース）
- DNSベース（Route 53）での加重ルーティングはキャッシュの影響が強く、短期的なA/Bテストやユーザー固定には不適
- Auto Scalingの更新戦略（ローリング、ブルーグリーン等）はインスタンスの置き換えに効果的だが、ユーザーセッション制御には不十分
- LORやRR（ラウンドロビン）などのALBルーティングアルゴリズムはトラフィック最適化向けで、割合制御やスティッキーネスとは別物
次の問題もあれば続けてどうぞ。どんどん整理していきましょう。
以下は問題4の出力結果です。
■ 問題文（編集せずに出力）
ある企業は、AWS クラウドでコンテナ化されたアプリケーションを実行しています。このアプリケーションは、Amazon Elastic Container Service (Amazon ECS) を使用して、一連の Amazon EC2 インスタンス上で実行されています。EC2 インスタンスは Auto Scaling グループで実行されています。
同社は、Amazon Elastic Container Registry (Amazon ECR) を使用してコンテナイメージを保存しています。新しいイメージバージョンがアップロードされると、新しいイメージバージョンは一意のタグを受け取ります。
同社は、新しいイメージバージョンに一般的な脆弱性や危険性がないか検査するソリューションを必要としています。このソリューションでは、重大度が「クリティカル (Critical)」または「高 (High)」であることが発見された新しいイメージタグを自動的に削除する必要があります。また、このような削除が発生した場合、開発チームに通知する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. リポジトリでプッシュ時のスキャンを構成します。Amazon EventBridge を使用して、重大度が「Critical」または「High」の所見があるイメージのスキャンが完了したときに、AWS Step Functions ステートマシンを呼び出します。Step Functions ステートマシンを使用して、これらのイメージのイメージタグを削除し、Amazon Simple Notification Service (Amazon SNS) を通じて開発チームに通知します。
- B. リポジトリでプッシュ時のスキャンを構成します。スキャン結果が Amazon Simple Queue Service (Amazon SQS) キューにプッシュされるように設定します。新しいメッセージが SQS キューに追加されたら、AWS Lambda 関数を呼び出します。Lambda 関数を使用して、重大度が「Critical」または「High」の所見があるイメージのイメージタグを削除します。Amazon Simple Email Service (Amazon SES) を使用して開発チームに通知します。
- C. AWS Lambda 関数をスケジュールして、1 時間ごとに手動イメージスキャンを開始します。スキャン完了時に別の Lambda 関数を呼び出すように Amazon EventBridge を構成します。2 つ目の Lambda 関数を使用して、重大度が「Critical」または「High」の所見があるイメージのイメージタグを削除します。Amazon Simple Notification Service (Amazon SNS) を使用して開発チームに通知します。
- D. リポジトリで定期的なイメージスキャンを構成します。スキャン結果が Amazon Simple Queue Service (Amazon SQS) キューに追加されるように設定します。新しいメッセージが SQS キューに追加されたら、AWS Step Functions ステートマシンを起動します。Step Functions ステートマシンを使用して、重大度が「Critical」または「High」の所見があるイメージのイメージタグを削除します。Amazon Simple Email Service (Amazon SES) を使用して開発チームに通知します。
■ 問題文の要件の概要
- ECRに新しいイメージがプッシュされたときに自動スキャンしたい
- 「Critical」または「High」の脆弱性があるタグは自動削除
- 削除が発生した場合には開発チームに即通知
✅ 正解の選択肢と解説
- 正解：A
解説：
- Amazon ECRのプッシュ時スキャン機能により、イメージアップロード直後に脆弱性スキャンを自動で実行
- スキャン完了イベントは Amazon EventBridge によってトリガーされる
- イベントトリガーを Step Functions ステートマシンに連携し、以下の一連の処理を実行：
- 該当イメージタグの削除
- SNS通知による開発チームへの即時アラート
この構成により、自動化・即時性・通知性すべての要件を満たす。
❌ 不正解の選択肢の理由
B.
- SQSはポーリングベースで、リアルタイム性に欠ける
- SESは通知に使えるが、メール以外の連携が難しく、チーム通知用途にはSNSの方が適切
C.
- 1時間おきのスケジュールスキャンではリアルタイム性がなく、重大脆弱性を長時間放置するリスク
- プッシュ直後の検知ができないためセキュリティ要件を満たさない
D.
- 定期スキャンは最大24時間遅延する可能性あり
- SQS + SES連携では通知と削除もリアルタイムにならず、運用面で不適
■ SAP試験で押さえておくべきポイント
- Amazon ECRのプッシュ時スキャンを使うと、イメージアップロード時点で即座に脆弱性チェックが可能
- EventBridgeはECRスキャン完了イベントに対応し、自動的なリアクションを設計できる
- Step Functionsはタグ削除や通知処理など、複数ステップをワークフロー化できるのでセキュリティ自動化に最適
- SNSは開発チームへの通知手段として、SlackやEmailへの連携が柔軟
- SQSや定期スキャン方式では遅延が大きく、セキュリティリスクに対応しきれないことがあるため、即時性が求められる問題では不向き
次の問題があれば続けてどうぞ！SAP対策、引き続きしっかり整理していきましょう。
以下は問題5の出力結果です。
■ 問題文（編集せずに出力）
ある企業が、お客様のトランザクションデータベースをオンプレミスから AWS に移行する必要があります。データベースは、Linux サーバー上で動作する Oracle DB インスタンス上に存在します。新しいセキュリティ要件によると、同社はデータベースのパスワードを毎年更新する必要があります。
運用上のオーバーヘッドを最小限に抑えてこれらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. AWS Schema Conversion Tool (AWS SCT) を使用して、データベースを Amazon DynamoDB に変換します。AWS Systems Manager Parameter Store にパスワードを保存します。1 年ごとのパスワードローテーションのために AWS Lambda 関数を呼び出す Amazon CloudWatch アラームを作成します。
- B. データベースを Amazon RDS for Oracle に移行します。パスワードを AWS Secrets Manager に保存します。自動ローテーションを有効にします。年間ローテーションスケジュールを設定します。
- C. データベースを Amazon EC2 インスタンスに移行します。AWS Systems Manager Parameter Store を使用して、AWS Lambda 関数を使用して接続文字列を維持し、年間スケジュールでローテーションします。
- D. AWS Schema Conversion Tool (AWS SCT) を使用して、データベースを Amazon Neptune に移行します。1 年ごとのパスワードローテーションのために AWS Lambda 関数を呼び出す Amazon CloudWatch アラームを作成します。
■ 問題文の要件の概要
- Oracle DB を AWS に移行する必要がある
- セキュリティ要件として、年1回のパスワードローテーションが必要
- 運用の手間（オーバーヘッド）は最小限にしたい
✅ 正解の選択肢と解説
- 正解：B
解説：
- Amazon RDS for Oracle はマネージドな Oracle 環境を提供し、パッチ適用・バックアップ・監視などの運用を AWS が代行
- AWS Secrets Manager は RDS と連携し、パスワードの自動ローテーションが可能（年間などスケジュール設定も可能）
- この組み合わせにより、マネージド DB + 自動化された認証情報管理で、運用オーバーヘッドを最小限に抑えられる
❌ 不正解の選択肢の理由
A.
- Oracle → DynamoDB は構造が異なり、ACIDやSQL互換性を失う
- パスワード自動ローテーション機能がない Parameter Store では、手動で Lambda/CloudWatch を維持する必要があり、運用負荷が大きい
C.
- EC2 上で Oracle を運用すると、パッチ・バックアップ・可用性構成を自分で対応する必要がある
- Parameter Store にも自動ローテーション機能はなく、Lambda などでスクリプトの保守が必要
D.
- Oracle → Amazon Neptune への移行は構造やクエリ言語（Gremlin/SPARQL）非互換
- パスワードローテーションも Lambda + CloudWatch アラームによる手動構築が必要
■ SAP試験で押さえておくべきポイント
- Secrets Manager は認証情報の安全な保管と、自動ローテーション機能を提供する
- RDS と連携することで、パスワード変更や適用まで完全自動化でき、Lambda などのカスタム実装が不要
- マネージドサービスの導入により、運用の責任共有モデルにおける「AWS側の負担」を活用するのがベストプラクティス
- EC2 自己管理 or 手動ローテーション系設計は「運用オーバーヘッド最小化」の要件に反する
- RDS for Oracle + Secrets Managerの組み合わせは、SAP試験で頻出の設計パターン。自動化・運用最小化・セキュリティ強化の観点で覚えておくべき
続けて別の問題があれば、どうぞ貼り付けてください。分析を続けます。
以下は問題6の出力結果です。
■ 問題文（編集せずに出力）
ある企業がオンプレミスの SFTP サイトを AWS に移行する必要があります。SFTP サイトは現在、Linux VM 上で実行されています。アップロードされたファイルは、NFS 共有を通じてダウンストリームアプリケーションが利用できるようになっています。
AWS への移行の一環として、ソリューションアーキテクトは高可用性を実装する必要があります。ソリューションは、ベンダーが許可できる静的パブリック IP アドレスのセットを外部ベンダーに提供する必要があります。同社は、オンプレミスのデータセンターと VPC の間に AWS Direct Connect 接続を設定しました。
運用上のオーバーヘッドを最小限に抑えながら、これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. AWS Transfer Family サーバーを作成します。Transfer Family サーバー用にインターネットに接続された VPC エンドポイントを構成します。各サブネットの Elastic IP アドレスを指定します。複数のアベイラビリティーゾーンにデプロイされる Amazon Elastic File System (Amazon EFS) ファイルシステムにファイルを配置するように Transfer Family サーバーを構成します。既存の NFS 共有にアクセスするダウンストリームアプリケーションの構成を変更し、代わりに EFS エンドポイントをマウントします。
- B. AWS Transfer Family サーバーを作成します。Transfer Family サーバーのパブリックにアクセス可能なエンドポイントを構成します。複数のアベイラビリティーゾーンにデプロイされる Amazon Elastic File System (Amazon EFS) ファイルシステムにファイルを配置するように Transfer Family サーバーを構成します。既存の NFS 共有にアクセスするダウンストリームアプリケーションの構成を変更し、代わりに EFS エンドポイントをマウントします。
- C. AWS Application Migration Service を使用して、既存の Linux VM を Amazon EC2 インスタンスに移行します。EC2 インスタンスに Elastic IP アドレスを割り当てます。Amazon Elastic File System (Amazon EFS) ファイルシステムを EC2 インスタンスにマウントします。EFS ファイルシステムにファイルを配置するように SFTP サーバーを構成します。既存の NFS 共有にアクセスするダウンストリームアプリケーションの構成を変更し、代わりに EFS エンドポイントをマウントします。
- D. AWS Application Migration Service を使用して、既存の Linux VM を AWS Transfer Family サーバーに移行します。Transfer Family サーバーのパブリックにアクセス可能なエンドポイントを構成します。複数のアベイラビリティーゾーンにデプロイされる Amazon FSx for Lustre ファイルシステムにファイルを配置するように Transfer Family サーバーを構成します。既存の NFS 共有にアクセスするダウンストリームアプリケーションの構成を変更し、代わりに FSx for Lustre エンドポイントをマウントします。
■ 問題文の要件の概要
- オンプレ SFTP を AWS に移行する
- アップロードファイルは NFS で後段システムに提供される
- 高可用性が必要
- 固定（静的）パブリック IP アドレスの提供が必要
- 運用オーバーヘッドを最小限にしたい
- Direct Connect 接続がある
✅ 正解の選択肢と解説
- 正解：A
解説：
- AWS Transfer Family + VPC エンドポイント型：Elastic IP を割り当て可能 → 静的パブリック IP 要件を満たす
- Amazon EFS：NFS 互換であり、ダウンストリームアプリが最小変更で対応可能
- 両サービスはマネージドサービスのため、可用性・スケーラビリティ・パッチ管理を自動で実行
- Transfer Family はマルチ AZ にまたがって冗長化されるため、高可用性の要件を満たす
- Direct Connect を活用する構成にも適合する
❌ 不正解の選択肢の理由
B.
- Transfer Family の 「パブリックエンドポイント」には Elastic IP を割り当てられず、動的 IP となる → 静的 IP 提供の要件を満たさない
C.
- EC2 に Elastic IP を割り当てても 単一障害点（SPOF）であり、高可用性要件を満たさない
- パッチ適用や可用性設計をユーザー側で対応する必要があり、運用オーバーヘッドが増大
D.
- Application Migration Service から Transfer Family への「直接移行」は 不可能
- また FSx for Lustre は NFS 非互換のため、既存アプリが利用できない
🎯 SAP試験で押さえておくべきポイント
- **Transfer Family のエンドポイント種別の違い（Elastic IP 可否）**を理解する：
- VPC エンドポイント：Elastic IP 割り当て可（静的 IP 提供に対応）
- パブリックエンドポイント：Elastic IP 割り当て不可（動的 IP）
- Amazon EFS は NFS 互換で高可用性かつマネージドな共有ストレージであり、移行に最適
- Application Migration Service の役割は EC2 への VM リフト＆シフトであり、マネージドサービス（例：Transfer Family）への移行ではない
- 高可用性を求められるシステムでは、マネージドサービスを優先的に検討し、SPOF を回避する設計が基本
次の問題があれば、引き続きどうぞご送付ください。分析を続けます。
以下は、提供いただいた「問題7」に基づく整理・解説です。
■ 問題文
ある企業には 5 つの開発チームがあり、それぞれアプリケーションの開発とホスティングのために 5 つの AWS アカウントを作成しました。支出を追跡するために、開発チームは毎月各アカウントにログインし、AWS Billing and Cost Management コンソールから現在のコストを記録し、会社の財務チームに情報を提供します。
この会社には厳格なコンプライアンス要件があり、リソースが米国の AWS リージョンでのみ作成されるようにする必要があります。ただし、いくつかのリソースは他のリージョンで作成されています。
ソリューションアーキテクトは、財務チームがすべてのアカウントの支出を追跡し、統合できるソリューションを実装する必要があります。また、このソリューションは、米国内のリージョンでのみリソースを作成できるようにする必要があります。
最も運用効率の高い方法でこれらの要件を満たす手順の組み合わせを選択してください。(3 つ選択)
■ 選択肢
- A. 管理アカウントとして機能する新しいアカウントを作成します。財務チーム用の Amazon S3 バケットを作成します。AWS コストと使用状況レポートを使用して、月次レポートを作成し、財務チームの S3 バケットにデータを保存します。
- B. 管理アカウントとして機能する新しいアカウントを作成します。すべての機能を有効にして、AWS Organizations に組織をデプロイします。すべての既存アカウントを組織に招待します。各アカウントが招待を受け入れることを確認します。
- C. すべての開発チームを含む OU を作成します。米国内のリージョンでのみリソースの作成を許可する SCP を作成します。SCP を OU に適用します。
- D. すべての開発チームを含む OU を作成します。米国外のリージョンでのリソースの作成を拒否する SCP を作成します。SCP を OU に適用します。
- E. 管理アカウントに IAM ロールを作成します。Billing and Cost Management コンソールを表示する権限を含むポリシーをアタッチします。財務チームのユーザーがこのロールを引き受けることを許可します。AWS Cost Explorer と Billing and Cost Management コンソールを使用して、コストを分析します。
- F. 各 AWS アカウントに IAM ロールを作成します。Billing and Cost Management コンソールを表示する権限を含むポリシーをアタッチします。財務チームのユーザーがそのロールを引き受けることを許可します。
■ 問題文の要件の概要
- 5アカウントの支出を統合的に分析したい（手動ログイン不要に）
- 米国リージョン以外のリソース作成を禁止したい（コンプライアンス遵守）
- 運用効率が高い方法を選びたい
✅ 正解の選択肢と解説
- B. AWS Organizations を構成し、すべてのアカウントを一元管理可能にします。これにより一括請求や SCP の適用が可能になります。
- D. OU を作成し、SCP によって「us-」以外のリージョンでのリソース作成を明示的に拒否することでコンプライアンスを担保できます。
- E. 管理アカウントに IAM ロールを用意し、Cost Explorer で全アカウントの支出を可視化でき、手動での個別ログインを不要にします。
❌ 不正解の選択肢の理由
- A: AWS Cost and Usage Report（CUR）での月次出力では即時性がなく、またSCPのような制御も不可能なため要件を満たさない。
- C: SCP は基本的に明示的な拒否（Deny）に有効であり、「許可（Allow）」だけで制御しようとすると
FullAWSAccessポリシーとの干渉が起きて不完全な制御になる。 - F: 各アカウントにロールを作ると管理が煩雑になり、財務チームは毎回スイッチロールを繰り返すことになり運用効率が悪い。
🎯 SAP試験で押さえておくべきポイント
- Organizations + SCP + IAM ロールの組み合わせは頻出パターン。コスト統合とガバナンスの代表設計。
- SCPは明示的拒否(Deny)が基本。許可(Allow)のみでは不完全なアクセス制御となる。
- CURは詳細レポートだが即時性・統合性に欠けるため、運用効率の観点では不適。
- マルチアカウント戦略では「一括請求 (Consolidated Billing)」と「サービス制御」を分離して考えると整理しやすい。
次の問題もあればお送りください。引き続き対応いたします。
