【速報】マルチAZなRDSもインスタンスの停止に対応しました！

以前はシングルAZなRDSでしか対応していなかったRDSの停止ですが、突如としてマルチAZなRDSでも停止処理に対応しました！！

Amazon RDS Enables Stopping and Starting of Multi-AZ Database Instances

下記、RDSのドキュメントヒストリーに、しっかり記載があります。

Document History - Amazon Relational Database Service

Change Amazon RDS can now stop multi-AZ instances

Amazon RDS can now stop a DB instance that is part of a multi-availability zone deployment. Formerly, the "stop instance" feature had a limitation for multi-AZ instances. For more information,

マルチAZ停止きたか…!!

　 ( ﾟдﾟ)　ｶﾞﾀｯ
　 /　　 ヾ
＿_L| /￣￣￣/＿
　 ＼/　　　/

マルチAZなRDS停止の仕様

公式ドキュメントはこちらを参照。

Stopping an Amazon RDS DB Instance Temporarily - Amazon Relational Database Service

以前のRDSの停止対象はシングルAZのみ

RDSの起動/停止処理がリリースされたのは、2017年6月1日。これは衝撃的でしたね。当時の様子はこちらの記事をご参照ください。

[速報] RDSインスタンスの起動/停止 ｜ DevelopersIO

衝撃は大きかったのですが、マルチAZのRDSには対応していないという制約がありました。この制約が無くなったというのが今回の大きなアップデートです。

RDS停止処理の主な仕様

DBインスタンスが停止している間は、DBインスタンスの起動にかかる時間は課金されません（課金対象なのはストレージのみ）。

マルチAZの停止処理に対応しているデータベースエンジンは以下の通り。

• MariaDB
• MySQL
• Oracle
• PostgreSQL

一点注意点として、Microsoft SQL Serverは、マルチAZの場合の停止処理に対応していません（2018年10月30日時点）。

従来のRDS停止処理と同じく、DBインスタンスの停止は最大7日間停止することが可能。7日後にDBインスタンスを手動で起動しない場合、DBインスタンスが自動的に起動します。

特徴としては、DBインスタンスの停止と起動は、DBスナップショットの作成→スナップショットからの復元よりも高速ということ。DBインスタンスを停止すると、ID、ドメインネームサーバー（DNS）エンドポイント、パラメータグループ、セキュリティグループ、およびオプショングループが保持されます。DBインスタンスを起動すると、停止したときと同じ構成になります。さらに、必要に応じてポイントインタイムリストアを実行できます。

利用上の制限

以下、制限事項になります。

• リードレプリカをもつDBインスタンスの停止不可
• マルチAZなMicrosoft SQL Serverは停止不可
• ミラーリングを使用するMicrosoft　SQL Serverは停止不可
• 停止したDBインスタンス変更はできない
• 停止したDBインスタンスのオプショングループは削除できない
• 停止したDBインスタンスのDBパラメータグループは削除できない

実際に停止処理をやってみた

というわけで、AWSコンソール上でマルチAZなRDSの停止・起動処理を実施します。

マルチAZなMySQLのRDSを作成します。

「インスタンスの操作」ボタンを押すと、停止アクションが選択できるようになっています！

「停止」をクリックすると、「DBインスタンスの停止」画面が表示されています。7日後に起動などの注意書きもありますね。

「はい、今すぐ停止します」をクリックすると、無事停止処理が動きます。

自分が試したのは作成直後のMySQL（8.0.11）、db.t2.micro、ストレージ20GBの最小構成で、停止には約15分ほどかかりました。起動は停止より速く、約3分ほどで起動中になりました。

開発環境や本番環境でのコスト抑制に有用

基本的にデータベースの停止は、開発環境のコスト抑制に非常に有用です。開発環境を本番環境の構成と同一にするためにマルチAZを利用していた場合でも、今回の停止処理の対象化でより簡単にコスト抑制が実現できます。また、ピンポイントでマルチAZなRDSの検証環境を用意しておくのも、従来のスナップショットからの復元よりは起動が高速なので使い所は多そうです（7日後に勝手に起動するところは気をつける必要ありますが）

また、本番環境でも、夜間の利用が全く無かったり週末だけの処理で利用されるデータベースであれば、定期的な停止→起動処理により、コストを大幅に削減できる可能性もあるのではないでしょうか。

最近はAurora ServerlessなどAuroraの進化から目が離せませんが、RDSもどんどん進化しており今後のアップデートが楽しみですね。

それでは、今日はこのへんで。濱田（@hamako9999）でした。