AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. Amazon DynamoDB にセンサーイベントを直接書き込み、必要に応じて全件スキャンして異常を集計する

Amazon DynamoDB は高スループットな書き込みには耐えられますが、異常検知のたびに全件スキャンするのは実質的なバッチ処理であり、即時アラートの要件を満たしません。
テーブルの全件スキャンはデータ量に比例して読み込みコストとレイテンシが増えるため、毎秒数千件が積み上がる用途では現実的ではありません。
ストリームとして「到着順に複数の処理系統へ配信する」役割も担えず、この構成では設計の土台が変わってしまいます。

正解

B. Amazon Kinesis Data Streams でセンサーとカメラからのイベントを取り込み、複数のコンシューマーに順序を保ったまま配信する

Amazon Kinesis Data Streams は、大量のイベントを継続的に取り込むストリーミングデータの基盤です。
データはパーティションキーごとにシャードへ振り分けられ、シャード内では到着順序が保持されるため、センサーの時系列を崩さずに処理できます。
さらに同じストリームを複数のコンシューマーが独立して読めるため、異常検知用と長期保存用といった別々の処理系統へ同時に配信でき、スループットはシャード数で調整できます。この問題の4条件をすべて満たす唯一の選択肢です。

C. Amazon SQS の標準キューにイベントをためておき、5分間隔で起動するバッチジョブがまとめて取り出して処理する

Amazon SQS の標準キューは順序が保証されず（ベストエフォート順）、センサーの時系列を前提とした異常検知には向きません。
また、1つのメッセージは基本的に受信した1つのコンシューマーが処理して削除するモデルであり、複数の処理系統へ同じデータを同時配信する用途にはそのまま使えません。
加えて「5分間隔のバッチ起動」は、即座にアラートを発報したいという要件と真っ向から矛盾します。

D. Amazon S3 に一定時間ごとにセンサーデータをアップロードし、Amazon Athena でバッチ集計してから生成AIアプリケーションに渡す

Amazon S3 に一定時間ごとにアップロードして Amazon Athena で集計する構成は、典型的なバッチ分析パイプラインです。
データが S3 に置かれるまでのタイムラグとクエリ実行時間が加わるため、破損兆候を検知して即座にアラートを出すというリアルタイム要件を満たせません。
長期保存や事後分析の系統としては有効ですが、取り込み層そのものの答えにはなりません。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
毎秒数千件のイベントを継続的に取り込む	シャードを増やしてスループットを線形にスケールできるストリーミング基盤が必要 →選択肢（B）が正解
到着順序を保ったまま処理したい	SQS 標準キューは順序を保証しない。ストリームはシャード内で順序が保たれる →選択肢（C）を消す
異常検知用と長期保存用など複数の処理系統へ同時配信	同一ストリームを複数コンシューマーが独立して読めるのがストリームの特性。キューは1メッセージを1コンシューマーが取り切る →選択肢（B）が正解
異常を検知したら即座にアラートを発報する	5分間隔のバッチやS3 へ一定時間ごとにアップロードして Athena で集計する構成は、その時点でリアルタイム要件から外れる →選択肢（C・D）を消す
生成 AI アプリケーションへ継続的に取り込む	全件スキャン前提の DynamoDB 直書きは、取り込み層としても検知処理としても成立しない →選択肢（A）を消す

ひっかけポイント

• 「たまったデータを処理する」系の選択肢（C の5分間隔バッチ、D の Athena 集計）は、要件に「即座にアラート」と書かれた時点で全滅する。まずこの軸で2つ落とせる
• SQS はスケーラブルで手軽なため選びたくなるが、標準キューは順序保証なし。順序が要件に出てきたら、標準キューは真っ先に外す
• 「複数の処理系統へ同時に配信」はキューとストリームを分ける決定打。キューは取り出したら消えるのに対し、ストリームは保持期間中に複数のコンシューマーが何度でも読める
• DynamoDB は書き込み性能だけ見ると成立しそうに見えるが、全件スキャンで異常を集計するという後半でリアルタイム性もコスト効率も崩れる

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「取り込んだデータをAmazon S3 へそのまま集約したいだけで、独自のリアルタイム処理は不要」	Amazon Data Firehose（旧 Kinesis Data Firehose）によるマネージド配信が正解軸に。
「厳密な順序と重複排除が必要だが、コンシューマーは1系統だけ」	SQS FIFO キューが候補に浮上する。
「取り込んだイベントを複数の異なるサービスへイベント駆動でルーティングしたい」	Amazon EventBridge によるルールベースの配信が正解軸に。
「既存の Apache Kafka 資産をそのまま移行したい」	Amazon MSK が正解に。API 互換性が判断軸になる。
「1日1回のバッチで過去データを集計してレポートしたい」	S3 + Athena（＋Glue）の構成が正解に転じる。

関連サービスの解説

Amazon Bedrock
Amazon Kinesis