AWS認定資格 WEB問題集＆徹底解説
ソリューションアーキテクト-プロフェッショナル
問題文と選択肢
- Amazon SQS を使用してジョブメッセージを配信し、Amazon CloudWatch アラームを使用してアイドル状態になった Amazon EC2 ワーカーインスタンスを終了します。データ処理後、S3 オブジェクトのストレージクラスを S3 Standard-IA に移行します。
- スポットインスタンスを使用し、Amazon SQS でメッセージを処理する Auto Scaling グループをキューの深さに基づいてスケールするように設定します。データ処理後、S3 オブジェクトのストレージクラスを S3 Standard-IA に移行します。
- スポットインスタンスを使用し、Amazon SQS でメッセージを処理する Auto Scaling グループをキューの深さに基づいてスケールするように設定します。データ処理後、S3 オブジェクトのストレージクラスを S3 Glacier に移行します。
- Amazon SNS を使用してジョブメッセージを配信し、Amazon CloudWatch アラームを使用してアイドル状態になったスポットインスタンスを終了します。データ処理後、S3 オブジェクトのストレージクラスを S3 Glacier に移行します。
A. Amazon SQS を使用してジョブメッセージを配信し、Amazon CloudWatch アラームを使用してアイドル状態になった Amazon EC2 ワーカーインスタンスを終了します。データ処理後、S3 オブジェクトのストレージクラスを S3 Standard-IA に移行します。
Amazon SQS でジョブを配信する点は正しいが、2 つの弱点がある。まず処理後の保存先が S3 Standard-IA で、これは「たまにアクセスする低頻度アクセスデータ」向けのクラス。テープでのオフサイト長期保管の代替としてはコストが高すぎる（アーカイブ要件に対して最適ではない）。
さらに、CloudWatch アラームでアイドルインスタンスを終了する方式は、キュー深度に応じた自動スケールアウトが無く、オンデマンド EC2 のままなのでコスト最小化の要件も満たさない。
B. スポットインスタンスを使用し、Amazon SQS でメッセージを処理する Auto Scaling グループをキューの深さに基づいてスケールするように設定します。データ処理後、S3 オブジェクトのストレージクラスを S3 Standard-IA に移行します。
スポットインスタンス＋キュー深度ベースの Auto Scaling というコンピューティング側の設計は正解 C と同じで妥当。しかしアーカイブ先が S3 Standard-IA である点が要件に反する。
問題文は「テープに記録してオフサイト保管していた」＝めったに取り出さない長期保管であり、かつ「AWS のアーカイブストレージを活用してコストを最小化」と明示している。ここで選ぶべきは Standard-IA ではなく S3 Glacier。C との違いはこの 1 点だけで、まさに読み飛ばしを狙った選択肢。
C. スポットインスタンスを使用し、Amazon SQS でメッセージを処理する Auto Scaling グループをキューの深さに基づいてスケールするように設定します。データ処理後、S3 オブジェクトのストレージクラスを S3 Glacier に移行します。
3 つの要件すべてを満たす唯一の選択肢。
Amazon SQS は「ワーカーがキューからジョブをプルして処理する」という RabbitMQ と同じアーキテクチャパターンをマネージドサービスで再現でき、既存パターンの維持という指示に合致する。
キューの深さ（ApproximateNumberOfMessagesVisible）に基づく Auto Scaling により、未処理ジョブが多いときだけワーカーを増やし、空になれば縮退できる。ワーカーをスポットインスタンスにすれば、中断耐性のあるバッチ処理としてコンピューティングコストを大幅に削減できる（SQS の可視性タイムアウトにより、中断されたジョブはメッセージがキューへ戻り再処理される）。
処理後のデータは S3 Glacier へ移行することで、テープのオフサイト保管に相当する低コストな長期アーカイブを実現できる。
D. Amazon SNS を使用してジョブメッセージを配信し、Amazon CloudWatch アラームを使用してアイドル状態になったスポットインスタンスを終了します。データ処理後、S3 オブジェクトのストレージクラスを S3 Glacier に移行します。
Amazon SNS はプッシュ型の Pub/Sub 通知サービスであり、メッセージを保持してワーカーが取りに来るのを待つキューではない。ワーカーがダウンしていればジョブは失われ、RabbitMQ で実現していた「キューからプルして処理する」パターンを再現できない。
また、CloudWatch アラームでアイドル状態のインスタンスを終了するだけでは負荷に応じてスケールアウトする仕組みが無い。S3 Glacier への移行だけは正しいが、メッセージングの選定を誤っているため不適。
RabbitMQ → Amazon SQS、テープ → S3 Glacier、コスト最小 → スポット＋キュー深度スケール。3 点セットで覚える。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| RabbitMQ でジョブ情報をサーバーに配信していた（既存パターンの維持） | ワーカーがキューからプルする方式。マネージドの等価物は Amazon SQS。SNS はプッシュ型で代替にならない →選択肢（D）を消す |
| 処理完了後、テープでオフサイト長期保管していた | 取り出し頻度が極めて低い長期保管＝S3 Glacier。S3 Standard-IA は「低頻度アクセス」であってアーカイブ用ではない →選択肢（A・B）を消す |
| コストを最小限に抑える | 中断耐性のあるバッチ処理はスポットインスタンスで大幅に安くなる。CloudWatch アラームでの手動的な終了管理では不十分 →選択肢（C）が正解 |
| 大量データを処理する（負荷が変動する） | キューの深さに基づく Auto Scaling なら、未処理ジョブ数に比例してワーカーを増減でき、無駄な稼働が出ない →選択肢（C）が正解 |
ひっかけポイント
- B と C の違いは末尾の「S3 Standard-IA」か「S3 Glacier」か だけ。前半のスポット＋キュー深度スケールが正しいので、そこで安心して B を選ばせる作り
- S3 Standard-IA は「アーカイブ」ではない。ミリ秒で取り出せる代わりに保管単価が高い。「テープの代替」と書かれたら Glacier 系を選ぶ
- 選択肢 A・D の「CloudWatch アラームでアイドルインスタンスを終了」は一見コスト削減に見えるが、スケールアウト側の仕組みが無い。Auto Scaling による増減とは別物
- SQS と SNS の取り違えは頻出。「ワーカーがジョブを取得して処理する」＝プル型＝SQS、「複数の宛先に一斉通知」＝プッシュ型＝SNS
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「アーカイブしたデータを数分〜数時間以内に取り出す必要がある」 | S3 Glacier Flexible Retrieval（迅速/標準取り出し）が妥当。数ミリ秒が必要なら S3 Glacier Instant Retrieval に。 |
| 「10 年以上保管し、取り出しは 12 時間かかってもよい・とにかく最安で」 | S3 Glacier Deep Archive が正解軸に。 |
| 「アクセスパターンが読めない／変動するデータを自動で最適なクラスに置きたい」 | S3 Intelligent-Tiering が正解に（手動のライフサイクル移行より有利）。 |
| 「RabbitMQ / AMQP のプロトコルをそのまま使い続けたい（アプリを書き換えたくない）」 | Amazon MQ が正解軸に。SQS はプロトコル互換ではない点に注意。 |
| 「ジョブは厳密な順序どおり・重複なしで処理する必要がある」 | SQS FIFO キューが正解に（スループット上限とのトレードオフ）。 |
- Amazon SQS を使用してジョブメッセージを配信し、Amazon CloudWatch アラームを使用してアイドル状態になった Amazon EC2 ワーカーインスタンスを終了します。データ処理後、S3 オブジェクトのストレージクラスを S3 Standard-IA に移行します。
- スポットインスタンスを使用し、Amazon SQS でメッセージを処理する Auto Scaling グループをキューの深さに基づいてスケールするように設定します。データ処理後、S3 オブジェクトのストレージクラスを S3 Standard-IA に移行します。
- スポットインスタンスを使用し、Amazon SQS でメッセージを処理する Auto Scaling グループをキューの深さに基づいてスケールするように設定します。データ処理後、S3 オブジェクトのストレージクラスを S3 Glacier に移行します。
- Amazon SNS を使用してジョブメッセージを配信し、Amazon CloudWatch アラームを使用してアイドル状態になったスポットインスタンスを終了します。データ処理後、S3 オブジェクトのストレージクラスを S3 Glacier に移行します。