こんにちは。テクニカルサポート課の森本です。
仰々しいブログタイトルとなっていますが、先日 Aurora MySQL の特定のリーダーインスタンスのみ個別のセキュリティグループの設定ができるか？という問い合わせを受けた際にちょっと調べて考えたことをまとめます。
前提
本記事は Auora/RDS の中でも MySQL/PostgreSQL のデータベースエンジンで実現可能な内容が中心となっています。
Aurora ではクラスター単位でしかセキュリティグループの設定ができない
Auroraでは同一クラスター内の DB インスタンスに個別のセキュリティグループの設定ができず、クラスター単位での設定となります。
Aurora クラスターに属する 個別の DB インスタンスの変更は modifyDBInstance API により 可能であり、その中でセキュリティグループの変更もできそうには見えます。
しかし CloudTrail を確認すると、セキュリティグループの変更の場合は modifyDBInstance API 実行後に内部的に modifyDBCluster API および ModifyNetworkInterfaceAttribute API が実行されており、 一つの DB インスタンスの変更が全ての DB インスタンスに伝搬するような動作となっておりました。
個別のセキュリティグループが設定できない構成例
DB インスタンス単位でセキュリティグループの設定ができない例は以下のような構成です。
- 単一の Aurora クラスター内の ライター/リーダー DB インスタンス(前述の例)
- RDS マルチ AZ 配置の プライマリ/セカンダリ DB インスタンス
- RDS マルチ AZ DB クラスター配置 のライター/リーダー DB インスタンス
これらの構成の共通点は、プライマリ/ライター DB インスタンスに不具合があった際、自動でフェイルオーバーが行われるということです。
個別のセキュリティグループが設定できる構成例
一方で、DB インスタンスに個別のセキュリティグループを設定できるのは以下のような構成です。
- RDS のプライマリ DB インスタンス/リードレプリカ
- RDS のプライマリ DB インスタンス/Aurora レプリカ
- Aurora/RDS のBlue/Green Deployment における Blue/Green 環境*1
- Aurora/RDS のプライマリDBインスタンス/クロスリージョンリードレプリカ*2
- Aurora Global Database のプライマリ/セカンダリ DB クラスター
これらの構成の共通点は、不具合があった際も自動でフェイルオーバーが行われず、プライマリへの昇格の際に手動での介入が必要となるということです。
また 4. や 5. の場合は配置するリージョン(およびVPC)が異なるため、そもそも同じセキュリティグループを設定することができません。
まとめ
今回の調査を通じて、DB インスタンスへの個別のセキュリティグループの設定可否が、自動フェイルオーバーするかどうかによって分かれている(らしい)ことがわかりました。
自動フェイルオーバー後にもアプリケーションからの通信を制限しないような設計となっていると読み取ることができ、よく考えられてるな〜と感じた次第です。
意外だったのは Blue/Green Deployment でクラスター単位で別のセキュリティグループが設定可能なことです。確かにスイッチオーバーは手動で行うのですが、実際にスイッチオーバーを行う際は同じセキュリティグループにしておくとセキュリティグループによる意図しない通信の不具合は防げそうです。
余談
今回のお客様のお問い合わせの場合、背景として特定のリーダーインスタンスには特定のアプリケーションからしか接続しないため、アクセスをしぼった方がセキュリティが向上するのではないか、といった背景がありました。
残念ながら Aurora クラスターの仕様上、単一のAuroraクラスターでは実現できない事例でしたが、別の Aurora クラスターへのバイナリログによるレプリケーションを利用すればご要望の一部は実現可能ではないか、と回答させていただきました。
今回のように仕様による制限がある場合も背景をお伝えいただければ代替案をご提案できる可能性もあるので、やはりお問い合わせいただく際は背景までご共有いただけるとありがたいと改めて感じたお問い合わせでした。
その他テクニカルサポートにお問い合わせいただく際のコツなどは弊社佐藤のブログをご一読いただければ幸いです。
この記事がどなたかのお役に立てば幸いです。
