メディアストリーミングスタートアップが2年の成長を経てサーバーレスAPIの月次コストが急増しています。 アーキテクチャ構成：API Gateway REST API（30エンドポイント）→ Lambda（100以上の関数）→ DynamoDB（8テーブル） 月次コスト内訳：Lambda 21万円、DynamoDB 42万円（プロビジョンドキャパシティ）、API Gateway REST 9万円 DynamoDB分析：8テーブルのうち6テーブルは平均RCU/WCU使用率が15%未満で、残り2テーブルは予測不能なトラフィックスパイクが発生します。 Lambda：全関数に1GBメモリを割り当てていますが、AWS Compute Optimizerは平均メモリ使用率35〜40%を報告しています。全Lambda呼び出しの85%は日中継続的に安定して発生します。 API Gateway：30エンドポイントのうちAPIキー・使用量プラン・リクエストバリデーションモデルなどのREST固有機能は使用していません。 最もコスト削減効果の高い改善策はどれですか？
DynamoDBコスト最適化には8テーブル全体の特性を正確に判断する必要があります。6テーブルは平均使用率15%未満（大幅な過剰プロビジョニング状態）であり、オンデマンドモードが圧倒的に安価です。予測不能なスパイクが発生する2テーブルに対してDynamoDBオートスケーリングは適切ではありません。オートスケーリングの容量増加には最大15分かかるため、突発的スパイク時にスロットリングが発生するリスクがあります。オンデマンドモードは即時スケールアップが保証されるため予測不能スパイクにも安全に対応でき、全8テーブルをオンデマンドに統一する判断が最適です。 LambdaのRight-sizingを先に実施してメモリ量を削減したうえでSavings Plansを購入することが重要です。削減後のベースコストに割引を適用することでコミット量を最小化しながら最大の削減効果を得られます。HTTP API GatewayはREST APIと比較して約70%安価であり、REST固有機能を使用していない30エンドポイントはすべて移行対象となります。 選択肢Aの予測不能スパイクのある2テーブルへのオートスケーリング設定は最大15分の反応遅延があり、スロットリングリスクが残るため不適切です。 選択肢CのDynamoDB予約済みキャパシティは現行プロビジョン量で1年コミットするため使用率15%未満のテーブルで大幅なコスト無駄が生じます。Lambda Provisioned ConcurrencyはコールドスタートのないWarm状態維持のためのパフォーマンス施策であり、コスト増加要因のためコスト最適化目標と相反します。 選択肢DのDynamoDB DAXはキャッシュクラスター自体の運用コストが発生するため読み取りキャパシティ削減分を相殺する可能性があります。Right-sizingなしでの3年Savings Plansコミットは過剰なコミットになるリスクが高くスタートアップには不適切です。