最終回はAWS上でRDB（リレーショナルデータベース）をフルマネージドサービスとして提供しているRDS（Relational Database Service）のつまずきポイントについて解説する。RDSとはMySQLをはじめ、MS SQL ServerやOracle DatabaseなどのRDBを、OSやRDBをインストールすることなくすぐに利用できるサービスである。

　必要なパラメーターをRDS起動時に設定し、起動したRDSは各RDBクライアントから接続して利用する。また、フルマネージドサービスなのでOSやRDBのパッチングについてはユーザーが意識する必要がない。オプションも豊富で、複数のアベイラビリティーゾーンでActive-Standby構成を実現する「Multi-AZ」機能や、参照用RDSを作成する「Read Replica」機能も簡単に設定できる。

　このように便利なサービスなのだが、サービスとして提供されているので制限も存在する。

つまずきポイント1：SSH（RDP）接続ができない

　RDSを起動するとエンドポイントと呼ばれる専用のDNS名が発行される。ユーザーやアプリケーションはこのエンドポイントに接続してRDSを利用することができるのだが、RDSが提供しているインターフェースはエンドポイントへの特定ポートであり、接続可能なプロトコルも限られる。

　このことを知らずに、オンプレミスのDBサーバーのような感覚でOSにログインしようとする初心者は多い。ログインする理由としては、OSに出力されたログを確認しようとしたり、MySQLのプラグインを導入したりするためだ。

　RDSが稼働しているOSにEC2インスタンスと同様にSSHやRDPで接続しても、ログインは不可能だ。AWSの仕様として、RDSが動作するOSへのアクセスはできないようになっている。

　この対策としては、求めているシステム要件がRDSで満たせるかどうかをよく確認することだ。RDSで満たせないと判断した場合には、EC2上にRDBMSをインストールして自前で運用するという選択肢もある。