この記事はアイレット25卒社員によるAWSブログリレーのAmazon RDS編です。
Amazon RDSについての概要紹介とハンズオンを実施したので紹介をしたいと思います。
この記事は2025 Japan AWS Top Engineersのクラウドインテグレーション事業部 ソリューション開発セクション 畠山 大治さんに監修していただきました。

目次

  1. Amazon RDSの概要
  2. ローカルマシンからDBへログイン
  3. まとめ

1. Amazon RDS 概要

Amazon RDSはマネージドなリレーショナルデータベースサービスです。6つのDBエンジンが使用可能で、PostgreSQLやMySQL等があります。オンプレミスやAmazon EC2を使ったデータベースデプロイと比較するとハードウェアやソフトウェアの管理が不要です。バックアップや自動的な障害検出、復旧などAWS側で管理します。

主要な機能
サポートされている機能はリージョンや使用するDBエンジンによって異なりますが、ここでは東京リージョンかつ代表的なDBエンジンMySQLでサポートされている機能の一部を紹介します。

  1. ブルー/グリーンデプロイ
  2. クロスリージョン自動バックアップ
  3. クロスリージョンリードレプリカ
  4. RDS Proxy

ブルー/グリーンデプロイ

ブルー/グリーンデプロイの機能を使うことで、本番環境に変更を加える前にステージング環境を作成することでテストを行えます。本番環境(ブルー)の設定や機能を丸々コピーし、ステージング環境(グリーン)へ変更を加えることで、本番環境への影響を与えずに済みます。
変更を終えたら、ステージング環境を本番環境へ切り替えることができます。切り替えには通常1分もかかりません。

クロスリージョン自動バックアップ

障害復旧機能を向上させるため、任意の送信先AWSリージョンへスナップショットとトランザクションログをレプリケーションすることができます。
スナップショットは特定のタイミングのDB内の論理状態(デーブルやデータの関係性等)を保持したもので、トランザクションログとはDB操作の履歴を操作順序を加味して保持したものです。
この2つを別リージョンへレプリケーションすることで、障害が起こった際、DB内の状態を復元します。現在(2025/10/17)、送信元が東京リージョンの場合サポートされているバックアップの送信先は以下の通りです[1]。

送信元 送信先
東京リージョン アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)　米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)

クロスリージョンリードレプリカ

クロスリージョンリードレプリカとは、あるリージョン（例：東京リージョン）に存在するプライマリDBインスタンスのデータを、別のAWSリージョン（例：オハイオリージョン）にリードレプリカとして複製する仕組みです。プライマリDBインスタンスは、メインで使用するDBインスタンスでデータの書込みや読取りが可能なインスタンスです。
一方、リードレプリカは名前の通り読取り専用のインスタンスです。クロスリージョンレプリカも障害復旧機能を向上させるための仕組みですがクロスリージョン自動バックアップと違い、リードレプリカをそのままメインのプライマリDBインスタンスとして使用できるため、復旧までの時間が短縮できます。
また、読取りに関しては、プライマリDBインスタンスだけでなく、リードレプリカに分散させることができるためパフォーマンスの向上も期待できます。

RDSProxy

RDS Proxyは、Amazon RDS および Amazon Aurora データベースに対するフルマネージド型のプロキシサービスです。アプリケーションとデータベースの間を仲介し、主に接続管理と耐障害性の向上という2つの重要な役割を果たします。

  • 接続管理
    1. 接続プーリング：アプリケーションからの接続要求が急増しても、Proxy は一度確立されたDBへの接続を待機場所
      へ移し(プーリング)、それを再利用することで接続確立時の負荷を軽減することができます。
    2. 接続多重化：アプリケーションがDB操作指示待ちの状態(アイドル状態)になった場合、その接続を解放してあげることで別のアプリケーションの接続へ利用するよう切り替えることができます。これによりデータベースが処理できる同時接続数の上限に達することを防ぐことができます[2]。
  • 耐障害性
    1. 自動接続ルーティング: フェイルオーバーが発生した場合、Proxy はアプリケーションに意識させることなく、新しいプライマリ DB インスタンスに接続を自動的かつ迅速に切り替えます。

    RDSProxyのユースケースとしては、サーバレスアプリケーションやEコマースアプリケーションで使用するケースがあります。これらのアプリケーションは多数のデータベース接続に対処するためあらかじめ接続を開いたままにすることで応答速度を短縮する方法を取ることがあるようです。
    この場合、データベースサーバーへの負荷が増加し、クエリ処理などの速度が低下してしまいます。そこで、上記のような接続管理をしてくれるRDSProxyをアプリケーションとデータベースサーバーの間に入れることで、処理の安定を図れるようです。[3]

    2. ローカルマシンからDBへログイン

    今回は、RDSProxyを使用したDBを作成してローカルマシンからDB接続をしてみようと思います。構成は以下の図の通りです。DBクライアントからSystems ManagerのSession Managerを利用してEC2へ接続を開始し、DB接続するといった流れで進みます。こんな方法があるよという一例の紹介です。
    (使用機材：Mac Appleシリコン搭載)

    ※RDSProxyはSecretsManagerからDBユーザ名やログインパスワードを参照するためあらかじめシークレットを作成する必要があります。

    大前提：
    EC2上にSSM エージェントとMySQLがインストールされていること。
    以下のライブラリがローカルのマシンにインストール済みであること。
    (※インストール方法はURL参照公式Doc)
    ・AWS CLI：
    公式ドキュメント(AWS CLI の最新バージョンのインストールまたは更新)
    ・AWS CLI用session managerプラグイン：
    公式ドキュメント(AWS CLI 用の Session Manager プラグインをインストールする)

  • 接続の手順
    1. MySQLインストール(CLI上で接続する場合)
    2. ポートフォワーディングのセッション開始
    3. DBへ接続

    2-1. MySQLインストール(CLI上で接続する場合)

    今回は、CLI上でMySQLのコマンドを実行してDB接続を試すため、あらかじめインストールしておきます。DBツールを使う場合はパッケージがインストールされている場合も多いので必須ではないです。
    MySQLインストールは以下のコマンドで行いました。

    brew install mysql-client

# 確認
mysql --version

    2-2. ポートフォワーディングのセッション開始

    まず、ポートフォワーディングとは、外部からの特定のポート宛ての通信を、内部ネットワーク上の特定のIPおよびポートへ転送する仕組みのことです。ここでは、ローカルマシン(外部)の特定のポートからの通信をAWS環境のVPC上のリソース(内部)へ転送することを意味します。
    Session Managerを利用してEC2へポートフォワーディングし、EC2上にあるSSMエージェントがRDSへの通信を転送するといった仕組みです。セッション開始には以下のコマンドをターミナル上で実行します。

    aws ssm start-session \
--profile [プロファイル名] \
--target [EC2インスタンスID] \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["DBユーザーに応じたRDSProxyエンドポイント"],"portNumber":["3306"],"localPortNumber":["各自指定するPort番号"]}'

    実行結果：
Starting session with SessionId: [アカウント名-hogehoge]
Port [指定したポート番号] opened for sessionId　[アカウント名-hogehoge]
Waiting for connections...

    この状態になると、指定したポートが解放され通信ができるようになります。

    2-3. DBへ接続

    ここで前段の「Waiting for connections…」が表示されたターミナルをそのままにして、別ウィンドウで新しいターミナルを開きます。そこで、MySQLの接続コマンドを打つことでDBへ接続できます。 コマンドは以下のものを打ちました。
    コマンドは、ローカルPCから接続するため「ループバックアドレス」と呼ばれるlocalhostのIPアドレスを指定します。そして、ローカルで開放したポート番号、RDS作成時にマスターユーザーとして登録した名前を指定しています。
    最後の「-p」はパスワードの入力を促すオプションです。このコマンドを実行するとパスワードを聞かれますのでパスワードを入力後、エンターを押すと下記のような結果が返されます。

    mysql -h 127.0.0.1 -P [各自指定したポート番号] -u [マスターユーザー名] -p
Enter password: [シークレットマネージャに登録したパスワード]
ーー以下結果
Welcome to the MySQL monitor. Commands end with ; or \g.
SHOW DATABASES;
Your MySQL connection id is hogehoge
Server version: ○.○.○
ーー略
mysql>

    これでローカルからDBに接続することができました！試しにデフォルトで作成されているDatabaseを確認してみます。

    mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.034 sec)

    デフォルトだと、この4つが作られているようです。RDSインスタンス作成時にデータベース名を指定すれば自動で作ってくれるようですが完全に失念、無念。

    3. まとめ

    簡単にRDSの概要を見たあと、ローカルマシンからRDSへ接続する方法を紹介しました。RDSへ接続する方法は他にもあるようなのですが、ssh接続のために秘密鍵を保存したファイルを用意しなければならず、セキュリティ的な不安もあるようです。
    今回紹介したものは、機密情報が書かれたファイルが流出する懸念がないという点でセキュアな接続方法になります。参考にしていただけると幸いです。
    また、Amazon RDSについては、同じく25卒社員の佐藤 優太さんも紹介していますのでこちらも是非みてください。

    参考：
    [1]. https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html
    [2]. https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/amazon-rds-proxy/targeted-business-outcomes.html
    [3]. https://aws.amazon.com/jp/rds/proxy/