【コスト注意】EBS スナップショットをリージョン間コピーする際に暗号化済みかどうかでデータ転送量が結構変わる
コンバンハ、千葉(幸)です。
突然ですが問題です。以下のようなケースを考えてください。
- ひとつの EBS ボリュームのデータ量が以下の時点で EBS スナップショットを取得する
- 100 GiB
- 150 GiB
- 155 GiB
- 取得した EBS スナップショットを順にリージョン間コピーする
3 つの EBS スナップショットのリージョン間コピーが完了した時、リージョン間のデータ転送量はどの程度になるか、という問題です。
差分だけを考えると 100 + 50 + 5 ……合計で155 GiB なんじゃないの?と思った方が多いかもしれません。
結論から言うと、155 GiB が答えになることもあるし、そうでない時もあります。今回の問題では詳細な条件が記載されていないので、一概には言えない状態です。
ではどんな時に転送量が変わるの?というのを記していきます。
EBSスナップショットリージョン間コピーのデータ転送量まとめ
- 暗号化なしの EBS スナップショットはデータ転送量が圧縮される
- コピー後のスナップショットが増分になる場合、データ転送量も増分のみで済む
- コピー後のスナップショットが増分とならない場合、データ転送量はフルサイズとなる
- 検証のためにやたらと EBS スナップショットのリージョン間コピーを行うと意外とコストがかかるので気をつけよう、やるとしてもデータ転送料金が低いリージョンを選んだりデータ量を少なめにしたり試行回数を少なめにしよう、それをしなかったためにわたしは会社の検証アカウントで 57 ドルくらい溶かしましたすみません
EBS スナップショットのリージョン間コピーを試す構成
実際に検証してデータ転送量を確認します。
冒頭の例のように段階的に EBS スナップショットを作成し、順次 リージョン間コピーを行います。
コピー元のスナップショットの暗号化状態による違いも確認したかったため、以下のようにいくつかのパターンで試行します。
- 暗号化なしのパターン
- デフォルトキー(
aws/ebs
)で暗号化されたパターン - カスタマー管理キー(マルチリージョンキー)で暗号化されたパターン
リージョン間コピーを行ったのち、以下の観点を確認します。
- スナップショットコピーが増分かどうか(CloudWatchイベントから)
- データ転送量(Billing コンソールから)
前者は、以下ページの記載が参考になります。
コピー先の各リージョンで以下のイベントパターンをもつ CloudWatch イベントルールを作成し、通知内容から増分かどうかを確認しました。
{ "source": ["aws.ec2"], "detail-type": ["EBS Snapshot Notification"], "detail": { "event": ["copySnapshot"] } }
後者は検証の実行から 24 時間程度の十分な時間を置き、Billing コンソールの「請求書」から確認します。検証を始める前のデータ転送量はほぼ 0 でした。
EBS スナップショットの作成
以下のインスタンスを用意し作業します。
- 大阪リージョン
- Amazon Linux2
- t3.small
- EBS ボリューム 200 GiB(gp3・暗号化なし)
作業前のディスクの使用量は以下で、およそ 1.8 GiBが使用されていました。
sh-4.2$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 960M 0 960M 0% /dev tmpfs 969M 0 969M 0% /dev/shm tmpfs 969M 400K 969M 1% /run tmpfs 969M 0 969M 0% /sys/fs/cgroup /dev/nvme0n1p1 200G 1.8G 199G 1% / tmpfs 194M 0 194M 0% /run/user/0
まず以下コマンドで 100 GiB のデータを追加します。
sh-4.2$ sudo dd if=/dev/zero of=100G_dummy bs=1G count=100 100+0 records in 100+0 records out 107374182400 bytes (107 GB) copied, 818.21 s, 131 MB/s
実行後に確認するとおよそ 102 GiB が使用されていることが分かります。
sh-4.2$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 960M 0 960M 0% /dev tmpfs 969M 0 969M 0% /dev/shm tmpfs 969M 400K 969M 1% /run tmpfs 969M 0 969M 0% /sys/fs/cgroup /dev/nvme0n1p1 200G 102G 99G 51% / tmpfs 194M 0 194M 0% /run/user/0
この時点で EBS スナップショットを取得し、作成が完了したらリージョン内のコピー(デフォルトキー、カスタマー管理キー付与)、リージョン間コピー(3パターン)を行います。
以降、2回目と3回目も同様の手順でデータ追加・EBS スナップショット取得・コピーを行います。
それぞれのデータ追加の内訳は以下の通りです。
#データ追加 sh-4.2$ sudo dd if=/dev/zero of=50G_dummy bs=1G count=50 50+0 records in 50+0 records out 53687091200 bytes (54 GB) copied, 408.377 s, 131 MB/s #ディスク使用量確認 sh-4.2$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 960M 0 960M 0% /dev tmpfs 969M 0 969M 0% /dev/shm tmpfs 969M 400K 969M 1% /run tmpfs 969M 0 969M 0% /sys/fs/cgroup /dev/nvme0n1p1 200G 152G 49G 76% / tmpfs 194M 0 194M 0% /run/user/0
#データ追加 sh-4.2$ sudo dd if=/dev/zero of=5G_dummy bs=1G count=5 5+0 records in 5+0 records out 5368709120 bytes (5.4 GB) copied, 39.6104 s, 136 MB/s #ディスク使用量確認 sh-4.2$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 960M 0 960M 0% /dev tmpfs 969M 0 969M 0% /dev/shm tmpfs 969M 344K 969M 1% /run tmpfs 969M 0 969M 0% /sys/fs/cgroup /dev/nvme0n1p1 200G 157G 44G 79% /
それぞれのスナップショットを以下の通り呼称します。
名称 | 取得時のデータサイズ |
---|---|
1st スナップショット | およそ 102GiB |
2nd スナップショット | およそ 152GiB |
3rd スナップショット | およそ 157GiB |
EBS スナップショットのリージョン間コピーのパターンごとのデータ転送量
各パターンでの結果を確認していきます。
暗号化なしでリージョン間コピーした場合
大阪→東京リージョンで試行しました。
# | コピー対象 | コピー前 | コピー後 | 増分か |
---|---|---|---|---|
1 | 1st スナップショット | 暗号化なし | 暗号化なし | いいえ |
2 | 2nd スナップショット | 暗号化なし | 暗号化なし | はい |
3 | 3rd スナップショット | 暗号化なし | 暗号化なし | はい |
この試行を行なった翌日に AWS マネジメントコンソールの Billing コンソールからデータ転送量を確認すると、およそ 1.3 GB と記録されていました。
3rd スナップショットを取得した時点で EBS ボリュームには 157 GiB のデータがあったのに、データ転送量はこんなに圧縮されるんだ……というのが驚きでした。
これはリージョン固有の事象だったりする?
大阪→東京という組み合わせ特有の事象なのか?というのが少し気になったので以下のパターンも試しました。
- 大阪→ムンバイ
- 東京→バージニア北部
いずれも、EBS ボリューム内のデータ量より著しく低いデータ転送量が記録されていました。 *1
リージョン固有の事象でなく、コピー前後ともに暗号化なしの場合に再現が確認できました。
デフォルトキーで暗号化されたものをリージョン間コピーした場合
大阪→ソウルリージョンで試行しました。
# | コピー対象 | コピー前 | コピー後 | 増分か |
---|---|---|---|---|
1 | 1st スナップショット | aws/ebs で暗号化 | aws/ebs で暗号化 | いいえ |
2 | 2nd スナップショット | aws/ebs で暗号化 | aws/ebs で暗号化 | はい |
3 | 3rd スナップショット | aws/ebs で暗号化 | aws/ebs で暗号化 | はい |
この試行の結果、記録されていた転送量はおよそ 157 GB でした。 場合によっては(102 + 152 + 157 )GBとなることもあるかなと思っていたのですが、うまいこと増分のみを転送してくれているようです。
カスタマー管理キーで暗号化されたものをリージョン間コピーした場合
大阪→シンガポールリージョンで試行しました。
# | コピー対象 | コピー前 | コピー後 | 増分か |
---|---|---|---|---|
1 | 1st スナップショット | プライマリキーで暗号化 | レプリカで暗号化 | いいえ |
2 | 2nd スナップショット | プライマリキーで暗号化 | レプリカで暗号化 | はい |
3 | 3rd スナップショット | プライマリキーで暗号化 | レプリカで暗号化 | はい |
こちらでも転送量はおよそ 157 GB となっていました。デフォルトキーでなくとも考え方は同じようです。
増分でないリージョン間コピーを挟んだ場合
大阪→シドニーリージョンで試行しました。
# | コピー対象 | コピー前 | コピー後 | 増分か |
---|---|---|---|---|
1 | 1st スナップショット | 暗号化なし | 暗号化なし | いいえ |
2 | 2nd スナップショット | 暗号化なし | aws/ebs で暗号化 | いいえ |
3 | 3rd スナップショット | 暗号化なし | aws/ebs で暗号化 | はい |
試行の結果、データ転送量はおよそ 158GB となりました。
これは先ほどのソウルリージョンへのコピーのパターンと比べて、1st スナップショット(暗号化なし)の分だけ転送量が多くなっているものと見受けられます。
追加のデータ転送を行った場合
以下のコピーを行った大阪→シンガポールリージョンに追加のコピーを行います。
# | コピー対象 | コピー前 | コピー後 | 増分か |
---|---|---|---|---|
1 | 1st スナップショット | プライマリキーで暗号化 | レプリカで暗号化 | いいえ |
2 | 2nd スナップショット | プライマリキーで暗号化 | レプリカで暗号化 | はい |
3 | 3rd スナップショット | プライマリキーで暗号化 | レプリカで暗号化 | はい |
上記の状態から、以下を実施します。
# | コピー対象 | コピー前 | コピー後 | 増分か |
---|---|---|---|---|
4 | 3rd スナップショット | 暗号化なし | aws/ebs で暗号化 | いいえ |
これにより、データ転送量としておよそ 157 GB が追加されました。コピー先のリージョンにおいて#4のスナップショットは#1~3のそれと異なるキーで暗号化されているため、増分でなくフルサイズでのスナップショットとなります。そのため、まるまる 157 GBが転送されたように見受けられます。
さらに、以下を実施します。
# | コピー対象 | コピー前 | コピー後 | 増分か |
---|---|---|---|---|
5 | 3rd スナップショット | 暗号化なし | 暗号化なし | いいえ |
これにより、およそ 1.3 GBがデータ転送量として追加されました。このサイズは暗号化なしで試した大阪→東京リージョンの結果と一致しています。
- スナップショットコピーが増分の場合は増分のみ転送
- スナップショットコピーが増分でない場合はフルサイズで転送
- コピーに前後で EBS スナップショットが暗号化されていない場合は転送量が圧縮される
……ということが分かりました。
無闇矢鱈と暗号化済み EBS スナップショットをリージョン間コピーしないように
EBS スナップショットをリージョン間コピーした場合のデータ転送量の考え方を確認してみました。
データの内訳により効率が変わるかと思いますが、暗号化なしの場合はかなり圧縮してくれることが分かりました。また、コピー後のスナップショットコピーが増分の場合はデータ転送量も増分だけで済むことが確認できました。
そんなこんなで検証を繰り返していたら AWS 利用費が意外と嵩んでしまったので、皆さんも検証の際はお気をつけください。
▲ なぜ先に0.09USD/GBだという内訳を確認しておかないのか
このエントリではデータ転送量をメイントピックに絞って記載しましたが、「どういった場合にスナップショットコピーが増分になるか」については以下のエントリで取り上げています。
あわせて読んでいただくと理解が深まるかと思います。
以上、 チバユキ (@batchicchi) がお送りしました。
参考
脚注
- ちなみに大阪→ムンバイは大阪→東京と同じ条件で試行し同じ結果に、東京→バージニアの場合はデータサイズ 17GiB のスナップショットをコピーしてデータ転送量が 0.65 GB の結果となりました。 ↩