Amazon DynamoDBテーブルでのオートスケーリングの設定について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。

今回は、Amazon DynamoDBテーブルがプロビジョンドキャパシティモードで稼働しており、需要に応じてオートスケーリングされていない状態について、そのリスクと対策を解説します。

ポリシーの説明

DynamoDB の Security Hub コントロール – AWS Security Hub

[DynamoDB.1] DynamoDB テーブルは、需要に応じて容量をオートスケーリングする必要があります

このコントロールは、Amazon DynamoDB テーブルが必要に応じて読み取りおよび書き込み容量をスケーリングできるかどうかをチェックします。テーブルで自動スケーリングが設定されたオンデマンドキャパシティモードまたはプロビジョンモードを使用しない場合、コントロールは失敗します。デフォルトでは、このコントロールは、特定のレベルの読み込みまたは書き込みキャパシティに関係なく、これらのモードのいずれかを設定するだけで済みます。必要に応じて、特定のレベルの読み込みおよび書き込みキャパシティ、またはターゲット使用率を必要とするカスタムパラメータ値を指定できます。

リスク

Amazon DynamoDBは、ミリ秒単位のパフォーマンスで任意の規模のワークロードを処理できる、フルマネージドのNoSQLデータベースサービスです。DynamoDBのキャパシティモードには「プロビジョンドキャパシティ」と「オンデマンド」の2種類があります。テーブルがプロビジョンドキャパシティモードで、かつ適切にオートスケーリングが設定されていない場合、以下のような重大な可用性、パフォーマンス、およびコストのリスクが発生します。

  • リクエストスロットリングによる可用性の低下: プロビジョンドキャパシティモードでは、事前に読み込みおよび書き込みキャパシティーユニット (RCU/WCU) を指定する必要があります。実際のトラフィックがプロビジョニングされたキャパシティを超えると、DynamoDBはリクエストをスロットリング(拒否)します。これにより、アプリケーションのエラー率が増加し、パフォーマンスが低下し、最終的に可用性が損なわれます。特に、トラフィックの予測が難しい場合や急なスパイクが発生した場合に顕著です。
  • 運用オーバーヘッドの増加: トラフィックパターンに合わせて手動でキャパシティを調整する必要があるため、運用チームの負担が増大します。これにより、深夜や週末の急なトラフィック変動に対応するために、人為的な介入やアラート対応が必要になり、運用コストとストレスが増加します。
  • パフォーマンス予測の困難さ: トラフィックの変動が大きい場合、プロビジョニングされたキャパシティでは安定したパフォーマンスを保証することが難しくなります。これにより、エンドユーザーエクスペリエンスが低下し、SLA(サービスレベル契約)を遵守できなくなる可能性があります。

対策

DynamoDBテーブルをオンデマンドキャパシティモードに設定することは、上記のすべてのリスクを効果的に軽減し、よりシンプルでコスト効率の高い運用を実現するための最適な対策です。

  • オートスケーリング: オンデマンドモードでは、DynamoDBがテーブルのトラフィック量に応じて自動的にキャパシティをスケールアップ・スケールダウンします。これにより、トラフィックの急増にも自動的に対応し、リクエストスロットリングを回避できます。
  • 予測不可能なワークロードへの最適化: ワークロードが予測不可能である、または急激なスパイクが頻繁に発生する場合に特に効果的です。例えば、新規アプリケーション、トラフィックの変動が大きいゲーム、プロモーションキャンペーンなどが挙げられます。
  • 従量課金モデル: オンデマンドモードでは、RCU/WCUを事前にプロビジョニングする必要がなく、実際に使用された読み込みおよび書き込みに対してのみ課金されます。これにより、コストが最適化され、アイドル時の無駄な支出がなくなります。
  • 運用オーバーヘッドの削減: 手動でのキャパシティ調整が不要になるため、運用チームの負担が大幅に軽減されます。キャパシティプランニングに費やす時間を削減し、より重要なタスクに集中できます。

修復方法

AWSコンソールでの修復手順

AWSコンソールを使用して、DynamoDBテーブルのキャパシティモードをオンデマンドに変更します。

  1. DynamoDBサービスへ移動: AWSコンソールにログインし、Amazon DynamoDB サービスを開きます。
  2. テーブルへ移動: 左側のナビゲーションペインで「ダッシュボード」の下にある「テーブル」を選択します。
  3. 対象のテーブルを選択: キャパシティモードを変更したいDynamoDBテーブルを選択します。
  4. キャパシティタブへ移動: テーブルの詳細ページで、「キャパシティ」タブをクリックします。
  5. キャパシティモードの変更:キャパシティモード」セクションを見つけ、「編集」をクリックします。
  6. オンデマンドモードの選択:
    • キャパシティモード」のラジオボタンで「オンデマンド」を選択します。(もしプロビジョンドモードだった場合、現在のRCU/WCUの設定が表示されますが、オンデマンドを選択するとこれらの設定は無視されます。)
  7. 変更を保存: 設定を確認し、「変更を保存」をクリックします。

これで、DynamoDBテーブルのキャパシティモードがオンデマンドに変更され、トラフィックに応じて自動的にスケールするようになります。変更の適用には数分かかる場合があります。

Terraformでの修復手順

TerraformでDynamoDBテーブルのキャパシティモードをオンデマンドに変更するには、aws_dynamodb_table リソースの billing_mode"PAY_PER_REQUEST" に設定します。

# (例) オンデマンドキャパシティモードのDynamoDBテーブル
resource "aws_dynamodb_table" "my_ondemand_table" {
  name             = "my-ondemand-table"
  hash_key         = "id"
  # range_key      = "timestamp" # 範囲キーが必要な場合

  # オンデマンドキャパシティモードを設定
  # これにより、プロビジョンドキャパシティ (read_capacity, write_capacity) の指定は不要になります。
  billing_mode = "PAY_PER_REQUEST"

  attribute {
    name = "id"
    type = "S" # String型
  }

  # 範囲キーがある場合は、ここに追加
  /*
  attribute {
    name = "timestamp"
    type = "N" # Number型
  }
  */

  tags = {
    Environment = "Production"
    ManagedBy   = "Terraform"
  }

  # グローバルセカンダリインデックス (GSI) やローカルセカンダリインデックス (LSI) がある場合も、
  # billing_modeはテーブル全体に適用されるため、別途設定は不要です。
  /*
  global_secondary_index {
    name            = "my-gsi"
    hash_key        = "gsi_partition_key"
    range_key       = "gsi_sort_key"
    projection_type = "ALL"
  }
  */
}

上記のTerraformコードでは、aws_dynamodb_table リソース内の billing_mode = "PAY_PER_REQUEST" を設定することで、DynamoDBテーブルをオンデマンドキャパシティモードで作成または更新しています。

  • name: DynamoDBテーブルの名前を指定します。
  • hash_key: パーティションキーの名前を指定します。
  • billing_mode = "PAY_PER_REQUEST": これを設定するだけで、テーブルはオンデマンドキャパシティモードで動作します。

注意点:

  • 既存のプロビジョンドキャパシティのテーブルをTerraformで管理している場合、billing_mode"PAY_PER_REQUEST" に変更して terraform apply を実行することで、モードを切り替えることができます。
  • オンデマンドモードでは read_capacity および write_capacity パラメータは不要であり、Terraform構成から削除する必要があります。

my-ondemand-table などのプレースホルダーは、実際の環境に合わせて修正してください。

最後に

この記事では、DynamoDBテーブルをオンデマンドキャパシティモードに設定することの重要性について解説しました。オンデマンドモードは、予測不可能なワークロードや、運用上のオーバーヘッドを最小限に抑えたい場合に非常に強力な選択肢です。スロットリングのリスクを排除し、コスト効率を向上させながら、アプリケーションに最高のパフォーマンスと可用性を提供できます。 貴社のDynamoDBテーブルは、需要に応じてオートスケーリングされていますか?この機会にぜひ設定を確認・強化してみてください。 こちらの内容の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。運用が非常にラクに出来る製品になっていますのでぜひ興味がある方はお問い合わせお待ちしております。

最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

料金プランを詳しく見る