Aurora Blue/Green デプロイメントでバージョンアップを行うと Auto Scaling が動作しなくなった話

セキュリティサービス部佐竹です。
今回は、Amazon Aurora の Blue/Green Deployments を利用してバージョンアップを行った際、Application Auto Scaling が意図せず動作しなくなったという事象に遭遇したため、その原因と対策について動作検証も踏まえて注意喚起します。

はじめに
Aurora の Auto Scaling が機能しなくなった経緯
原因は Aurora Blue/Green Deployments の仕様
- 調査に関する補足
対策と再発防止
実際にどうなるか動作検証してみた
参考ドキュメント
まとめ

はじめに

Amazon Aurora の運用において、「Blue/Green Deployments」と「Application Auto Scaling」は強力で便利な機能です。

Amazon Aurora Blue/Green Deployments:
本番環境に影響を与えることなく、安全にバージョンアップグレードなどを実施するための機能。ブルー環境（以前のデータベースインスタンス）がそのまま残るため、ダウンタイムを最小限に抑えつつも、いつでも切り戻しが可能な状態でデプロイが可能です。
Application Auto Scaling for Aurora:
負荷やスケジュールに応じて、Aurora クラスターのリードレプリカ数を自動で増減させてくれる機能です。コスト最適化とパフォーマンスの維持を両立できます。

この2つの便利な機能ですが、組み合わせて利用する際には注意すべき「仕様」が存在します。

本ブログでは、この注意点を周知するため、実際に発生した事象とその原因を動作検証を踏まえながら解説します。

Aurora の Auto Scaling が機能しなくなった経緯

先日、とある Aurora MySQL クラスターで、長らく運用され設定されていた Application Auto Scaling が正常に機能していないという事象が報告されました。具体的には、負荷が高まってもリードレプリカが増加（スケールアウト）せず、また夜間のスケジュールされたスケールインも実行されていませんでした。

調査を進めると、この事象が発生する数日前に、Aurora データベースのバージョンアップのために「Blue/Green Deployments」が実施されていたことがわかりました。

デプロイメント自体は成功しており、アプリケーションも正常に動作していましたが、Application Auto Scaling は動作しませんでした。

原因は Aurora Blue/Green Deployments の仕様

結論からお伝えすると、この事象は不具合ではなく、Amazon Aurora Blue/Green Deployments の仕様が原因でした。

AWSの公式ドキュメントには、以下のように明記されています。

ブルー DB クラスターで設定されている Auto Scaling ポリシーはグリーン環境にコピーされません。最初にブルー環境またはグリーン環境でセットアップされたかにかかわらず、スイッチオーバー後に再設定する必要があります。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-considerations.html

Blue/Green Deployments では、既存の環境 (ブルー) とは別に新しい (グリーン) 環境が作成され、スイッチオーバーによって実行環境自体を切り替える*1ものです。

そして、スイッチオーバーが実行されると、新しい本番環境(グリーン環境だったもの)には Auto Scaling の設定が引き継がれません。この後に詳しく記載する実環境の検証結果からも、設定は古いブルー環境（-old1）にも残存せず、スイッチオーバーの過程で完全に消失することが確認できています。

よって、追って手動で再設定を行わない限り、スケーリングが実行されなくなってしまいます。

なお設定は完全に消失してしまうことから、後から設定を確認すること自体も難しく、後手に回ると復元にも手間がかかることになります。

調査に関する補足

調査では aws application-autoscaling describe-scaling-activities --service-namespace rds が役立ちました。このログを確認することで、過去いつどのようなオートスケールが実行されていたのか調査することが可能です。

その後 CloudTrail で DeleteDBInstance を調査することで、ここ90日間の実際のスケールインがいつ行われたかも確認しました。

対策と再発防止

この仕様への対策は以下の通りです。

これは避けられない仕様ですので、Amazon Aurora Blue/Green Deployments を利用したスイッチオーバー後、Application Auto Scaling を手動で再設定する以外ありません。

事前準備

具体的には、バージョンアップ作業の前に現在の設定をコマンドで確認及び保存しておき、スイッチオーバーが完了した後に、保存した設定を元に新しいクラスターへ再適用します。

繰り返しになりますが、スイッチオーバーを行うとそれを実施した Aurora の Auto Scaling の設定もまとめて消えてしまいます。よって、スイッチオーバーよりも前に実施します。

以下は実際の調査のための AWS CLI のコマンド例です。

Blue/Green Deployments を開始する前に、以下の AWS CLI コマンドを実行して現在のスケーリング設定の全容を把握し、結果を保存しておきます。

database-1 は仮の値です。ここには、実際の Aurora Cluster の名称を記載します。

describe-scalable-targets

「どのクラスター」を「何台から何台の範囲で」管理するかの基本設定

aws application-autoscaling describe-scalable-targets \
--service-namespace rds \
--resource-id "cluster:database-1"

返り値の例

{
    "ScalableTargets": [
        {
            "ServiceNamespace": "rds",
            "ResourceId": "cluster:database-1",
            "ScalableDimension": "rds:cluster:ReadReplicaCount",
            "MinCapacity": 1,
            "MaxCapacity": 10,
            "RoleARN": "arn:aws:iam::123412341234:role/aws-service-role/rds.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_RDSCluster",
            "CreationTime": "2025-09-16T06:08:34.486000+00:00",
            "SuspendedState": {
                "DynamicScalingInSuspended": false,
                "DynamicScalingOutSuspended": false,
                "ScheduledScalingSuspended": false
            },
            "ScalableTargetARN": "arn:aws:application-autoscaling:ap-northeast-1:123412341234:scalable-target/03d5ba51a986af3b4f1782b7e807f3241028"
        }
    ]
}

describe-scaling-policies

負荷に応じて動的にスケーリングさせるルール

aws application-autoscaling describe-scaling-policies \
--service-namespace rds \
--resource-id "cluster:database-1"

返り値の例

{
    "ScalingPolicies": [
        {
            "PolicyARN": "arn:aws:autoscaling:ap-northeast-1:123412341234:scalingPolicy:ba51a986-af3b-4f17-82b7-e807f3241028:resource/rds/cluster:database-1:policyName/aurora-auto-scale-policy-1",
            "PolicyName": "aurora-auto-scale-policy-1",
            "ServiceNamespace": "rds",
            "ResourceId": "cluster:database-1",
            "ScalableDimension": "rds:cluster:ReadReplicaCount",
            "PolicyType": "TargetTrackingScaling",
            "TargetTrackingScalingPolicyConfiguration": {
                "TargetValue": 70.0,
                "PredefinedMetricSpecification": {
                    "PredefinedMetricType": "RDSReaderAverageCPUUtilization"
                },
                "ScaleOutCooldown": 300,
                "ScaleInCooldown": 600,
                "DisableScaleIn": false
            },
            "Alarms": [
                {
                    "AlarmName": "TargetTracking-cluster:database-1-AlarmHigh-5575d08a-ece5-4dae-b709-5ffe4ee101bb",
                    "AlarmARN": "arn:aws:cloudwatch:ap-northeast-1:123412341234:alarm:TargetTracking-cluster:database-1-AlarmHigh-5575d08a-ece5-4dae-b709-5ffe4ee101bb"
                },
                {
                    "AlarmName": "TargetTracking-cluster:database-1-AlarmLow-ba106a7d-00e1-414b-a9ce-22de66145cdb",
                    "AlarmARN": "arn:aws:cloudwatch:ap-northeast-1:123412341234:alarm:TargetTracking-cluster:database-1-AlarmLow-ba106a7d-00e1-414b-a9ce-22de66145cdb"
                }
            ],
            "CreationTime": "2025-09-16T06:08:45.283000+00:00"
        }
    ]
}

describe-scheduled-actions

時間指定でスケーリングさせるルール

aws application-autoscaling describe-scheduled-actions \
--service-namespace rds \
--resource-id "cluster:database-1"

返り値の例

{
    "ScheduledActions": [
        {
            "ScheduledActionName": "aurora-time-based-scale-in-1",
            "ScheduledActionARN": "arn:aws:autoscaling:ap-northeast-1:123412341234:scheduledAction:ba51a986-af3b-4f17-82b7-e807f3241028:resource/rds/cluster:database-1:scheduledActionName/aurora-time-based-scale-in-1",
            "ServiceNamespace": "rds",
            "Schedule": "cron(50 19 * * ? *)",
            "Timezone": "Asia/Tokyo",
            "ResourceId": "cluster:database-1",
            "ScalableDimension": "rds:cluster:ReadReplicaCount",
            "ScalableTargetAction": {
                "MinCapacity": 1,
                "MaxCapacity": 10
            },
            "CreationTime": "2025-09-16T06:08:58.102000+00:00"
        }
    ]
}

① ScalingPolicies と ② ScheduledActions のどちらも確認してください。片方を漏らした場合に、もう片方だけでは意図通りに動作しない可能性があります。

事後作業（設定の復旧）

スイッチオーバーが完了したら、前のステップで保存した設定内容を元に、新しい本番クラスターに対して以下のコマンドで設定を再適用します。

register-scalable-target
put-scaling-policy
put-scheduled-action

以下は例です。

register-scalable-target

aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --resource-id "cluster:database-1" \
  --scalable-dimension "rds:cluster:ReadReplicaCount" \
  --min-capacity 1 \
  --max-capacity 10

put-scaling-policy

aws application-autoscaling put-scaling-policy \
  --policy-name "aurora-auto-scale-policy-1" \
  --service-namespace rds \
  --resource-id "cluster:database-1" \
  --scalable-dimension "rds:cluster:ReadReplicaCount" \
  --policy-type "TargetTrackingScaling" \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "RDSReaderAverageCPUUtilization"
    },
    "ScaleOutCooldown": 300,
    "ScaleInCooldown": 600,
    "DisableScaleIn": false
  }'

put-scheduled-action

aws application-autoscaling put-scheduled-action \
  --service-namespace rds \
  --resource-id "cluster:database-1" \
  --scalable-dimension "rds:cluster:ReadReplicaCount" \
  --scheduled-action-name "aurora-time-based-scale-in-1" \
  --schedule "cron(50 19 * * ? *)" \
  --timezone "Asia/Tokyo" \
  --scalable-target-action "MinCapacity=1,MaxCapacity=10"

再発防止と手順書に関して

もし定型化されている手順書等がある場合には、Aurora のバージョンアップ手順書（SOP/Standard operating procedure）や Runbook に、「Blue/Green Deployments 後の Application Auto Scaling 再設定」を必須の作業項目として明記することが推奨されます。

実際にどうなるか動作検証してみた

実際に検証環境で、上記の Application Auto Scaling が設定された「database-1」という名の Aurora MySQL 3.08.2 を、3.10.0 へとバージョンアップする作業を、Blue/Green デプロイメントを用いて実行してみました。

グリーン環境の構築

まずは準備段階として、Blue/Green Deployments を利用して、グリーン環境を構築します。

設定後のデプロイメントの進捗について、参考までに状況の変遷を以下に示します。

グリーン環境はまず既存のクラスターの複製として構築されます。よってバージョンはまだ 3.08.2 です。ただし、初回は Writer のみです。

グリーン環境はその後 8.0.mysql_aurora.3.10.0 へとバージョンアップされます。

バージョンアップが完了しました。ただし、ここでもまだ Writer のみです。

最後に、バージョンアップ後のグリーン環境へ Reader が追加されます。

Reader が無事追加され、3.10.0 のグリーン環境の構築が完了しました。これで準備は万端となりました。

スイッチオーバー（Switch over）

それでは、スイッチオーバーをします。

なお、この時点ではこの通り、まだ"cluster:database-1"には Application Auto Scaling の設定が残存していることがわかります。

スイッチオーバーの実行画面には、「IAM ロールはブルー環境からグリーン環境にコピーされません。」などの注意喚起が記載されます。利用者が気づきやすいよう、ここに Application Auto Scaling に関する注意書きも追記されることが望まれます。

スイッチオーバーの実行中です。

スイッチオーバーが完了しました。画面には以下のメッセージが表示されます。

Some green environment settings are different from blue environment settings
The blue instance engine version is 8.0.mysql_aurora.3.08.2 and the green instance engine version is 8.0.mysql_aurora.3.10.0.
Your switchover was successfully completed
We recommend you delete your blue/green environment bg-deployment-1.

Aurora 側のログ（Recent events ）も参考までに掲載します。

September 16, 2025, 16:06 (UTC+09:00)
Switchover started on blue/green deployment bg-deployment-1.
September 16, 2025, 16:07 (UTC+09:00)
Switchover completed on blue/green deployment bg-deployment-1.

スイッチオーバーは1分程度で完了しましたが、これは検証用の Aurora MySQL にデータがほとんど入っていなかったためだと考えられます。

なお、「aws rds describe-events」で確認したところ、16:06:24.707 スイッチオーバー開始で、16:07:58.248 スイッチオーバー完了というログになっていました。

参考: describe-events のログ分析結果

16:06:24.707 - スイッチオーバー開始
- "Message": "Switchover started on blue/green deployment bg-deployment-1."
- Blue/Greenデプロイメントのスイッチオーバープロセスが開始されました。
16:06:31.217 - クラスターの切り替え開始
- "Message": "Switchover from DB cluster database-1 to database-1-green-t0eqnd started."
- 古い本番環境（Blue: database-1）から新しい環境（Green: database-1-green-t0eqnd）への切り替えが始まりました。
16:06:38.683 - Blue環境のコネクション切断開始
- "Message": "Starting to terminate connections and user processes in the blue environment..."
- 古い本番環境（Blue）への新しい接続を停止し、既存の接続を切断し始めます。ここから書き込みができない状態です。
16:06:38.892 - Blue環境のコネクション切断完了
- "Message": "Finished terminating connections and user processes in the blue environment..."
- 古い本番環境（Blue）のすべての接続が終了しました。
16:06:39.550 - Green環境が書き込み可能に
- "Message": "The DB cluster database-1-green-t0eqnd is now accepting read and write operations... The write downtime during the switchover lasted approximately 0 seconds."
- 新しい環境（Green）がプライマリとして昇格し、読み書き両方の操作を受け付け始めました。この時点でダウンタイムが終了しています。
16:06:58.712 〜 16:07:13.101 - クラスター名（エンドポイント）の変更
- "Message": "...Renamed database-1 to database-1-old1 and database-1-green-t0eqnd to database-1."
- 古いクラスターが database-1-old1 にリネームされ、新しいクラスターが元の本番名 database-1 に変更されました。
- これにより、アプリケーションは接続設定を変えることなく新しいデータベースに接続できます。
16:07:58.248 - スイッチオーバー完了
- "Message": "Switchover completed on blue/green deployment bg-deployment-1."
- エンドポイントの変更や後処理を含めた、すべてのスイッチオーバープロセスが完了しました。

スイッチオーバー後の設定確認

スイッチオーバーが完了したため Application Auto Scaling の設定が残っているか確認します。

結果ですが、画像の通り、設定は全て消えていました。

元の設定を施していた旧クラスター(-old1)を指定して

aws application-autoscaling describe-scalable-targets \
--service-namespace rds \
--resource-id "cluster:database-1-old1"

と、実行しても消えており、もちろん

aws application-autoscaling describe-scalable-targets \
--service-namespace rds \
--resource-id "cluster:database-1"

現クラスターを指定しても、消えていることがわかります。

この検証で、スイッチオーバーによって設定が消失することは確実であることが確認できました。

参考ドキュメント

AWS CLI

AWS 公式ブログ

aws.amazon.com

AWS 公式ドキュメント

まとめ

今回のブログでは、Amazon Aurora における Blue/Green Deployments の利用時に Application Auto Scaling が意図せず機能しなくなる事象について、その原因と対策を動作検証も踏まえた上で解説しました。

事象: Aurora の Blue/Green デプロイによるスイッチオーバー後、Application Auto Scaling が動作しなくなる。
原因: Amazon Aurora の仕様により、Application Auto Scaling ポリシーは新しい本番環境に引き継がれないため。
対策: スイッチオーバー前に事前に調査を行い、スイッチオーバー後には漏れずに Application Auto Scaling の設定を新しい本番クラスターに対して手動で再適用する。
再発防止: バージョンアップ手順書に、Application Auto Scaling の再設定作業を組み込む。

便利な機能の組み合わせが思わぬ落とし穴になるケースは AWS 運用で時折みられますが、今回は特に気づきにくい仕様だと感じました。

できればこれは、Amazon Aurora の Blue/Green Deployments 側の機能で吸収して欲しいと切に願います。また確認は「スイッチオーバーの実行前に」行うよう改めて記載致します。

本ブログが、同様の事象に直面した方の助けになれば幸いです。

では、またお会いしましょう。

*1:切り替えというかは、入れ替えると言ったほうがわかりやすいかもしれません

Aurora Blue/Green デプロイメントでバージョンアップを行うと Auto Scaling が動作しなくなった話

はじめに

Aurora の Auto Scaling が機能しなくなった経緯

原因は Aurora Blue/Green Deployments の仕様

調査に関する補足

対策と再発防止

事前準備

describe-scalable-targets

返り値の例

describe-scaling-policies

返り値の例

describe-scheduled-actions

返り値の例

事後作業（設定の復旧）

register-scalable-target

put-scaling-policy

put-scheduled-action

再発防止と手順書に関して

実際にどうなるか動作検証してみた

グリーン環境の構築

スイッチオーバー（Switch over）

参考: describe-events のログ分析結果

スイッチオーバー後の設定確認

参考ドキュメント

AWS CLI

AWS 公式ブログ

AWS 公式ドキュメント

関連エンジニアブログ

まとめ

AWS CodeBuild、GitHub Actions、GitLab CI/CDにおけるキャッシュの書き方

Aurora Blue/Green デプロイメントでバージョンアップを行うと Auto Scaling が動作しなくなった話

CrowdStrike Falcon Sensorをアンインストールする

New RelicでSNMP Trapの基本的な監視設定をしよう

Amazon GuardDutyでエンティティリストを使用した脅威検出のカスタマイズ