1. はじめに
- 前回の記事「AWS Privatelink (NLB不要版) を使ってみる」にて、別のVPCからのアクセスを従来のNLBではなくResource Gatewayを用いて受け付ける構成について検証した。
- 前回の記事ではResource Gatewayを用いて、EC2インスタンス(nginx)に対して外部から接続する設定としたが、本記事ではEC2インスタンスではなく、RDSインスタンス(RDS for Oracle)に対しての接続を設定し動作確認を行い、どこが違うのかなどを確認する。
2. やったこと
- VPC1にRDS for Oracle(接続される用)を作成
- VPC1にResource Gateway/Resource Configuration(VPC外からの接続を受けるための設定)を作成
- VPC2にOracleのクライアント(sqlplus)を作成
- VPC2にResource Endpoint(VPC1のResource Configurationと繋ぐためのEndpoint)を作成
- VPC2のクライアントから上記の経路を使用してVPC1のRDS for Oracleへ接続
- RDS for Oracle のAct/Sbyの系切替をしても切替後に接続できることを確認
3. 構成図
4. 手順
4.1 事前準備
- VPC1/VPC2を作成し、VPC1側にResource Gatewayを作成する。手順は前回の記事「AWS Privatelink (NLB不要版) を使ってみる」を参照。
- VPC1内にRDS for Oracle をスタンバイインスタンス有りで作成する。手順は以前の記事「【初心者】いまさら Amazon RDS for Oracle に入門するを参照。
4.2 Resource Configurationの作成
- 前回の記事で作成したResource Gateway(nginxインスタンスへのResource Configurationを含む)にて、追加のResource Configurationを作成する。
- TypeをARN、Resource typeをRDSとすると、接続したいRDS Databaseが選択できるようになるため、事前に作成したRDS for Oracleを選択する。
- 動作確認のため、CloudWatchへのログ出力を設定する。
- 作成後、Type: ARN と Type: Child の 2つのConfigurationが作成される。ARNの子設定としてChildがあり、Child側にポート番号などの詳細が入っているイメージ。(Type: Singleは前回の記事で作成したEC2インスタンスへの接続用のConfiguration)
4.3 Resource Endpointの作成
- VPC2側に、RDS for Oracle接続用のResource Configurationと接続するためのResource Endpointを作成する。
- 接続先はARNのほう(CHILDではない)を選択する。
-
作成されたResource EndpointにはDNS名が付与される。
-
Resource EndpointのIPアドレスを確認する。Resource Endpointの画面では10.0.2.80/10.0.3.96 と表示されているが、それぞれのENIを確認すると、セカンダリプライベートアドレスが付与されており、10.0.2.126と10.0.3.50がアサインされていた。
4.4 接続確認
通常時
- VPC2にあるクライアント(SQLPLUS)から、Resource Endpointを経由してVPC1のRDS for Oracleに接続できることを確認する。
- コマンドラインは以下の通り。
[ec2-user@ip-10-0-0-121 ~]$ sqlplus admin/PASSWORD@//10.0.3.50:1521/ORCL
SQL*Plus: Release 19.0.0.0.0 - Production on Tue Jan 7 07:49:47 2025
Version 19.19.0.0.0
Copyright (c) 1982, 2022, Oracle. All rights reserved.
Last Successful login time: Tue Jan 07 2025 07:49:14 +00:00
Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.25.0.0.0
SQL>
- Resource EndpointのENIのIPは計4つあるが、そのうち2つは疎通不可だった。何かバックアップ的な感じ（普段は使えない）なのかもしれない。
| IPアドレス | プライマリ/セカンダリ | 疎通可否 |
|---|---|---|
| 10.0.2.80 | プライマリ | 不可 |
| 10.0.2.126 | セカンダリ | 可 |
| 10.0.3.96 | プライマリ | 不可 |
| 10.0.3.50 | セカンダリ | 可 |
- AZ-3b側にRDS for OracleのACTがある状態でのアクセスログは以下のようになる。
系切替時
- RDS for Oracle を手動フェイルオーバー(ACTをAZ-3a側へ)して、再度Resource Endpoint経由でのアクセスが可能なことを確認する。
- SQLPLUSによる接続確認を行った（コマンド結果は省略）。疎通可能なResource EndpointのIPアドレスは系切替前と変わらなかった。(10.0.2.126、10.0.3.50経由のみ疎通可能)
- AZ-3a側にRDS for OracleのACTがある状態でのアクセスログは以下のようになる。
5. 所感
- 接続先がRDSの場合でもEC2の時とそれほど設定内容の差はなかったが、Resource EndpointのENIにセカンダリIPが付与される点がよく分からなかったため継続調査したい。(あまり気にせずにDNS名を使うようにすればよいのかもしれないが）
- VPC間をPeeringやTransit Gatewayで接続することができないような環境で、RDSに対して他のVPCから接続を受けるようにするには有用な仕組みではないかと思った。