developersIO
[アップデート] EBSボリュームのクローンを高速に作成できるようになりました

[アップデート] EBSボリュームのクローンを高速に作成できるようになりました

検証やテストなどで素早くボリュームを複製したい場合に
Amazon EBSAWS
FacebookHatena blogX
2025.10.21

既存のEBSボリュームと同じものをすぐに用意したい

こんにちは、のんピ(@non____97)です。

皆さんは既存のEBSボリュームと同じものをすぐに用意したいなと思ったことはありますか? 私はあります。

同じデータが保存されているEBSボリュームを作成しようとすると、以下のようなプロセスが必要になります。

  • EBSボリュームのスナップショットの取得
  • EBSスナップショットからのリストア

ここで気になるのは時間です。

前者については前回スナップショットからの差分量によって取得完了にかかる時間が大きく変動します。対象のEBSボリュームについて初めてのEBSスナップショットである場合や、差分量が多い場合は実際に使用できるようになるまでにかなりの時間がかかるでしょう。場合によっては数時間〜数十時間かかることもあります。

後者については最大パフォーマンスが提供されるまでの時間が気になります。

以下記事で紹介されているとおり、EBSスナップショットからリストアされたEBSボリュームがフル性能を出すためには、ボリュームの初期化やddによる全ブロックのリードが必要です。

https://dev.classmethod.jp/articles/ebs-provisioned-rate-volume-initialization/

このように同一のデータを保存しているEBSボリュームを手早く用意するためには時間がかかります。

今回、EBSボリュームのクローンを作成できるようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2025/10/amazon-ebs-volume-clones-instant-volume-copies/

これにより、瞬時に同一データを保存しているEBSボリュームを複製することが可能になりました。

使い勝手的にはAuroraのクローンやAmazon FSx for NetApp ONTAPのFlexCloneのような感じでしょうか。

https://dev.classmethod.jp/articles/amazon-aurora-database-cloning/

https://dev.classmethod.jp/articles/amazon-fsx-for-netapp-ontap-flexclone/

実際に触ってみたので紹介します。

いきなりまとめ

  • 既存のEBSボリュームと同じAZ内でポイントインタイムコピーを瞬時に作成可能に
  • クローンボリュームは即時に作成されるが、裏側で初期化処理が走る
    • ソースボリュームからバックグラウンドでコピーされる
    • 初期化中もソースボリュームはパフォーマンス影響なく使用できる
    • 初期化中もクローンボリュームに1msのレイテンシーでデータブロックにアクセスできる
  • 暗号化されていないボリュームのクローンは作成できない
  • Auroraのクローンのようにソースからの変更分だけ課金が発生するのではなく、通常のEBSボリュームとして課金およびクローン処理対する課金が発生する

仕様の確認

まずはドキュメントを確認します。

主に確認するドキュメントは以下です。

https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copying-volume.html

主に注意して内容は以下のとおりです。

  • 既存のEBSボリュームと同じAZ内でポイントインタイムコピーを瞬時に作成可能
  • クローンボリュームはクラッシュ整合性があるコピーとして作成される
  • クローンボリュームは即時に作成されるが、裏側で初期化処理が走る
    • ソースボリュームからバックグラウンドでコピーされる
    • 初期化中もソースボリュームはパフォーマンス影響なく使用できる
    • 初期化中もクローンボリュームに1msのレイテンシーでデータブロックにアクセスできる
    • 初期化までにかかる時間は以下
      • 最初の1TiB : 最大6時間
      • 16TiBまで : 1.2時間/TiB
      • 16TiB以上 : 24時間
  • 暗号化されていないボリュームのクローンは作成できない
  • クローンボリュームはソースボリュームと同じKMSキーを使用する
  • 同一のソースボリュームから同時に作成可能なクローンボリュームは1つのみ
  • リージョンごとに最大5個の同時クローンボリュームの初期化を実施可能
  • コピー中にソースボリュームを削除してもコピー操作は完了する
  • ソースボリュームに割り当てたタグはクローンボリュームに割り当てられない

初期化中にパフォーマンス影響がないところなどを見ると、EBSボリュームのIOPSやスループットも消費しなさそうですね。AWSの裏側の処理として動いてくれるのでしょう。

料金

気になるのは料金です。

Auroraのクローンのようにソースからの変更分だけ課金が発生するのでしょうか。

料金ページには以下のように、ソースボリュームへ書き込まれているデータ量に対して課金が発生し、クローンボリュームは通常のEBSボリュームの課金が発生するとありました。

When creating a clone of a source volume you are charged for the cloning operation. The cloning/copy operation is charged based on the size of the written blocks of the source volume at the time of clone creation. The newly created volume is charged as a standard EBS volume.

Amazon EBS Volume Clones $0.00080/GB

..(中略)..

Example 13 - Amazon EBS Volume Clones
Amazon EBS Volume Clones allows you to instantly create copies of your EBS volumes within the same Availability Zone. When you create a copy using Volume Clones, you are charged based on the size of the written blocks of the source volume at the time of clone creation.

For example, let's assume you have a source EBS volume that is provisioned for 1000 GB, and has an allocated size of 600 GB (represents the size of all the blocks that were written to the source volume at the time the clone was initiated). If you create a clone of this volume in a region that charges $0.00080 per GB, you will be billed $0.48 (600 GB x $0.00080 per GB). Please note that the cost for Volume Clones is independent of your EBS volume costs. The resulting copied volume will be charged separately as a standard EBS volume.

EBS Pricing

つまりは、Auroraのクローンのようにソースからの変更分だけ課金が発生する形ではないようです。

やってみる

データの書き込み

クローンボリュームを作成する前にソースボリュームにデータを書き込みます。

EC2インスタンスにはEBSボリュームを2つマウントしています。

2.ボリューム一覧.png

このうち、/dec/sdbにマウントしているボリュームをソースボリュームとして扱います。

3.対象のEBSボリューム.png

ちなみにEC2インスタンスのインスタンスタイプはc7i.largeです。

デバイスが/dev/sdbのEBSボリュームをXFSでフォーマットしてマウントします。

$ df -hT
Filesystem       Type      Size  Used Avail Use% Mounted on
devtmpfs         devtmpfs  4.0M     0  4.0M   0% /dev
tmpfs            tmpfs     1.9G     0  1.9G   0% /dev/shm
tmpfs            tmpfs     762M  8.6M  753M   2% /run
/dev/nvme0n1p1   xfs       8.0G  1.6G  6.4G  20% /
tmpfs            tmpfs     1.9G     0  1.9G   0% /tmp
/dev/nvme0n1p128 vfat       10M  1.3M  8.7M  13% /boot/efi

$ lsblk
NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0   8G  0 disk
├─nvme0n1p1   259:2    0   8G  0 part /
├─nvme0n1p127 259:3    0   1M  0 part
└─nvme0n1p128 259:4    0  10M  0 part /boot/efi
nvme1n1       259:1    0  40G  0 disk

$ sudo mkfs -t xfs /dev/sdb
meta-data=/dev/sdb               isize=512    agcount=4, agsize=2621440 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
         =                       exchange=0
data     =                       bsize=4096   blocks=10485760, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

$ sudo lsblk -f
NAME          FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1   xfs          /     6bf6dcc0-0673-443a-b92a-b26a3524cf3b    6.3G    20% /
├─nvme0n1p127
└─nvme0n1p128 vfat   FAT16       92F7-4B7C                               8.7M    13% /boot/efi
nvme1n1       xfs                42da5136-52ba-415b-b723-786ecdb9333e

$ sudo mkdir /vol
$ sudo mount /dev/sdb /vol

$ df -hT
Filesystem       Type      Size  Used Avail Use% Mounted on
devtmpfs         devtmpfs  4.0M     0  4.0M   0% /dev
tmpfs            tmpfs     1.9G     0  1.9G   0% /dev/shm
tmpfs            tmpfs     762M  8.6M  753M   2% /run
/dev/nvme0n1p1   xfs       8.0G  1.6G  6.4G  20% /
tmpfs            tmpfs     1.9G     0  1.9G   0% /tmp
/dev/nvme0n1p128 vfat       10M  1.3M  8.7M  13% /boot/efi
tmpfs            tmpfs     381M     0  381M   0% /run/user/0
/dev/nvme1n1     xfs        40G  318M   40G   1% /vol

32GiBのファイルを作成します。

sudo dd if=/dev/urandom of=/vol/random_pattern_binary_block_1GiB bs=1M count=1024

$ sudo dd if=/dev/urandom of=/vol/random_pattern_binary_block_32GiB bs=1M count=32768
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 125.078 s, 275 MB/s

読み込み速度を確認しておきます。

$ dd if=/vol/random_pattern_binary_block_32GiB of=/dev/null bs=1M
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 126.674 s, 271 MB/s

$ dd if=/vol/random_pattern_binary_block_32GiB of=/dev/null bs=1M
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 126.778 s, 271 MB/s

270MBpsほどと考えておけば良いでしょう。

CloudWatchメトリクスでも確認できます。

6.読み取りをした際の読み取りスループット.png

EBSボリュームのクローンの作成

それではボリュームのクローンを作成します。

先ほど32GiBのファイルを作成したEBSボリュームを選択して、ボリュームをコピーをクリックします。

4.ボリュームのクローン.png

ボリュームタイプやサイズ、IOPS、スループット、タグを設定します。

5.クローンボリュームの作成.png

クローンのタイミングでソースボリュームよりも小さいサイズの縮小はできませんでした。残念。

今回はタグを除いてソースボリュームと同じ値を設定しました。

ボリュームをコピーをクリックします。

すると、すぐさまボリュームの状態が使用可能のボリュームが現れました。

7.クローンが作成されたことを確認.png

爆速ですね。

初期化のステータスを確認すると、まだ0%です。

8.初期化中.png

少し待つと、44%になりました。

9.初期化中2.png

初期化処理が走っている状態でクローンボリュームを/dev/sdcでEC2インスタンスにアタッチします。

$ sudo mkdir /vol_clone
$ sudo mount /dev/sdc /vol_clone
mount: /vol_clone: wrong fs type, bad option, bad superblock on /dev/nvme2n1, missing codepage or helper program, or other error.

$ sudo mount /dev/sdc /vol_clone
mount: /vol_clone: wrong fs type, bad option, bad superblock on /dev/nvme2n1, missing codepage or helper program, or other error.

マウントできないですね。

ログを確認してみましょう。

$ sudo dmesg | tail -20
[ 1579.535104] pcieport 0000:03:03.6: pciehp: Slot(32-1) Powering on due to button press
[ 1579.535923] pcieport 0000:03:03.6: pciehp: Slot(32-1): Card present
[ 1579.536422] pcieport 0000:03:03.6: pciehp: Slot(32-1): Link Up
[ 1579.688786] pci 0000:22:00.0: [1d0f:8061] type 00 class 0x010802
[ 1579.689459] pci 0000:22:00.0: reg 0x10: [mem 0x00000000-0x00003fff]
[ 1579.690165] pci 0000:22:00.0: enabling Extended Tags
[ 1579.691030] pci 0000:22:00.0: BAR 0: assigned [mem 0xc7f00000-0xc7f03fff]
[ 1579.691631] pcieport 0000:03:03.6: PCI bridge to [bus 22]
[ 1579.692150] pcieport 0000:03:03.6:   bridge window [mem 0xc7f00000-0xc80fffff]
[ 1579.692735] pcieport 0000:03:03.6:   bridge window [mem 0x1a0000000-0x1a0ffffff 64bit pref]
[ 1579.693793] nvme nvme2: pci function 0000:22:00.0
[ 1579.694242] nvme 0000:22:00.0: enabling device (0000 -> 0002)
[ 1579.703059] nvme nvme2: 2/0/0 default/read/poll queues
[ 1612.983436] XFS (nvme2n1): Filesystem has duplicate UUID 42da5136-52ba-415b-b723-786ecdb9333e - can't mount
[ 1664.605596] XFS (nvme2n1): Filesystem has duplicate UUID 42da5136-52ba-415b-b723-786ecdb9333e - can't mount
[ 1680.804464] XFS (nvme2n1): Filesystem has duplicate UUID 42da5136-52ba-415b-b723-786ecdb9333e - can't mount
[ 1708.914268] XFS (nvme2n1): Filesystem has duplicate UUID 42da5136-52ba-415b-b723-786ecdb9333e - can't mount
[ 1711.325744] XFS (nvme2n1): Filesystem has duplicate UUID 42da5136-52ba-415b-b723-786ecdb9333e - can't mount
[ 1771.933951] XFS (nvme2n1): Filesystem has duplicate UUID 42da5136-52ba-415b-b723-786ecdb9333e - can't mount
[ 1801.766273] XFS (nvme2n1): Filesystem has duplicate UUID 42da5136-52ba-415b-b723-786ecdb9333e - can't mount

$ sudo lsblk -f
NAME          FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1   xfs          /     6bf6dcc0-0673-443a-b92a-b26a3524cf3b    6.3G    20% /
├─nvme0n1p127
└─nvme0n1p128 vfat   FAT16       92F7-4B7C                               8.7M    13% /boot/efi
nvme1n1       xfs                42da5136-52ba-415b-b723-786ecdb9333e    7.6G    81% /vol
nvme2n1       xfs                42da5136-52ba-415b-b723-786ecdb9333e

$ sudo blkid /dev/sdc
/dev/sdc: UUID="42da5136-52ba-415b-b723-786ecdb9333e" BLOCK_SIZE="4096" TYPE="xfs"

$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 40 GiB, 42949672960 bytes, 83886080 sectors
Disk model: Amazon Elastic Block Store
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

どうやらUUIDが重複しているようです。クローンボリュームを同一マシンにマウントしたい場合は注意が必要ですね。

ソースボリュームをアンマウントして、クローンボリュームをマウントします。

$ sudo umount /dev/sdb
$ sudo mount /dev/sdc /vol_clone

$ df -hT
Filesystem       Type      Size  Used Avail Use% Mounted on
devtmpfs         devtmpfs  4.0M     0  4.0M   0% /dev
tmpfs            tmpfs     1.9G     0  1.9G   0% /dev/shm
tmpfs            tmpfs     762M  8.7M  753M   2% /run
/dev/nvme0n1p1   xfs       8.0G  1.6G  6.4G  20% /
tmpfs            tmpfs     1.9G     0  1.9G   0% /tmp
/dev/nvme0n1p128 vfat       10M  1.3M  8.7M  13% /boot/efi
tmpfs            tmpfs     381M     0  381M   0% /run/user/0
/dev/nvme2n1     xfs        40G   33G  7.7G  81% /vol_clone

マウントできました。

現時点の初期化ステータスは69%です。このタイミングでクローンボリュームのファイルの読み込みを行います。

$ dd if=/vol_clone/random_pattern_binary_block_32GiB of=/dev/null bs=1M
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 126.78 s, 271 MB/s

271MBpsです。ソースボリュームで同じ操作をした際と同じ速度ですね。

ちなみに、読み取りが完了したタイミングでもEBSボリュームの初期化ステータス69%ででした。

AWS CLIでも確認しましょう。

> aws ec2 describe-volume-status --volume-ids vol-0c338dba4fa97b6d8 --region ap-northeast-1
{
    "VolumeStatuses": [
        {
            "Actions": [],
            "AvailabilityZone": "ap-northeast-1a",
            "Events": [],
            "VolumeId": "vol-0c338dba4fa97b6d8",
            "VolumeStatus": {
                "Details": [
                    {
                        "Name": "io-enabled",
                        "Status": "passed"
                    },
                    {
                        "Name": "io-performance",
                        "Status": "normal"
                    },
                    {
                        "Name": "initialization-state",
                        "Status": "initializing"
                    }
                ],
                "Status": "ok"
            },
            "InitializationStatusDetails": {
                "InitializationType": "volume-copy",
                "Progress": 98
            },
            "AvailabilityZoneId": "apne1-az4"
        }
    ]
}

> aws ec2 describe-volume-status --volume-ids vol-0c338dba4fa97b6d8 --region ap-northeast-1
{
    "VolumeStatuses": [
        {
            "Actions": [],
            "AvailabilityZone": "ap-northeast-1a",
            "Events": [],
            "VolumeId": "vol-0c338dba4fa97b6d8",
            "VolumeStatus": {
                "Details": [
                    {
                        "Name": "io-enabled",
                        "Status": "passed"
                    },
                    {
                        "Name": "io-performance",
                        "Status": "normal"
                    },
                    {
                        "Name": "initialization-state",
                        "Status": "completed"
                    }
                ],
                "Status": "ok"
            },
            "InitializationStatusDetails": {
                "InitializationType": "volume-copy",
                "Progress": 100
            },
            "AvailabilityZoneId": "apne1-az4"
        }
    ]
}

気づいたら100%になりましたね。

マネジメントコンソール上でも100%であることを確認しました。

10.初期化完了.png

初期化が完了するまでは13分ほどでした。

また、ソースボリュームのメトリクスを確認すると、無風状態でした。

12.ソースボリュームのメトリクス.png
11.ソースボリュームのメトリクスを確認すると、読み取りスループットは走っていない.png

確かに初期化中はソースボリュームのパフォーマンス影響はなさそうです。

初期化が完了したということで、再度読み込みをします。

$ dd if=/vol_clone/random_pattern_binary_block_32GiB of=/dev/null bs=1M
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 126.779 s, 271 MB/s

特に読み込み速度は変わりないですね。安定しています。

クローンの初期化中のソースボリュームの削除

クローンの初期化中にソースボリュームを削除しても問題ないかを確認します。

クローンボリュームのソースは先ほど作成したクローンボリュームです。

13.クローンボリュームのクローン.png

クローンボリュームのクローンボリュームが作成されたことを確認します。

14.クローンボリュームのクローンの確認.png

初期化中に、今回のクローンのソースボリュームを削除します。

15.強制デタッチ.png
16.ボリュームの削除.png

削除時の初期化ステータスは23%でした。

> aws ec2 describe-volume-status --volume-ids vol-0546763a32cbed7af --region ap-northeast-1
{
    "VolumeStatuses": [
        {
            "Actions": [],
            "AvailabilityZone": "ap-northeast-1a",
            "Events": [],
            "VolumeId": "vol-0546763a32cbed7af",
            "VolumeStatus": {
                "Details": [
                    {
                        "Name": "io-enabled",
                        "Status": "passed"
                    },
                    {
                        "Name": "io-performance",
                        "Status": "not-applicable"
                    },
                    {
                        "Name": "initialization-state",
                        "Status": "initializing"
                    }
                ],
                "Status": "ok"
            },
            "InitializationStatusDetails": {
                "InitializationType": "volume-copy",
                "Progress": 23
            },
            "AvailabilityZoneId": "apne1-az4"
        }
    ]
}

初期化処理が完了するまで待ちます。

> while true; do
  date
  PROGRESS=$(aws ec2 describe-volume-status --volume-ids vol-0546763a32cbed7af --region ap-northeast-1 --query 'VolumeStatuses[0].InitializationStatusDetails.Progress' --output text)
  echo "Progress: ${PROGRESS}%"
  [ "$PROGRESS" = "100" ] && break
  sleep 1
done
2025年 10月20日 月曜日 19時19分02秒 JST
Progress: 85%
2025年 10月20日 月曜日 19時19分06秒 JST
Progress: 85%
.
.
(中略)
.
.
2025年 10月20日 月曜日 19時20分29秒 JST
Progress: 85%
2025年 10月20日 月曜日 19時20分32秒 JST
Progress: 85%
2025年 10月20日 月曜日 19時20分36秒 JST
Progress: 100%

100%になりました。

クローンボリュームを作成して、初期化ステータスが100%になるまでの時間は12分ほどでした。

未暗号化のEBSボリュームのクローンの作成

最後に未暗号化のEBSボリュームのクローンを作成しようとしてみます。

1.未暗号化EBSボリューム.png

はい、コピーできるのは暗号化されたボリュームだけです。と怒られました。

検証やテストなどで素早くボリュームを複製したい場合に

EBSボリュームのクローンを高速に作成できるようになったアップデートを紹介しました。

検証やテストなどで素早くボリュームを複製したい場合は必須ですね。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!

この記事をシェアする

FacebookHatena blogX

関連記事

EBS スナップショットのアーカイブが料金削減に繋がらない
中村祐太郎
2025.10.08
Amazon EBS gp3 ボリュームの性能上限が大幅に引き上がり、容量 4 倍、IOPS 5 倍、スループット 2 倍になりました
大村 保貴
2025.09.29
[アップデート] AWS Fault Injection Service (FIS) で EBS の I/O レイテンシー注入アクションが利用出来るようになりました
いわさ
2025.09.24
Amazon EBS ボリュームの詳細なパフォーマンス統計情報を CloudWatch エージェントから取得可能になりました
大村 保貴
2025.09.21