はじめに

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はすぐに設定できるのでオススメです。

今後どんどんと不要なリソースを削除する方向に動いていきたいです。
あらゆる作業・管理がシンプルで簡単になると良いなぁ。