大手 EC サイトがリアルタイムの顧客クリックストリームデータおよび注文イベントを処理するパイプラインを AWS 上で運用しています。現在のアーキテクチャは以下の通りです。 ・Amazon Kinesis Data Streams: 60 シャード（プロビジョニングモード） — 平均シャード使用率: 22%（フラッシュセール時ピーク使用率: 85%、1日3時間のみ） ・AWS Lambda（Kinesis コンシューマー）: — バッチサイズ: 200、並列化係数（Parallelization Factor）: 1 — Lambda 平均実行時間: 800ms、メモリ: 512MB — コールドスタート発生率: 28%（平均 10,000 回/時間、ピーク 45,000 回/時間） ・Amazon DynamoDB（オンデマンドキャパシティ）: — レコメンデーション状態データを保持 — 同一プロダクト ID に対する GetItem 呼び出しの 55% が 2 分以内に重複発生 ・Amazon S3 + Amazon Athena: データサイエンスチームのアドホック分析用 月次コスト内訳: ・Kinesis Data Streams: $9,800 ・Lambda: $14,200 ・DynamoDB: $6,200 ・合計: 約 $30,200 目標: スループットの低下および p99（99 パーセンタイル）レイテンシ 2 秒超過なしに、月次コストを 35% 以上削減する（削減目標: 約 $10,570）。 コスト削減効果が最大で、かつ要件を満たす変更はどれですか？2 つ選択してください。
平均シャード使用率が22%（78%が未使用）のプロビジョニングモードをオンデマンドモードに切り替えることで、実際のスループットに比例したコストに変換されます。ピーク時の85%使用率も自動スケールで対応でき、$9,800のKinesisコストから大幅な削減が見込めます。 正解：B. DynamoDB の前段に Amazon ElastiCache for Redis（クラスターモード無効、cache.r6g.large）をルックアサイドキャッシュとして追加し、TTL（Time to Live：データ有効期間）を 3 分に設定する。2 分以内の重複 GetItem 呼び出し 55% をキャッシュヒットに変換し、DynamoDB の読み取りキャパシティ消費を約 50〜55% 削減する。 DynamoDBの前段にAmazon ElastiCache for RedisをTTL（Time to Live：データ有効期間）3分のルックアサイドキャッシュとして追加することで、2分以内に重複発生するGetItem呼び出しの55%をキャッシュヒットに変換し、DynamoDBの読み取りキャパシティ消費を約50〜55%削減できます。 選択肢C のLambdaのバッチサイズを200から10に削減すると、同じデータ量を処理するためのLambda呼び出し回数が最大20倍に増加しコスト増となります。 選択肢D のLambdaをEC2 Auto Scalingのカスタムアプリケーションに置き換えると、開発・テスト・運用の負荷が大幅に増大します。 選択肢E はプロビジョニングされた同時実行数（Provisioned Concurrency）はアイドル時も課金されるためLambdaコストが増加します。また30秒のバッチウィンドウを設定するとイベントが最大30秒待機してからバッチ処理されるため、p99（99パーセンタイル）レイテンシ要件である2秒以内を大幅に超過します。