Aurora DSQL コンソールと CloudWatch アラームで Amazon Aurora DSQL のコストをモニタリングする

本記事は 2026 年 10 月 13 日 に公開された「Monitor Amazon Aurora DSQL costs with the Aurora DSQL console and CloudWatch alarms」を翻訳したものです。

Amazon Aurora DSQL のワークロードが拡大し、Distributed Processing Unit (DPU) の消費量が増えてきたとき、コストをどう把握すればよいでしょうか。適切なモニタリングを用意しておけば、支出を先回りして管理でき、サーバーレスデータベースのコストを常に把握できます。固定のインスタンス料金という上限がなくても、コストを見失うことはありません。

本記事では、Aurora DSQL の使用量とコストをモニタリングし、オンデマンド料金のメリットを最大限に活かす方法を紹介します。Aurora DSQL では、使った分だけ料金が発生します。ここでは、Aurora DSQL コンソールに組み込まれた Usage and cost パネルと Amazon CloudWatch アラームを順に説明します。本記事の CloudWatch アラームは、1 時間ごとの DPU 使用量 (月初からの累計支出ではありません) を 1 時間単位でチェックします。そのため、アラートは即時ではなく、CloudWatch メトリクスの計測に伴う少しの遅れ (ほぼリアルタイム) をはさんで届きます。本記事で扱う内容は次のとおりです。

• Aurora DSQL の DPU 料金モデルと、CloudWatch メトリクスと請求額の対応関係
• Aurora DSQL コンソールの Usage and cost パネルで DPU 使用量と推定コストを確認する方法
• 1 時間あたりの DPU 使用量が予算の 1 時間分に近づいたときに Amazon Simple Notification Service (Amazon SNS) で通知する CloudWatch アラームの設定方法。推奨アラームが入力済みになるコンソールの Create alarm フローも含みます。
• AWS CloudFormation を使い、Infrastructure as Code (IaC) としてモニタリング用アラームを一貫した形でデプロイする方法

本記事は、Aurora DSQL を利用中または評価中で、コストを先回りして管理したい AWS 開発者やデータベース管理者を対象とした上級 (300) レベルの内容です。

前提条件

始める前に、次のものがそろっていることを確認してください。

• 稼働中の Aurora DSQL クラスター (シングルリージョンまたはマルチリージョン)
• 適切な権限で設定済みの AWS Command Line Interface (AWS CLI)
• AWS Identity and Access Management (IAM) ロールと CloudWatch アラームを作成する権限
• AWS CloudFormation コンソールにアクセスできる AWS アカウント

Aurora DSQL の料金体系

Aurora DSQL は、アクティブ-アクティブのマルチリージョンアーキテクチャを備えた、サーバーレスで PostgreSQL 互換の分散 SQL データベースです。シングルリージョンで 99.99%、マルチリージョンで 99.999% の可用性を実現するよう設計されています。料金はリクエストベースの従量課金で、プロビジョニングするインスタンスはなく、データベースがアイドル状態のときに時間単位の料金も発生しません。使わないときはゼロまでスケールするため、消費した分だけを支払います。

Aurora DSQL の課金対象は主に 2 つです。Distributed Processing Unit (DPU) で測定するデータベースアクティビティと、GiB-月で測定するストレージです。アクティブなデータベース使用量は DPU という単一の課金単位にまとめられ、コンピューティング、読み取り、書き込み、マルチリージョン書き込み、変更データキャプチャ (CDC) ストリーミングのどのアクティビティでも、DPU は同じ料金で正規化されます。vCPU、メモリ、ネットワーク帯域幅、1 秒あたりの I/O オペレーション数 (IOPS) を個別に追跡・課金するのではなく、アクティブなデータベース使用量をこの単一のメトリクスに統合しています。ストレージは別途課金され、DPU の計算には含まれません。

シングルリージョンクラスターの場合、合計 DPU は次の 3 つの要素の合計です。

TotalDPU = ComputeDPU + ReadDPU + WriteDPU

対応する機能を使っている場合に限り、2 つの要素が追加されます。マルチリージョンクラスターでは MultiRegionWriteDPU、変更データキャプチャ (CDC) を有効にしたクラスターでは StreamDPU が加わります。

TotalDPU = ComputeDPU + ReadDPU + WriteDPU
+ MultiRegionWriteDPU   (multi-Region clusters only)
+ StreamDPU             (clusters with CDC enabled only)

注: StreamDPU はクラスターで CDC を有効にした場合にのみ、MultiRegionWriteDPU はマルチリージョンクラスターでのみ発生します。CDC ストリームのないシングルリージョンクラスターでは両方ともゼロで、請求額には影響しません。

表 1 に、米国東部 (オハイオ) リージョンにおける Aurora DSQL の料金要素をまとめます。料金はリージョンによって異なります。最新の料金は Aurora DSQL の料金ページを参照してください。

表 1: Aurora DSQL の料金要素

ストレージの料金は 1 GiB-月あたり 0.33 USD です。Aurora DSQL は各リージョンで 3 つのアベイラビリティーゾーンにストレージをレプリケートしますが、料金はリージョンごとに 1 つの論理コピー分のみです。

マルチリージョンクラスターを作成した場合に限り、Aurora DSQL は書き込みを他の AWS リージョンにあるピアクラスターへ自動的にレプリケートします。レプリケートされた書き込みには元の書き込みと同額の DPU 料金が追加で発生し、CloudWatch では MultiRegionWriteDPU として表示されます。このレプリケーションに個別のデータ転送料金はかかりません。シングルリージョンクラスターでは MultiRegionWriteDPU は発生しません。

請求書に表示される明細は、ストレージと DPU の 2 項目だけです。DPU の明細は各要素の合計です。

Aurora DSQL の主な CloudWatch メトリクス

Aurora DSQL は、ほぼリアルタイムの使用量メトリクスを AWS/AuroraDSQL 名前空間に ClusterId ディメンション付きで CloudWatch に発行します。CloudWatch はこれらの統計を 15 か月間保持するため、傾向分析に十分な履歴データを利用できます。

表 2: 請求に対応する DPU メトリクス (ClusterId ディメンション)

CDC ストリーミングを有効にしている場合は、Aurora DSQL が ClusterId と StreamId の両ディメンション付きで発行するストリーム単位のメトリクスを使って、ストリームごとにモニタリングできます。表 3 に、コストに特に関係する CDC ストリームのメトリクスを示します。

表 3: CDC ストリームのメトリクス (ClusterId および StreamId ディメンション)

表 4 に、リソース消費のパターンを把握するのに役立つオブザーバビリティメトリクスを示します。

表 4: オブザーバビリティメトリクス

重要: コストを追跡する際は、DPU メトリクスに Sum 統計を使用してください。Sum 統計では一定期間の総消費量が得られ、請求額と直接対応します。DPU 数を金額の見積もりに換算するには、CloudWatch のメトリクス演算を使います。

Estimated Cost ($) = SUM(TotalDPU) x [your regional per-DPU rate, e.g., 0.000008 for us-east-1]

注: プレースホルダーは、お使いのリージョンの DPU 単価に置き換えてください。たとえば、1 DPU あたり 0.000008 USD は、米国東部 (バージニア北部) us-east-1 リージョンと米国東部 (オハイオ) us-east-2 リージョンにおける 100 万 DPU あたり 8 USD に相当します。料金はリージョンによって異なります。お使いのリージョンの料金は Aurora DSQL の料金ページを参照してください。

Aurora DSQL コンソールでコストを確認する

Aurora DSQL コンソールには Usage and cost パネルが組み込まれており、DPU 消費量と推定コストを直接表示します。ダッシュボードを別途設定する必要はありません。このパネルは、AWS マネジメントコンソールのクラスター詳細ページから利用できます。

パネルには、過去 24 時間、7 日間、30 日間の DPU 総消費量、リージョンでの推定コスト、クラスターのストレージサイズ (30 日分のストレージコスト付き) が表示されます。読み取り、書き込み、コンピューティングの DPU 内訳は表示されません。内訳は CloudWatch メトリクスのビューで確認できます。

次のスクリーンショットは、コンソールに表示された Aurora DSQL クラスターの Usage and cost パネルです。

図 1: Aurora DSQL コンソールのクラスターの Summary タブにある Usage and cost パネル。過去 24 時間、7 日間、30 日間の DPU 使用量と推定コスト、クラスターのストレージサイズ、Create alarm ボタンが表示されている

このパネルを開くには、Aurora コンソールのナビゲーションペインで Clusters を選択し、Aurora DSQL クラスターを選んでから、クラスター詳細ページの Summary タブを選択します。デフォルトでは、過去 24 時間、7 日間、30 日間の DPU 消費量と推定コストが並べて表示されます。

DPU の要素 (読み取り、書き込み、コンピューティング、マルチリージョン書き込み) ごとの詳しい内訳を見るには、クラスター詳細ページの Monitoring タブを選択します。要素ごとのグラフと時間範囲を設定できる、CloudWatch メトリクスの詳細ビューが表示されます。

マルチリージョンクラスターの場合、各ピアクラスターはそれぞれのリージョンのコンソールで確認します。あるクラスターの Usage and cost パネルには、そのリージョンの DPU 消費量と推定コストが表示されます。ピアリージョンごとにパネルを開けば、リージョン間で消費量を比較し、書き込みレプリケーションのコストに想定外の偏りがないかを確認できます。

コストアラート用の CloudWatch アラームを設定する

CloudWatch アラームを使うと、Aurora DSQL の 1 時間あたりの DPU 使用量が定義したしきい値に近づいたり超えたりしたときに、自動で対応できます。各アラームは 1 つのメトリクスを監視し、しきい値に対するメトリクスの値に応じて状態が変わります。

アラームの状態は次のとおりです。

• OK: メトリクスが定義したしきい値の範囲内にあります。
• ALARM: メトリクスが定義したしきい値を超えています。
• INSUFFICIENT_DATA: アラームの状態を判定するのに十分なデータポイントがありません。

アラームがメトリクスを評価する方法は、次の 3 つの主要な設定で決まります。

• Period (期間): メトリクスを評価する時間の長さ (たとえば、1 時間ごとに評価する場合は 3,600 秒)
• Evaluation periods (評価期間): 評価する連続した期間の数
• Datapoints to alarm (アラームを発生させるデータポイント): アラームの状態を変えるのに、評価期間のうち何期間でしきい値を超える必要があるか

注: CloudWatch アラームは、固定の期間でメトリクスを評価します。月初からの累計支出は追跡せず、30 日間のアラーム期間もネイティブには用意されていません。本記事のアラームは 1 時間単位のアラームです。1 時間ごとに TotalDPU の合計を監視し、その 1 時間の値が予算の 1 時間分を超えると ALARM 状態になります。そのため、変動の大きいワークロードでは、月全体では予算内に収まっていても、特定の 1 時間でアラームが発生することがあります。月初からの累計を追跡するには、このアラームと AWS Budgets を組み合わせてください (ベストプラクティスを参照)。CDC を使っている場合、Aurora DSQL は StreamDPU を ClusterId と StreamId ディメンションを持つストリーム単位の別メトリクスとして発行しますが、このアラームの TotalDPU メトリクスはクラスター単位です。ストリーミングのコストを確実にモニタリングするには、ストリームごとに StreamDPU の別アラームを作成してください。

ステップ 1: しきい値を計算する

アラームは 1 時間ずつ評価するため、入力する値は 1 時間あたりの DPU しきい値です。表 5 では、月間予算の目標から 1 時間あたりのしきい値を算出しています。月間の DPU 許容量を平均的な 1 か月の 730 時間 (AWS Pricing Calculator と同じ考え方) で均等に割り、その 1 時間分の 80% を早期警告のしきい値としています。

表 5: 1 時間あたりのアラームしきい値の計算例

注: 以降の手順では、「1 時間あたりの警告 (80%)」列の値をアラームのしきい値として設定します。たとえば ~13,699 は、月 100 USD の予算の 1 時間分の 80% に相当します。

ステップ 2: 通知用の Amazon SNS トピックを作成する

Amazon SNS トピックを作成し、チームのメールアドレスをサブスクライブしてアラーム通知を受け取れるようにします。

aws sns create-topic --name dsql-cost-alerts
aws sns subscribe \
    --topic-arn arn:aws:sns:<region>:<account-id>:dsql-cost-alerts \
    --protocol email \
    --notification-endpoint your-team@example.com

ステップ 3a: Aurora DSQL コンソールからアラームを作成する (推奨)

最もお手軽なのは、Aurora DSQL コンソールから作成する方法です。クラスターの Summary タブにある Usage and cost パネルには、Create alarm アクションがあります。これを選択すると CloudWatch のアラーム作成フローが開き、TotalDPU メトリクス、AWS/AuroraDSQL 名前空間、クラスターの ClusterId があらかじめ入力されています。あとは統計に合計、期間に 1 時間、しきい値に表 5 の 1 時間あたりの警告値を設定し、ステップ 2 の SNS トピックを指定します。最近追加されたコンソール機能なので、メトリクスのツリーを手作業でたどる必要はありません。

アラームを手動で作成する場合やスクリプト化する場合は、以降の CloudWatch コンソールまたは AWS CLI の手順を使用してください。

ステップ 3b: CloudWatch アラームを作成する (CloudWatch コンソール)

CloudWatch コンソールでアラームを手動作成するには、次の手順を実行します。

1. CloudWatch コンソールを開き、ナビゲーションペインで Alarms、All alarms を選択します。
2. Create alarm を選択し、Select metric を選択します。
3. メトリクスブラウザで AWS/AuroraDSQL、ClusterId の順に選択します。対象のクラスターと TotalDPU メトリクスを選択します。
4. Specify metric and conditions で、Statistic を Sum、Period を 1 時間 (3,600 秒)、しきい値の種類を Static に設定します。
5. Whenever TotalDPU is で Greater than を選択し、計算した 1 時間あたりの警告しきい値を入力します (たとえば、月 100 USD の予算で 80% の警告なら 13699)。
6. Evaluation periods を 1、Datapoints to alarm を 1 に設定します。Missing data treatment は Treat missing data as not breaching に設定します。
7. Notification で SNS トピック (dsql-cost-alerts) を選択し、アラームが ALARM、OK、INSUFFICIENT_DATA の各状態になったときに通知されるようにします。
8. DSQL-Hourly-DPU-Budget-Warning のようなわかりやすい名前をアラームに付け、設定を確認して Create alarm を選択します。

ステップ 3c: CloudWatch アラームを作成する (AWS CLI)

AWS CLI で同じアラームを作成することもできます。

aws cloudwatch put-metric-alarm \
    --alarm-name "DSQL-Hourly-DPU-Budget-Warning" \
    --alarm-description "Alert when hourly DPU exceeds 80% of budget" \
    --metric-name TotalDPU \
    --namespace AWS/AuroraDSQL \
    --statistic Sum \
    --period 3600 \
    --evaluation-periods 1 \
    --datapoints-to-alarm 1 \
    --threshold 13699 \
    --comparison-operator GreaterThanThreshold \
    --dimensions Name=ClusterId,Value=<your-cluster-id> \
    --alarm-actions arn:aws:sns:<region>:<account-id>:dsql-cost-alerts \
    --ok-actions arn:aws:sns:<region>:<account-id>:dsql-cost-alerts \
    --treat-missing-data notBreaching

この設定で、次のようなことができます。

• データベース管理者や財務チームへのメールアラート
• コスト是正ワークフローのための AWS Lambda 関数の自動トリガー
• Amazon SNS サブスクリプションを通じたインシデント管理システムとの連携

Aurora DSQL のコストアラームを設定する際は、次のベストプラクティスを検討してください。

• 予算の 70% で警告アラーム、90% で重大アラームを設定する。
• OK アクションを含め、コストが通常に戻ったときにチームへ通知する。
• Datapoints to alarm を 3 評価期間中 2 に設定し、一時的なスパイクによる誤報を減らす。この方法は 1 時間のような短い評価期間に適しています。日次評価のような長い期間では、通常は 1 期間中 1 の設定が適しています。
• マルチリージョンクラスターでは、リージョンごとのクラスターに個別のアラームを作成し、コストが発生したリージョンを特定できるようにする。

AWS CloudFormation でモニタリング用アラームをデプロイする

アラーム関連のインフラストラクチャをコードとしてデプロイすれば、一貫性、再現性、バージョン管理を確保できます。AWS CloudFormation には、必要なコンポーネントのネイティブリソースタイプとして AWS::CloudWatch::Alarm と AWS::SNS::Topic が用意されています。

CloudFormation テンプレート

次のテンプレートを dsql-cost-alarms.yaml として保存します。このテンプレートは、通知用の SNS トピックと、しきい値をパラメータ化した TotalDPU メトリクスの CloudWatch アラームを作成します。

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0
AWSTemplateFormatVersion: "2010-09-09"
Description: >
  CloudWatch alarm for Aurora DSQL hourly DPU budget monitoring.
Parameters:
  ClusterId:
    Type: String
    Description: Aurora DSQL Cluster ID to monitor
  AlarmThreshold:
    Type: Number
    Default: 13699
    Description: Hourly DPU threshold (default = 80% of $100/month budget)
  NotificationEmail:
    Type: String
    Description: Email address for alarm notifications
Resources:
  DSQLCostAlertTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: dsql-cost-alerts
      Subscription:
        - Protocol: email
          Endpoint: !Ref NotificationEmail
  DSQLHourlyDPUAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: DSQL-Hourly-DPU-Budget-Warning
      AlarmDescription: Alert when hourly DPU exceeds budget threshold
      MetricName: TotalDPU
      Namespace: AWS/AuroraDSQL
      Statistic: Sum
      Period: 3600
      EvaluationPeriods: 1
      DatapointsToAlarm: 1
      Threshold: !Ref AlarmThreshold
      ComparisonOperator: GreaterThanThreshold
      TreatMissingData: notBreaching
      Dimensions:
        - Name: ClusterId
          Value: !Ref ClusterId
      AlarmActions:
        - !Ref DSQLCostAlertTopic
      OKActions:
        - !Ref DSQLCostAlertTopic
Outputs:
  AlarmArn:
    Description: ARN of the CloudWatch alarm
    Value: !GetAtt DSQLHourlyDPUAlarm.Arn
    Export:
      Name: !Sub "${AWS::StackName}-AlarmArn"
  SNSTopicArn:
    Description: ARN of the SNS notification topic
    Value: !Ref DSQLCostAlertTopic
    Export:
      Name: !Sub "${AWS::StackName}-SNSTopicArn"

テンプレートのデプロイ

AWS CLI で CloudFormation スタックをデプロイします。

aws cloudformation deploy \
    --template-file dsql-cost-alarms.yaml \
    --stack-name dsql-cost-monitoring \
    --parameter-overrides \
    ClusterId=<your-cluster-id> \
    AlarmThreshold=13699 \
    NotificationEmail=your-team@example.com

パラメータとリソースのプロパティは !Ref で結び付けます。たとえば Threshold: !Ref AlarmThreshold や AlarmActions: [!Ref DSQLCostAlertTopic] とすれば、同じテンプレートを環境ごとに異なるしきい値でデプロイできます。

StackSets によるマルチリージョンデプロイ

マルチリージョンの Aurora DSQL クラスターを運用している組織では、AWS CloudFormation StackSets を使って、1 つのテンプレートから複数のリージョンへモニタリングスタックを一貫した形でデプロイできます。モニタリング用インフラストラクチャの CloudFormation スタックを構成する際は、次のプラクティスをお勧めします。

• モニタリング用インフラストラクチャをアプリケーションのリソースと分離し、ライフサイクルを独立して管理する。
• クロススタック参照を使い、リソースの ARN (SNS トピックの ARN など) をスタック間で共有する。
• しきい値をパラメータ化し、スタック全体を再デプロイせずに上限を更新できるようにする。
• CloudFormation モジュールを使い、アラームの設定を再利用可能なモジュールとしてパッケージ化する。
• AWS CloudFormation Guard を使い、Policy as Code でテンプレートを検証する。

Aurora DSQL のコスト管理のベストプラクティス

• DPU の推移をモニタリングする。 Aurora DSQL コンソールの Usage and cost パネルと CloudWatch を使って DPU 消費のパターンを把握し、アプリケーションのイベントやデプロイと関連付けます。
• 段階的なアラートを使う。 予算の 100% で 1 つのアラームを設定するのではなく、複数のしきい値 (70% で警告、90% で重大) を設定します。
• 開発には AWS 無料利用枠を使う。 毎月 100,000 DPU と 1 GiB のストレージが使える無料利用枠は、開発環境やテスト環境に最適です。
• EXPLAIN ANALYZE VERBOSE でクエリのコストを分析する。 EXPLAIN ANALYZE VERBOSE を実行すると、ステートメント単位の DPU の見積もりを確認でき、各オペレーションに伴うコストを把握できます。この値はチューニングの目安として使い、請求レベルの正確な数値とはみなさないでください。正式なコストデータには CloudWatch メトリクスや請求レポートを使います。
• Database Insights でリソースを多く使うクエリを特定する。 Amazon CloudWatch Database Insights は、すべての Aurora DSQL クラスターで追加料金なしで自動的に有効になっています。DSQL Active Session History (DASH) のメトリクス db.active_sessions.avg を待機イベント別や SQL ステートメント別に分析できるため、リソースを最も多く消費するクエリをすばやく特定し、負荷のスパイクでアラートを出せます。Database Insights でコストの高いクエリを見つけ、DPU メトリクスと EXPLAIN ANALYZE VERBOSE でコストへの影響を確認してください。
• AWS Budgets と組み合わせる。 月初からの累計支出の追跡には AWS Budgets を、1 時間単位の運用アラートには CloudWatch を使います。本記事の 1 時間単位のアラームはスパイクをすばやく検知し、AWS Budgets は月初からの支出を予算と比較して追跡します。両方を組み合わせれば、2 つの観点をカバーできます。

クリーンアップ

今後の料金発生を避けるため、本記事の手順で作成したリソースを削除します。次の手順を実行してください。

CloudWatch アラームを削除します。

aws cloudwatch delete-alarms --alarm-names "DSQL-Hourly-DPU-Budget-Warning"

または、CloudFormation スタック全体を削除して、アラーム、SNS トピック、サブスクリプションをまとめて削除します。

aws cloudformation delete-stack --stack-name dsql-cost-monitoring

注: CloudFormation スタックを削除すると Amazon SNS のメールサブスクリプションも削除されるため、削除後はサブスクライバーに通知が届かなくなります。

まとめ

Aurora DSQL は料金が DPU に一本化されているためコスト管理がシンプルですが、予算を管理するには先回りしたモニタリングが欠かせません。Aurora DSQL コンソールに組み込まれた Usage and cost パネルと CloudWatch アラームを使えば、シングルリージョンでもマルチリージョンでも、Aurora DSQL のコスト全体を把握できます。

本記事では、次の内容を説明しました。

• DPU メトリクスと請求額の直接の対応関係と、正確なコスト追跡のための Sum 統計の使い方
• Aurora DSQL コンソールの Usage and cost パネルでの DPU 消費量と推定コストの確認 (ダッシュボードの設定は不要)
• 1 時間あたりの DPU 使用量に対する CloudWatch アラームの設定。適切な評価期間と SNS 通知を組み合わせ、特定の 1 時間が予算の 1 時間分を超えたときにチームへ通知します。
• CloudFormation を使ったアラームスタック全体の Infrastructure as Code によるデプロイと、複数リージョンで Aurora DSQL クラスターを運用する場合の StackSets の活用

まずは CloudFormation テンプレートを Aurora DSQL クラスターに対してデプロイし、予算に合わせてアラームのしきい値を調整してください。また、DPU 消費を抑えるクエリ最適化の手法について Aurora DSQL のドキュメントも参照してください。組織全体で月初からのコストを管理するには、AWS Budgets の利用を検討してください。ご質問はコメント欄にお寄せください。

参考資料

• Amazon Aurora DSQL の料金
• Aurora DSQL での請求の仕組み
• Amazon CloudWatch を使用した Aurora DSQL のモニタリング
• Amazon CloudWatch でのアラームの使用
  
• StackSets を使用したアカウントとリージョン全体でのスタックの管理
• メトリクスを使用した数式

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。