以下は、提示された問題に基づいた整理です。
■ 問題文（そのまま）
ある企業は、Amazon RDS for MySQL データベースを使用してデータを保存する重要なアプリケーションを実行しています。RDS DB インスタンスはマルチ AZ モードでデプロイされています。
最近の RDS データベースのフェイルオーバーテストでは、アプリケーションに 40 秒の停止が発生しました。ソリューションアーキテクトは、停止時間を 20 秒未満に短縮するソリューションを設計する必要があります。
これらの要件を満たす最適な手順を組み合わせを選択してください。 (3 つ選択)
■ 選択肢（文字列そのまま）
- A. Amazon ElastiCache for Memcached をデータベースの前で使用します。
- B. Amazon ElastiCache for Redis をデータベースの前で使用します。
- C. RDS Proxy をデータベースの前で使用します。
- D. データベースを Amazon Aurora MySQL に移行します。
- E. Amazon Aurora レプリカを作成します。
- F. RDS for MySQL リードレプリカを作成します。
■ 問題文の要件の概要
- RDS MySQL のフェイルオーバーによって発生する ダウンタイム（40秒） を 20秒未満 に短縮したい。
- 高可用性と速やかなフェイルオーバーが求められる。
- 高速な接続切替、短縮されたフェイルオーバー時間がキー。
■ 正解の選択肢と解説
✅ C. RDS Proxy をデータベースの前で使用します。
RDS Proxy は接続プーリングとフェイルオーバー時の自動接続先切替を行うため、停止時間を数秒に短縮可能。
✅ D. データベースを Amazon Aurora MySQL に移行します。
Aurora MySQL はフェイルオーバーを 10〜20 秒で完了でき、停止時間を要件内に抑えられる。
✅ E. Amazon Aurora レプリカを作成します。
Aurora レプリカは自動昇格が高速（数秒）で、Aurora の高速フェイルオーバーを補完。
■ 不正解の選択肢の理由
❌ A. Amazon ElastiCache for Memcached
キャッシュによってレイテンシー削減はできるが、DBフェイルオーバーによる停止時間の短縮には無関係。
❌ B. Amazon ElastiCache for Redis
Memcachedと同様にキャッシュは遅延軽減用。書き込みはバックエンドDB依存なので、フェイルオーバー時の停止には無力。
❌ F. RDS for MySQL リードレプリカを作成します。
MySQLリードレプリカは自動昇格非対応かつ非同期レプリケーションのため、手動操作が必要で時間がかかる。
■ SAP試験で押さえておくべきポイント
- Aurora MySQL は従来のRDSよりも高速なフェイルオーバーが可能（約10～20秒）。
- RDS Proxy によってアプリケーションの接続維持と切替が迅速に行える。
- RDSリードレプリカ（MySQL） は高可用性ではなくスケーラビリティ用途（読み取り負荷分散）である。
- ElastiCache（Redis/Memcached）はキャッシュ用途であって、可用性対策ではない。
- 高可用性 = 自動フェイルオーバー機能の有無 + 接続切替の仕組みであることを整理して覚える。
必要に応じて次の問題も対応可能です。ご希望があればお知らせください。
以下に、AWS Certified Solutions Architect – Professional（SAP）試験問題2 を指定の形式で整理しました。
◆ 問題文（編集なし）
ある企業が AWS クラウドで、Auto Scaling グループの Amazon EC2 インスタンスを使用して動画を処理しています。動画の処理には 30 分かかります。Amazon Simple Queue Service (Amazon SQS) のキューにある動画の数に応じて、複数の EC2 インスタンスがスケールイン / スケールアウトします。
会社は、ターゲットデッドレターキューと maxReceiveCount を 1 に指定する Redrive ポリシーを使用して SQS キューを構成しました。会社は、SQS キューの可視性タイムアウトを 1 時間に設定しました。同社は、デッドレターキューにメッセージがある場合に開発チームに通知する Amazon CloudWatch アラームを設定しました。
一日のうちに数回、開発チームは、メッセージがデッドレターキューにあり、動画が処理されていないという通知を受け取ります。調査の結果、アプリケーションログにエラーは見つかりませんでした。
この問題を解決する最適な方法を選択してください。
◆ 選択肢（編集なし）
- A. EC2 インスタンスの終了保護を有効にします。
- B. SQS キューの可視性タイムアウトを 3 時間に更新します。
- C. 処理中のインスタンスのスケールイン保護を設定します。
- D. Redrive ポリシーを更新し、maxReceiveCount を 0 に設定します。
◆ 問題文の要件の概要
- Auto Scaling 環境で動画処理を実施。
- 各動画処理には 30分 かかる。
- SQS → EC2ワーカーで処理しているが、処理されないままDLQに送られることがある。
- 可視性タイムアウトは 1時間 に設定されており、アプリケーションログにエラーはない。
- 原因不明のメッセージ未処理（DLQ送り）を解消する必要がある。
◆ 正解の選択肢と解説
正解：C. 処理中のインスタンスのスケールイン保護を設定します。
- Auto Scaling における スケールイン保護を使うと、ジョブを処理中のインスタンスがスケールインで削除されるのを防げます。
- 本問では、動画処理中にスケールインでインスタンスが落ちてしまい、可視性タイムアウト後に再取得、そして
maxReceiveCount=1によりDLQ行きになっている。 - スケールイン保護を使えば、ジョブ完了までインスタンスが維持され、処理漏れ・DLQ行きの根本原因を解決できます。
◆ 不正解の選択肢の理由
- A. EC2 インスタンスの終了保護を有効にします。
→ EC2の終了保護は、ユーザーやスクリプトによる手動終了操作の防止であり、Auto Scaling のスケールインとは無関係です。スケールインイベントではインスタンスは終了されてしまいます。 - B. SQS キューの可視性タイムアウトを 3 時間に更新します。
→ 可視性タイムアウトを延長しても、スケールインでインスタンスが落ちた場合、ジョブは完了せず、可視時間経過後に再表示 →maxReceiveCount超過 → DLQ行きとなるため無意味です。 - D. Redrive ポリシーを更新し、maxReceiveCount を 0 に設定します。
→maxReceiveCount = 0は無効であり、ポリシーが適用されなくなります。失敗したメッセージが再処理され続けるだけで、根本解決にはなりません。
◆ SAP試験で押さえておくべきポイント
- Auto ScalingとSQSの連携設計：長時間処理を伴うジョブでは「スケールイン保護」を忘れずに。
- 終了保護とスケールイン保護の違い：
- 終了保護 → EC2手動終了防止。
- スケールイン保護 → Auto Scaling の終了対象から除外。 - SQSのRedriveポリシーとmaxReceiveCountの意味：DLQの利用は一時的失敗の検出目的。根本対処を怠るとDLQに溢れる。
- 可視性タイムアウトは万能ではない：インスタンス落ちなど他要因には無力。可視時間は適切な範囲に。
次の問題も引き続き対応できますので、どうぞ送ってください。
以下に、問題3の内容を指定された形式で整理しました。
■ 問題文
ある企業では、社内のクラウド課金戦略を事業部ごとに変更したいと考えています。現在、クラウドガバナンスチームは、クラウド全体の支出に関するレポートを各事業部の責任者と共有しています。この会社では、AWS Organizations を使用して、各事業部の個別の AWS アカウントを管理しています。組織の既存のタグ付け基準には、アプリケーション、環境、および所有者が含まれています。クラウドガバナンスチームは、各事業部がクラウド支出に関する月次レポートを受け取ることができるように、一元化されたソリューションを望んでいます。また、設定したしきい値を超えたクラウド利用があった場合には、通知を送信する必要があります。
これらの要件を満たすための最も費用対効果の高いソリューションを選択してください。
■ 選択肢（※文字列はそのまま）
A. 各アカウントで AWS Budgets を設定し、アプリケーション、環境、所有者ごとにグループ化された予算アラートを設定します。各事業部をアラートごとに Amazon SNS トピックに追加します。各アカウントで Cost Explorer を使用して、各事業部の月次レポートを作成します。
B. 組織の管理アカウントで AWS Budgets を設定し、アプリケーション、環境、所有者ごとにグループ化された予算アラートを設定します。各事業部をアラートごとに Amazon SNS トピックに追加します。組織の管理アカウントで Cost Explorer を使用して、各事業部の月次レポートを作成します。
C. 各アカウントで AWS Budgets を設定し、アプリケーション、環境、所有者ごとにグループ化された予算アラートを設定します。各事業部をアラートごとに Amazon SNS トピックに追加します。各アカウントで AWS Billing and Cost Management ダッシュボードを使用して、各事業部の月次レポートを作成します。
D. 組織の管理アカウントで AWS コストと使用状況レポートを有効にし、アプリケーション、環境、所有者ごとにグループ化されたレポートを設定します。AWS コストと使用状況レポートを処理し、予算アラートを送信し、各事業部のメーリングリストに月次レポートを送信する AWS Lambda 関数を作成します。
■ 問題文の要件の概要
- AWS Organizations を利用した複数アカウント構成
- タグ（アプリケーション、環境、所有者）を活用
- 事業部単位でのコスト把握
- 月次レポートを配信したい
- 予算しきい値超過時には通知が必要
- 中央管理・費用対効果が求められている
■ 正解の選択肢と解説
正解：B
組織の管理アカウントで AWS Budgets を設定し、アプリケーション、環境、所有者ごとにグループ化された予算アラートを設定します。各事業部をアラートごとに Amazon SNS トピックに追加します。組織の管理アカウントで Cost Explorer を使用して、各事業部の月次レポートを作成します。
- 管理アカウントから 組織全体に対して集中管理ができ、費用対効果が高い。
- 既存タグでアカウント横断の予算設定とコストフィルタリングが可能。
- Budgetsでしきい値通知、Cost Explorerで月次レポートが作成可能。
- SNS連携により、各部門へ自動通知も実装できる。
■ 不正解の選択肢の理由
A. 各アカウントで AWS Budgets と Cost Explorer を個別設定
- 各アカウントにバラバラに予算設定すると一元管理できず、手間と運用コストが増す。
- クロスアカウント集計が困難で、全体最適ができない。
C. 各アカウントで Budgets と Billing Dashboard を使用
- Billing Dashboard は可視化に特化しており、自動レポート送信や通知機能はない。
- Budgetsの設定もアカウントごとでは管理が煩雑。
D. CUR（Cost and Usage Report）＋ Lambda
- CURは高機能だが、Athena, Glue, Lambda などの実装が必要で、保守・運用コストが高くなる。
- 要件に対してオーバーエンジニアリングである。
■ SAP試験で押さえておくべきポイント
- AWS Budgets はしきい値ベースでコスト・使用量の管理が可能。SNS と連携できる。
- Cost Explorer はタグに基づいた可視化・レポート出力が可能。
- AWS Organizations の管理アカウントから予算やレポートの集中管理が可能。
- 各アカウント個別管理は非効率で、試験では避けるべき選択肢。
- CUR + Lambda のような実装は拡張性は高いが、費用対効果と照らして適切か見極めが必要。
次の問題もどうぞ、お待ちしています。
以下に、AWS SAP問題4の解説を指定の形式でまとめました。
◆ 問題文
オンラインゲーム会社は、ゲームプラットフォームを AWS で再ホストする必要があります。同社のゲームアプリケーションは、ハイパフォーマンスコンピューティング (HPC) 処理を必要とし、頻繁に変更されるリーダーボードを持っています。コンピューティング生成用に最適化された Ubuntu インスタンスは、ゲーム表示用の Node.js アプリケーションをホストします。ゲームの状態はオンプレミスの Redis インスタンスで追跡されます。
同社は、アプリケーションのパフォーマンスを最適化する移行戦略を必要としています。
これらの要件を満たすソリューションを選択してください。
◆ 選択肢
A: Application Load Balancer の背後に m5.large Amazon EC2 スポットインスタンスの Auto Scaling グループを作成します。Amazon ElastiCache for Redis クラスターを使用して、リーダーボードを維持します。
B: Application Load Balancer の背後に c5.large Amazon EC2 スポットインスタンスの Auto Scaling グループを作成します。Amazon OpenSearch Service クラスターを使用して、リーダーボードを維持します。
C: Application Load Balancer の背後に c5.large Amazon EC2 オンデマンドインスタンスの Auto Scaling グループを作成します。Amazon ElastiCache for Redis クラスターを使用して、リーダーボードを維持します。
D: Application Load Balancer の背後に m5.large Amazon EC2 オンデマンドインスタンスの Auto Scaling グループを作成します。Amazon DynamoDB のテーブルを使用してリーダーボードを維持します。
◆ 問題文の要件の概要
- 高性能な計算能力（HPC）を要するゲーム処理
- 頻繁に変更されるリーダーボード（高速読み書きが必要）
- Ubuntu + Node.js の環境
- パフォーマンス最適化が目的
- Redisを使用している（低レイテンシーなデータストア）
◆ 正解の選択肢と解説
正解：C
解説：
c5.large（オンデマンド）：コンピューティング最適化インスタンス。HPC用途に適しており、オンデマンドを選ぶことでスポット中断のリスクを排除。ゲーム処理の安定性が向上。ElastiCache for Redis：Redis互換のインメモリデータストア。リーダーボードのように頻繁な更新と高速レスポンスが求められるユースケースに最適。
◆ 不正解の選択肢の理由
A:
m5.largeは汎用インスタンスであり、HPC向けにはスペック不足。- スポットインスタンスは中断リスクがあり、リアルタイム性が重要なゲームアプリには不適。
B:
c5.largeの選定は良いが、OpenSearchは検索用であり、リーダーボードのような高速更新用途には不向き。
D:
DynamoDBは高速なNoSQL DBではあるが、Redisに比べてレイテンシーが高く、インメモリ処理ができないためリーダーボードには不向き。m5.largeもHPCには適さない。
◆ SAP試験で押さえておくべきポイント
- HPC用途には
c5系インスタンス（Compute Optimized）を選ぶこと。 - スポットインスタンスはコスト効果は高いが中断リスクあり。常時稼働が求められるワークロードには不向き。
- 頻繁に変更・更新されるデータ（リーダーボードなど）には、ElastiCache for Redis のようなインメモリストレージが最適。
- OpenSearch や DynamoDB は用途が異なるため、データの性質（アクセス頻度、読み書きのパターン）に応じて適切に選定する。
次の問題があれば、同様の形式でお手伝いしますので送ってください。
以下に、AWS SAP問題5の内容を指定フォーマットで整理しました。
◆ 問題文（編集せずに出力）
ある企業は、Amazon EC2 インスタンスのフリート上に分散インメモリデータベースをデプロイしています。フリートは、1 つのプライマリノードと 8 つのワーカーノードで構成されています。プライマリノードは、クラスターの状態を監視し、ユーザーリクエストを受け付け、ユーザーリクエストをワーカーノードに分散し、集約されたレスポンスをクライアントに返送します。ワーカーノードは相互に通信してデータパーティションを複製します。
同社では、最大のパフォーマンスを達成するために、ネットワーク遅延を可能な限り低く抑える必要があります。
これらの要件を満たすソリューションを選択してください。
◆ 選択肢（編集せずに出力）
A: パーティションプレイスメントグループでメモリ最適化 EC2 インスタンスを起動します。
B: パーティションプレイスメントグループでコンピューティング最適化 EC2 インスタンスを起動します。
C: クラスタープレイスメントグループでメモリ最適化 EC2 インスタンスを起動します。
D: スプレッドプレイスメントグループでコンピューティング最適化 EC2 インスタンスを起動します。
◆ 問題文の要件の概要
- 分散インメモリデータベースを使用
- 高速なノード間通信が求められる（複製・集約処理）
- ネットワーク遅延を極力小さくしたい
- ノード数は9（プライマリ1＋ワーカー8）
◆ 正解の選択肢と解説
正解：C
クラスタープレイスメントグループでメモリ最適化 EC2 インスタンスを起動します。
解説：
- クラスタープレイスメントグループは、インスタンスを物理的に近接配置することで、ノード間の**レイテンシーを最小限（1桁ms未満）**に抑え、**高帯域通信（最大100 Gbps）**を可能にします。
- メモリ最適化インスタンスは、インメモリデータベースに必要な大容量RAMと高速ENA（Elastic Network Adapter）を持ち、高い処理性能を発揮します。
- この組み合わせにより、ノード間の複製や集約処理のパフォーマンスを最大化できます。
◆ 不正解の選択肢の理由
A: パーティション + メモリ最適化
- パーティションプレイスメントはラック分散が目的で、ノード間距離が広がりレイテンシーが悪化。
- 高可用性には向くが、低レイテンシー要件には不適。
B: パーティション + コンピューティング最適化
- プレイスメントがラック分散により遅延が大きくなる。
- コンピューティング最適化インスタンスはvCPU性能は高いがメモリ帯域が不十分で、インメモリDBに不向き。
D: スプレッド + コンピューティング最適化
- スプレッドプレイスメントは**可用性重視（別ホスト配置）**で、低レイテンシーを実現できない。
- メモリ要件も満たせず、適切ではない。
◆ SAP試験で押さえておくべきポイント
- クラスタープレイスメントグループはレイテンシー重視用途（HPC、インメモリDB）に使う。
- パーティションプレイスメントグループは高可用性／障害分離に向くが、レイテンシーは劣る。
- スプレッドプレイスメントグループは、単一ラックへの配置を避け、インスタンス障害の影響を限定するために利用。
- インスタンスタイプ選定はワークロード特性に合わせる：
- メモリ最適化：インメモリDB、キャッシュ用途
- コンピューティング最適化：高vCPU処理（ゲーム、バッチ）
次の問題があれば、またお送りください。引き続きSAP対策をサポートします。
以下に、AWS Certified Solutions Architect – Professional（SAP）問題6の整理と解説を行います。
◆ 問題文（原文）
あるソリューションアーキテクトは、従業員のモバイルデバイスからタイムシートの入力を受け付けるアプリケーションを設計しています。タイムシートは毎週提出され、ほとんどの提出は金曜日に行われます。データは、給与管理者が月次レポートを作成できる形式で保存する必要があります。インフラは可用性が高く、入力されるデータとレポート要求の速度に合わせて拡張できる必要があります。
運用上のオーバーヘッドを最小限に抑えつつ、これらの要件を満たす手順の組み合わせを選択してください。 (2 つ選択)
◆ 選択肢（原文）
- A. 複数のアベイラビリティーゾーン間で負荷分散を行う Amazon EC2 オンデマンドインスタンスにアプリケーションをデプロイします。スケジュールされた Amazon EC2 Auto Scaling を使用して、金曜日の大量の送信の前に容量を追加します。
- B. 複数のアベイラビリティーゾーン間で負荷分散を行う Amazon Elastic Container Service (Amazon ECS) を使用して、コンテナにアプリケーションをデプロイします。スケジュールされた Service Auto Scaling を使用して、金曜日の大量の送信の前に容量を追加します。
- C. アプリケーションのフロントエンドを、Amazon CloudFront が提供する Amazon S3 バケットにデプロイします。AWS Lambda プロキシ統合を備えた Amazon API Gateway を使用して、アプリケーションバックエンドをデプロイします。
- D. タイムシートの提出データを Amazon Redshift に保存します。Amazon QuickSight を使用して、データソースとして Amazon Redshift を使用してレポートを生成します。
- E. タイムシート提出データを Amazon S3 に保存します。Amazon Athena と Amazon QuickSight を使用して、データソースとして Amazon S3 を使用してレポートを生成します。
◆ 問題文の要件の概要
- 可用性が高いインフラ
- スパイク（金曜の集中）に自動的に対応可能なスケーラビリティ
- 月次レポート生成に適したデータ形式
- 運用負荷の最小化
◆ 正解の選択肢と解説
✅ C. Amazon S3 + CloudFront + API Gateway + Lambda
→ フロントは S3 に静的ホスティングし、CloudFront によりキャッシュ・高速配信。バックエンドは Lambda と API Gateway による完全サーバーレス構成で、スパイクにも自動スケーリング可能。メンテナンス不要で可用性も高く、運用負荷最小。
✅ E. Amazon S3 + Athena + QuickSight
→ データ保存は S3（安価・スケーラブル・高耐久）、Athena によるサーバーレス SQL 分析、QuickSight による GUI レポート作成。月次レポート向きかつフルマネージド分析基盤。運用負荷・コストが最も低い。
◆ 不正解の選択肢の理由
❌ A. EC2 + Auto Scaling（スケジュールベース）
→ インスタンス管理・OS保守・セキュリティ更新など運用負荷が大きい。Auto Scaling は事前予測のピークにしか対応できず、突発スパイクに弱い。
❌ B. ECS（EC2ベース） + Service Auto Scaling
→ ECS on EC2 はクラスターの管理が必要で、EC2 キャパシティ不足時はスケール失敗の可能性。フルマネージドではないため運用が複雑。
❌ D. Redshift + QuickSight
→ Redshift は大規模分析向けで、モバイルアプリのリアルタイムデータ処理や小規模トランザクションには不適。初期セットアップ・VACUUM などの管理が必要で運用負荷が高い。
◆ SAP試験で押さえておくべきポイント
- サーバーレス（S3, Lambda, API Gateway, Athena）を活用して運用負荷を下げる構成を選ぶこと
- リアルタイム or バッチ処理の特性に応じたサービス選定
- Redshift は大規模バッチ分析用途、Athena は小規模データ分析・クエリに適する
- EC2やECS on EC2は管理対象が多いため、明示的に避けられることが多い
次の問題があれば、引き続きどうぞ！
以下に、AWS Certified Solutions Architect – Professional（SAP）問題7の内容を指定フォーマットで整理・解説します。
◆ 問題文（原文）
ある企業が、ユーザーがランダムに写真をアップロードして検索できる画像サービスをウェブ上に構築しています。ピーク時には、世界中で最大 1 万人のユーザーが画像をアップロードします。アップロードされた画像にテキストが重ねられ、企業のウェブサイトに公開されます。
ソリューションアーキテクトはどの設計を実装する必要がありますか ?
◆ 選択肢（原文）
A:
アップロードされた画像を Amazon Elastic File System (Amazon EFS) に保存します。各画像に関するアプリケーションログ情報を Amazon CloudWatch Logs に送信します。CloudWatch Logs を使用して、処理する必要がある画像を決定する Amazon EC2 インスタンスのフリートを作成します。処理した画像を Amazon EFS の別のディレクトリに配置します。Amazon CloudFront を有効にし、オリジンをフリート内の EC2 インスタンスの 1 つに設定します。
B:
アップロードされた画像を Amazon S3 バケットに保存し、Amazon Simple Notification Service (Amazon SNS) にメッセージを送信するように S3 バケットのイベント通知を設定します。Application Load Balancer (ALB) の背後に Amazon EC2 インスタンスのフリートを作成し、Amazon SNS からメッセージをプルして画像を処理し、Amazon Elastic File System (Amazon EFS) に配置します。EC2 インスタンスをスケールアウトするために、SNS メッセージ量の Amazon CloudWatch メトリクスを使用します。Amazon CloudFront を有効にし、オリジンが EC2 インスタンスの前の ALB になるように設定します。
C:
アップロードされた画像を Amazon S3 バケットに保存し、Amazon Simple Queue Service (Amazon SQS) キューにメッセージを送信するように S3 バケットのイベント通知を設定します。Amazon EC2 インスタンスのフリートを作成して、SQS キューからメッセージを取得して画像を処理し、別の S3 バケットに配置します。EC2 インスタンスをスケールアウトするために、キューの深さの Amazon CloudWatch メトリクスを使用します。Amazon CloudFront を有効にし、オリジンを処理された画像を含む S3 バケットに設定します。
D:
アップロードされた画像を、Amazon EC2 スポットインスタンスのフリートにマウントされた共有 Amazon Elastic Block Store (Amazon EBS) ボリュームに保存します。アップロードされた各画像と処理済みかどうかの情報を含む Amazon DynamoDB のテーブルを作成します。Amazon EventBridge ルールを使用して EC2 インスタンスをスケールアウトします。Amazon CloudFront を有効にし、EC2 インスタンスのフリートの前にある Elastic Load Balancer を参照するようにオリジンを設定します。
◆ 問題文の要件の概要
- グローバルユーザーが画像を大量アップロード（最大1万人同時）
- 画像にテキスト加工を施し公開（処理が必要）
- 高スループット処理能力とスケーラビリティ
- グローバル配信（ウェブに公開）
◆ 正解の選択肢と解説
✅ C. S3 + SQS + EC2 + CloudWatch メトリクス + CloudFront
解説：
- Amazon S3：オブジェクトストレージとして大規模な同時アップロードに対応可能。自動スケーリングと高可用性を持つ。
- Amazon SQS：非同期で画像処理をバッファリング。EC2と疎結合し、処理レートの変動に耐える。
- EC2 Auto Scaling：CloudWatchのキュー深度メトリクスにより自動スケール。処理能力を自動調整。
- CloudFront：処理後の画像を世界中にキャッシュ配信し、低レイテンシ・高パフォーマンスを実現。
- この構成は、イベント駆動・フルスケーラブル・非同期処理・グローバル配信という本問の要件すべてを満たします。
◆ 不正解の選択肢の理由
❌ A:
- EFSはNFSベースでスループットに制限あり、10,000同時アップロードに耐えられない。
- CloudWatch Logsポーリングによる処理はリアルタイム性・スケーラビリティに欠ける。
- CloudFrontオリジンがEC2インスタンス1台だと可用性が低く、単一障害点になる。
❌ B:
- SNSはプッシュ型通知。EC2がメッセージを確実に受け取る方法がない（キューではない）。
- 処理対象をEFSに格納する構成もAと同様に高スループットに不向き。
- CloudFrontのオリジンにALB（動的コンテンツ）を設定するとキャッシュ効果が薄くコスト・遅延が増す。
❌ D:
- EBSの共有マウントやマルチライター運用は非推奨。性能と可用性に課題。
- スポットインスタンスは処理途中で中断されるリスクがあり、データ損失の懸念。
- EventBridgeは5分間隔のトリガーで即時スケールに不向き。
◆ SAP試験で押さえておくべきポイント
- Amazon S3 + SQS + EC2（Auto Scaling） はイベント駆動設計の代表例。疎結合・スケーラビリティに優れる。
- SNSは**通知用途（Push）**であり、EC2への直接通知やPullには不適。
- EFSはスループット制限がある共有ストレージ。大規模アップロードにはS3が適任。
- CloudWatchメトリクスに基づくAuto Scaling設計の理解が必要。
- CloudFrontは静的オリジン（S3など）との組み合わせがキャッシュ効率が高い。
次の問題も引き続きお送りください。SAP試験対策を丁寧にサポートします。
