Amazon Aurora Cluster のリーダーエンドポイントに騙されないで！
はじめに
最近はクラウドに触れる時間が減少気味の @___nix___ です。
背景
みなさん、Amazon Aurora を利用されている方も多いかと思います。
更新系のエンドポイント(Writer Endpoint)と参照系のエンドポイント(Reader Endpoint)が分かているのは非常に嬉しい機能の一つですね。
概要
今回、この参照系エンドポイント(Reader Endpoint)の落とし穴をご紹介しようと思います。
既に常識になっている方もいるかと思いますが、この Reader Endpoint 経由で接続してもデータの更新が出来てしまうケースがあります。
「DBユーザーは更新権限を与えているが、 Reader Endpoint に接続しているので安心！」という方は注意です。
詳細
一般的な Aurora Cluster
Writer Instance と Reader Instance (Replica) の一般的な構成です。
今回この構成になっている場合は「安心」して頂いて構いません。
Writer Instance 単体の Aurora Cluster
以下のように Writer Instance のみで運用している場合は「注意」です。
このような構成でも Amazon Aurora では Writer Endpoint と Reader Endpoint をあたかも問題が無いかのように提供してくれますが、ポイントは「★Reader Endpoint」の部分です。
この構成の場合、「★Reader Endpoint」に接続しても更新系クエリ（INSERT/UPDATE/DELETE）が実行できてしまいます。
解説
元々 Writer と Reader の権限はインスタンス単位で設定されています。
つまり、Writer Instance のみが存在する場合、権限は Writer の設定になっていますので、 Reader Endpoint に接続しても接続しているのは Writer Instance であるということです。
Reader Endpoint と Writer Endpoint のIPを調べてみると以下の通りIPが同じ（＝Writer も Reader も同じインスタンス）であることが分かります。
# dig <Reader Endpoint> a +short
xxxx.<region>.rds.amazonaws.com.
192.0.2.86
# dig <Writer Endpoint> a +short
xxx.<region>.rds.amazonaws.com.
192.0.2.86
【付録】RDS Proxy を利用しているケース
RDS Proxy で単体運用している場合、RDS Proxy で Reader に繋いでもエラーとなるのでこのような事故には繋がりません。
これについては公式サイトでも以下のように記載されています。
注記
新しいエンドポイントが読み取り専用であることを指定する場合、RDS Proxy は Aurora クラスターに 1 つ以上のリーダー DB インスタンスがあることを必要とします。場合によっては、プロキシのターゲットを、シングルライターのみを含む Aurora クラスターに変更することがあります。この場合、リーダーエンドポイントへのリクエストはすべてエラーになり、失敗します。プロキシのターゲットが Aurora クラスターではなく RDS インスタンスである場合も、リクエストは失敗します。
結論
Writer Endpoint を使って参照権限を付与する運用のケースでは必ずレプリカを作成し、Reader Instance を作成するようにしましょう。
また、Serverless v2 等で運用している場合も、Writer がスケールしても Writer でしかありませんので、Reader Endpoint を利用する時は明示的に Reader Instance を作成しましょう。
終わりに
「Reader Endpoint に接続していれば安心」と思っていた方がおりましたら注意しましょうね。
参照権限だから雑に扱っても大丈夫ってことにはなりませんので。
一言
この記事良かったと少しでも思って頂けたら是非 @___nix___ をフォローしてあげてください。或いは記事に対してリアクションをお願い致します。
Discussion