了解です。いただいた問題を指定の形式で整理しました。
問題文（原文）
東海岸に本社を置く北米の企業が、us-east-1 リージョンの Amazon EC2 で実行される新しいウェブアプリケーションをデプロイしています。このアプリケーションは、ユーザーの需要を満たすために動的に拡張し、回復力を維持する必要があります。さらに、アプリケーションには、us-west-1 リージョンを使用したアクティブ/パッシブ構成のディザスタリカバリ機能が必要です。us-east-1 リージョンで VPC を作成した後、ソリューションアーキテクトはどの手順を実行する必要がありますか？
選択肢（原文）
A：us-east-1 リージョンの VPC に複数のアベイラビリティーゾーン (AZ) にまたがる Application Load Balancer (ALB) をデプロイします。ALB が提供する Auto Scaling グループの一部として、EC2 インスタンスを複数の AZ にデプロイします。同じソリューションを us-west-1 リージョンにデプロイします。フェイルオーバールーティングポリシーとヘルスチェックを有効にして Amazon Route 53 レコードセットを作成し、両方のリージョンで高可用性を提供します。
B：複数のアベイラビリティーゾーン (AZ) にまたがる Application Load Balancer (ALB) を us-east-1 リージョンの VPC にデプロイします。ALB が提供する Auto Scaling グループの一部として、EC2 インスタンスを複数の AZ にデプロイします。同じソリューションを us-west-1 リージョンにデプロイします。各リージョンに、リージョン内の ALB を指す個別の Amazon Route 53 レコードを作成します。Route 53 ヘルスチェックを使用して、両方のリージョンで高可用性を提供します。
C：us-west-1 リージョンで VPC を作成します。リージョン間 VPC ピアリングを使用して、両方の VPC を接続します。us-east-1 リージョンの VPC に複数のアベイラビリティーゾーン (AZ) にまたがる Application Load Balancer (ALB) をデプロイします。両方の VPC にまたがる Auto Scaling グループの一部として、各リージョンの複数の AZ にまたがって EC2 インスタンスをデプロイし、ALB によってサービスを提供します。
D：us-west-1 リージョンに VPC を作成します。リージョン間 VPC ピアリングを使用して、両方の VPC を接続します。両方の VPC にまたがる Application Load Balancer (ALB) をデプロイします。ALB がサービスを提供する各 VPC に Auto Scaling グループの一部として、EC2 インスタンスを複数のアベイラビリティーゾーンにデプロイします。 ALB を指す Amazon Route 53 レコードを作成します。
問題文の要件の概要
- 動的スケーリング：負荷に応じて自動拡張（EC2 Auto Scaling + ALB、Multi-AZ）。
- 回復力：リージョン内の冗長化（Multi-AZ）に加えて、us-west-1を用いたアクティブ/パッシブDR。
- DNSフェイルオーバー：プライマリ（us-east-1）障害時のみセカンダリ（us-west-1）を有効化するルーティング。
正解の選択肢と解説
正解：A
- 各リージョンで ALB + Multi-AZのAuto Scaling を構成し、リージョン内の可用性を確保。
- Route 53 フェイルオーバールーティングポリシーとヘルスチェックで、プライマリ(us-east-1)が正常な間はそちらのみ応答し、異常時にセカンダリ(us-west-1)へ自動切替。
- 要件の「アクティブ/パッシブ」に合致（通常はeastのみアクティブ）。
不正解の選択肢の理由
- B：各リージョンに個別レコード＋ヘルスチェックは一見正しそうだが、明示的な“フェイルオーバー”ポリシー指定がなく、構成次第でアクティブ/アクティブや不定な挙動になりうる。要件は「アクティブ/パッシブ」なのでフェイルオーバーポリシーを使うAが適切。
- C：ALBもASGもリージョンをまたいで展開できない。VPCピアリングをしても、単一のALBで他リージョンのターゲットを直接配下に置くことは不可。ASGもクロスリージョン不可。
- D：ALBを“両VPCにまたがって”配置はできない（ALBはリージョン内・VPC内のリソースをターゲット）。VPCピアリングの有無に関係なく誤り。
SAP試験で押さえておくべきポイント
- DRパターンの用語
- アクティブ/パッシブ＝Route 53のフェイルオーバールーティング＋ヘルスチェック。
- アクティブ/アクティブ＝加重/レイテンシールーティング等で両方に振る。
- ALB/ASGのスコープ：リージョンをまたげない・VPCをまたげないのが基本。リージョン間冗長は各リージョンで完結構築＋DNS制御が王道。
- Multi-AZはベースライン：ALBはMulti-AZ、ASGは複数AZサブネットを指定するのが基本設計。
ほかの問題も同じフォーマットで続けます。必要なら、各設計のアーキ図のポイントもまとめますよ。
了解です。指定の形式で整理します。
問題文（そのまま）
ある企業は、オンプレミス型の SaaS（Software-as-a-Service）ソリューションを運営しており、毎日複数のファイルを取り込んでいます。同社は、ファイル転送を容易にするために、顧客に複数のパブリック SFTP エンドポイントを提供しています。顧客は、SFTP エンドポイントの IP アドレスを、アウトバウンドトラフィックのファイアウォール許可リストに追加しています。SFTP エンドポイントの IP アドレスの変更は許可されていません。同社は、SaaS ソリューションを AWS に移行し、ファイル転送サービスの運用オーバーヘッドを減少させたいと考えています。これらの要件を満たすソリューションを選択してください。
選択肢（そのまま）
A：顧客が所有する IP アドレスのブロックを含むサブネットを VPC に追加します。アドレスプールから Elastic IP アドレスを作成し、Application Load Balancer (ALB) に割り当てます。ALB の背後にある Auto Scaling グループで、FTP サービスをホストする EC2 インスタンスを起動します。Amazon Elastic Block Store (Amazon EBS) ボリュームにファイルを保存します。
B：顧客が所有する IP アドレスのブロックを会社の AWS アカウントに登録します。アドレスプールから Elastic IP アドレスを作成し、AWS Transfer for SFTP のエンドポイントに割り当てます。AWS Transfer を使用して、Amazon S3 にファイルを保存します。
C：顧客が所有する IP アドレスのブロックを会社の AWS アカウントに登録します。アドレスプールから Elastic IP アドレスを作成し、Amazon S3 VPC エンドポイントに割り当てます。S3 バケットで SFTP サポートを有効にします。
D：顧客が所有する IP アドレスのブロックを Amazon Route 53 に登録します。Route 53 に、 Network Load Balancer (NLB) を指すエイリアスレコードを作成します。NLB の背後にある Auto Scaling グループで FTP サービスをホストする EC2 インスタンスを起動します。Amazon S3 にファイルを保存します。
要件の概要
- 既存顧客はSFTP宛先の固定パブリックIPを許可リストに登録済み → IPを変えられない。
- 運用オーバーヘッドの削減（サーバ管理やスケーリングを極力マネージド化）。
- SaaSをAWSへ移行しつつ、ファイルはクラウド側に安全に保管。
正解の選択肢と解説
正解：B
- AWS Transfer Family (Transfer for SFTP) はフルマネージドでSFTPを提供。サーバ運用を省力化。
- Bring Your Own IP（BYOIP）/ Elastic IP をTransferサーバのエンドポイントに割り当てでき、既存顧客の許可リストに登録済みの固定IPを維持可能。
- バックエンドの保存先を Amazon S3 にすることで耐久性・コスト・スケーラビリティを最適化。運用負荷も最小。
不正解の選択肢の理由
- A：ALBに静的IPを割り当てられない（ALBは固定IP非対応）。さらにFTPは要件のSFTPと異なる（暗号化要件未満）。EC2での運用はオーバーヘッド増。
- C：S3はSFTPをネイティブサポートしていない。S3 VPCエンドポイントにElastic IPも割り当てられない。
- D：Route 53登録では送信元許可リストの固定IP要件を満たせない。NLBは固定IP（EIP）割当可だが、EC2でFTP運用は運用負荷が大きく、またFTPは要件のSFTPと不一致。
SAP試験で押さえるべきポイント
- Transfer Family（SFTP/FTPS/FTP）はS3/EFSと連携するマネージドファイル転送。オンプレSFTPの置き換え問題では第一候補。
- 取引先の許可リスト固定IP要件がある場合は、EIP割当やBYOIPをサポートするサービス（Transfer/NLBなど）で解決する。
- ALBは固定IP不可／NLBは固定IP可。ただしプロトコル要件（SFTP）と運用負荷も考慮する。
- S3はSFTPを直接提供しないため、SFTP→Transfer→S3のパスが定石。
次の問題もこのフォーマットで続けます。
了解です。この問題もフォーマットに沿って整理します。
問題文（そのまま）
ある会社が、人気のある一般向け e コマースウェブサイトを運営しています。同社のユーザーベースは、地方市場から全国市場へと急速に成長しています。ウェブサイトは、ウェブサーバーと MySQL データベースを備えたオンプレミスのデータセンターでホストされています。同社は、ワークロードを AWS に移行したいと考えています。ソリューションアーキテクトは、次のようなソリューションを作成する必要があります。
・セキュリティの向上
・信頼性の向上
・可用性の向上
・レイテンシーの低減
・メンテナンスの軽減
ソリューションアーキテクトがこれらの要件を満たすために実行する必要がある手順の組み合わせはどれですか？ (3 つ選択)
選択肢（そのまま）
A：データベースをマルチ AZ の Amazon Aurora MySQL DB クラスターに移行します。
B：Application Load Balancer の背後にある Auto Scaling グループのウェブサーバーに、2 つのアベイラビリティーゾーンで Amazon EC2 インスタンスを使用します。
C：Amazon S3 で静的なウェブサイトのコンテンツをホストします。 S3 Transfer Acceleration を使用して、ウェブページを提供する際のレイテンシーを減らします。AWS WAF を使用して、ウェブサイトのセキュリティを向上させます。
D：2 つのアベイラビリティーゾーンで Amazon EC2 インスタンスを使用して、高可用性の MySQL データベースクラスターをホストします。
E：Amazon S3 で静的なウェブサイトのコンテンツをホストします。Amazon CloudFront を使用して、ウェブページを提供する際のレイテンシーを減らします。AWS WAF を使用して、ウェブサイトのセキュリティを向上させます。
要件の概要
- セキュリティ向上 → AWS WAF、マネージドDB、CloudFront活用
- 信頼性 / 可用性向上 → マルチAZ構成（Aurora, Auto Scaling with ALB）
- レイテンシー低減 → CloudFrontによるグローバルキャッシュ配信
- メンテナンス軽減 → マネージドサービス活用（Aurora, S3, CloudFront）
正解の選択肢と解説
正解：A, B, E
- A：Aurora MySQL マルチAZ
→ 高可用性、フェイルオーバー内蔵、運用管理負担の軽減。オンプレMySQLより信頼性と保守性向上。 - B：ALB + Auto Scaling + マルチAZ EC2
→ 可用性・スケーラビリティを確保。トラフィックに応じた自動拡張で信頼性UP。 - E：S3 + CloudFront + WAF
→ 静的コンテンツをS3に、グローバル配信をCloudFrontで低レイテンシ提供。WAFでセキュリティ強化。
不正解の選択肢の理由
- C：S3 Transfer Accelerationは主にアップロードの高速化用途であり、Webページ配信の低レイテンシにはCloudFrontを使うべき → 不適。
- D：EC2上でMySQLクラスタを構築するとレプリケーション管理や運用負荷が高い。AuroraやRDSのマネージドDBを使う方が要件に適合。
SAP試験で押さえるべきポイント
- DB移行 → EC2に自前構築するのではなくAurora/RDS マルチAZで管理負担削減＋高可用性。
- Web層の可用性/スケーラビリティ → ALB + Auto Scaling + 複数AZが定石。
- 静的コンテンツ配信 → S3 + CloudFront。Transfer Accelerationは配信には使わない。
- セキュリティ → AWS WAF + CloudFrontでDDoS/攻撃防御。
👉 この問題は「移行時の定石構成を問う」パターンですね。EC2自前構築は減点要素、AuroraやCloudFront採用が試験的に優先されます。
次もこの形式でまとめますか？
了解しました。この問題もフォーマットに沿って整理します。
問題文（そのまま）
ある企業では、アプリケーションサービスをコンテナ化し、パブリック IP を持つ複数の Amazon EC2 インスタンスにデプロイしています。この EC2 インスタンスには、Apache Kafka クラスターがデプロイされています。PostgreSQL データベースは、Amazon RDS for PostgreSQL に移行されています。同社は、主力製品の新バージョンがリリースされると、そのプラットフォーム上での注文が大幅に増加すると予想しています。現在のアーキテクチャにどのような変更を加えれば、運用上のオーバーヘッドを削減し、製品のリリースをサポートできますか。
選択肢（そのまま）
A：Application Load Balancer の背後に EC2 Auto Scaling グループを作成します。DB インスタンスの追加のリードレプリカを作成します。Amazon Kinesis Data Streams を作成し、データストリームを使用するようにアプリケーションサービスを設定します。静的コンテンツを Amazon S3 から直接保存して提供します。
B：AWS Fargate を使用して Amazon Elastic Kubernetes Service (Amazon EKS) 上にアプリケーションをデプロイし、Application Load Balancer の背後で自動スケーリングを有効にします。DB インスタンスに追加のリードレプリカを作成します。Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスターを作成し、アプリケーションサービスがこのクラスターを使用するように設定します。Amazon CloudFront ディストリビューションの背後にある Amazon S3 に静的コンテンツを保存します。
C：Application Load Balancer の背後に EC2 Auto Scaling グループを作成します。DB インスタンスをマルチ AZ モードでデプロイし、ストレージの自動スケーリングを有効にします。Amazon Kinesis Data Streams を作成し、データストリームを使用するようにアプリケーションサービスを設定します。静的コンテンツを Amazon S3 から直接保存して提供します。
D：Application Load Balancer の背後にある EC2 インスタンス上に作成された Kubernetes クラスターにアプリケーションをデプロイします。DB インスタンスをマルチ AZ モードでデプロイし、ストレージの自動スケーリングを有効にします。Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスターを作成し、アプリケーションサービスがこのクラスターを使用するように設定します。Amazon CloudFront ディストリビューションの背後にある Amazon S3 に静的コンテンツを保存します。
要件の概要
- 運用オーバーヘッド削減：EC2自己管理をやめ、EKS + FargateやMSKなどマネージドサービスに移行。
- スケーラビリティ：注文増に対応するため、アプリ層とメッセージング層の自動スケーリングが必須。
- 高可用性：RDSリードレプリカやマルチAZ対応でデータベースの読み取り負荷分散。
- 配信効率：静的コンテンツはS3 + CloudFrontで最適化。
正解の選択肢と解説
正解：B
- AWS Fargate + EKS
→ コンテナ基盤をEC2管理から脱却し、Fargateでサーバーレスに実行。運用オーバーヘッドが大幅に削減。ALB + Auto Scalingでスケーラブル。 - RDS リードレプリカ
→ 読み取りトラフィックの分散。大量注文時の負荷を吸収可能。 - Amazon MSK
→ Kafkaを自己管理ではなくフルマネージドサービスに移行。スケーリングや障害復旧をAWSに任せられる。 - S3 + CloudFront
→ 静的コンテンツをグローバルにキャッシュ配信し、レイテンシーとコストを最適化。
不正解の選択肢の理由
- A：EC2 Auto Scalingは有効だが、KafkaをKinesisに置き換えるのは要件から外れる。さらに「S3から直接配信」ではCloudFrontによるキャッシュ最適化が欠ける。
- C：Kinesis採用で要件と異なる。DBをマルチAZ化は可用性対策だが、読み取りスケーリングには不足。CloudFront未利用で最適化不足。
- D：EKSをEC2にデプロイすると管理負担が増大し「運用オーバーヘッド削減」の要件に反する。
SAP試験で押さえるべきポイント
- 運用オーバーヘッド削減には「マネージドサービス」優先（EKS+Fargate, MSK, Aurora/RDS）。
- Kafkaワークロード → Amazon MSKが試験的に推奨解。
- 静的コンテンツ配信 → CloudFront必須。S3単体やS3 Transfer Accelerationでは不十分。
- スケーラビリティ戦略 → ALB + Auto Scalingはベストプラクティス。
- DBスケーリング → リードレプリカで読み取り負荷分散、マルチAZは耐障害性。
👉 この問題は「既存のEC2ベースKafkaやコンテナ環境をどうマネージド化するか」を問う典型パターンです。
次の問題も同じ形式で整理しましょうか？
了解しました！この問題もフォーマットに従って整理しました。
問題文（そのまま）
ある会社は、AWS CodePipeline と AWS CloudFormation を使用して AWS にアプリケーションをデプロイする方法を標準化しました。アプリケーションは TypeScript と Python を使用しています。同社は最近、Python スクリプトを使用してアプリケーションを AWS にデプロイする別の事業を買収しました。一方で、新しく買収した会社の開発者は、新しいドメイン固有の言語を学ぶ必要があり、ループなどの言語機能を利用できなくなるため、アプリケーションを CloudFormation に移行することに躊躇しています。開発者の懸念を解消しつつ、買収したアプリケーションを迅速にデプロイの標準化に近づける最適な方法を選択してください。
選択肢（そのまま）
A：AWS CodeBuild 内のサードパーティ製のリソースプロビジョニングエンジンを使用して、既存企業と買収した企業のデプロイプロセスを標準化します。CodePipeline を使用して CodeBuild ジョブを調整します。
B：CloudFormation テンプレートを作成し、Python スクリプトの一部をインスタンスユーザーデータとして再利用します。AWS Cloud Development Kit (AWS CDK) を使用して、これらのテンプレートを使用してアプリケーションをデプロイします。AWS CDK を CodePipeline に組み込み、これらのテンプレートを使用してアプリケーションを AWS にデプロイします。
C：TypeScript や Python を使用して AWS リソースを定義します。AWS Cloud Development Kit (AWS CDK) を使用して開発者のコードから CloudFormation テンプレートを作成し、AWS CDK を使用して CloudFormation スタックを作成します。AWS CDK を CodePipeline の CodeBuild ジョブとして組み込みます。
D：AWS OpsWorks で標準化します。OpsWorks を CodePipeline と統合します。開発者に Chef レシピを作成してもらい、アプリケーションを AWS にデプロイします。
問題文の要件の概要
- 既存の会社：CodePipeline + CloudFormation によるデプロイを標準化済み。
- 買収した会社：Python スクリプトを利用してAWSリソースをデプロイしている。
- 課題：開発者はCloudFormationのDSL（ドメイン固有言語）を新たに学ぶことに抵抗がある。
- 要件：
- 開発者が 慣れた言語（Python, TypeScript） を継続利用できること。
- デプロイ方法を 既存の標準（CodePipeline + CloudFormation） に近づけること。
- 運用をシンプルにすること。
正解の選択肢と解説
正解：C
- AWS CDK (Cloud Development Kit) を使えば、Python や TypeScript でリソースを記述できる。
- CDK はコードから CloudFormation テンプレートを自動生成し、最終的には CloudFormation スタックを通してデプロイする。
- これにより、開発者はCloudFormationのDSLを学ばずに済み、ループや条件分岐といったプログラミング言語の表現力を活用可能。
- CodePipeline には CodeBuild ジョブとして CDK を統合でき、既存のパイプライン標準に組み込める。
不正解の選択肢の理由
- A：サードパーティ製のプロビジョニングツールを導入すると標準化から外れ、追加の管理オーバーヘッドが発生する。
- B：一部 Python スクリプトをユーザーデータに流用するだけではCloudFormationとの整合性が中途半端。完全な標準化や開発者の懸念解消には不十分。
- D：OpsWorks (Chef/Puppet) はレガシーであり、CodePipeline + CloudFormation の既存標準から外れる。今後推奨される方向性ではない。
SAP試験で押さえておくべきポイント
- AWS CDK の役割：プログラミング言語（TypeScript, Python, Java, C#など）からCloudFormationを生成。 → 開発者の習熟言語を活用可能。
- 最終的なデプロイは CloudFormation：企業標準に準拠しつつ、開発者の懸念（新しいDSLを覚える必要性）を回避。
- 試験の出題傾向：
- 「開発者がCloudFormationの学習に抵抗」→ CDKで解決
- 「標準化されたパイプライン」→ CodePipeline + CodeBuild統合
- 「OpsWorksやサードパーティ」は基本的に誤答選択肢。
👉 この問題は「開発者体験と組織標準のバランス」をCDKで解決する典型例です。
次も整理しますか？
はい！この問題もフォーマットに従って整理しました。
問題文（そのまま）
ソリューションアーキテクトは、ウェブサーバーによって開始されるユーザーのメタデータを更新するためのソリューションを構築しています。このソリューションは、30 秒以内に数百から数万のジョブに迅速に拡張する必要があります。ソリューションは非同期で、常に利用可能で、コストを最小限に抑える必要があります。これらの要件を満たすために、ソリューションアーキテクトはどの戦略を使用する必要がありますか？
選択肢（そのまま）
A：ユーザーのメタデータを更新する AWS SWF ワーカーを作成して、ウェブアプリケーションを更新し、すべてのジョブの新しいワークフローを開始します。
B：ユーザーのメタデータを更新する AWS Lambda 関数を作成します。Lambda 関数をトリガーする AWS Step Functions を作成します。ジョブごとに Step Functions を起動するようにウェブアプリケーションを更新します。
C：Amazon SQS キューを作成します。ワーカーを使用して AMI を作成し、キューを確認してユーザーのメタデータを更新します。新しい AMI で Amazon EC2 Auto Scaling グループを設定します。キューにジョブを送信するようにウェブアプリケーションを更新します。
D：ユーザーのメタデータを更新する AWS Lambda 関数を作成します。Amazon SQS キューを作成し、Lambda 関数のイベントソースとして設定します。キューにジョブを送信するようにウェブアプリケーションを更新します。
問題文の要件の概要
- 数百～数万ジョブを 30秒以内にスケーリング
- 処理は 非同期
- 常に利用可能
- コスト最小化
- バックエンドは「ユーザーのメタデータ更新」処理
正解の選択肢と解説
正解：D
- Amazon SQS + AWS Lambda を組み合わせると、ジョブを非同期にキューに投入し、Lambda が自動的にイベントソースとして処理するアーキテクチャが実現できる。
- Lambda は短時間で数万の並列実行にスケール可能であり、SQS がバッファとして機能するため、スパイク負荷も吸収可能。
- 従量課金で、アイドル時はコストがほぼゼロ。
- 非同期処理・高スケーラビリティ・低運用コストの全要件を満たす。
不正解の選択肢の理由
- A（SWF ワーカー）：SWF は複雑なワークフロー管理に使えるが、迅速なスケーリングやコスト最適化には不向き。レガシー傾向で試験的にも優先度が低い。
- B（Step Functions + Lambda）：Step Functions はオーケストレーションに適しているが、ジョブごとに起動するとオーバーヘッドが大きく、また要件の「非同期大量処理」には SQS 連携がより適切。
- C（SQS + EC2 Auto Scaling）：EC2ベースではスケールに時間がかかり、短時間で数万ジョブに対応できない。さらに常時稼働によるコストも高い。
SAP試験で押さえておくべきポイント
- 大量の短時間ジョブ処理 → Lambda + SQS の組み合わせがベストプラクティス。
- Step Functions はオーケストレーションや長時間処理フローに適するが、バースト処理には不向き。
- EC2 Auto Scaling は分単位でのスケーリングであり、秒単位の急激なスパイクには対応できない。
- コスト最適化：サーバーレス（Lambda, SQS）はアイドルコストがゼロに近いため試験上の最適解になりやすい。
👉 この問題は「サーバーレスによるバースト処理対応」を問う典型問題です。
次の問題（問題7以降）も整理しますか？
はい！この問題もフォーマットに従って整理しました。
問題文（そのまま）
ある会社が AWS への移行を計画しています。ソリューションアーキテクトは、AWS Application Discovery Service をフリート上で使用し、Oracle データウェアハウスと複数の PostgreSQL データベースがあることを発見しました。移行パターンの組み合わせで、ライセンスコストと運用上のオーバーヘッドを削減できるのはどれか。(2 つ選択）
選択肢（そのまま）
A：AWS SCT と AWS DMS を使用して、Oracle データウェアハウスを Amazon Redshift に移行します。
B：AWS DMS を使用して、Oracle データウェアハウスを Amazon EC2 に移行します。
C：AWS DMS を使用して、Oracle データウェアハウスを Amazon EMR マネージドクラスターに移行します。
D：AWS DMS を使用して、PostgreSQL データベースを Amazon EC2 に移行します。
E：AWS DMS を使用して、PostgreSQL データベースを Amazon RDS for PostgreSQL に移行します。
問題文の要件の概要
- Oracle データウェアハウスと複数の PostgreSQL データベースが存在。
- 移行先では ライセンスコストを削減したい（Oracle ライセンス削減）。
- 運用オーバーヘッドを減らす（フルマネージドサービスへの移行が望ましい）。
- 最適な移行パターンの組み合わせを選ぶ必要がある。
正解の選択肢と解説
正解：A, E
- A：Oracle → Redshift
- Oracle データウェアハウスを Amazon Redshift に移行すると、Oracle の高額ライセンス費用を削減可能。
- AWS Schema Conversion Tool (SCT) でスキーマを変換し、AWS Database Migration Service (DMS) でデータを移行する。
- Redshift はフルマネージド DWH で、パフォーマンス・スケーラビリティに優れる。
- E：PostgreSQL → Amazon RDS for PostgreSQL
- PostgreSQL を EC2 ではなく RDS に移行することで、OS・パッチ適用・バックアップ・フェイルオーバーなどの運用負担を軽減。
- DMS を使って移行可能。
- オープンソース DB であり、ライセンスコストを抑えつつ、マネージドの利点を享受できる。
不正解の選択肢の理由
- B（Oracle → EC2）：EC2 に移行しても Oracle ライセンスコストはそのまま。運用オーバーヘッドも削減できない。
- C（Oracle → EMR）：EMR はビッグデータ処理に適するが、DWH 移行先として適切ではなく、運用も増える。
- D（PostgreSQL → EC2）：EC2 に移行すると運用負担（パッチ、バックアップ管理）が残るため要件不一致。
SAP試験で押さえておくべきポイント
- Oracle DWH → Amazon Redshift：ライセンス削減 + マネージド DWH。
- PostgreSQL → Amazon RDS for PostgreSQL：オープンソース + マネージド DB。
- EC2 への移行はコスト削減・運用負担削減の観点で不適。
- SCT + DMS の組み合わせは異種 DB 移行（Oracle → Redshift など）の定番。
👉 この問題は「移行先を EC2 にすると運用負担が残るため不正解」という試験の典型パターンです。
次の問題（問題8以降）も整理していきますか？
