確実な災害復旧計画を実現!Amazon EC2の新機能「時間ベースのAMIコピー」を解説

クラウドインフラ運用における重要な課題の一つは、リソースのバックアップと災害復旧計画の効率的な実装です。
しかし、今までのバックアップ機能では、AMIの取得後にクロスリージョンコピーがいつ完了するかわからない状況でした。
災対環境へのクロスリージョンコピーが完了していない状態で災害が起きてしまうと、災対環境側での復旧がうまくいかないという課題は皆さんもお持ちだったと思います。
この課題に対応するため、AWSは2025年2月に、Amazon EC2に時間ベースのAMIコピー機能を導入しました。
この新機能により、お客様はAmazon Machine Images (AMIs)を特定のスケジュールに基づいて自動的に異なるリージョンやアカウントにコピーできるようになりました。
この革新的な機能は、クロスリージョンのディザスタリカバリ戦略を簡素化し、マルチリージョン展開の効率性を大幅に向上させることが期待されています。
特に大規模なクラウド環境を運用する企業にとって、インフラストラクチャの一貫性維持とセキュリティ体制の強化に役立つでしょう。
本記事では、この新機能の詳細、設定方法、ビジネスメリットについて解説します。
しかし、今までのバックアップ機能では、AMIの取得後にクロスリージョンコピーがいつ完了するかわからない状況でした。
災対環境へのクロスリージョンコピーが完了していない状態で災害が起きてしまうと、災対環境側での復旧がうまくいかないという課題は皆さんもお持ちだったと思います。
この課題に対応するため、AWSは2025年2月に、Amazon EC2に時間ベースのAMIコピー機能を導入しました。
この新機能により、お客様はAmazon Machine Images (AMIs)を特定のスケジュールに基づいて自動的に異なるリージョンやアカウントにコピーできるようになりました。
この革新的な機能は、クロスリージョンのディザスタリカバリ戦略を簡素化し、マルチリージョン展開の効率性を大幅に向上させることが期待されています。
特に大規模なクラウド環境を運用する企業にとって、インフラストラクチャの一貫性維持とセキュリティ体制の強化に役立つでしょう。
本記事では、この新機能の詳細、設定方法、ビジネスメリットについて解説します。
機能概要
今回の機能は、以前以下の記事で紹介したスナップショットの時間コピーに類する機能となります。
以前の追加ではスナップショットのみ、時間ベースでのコピーが提供されましたが、対象が拡張されAMIも同様に時間ベースのコピーが可能となったのです。
この追加された機能は、AMIをAWSアカウント内、またはクロスアカウントでコピーを行う際に指定した時間以内に作業を完了するよう期間設定ができるというものです。
例えば、今までだと夜中の1時に東京リージョンでAMIを取得して、大阪リージョンにコピーを行う際に、データ容量によっては数時間かかっていました。
つまり、災対環境の大阪にAMIの退避が完了するのは、東京リージョンのAMIの取得が完了してから数時間後という状況でした。
もし、このコピー時間中に災害が発生した場合はどうなるでしょうか?
退避が完了していないので、災対環境に切り替えたとしても直近である夜中の1時に取得したバックアップは大阪では使えません。
もう1世代前のコピーが完了しているものを使うしかなかったのです。
これではRPO要件を定めることが困難でした。
それが今回のアップデートではコピーの期間を最小15分から最大48時間まで指定できるようになったということです。
条件はありますが、最小の15分としておけば、夜中1時に取得したバックアップが1時15分には大阪リージョンにコピー完了しているという計算になります。
これであればRPO要件も定義できますし、満たすような設計も取りうると考えられます。
以前の追加ではスナップショットのみ、時間ベースでのコピーが提供されましたが、対象が拡張されAMIも同様に時間ベースのコピーが可能となったのです。
この追加された機能は、AMIをAWSアカウント内、またはクロスアカウントでコピーを行う際に指定した時間以内に作業を完了するよう期間設定ができるというものです。
例えば、今までだと夜中の1時に東京リージョンでAMIを取得して、大阪リージョンにコピーを行う際に、データ容量によっては数時間かかっていました。
つまり、災対環境の大阪にAMIの退避が完了するのは、東京リージョンのAMIの取得が完了してから数時間後という状況でした。
もし、このコピー時間中に災害が発生した場合はどうなるでしょうか?
退避が完了していないので、災対環境に切り替えたとしても直近である夜中の1時に取得したバックアップは大阪では使えません。
もう1世代前のコピーが完了しているものを使うしかなかったのです。
これではRPO要件を定めることが困難でした。
それが今回のアップデートではコピーの期間を最小15分から最大48時間まで指定できるようになったということです。
条件はありますが、最小の15分としておけば、夜中1時に取得したバックアップが1時15分には大阪リージョンにコピー完了しているという計算になります。
これであればRPO要件も定義できますし、満たすような設計も取りうると考えられます。
注意点
本機能を使う上での注意点です。
スナップショットでの時間ベースのコピーでもありましたが、AMIのコピーにおいてもスループットの制約が発生します。
AMIは複数のスナップショットをまとめたものですので、その中には1つ以上のスナップショットが含まれています。
機能的には、AMIの時間ベースのコピーは含まれているスナップショットを全てスナップショットの時間ベースコピーで複製するようなイメージになります。
この時にスナップショットの時間べースコピーと同様のスループット制限がかかります。
500GiBのスナップショットをコピーする場合、500MiB/秒という制約を照らし合わせると最低でも1024秒(約17分)かかることになります。
1000GiBのスナップショットをコピーする場合も同様の計算を行うと。最低でも2048秒(約34分)かかることになります。
累積の制限も考慮すると、最初の17分間は3本のスナップショットがフルの500MiB/秒でコピーされますので、1500MiB/秒のスループットが使われます。
これは、累積最大スループットを満たしているので、条件に引っかからないことがわかります。
もし条件に引っかかる場合は、累積最大スループットは上限緩和可能なので、サポートに申請しましょう。
そして、このAMIをコピーした場合、500GiBのスナップショットは17分でコピーできますが、最後の1000GiBのデータは34分かかりコピーが終わるので、AMI全体でいうと最低でもコピーには34分かかるという計算になります。
時間ベースのコピーは15分単位での設定になるので、厳密には、45分での時間ベースコピーを実行することになります。
このように、スナップショットの容量を考慮して、同時にコピーする容量や本数を緻密にコントロールすることが必要になりそうですね。
大まかにスナップショット容量と可能な最速転送速度を表に整理します。
累積は考慮していないので、全て1つのスナップショットをコピーする場合で考えてください。
スナップショットでの時間ベースのコピーでもありましたが、AMIのコピーにおいてもスループットの制約が発生します。
AMIは複数のスナップショットをまとめたものですので、その中には1つ以上のスナップショットが含まれています。
機能的には、AMIの時間ベースのコピーは含まれているスナップショットを全てスナップショットの時間ベースコピーで複製するようなイメージになります。
この時にスナップショットの時間べースコピーと同様のスループット制限がかかります。
- 1つのスナップショットコピーでは、最大スループット:500MiB/秒
- 複数のスナップショットコピーでの累積最大スループット:2000MiB/秒
※この制約は上限緩和可能 - 時間は15分間隔で設定可能。(15分以内、30分以内、45分以内....)
- スループットの制約を超えるコピーリクエストが発生した場合、指定した時間内にコピーが完了しないことがある。
- 時間ベースのスナップショットコピーで転送したデータ料に応じて追加料金が発生する。
500GiBのスナップショットをコピーする場合、500MiB/秒という制約を照らし合わせると最低でも1024秒(約17分)かかることになります。
1000GiBのスナップショットをコピーする場合も同様の計算を行うと。最低でも2048秒(約34分)かかることになります。
累積の制限も考慮すると、最初の17分間は3本のスナップショットがフルの500MiB/秒でコピーされますので、1500MiB/秒のスループットが使われます。
これは、累積最大スループットを満たしているので、条件に引っかからないことがわかります。
もし条件に引っかかる場合は、累積最大スループットは上限緩和可能なので、サポートに申請しましょう。
そして、このAMIをコピーした場合、500GiBのスナップショットは17分でコピーできますが、最後の1000GiBのデータは34分かかりコピーが終わるので、AMI全体でいうと最低でもコピーには34分かかるという計算になります。
時間ベースのコピーは15分単位での設定になるので、厳密には、45分での時間ベースコピーを実行することになります。
このように、スナップショットの容量を考慮して、同時にコピーする容量や本数を緻密にコントロールすることが必要になりそうですね。
大まかにスナップショット容量と可能な最速転送速度を表に整理します。
累積は考慮していないので、全て1つのスナップショットをコピーする場合で考えてください。
スナップショット容量 | 最速コピー時間 |
---|---|
0GiB~439GiB | 15分 |
440GiB~878GiB | 30分 |
879GiB~1318GiB | 45分 |
1319GiB~1757GiB | 60分 |
機能検証
①適当なAMIを大阪リージョンにコピーしてみます。
ディスク構成は、30GB、5GB、4GBの3本です。

②送信先リージョンをアジアパシフィック(大阪)にして、時間ベースのコピーを有効化します。
時間は15分に設定してみます。
スループットの制限的に十分15分以内に間に合う容量のはずです。

③コピーを開始した段階で転送先にはガワだけ作成されるみたいですね。

スナップショットもガワだけ作成されていますね。
AMI側では時間ベースのコピーが行われているのかが画面では見えませんが、スナップショット側にはしっかりと時間ベースのコピーの設定が見えました。

④無事にコピーが完了しました。
時間は12分05秒となので想定通りの時間内で複製完了していますね。

ディスク構成は、30GB、5GB、4GBの3本です。

②送信先リージョンをアジアパシフィック(大阪)にして、時間ベースのコピーを有効化します。
時間は15分に設定してみます。
スループットの制限的に十分15分以内に間に合う容量のはずです。

③コピーを開始した段階で転送先にはガワだけ作成されるみたいですね。

スナップショットもガワだけ作成されていますね。

AMI側では時間ベースのコピーが行われているのかが画面では見えませんが、スナップショット側にはしっかりと時間ベースのコピーの設定が見えました。

④無事にコピーが完了しました。
時間は12分05秒となので想定通りの時間内で複製完了していますね。

まとめ
災対環境を用意するシステムも増えてきた中で、バックアップの退避は大きな課題でした。
特に大規模なDBを持つようなシステムでは、バックアップを災対環境に退避するだけでも大きな時間がかかりRPOが伸びる原因でもありました。
今後、スループットも増えていき、より高速に災対環境へのバックアップ転送が行えるようになるとよりDR対策が取りやすくなりますね。
ぜひ使ってみてください。
特に大規模なDBを持つようなシステムでは、バックアップを災対環境に退避するだけでも大きな時間がかかりRPOが伸びる原因でもありました。
今後、スループットも増えていき、より高速に災対環境へのバックアップ転送が行えるようになるとよりDR対策が取りやすくなりますね。
ぜひ使ってみてください。