この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

RDS Auroraクラスターを一時停止して起動すると、毎回backing-upというステータスになる。これについて調べた内容を整理しておく。

backing-upとは何か

backing-upはDBが使用可能な状態でスナップショットを取得している状態を指す。初回のバックアップはディスク全体をコピーする必要があるため時間がかかり、2回目以降は差分のみをコピーするので速くなる、という挙動がコミュニティ上でも報告されている。クラスター作成直後やスナップショットからの復元直後にこのステータスが出やすいのは、この初回バックアップの重さが理由と考えられる。

逆に言うと、通常の再起動（一時停止を挟まない場合）で毎回backing-upが出るわけではない。

一時停止からの再開時

一時停止から起動した場合に毎回backing-upが出るという現象自体は、実際によく報告されている挙動ではある。ただし「なぜ毎回出るのか」を明確に説明した公式ドキュメントは見つけられなかった。

確認できたのは以下のところまで。

• DBインスタンスを停止してもメタデータ（エンドポイント、パラメータグループ、オプショングループのメンバーシップ）は保持される
• トランザクションログも保持されるため、必要であればポイントインタイムリストアが可能
• 停止中は課金体系が変わる（プロビジョニング済みストレージやバックアップストレージの課金は継続）

「停止中はバックアップが行われず、再開後にバックアップ処理が再開する」という説明は理屈としては筋が通っているが、公式な裏付けは取れていない。ここは推測として書いておく。

インスタンスとクラスターの違い

ここは訂正が必要だった部分。単一のRDSインスタンス（MySQL単体など）とAuroraクラスターを並べて「どちらでもbacking-upが出る」と考えていたが、そもそもAuroraは個別インスタンス単位での停止・起動ができない。

停止・起動はクラスター単位の操作（StopDBCluster / StartDBCluster）のみで、通常のRDSインスタンス向けのStopDBInstance / StartDBInstanceは、RDS Custom・Aurora MySQL・Aurora PostgreSQLには適用されないと明記されている。つまり「Auroraのインスタンス単体を一時停止から起動する」というシチュエーション自体が存在しない。

状態遷移としてはだいたいこんな感じになる。

stateDiagram-v2
    [*] --> stopped: クラスター停止
    stopped --> starting: クラスター起動
    starting --> backing_up: 起動処理中に発生することが多い
    backing_up --> available
    available --> stopped: 再度停止

分かったこと・分からなかったこと

• 初回バックアップが重いのでbacking-upの時間が長くなりやすい、というのは裏付けが取れた
• 一時停止からの再開で毎回backing-upになる、という現象自体は経験則として妥当そう
• ただしその原因（バックアップ処理が再開されるから、という説明）は未確認
• Auroraは個別インスタンスの停止・起動ができず、クラスター単位でしか操作できない

原因の部分は実機で追加検証するか、AWSサポートに聞いてみるのが確実そう。