LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

DynamoDBのコスト構造：読み書きキャパシティ・ストレージ・オプション費用

DynamoDBのコスト最適化とは、読み書きキャパシティの課金方式（オンデマンドまたはプロビジョンド）・ストレージ使用量・バックアップやデータ転送などのオプション費用を体系的に把握し、ワークロードに合った設定に切り替えていく取り組みを指します。

DynamoDBの課金体系はAWS公式ドキュメントに基づき3つの区分で整理できます^*1。第1区分はキャパシティ（読み書きリクエスト）で、オンデマンドモードではRRU（Read Request Unit）/WRU（Write Request Unit）単位の従量課金、プロビジョンドモードではRCU（Read Capacity Unit）/WCU（Write Capacity Unit）を事前予約する方式です。

第2区分はストレージで、テーブルに保存されているデータ量をGBあたりの月額料金で課金します。グローバルセカンダリインデックス（GSI）は独立したテーブルと同等のストレージを消費するため、インデックス数が増えると比例してストレージ費用が増加します。

第3区分はオプション費用です。ポイントインタイムリカバリ（PITR）有効化・オンデマンドバックアップ・DynamoDB Accelerator（DAX）・DynamoDB Streamsなど、機能を有効にするごとに追加費用が発生します。コスト最適化の第一歩は、これら3区分を現在のAWSコスト管理ツール（Cost Explorer）で分解し、どの区分が支出の大半を占めているかを把握することです。

オンデマンドとプロビジョンドの使い分け：トラフィックパターン別の選定基準

DynamoDBはテーブルごとにキャパシティモードを選択でき、オンデマンドとプロビジョンドの2種類があります。AWS公式によると、両モードはワークロードの特性に応じて選択することが推奨されており、24時間以内に1回限りモードを切り替えることも可能です^*1。

オンデマンドモードが向いているケース

オンデマンドモードは、事前にキャパシティを指定せずにリクエスト単位で課金されます。AWS公式によると、トラフィックが予測不能またはバースト的なワークロードや、新しいテーブルで利用量が不明な段階に適しています^*1。

具体的には、リリース直後のアプリケーション・キャンペーン時に急増するECサイトのカートデータ・開発・ステージング環境など、負荷の見通しが立てにくいケースで有用です。キャパシティ管理の手間がなくなる半面、常時高スループットが続く場合はプロビジョンドより割高になる場合があります。

プロビジョンドモードが向いているケース

プロビジョンドモードは、読み書きキャパシティを事前に指定して予約します。AWS公式によると、安定したトラフィックパターンのワークロードに適しており、オンデマンドと比べてリクエスト単価を抑えやすい特徴があります^*1。

業務システムのバックエンドDB・定期バッチ処理・夜間レポート生成など、1日を通じてアクセス量が大きく変動しないケースが代表的な適用場面です。プロビジョンドモードを選択した場合も、後述のAuto Scalingを組み合わせることで変動するトラフィックに対応できます。

どちらのモードがコスト面で有利かは、実際のリクエスト量とその変動パターン次第です。AWSが提供するコスト試算ツール（Pricing Calculator）や、過去1〜4週間のCloudWatchメトリクスからトラフィックを分析してから両モードを比較試算することが、選定の根拠になります。

Auto Scalingとリザーブドキャパシティ：事例削減目安とターゲット使用率の設計

プロビジョンドモードを選択した場合、Application Auto Scalingを有効にすることで、実際のトラフィックに応じてRCU/WCUが自動で増減し、未使用キャパシティへの支払いを抑えられます。

Auto Scalingの仕組みとターゲット使用率

DynamoDB Auto Scalingは、Application Auto Scalingサービスを通じてCloudWatchのメトリクスを監視し、設定したターゲット使用率（ProvisionedReadCapacityUtilization / ProvisionedWriteCapacityUtilization）に対してキャパシティを増減します^*2。

AWS公式ベストプラクティスでは、ターゲット使用率は70%から始めることが推奨されています^*2。使用率を高く設定しすぎると、急なトラフィック増加時にスロットリング（ProvisionedThroughputExceededException）が発生するリスクがあります。安定したワークロードでは70〜80%程度を目安とし、変動が大きい場合はより低い値を設定することが実務上の選択肢となります。

AWS公式が示すスケーリングのベストプラクティス事例では、Auto Scalingの適用によって約30.8%のコスト削減が見込まれた例が示されています^*2。これはAWSが公表した事例値・目安であり、実際の削減幅はワークロードのパターンや設定によって異なります。

リザーブドキャパシティとの組み合わせ

リザーブドキャパシティは、1年または3年のコミットにより、プロビジョンドモードのキャパシティコストを割引購入できる仕組みです。Auto Scalingで変動分をカバーしながら、ベースライン需要に相当するキャパシティをリザーブドキャパシティで調達することで、割引効果を組み合わせられます。

AWS公式が示す事例では、Auto Scaling適用に加えてリザーブドキャパシティを1年コミットで購入した場合、約55.1%のコスト削減効果が見込まれた例が示されています^*2。これもAWSが公表した事例値・目安です。

リザーブドキャパシティは購入後に取り消しができないため、最低でも4〜8週間のCloudWatchメトリクスでベースライン需要を確認してから購入することをおすすめします。需要が確認できない段階での先行購入は、未使用キャパシティの固定費化につながります。

TTL・インデックス・バックアップ：追加コスト最適化の手順と効果

キャパシティモードの見直しに加え、ストレージ・インデックス・バックアップの設定を最適化することで、さらにコストを抑えられます。

TTL（Time to Live）による不要データの自動削除

TTL（Time to Live）は、DynamoDBアイテムに有効期限を設定し、期限が過ぎたアイテムをバックグラウンドで自動削除する機能です。AWS公式によると、TTL削除はキャパシティユニットを消費せずに実行されます^*1。

セッション情報・ログデータ・一時キャッシュ・通知履歴など、保持期間が決まっているデータへの適用が代表的なユースケースです。TTLを有効にするだけではすぐにストレージが削減されるわけではなく、期限切れアイテムの削除はバックグラウンドで非同期に処理されます。TTL削除後にPITRやバックアップのサイズが縮小するかを定期的に確認し、効果を把握することをおすすめします。

グローバルセカンダリインデックス（GSI）の整理

グローバルセカンダリインデックス（GSI）は、テーブルと独立してキャパシティとストレージが発生します。使用されていないGSIや、クエリパターンが重複しているGSIは、削除することでキャパシティ・ストレージ双方のコストを削減できます。

GSIの削除には、そのインデックスを利用しているアプリケーション側のクエリ変更が伴うため、事前にCloudWatchのConsumedReadCapacityUnitsメトリクスで各GSIの利用状況を確認してから対応することが重要です。利用量がゼロに近いGSIは整理候補です。

バックアップ・PITRの見直し

ポイントインタイムリカバリ（PITR）を有効にすると、保護対象テーブルのストレージ量に比例した追加費用が発生します。すべてのテーブルでPITRを有効にするのではなく、業務継続に不可欠なテーブルに限定することで、オプション費用を抑えられます。

オンデマンドバックアップ（手動取得）は保存容量に応じた費用が発生します。不要になったバックアップは定期的に削除し、保存コストを抑えることをおすすめします。PITR・オンデマンドバックアップの要否を、システムのRTO（目標復旧時間）・RPO（目標復旧時点）と照らし合わせながら設計することが重要です。

最適化の進め方と外注の使いどころ：試算・モード設計・運用委託の判断軸

DynamoDBのコスト最適化を実際に進めるには、現状分析・試算・設定変更・検証・継続監視という一連の工程が必要です。各工程で必要な専門知識と、外注が有効なケースを整理します。

内製で対応できる工程と必要なスキル

Cost ExplorerやCloudWatchのメトリクス確認は、AWSコンソールへのアクセス権があれば開始できます。ただし、キャパシティモードの試算比較には過去のReadCapacityUnitsProvisionedおよびWriteCapacityUnitsProvisioned・ConsumedReadCapacityUnits・ConsumedWriteCapacityUnitsの分析が必要です。

Auto Scalingの設定変更はコンソールまたはCloudFormation/Terraformから行えますが、ターゲット使用率の設計を誤ると本番環境でスロットリングが発生するリスクがあります。スロットリングはアプリケーションのエラー率増加に直結するため、変更前後の検証が不可欠です。

外注が有効な局面

以下の局面では、専門パートナーへの委託を検討することで、設定ミスによるサービス影響リスクを抑えられます。

• 複数テーブル・複数環境（本番・ステージング・開発）のキャパシティを横断的に分析・試算する場合
• Auto Scalingの設計・テスト・本番適用を短期間でリスクを抑えて完了させたい場合
• リザーブドキャパシティの購入タイミングと数量の判断を根拠を持って行いたい場合
• TTL設定・GSI整理にアプリケーション側のコード変更が伴い、影響範囲の把握に時間がかかる場合
• 継続的なコスト監視・アラート設定・月次レポートを運用として委託したい場合

委託範囲の明確化と契約形態

外注する際は委託範囲を事前に文書化することが重要です。分析・試算のみを依頼するのか、設計・実装・テストまで含めるのか、本番切り替えと事後モニタリングまで含めるのかを明確にします。

分析フェーズは成果物（現状分析レポート・試算比較表）が定義しやすいため準委任または請負どちらでも対応可能です。実装フェーズは変更範囲が固まってから請負を検討し、継続監視は準委任契約が適しています。

LやSSなどのAWSパートナー資格を持ち、DynamoDBの設計・運用実績がある委託先を選ぶことで、設定ミスによるサービス影響リスクを低減できます。選定時は過去の対応事例・担当エンジニアの経験・緊急時の対応フロー確認も実施してください。

まとめ：DynamoDBコスト最適化の3つの判断軸

本稿では、DynamoDBのコスト構造の把握からキャパシティモード選定・Auto Scalingとリザーブドキャパシティによるコスト削減・TTL/GSI/バックアップの追加施策・外注の使いどころまでを整理しました。要点を3つに集約すると次の通りです。

第一に、コスト最適化の起点はキャパシティモードの選定です。オンデマンドはバースト的・予測不能なワークロードに、プロビジョンドは安定・予測可能なワークロードに向いており、AWSが提供する試算ツールとCloudWatchメトリクスで両モードを比較してから判断することが重要です。

第二に、プロビジョンドモードにはAuto Scalingとリザーブドキャパシティをセットで設計することで、AWS公表の事例値を参考にした削減効果が見込まれます。ターゲット使用率の設計を誤るとスロットリングが発生するため、変更前後の検証が不可欠です。

第三に、ストレージ・オプション費用の見直しは地道ながら確実な施策です。TTLによる不要データ削除・未使用GSIの整理・PITRの適用範囲最適化を組み合わせることで、追加コストを継続的に抑えられます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「Read/write capacity mode」（Amazon DynamoDB Developer Guide、AWS公式ドキュメント）
2. *2　出典：AWS「Best practices for DynamoDB provisioned capacity and Auto Scaling」（Amazon DynamoDB Developer Guide、AWS公式ドキュメント）

Tweet