AWS Secrets Manager のクロスリージョンレプリケーションをやってみました

はじめに

データベースの認証情報、APIキーなどの機密性の高い情報を、可用性を確保して安全に管理するにはどうしたいいんだろう？
災害対策（DR）について調べる機会がありましたので、AWS Secrets Manager のクロスリージョンレプリケーションで実現する、堅牢なシークレット管理をまとめてみました。

目次

• シークレット管理の課題
• AWS Secrets Manager とは
• レプリケーションが必要となるユースケース
• シークレットのレプリケーションやってみる
• まとめ

シークレット管理の課題

• 複数リージョンでの一貫した管理
• 災害時のシークレットの可用性確保
• 機密情報の安全な更新と同期

これらの課題を解決してくれるサービスが、AWS Secrets Managerです。

AWS Secrets Manager とは

AWS Secrets Manager は、パスワード、APIキー、その他の機密情報を一元管理するためのサービスです。
主な特徴は

• 暗号化されたシークレットの保存
• きめ細かなアクセス制御
• シークレットの自動ローテーション
• AWS サービスとの統合
• クロスリージョンレプリケーション

今回は、クロスリージョンレプリケーションに焦点を当てて、東京リージョンと大阪リージョンでレプリケーションをしてみようと思います。

レプリケーションが必要となるユースケース

1. 災害対策（DR）
   プライマリリージョンが使用できなくなった場合のバックアップ
   ビジネス継続性の確保

2. グローバル展開
   世界各地のユーザーへの低レイテンシーでのアクセス提供
   リージョン間でのシークレットの一貫性維持

3. コンプライアンス要件
   データの地理的冗長性の確保
   規制要件への対応

レプリケーションの構成

• プライマリシークレット：元となるシークレットで、通常は主要なリージョンに配置
• レプリカシークレット：プライマリシークレットのコピーで、他のリージョンに配置
• 自動同期：プライマリの更新が自動的にレプリカに反映

シークレットのレプリケーションやってみる

今回、想定したのは、平時は、東京をプライマリとして業務システムを動かしておいて、DR発動時にフェイルオーバーして、大阪リージョンで業務システムを動かして事業継続を行う。
データベースは、クロスリージョンレプリケーションで大阪側にも同期しておき、パスワードなどの機密情報はSecrets Managerから取得して使うので東京と大阪で同期をしておく。

イメージはこんな感じです

シークレットの作成

シークレットを作成します。
今回は、東京に作成済みシークレットと東京と大阪の両方に作成済みのシークレットでそれぞれレプリケーションの設定をしてみます。

新しいシークレットを保存する からシークレットを作成していきます。

シークレットのタイプを選択して、各ステップで必要な項目を入力していきます。

ステップは、4ステップです。

• ステップ1　シークレットのタイプを選択
  　データベースの認証情報は、ユーザー名、パスワード
  　API キー、トークンなどのその他のもの

• ステップ2　シークレットの設定
  　このステップでシークレットのレプリケーションの設定も一緒に出来ます。

• ステップ3　ローテーションの設定
  　シークレットの自動ローテーションのスケジュール、ローテーションを行うLambdaを指定します。

• ステップ4　レビュー
  

これでシークレットが作成出来ました。

レプリケーションの設定

1. レプリケーション元リージョンのマネジメントコンソールから行います。
   
   設定するのは、レプリケーション先のリージョンと暗号化キーを選択するだけ。
   リージョンの追加で、複数リージョンにレプリケーションすることも出来ます。
   

2. レプリケーションの設定後、すぐに、東京→大阪のシークレットの同期が行われます。
   
   　レプリケーション先の大阪リージョンにシークレットが作成されました。
   
   

3. レプリケーションの確認をしてみます。
   　東京リージョンのシークレットの値を更新して、大阪リージョンのシークレットの値を確認します。
   　
   　現在の値を確認
   　東京リージョン、大阪リージョンの値は、同じ値：tokyo2025 です。

   東京リージョンのシークレットの値 $ aws secretsmanager get-secret-value --secret-id Test-Secret-1 --region ap-northeast-1 { "ARN": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:Test-Secret-1-xCmMms", "Name": "Test-Secret-1", "VersionId": "6ec85f38-0884-4a93-9180-c598db533493", "SecretString": "{\"test-key\":\"tokyo2025\"}", "VersionStages": [ "AWSCURRENT" ], "CreatedDate": "2025-02-28T09:57:02.667000+09:00" } レプリケーションされた大阪リージョンのシークレット $ aws secretsmanager get-secret-value --secret-id Test-Secret-1 --region ap-northeast-3 { "ARN": "arn:aws:secretsmanager:ap-northeast-3:123456789012:secret:Test-Secret-1-xCmMms", "Name": "Test-Secret-1", "VersionId": "6ec85f38-0884-4a93-9180-c598db533493", "SecretString": "{\"test-key\":\"tokyo2025\"}", "VersionStages": [ "AWSCURRENT" ], "CreatedDate": "2025-03-03T13:01:55.830000+09:00" }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

   東京リージョンのシークレットの値 $ aws secretsmanager get-secret-value --secret-id Test-Secret-1 --region ap-northeast-1 { "ARN": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:Test-Secret-1-xCmMms", "Name": "Test-Secret-1", "VersionId": "6ec85f38-0884-4a93-9180-c598db533493", "SecretString": "{\"test-key\":\"tokyo2025\"}", "VersionStages": [     "AWSCURRENT" ], "CreatedDate": "2025-02-28T09:57:02.667000+09:00" } レプリケーションされた大阪リージョンのシークレット $ aws secretsmanager get-secret-value --secret-id Test-Secret-1 --region ap-northeast-3 { "ARN": "arn:aws:secretsmanager:ap-northeast-3:123456789012:secret:Test-Secret-1-xCmMms", "Name": "Test-Secret-1", "VersionId": "6ec85f38-0884-4a93-9180-c598db533493", "SecretString": "{\"test-key\":\"tokyo2025\"}", "VersionStages": [     "AWSCURRENT" ], "CreatedDate": "2025-03-03T13:01:55.830000+09:00" }

　東京リージョンのシークレットの値を更新しました。

シークレットの同期が行われて、東京リージョンのシークレットの値が、大阪リージョンのシークレットに反映されています。

次は、東京リージョンと大阪リージョンの両方に作成済みのシークレットのレプリケーションを設定してみます。

「Replication failed: Secret name Test-Secret-2 already exists in region ap-northeast-3.」のエラーが発生し、失敗してしまいました。
これは、レプリケーション先の大阪リージョンに既に同じ名前のシークレット(Test-Secret-2)が存在していたのが原因です。

再試行をすると、大阪のシークレットを一旦削除し、再作成を行うので、大阪で使用していことの確認ダイアログが表示されます。

再試行でシークレットが再作成されました
ARN、CreatedDateの日時が変更されています
もちろん東京→大阪のレプリケーションも行われています

レプリカシークレットのスタンドアロン昇格

DR発動時など、レプリケーション元が障害等で利用できなくなった時は、レプリカシークレットを、スタンドアロンシークレットに昇格させることが必要です。

スタンドアロンシークレットに昇格させてみます。

　　　　　↓

確認のメッセージが表示され、レプリカを昇格させるを押下すると、スタンドアロンシークレットに昇格が行われて、レプリケーション設定が削除されます。
また、大阪リージョンでシークレットの値の変更が可能になります。

レプリケーションの再設定は、東京リージョンのシークレットからレプリケーションの再設定を行い、同期を再開します。
同一名称のシークレットがある場合、両方のリージョンに同一名のレプリケーションの時と同じく、一度失敗しますが、再試行→上書き設定でレプリケーションの設定が行われて、同期が行われます。

まとめ

災害対策観点でリージョン間のレプリケーションを調査していましたが、検証を通じて多くの気づきがありました。
AWS Secrets Manager のクロスリージョンレプリケーションは、以下のような点で非常に有用であることがわかりました：

• 災害対策（DR）だけでなく、グローバル展開におけるレイテンシー対策にも有効。
• シークレットを一元管理でき、後からでもレプリケーションの設定が可能なため、システム要件の変化に柔軟に対応出来る。
• プライマリシークレットの変更がレプリカにほぼリアルタイムで反映されるため、常に最新の情報を維持出来る。
• レプリカシークレットをスタンドアロンに昇格させる機能により、プライマリリージョンに障害が発生した場合でも、スムーズに運用を継続できます。

AWS Secrets Manager のクロスリージョンレプリケーションを活用することで、機密情報の安全性と可用性を両立した堅牢なシステム構築が可能になることが分かりました。
特に複数リージョンでの運用やグローバル展開を行う企業にとって、検討する価値のある機能だと思いました。