Amazon DynamoDBのキャパシティモードには、オンデマンドモードとプロビジョニング済みモードの2種類があります。どちらを選択するかによってコストが大きく変わるため、ユースケースに応じた適切な選択が重要です。

オンデマンドモードの概要として、トラフィックに応じて自動的にスケールするモードです。事前にキャパシティを設定する必要がなく、実際のリクエスト数に基づいて課金されます。料金体系は読み取りリクエストユニット（RRU）と書き込みリクエストユニット（WRU）ごとの従量課金制です。

プロビジョニング済みモードの概要として、読み取りキャパシティユニット（RCU）と書き込みキャパシティユニット（WCU）を事前に設定するモードです。設定したキャパシティに対して時間単位で課金されます。Auto Scalingと組み合わせることで、トラフィックの変動に自動対応できます。

コスト比較として、東京リージョンの料金（2024年時点）でオンデマンドモードは読み取り1億リクエストあたり約$12.5、書き込み1億リクエストあたり約$62.5です。プロビジョニング済みモードはRCU 1時間あたり$0.00013、WCU 1時間あたり$0.00065（100RCU/月あたり約$0.00936）です。

オンデマンドが有利なケースとして、トラフィックが予測不能または大きく変動するアプリケーション、開発・テスト環境でのコスト最小化、新規サービスでトラフィックが未知数の場合が挙げられます。

プロビジョニング済みが有利なケースとして、トラフィックが安定していて予測可能なアプリケーション、高トラフィックで継続的なアクセスがある本番環境、コスト最適化が重要なバッチ処理システムが挙げられます。一般的に、トラフィックが安定している場合はプロビジョニング済みモードの方が大幅にコスト効率が高くなります。

具体的なコスト計算例として、1日100万回の読み取りと10万回の書き込みが安定して発生するケースを考えます。オンデマンドモードの月額コストは読み取り30億リクエスト×$12.5/1億=$375、書き込み3億リクエスト×$62.5/1億=$187.5で合計$562.5程度です。プロビジョニング済みモードで適切なRCU/WCUを設定した場合、同等のワークロードで$100〜$150程度に抑えられることが多く、大きなコスト差が生じます。

DynamoDB Accelerator（DAX）との組み合わせについて、読み取りが多いワークロードではDAX（インメモリキャッシュ）を活用することでDynamoDBへの読み取りリクエストを大幅に削減でき、コストとレイテンシの両方を改善できます。

切り替えのタイミングとして、新規プロジェクトではオンデマンドモードから始めて実際のトラフィックパターンを把握し、安定してきたらプロビジョニング済みモードに切り替えることがコスト最適化の定石です。AWSコンソールからはいつでもモードを切り替えられますが、切り替え後24時間はオンデマンドに戻せない制約があります。

AWS Well-Architectedフレームワークのコスト最適化の観点から、DynamoDBのキャパシティ設定は定期的にCloudWatchメトリクスで確認し、実際の使用量と設定値の乖離を監視することが推奨されます。AWS Cost Explorerを使ってDynamoDBのコスト傾向を把握し、最適なモードを継続的に評価することが重要です。

DynamoDBのグローバルテーブルについて、複数リージョンにわたるグローバルテーブルを使用する場合、オンデマンドモードとプロビジョニング済みモードの両方でリプリケーション書き込みの追加コストが発生します。グローバルテーブルのコスト計算は単一リージョンより複雑になるため、AWS公式の料金計算ツールで事前に試算することをお勧めします。

DynamoDB Streamsとコスト最適化の関係として、変更データキャプチャ機能であるDynamoDB Streamsを有効にすると、読み取りリクエストユニットの追加コストが発生します。Lambda関数とのイベント駆動連携に活用される機能ですが、コスト試算に含めることを忘れないようにしてください。

オンデマンドモードの注意点として、急激なトラフィック増加があっても自動でスケールしますが、直前の最大スループットの2倍を超えるスパイクが発生した場合、一時的にスロットリングが生じる可能性があります。高トラフィックスパイクが予測できる場合（セール、キャンペーン等）は、事前にキャパシティ設定を見直すことが推奨されます。

プロビジョニング済みモードのAuto Scaling設定について、最小・最大のRCU/WCUとターゲット使用率（推奨70%）を設定します。スケールアップは数分で完了しますが、スケールダウンには最大4時間かかる場合があります。急激なトラフィック減少後も一定時間は高いキャパシティコストが発生することを認識しておいてください。

AWS試験でのDynamoDB問題対策として、SAA-C03やDVA-C02では「コスト最適化」「スケーラビリティ」「一貫性（結果整合性 vs 強整合性読み取り）」の観点からDynamoDBの問題が出題されます。オンデマンドとプロビジョニング済みの使い分けは試験頻出テーマです。グローバルセカンダリインデックス（GSI）とローカルセカンダリインデックス（LSI）のコストと制限の違いも合わせて理解しておくことをお勧めします。

DynamoDBのパーティションキー設計とコストの関係について、適切なパーティションキーを設計することでホットパーティション問題を回避し、コストを最適化できます。カーディナリティの高いカラム（UUIDなど）をパーティションキーに使用することで、データが均等に分散されます。偏ったアクセスパターンが予想される場合は、パーティションキーにランダムな接尾辞を付ける「シャーディング」テクニックも有効です。

DynamoDB TransactionsとCondition Writesについて、TransactWriteItemsを使った複数テーブルのトランザクション処理は、追加のコストが発生します（通常の書き込みの2倍のWCU）。Condition Writesを活用して楽観的ロックを実装することで、追加コストを抑えながらデータ整合性を確保できます。アプリケーションの要件に応じた適切なトランザクション戦略を選択することがコスト最適化につながります。

DynamoDB TTL（Time To Live）機能について、TTLを使って期限切れデータを自動削除することで、ストレージコストを削減できます。TTL削除は追加コストなしで実行され、24時間以内に期限切れアイテムが削除されます。セッションデータ・ログデータ・一時的なキャッシュデータなど、有効期限があるデータの管理にTTLを活用することで、データ量の増加に伴うコスト増を抑えられます。

まとめとして、DynamoDBのオンデマンドモードとプロビジョニング済みモードの選択は、アプリケーションのトラフィックパターンとコスト要件に応じて慎重に判断することが重要です。新規開発時はオンデマンドで始め、本番運用が安定したらプロビジョニング済みモードへの移行を検討することが多くのケースで最適な戦略です。