暗号化された RDS for SQL Server でクロスリージョン自動バックアップとリストアをやってみる
2025.05.05コーヒーが好きな emi です。
RDS for SQL Server の BCP 対策を検討する中で、クロスリージョン自動バックアップとリストアの検証をおこないました。
本ブログでは検証手順を共有します。
ポイント
- 暗号化された RDS for SQL Server でも実装可能
- 自動バックアップ送信先リージョンの KMS キーを指定することに注意
- SQL Server Standard Edition でもサポートされる（Enterprise Sdition じゃなくても OK）
- 自動バックアップ送信先リージョンで PITR が可能
- Secrets Manager でマスターパスワードを管理している場合でも、送信先リージョンでリストアするとセルフマネージド管理に変わる
- 必要に応じてマスターパスワードの管理方法は再設定する必要がある
- 参考情報▼
構成図
AD 環境ではない WORKGROUP 環境で検証しました。
0. 事前準備
VPC を作成しておいてください。今回は私の検証環境にあらかじめ作成しておいた VPC を使用します。
DB サブネットグループも作成しておきました。
1. 東京リージョンで RDS for SQL Server の作成
まずは東京リージョンで RDS for SQL Server を作成します。
今回はマネジメントコンソールから作成します。標準作成で SQL Server Standard Edition を選択し、エンジンバージョンは SQL Server 2022 16.00.4185.3.v1 を選択しました。
パスワードは Secrets Manager で管理することにしました。ストレージは画像のように設定します。
可用性、接続は以下のように設定します。
認証やモニタリングは以下のように設定します。
パラメーターグループとオプショングループはデフォルトのものをそのまま指定しました。
バックアップに 「バックアップレプリケーション」 の項目があり、ここでクロスリージョン自動バックアップを設定できるのですが、今回は後で設定するのでチェックしないで進めました。
暗号化を有効にし、KMS キーは AWS 管理の aws/rds を指定します。他は以下のように設定します。
作成します。
15 分程度待ち、RDS for SQL Server が出来ました。
メンテナンスとバックアップタブは以下のようになっています。
2. クロスリージョン自動バックアップを設定
クロスリージョン自動バックアップを設定します。
画面左のナビゲーションペインメニューで 「自動バックアップ」 を選択し、「現在のリージョン」 タブを見ると、作成した RDS for SQL Server が表示されます。チェックした状態で 「アクション」 をクリックし、「クロスリージョンレプリケーションを管理」 をクリックします。
バックアップレプリケーションにチェックし、送信先リージョンを選択します。今回は大阪リージョンを指定します。
KMS キーの ARN を入力する必要があるのですが、大阪リージョンに KMS を作成していないので、
以下のように大阪リージョンで KMS コンソールを開くと KMS キーがありません。
大阪リージョンで AWS 管理の KMS キーを作成します。
大阪リージョンで KMS キーの作成
以下ブログを参考に CloudShell から AWS CLI で KMS キーを作成します。
aws kms describe-key --key-id alias/aws/rds --region <リージョン名>
今回は大阪リージョンなので、以下コマンドを CloudShell で実行しました。
aws kms describe-key --key-id alias/aws/rds --region ap-northeast-3
▼実行結果
~ $ aws kms describe-key --key-id alias/aws/rds --region ap-northeast-3
{
"KeyMetadata": {
"AWSAccountId": "123456789012",
"KeyId": "3b895a70-c632-4c6b-a15b-1d0xxxxxxxxxx",
"Arn": "arn:aws:kms:ap-northeast-3:123456789012:key/3b895a70-c632-4c6b-a15b-1d0xxxxxxxxxx",
"CreationDate": "2025-05-02T02:59:12.771000+00:00",
"Enabled": true,
"Description": "Default key that protects my RDS database volumes when no other key is defined",
"KeyUsage": "ENCRYPT_DECRYPT",
"KeyState": "Enabled",
"Origin": "AWS_KMS",
"KeyManager": "AWS",
"CustomerMasterKeySpec": "SYMMETRIC_DEFAULT",
"KeySpec": "SYMMETRIC_DEFAULT",
"EncryptionAlgorithms": [
"SYMMETRIC_DEFAULT"
],
"MultiRegion": false
}
}
~ $
大阪リージョンで AWS 管理の KMS キーができました。
作成した大阪リージョンの KMS キーの ARN をコピーします。
RDS 自動バックアップの画面に戻り、コピーした KMS キーの ARN を入力します。
自動バックアップのレプリケーション設定ができました。
KMS キーの作成中 RDS の設定タブを開きっぱなしにしていてエラーになった方は、ブラウザを再読み込みするとうまくいきます。
左が東京リージョンで、右が大阪リージョンのコンソール画面です。
大阪リージョン側で 「レプリケート済み」 タブを見ると、レプリケートされてきた自動バックアップが確認できます。
3. 大阪リージョンにレプリケートしたバックアップから PITR する
大阪リージョンにレプリケートされた自動バックアップから、ポイントインタイムリカバリ（Point In Time Recovery、PITR）をおこないます。
大阪リージョンにレプリケートされた自動バックアップを開き、アクションから 「特定時点への復元」 をクリックします。
復元する時刻を選択できます。
ちなみに、DB エンジンは Standard Edition から変更できず、
ライセンスモデルも License Included から変更できません。
インスタンスタイプは東京リージョンのものとは違うものに変更できます。
マルチ AZ 配置やストレージの設定も東京リージョンのものとは違う構成に変更できます。
大阪リージョンの VPC を選択します。今回は検証なのでパブリックサブネットしかないデフォルト VPC を選択してしまいましたが、本番環境の場合は VPC を要件に応じて作成してください。
他の設定は画像を参照ください。
バックアップの設定はここでは変更できませんでした。
15 分程度待つと、大阪リージョンで RDS for SQL Server インスタンスを復元することができました。
ブラウザタブを並べて、東京リージョンのインスタンスと大阪リージョンで復元したインスタンスを比較します。左が東京リージョンで、右が大阪リージョンです。
インスタンスのエンドポイントが変わっています。
接続タブを見ると、マスターパスワードの設定が違っています。東京リージョンでは Secrets Manager 管理としましたが、大阪リージョンは Secrets Manager 利用になっていません。
変更から見てみると、セルフマネージドになっていました。この画面はキャンセルで閉じます。
4. 大阪リージョン RDS インスタンスのパスワード確認
大阪リージョンで復元した RDS for SQL Server インスタンスのマスターパスワードは何でしょうか？
大阪リージョンで復元した RDS for SQL Server インスタンスに接続してみるために、大阪リージョンで EC2（Windows Server 2022）を構築し、フリートマネージャーを使って接続テストをおこないます。
EC2 と RDS のセキュリテイグループを設定しておいてください。RDS のセキュリテイグループのインバウンドルールで、EC2 のセキュリテイグループからの MSSQL（ポート 1433）を許可しておきます。
フリートマネージャーでリモートデスクトップ接続します。
SQL Server に接続するために、 SQL Server Management Studio (SSMS) をインストールしておきます。
Windows Server 2022 で Edge を使い、以下のダウンロードページを開いてください。
ダウンロードページで、日本語版の SSMS をダウンロードします。
デフォルトのディレクトリにインストールします。
2 分程度でインストールが完了します。
SSMS を開きます。
接続情報として、東京リージョンの Secrets Manager 画面を開き、東京リージョンの RDS for SQL Server のシークレット情報を取得しておきます。
SSMS で以下のように入力します。
- Server name：大阪リージョンで復元した RDS for SQL Server のエンドポイント
- Authentication：SQL Server Authentication
- Login：東京リージョンの Secrets Manager から取得した情報
- Password：東京リージョンの Secrets Manager から取得した情報
- Trust server certificate にチェックする
接続できました。大阪リージョンで復元した RDS for SQL Server インスタンスのマスター認証情報は、東京リージョンの情報がセルフマネージド形式で使える状態であることが確認できました。
必要に応じて Secrets Manager や Systems Manager のパラメーターストアの利用をご検討ください。
おわりに
本記事への質問やご要望については画面下部のお問い合わせ「DevelopersIO について」からご連絡ください。記事に関してお問い合わせいただけます。
参考
