はじめに
AWSのセキュリティベストプラクティスにおいて、RDSやAuroraなどのデータベースインスタンスはプライベートサブネットに配置することが強く推奨されます。しかし、開発時のメンテナンスやトラブルシューティングのために、ローカルの開発環境やGUIツールから安全に接続したい場面が多々あります。
本記事では、踏み台サーバー(EC2)のSSH(22番ポート)をインターネットに公開することなく、AWS Systems Manager(SSM)のセッションマネージャーを利用して、プライベートサブネット内のAuroraにセキュアに接続する環境の設計と構築手順を分かりやすく解説します。
前提知識/必要な理由
従来の踏み台サーバー運用では、パブリックサブネットにEC2を配置し、セキュリティグループで特定のIPアドレスからのSSH接続(ポート22)を許可する方法が一般的でした。しかし、この方法には以下のリスクが存在します。
- SSHキーペアの管理負荷と漏洩リスク
- リモートワークなどで接続元IPが頻繁に変わる場合の運用負荷増大
- インターネット上にSSHポートが露出することによる不正アクセスの標的化
SSMセッションマネージャーの「リモートホストへのポートフォワーディング」機能を利用することで、踏み台EC2へのインバウンド接続をすべて塞いだ状態で、AWSのAPI経由でセキュアなトンネリングを確立できます。これにより、インターネット経由の侵入経路を完全に遮断しつつ、ローカルPCからプライベートデータベースへの接続が可能になります。
具体的な設定手順・設計方法
1. 踏み台EC2インスタンスの作成とIAMロール付与
まずは、プライベートサブネットに踏み台用となるEC2インスタンスを作成します。OSは標準的なAmazon Linux 2023を推奨します。
作成したEC2インスタンスがSSMサービスと通信できるように、以下のAWS管理ポリシーを付与したIAMロールを作成し、インスタンスプロフィールとしてEC2にアタッチします。
- AmazonSSMManagedInstanceCore
2. セキュリティグループの設定
最小特権の原則に従い、セキュリティグループのルールを厳しく制限します。
踏み台EC2用セキュリティグループ
- インバウンドルール: なし(完全に空にします)
- アウトバウンドルール: HTTPS (443) をすべて(またはSSMのVPCエンドポイント)に向けて許可
Aurora用セキュリティグループ
- インバウンドルール: データベースのポート(MySQL: 3306、PostgreSQL: 5432)を、踏み台EC2用のセキュリティグループからのみ許可
- アウトバウンドルール: 任意
3. ローカルPC側の環境準備(プラグインの導入)
ローカルPCからSSM経由でポートフォワーディングを実行するには、AWS CLIのほかにSession Manager Pluginをインストールする必要があります。
macOSの場合 (Homebrewを使用):
# Homebrewを使用してプラグインをインストール
brew install --cask session-manager-plugin
Windowsの場合 (PowerShellを使用):
# インストーラーをダウンロードして実行
Start-BitsTransfer -Source "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows_amd64/SessionManagerPluginSetup.exe" -Destination "C:\SessionManagerPluginSetup.exe"
Start-Process -FilePath "C:\SessionManagerPluginSetup.exe" -ArgumentList "/S" -Wait
4. SSMポートフォワーディングの実行
ローカルPCのターミナルまたはPowerShellから、以下のAWS CLIコマンドを実行します。これにより、ローカルPCの特定ポート(例:15432)へのアクセスが、踏み台EC2を経由してAuroraへ転送されます。
# Aurora PostgreSQLへのポートフォワーディング接続コマンド例
aws ssm start-session \
--target "i-0xxxxxxxxxxxxxx" \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{
"host": ["aurora-cluster-endpoint.cluster-xxxxxxxx.ap-northeast-1.rds.amazonaws.com"],
"portNumber": ["5432"],
"localPortNumber": ["15432"]
}'
コマンドの実行に成功すると「Waiting for connections…」と表示されます。この状態を維持したまま、ローカルPCのデータベース管理ツール(DBeaverなど)から localhost:15432 宛てに接続を行います。
実務での注意点
- プライベートEC2のSSM接続性の確保: 踏み台EC2が配置されているプライベートサブネットから、SSMのAPIエンドポイントにアクセスできる必要があります。NAT Gatewayを経由してインターネット経由で接続するか、もしくはVPC内にSSM用のVPCエンドポイント(ssm, ssmmessages, ec2messages)を配置してください。
- セッションタイムアウト: Session Managerにはデフォルトでアイドル接続のタイムアウトが設定されています。長時間の大規模クエリやデータ移行を行う場合は、Systems Managerの管理画面からタイムアウト時間の変更を検討してください。
- AWS IAMによる制御: 開発者に踏み台EC2へのSSM接続を許可する際は、IAMポリシーでターゲットとなるEC2インスタンスID(
i-0xxxxxxxxxxxxxx)をリソース制限し、不要なリソースへのアクセスを防ぐように制限してください。
まとめ
AWS Systems Managerを利用したプライベートデータベースへの接続方法は、セキュリティと利便性を両立する強力なソリューションです。従来の「SSHキーの紛失」や「IPアドレス制限のメンテナンス」といった運用コストを大幅に削減できます。ぜひ本手順を参考に、セキュアなインフラ設計を実務に取り入れてみてください。