運用とコスト

モデリングはデータをテーブルに置く。運用する — 一貫した書き込み、変更フィード、 期限切れ、キャパシティ請求、マルチリージョン生存、復旧 — ことが、本番で DynamoDB を信頼するか、午前 2 時にスロットルしたデータベースとして扱うかを決める。

このセクションは 1 つの稼働シナリオを歩く。マルチテナント SaaS の監査ログ — 企業の買い手が求める不変の「誰が何をいつしたか」記録。テナントごとに パーティション化された 1 テーブル:

各ガイドはこの同じテーブルに 1 つの運用上の関心事を足す。

読み終えたらできること

• オールオアナッシングの書き込みが重要なところでトランザクションを使い、AWS が返す キャンセル理由を知っている。
• 夜間の削除ジョブなしに追加専用の監査保持のため DynamoDB Streams と TTL を配線できる。
• オンデマンド対プロビジョンドキャパシティを選び、小さなアイテムを膨らませる 切り上げルールを読める。
• 現実的な RPO/RTO 期待でグローバルテーブルと PITR 復旧を計画できる。

読む順番

1. コストモデルと SQL スキャン — 監査テーブルを運用する前に、スキャン形の読み取りが請求にどう出るか。
2. トランザクション — 対になった監査 + 残高 更新のための TransactWriteItems。冪等性トークン。
3. Streams — テーブルをポールせずに監査イベントを SIEM やウェアハウスへ送るストリームコンシューマ。
4. TTL — 古い EVENT# 行を自動期限切れ。TTL 属性上の epoch 秒。
5. オンデマンド対プロビジョンド — リクエストあたり課金対予約キャパシティ。バーストする監査トラフィックで どちらが勝つか。
6. オートスケーリング — プロビジョンドモードの スケーリングポリシー。
7. スロットリング — ProvisionedThroughputExceededException とスパイク下のオンデマンド適応スロットリング。
8. テーブルサイズとアイテム数 — AWS が報告するもの対テーブルの概要がローカルで見積もるもの。
9. グローバルテーブル — 監査ログ向けの マルチリージョン複製。書き込み衝突とリーダーエンドポイント。
10. バックアップと PITR — 継続バックアップと ポイントインタイム復元ウィンドウ。

オンデマンドの書き込みリクエストユニットは 1 KB ごとに切り上げる。1.1 KB の監査 イベントは書き込みあたり 2 WRU を請求し、1 ではない — capacityUnits はキロバイト 境界で切り上げる。us-east-1 オンデマンドで毎秒 100 の持続する 1 KB 書き込みなら、 書き込みだけで GSI やストリームの前に月あたり約 $164.25。 料金計算機 がテナント数とイベントレートを 見積もる。

TTL 削除はキャパシティ面では無料だが非同期。直ちに証明しなければならない コンプライアンス保持のためのリアルタイム削除機構として TTL を使わない。

DynoTable で見る

DynoTable をダウンロードし、読み進めながら監査テーブルを調べる。 テーブルの概要はキー構造、GSI、サイズ／アイテム見積もりを示す。 TTL コンバーター はカレンダー日付を TTL 属性向けの epoch 秒に変える — TTL はミリ秒ではなく秒を期待する。

DynoTable は存在すればバックアップ／PITR 設定を読むが設定はしない。コントロール プレーンの変更は AWS コンソールまたは IaC に留まる。ストリーム作成やキャパシティ モード切替も同じ — アプリはデータプレーン中心だ。

スパイクするセキュリティフィードにオンデマンドを選ぶ前に、料金計算機で失敗ログイン 書き込みのバースト対定常監査追記を見積もろう。