【脱・踏み台/VPN】AWS Verified Accessでローカル DBeaver から プライベートRDS(Aurora Postgres)への接続を試してみた

はじめに：プライベートDBアクセスの「あの手間」

ローカル端末のDBクライアント（DBever や DataGrip）からプライベートサブネットにある Aurora や RDS に接続するには、いくつかの定番の方法があります。

• パブリックなEC2を立てて、SSHポートフォワーディング
• プライベートなEC2やFargateを立ててSSMポートフォワーディング
• クライアントVPNエンドポイントを設定して、端末にVPNクライアント入れて接続

これらの方法は確実ですが、「ちょっとDBのデータ確認したいだけ」の割に、セットアップや日々の運用が地味に面倒なのが正直なところ。
踏み台サーバーの管理コスト、CLIコマンド実行のための準備、VPNクライアントの管理など、どれも「うーん、この手間…」となる作業が伴います。

そんな中、AWS Verified Access (AVA) が 非HTTPリソース に対応していることを最近になって知り、「これならVPNも踏み台もなしでローカルPCから簡単にAurora に繋げるのでは？」と思い、試してみました。

AWS Verified Access (AVA) とは？

ざっくり言うと、「AWS版のゼロトラスト・ネットワークアクセス(ZTNA)」サービスです。
これまではHTTPS(Webアプリ)へのアクセス制御がメインでしたが、2025年2月6日のアップデートで TCP/UDP (非HTTP) にも対応しています。

つまり、PostgreSQL(TCP/5432)などのデータベース通信も、IdP(IAM Identity Centerなど)で認証されたユーザーだけがアクセスできるようになる、という代物です。

やったこと：AVA経由でローカルDBeaverからAuroraへ

1. 全体像（構成図）

今回目指した構成はこんな感じです。ローカルPCの DBeaver から、インターネット経由で Verified Access エンドポイントにアクセスすると、認証(IdP)を経て、プライベートサブネットの Aurora PostgreSQL に接続できる、という流れです。

2. AWS側の設定

基本的には、AVAのインスタンスやグループを作成し、最後にエンドポイントを Aurora に関連付けます。

ステップ1: Verified Access信頼プロバイダーの作成

まずは認証の土台。IAM Identity Centerを信頼プロバイダーとして設定します。
(この時点ではコストはかかりません)

ステップ2: Verified Accessインスタンスの作成

次にVerified Accessインスタンスを作成し、ステップ1の信頼プロバイダーと統合します。
(この時点でもコストはかかりません)

ステップ3: Verified Accessグループの作成

ステップ2のVerified Accessインスタンスをグループにアタッチします。
(これもまだコストはかかりません)

ステップ4: Verified Accessエンドポイントの作成 (最重要！)

ここで初めてDBへの接続口を作ります。このステップで設定項目がいくつかあります。
(このエンドポイントを作成した瞬間から $0.20/時間 の課金が開始されます！)

設定項目（抜粋）

• プロトコル: TCP
• エンドポイントタイプ: Amazon Relational Database Service (RDS)
• RDS ターゲットタイプ: RDS cluster (Aurora用) を選択
• RDS エンドポイント: Aurora のクラスターエンドポイント (Writer) を選択
  • 注意: Aurora の場合、Writer と Reader は別々のエンドポイントです。両方にAVA経由でアクセスしたい場合は、それぞれ個別にAVAエンドポイントを作成する必要があります。
• ポート: 5432 (PostgreSQL)
• サブネット: Aurora がいるプライベートサブネットを指定（AVAのエンドポイントENIがこのサブネットに作成されます）
• セキュリティグループ: Verified Accessエンドポイント用のセキュリティグループを指定
  • このセキュリティグループは、以下のように設定しておきます。
    • インバウンドルール: 特になし
    • アウトバウンドルール: 宛先をAuroraのSG、ポートは5432で許可

ポリシー定義設定(最重要ハマりポイント)

同じく「Verified Accessエンドポイントの作成」画面の下部に「ポリシーの詳細 - オプション」があります。
これが最大の罠でした。ここはオプションと書かれていますが、ポリシーを設定せず（空白のまま）作成を完了したところ、クライアント側設定してもDBに全く繋がりませんでした。
「なぜだ？」と思いドキュメントを漁ったところ、以下のような記載がありました。

(AWSドキュメントより引用)
"You can create a group or endpoint without defining the Verified Access policy, but all access requests will be blocked until you define a policy."
(ポリシーなしで作成できるが、定義するまですべてのアクセスはブロックされる)

つまり、デフォルトは全拒否 だったのです。（Verified Accessグループ側でポリシーの設定をしていれば別ですが、今回は両方空白でした）

そこで、ひとまず疎通確認のため、このポリシー欄に「すべてを許可する」ポリシーを設定しました。

permit(principal, action, resource)
when {
    true
};

これを設定した途端、無事に接続できました！
しかし、本来は when { ... } の中に context.idc.user.email.address == "[e-mail]" のように、IdPから渡されたユーザー情報を使って厳密に制御すべきです。

ステップ5: 接続先 (Aurora) 側のSG設定

接続先であるAuroraにアタッチされているセキュリティグループにも設定変更が必要です。
インバウンドルールに、ソースがVerified AccessエンドポイントのSG ID、ポート 5432 を許可するルールを追加します。

3. クライアント側の設定

AWS側の準備ができたら、次はローカル端末の設定です。

Connectivity Client のインストール

AWSのコンソールから専用のクライアント (Windows/macOS用) をダウンロードしてインストールします。
インストール方法は以下公式ドキュメントを参照しました。

クライアント設定ファイルの配置

コンソール画面からVerified Accessインスタンスを選択し、クライアント設定ファイルをエクスポートした後、エクスポートしたファイルをローカル端末の指定の場所に配置します。

• Windows – C:\ProgramData\Connectivity Client
• macOS – /Library/Application\ Support/Connectivity\ Client

Connectivity Client起動

Connectivity Client を起動すると、ブラウザが開き IdP (IAM Identity Center) の認証が求められます。

認証が成功すると、クライアントが「接続済み」になります。

4. DBeaverでの接続設定

ここまで来れば、あとは DBeaver の設定だけです。

まずは、AVAエンドポイントドメインをコピーします。 (AWSコンソールの[Verified Access Endpoints]から取得)

次に、DBeaverを起動し以下のように設定します。
Host: AVAエンドポイントドメイン
Database: データベース名
SSL mode: require

「接続テスト」をクリックすると、成功しました！
ローカルPCから、VPNも踏み台も使わずにプライベートな Aurora に接続できました！

ついでにデータ参照も以下の通りできました。

気になるコストは？

便利ですが、コストはどうでしょうか。
調査したところ、非HTTPリソース（今回の場合）の料金は以下の2つでした。

• エンドポイント時間料金: $0.20 / 時間

  • これがメインのコストです。AVAエンドポイントを作成している間、ずっと課金されます。
  • Aurora の Writer と Reader で2つ作ったら、\$0.40/時間 です。
    (参考: 1ヶ月(730h)出しっぱなしだと \$0.20 * 730h = $146/月)

• 接続料金: $0.001 / 接続時間

  • ただし、エンドポイント1つにつき、1時間あたり最大100回まで無料枠があるので、DBeaverでたまに接続する程度なら、接続料金については無料枠で十分収まりそうです。

まとめ：踏み台・VPN管理から解放されよう

AWS Verified Access の非HTTP対応は、DBアクセスの面倒な管理（踏み台のメンテ、VPNライセンス、IP管理...）から我々を解放してくれる素晴らしいアップデートでした。
IdPでの認証が強制されるため、セキュリティ的にも従来の方法より堅牢です。
「エンドポイントの時間課金」 という点だけ注意が必要ですが、それを補って余りある快適さでした。
DBアクセスに課題を感じている方は、ぜひ試してみてください！

参考にしたドキュメント