Uncategorized

#15

 

以下に、指定されたフォーマットで問題1を整理してご提供いたします。

■ 問題文

企業は、AWS 上のアプリケーションのコストを最適化する必要があります。このアプリケーションは、AWS Lambda 関数と、AWS Fargate 上で動作する Amazon Elastic Container Service (Amazon ECS) コンテナを使用しています。このアプリケーションは書き込み負荷が高く、Amazon Aurora MySQL データベースにデータを保存します。

アプリケーションの負荷は一定ではありません。アプリケーションは長期間使用されず、その後トラフィックが突然大幅に増減します。データベースは、メモリを最適化した DB インスタンスで実行されているが、負荷に対応できません。

ソリューションアーキテクトは、トラフィックの変化に対応できるように拡張できるソリューションを設計する必要があります。

これらの要件を最もコスト効率よく満たすソリューションを選択してください。

■ 選択肢

A. データベースにリードレプリカを追加します。Instance Savings Plans と RDS リザーブドインスタンスを購入します。

B. 複数のライターインスタンスを持つ Aurora DB クラスターにデータベースを移行します。Instance Savings Plans を購入します。

C. Aurora Global Database にデータベースを移行します。Compute Savings Plans と RDS リザーブドインスタンスを購入します。

D. Aurora Serverless v2 にデータベースを移行します。Compute Savings Plans を購入します。

■ 問題文の要件の概要

  • Lambda + Fargate を活用したサーバレス寄りの構成
  • 書き込み負荷が高い
  • Aurora MySQL 使用中（現在はメモリ最適化インスタンス）
  • トラフィックは突発的・不規則
  • 長期間使用されない期間がある
  • 負荷に応じて拡張でき、かつコスト効率が良いソリューションを求めている

■ 正解の選択肢と解説

正解: D. Aurora Serverless v2 にデータベースを移行します。Compute Savings Plans を購入します。

Aurora Serverless v2 は、アプリケーションのトラフィックの変動に応じて、自動的にスケーリングできる Aurora のモードで、使用していない期間のコストも削減できます。また、Compute Savings Plans は Fargate や Lambda にも適用可能で、長期間の利用を前提としたコスト最適化に寄与します。

この組み合わせにより、以下を満たします：

  • トラフィック急増/急減に対応（Aurora Serverless v2）
  • 書き込み負荷に対応（Aurora）
  • 非稼働時間のコスト削減（Serverless 課金モデル）
  • Lambda/Fargate に対するコスト最適化（Compute Savings Plans）

■ 不正解の選択肢の理由

  • A. リードレプリカは読み取り負荷対策に有効ですが、書き込み負荷には対応できません。また、Savings Plans と Reserved Instances は、常に起動している前提での割引であり、トラフィックが不規則なケースには不適切。
  • B. 複数のライターインスタンスは Aurora Multi-Master 構成ですが、現時点では複雑かつ制約が多く、またトラフィックの不規則性に対するコスト最適化には不向きです。
  • C. Aurora Global Database はグローバルな読み取り性能向上が主目的。スケーラビリティはあるが、突発的トラフィックの処理やコスト効率の面では Serverless v2 に劣ります。

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

  • Aurora Serverless v2 は、トラフィックが不規則・突発的なシステムに最適。常に稼働しないワークロードにはコストメリットが大きい。
  • Compute Savings Plans は、Fargate や Lambda を含む柔軟な計算リソース利用に対して割引を適用できる。
  • Auroraのモード選択（Standard vs Serverless vs Global）やSavings Planのタイプ選定（Instance vs Compute）は、コスト最適化とスケーラビリティの観点から頻出。
  • SAPレベルでは「どの構成が可用性・スケーラビリティ・コスト効率を同時に満たすか」が問われるケースが多い。

続けて他の問題も分析できますので、必要であれば次の問題をお送りください。

以下に、問題2 を指定フォーマットで整理してご提供します。

■ 問題文

ある企業は、AWS Organizations を使用してマルチアカウント構造を管理しています。同社は数百の AWS アカウントを持っており、アカウントの数はさらに増加すると予想しています。同社は、Docker イメージを使用する新しいアプリケーションを構築しています。同社は、Docker イメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュします。同社の組織内のアカウントのみがイメージにアクセスできるようにする必要があります。

同社は CI/CD プロセスを頻繁に実行しています。同社は、タグ付けされたイメージをすべて保持したいと考えています。ただし、同社はタグなしの最新の 5 つのイメージを保持しています。

運用上のオーバーヘッドを最小限に抑えてこれらの要件を満たすソリューションを選択してください。

■ 選択肢

A. Amazon ECR にプライベートリポジトリを作成します。そのリポジトリに対して、必要な ECR オペレーションのみを許可するアクセス許可ポリシーを作成します。aws:PrincipalOrgID 条件キーの値が会社の組織の ID と等しい場合に ECR オペレーションを許可する条件を含めます。ECR リポジトリにライフサイクルルールを追加し、タグ付けされていない 5 つ以上のイメージをすべて削除します。

B. Amazon ECR にパブリックリポジトリを作成します。ECR アカウントに IAM ロールを作成します。aws:PrincipalOrgID 条件キーの値が会社の組織の ID と等しい場合に、どのアカウントでもロールを引き受けられるように権限を設定します。ECR リポジトリにライフサイクルルールを追加し、タグ付けされていない 5 つ以上のイメージをすべて削除します。

C. Amazon ECR にプライベートリポジトリを作成します。そのリポジトリに対して、必要な ECR オペレーションのみを含むアクセス許可ポリシーを作成します。組織内のすべてのアカウント ID に対して ECR オペレーションを許可する条件を含めます。Amazon EventBridge ルールを毎日スケジュールして、タグ付けされていない 5 つ以上のイメージをすべて削除する AWS Lambda 関数を呼び出します。

D. Amazon ECR にパブリックリポジトリを作成します。Amazon ECR を構成して、企業がプルする必要があるイメージに必要なアクセス許可を含むエンドポイントポリシーを持つインターフェイス VPC エンドポイントを使用します。会社の組織内のすべてのアカウント ID に対して ECR オペレーションを許可する条件を含めます。Amazon EventBridge ルールを毎日スケジュールして、タグ付けされていない 5 つ以上のイメージをすべて削除する AWS Lambda 関数を呼び出します。

■ 問題文の要件の概要

  • ECR に格納された Docker イメージのセキュアな管理
    → 組織（AWS Organizations）内のアカウントのみに限定してアクセスを許可
  • 頻繁な CI/CD によるイメージ蓄積への対応
    → タグ付きはすべて保持、タグなしは直近5つのみ保持
  • 運用オーバーヘッドの最小化
    → 自動でクリーンアップされるのが理想（LambdaやEventBridgeはできれば避けたい）

■ 正解の選択肢と解説

正解: A.

  • プライベートリポジトリ + aws:PrincipalOrgID 条件付きのリポジトリポリシーにより、組織内のアカウントのみにイメージアクセスを許可可能。
  • ECR ライフサイクルルールを使えば、Lambda や EventBridge を使わずに タグなしのイメージを自動的に管理可能。
  • よって、セキュリティと運用効率の両方をバランス良く満たしており、最も適切です。

■ 不正解の選択肢の理由

  • B.
    　→ パブリックリポジトリを使用しており、組織外からもアクセス可能になってしまう。セキュリティ要件違反。
  • C.
    　→ Lambda + EventBridge によるイメージ削除は可能だが、運用オーバーヘッドが高い。ECR のネイティブ機能（ライフサイクルルール）で十分対応できるため、不要な設計。
  • D.
    　→ パブリックリポジトリ利用 + Lambda によるクリーンアップで、セキュリティも運用負荷も要件を満たさない。

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

  • ECR のアクセス制御には aws:PrincipalOrgID 条件キーを活用
    　→ Organizations 単位でのセキュアなアクセス制御が可能。アカウント増加にも強い。
  • ECR のライフサイクルポリシーは、タグ付き／タグなしの保持ルールを柔軟に設定可能
    　→ Lambda を使わなくても自動削除を実現できる。
  • パブリックリポジトリは原則 “全世界に公開” が前提
    　→ 制限付きアクセス用途では プライベートリポジトリ一択。
  • 運用の簡素さを問う問題では、Lambda や EventBridge を提案している選択肢は要注意
    　→ それが本当に必要か、ネイティブ機能で代替できないかを考える。

次の問題もお送りいただければ、同様に解説いたします。

以下に、問題3 を指定のフォーマットで整理してご提供します。

■ 問題文

ある企業には、必要以上に大きな Amazon EC2 インスタンスを立ち上げているプロジェクトがあります。このアクティビティを企業 IT の外部に維持するためのポリシー制限により、プロジェクトのアカウントを AWS Organizations の会社の組織の一部にすることはできません。同社は、プロジェクトのアカウント内の開発者による t3.small EC2 インスタンスの起動のみを許可したいと考えています。これらの EC2 インスタンスは、us-east-2 リージョンに制限する必要があります。

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

■ 選択肢

A. 新しい開発者アカウントを作成します。すべての EC2 インスタンス、ユーザー、アセットを us-east-2 に移動します。AWS Organizations の会社の組織にアカウントを追加します。リージョンアフィニティを示すタグ付けポリシーを適用します。

B. us-east-2 の t3.small EC2 インスタンス以外のすべての EC2 インスタンスの起動を拒否する SCP を作成します。プロジェクトのアカウントに SCP をアタッチします。

C. us-east-2 の開発者ごとに t3.small EC2 リザーブドインスタンスを作成して購入します。各開発者に、タグとして名前を付けた特定の EC2 インスタンスを割り当てます。

D. us-east-2 で t3.small EC2 インスタンスのみの起動を許可する IAM ポリシーを作成します。プロジェクトのアカウントで開発者が使用するロールとグループにポリシーをアタッチします。

■ 問題文の要件の概要

  • EC2のサイズ制限：t3.small のみを許可したい
  • リージョン制限：us-east-2 のみでインスタンスを起動させたい
  • 組織外アカウント：AWS Organizations には追加できない制約あり
  • 最小限の制御で実現したい（過剰な構成変更やコスト増は避ける）

■ 正解の選択肢と解説

正解：D.

us-east-2 で t3.small EC2 インスタンスのみを起動可能とする IAMポリシー を作成し、該当ロールやグループにアタッチする方法。

  • AWS Organizations を使用せずに、IAM ポリシーのみで細かな制御が可能。
  • ec2:RunInstances アクションに対して、"Condition" ブロックを使って InstanceType や Region を指定できます。
  • 以下のような構成にすることで、開発者は us-east-2 で t3.small だけを起動可能になります。

例：IAMポリシーの抜粋

{
  "Effect": "Allow",
  "Action": "ec2:RunInstances",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "ec2:InstanceType": "t3.small",
      "aws:RequestedRegion": "us-east-2"
    }
  }
}

■ 不正解の選択肢の理由

  • A.
    　→ AWS Organizations にアカウントを追加しようとしており、問題文の前提条件に違反している（外部に維持しなければならない）。また、タグ付けポリシーでは EC2 起動制御は不十分。
  • B.
    　→ SCP（Service Control Policy） は AWS Organizations に属するアカウントに対してのみ適用可能。問題文の条件（Organizationsに所属不可）に合わない。
  • C.
    　→ リザーブドインスタンスの購入は制御手段ではなくコスト最適化手段。また、個別購入＋タグ運用は非効率で手間がかかる。制御の本質を満たしていない。

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

  • IAMポリシーの ec2:RunInstances に対する条件指定（ec2:InstanceType や aws:RequestedRegion）で、細かい制御が可能
  • Organizations が使えない環境では、IAMポリシーが唯一の強力なガバナンス手段
  • SCP は強力だが、「Organizations の一部であること」が前提
  • リザーブドインスタンスはコスト削減目的であり、リソース起動の制御には直接使えない

次の問題もあれば、引き続きお任せください。試験によく出る IAM 条件キーのまとめなどもご提供可能です。

以下に、問題4 を指定のフォーマットで整理してご提供します。

■ 問題文

ある企業は、オンプレミスのトランザクション処理アプリケーションを AWS に移行することを計画しています。このアプリケーションは Docker コンテナ内で実行され、会社のデータセンター内の VM 上でホストされています。Docker コンテナには共有ストレージがあり、アプリケーションはここにトランザクションデータを記録します。

トランザクションは時間に敏感です。アプリケーション内のトランザクションの量は予測できません。同社は、需要の増加に合わせてスループットを自動的に拡張する低レイテンシーストレージソリューションを実装する必要があります。同社はアプリケーションをこれ以上開発することができず、Docker ホスティング環境の管理を継続することもできません。

これらの要件を満たすために、企業はアプリケーションを AWS にどのように移行する必要がありますか？

■ 選択肢

A. アプリケーションを実行するコンテナを Amazon Elastic Kubernetes Service (Amazon EKS) に移行します。Amazon S3 を使用して、コンテナが共有するトランザクションデータを保存します。

B. アプリケーションを実行するコンテナを Amazon Elastic Container Service (Amazon ECS) の AWS Fargate に移行します。Amazon Elastic File System (Amazon EFS) ファイルシステムを作成します。Fargate タスク定義を作成します。タスク定義にボリュームを追加して、EFS ファイルシステムを指すようにします。

C. アプリケーションを実行するコンテナを Amazon Elastic Container Service (Amazon ECS) の AWS Fargate に移行します。Amazon Elastic Block Store (Amazon EBS) ボリュームを作成します。Fargate タスク定義を作成します。実行中の各タスクに EBS ボリュームをアタッチします。

D. Amazon EC2 インスタンスを起動します。EC2 インスタンスに Docker をインストールします。EC2 インスタンスにコンテナを移行します。Amazon Elastic File System (Amazon EFS) ファイルシステムを作成します。EC2 インスタンスに EFS ファイルシステムのマウントポイントを追加します。

■ 問題文の要件の概要

  • アプリケーションを再開発できない（リフト＆シフト）
  • Docker ホスティング環境の管理は不可
  • トランザクションデータは共有ストレージに記録
  • 低レイテンシー & スループット自動拡張が必要
  • トランザクション数は予測できない（可変性が高い）

■ 正解の選択肢と解説

正解：B

ECS on Fargate + EFS の組み合わせが最適

  • AWS Fargate により、サーバー管理が不要となり、コンテナホスティングの運用負荷を解消。
  • Amazon EFS は複数タスク間で共有可能なファイルシステムで、スループット自動拡張や低レイテンシーアクセスにも対応。
  • Fargate タスク定義に EFS マウントポイントを指定することで、各タスクが同じストレージにアクセス可能。

■ 不正解の選択肢の理由

  • A.
    　→ Amazon S3 はオブジェクトストレージであり、ファイルシステムのような低レイテンシーで頻繁な read/write には不向き。また EKS もクラスター管理が必要なため「ホスティング管理不可」という条件に合致しない。
  • C.
    　→ Amazon EBS は EC2 専用のブロックストレージで、複数のタスク間で共有できない。また、Fargate タスクには直接アタッチできないため構成として不適切。
  • D.
    　→ EC2 インスタンスを自分で立ち上げる必要があり、「Docker ホスティング環境の管理を継続できない」という要件に違反。

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

  • Fargate + EFS は、コンテナ管理を最小化しつつ、共有ストレージが必要なシナリオにおけるベストプラクティス。
  • EFS はスループットの自動調整が可能で、トラフィック変動の大きいアプリにも対応しやすい。
  • EBSは1対1のEC2アタッチ型ストレージ。複数コンテナでの共有には向かない。
  • オブジェクトストレージ（S3）は高スループットだが低レイテンシーではない。ファイルシステム用途ではEFSが正解。

次の問題もお気軽にどうぞ。必要であれば「FargateとECSの違い」「EFSの構成パターン」なども補足解説します。

以下に、提供いただいた「問題5」の内容を、指定のフォーマットで整理して解説いたします。

■ 問題文

ある金融サービス会社には、世界中で何千人ものお客様が利用している資産運用商品があります。お客様はアンケートを通じて製品に関するフィードバックを提供しています。同社は、これらのアンケートのデータを分析するために、Amazon EMR 上で動作する新しい分析ソリューションを構築しています。次のユーザーペルソナは、さまざまなアクションを実行するために分析ソリューションにアクセスする必要があります。

  • 管理者 : チームの要件に基づいて、分析チーム用に EMR クラスターをプロビジョニングします。
  • データエンジニア : ETL スクリプトを実行し、データセットを処理、変換、強化します。
  • データアナリスト : データに対して SQL や Hive クエリーを実行します。

ソリューションアーキテクトは、すべてのユーザーペルソナが必要なリソースだけに最小権限でアクセスできるようにしなければなりません。ユーザーペルソナは、承認および許可されたアプリケーションのみを起動できる必要があります。また、ソリューションでは、ユーザーペルソナが作成するすべてのリソースのタグ付けを確実に行う必要があります。

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

■ 選択肢（正誤を伏せたまま）

A. 各ユーザーペルソナに IAM ロールを作成します。アイデンティティベースのポリシーをアタッチして、ロールを引き受けるユーザーが実行できるアクションを定義します。AWS Config ルールを作成して、非準拠のリソースを確認します。非準拠のリソースを修復するために、管理者に通知するルールを構成します。

B. EMR クラスターの起動時に Kerberos ベースの認証を設定します。クラスター固有の Kerberos オプションとともに、Kerberos セキュリティ構成を指定します。

C. AWS Service Catalog を使用して、デプロイに利用可能な Amazon EMR のバージョン、クラスター構成、および各ユーザーペルソナのアクセス許可を制御します。

D. AWS CloudFormation を使用して EMR クラスターを起動し、クラスターの作成時にリソースベースのポリシーを EMR クラスターにアタッチします。AWS Config ルールを作成して、非準拠のクラスターと非準拠の Amazon S3 バケットを確認します。管理者に非準拠リソースを修復するよう通知するルールを構成します。

■ 問題文の要件の概要

  • 複数のユーザーペルソナ（管理者・エンジニア・アナリスト）が存在
  • 最小権限アクセスの適用
  • 承認されたアプリケーション構成の起動制限
  • 作成リソースに対するタグ付けの徹底
  • EMR クラスターの使用とその構成の統制

■ 正解の選択肢と解説

正解：C. AWS Service Catalog を使用して、デプロイに利用可能な Amazon EMR のバージョン、クラスター構成、および各ユーザーペルソナのアクセス許可を制御します。

理由：
AWS Service Catalog は、企業が事前承認された構成（CloudFormationなど）をカタログとして提供し、ユーザーがその範囲内でデプロイできるようにする仕組みです。

  • 最小権限アクセス制御：ユーザーペルソナごとに IAM と連携し、アクセス範囲を制限できます。
  • 起動可能な構成の制限：Service Catalog 製品で「どの AMI」「どの EMR バージョン」などを定義可能。
  • タグの自動付与：テンプレート側に強制的にタグ設定を埋め込める。
  • ユーザーのミスや構成のばらつきを防止し、ガバナンスの効いた構成管理が可能です。

■ 不正解の選択肢の理由

A. IAM ロール + AWS Config ルール
→ IAM ロールはユーザーアクセス管理には有効ですが、起動する構成の制御（承認済みアプリ制限）やタグ強制はできません。AWS Config は後付けの検知はできますが、「防止」や「制御」はできないため要件不一致。

B. Kerberos 認証
→ Kerberos は EMR 内部のユーザー認証・認可に使うもの。ペルソナ別の IAM 権限制御やタグの強制、承認済みアプリ制限には関与しません。

D. CloudFormation + Config ルール
→ CloudFormation は構成の自動化はできても、「誰がどのテンプレートを使えるか」のカタログ的管理はできません。またタグ付け強制やアクセス制御も統合的には行えません。

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

✅ AWS Service Catalog のユースケース：

  • 特定構成のデプロイ制限
  • ガバナンス遵守（タグ、リージョン、設定制限）
  • ユーザーペルソナごとのアクセス管理とセルフサービス展開

✅ 最小権限の原則（Least Privilege）：

  • IAM ポリシーだけでは不十分な場合、Service Catalog や SCP との組み合わせが必要なことも。

✅ タグポリシーや自動タグ付けの実現手段としての CloudFormation / Service Catalog の活用。

✅ AWS Config は「検出・通知」までで、「制御」は行えないことに注意。

ご不明点があれば、続けて深掘り可能です。次の問題もお待ちしています！

以下に、提供いただいた「問題6」の内容を指定フォーマットで整理して解説します。

■ 問題文

ある企業のコンプライアンス監査で、AWS アカウントで作成された Amazon Elastic Block Store (Amazon EBS) ボリュームの一部が暗号化されていないことが判明しました。ソリューションアーキテクトは、すべての新しい EBS ボリュームを暗号化するソリューションを実装する必要があります。
最小限の労力でこの要件を満たすソリューションを選択してください。

■ 選択肢（正誤を伏せたまま）

A. 暗号化されていない EBS ボリュームの作成を検出する Amazon EventBridge ルールを作成します。AWS Lambda 関数を呼び出して、非準拠のボリュームを削除します。

B. データ暗号化を備えた AWS Audit Manager を使用します。

C. 新しい EBS ボリュームの作成を検出する AWS Config ルールを作成します。AWS Systems Manager Automation を使用してボリュームを暗号化します。

D. すべての AWS リージョンで EBS 暗号化をデフォルトで有効にします。

■ 問題文の要件の概要

  • 一部の EBS ボリュームが暗号化されていない
  • 今後作成される すべての新しい EBS ボリュームを確実に暗号化したい
  • 最小限の労力で実現する方法を問う

■ 正解の選択肢と解説

正解：D. すべての AWS リージョンで EBS 暗号化をデフォルトで有効にします。

解説：

Amazon EC2/EBS には「EBS 暗号化のデフォルト有効化」という設定があり、これを有効にすることで、そのリージョン内で作成される すべての新しい EBS ボリュームが自動的に暗号化されます。

  • 設定は1回のみで済み、手動介入が不要
  • リージョン単位で適用され、確実性が高い
  • KMSキーを指定して暗号化も可能

この機能を使えば、EventBridgeやConfigを用いた後追い対応が不要となり、最小の労力でコンプライアンス要件を満たせます。

■ 不正解の選択肢の理由

A. EventBridge + Lambda で非暗号化検出 → 削除
→ 暗号化を「強制」するのではなく、後処理。しかも削除は業務への影響大。プロアクティブではなく、破壊的な対応で非現実的。

B. AWS Audit Manager の使用
→ Audit Manager は「監査支援ツール」であり、EBS 暗号化の制御や強制はできません。可視化とレポートが主な用途です。

C. AWS Config + Systems Manager Automation で後暗号化
→ これも後追いの対応であり、手間が多くリアルタイム性に欠ける。また、既存ボリュームの再暗号化は一度スナップショット＆再作成が必要。

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

✅ EBS 暗号化のデフォルト設定（Enable EBS encryption by default）は、

  • 新規作成ボリューム・スナップショットコピーに対して有効
  • 既存ボリュームには影響しない
  • リージョン単位の設定なので、グローバルに対応する場合はすべてのリージョンで設定が必要

✅ 最小の労力での強制適用 = デフォルト暗号化設定がベストプラクティス

✅ 後追い対応（EventBridge, Config, Automation）よりも「未然防止」が重要

ご不明な点や他の問題もございましたら、引き続きお知らせください！

以下に「問題7」の内容を指定フォーマットで整理・解説します。

■ 問題文

ある企業には、複数の .NET Framework コンポーネント上で実行されるレガシーアプリケーションがあります。これらのコンポーネントは、同じ Microsoft SQL Server データベースを共有し、Microsoft メッセージキュー (MSMQ) を使用して非同期に通信を行います。

同社は、コンテナ化された .NET Core コンポーネントへの移行を開始しており、AWS 上で実行するためにアプリケーションをリファクタリングしたいと考えています。.NET Core コンポーネントは複雑なオーケストレーションを必要とします。同社は、ネットワークとホスト構成を完全に制御する必要があります。アプリケーションのデータベースモデルは強いリレーショナルです。

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

■ 選択肢（正誤を伏せたまま）

A. AWS App Runner で .NET Core コンポーネントをホストします。Amazon RDS for SQL Server でデータベースをホストします。非同期メッセージングには Amazon EventBridge を使用します。

B. AWS Fargate 起動タイプを使用して、Amazon ECS で .NET Core コンポーネントをホストします。Amazon DynamoDB でデータベースをホストします。非同期メッセージングには Amazon SNS を使用します。

C. AWS Elastic Beanstalk で .NET Core コンポーネントをホストします。Amazon Aurora PostgreSQL Serverless v2 でデータベースをホストします。非同期メッセージングには Amazon MSK を使用します。

D. Amazon ECS（EC2 起動タイプ）で .NET Core コンポーネントをホストします。Amazon Aurora MySQL Serverless v2 でデータベースをホストします。非同期メッセージングには Amazon SQS を使用します。

■ 問題文の要件の概要

  • レガシー → .NET Core への移行
  • 複雑なオーケストレーションが必要
  • ネットワークとホスト構成の完全な制御が必要
  • 強いリレーショナルデータベースが必要
  • 非同期メッセージングのサポート（MSMQ代替）

■ 正解の選択肢と解説

正解：D. Amazon ECS（EC2起動タイプ） + Aurora MySQL Serverless v2 + SQS

解説：

  • ECS on EC2: Fargateでは制御できない ホスト設定やネットワーク構成をEC2起動タイプで完全に制御可能。
  • Aurora MySQL Serverless v2: 高い可用性とスケーラビリティを持ち、強いリレーショナルデータモデルに適している。
  • SQS: MSMQ のような非同期通信に最適なマネージドキューイングサービス。簡素で信頼性の高い非同期メッセージングが可能。

この構成は、移行・制御・通信のすべての観点から、最も要件に合致した選択肢です。

■ 不正解の選択肢の理由

A. App Runner + RDS for SQL Server + EventBridge

  • App Runner は複雑なオーケストレーションやホスト構成の制御に不向き。
  • EventBridge はイベントルーティング向けで、MSMQのようなキュー用途には不適。

B. Fargate + DynamoDB + SNS

  • Fargate はホスト制御ができない。
  • DynamoDB は非リレーショナル。強いリレーショナル要件に不適。
  • SNS はPub/Sub。MSMQの代替には向かない。

C. Elastic Beanstalk + Aurora PostgreSQL + MSK

  • Beanstalk は制御粒度が粗く、複雑なオーケストレーションに向かない。
  • MSK（Kafka） は強力だが、MSMQの代替としては過剰かつ運用が複雑。

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

✅ EC2起動タイプのECS → ホスト・ネットワーク構成を完全制御したいときに選ぶ
✅ Fargate起動タイプ → 制御不要で簡素な構成を目指すときに選ぶ（制限あり）
✅ Aurora Serverless v2 → スケーラブルかつ高パフォーマンスなリレーショナルDBが必要なときに有効
✅ SQS vs SNS vs MSK

  • SQS：単純なキューイング、MSMQ代替に最適
  • SNS：Pub/Sub（ファンアウト）用途
  • MSK：複雑なストリーミング処理向け、運用負荷大

引き続き他の問題も対応可能ですので、必要であれば貼り付けてください！

RELATED POST