ローカルからプライベートサブネットにいるRDSに接続するためにNLBを踏み台にしてみた

ローカル環境からVPCのプライベートサブネット上にいるRDSにアクセスしたいとき、パブリックサブネットにEC2インスタンスを置いて踏み台として利用することが多いかと思います。

ですがEC2インスタンスの管理・運用をしたくありません。そこで、代わりにNLBを使う構成を考えてみました。

注意事項

先にお伝えしておきますが、この構成はあまりおすすめしません。後述のデメリットの部分についてしっかりご認識のうえご利用いただければと思います。

踏み台EC2インスタンスを置く構成と比較してのメリット・デメリット

メリット

前述のとおり、EC2インスタンスの管理・運用をユーザー側で行なう必要がないことです。

デメリット

• NLBのターゲットとしてRDSを指定するには、ターゲットの種類をIPにする必要があります。RDSインスタンスのIPを登録することになります。ですので、インスタンスフェイルオーバーによってインスタンスのIPが変わった場合疎通不可になります。手動でNLBターゲットのIP値を書き換える必要があります。（Lambda関数を書くなどすれば自動化できるかもしれませんが、今回の範囲外とします
• 踏み台EC2インスタンスを使う場合、SSH鍵認証が利用できます。ですがこの構成だと鍵認証はできません。ID・パスワード認証になります。
• SSHの場合は通信経路の暗号化もできます。このNLB構成で通信経路の暗号化を実現したい場合は、リスナーでTLS (セキュアTCP)を利用する必要があります。TLS (セキュアTCP)ではなく、TCPを選択すると通信経路暗号化はされません。（後述の「やってみた」ではTCPを選択しています）
• NLBエンドポイントは外部からアクセス可能です。IP制限を書けたいところですが、NLBにはセキュリティグループをアタッチできません。そのためネットワークACLでIP制限することになるかと思います。

RDSをパブリックアクセス可能にしてしまえば？

そうですね。。RDSをパブリックサブネットに置きパブリックアクセス可能にする構成の方がシンプルで良いですね。

ですが、実は今回の案件では制約として、アクセス元(ローカル)が所属するネットワークのファイアウォールがウェルノウンポート以外のアウトバウンドをブロックする、というものがありました。

またRDSは、インスタンス接続に使うポートは1150番以上にする必要があります。

というわけで、今回の場合はパブリックアクセス構成では要件を満たしません。

一方、NLBはリスナーポートをウェルノウンポートにすることができ、かつNLB-RDS間通信は1150番以上のポートを使うこともできます。というわけで今回の制約条件上でもアクセスできそうです。（とはいえファイアウォールルールの抜け道を利用するような方法なので、この方法が良いかどうかは微妙なところです。）

または、正攻法でファイアウォールルールを社内システム部に変更申請（=IP xx.xx.xx.xxへの○番ポートアウトバウンドを許可してください）する場合でもNLB案には優位点があります。パブリックアクセス構成の場合、前述の通りフェイルオーバーが発生するたびにアクセス先インスタンスが変わるので、IPも変わります。都度ファイアウォールルール設定変更申請をするのは煩雑かと思います。

一方、NLBにはElastic IPを付与して固定IPを持たせることができます。ですのでそのElastic IPの特定ポートに対するアウトバウンド許可さえ設定してしまえば、以後設定変更申請する必要がありません。

やってみた

手順の大枠は以下です。

1. VPC作成
2. ネットワークACLでIP制限
3. DBサブネットグループ作成
4. セキュリティグループ作成
5. Auroraクラスター作成
6. ターゲットグループ作成 & ターゲット登録
7. Elastic IP作成
8. NLB作成
9. セキュリティグループ修正

VPC作成

以下構成のVPCを作成します。

VPC作成の手順について今回は割愛します。この部分についてわからない方は、以下リンク先にて学ばれるのをおすすめいたします。

ネットワークACLでIP制限

パブリックサブネットに紐付けるネットワークACLのインバウンドルールをふたつ追加して、80番ポートへのインバウンドはローカルIPからのみ許可するようにします。

DBサブネットグループ作成

プライベートサブネット2つを選択します。

セキュリティグループ作成

Auroraクラスターにアタッチするセキュリティグループです。インバウンドルールにパブリックサブネットのCIDRを指定することで、NLBからのインバウンドを許可します。

Auroraクラスター作成

今回はAuroraを採用しましたが、（Auroraではない）RDSでも構いません。

作成したDBサブネットグループとセキュリティグループを使います。

ターゲットグループ作成 & ターゲット登録

プロトコルはTCPを選択してください。

次のページ、ターゲットIPにはAuroraプライマリインスタンスのIPを登録します。

• クラスターの書き込みエンドポイント((DB識別子).cluster-(DB識別子).rds.amazonaws.com)
• プライマリインスタンスのエンドポイント((DB識別子)-instance-1.(DB識別子).rds.amazonaws.com)

いずれかを使って$ dig (エンドポイント) +short でIPを確認します。そのIPを以下の「IP」欄に入力します。

「保留中として以下を含める」クリックを忘れないように。

Elastic IP作成

NLBにアタッチする予定のElastic IPを作成します。アベイラビリティーゾーン毎にIPが必要になるので、2つ作成します。

NLB作成

アベイラビリティーゾーン欄でElastic IPを使うように設定します。

セキュリティグループ修正

ElasticIPをアタッチすると、プライベートIPも決定されます。ですので、このプライベートIPをAuroraクラスターにアタッチするセキュリティグループのインバウンドルールCIDRとするとより厳密なトラフィック制御ができます。

接続テスト

Pオプションでポートを指定します。

$ mysql -h nlb-aurora-test-xxxxxxxx.elb.ap-northeast-1.amazonaws.com -u (マスターユーザー名) -p -P 80
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1389
Server version: 5.6.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

接続できました！

他の選択肢

まずは、VPNやDirect Connectなどでローカル環境も閉域網の中に入れてしまうという方法が考えられます。そうしてしまえば踏み台を設置することなく直接接続できます。Client VPNを利用するのが一番手っ取り早いかと思います。

また、 Cloud9を踏み台として利用することを検討された方もいらっしゃいます。

他には、実際やってみたことはありませんが、AppStream2.0でMySQL WorkbenchなどのDBクライアントツールを配信する方法も実現できるのではないかなと思います。

あわせて読みたい