はじめに
VPC private subnetに置かれたRDS Aurora MySQLに対して接続しようとした時、
古くからある手段としては、public subnetに置かれた踏み台EC2を経由してRDSに接続するという方法だと思います。
しかし、以下問題があります。
- EC2のサーバーは稼働しっぱなしでお金がかかる
- サーバーが存在するという事は管理コストがかかる
これをなんとかしたいです。
解決策
現状では、以下が良さそうだと思っています。
- クエリを実行したい場合はRDS Data APIを使う
- mysqldumpコマンドなどのコマンドを実行したい場合はCloudShellを使う
RDS Data APIは、以下参考ください。
※現状ではRDS Data APIはAmazon Aurora PostgreSQLとAmazon Aurora MySQLのみサポートとなります。
CloudShellは、こちらの記事が参考になります。
直近のアップデートにより、ユーザーが作成した VPC 上に CloudShell を起動することでprivate subnet内のリソースに対して CloudShell を利用できるようになっています。
今回は、上記2パターンについて詳しく記載していきたいと思います。
RDS Data API
簡単に言うと、以下の特徴があります。
- AWSの管理画面からSQLを実行できるAPI
- DB クラスターへの永続的な接続を必要としない。セキュア HTTP エンドポイントおよび AWS SDK との統合を利用し、実行単位で接続する
- AWS Secrets Managerに保存された認証情報を使用するか、直接認証情報を設定することでRDSに接続できる
- Aurora クエリエディタを使用してクエリを実行できる
詳しくは、こちらをご覧ください。
手順
1. サービス RDSを選択
2. RDS Data APIの有効化をする
データベース作成時に「RDS Data APIの有効化」をします。
既存のデータベースに対して設定したい場合、データベースを選択し「アクション」から「RDS Data API」を選択することで有効化します。
3. クエリエディタの選択と認証設定
RDSサイドバー上にある「クエリエディタ」を選択します。
- Secrets managerの認証情報を読む場合
因みに、Secrets managerのキーだけお見せします
- 直接認証情報を入力する場合
これらの値を入力及び選択し、「データベースに接続します」を押下することで、
データベースと接続する事が可能となります。
4.クエリを実行してみる
試しにcompaniesテーブルのデータを取得してみます。
取得できました。
また、Export to csv ボタンにより、csv出力も可能となっていますし、
保存ボタンによりクエリを保存することも可能です。
シンプルなUIであり、最低限必要な機能が揃っているので、非常に良きです。
CloudShell
mysqldumpコマンドなどのコマンドを実行したい場合、CloudShellを使うという方法があります。
気づいていない人も多いかもしれませんが、いつも居ます。
画面左下のこれです。
これを使うことでAWSの管理画面上でターミナル（コンソール）を起動することができます。
接続設定の流れ
今回は、以下を実行できる環境を整えたいと思います。
- CloudShellをVPC private subnet内で実行できるようにする
- CloudShellからRDSへ接続できるようにする
- VPCエンドポイントによりVPC private subnetとS3間の接続ができるようにする
※mysqldumpファイルを保管するため
CloudShellをVPC private subnet内で実行できるようにする
VPC環境を作る
CloudShellにはVPC環境という機能があります。
RDSが存在するVPC private subnetを指定し、VPC環境を作成することでRDSに接続できる環境を作ることが可能です。
ターミナル上の「+」ボタンを押下することでVPC環境を作ることができます。
作成が完了すると、「＋」ボタンで、
private subnet内で実行される鍵マークがついた新たなターミナルを起動することができるようになります。
CloudShellからRDSへ接続できるようにする
IPアドレスをRDSセキュリティグループに追加する
CloudShellは、セッションごとにIPが動的に割り振られます。
なので、RDSのセキュリティグループにCloudShellのIPの追加をする必要があります。
CloudShellを立ち上げる度にこの設定をする必要があるので、
自分的にはここがあまり気に入っていない部分ではありますが、EC2無くせるしな〜という気持ちで許容しています。
データベースに接続できるか確認します。
いけましたね〜。
VPCエンドポイントによりVPC private subnetとS3間の接続ができるようにする
目的
運用中の本番環境に対して何か機能の追加をする場合、
本番環境のデータを検証環境に反映した上で、本番環境同等の状況を作り出してから、検証・テストを行うケースが多いと思います。
私の場合、mysqldumpで取得したデータを検証環境に反映する方法を取っています。
RDSスナップショットの復元でも実現可能だとは思いますが、
検証環境で複数パターンの検証を行いたいため、検証→本番相当にデータリセット→検証、を素早くできるようにしたい、という目的があります。
今回のケース
さて、今回は本番環境dumpファイルを、
- 別のVPCにある検証環境に置きたい
- S3に保管もしておきたい
というケースを想定します。
S3はVPC内に存在していないので、
VPC private subnetは何も設定をしなければS3との接続はできません。
接続できるようにするため、今回VPCエンドポイントを設定します。
1. VPCエンドポイントの作成
- VPCダッシュボードに移動
- 「エンドポイント」を選択し、「エンドポイントの作成」をクリック
- サービスカテゴリで「AWSサービス」を選択し、サービス名としてcom.amazonaws..s3（例: com.amazonaws.ap-northeast-1.s3）を選択
2. エンドポイントタイプの選択
ゲートウェイ型またはインターフェイス型のいずれかを選択します。
ゲートウェイ型は追加料金なしで使用でき、S3とDynamoDBに対応しています。
インターフェイス型はPrivateLinkを使用し、オンプレミスからもアクセス可能ですが、各アベイラビリティゾーンごとに料金が発生します。
今回はゲートウェイ型を選択します。
3. VPCとサブネットの選択
エンドポイントを作成するVPCと、そのVPC内のサブネットを選択します。
プライベートサブネットを選ぶことで、インターネット経由ではなく内部ネットワーク経由でS3にアクセスできます。
4. ルートテーブルの関連付け
表示されているルートテーブルから、private subnetが含まれるルートテーブルを選択ください。
設定が終わると、aws s3コマンドを使ってS3バケットとの接続ができるようになっています。
これでdumpファイルをS3に送信することができるようになりました。
あとは、別のVPCにある検証環境にdumpファイルを置きたい場合、CloudShellで検証環境向けのVPC環境を作成し、その環境内でaws s3 cpコマンドを打つことでS3からファイルを取得する事が可能でしょう。
さいごに
RDS Data APIはすぐに設定できるのでオススメです。
今後どんどんと不要なリソースを削除する方向に動いていきたいです。
あらゆる作業・管理がシンプルで簡単になると良いなぁ。