Speeding Up Large EBS Volume Initialization During AWS MGN Migrations

Background

Amazon EBS volumes created from snapshots go through a process called volume initialization. Data blocks must be downloaded from Amazon S3 and written to the new volume. Until all blocks have been loaded, the volume may experience increased I/O latency and decreased performance. Full volume performance is achieved only once all storage blocks have been written to the volume. You can read more about this behavior in Initialize Amazon EBS volumes.

For most workloads, this initialization is transparent. But for database servers with multi-terabyte volumes and cutover windows under four hours, the initialization speed becomes the limiting factor.

AWS offers Provisioned Rate for Volume Initialization, which allows you to specify an initialization rate between 100 and 300 MiB/s when creating a volume from a snapshot. At the maximum rate of 300 MiB/s, a 3 TB volume would initialize in approximately 2.8 hours. This may be sufficient for many migration scenarios. However, if your cutover window is tighter or you need faster initialization, the io2 approach described below provides an alternative.

What We Observed

During a data center migration involving large database servers with volumes up to 3 TB, we measured the following initialization throughput after AWS MGN launched the target instances from snapshots:

• gp3 volumes: 130 to 140 MB/s actual throughput during initialization
• io2 volumes: 700 MB/s to 1.2 GB/s during initialization

It is worth noting that the gp3 volumes were configured with higher throughput settings (up to 1,000 MB/s), but the initialization throughput did not reflect those settings. This is expected, as the configured throughput and IOPS apply to steady-state volume performance, not to the background initialization process described in the EBS initialization documentation.

At these rates, a 3 TB gp3 volume takes roughly 6.5 hours to fully initialize. The same data on io2 completes in about 60 minutes.

Your results may vary depending on factors such as region, snapshot age, and volume configuration. We recommend running your own benchmarks in a non-production environment before planning cutover timelines around these numbers.

Why This Matters for Migrations

Many organizations plan their migration cutovers around maintenance windows. A four-hour window is common. If the database volumes need to be fully initialized before the application can serve production traffic, a 6.5-hour initialization on gp3 breaks the cutover plan.

This is especially relevant for:

• Database servers with volumes larger than 1 TB
• Migrations using AWS MGN for rehost (lift-and-shift)
• Environments where the target volume type is gp3 for cost reasons

Options for Faster Initialization

Option 1: Provisioned Rate for Volume Initialization

Provisioned Rate for Volume Initialization lets you specify a predictable initialization rate (100–300 MiB/s) when creating a volume from a snapshot. This is the simplest approach and works well when your cutover window can accommodate the resulting timeline. At 300 MiB/s, a 3 TB volume initializes in approximately 2.8 hours. Pricing is based on the full snapshot size and the specified rate. See EBS pricing for details.

While Provisioned Rate fits within a 4-hour cutover window, it leaves limited time for post-initialization validation, application startup, and rollback decisions.

Option 2: Launch on io2, Then Convert to gp3

If you need initialization faster than what Provisioned Rate offers, the approach that worked in our case was to launch with io2 volumes and convert to gp3 after validation.

Step 1 — Update the AWS MGN launch template. Set the target volume type to io2 for database server volumes. In our testing, the io2 volumes were configured with 64,000 IOPS.

Step 2 — Launch and wait for initialization. In our testing, a 3 TB io2 volume initialized in roughly 60 minutes and a 1 TB volume in about 20 minutes.

Step 3 — Validate the application. Run your standard post-migration checks. Confirm the database is healthy and serving queries correctly.

Step 4 — Convert to gp3 using ModifyVolume. During a low-activity window after cutover, modify the volume type:

aws ec2 modify-volume \
    --volume-id vol-0123456789abcdef0 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

A few things to keep in mind about the conversion:

• Pricing switches to gp3 rates immediately on modification
• The volume stays online during the change (no reboot or detach needed)
• Performance characteristics transition to gp3 levels during the modification window
• Test this conversion in a non-production environment first to understand the behavior during transition

Cost Comparison

Approach	Time (3 TB)	Approximate Cost
gp3 (default initialization)	~6.5 hours	No additional cost
Provisioned Rate (300 MiB/s)	~2.8 hours	~$10.80 per volume
io2 (64,000 IOPS, convert to gp3)	~60 minutes	~$21 per volume

Provisioned Rate pricing is based on full snapshot size and specified rate. The io2 cost estimate is based on public io2 pricing for a 3 TB volume at 64,000 IOPS for 4 hours. For most migrations, both options are negligible compared to the cost of extending a maintenance window or running a second cutover attempt.

When You Probably Do Not Need This

Not every migration needs these workarounds. You can skip them if:

• Your volumes are under 500 GB (initialization completes faster at smaller sizes)
• You do not have a strict cutover window
• Your workload can tolerate degraded read performance during initialization (many non-database workloads can)
• You are already planning to use io2 as the final volume type

Summary

If you are migrating large database servers with AWS MGN and running into cutover window constraints, check whether EBS initialization is the bottleneck. Consider Provisioned Rate for Volume Initialization as a first option — it provides predictable initialization at up to 300 MiB/s with no volume type changes required. If you need faster initialization than Provisioned Rate offers, launching on io2 and converting to gp3 after validation is a practical alternative that adds minimal cost and keeps your cutover on schedule.

We recommend testing either approach in your own environment, as initialization performance can vary based on region, snapshot characteristics, and volume configuration.

Resources

• Initialize Amazon EBS volumes
• Provisioned Rate for Volume Initialization
• Amazon EBS volume types
• Modify an Amazon EBS volume
• AWS Application Migration Service documentation
• Amazon EBS pricing