Aurora/RDS の永続的停止ツール ktnh を公開しました

2025年06月04日

【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 or rds)
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`