2020/04/09追記: 個別インスタンスのメンテナンスウィンドウの時間も「変更」ボタンを押さなくても確認できる様になりました

はじめに

Auroraのメンテナンスウィンドウの設定がわかりにくくて、本番稼働しているDBが強制再起動されました。

自分が犯したミスを他の方がしないために、はまったポイントを書き残しておこうと思います。

TL;DR

Auroraにはクラスター、インスタンスの2種類のメンテナンスウィンドウがある
クラスターにセットされたメンテナンスウィンドウは、DBインスタンスの詳細画面から確認できる
インスタンスにセットされたメンテナンスウィンドウは、DBインスタンスの詳細画面から確認できない
インスタンス個別のメンテナンスウィンドウを確認するには、インスタンスを選択し「変更」ボタンをクリックすることで、そのインスタンスにセットされたメンテナンスウィンドウの値を確認することができる
変更ボタンを押した際、プラウザにキャッシュされたパスワードがDBのパスワードを書き換えてしまう可能性があるので、プラウザのキャッシュをクリアしてから作業を行う

メンテナンスウィンドウとは？

ドライバの更新やパッチ当て等の再起動を伴う影響が大きいメンテナンスの実行時間を、
事前に「この日にやってね」と設定できる機能のことを言います。

AWS Systems Manager メンテナンスウィンドウでは、オペレーティングシステムのパッチ適用、ドライバーの更新、ソフトウェアやパッチのインストールなど、インスタンスに対して破壊的になり得るアクションを実行するスケジュールを定義できます。

基本的にアクセス数の少ない時間に設定すると思います。

設定箇所

確認方法はいたって簡単、
コンソールからRDS→データベースを選択します。

「メンテナンスとバックアップ」のタブでいつメンテナンスウィンドウが設定されているかがわかります。

この例ですとUTC時間の土曜19時~19時半の間に実行されるよう設定しています。

この設定をしていたのに関わらず、想定外の時間にメンテナンスが実行され、DBが再起動されました。

AWSのサポートに問い合わせると以下の回答を頂きました。

今回メンテナンス対象としてお知らせしておりました DB インスタンス hoge のメンテナンスウィンドウは毎週土曜日 13:51 - 14:21 UTC で設定されておりました。
ご確認頂いておりますリソースは DB インスタンスが動作する Aurora クラスター hogehoge のメンテナンスウィンドウで、DB インスタンスのメンテナンスウィンドウとは独立して設定されております。
DBインスタンスのメンテナンスウィンドウをご確認いただけますようお願いいたします。

最初何を言っているかが全くわかりませんでしたが、

DB インスタンスのメンテナンスウィンドウは独立している・・・？
ということがわかりました。

焦ってDBインスタンスを確認しました。

インスタンスを選択してもメンテナンスウィンドウの時間などタブにも表示されていませんし、確認もできません。

まさか、、、、嘘でしょ！？？？、、、と思いながら恐る恐る右上の「変更」ボタンを押してみると・・・・

DBインスタンス個別のメンテナンスの時間が表示されました。

TL;DRにも書きましたが、以下の仕様であることがわかりました。

Auroraにはクラスター、インスタンスの2種類のメンテナンスウィンドウがある
クラスターにセットされたメンテナンスウィンドウは、DBインスタンスの詳細画面から確認できる
インスタンスにセットされたメンテナンスウィンドウは、DBインスタンスの詳細画面から確認できない
インスタンス個別のメンテナンスウィンドウを確認するには、インスタンスを選択し「変更」ボタンをクリックすることで、そのインスタンスにセットされたメンテナンスウィンドウ値を確認することができる

この仕様は非常にわかりにくいので、サポートにフィードバックしたところ、AWSサポートでも問題は認識しており、担当部署にフィードバックしてくれるようです。

悪夢はまだ続く

さて、DBインスタンス毎にメンテナンスウィンドウを設定しなければいけないことがわかった自分は、
インスタンスを選択し、変更ボタンを押し、メンテナンスの時間を正しいものに設定しました。

DBマスターパスワードが勝手に書き換わった！？？

これで「一安心・・・」、と思っていたのですが、
ある日、DBのマスターパスワードが設定したメンテナンスウィンドウの時間に書き換わり、障害がおきました。

この障害が発生した時間はメンテナンスウィンドウを設定した時間だったので、なんとなく嫌な予感はしました。

しかし自分はメンテナンスウィンドウの時間を変更しただけで、マスターパスワードを変えた覚えは全くありませんでした。

サポートに問い合わせるとともに、CloudTrail（マネコンの操作ログ）をチームで確認しました。

CloudTrailを確認すると以下のようなログがながれていました。　

パスワード変更操作が実行されたことを示すログ（ModifyDBClouster）が記録されていました。

    "eventTime": "2019-xx-28Txx:xx:47Z",
    "eventSource": "rds.amazonaws.com",
    "eventName": "ModifyDBCluster",
    ...
    "userAgent": "console.amazonaws.com",
    ...
    "requestParameters": {
        "dBClusterIdentifier": "xxx",
        "applyImmediately": false,
        "masterUserPassword": "****",
        "allowMajorVersionUpgrade": false
    },

何故このようなことが発生したのでしょう。
サポートに問い合わせると以下のような返答がかえってきました。

要約するとプラウザにキャッシュされたパスワードがメンテナンスウィンドウの時間を設定する際に既存のパスワードを書き換えてしまった、ということです。

考えられる要因といたしまして、ブラウザの挙動として異なるインスタンスのパスワードなどが記録されている可能性がございます。
ブラウザの動作と関するため、断定することができませんが、具体的にもし異なるインスタンスで設定されたパスワードがブラウザに記録されている場合、そのパスワードがインスタンスの設定変更時において自動的に「新しいマスターパスワード」の項目へと記載され、パスワードの変更が意図せずリクエストされたことが考えられます。

DBインスタンスを選択し、「変更」ボタンを押すと
その上部に「新しいマスターパスワード」という入力欄があります。

どうやらメンテナンスウィンドウの時間を変更する際に、そこにGoogle Chromeにキャッシュされたパスワードが入ってしまったようです。

DBインスタンスのパスワードは設定したことなどありませんでしたが、このような事象が発生しました。

このようなことを起こさないためにはパスワード保管などを無効にした上で作業をする必要があるそうです。

もし今回の事象がこちらの状況に該当している場合でございましたら、再発防止にあたり、今後の作業時においてパスワードの補完を無効化する、ブラウザに保存されたパスワードを削除するなどをご検討いただければと存じます。

メンテナンスの時間を変更するだけ、という作業なのでいつもより、注意を払わなかった自分にも責任はありますが、
パスワード変更などの操作画面は切り出して欲しいと思いました。。。。

恥ずかしながら自分がはまったポイントについて記載しました。

誰かのお役に立てれば幸いです。

AWS Auroraのメンテナンスウィンドウの仕様を知らず、DBが強制再起動されました。南無・・・