developersIO
Aurora Auto Scaling でレプリカが増減したときの EventBridge イベントを実機で確認してみた

Aurora Auto Scaling でレプリカが増減したときの EventBridge イベントを実機で確認してみた

Aurora Auto Scaling でレプリカが増減した際、EventBridge にはどのようなイベントが届くのでしょうか。本記事では、実際に負荷をかけてスケールアウト／インを発生させ、イベント仕様とそれを確実に検知するための EventBridge パターンを検証結果として紹介します。
AWSAmazon AuroraAurora Auto ScalingAWS Auto ScalingAmazon RDS
2026.08.12

はじめに

Amazon Aurora には「オートスケーリング」と呼ばれる仕組みが現時点で 2 種類存在します。名前が似ているため混同されがちですが、スケールする方向が異なります。

方式 スケールの方向 何が変わるか
Aurora Auto Scaling 水平（スケールアウト/イン） 読み取り負荷に応じて Aurora レプリカ（読み取り専用インスタンス）の台数 が増減する
Aurora Serverless v2 垂直（スケールアップ/ダウン） 単一インスタンスの キャパシティ（ACU = CPU/メモリ） が自動調整される

本記事で扱うのは前者の Aurora Auto Scaling です。詳細については、以下の記事をご参照ください。
https://dev.classmethod.jp/articles/how-to-configure-amazon-aurora-auto-scaling/

実運用では、レプリカの増減をきっかけにタグ付けや CloudWatch アラームの追加、Slack 通知といった処理を挟みたくなります。これを EventBridge で実現するには、正確なイベントパターンを書く必要があります。
イベント ID の一覧はドキュメントで確認できますが、実際に届くイベントの中身まで把握しておくと、より確実なパターンを組み立てられます。

そこで本記事では、次の 2 点を確認します。

  • レプリカが自動で増減したとき、EventBridge にどんなイベントが届くのか
  • 増減を確実に検知するためのイベントパターンはどう書くか

検証方法

検証の流れは以下のとおりです。

  • Aurora クラスターに対し、同一 VPC 内の EC2 から sysbench でリーダーエンドポイント経由の読み取り負荷をかけ、スケールアウト／インを発生させる
  • RDS の DB インスタンスイベントは EventBridge で絞り込まずすべて CloudWatch Logs へ出力し、実際のフィールド値を確認する
  • あわせて CloudTrail で呼び出し元を確認し、Auto Scaling 起因であることを裏取りする

準備

0. EC2 と Aurora クラスターの作成

いずれも通常どおりの作成手順のため割愛します。本検証では以下のとおり構築しています。

負荷生成 EC2

項目 値
OS Amazon Linux 2023（Aurora と同一 VPC）
インスタンスクラス t3.micro
負荷生成ツール sysbench 1.1.0
MySQL クライアント mysql-community-client
SSL 証明書 global-bundle.pem（RDS 証明書バンドル）

Aurora クラスター

項目 値
エンジン Aurora MySQL 互換（8.0.mysql_aurora.3.10.3）
インスタンスクラス db.t4g.medium
構成 Writer 1 台
認証情報 AWS Secrets Manager で管理

1. レプリカ自動スケーリングの設定

作成済みの Aurora クラスターに対し、自動スケーリングポリシーを以下のとおり設定します。

ポリシー名：test-yutaka-autoscaling

項目 値
メトリクス/ターゲット値 平均 CPU 使用率 / 40%
キャパシティ 最小 1 / 最大 3
クールダウン スケールイン・アウトとも 300 秒

yutaka_test01_08

作成すると、裏側で Application Auto Scaling のスケーラブルターゲットとターゲット追跡ポリシー、およびサービスリンクロール AWSServiceRoleForApplicationAutoScaling_RDSClusterが作られます。
このロール名は後の CloudTrail での確認で取り上げます。

2. RDS イベントを全捕捉する EventBridge ルールを作成

どのフィールドにどんな値が入るかを確認するため、絞り込まず DB インスタンスイベントをすべて CloudWatch Logs へ流します。

ルール名：test-yutaka-capture-all-rds-events
ターゲット：CloudWatch Logs ロググループ（/aws/events/test-yutaka-capture-all-rds-events-log）

イベントパターン：

{
  "source": ["aws.rds"],
  "detail-type": ["RDS DB Instance Event"]
}

yutaka_test02

[検証1] スケールアウトを発生させる

Auto Scaling が参照するのはレプリカの平均 CPU 使用率（または平均接続数）のため、負荷はリーダーエンドポイントに流します。

認証情報とエンドポイントの準備

パスワードがコマンド履歴に残らないよう、Secrets Manager から取得して変数に格納します。

# パスワードを変数に格納
export DB_PASS="$(aws secretsmanager get-secret-value \
  --secret-id 'arn:aws:secretsmanager:ap-northeast-1:<ACCOUNT_ID>:secret:rds!cluster-xxxxxxxx' \
  --query SecretString --output text | jq -r '.password')"

# エンドポイント（ライター＝クラスター / リーダー）
export WRITER="<cluster-name>.cluster-xxxxxxxx.ap-northeast-1.rds.amazonaws.com"
export READER="<cluster-name>.cluster-ro-xxxxxxxx.ap-northeast-1.rds.amazonaws.com"

テーブル準備（sysbench prepare）

初回のみ、データベース sbtest を作成します。

mysql -h "$WRITER" -u admin -p"$DB_PASS" \
  --ssl-mode=VERIFY_IDENTITY --ssl-ca=./global-bundle.pem \
  -e "CREATE DATABASE IF NOT EXISTS sbtest;"

続いて prepare でテスト用テーブルを作成します。接続先はライターです。

sysbench oltp_read_only \
  --db-driver=mysql \
  --mysql-host="$WRITER" \
  --mysql-port=3306 \
  --mysql-user=admin \
  --mysql-password="$DB_PASS" \
  --mysql-db=sbtest \
  --mysql-ssl=verify_identity \
  --mysql-ssl-ca=./global-bundle.pem \
  --tables=8 \
  --table-size=200000 \
  --threads=4 \
  prepare
  • --tables=8 / --table-size=200000 … 計 160 万行。バッファプールに収まらない規模にして読み取りで CPU を使わせる
  • --threads=4 … T 系の CPU クレジットを prepare で使い切らないため

負荷投入

リーダーエンドポイントへ負荷投入します。

sysbench oltp_read_only \
  --db-driver=mysql --mysql-host="$READER" --mysql-port=3306 \
  --mysql-user=admin --mysql-password="$DB_PASS" --mysql-db=sbtest \
  --mysql-ssl=verify_identity \
  --mysql-ssl-ca=./global-bundle.pem \
  --tables=8 --table-size=200000 \
  --threads=16 --time=1800 --report-interval=10 \
  --rand-type=uniform \
  run | tee run_scaleout.log
  • --time=1800（30分）… 検知から効果確認まで 20 分程度かかるため
  • --threads=16 … db.t4g.medium で CPU 使用率 60〜80% を狙った値
  • --rand-type=uniform … バッファプールヒットによる CPU 低下を回避

スケールアウトを確認

しばらく待つとスケールアウトが実施されます。

yutaka_test03_08

スケールインを確認

負荷投入が完了し、しばらく経つとレプリカが削除されました。

yutaka_test04_08

[検証2] EventBridge に届いたイベントを確認する

RDS コンソールのクラスターイベントの時系列を参考に、CloudWatch Logs のログを確認します。

yutaka_test05_08

スケールアウト時

CloudWatch Logs から以下の記録を確認できました。

  • EventID は RDS-EVENT-0005（DB instance created / カテゴリ creation）
{
    "version": "0",
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "detail-type": "RDS DB Instance Event",
    "source": "aws.rds",
    "account": "<ACCOUNT_ID>",
    "time": "2026-08-12T00:01:40Z",
    "region": "ap-northeast-1",
    "resources": [
        "arn:aws:rds:ap-northeast-1:<ACCOUNT_ID>:db:application-autoscaling-d81b10f6-e321-4c52-bd49-ff96443d2266"
    ],
    "detail": {
        "EventCategories": [
            "creation"
        ],
        "SourceType": "DB_INSTANCE",
        "SourceArn": "arn:aws:rds:ap-northeast-1:<ACCOUNT_ID>:db:application-autoscaling-d81b10f6-e321-4c52-bd49-ff96443d2266",
        "Date": "2026-08-12T00:01:40.939Z",
        "Message": "DB instance created",
        "SourceIdentifier": "application-autoscaling-d81b10f6-e321-4c52-bd49-ff96443d2266",
        "EventID": "RDS-EVENT-0005",
        "Tags": {
            "application-autoscaling:resourceId": "cluster:test-yutaka-rds"
        }
    }
}

また、SourceIdentifier のプレフィックスが application-autoscaling- であることから、手動追加ではなく Aurora Auto Scaling によって作成されたレプリカだと判別できます。

Aurora Auto Scaling によってレプリカが追加されると、application-autoscaling- によってその DB インスタンス ID に application-autoscaling-61aabbcc-4e2f-4c65-b620-ab7421abc123 などのプレフィックスが付けられます。

スケールイン時

以下の記録を確認できました。

  • EventID は RDS-EVENT-0003（DB instance deleted / カテゴリ deletion）
{
    "version": "0",
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "detail-type": "RDS DB Instance Event",
    "source": "aws.rds",
    "account": "<ACCOUNT_ID>",
    "time": "2026-08-12T00:56:57Z",
    "region": "ap-northeast-1",
    "resources": [
        "arn:aws:rds:ap-northeast-1:<ACCOUNT_ID>:db:application-autoscaling-a9fe6882-f612-40c4-a79d-ff7302a94ebe"
    ],
    "detail": {
        "EventCategories": [
            "deletion"
        ],
        "SourceType": "DB_INSTANCE",
        "SourceArn": "arn:aws:rds:ap-northeast-1:<ACCOUNT_ID>:db:application-autoscaling-a9fe6882-f612-40c4-a79d-ff7302a94ebe",
        "Date": "2026-08-12T00:56:57.003Z",
        "Message": "DB instance deleted",
        "SourceIdentifier": "application-autoscaling-a9fe6882-f612-40c4-a79d-ff7302a94ebe",
        "EventID": "RDS-EVENT-0003",
        "Tags": {
            "application-autoscaling:resourceId": "cluster:test-yutaka-rds"
        }
    }
}

補足：CloudTrail での裏取り

前述の SourceIdentifier のプレフィックスは、Auto Scaling 起因かどうかを見分ける実用的な手がかりになります。ただし、同じ名前は手動でも付けられるため、あくまで命名規約に依存した判定です。
より厳密に確認したい場合は、CloudTrail を併用します。

同時刻の CloudTrail ログを確認すると、CreateDBInstance / DeleteDBInstance の userIdentity に、サービスリンクロール（AWSServiceRoleForApplicationAutoScaling_RDSCluster）とセッション名が記録されています。

  • CreateDBInstance
{
    ...
    "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::<ACCOUNT_ID>:assumed-role/AWSServiceRoleForApplicationAutoScaling_RDSCluster/AutoScaling-UpdateDesiredCapacity",
    ...
    },
    "eventSource": "rds.amazonaws.com",
    "eventName": "CreateDBInstance",
    ...
}
  • DeleteDBInstance
{
    ...
    "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::<ACCOUNT_ID>:assumed-role/AWSServiceRoleForApplicationAutoScaling_RDSCluster/AutoScaling-RetrieveCurrentCapacity",
    ...
    },
    "eventSource": "rds.amazonaws.com",
    "eventName": "DeleteDBInstance",
    ...
}

このロールは Application Auto Scaling のみが引き受けられるため、手動操作（IAM ユーザーやフェデレーティッドユーザーの ARN が記録される）とは明確に区別できます。

Aurora Auto Scaling は、サービスにリンクされたロール AWSServiceRoleForApplicationAutoScaling_RDSCluster を使用します。

検証結果

冒頭に挙げた 2 点について、以下の結果が得られました。

  • レプリカが自動で増減したとき、EventBridge にどんなイベントが届くのか
事象 EventID Message カテゴリ
スケールアウト RDS-EVENT-0005 DB instance created creation
スケールイン RDS-EVENT-0003 DB instance deleted deletion

いずれも SourceIdentifier は application-autoscaling- 形式でした。

  • 増減を確実に検知するためのイベントパターンはどう書くか
{
  "source": ["aws.rds"],
  "detail-type": ["RDS DB Instance Event"],
  "detail": {
    "EventID": ["RDS-EVENT-0005", "RDS-EVENT-0003"],
    "SourceIdentifier": [{ "prefix": "application-autoscaling-" }]
  }
}

なお、prefix マッチによって、手動作成した通常のインスタンスのイベントを除外できます。複数クラスターが同一アカウントに存在する場合は、detail.SourceArn に条件を足して絞り込むことも可能です。
https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-create-pattern-operators.html

まとめ

  • Aurora Auto Scaling によるレプリカ増減は、RDS-EVENT-0005（作成）と RDS-EVENT-0003（削除）として EventBridge に届きます。
  • SourceIdentifier の application-autoscaling- プレフィックスを併用すれば、手動作成のインスタンスと区別できます。

検知パターンが決まれば、あとは用途に応じて任意のターゲット（Lambda、SNS、Step Functions など）を選ぶだけです。
本記事が Aurora のスケーリングをフックにした自動化を検討している方の参考になれば幸いです。

参考情報

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

Aurora でフェイルオーバーが発生した際にログから検知する方法があるか教えてください
mochizuki.koji
2025.08.07
Aurora Auto Scaling ポリシー作成時に自動生成される 2 つの CloudWatch アラームの内、常に片方がアラーム状態になっている事象への対処方法
mochizuki.koji
2025.03.31
[アップデート] Amazon RDS for SQL Server の SQL Server Audit ログを CloudWatch Logs に直接配信できるようになりました
いわさ
2026.08.06
[Amazon Aurora] リードレプリカを指定した時刻でスケーリングできるのか教えてください
村上紗敏
2025.07.21