Amazon Auroraを検証用途で複製する5つの方法と選び方 〜クローン / スナップショット / レプリケーション / DMS+CDC / カスタムエンドポイント〜
はじめに
ある案件にて、「本番相当の調査用クラスターを作成してほしい」というご依頼をいただきました。
本番に（ほぼ）影響を与えずに、本番相当のデータで調査できる複製が要件でしたが、AWS でこれを実現する手段は一つではありません。ざっと挙げるだけでも、Aurora クローン／スナップショット復元／レプリケーション／DMS + CDC／カスタムエンドポイントと、5つほど候補が並びます。しかも「どれでもいい」わけではなく、本番への影響・運用の手間・コスト・リアルタイム性（データ鮮度）のバランスがそれぞれ大きく違います。
この記事では、この5方式を「実際に検討したときの目線」で比較していきます。最後には、今回のケースで最終的にどれを選び、なぜ残りを見送ったのかまで書きました。
先に結論（お急ぎの方向け）
- 影響を絶対ゼロにしたい → スナップショット復元
- 本番データでほぼ最新・軽量に検証したい（影響は極力なしで可） → Aurora クローン
- 常にリアルタイム同期したい → 放置で運用したいなら DMS + CDC、コスト重視なら レプリケーション
- 新クラスターを立てず軽く分離したい（かつ RDS Proxy が無い） → カスタムエンドポイント
比較の4つの観点
複製方式を選ぶとき、今回は次の4点で見ました。ここがブレると「なんとなくレプリケーションで」みたいな選び方になり、後で運用が重くなって後悔します。
- 本番への影響：複製操作そのもの、そして複製後の利用が、ソース（本番）にどれだけ負荷を与えるか
- 運用の手間：作成・削除・同期監視・復旧にかかる継続的なコスト
- 導入コスト／費用：追加コンポーネントの有無、ストレージ課金の増え方
- リアルタイム性：一度作って終わりでいいのか、常に最新へ追従し続ける必要があるのか（日次・週次など）
この4軸で5方式を並べると、ざっくり次のようになります。
| 方式 | 本番への影響 | 運用の手間 | 導入コスト | リアルタイム性 |
|---|---|---|---|---|
| Aurora クローン | ほぼ無し（ゼロではない） | 軽い | 低 | 作成時点 |
| スナップショット復元 | ゼロ | 軽い | 低 | 取得時点 |
| レプリケーション | 小〜中 | 重い | 中 | リアルタイム |
| DMS + CDC | フルロード時に負荷 | 中 | 高 | リアルタイム |
| カスタムエンドポイント | 設計次第 | 軽い | 低 | リアルタイム |
以降でそれぞれの仕組みと、選ぶ／選ばない判断ポイントを掘り下げます。
① Aurora クローン
まず押さえたい：Aurora の「コンピュートとストレージの分離」
Aurora は Aurora インスタンス（コンピュート）と、複数 AZ にまたがる分散ストレージがきれいに分離した構成です。データは 3 つの AZ に 6 多重（各 AZ に 2 コピー）で保持され、コンピュートはこの共有ストレージボリュームを参照するだけ。「データの実体はストレージ側にあり、インスタンスはそれを見にいく係」というイメージです。
この「コンピュートとストレージは別物」という前提があるからこそ、次の copy-on-write が効いてきます。
copy-on-write：まず共有し、変わったら複製する
クローンは、作成した瞬間にストレージを丸ごとコピーしたりはしません。各データページへのポインタを共有し、その後ソース側かクローン側で変更が入ったページだけを、copy-on-write で新しく確保します。名前のとおり「書き込みが発生したときに初めてコピーする」わけです。この結果、以下の2つのメリットが享受できます。
- 作成が速い。数分で終わり、そのほとんどは新しい Aurora インスタンスのプロビジョニング時間
- 読み取り主体なら、増えるストレージは変更ページ分だけ。つまりコスト増がとても小さい
「ほぼ無し」であって「ゼロ」ではない、という話
ここが今回いちばん確認したかったポイントです。クローンは別クラスターなので、CPU とメモリは完全に分離されています。たとえばクローン側で重いクエリを回してメモリが枯渇したとしても、その影響が本番に飛び火することはありません。この点は安心して良いところです。
ただし、ストレージだけはソースと同じボリュームを参照します。ここから「影響ゼロとは言い切れない」理由が出てきます。
- クローン側で大量の読み取りをすると、ストレージ I/O という物理層では本番と同じ基盤を叩くことになる（ただし読み取りだけであれば、ほぼ影響はないとAWS サポート回答あり)
- 書き込みが多い処理だと、copy-on-write によるページ複製が大量に発生し、そのぶんストレージ側に負荷がかかり得る
- 大量の更新・削除を続けると実データがどんどんコピーされ、使用ストレージも膨らんでコストがあがる
裏を返せば、読み取り中心の用途とクローンは非常に相性が良いということです。今回の「重いクエリの調査」はまさに読み取り中心。ここでクローンが一気に有力候補に浮上しました。
制約
- copy-on-write のクローンは 1 ソースあたり最大 15 個。これを超えるとフルコピーになります
- ソースと同一リージョンにのみ作成可能
- パラレルクエリ非対応のクラスターから、パラレルクエリを使うクラスターへのクローンは不可。この場合はスナップショット経由で復元します
向いている場面
- 本番データで重いクエリ・分析を試したい
- 影響は「極力なし」で許容できる（絶対ゼロまでは求めない）
- ほぼ最新のデータで検証したい
- クローンの作成・削除を頻繁に繰り返したい（作成が軽量なので、必要なときに作って終わったら消す運用が可能）。プロビジョンドインスタンスの場合はインスタンスが起動している間ずっと課金されるため、「使うときだけ作り、終わったら削除」でコストを抑えられます。今回は Serverless v2 を採用し、未使用時に ACU を 0 まで下げることでクローンを維持したままコストを最小化しています
② スナップショット復元
仕組み
スナップショットから、完全に独立した新しいボリュームへ復元する方式です。クローンと決定的に違うのは、ソースとストレージを一切共有しないこと。つまり本番への影響は原理的にゼロです。「とにかく影響を絶対ゼロにしたい」なら、実質この一択になります。
特性
- データはスナップショット取得時点のもの。当然ながら最新ではありません
- 復元先はソースとページを共有しない独立ボリュームを新規に用意するため、データ量が大きいほど利用可能になるまで時間がかかります
- 追加コンポーネントが不要で、導入も運用もシンプル
今回のケースでは「影響ゼロではないが、ほぼ無いと言い切れる」で許容できました。だとすると、データ鮮度が落ちて作成にも時間がかかるスナップショットは、この用途では出番が薄い。というわけで今回は採用していません。ただし要件に 「複製元への影響を絶対ゼロにする」が入るなら、迷わずこれが最有力です。
クローンとの使い分け
「スナップショットを取った直後に復元すれば、データ鮮度はクローンとほぼ同じでは？」という疑問は当然出てきます。実際そのとおりで、データ鮮度だけでは両者を差別化できません。判断を分けるのはコスト・作成速度・本番影響の3点です。
| 観点 | Aurora クローン | スナップショット復元 |
|---|---|---|
| ストレージコスト | 変更ページ分のみ課金（読み取り中心なら極めて小さい） | 全データ分のフルコピーが独立ボリュームに確保される |
| 作成速度 | 数分（新しい Aurora インスタンスの起動時間のみ） | データ量に依存（大規模だと数十分〜） |
| 本番への影響 | ほぼ無し（ストレージ共有のため原理的にゼロではない） | 完全ゼロ（物理的に独立） |
まとめると、コストと作成速度を優先するならクローン、本番影響を原理的にゼロにしたいならスナップショット復元、という軸で選ぶのが最もシンプルです。
③ レプリケーション
複製先を、継続的にソースへ追従させる方式です。Aurora では大きく2系統に分かれます。
- Aurora レプリカ（リーダーインスタンス）：同一クラスター内で共有ストレージを参照するタイプ。レプリカラグが非常に小さく（通常ミリ秒単位）、追加も簡単です。ただし本番と物理的に同居しているので、「本番から負荷を切り離したい」という今回の狙いとは方向性が違います
- 外部レプリケーション（binlog / ロジカルレプリケーション）：別インスタンス・別クラスターへ変更を流し込むタイプ。リアルタイム性が高く、コストも抑えやすい一方で、同期が崩れたときに「どこから同期されていないのか」を調査・復旧する作業がとにかく重い
「リアルタイム性が必須」かつ「他リソースにコストをかけたくない」なら候補になります。ただ、単発の調査用途に対しては、同期ズレの運用負荷が完全に割に合いません。社内の有識者からも「単発調査の一時的なクローンで済む場面に、常時レプリケーションの監視・復旧コストを抱え続けるのは明らかにオーバースペック」との意見があり、今回は早々に候補から外しました。
④ DMS + CDC
仕組み
レプリケーションインスタンス（または DMS サーバーレス）が、ソースを初期フルロードしたあと、CDC（変更データキャプチャ）で継続的に差分を同期していく方式です。「まず全部コピー、あとは差分を垂れ流し」というイメージ。
技術的なポイントと注意
- 初期フルロード時にソースを全件読み取るため、本番に負荷がかかります。ここが今回の要件（本番影響は極力なし）と正面から衝突しました
- レプリケーションインスタンスなどのコンポーネントが増え、導入・運用コストが高め
- 本来は異種エンジン間の移行に強い「移行」向けの機能です（スキーマ変換自体は SCT の担当で、DMS 単体はデータ移行が主戦場）。同一エンジンの単純な複製に使うと、ありがたみの半分くらいしか引き出せません
- 一度設定すれば放置で同期し続け、リアルタイム性は高い
「リアルタイム性が欲しい」「運用は放置で楽をしたい」「多少の導入負荷は許容できる」なら有力です。ただ、今回の調査に対しては導入負荷が高いため、見送りました。逆に、継続同期する分析基盤を別で作るなら第一候補になります。
⑤ カスタムエンドポイント
Aurora の接続エンドポイントをおさらい
Aurora には複数の接続エンドポイントがあります。
- クラスターエンドポイント：書き込み（Writer）へ接続
- リーダーエンドポイント：読み取りレプリカ群へ接続（負荷分散）
- カスタムエンドポイント：任意に選んだインスタンス群へ接続
これをうまく使うと、新規クラスターを立てずに、同一クラスター内へ分析用のリーダーインスタンスを1台足し、カスタムエンドポイントで分析トラフィックだけをそのインスタンスへ向ける、という軽量な分離ができます。エンドポイントは一度作れば使い続けられるので、導入負荷がとにかく軽いのが魅力です。
RDS Proxy 環境では話が変わる
今回の環境には RDS Proxy が入っていました。これが効いてきます。RDS Proxy は前段で接続をプールして集約・管理するため、本番の通信が、分析用にしたはずのインスタンスにも流れ込みます。特定インスタンスへ向けたつもりでも、実際にどこへつなぐかは Proxy 側の管理下。結果として、調査で負荷をかけたインスタンスに本番トラフィックが乗ってきてしまい、狙った分離が成立しません。
というわけで、今回はこの方式も見送りました。ただ念のため補足すると、RDS Proxy が無ければ、クラスターを新設せずに通信を振り分けられる、コスパの良い選択肢になり得ます。環境の前提条件ひとつで評価がひっくり返る形となりました。
結局どれを選ぶ？ 意思決定フロー
ここまでを1枚のフローに落とすと、こうなります。迷ったらこの分岐をたどってみてください。
まとめ：今回のケースでどう決めたか
最後に、今回のケースをどう絞り込んだのかを書き残しておきます。
要件は「本番への影響は極力なし・ほぼ最新（日次）のデータ・読み取り中心・作成と削除を何度も繰り返す」でした。スナップショットはコストと作成速度で一歩譲り、レプリケーションと DMS は今回の単発調査にはオーバースペック、カスタムエンドポイントは RDS Proxy に阻まれる。こうして一つずつ候補を消していった先に残ったのが Aurora クローンでした。
ただ、スムーズに決まったわけではなく、「影響が完全ゼロではない」という点が最後までハードルになりました。本番影響は多くの案件で最優先事項になるため、「どこまで許容できるか」「利便性とどちらを優先するか」を事前に整理しておくと、最適な方式を最短で選べると思います。
この記事がどなたかの役に立てれば幸いです。
