踏み台EC2を無くすためにAmazon Aurora MySQLのRDS Data APIとCloudShellを使ってみた

# はじめに
VPC private subnetに置かれたRDS Aurora MySQLに対して接続しようとした時、
古くからある手段としては、public subnetに置かれた踏み台EC2を経由してRDSに接続するという方法だと思います。

しかし、以下問題があります。
- EC2のサーバーは稼働しっぱなしでお金がかかる
- サーバーが存在するという事は管理コストがかかる

これをなんとかしたいです。

# 解決策
現状では、以下が良さそうだと思っています。

- クエリを実行したい場合はRDS Data APIを使う
- mysqldumpコマンドなどのコマンドを実行したい場合はCloudShellを使う

RDS Data APIは、以下参考ください。

https://aws.amazon.com/jp/about-aws/whats-new/2024/09/amazon-aurora-mysql-rds-data-api/

※現状ではRDS Data APIはAmazon Aurora PostgreSQLとAmazon Aurora MySQLのみサポートとなります。

CloudShellは、こちらの記事が参考になります。

https://dev.classmethod.jp/articles/cloudshell-vpc-environment/

直近のアップデートにより、ユーザーが作成した VPC 上に CloudShell を起動することでprivate subnet内のリソースに対して CloudShell を利用できるようになっています。





今回は、上記2パターンについて詳しく記載していきたいと思います。

# RDS Data API

簡単に言うと、以下の特徴があります。

- AWSの管理画面からSQLを実行できるAPI
- DB クラスターへの永続的な接続を必要としない。セキュア HTTP エンドポイントおよび AWS SDK との統合を利用し、実行単位で接続する
- AWS Secrets Managerに保存された認証情報を使用するか、直接認証情報を設定することでRDSに接続できる
- Aurora クエリエディタを使用してクエリを実行できる

詳しくは、こちらをご覧ください。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/data-api.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/query-editor.html

## 手順

### 1. サービス RDSを選択


### 2. RDS Data APIの有効化をする

データベース作成時に「RDS Data APIの有効化」をします。
既存のデータベースに対して設定したい場合、データベースを選択し「アクション」から「RDS Data API」を選択することで有効化します。


https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/data-api.html#data-api.enabling

### 3. クエリエディタの選択と認証設定

RDSサイドバー上にある「クエリエディタ」を選択します。

- Secrets managerの認証情報を読む場合
![スクリーンショット 2024-10-25 11.01.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730383/1947aab4-feba-6090-6c5e-c4f2b1524993.png)

因みに、Secrets managerのキーだけお見せします

![スクリーンショット 2024-10-25 11.11.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730383/d96b5c82-55c2-d946-5826-55bd16e6244c.png)



- 直接認証情報を入力する場合
![スクリーンショット 2024-10-25 11.01.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730383/8a21fe12-2ad7-e2d4-cecb-ed21734dcc7c.png)

これらの値を入力及び選択し、「データベースに接続します」を押下することで、
データベースと接続する事が可能となります。

### 4.クエリを実行してみる

試しにcompaniesテーブルのデータを取得してみます。

![スクリーンショット 2024-10-25 11.13.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730383/bc85e6ac-019f-9ddc-93c7-df252658121d.png)

取得できました。
また、Export to csv ボタンにより、csv出力も可能となっていますし、
保存ボタンによりクエリを保存することも可能です。

シンプルなUIであり、最低限必要な機能が揃っているので、非常に良きです。

# CloudShell

mysqldumpコマンドなどのコマンドを実行したい場合、CloudShellを使うという方法があります。
気づいていない人も多いかもしれませんが、いつも居ます。
画面左下のこれです。

![スクリーンショット 2024-10-25 14.00.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730383/5260afdd-06d2-a1a7-1e18-a8120e57c0b8.png)

これを使うことで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に接続できる環境を作ることが可能です。

https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/creating-vpc-environment.html

ターミナル上の「+」ボタンを押下することでVPC環境を作ることができます。

作成が完了すると、「＋」ボタンで、
private subnet内で実行される鍵マークがついた新たなターミナルを起動することができるようになります。

## CloudShellからRDSへ接続できるようにする
### IPアドレスをRDSセキュリティグループに追加する

CloudShellは、セッションごとにIPが動的に割り振られます。
なので、RDSのセキュリティグループにCloudShellのIPの追加をする必要があります。

CloudShellを立ち上げる度にこの設定をする必要があるので、
自分的にはここがあまり気に入っていない部分ではありますが、EC2無くせるしな〜という気持ちで許容しています。

![スクリーンショット 2024-10-25 14.12.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730383/a23493fb-a26c-bd84-b22f-be51d7b10222.png)

データベースに接続できるか確認します。
![スクリーンショット 2024-10-25 11.58.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730383/346bbe5f-ea48-5517-e78e-cd2c70811d17.png)

いけましたね〜。

## VPCエンドポイントによりVPC private subnetとS3間の接続ができるようにする

### 目的
運用中の本番環境に対して何か機能の追加をする場合、
本番環境のデータを検証環境に反映した上で、本番環境同等の状況を作り出してから、検証・テストを行うケースが多いと思います。

私の場合、mysqldumpで取得したデータを検証環境に反映する方法を取っています。
RDSスナップショットの復元でも実現可能だとは思いますが、
検証環境で複数パターンの検証を行いたいため、検証→本番相当にデータリセット→検証、を素早くできるようにしたい、という目的があります。

### 今回のケース
さて、今回は本番環境dumpファイルを、
- 別のVPCにある検証環境に置きたい
- S3に保管もしておきたい

というケースを想定します。

S3はVPC内に存在していないので、
VPC private subnetは何も設定をしなければS3との接続はできません。

接続できるようにするため、今回VPCエンドポイントを設定します。

### 1. VPCエンドポイントの作成

- VPCダッシュボードに移動
- 「エンドポイント」を選択し、「エンドポイントの作成」をクリック
- サービスカテゴリで「AWSサービス」を選択し、サービス名としてcom.amazonaws.<region>.s3（例: com.amazonaws.ap-northeast-1.s3）を選択

### 2. エンドポイントタイプの選択
ゲートウェイ型またはインターフェイス型のいずれかを選択します。
ゲートウェイ型は追加料金なしで使用でき、S3とDynamoDBに対応しています。
インターフェイス型はPrivateLinkを使用し、オンプレミスからもアクセス可能ですが、各アベイラビリティゾーンごとに料金が発生します。

今回はゲートウェイ型を選択します。

### 3. VPCとサブネットの選択
エンドポイントを作成するVPCと、そのVPC内のサブネットを選択します。
プライベートサブネットを選ぶことで、インターネット経由ではなく内部ネットワーク経由でS3にアクセスできます。

### 4. ルートテーブルの関連付け
表示されているルートテーブルから、private subnetが含まれるルートテーブルを選択ください。


設定が終わると、aws s3コマンドを使ってS3バケットとの接続ができるようになっています。

![スクリーンショット 2024-10-25 12.37.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730383/ecb0c236-412f-79c4-4520-65e2fc1106d3.png)

これでdumpファイルをS3に送信することができるようになりました。
あとは、別のVPCにある検証環境にdumpファイルを置きたい場合、CloudShellで検証環境向けのVPC環境を作成し、その環境内でaws s3 cpコマンドを打つことでS3からファイルを取得する事が可能でしょう。

# さいごに

RDS Data APIはすぐに設定できるのでオススメです。

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