Aurora/RDS の永続的停止ツール ktnh を公開しました
【2025年6月5日 追記】$ go install
によるインストール手順に不備があったので修正しました。
はじめに
平素は大変お世話になっております。
クイックガードのパー子です。
Amazon Aurora や RDS の一時停止期間は有限であり、7日後に勝手に起動してきてしまうことはよく知られています。
AWS からも公式ナレッジとして 対処方法が紹介 されていますが、このような設定セットを DBごとにいちいち作成して回るのは面倒くさいものです。
そこで、コマンド一発でこれを実現するためのツール koreru-toki-no-hiho
(ktnh
) を開発しました。
https://github.com/quickguard-oss/koreru-toki-no-hiho
DB の時間を凍らせる秘法なのです。
特長
ktnh
には以下の特長があります。
- コマンド一発で凍結/解凍
- 目的の DB に対して、凍結 (= 永続的な停止状態の維持) と解凍 (= 維持の解除) の切り替えをコマンド一発で行えます。
- Golang製
- シングルバイナリなので、取り回しが容易です。
- Aurora/RDS 両対応
- Auroraクラスタと RDSインスタンスの両方に対応しています。
使い方
Golang製なので、$ go install
でインストールできます。
$ go install github.com/quickguard-oss/koreru-toki-no-hiho@latest
$ alias ktnh="${GOPATH}/bin/koreru-toki-no-hiho"
または GitHub の Releasesページ からダウンロードしても OK です。
凍結する
DB の ID を引数として freeze
サブコマンドを実行します。
$ ktnh freeze <db-identifier>
詳しくは後述しますが、ktnh
は停止状態を維持するためのリソースを CloudFormation で管理しています。
凍結処理を実行せず、Dry run的に CloudFormationテンプレートだけ確認したい場合は -t
オプションを付与します。
$ ktnh freeze <db-identifier> -t
freeze
サブコマンドは、デフォルトでは CloudFormationスタックの適用完了を待ち合わせます。
結果を見届けず、すぐにコマンドを終了したい場合は --no-wait
オプションを付与します。
$ ktnh freeze <db-identifier> --no-wait
待ち時間は --wait-timeout
オプションで調整できます。
(time.ParseDuration()
でパース可能な文字列として指定します)
$ ktnh freeze <db-identifier> --wait-timeout <duration>
解凍する
解凍は defrost
サブコマンドです。
$ ktnh defrost <db-identifier>
freeze
サブコマンドと同様に、--no-wait
や --wait-timeout
オプションを使用できます。
凍結中の DB を一覧する
凍結中の DB の一覧を表示するには、引数なしで list
サブコマンドを実行します。
$ ktnh list
実行例:
$ ktnh list
ID TYPE STACK
yumeko-abc aurora ktnh-yumeko-abc-YK7W3W
yumeko-123-test rds ktnh-yumeko-123-t-LMPZWG
- DB の名称
- DB のタイプ (=
aurora
orrds
) - CloudFormationスタックの名称
の 3点が表示されます。
他のオプション
-j
- 画面へのログ出力を JSON形式へ切り替えます。
-p
- CloudFormationスタック名のプレフィックスを指定します。
(デフォルト:ktnh
) -v
- デバッグログを出力します。
仕組み
ktnh
は以下の AWSサービスを利用します。
サービス | 用途 |
---|---|
Step Functions | DB を停止する。 |
EventBridge Rule | Aurora/RDS の起動を検知して Step Functions を実行する。 |
EventBridge Scheduler | 補助的な仕組みとして、Step Functions を定期的に実行する。 |
これらのリソースは CloudFormation で管理され、DB ごとに専用のスタックが作成されます。
スタック名の形式は <プレフィックス>-<DB名>-<ランダム文字列>
で、DB名は 10文字に切り詰められます。
(先述したように、プレフィックスのデフォルト値は ktnh
ですが -p
オプションで変更できます)
例: ktnh-yumeko-abc-YK7W3W
トリガー
冒頭で紹介した AWS公式の手法では、“DBごとのメンテナンス・ウィンドウに合わせたスケジュール実行” を処理の契機としています。
事前に設定したスケジュールに従ってメンテナンス開始前に EventBridge が Step Functions を呼び出し、Step Functions はメンテナンス・ウィンドウを挟んで DB を起動 -> 待機 -> 停止してワークフロー終了、という流れとなっています。
DB が停止中であってもメンテナンスの機会を逃さずにアップデートを適用できるのは利点ですが、メンテナンス・ウィンドウは DB によって異なるため、日時管理が煩雑になりがちです。
また、メンテナンス・ウィンドウは DB作成後も任意のタイミングで変更できるため、スケジュールの追随漏れが発生する可能性もあります。
そこで、ktnh
では、日時ベースではなく、イベントを契機とした仕組みを採用しました。
以下のイベントを捕捉して Step Functions を呼び出します。
DBタイプ | イベントID | メッセージ |
---|---|---|
Aurora | RDS-EVENT-0153 | DB cluster is being started due to it exceeding the maximum allowed time being stopped. |
RDS | RDS-EVENT-0154 | DB instance is being started due to it exceeding the maximum allowed time being stopped. |
また、万が一イベントを取りこぼした場合に備えて、定期スケジュールで Step Functions を実行するようにしています。
(6時間ごとに発火します)
ワークフロー
Step Functions のワークフローは次のとおりです。

Aurora と RDS で経路は同一ですが、実行する AWS API が異なります。
DBタイプ | DescribeDBStatus | StopDB |
---|---|---|
Aurora | DescribeDBClusters | StopDBCluster |
RDS | DescribeDBInstances | StopDBInstance |
DB が完全に起動する前に停止リクエストを仕掛けても失敗してしまうので、DB のステータスをチェックして、まだ起動中ならば待機するようにしています。
ステータスの具体的な内訳は次のとおりで、これ以外の場合は異常な状態であると判断して何もせずにワークフローを終了します。
DBタイプ | 起動中 | 起動完了 |
---|---|---|
Aurora | backing-up backtracking creating failing-over maintenance migrating modifying promoting preparing-data-migration renaming resetting-master-credentials starting storage-optimization update-iam-db-auth upgrading | available |
RDS | backing-up configuring-enhanced-monitoring configuring-iam-database-auth configuring-log-exports converting-to-vpc creating maintenance modifying moving-to-vpc rebooting resetting-master-credentials renaming starting storage-config-upgrade storage-initialization storage-optimization upgrading | available incompatible-option-group incompatible-parameters restore-error storage-full |
補足
ただし、これらのステータスを 1つずつ発現させて検証することが難しいので、正しく分類できているかどうか…。
メンテナンスの扱い
AWS公式の手法と異なり、ktnh
はメンテナンス・ウィンドウを考慮しません。
メンテナンスの開始に合わせて DB を起動することもしませんし、メンテナンスの完了を待ち合わせて停止することもしません。
DB が停止している間はメンテナンスが行われない (= パッチが当たらない) ため、セキュリティ上のリスクを抱えることになります。
そのため、ktnh
で停止中の DB について定期的に適用待ちのパッチがないか確認して、都合のよいタイミングで明示的にメンテナンスを実施することをオススメします。
まとめ
7日を超えて Amazon Aurora / RDS を停止状態に保つためのコマンドライン・ツール ktnh
をご紹介しました。
https://github.com/quickguard-oss/koreru-toki-no-hiho
ぜひお試しください。
今後ともよろしくお願い申し上げます。