【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
  1. DB の名称
  2. DB のタイプ (= aurora or rds)
  3. CloudFormationスタックの名称

の 3点が表示されます。

他のオプション

-j
画面へのログ出力を JSON形式へ切り替えます。
-p
CloudFormationスタック名のプレフィックスを指定します。
(デフォルト: ktnh)
-v
デバッグログを出力します。

仕組み

ktnh は以下の AWSサービスを利用します。

サービス用途
Step FunctionsDB を停止する。
EventBridge RuleAurora/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メッセージ
AuroraRDS-EVENT-0153DB cluster is being started due to it exceeding the maximum allowed time being stopped.
RDSRDS-EVENT-0154DB instance is being started due to it exceeding the maximum allowed time being stopped.

また、万が一イベントを取りこぼした場合に備えて、定期スケジュールで Step Functions を実行するようにしています。
(6時間ごとに発火します)

ワークフロー

Step Functions のワークフローは次のとおりです。

Aurora と RDS で経路は同一ですが、実行する AWS API が異なります。

DBタイプDescribeDBStatusStopDB
AuroraDescribeDBClustersStopDBCluster
RDSDescribeDBInstancesStopDBInstance

DB が完全に起動する前に停止リクエストを仕掛けても失敗してしまうので、DB のステータスをチェックして、まだ起動中ならば待機するようにしています。
ステータスの具体的な内訳は次のとおりで、これ以外の場合は異常な状態であると判断して何もせずにワークフローを終了します。

DBタイプ起動中起動完了
Aurorabacking-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
RDSbacking-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

ぜひお試しください。

今後ともよろしくお願い申し上げます。