Amazon RDS for Db2 でカスタムドメイン名を維持する

本記事は 2026 年 5 月 26 日に公開された「Preserving custom domain names for Amazon RDS for Db2」を翻訳したものです。

IBM Db2 のワークロードをオンプレミスから Amazon Relational Database Service (Amazon RDS) for Db2 へ移行するお客様からは、既存のアプリケーション接続文字列を変更せずに使い続ける方法についてよく質問をいただきます。Amazon RDS for Db2 は、DB パラメータグループの ssl_svcename パラメータと db2comm レジストリ変数を SSL または SSL,TCP に設定することで、エンドツーエンドの暗号化をネイティブにサポートしています。ただしアプリケーションは、あらかじめ定義された RDS エンドポイント (例: mydb.abc123.us-east-1.rds.amazonaws.com:50000) に接続する必要があります。proddb.company.com:1443 から RDS エンドポイントへ切り替えるために数百ものアプリケーション接続文字列を書き換える作業は、コストがかかり、ミスも生じやすく、リフトアンドシフト移行の速度を低下させます。

本記事では、aws-samples/sample-rds-db2-tools リポジトリで公開されているモジュール化された Terraform テンプレートを紹介します。このテンプレートを使うと、Amazon RDS for Db2 へのエンドツーエンドの TLS 暗号化を維持しながら、アプリケーションが既存のカスタムドメイン名とポートをそのまま利用できます。テンプレートは、Server Name Indication (SNI) ベースの TLS プロキシをデプロイし、暗号化されたトラフィックを復号することなく転送します。

ソリューションの概要

テンプレートは、次の図のように 5 つの番号付き Terraform モジュールに分割されています。

Architecture diagram showing the five Terraform modules deploying an SNI-based TLS proxy between clients and Amazon RDS for Db2

各モジュールはスタックの特定の部分を担当し、それぞれ独立したリモート状態を保持します。そのため、他のモジュールに影響を与えずに 1 つのモジュールだけを更新できます。テンプレートは、状態管理とロックに Amazon Simple Storage Service (Amazon S3) と Amazon DynamoDB を使用し、証明書の保管に AWS Secrets Manager と AWS Certificate Manager (ACM) を使用します。

モジュール	作成されるもの
0-backend-setup	Terraform のリモート状態用の Amazon S3 バケットと Amazon DynamoDB テーブル
1-prerequisites	AWS Secrets Manager と ACM に保管される自己署名 SSL 証明書
2-infrastructure	OpenResty (Nginx) を実行する Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon Network Load Balancer (NLB)、Amazon Route 53 のプライベートホストゾーン
3-mappings	AWS Systems Manager パラメータストア内のカスタムドメインから RDS エンドポイントへのマッピング、およびポートごとに動的に作成される NLB リスナーとターゲットグループ
4-health-check	デプロイの検証 (EC2 のステータス、リッスンしているポート、ターゲットグループのヘルス、設定ファイル)

プロキシは TLS の ClientHello から SNI フィールドを読み取り、暗号化されたストリームを一致する RDS エンドポイントへ転送します。トラフィックはプロキシ上で復号されないため、クライアントから RDS までエンドツーエンドの暗号化が維持されます。EC2 インスタンス上の cron ジョブが 5 分ごとにパラメータストアからプロキシ設定を更新するため、データベースの追加や削除の際にインフラストラクチャを再デプロイする必要はありません。

前提条件

この手順を進めるには、次のものが必要です。

Amazon EC2、NLB、Route 53、AWS Identity and Access Management (IAM)、AWS Secrets Manager、ACM、Amazon S3、Amazon DynamoDB のリソースを作成する権限を持つ AWS アカウント。リポジトリには terraform-service-account-policy.json とサービスアカウントのセットアップガイドが同梱されています。
ローカルにインストールされた Terraform 1.5 以降、AWS Command Line Interface (AWS CLI)、および jq。
少なくとも 2 つのアベイラビリティーゾーンにプライベートサブネットを持ち、DNS ホスト名と DNS 解決が有効になっている既存の Amazon Virtual Private Cloud (Amazon VPC)。
SSL アクセス用に設定された 1 つ以上の Amazon RDS for Db2 インスタンス。db2comm を SSL または SSL,TCP に設定し、DB パラメータグループの ssl_svcename で SSL ポートを定義します。詳細については、Amazon RDS for Db2 DB インスタンスでの SSL/TLS の使用を参照してください。

リポジトリをクローンします。

git clone https://github.com/aws-samples/sample-rds-db2-tools.git
cd sample-rds-db2-tools/tools/End-to-End-Trust

ウォークスルー

以下の各サブセクションでは、それぞれのステップを要約します。完全なコマンド、変数の説明、サンプルの tfvars ファイルは、リポジトリの README からリンクされている各モジュールの README にあります。

ステップ 1: リモート状態を初期化する

残りのモジュールの状態を保持する S3 バケットと DynamoDB テーブルを作成します。

cd 0-backend-setup
./bootstrap-backend.sh
terraform init && terraform apply --auto-approve
cd ..
./configure-modules.sh

configure-modules.sh スクリプトは、モジュール 1 から 4 に backend.tf を書き込み、すべてが同じ共有状態バケットを使用するようにします。

ステップ 2: 証明書を生成する

モジュール 1 は、ワイルドカードのカスタムドメイン (例: *.db.mycompany.com) 用の自己署名証明書を生成し、秘密鍵を AWS Secrets Manager に、証明書を ACM に保管します。terraform.tfvars を aws_region、domain_name、organization で編集し、terraform init && terraform apply --auto-approve を実行します。

本番環境では、自己署名証明書を、企業の認証局が発行した証明書に置き換えてください。自己署名のフローは、開発およびテスト用です。

ステップ 3: プロキシインフラストラクチャをデプロイする

モジュール 2 は、EC2 プロキシ、NLB、および Route 53 プライベートホストゾーンをデプロイします。./configure-infrastructure.sh を実行して VPC、サブネット、セキュリティグループを対話的に選択するか、terraform.tfvars を手動で記述します。スクリプトがファイルを生成し、モジュール 2 が NLB を EC2 プロキシに接続し、証明書とパラメータストアの読み取りを許可するインスタンスプロファイルをアタッチして、NLB を指すワイルドカード DNS レコードをカスタムドメイン配下に作成します。

ステップ 4: RDS マッピングを設定する

モジュール 3 では、どのカスタムドメインとポートをどの RDS エンドポイントにルーティングするかを記述します。

rds_mappings = {
  "proddb.company.com:1443" = "mydb-prod.abc123.us-east-1.rds.amazonaws.com:50000"
  "testdb.company.com:1443" = "mydb-test.def456.us-east-1.rds.amazonaws.com:50000"
  "devdb.company.com:50443" = "mydb-dev.ghi789.us-east-1.rds.amazonaws.com:50000"
}

モジュールは一意のクライアントポート (この例では 1443、50443) を抽出し、ポートごとに 1 つの NLB リスナーとターゲットグループを作成して EC2 プロキシを登録し、各マッピングを /rds/proxy/mappings/<domain> 配下のパラメータストアに書き込みます。EC2 インスタンス上の cron ジョブが 5 分以内に新しいマッピングを取得し、プロキシ設定を再読み込みします。

後からデータベースを追加または削除するには、rds_mappings を編集して terraform apply を実行し、cron ジョブを待ちます。インフラストラクチャの再デプロイは不要です。

ステップ 5: デプロイを検証する

モジュール 4 は、EC2 インスタンスが実行中であること、SSM エージェントがオンラインであること、OpenResty がアクティブであること、マッピングされたすべてのポートがリッスンしていること、すべての NLB ターゲットグループが正常であること、プロキシ設定と証明書がインスタンス上に存在することを検証する、スクリプト化されたヘルスチェックを実行します。4-health-check から terraform init && terraform apply --auto-approve を実行します。実行に成功すると、次のようなサマリーが出力されます。

✓ EC2 instance is running
✓ OpenResty service is active
✓ Port 1443 is listening
✓ Port 50443 is listening
✓ Port 1443 target group: healthy
✓ Port 50443 target group: healthy
✓ RDS mappings configured (3 entries)

ステップ 6: Db2 クライアントから接続する

同じ VPC 内 (またはプロキシ VPC とピアリングされた Amazon VPC) の Db2 クライアントから、リージョン固有の RDS 証明書バンドル (例: us-east-1-bundle.pem) をダウンロードし、カスタムドメインとポートを使用するように db2dsdriver.cfg を設定します。

<dsn alias="PRODDB" host="proddb.company.com" name="BLUDB" port="1443">
  <parameter name="SSLServerCertificate" value="/home/db2user/certs/us-east-1-bundle.pem"/>
  <parameter name="SecurityTransportMode" value="SSL"/>
  <parameter name="TLSVersion" value="TLSV12"/>
</dsn>

次に接続します。

db2 connect to PRODDB user <username> using <password>

プロキシはストリームを一切復号しないため、クライアントが検証する証明書は RDS の証明書となり、接続がエンドツーエンドで暗号化されていることが確認できます。Java KeyStore の設定を完全に回避する Java クライアントのレシピについては、KeyStore や Keytool を使わずに Java で Amazon RDS for Db2 への SSL 接続を作成するを参照してください。

クリーンアップ

継続的な課金を避けるため、モジュールを逆順に破棄します。

./cleanup.sh

スクリプトはモジュール 3 から 1 を破棄し、状態バケットから rdsdb2-proxy/* プレフィックスを削除して、ローカルの Terraform ファイルをリセットします。モジュール 0 の状態バケットと DynamoDB テーブルは保持されるため、同じアカウント内の他の Terraform プロジェクトには影響しません。不要になった場合は手動で削除してください。

考慮事項と制限事項

このテンプレートは移行期の暫定的なソリューションとして設計しました。目的は、アプリケーション接続文字列を初日から書き換えることなく Amazon RDS for Db2 へ移行する時間を確保し、その後アプリケーションがネイティブの RDS エンドポイントを採用するにつれてプロキシを廃止できるようにすることです。アプリケーションを本当に変更できない場合 (例: 接続文字列がハードコードされたサードパーティ製アプリケーション) は、プロキシを無期限に運用することもできますが、その場合は運用、監視、パッチ適用が必要な追加のインフラストラクチャとして扱う必要があります。

コスト。 プロキシは、RDS for Db2 の料金に加えて、次の費用が発生します (参考として us-east-1 のリスト価格を使用)。

Amazon EC2 インスタンス 1 台: t3.medium (開発用) で月額約 30 ドル、c8i.large (本番のベースライン) で月額約 55 ドル。高可用性のためにアベイラビリティーゾーンをまたいで 2 台にすると、おおよそこの倍になります。
Network Load Balancer 1 台: アベイラビリティーゾーンあたり月額約 16 ドルに加え、LCU 時間あたり 0.006 ドルと GB あたりのデータ処理料金。低ボリュームのワークロードでカスタムポートが 1 つか 2 つの場合、NLB の料金は通常月額 25 ドル未満に収まります。
Amazon Route 53 プライベートホストゾーン: ゾーンあたり月額 0.50 ドルに加え、100 万クエリあたり 0.40 ドル。
AWS Secrets Manager と AWS Systems Manager パラメータストア: 証明書のシークレットと標準ティアのマッピングパラメータで月額 1 ドル未満。

単一インスタンスのリファレンスデプロイは、通常月額 50 ドルから 100 ドルの間に収まります。c8i.large の Auto Scaling グループを使用する 2 アベイラビリティーゾーンの本番デプロイは、データ転送料金を除いて月額 140 ドルから 200 ドルの間に収まります。

運用上の考慮事項。 デプロイを計画する際は、次の点に留意してください。

リファレンスアーキテクチャの単一障害点。 モジュール 2 は EC2 インスタンスを 1 台デプロイします。本番環境では、アベイラビリティーゾーンをまたいで 2 台以上のインスタンスを同じ NLB ターゲットグループに登録する Auto Scaling グループに置き換えてください。プロキシはステートレスなので、スケールアウトは容易です。
デフォルトでは自己署名証明書。 モジュール 1 は、ウォークスルーが単独で完結するように自己署名ワイルドカード証明書を生成します。本番環境では、企業の認証局が発行した証明書に置き換え、同じパラメータ名を使用して AWS Certificate Manager と AWS Secrets Manager にインポートしてください。
SNI が必須。 プロキシは、TLS の ClientHello の SNI 拡張を読み取って接続をルーティングします。最新の Db2 クライアントは SSL が設定されていると SNI を送信しますが、SNI を送信しないレガシークライアントはルーティングできず、単一の RDS エンドポイントにマッピングされたポートを使用する必要があります。
設定更新の遅延。 rds_mappings の新しいエントリは、EC2 の cron ジョブによって 5 分以内に取得されます。それを見込んで変更を計画するか、即時に更新するにはインスタンス上で /usr/local/bin/update-nginx-config.sh を実行してください。
DNS のスコープ。 Route 53 ホストゾーンはプライベートです。クライアントは、ゾーンに関連付けられた VPC (プロキシ VPC、ピアリングされた VPC、または Route 53 Resolver ルールを使用して AWS Transit Gateway 経由で到達可能な VPC) からカスタムドメインを解決する必要があります。パブリック DNS の解決は意図的に公開されていません。
単一リージョンのデプロイ。 テンプレートは 1 つの AWS リージョンにデプロイされます。マルチリージョンの災害対策のためには、各リージョンにテンプレートを個別にデプロイし、フェイルオーバーには Route 53 のヘルスチェックを使用してください。
キャパシティプランニング。 OpenResty は TCP パススルーで効率的に動作し、c8i.large インスタンスは数千の同時接続を余裕を持って処理しますが、プロキシが集約ワークロードに見合ったサイズになるよう、CPUUtilization、NetworkIn、NetworkOut、および NLB の HealthyHostCount と ActiveFlowCount を監視する必要があります。
プロキシからの移行パス。 アプリケーションがネイティブの RDS エンドポイントに接続するよう更新されたら、対応するエントリを rds_mappings から削除して terraform apply を実行します。最後のエントリを削除したら、cleanup.sh を実行してプロキシインフラストラクチャを廃止します。

まとめ

このモジュール化された Terraform テンプレートを使うと、真のエンドツーエンドの TLS 暗号化を維持しながら、アプリケーション接続文字列を 1 つも書き換えることなく IBM Db2 ワークロードを Amazon RDS for Db2 へリフトアンドシフトできます。プロキシは TLS 終端ではなく SNI ルーティングを使用するため、暗号化されたストリームはバイト単位でそのまま RDS へ転送されます。各モジュールは小さく、焦点が絞られ、冪等性があるため、段階的に採用でき、プロキシのロジックを変更せずにネットワークレイヤーを単一 VPC、マルチ VPC、AWS Transit Gateway、AWS PrivateLink、ハイブリッドのデプロイパターンに適応させられます。

完全なテンプレート、パラメータリファレンス、トラブルシューティングガイド、サンプルの tfvars ファイルは、aws-samples/sample-rds-db2-tools で入手できます。

AWS における Db2 関連のコンテンツについては、Deploying Amazon RDS for Db2 using Terraform、Amazon RDS for Db2 ユーザーガイド、および AWS Database Blog を参照してください。

謝辞

本記事をレビューしてくれた Rajib Sarkar と Kshitoj Sanghoi、そしてソリューションを徹底的にテストしてくれた Muhammad Gaballah に心から感謝します。

著者について

この記事はSolutions Architect の矢木覚が翻訳しました。

Amazon Web Services ブログ