Why do Windows snapshots take a long time?

I am running a vanilla Windows install on Amazon EBS volume. The computer takes 10 minutes to boot, which may be understandable开发者_Go百科 as 2 reboots are required. However, taking a snapshot is also a 10-15 minute process. Can anyone explain this? Any way to speed it up? I am a bit surprised, because I thought that snapshots are immediate replicas of the running EBS volume, in which case shouldn't they take just a couple of seconds to complete?

---

I will add that the console shows that "snapshot" is completed very quickly. But the "AMI" section is what seems to take 10-20 minutes. What's the difference? Is the snapshot available for use immediately, or do I need to wait for the AMI?

---

From the EBS product page:

Amazon EBS snapshots are incremental backups, meaning that only the blocks on the device that have changed since your last snapshot will be saved. If you have a device with 100 GBs of data, but only 5 GBs of data has changed since your last snapshot, only the 5 additional GBs of snapshot data will be stored back to Amazon S3.

Subsequent snapshots are fast because only the changed blocks need to be saved. So the time it takes scales with the amount of changes since the last snapshot.

Is the snapshot available for use immediately, or do I need to wait for the AMI?

Also from the product page:

New volumes created from existing Amazon S3 snapshots load lazily in the background. This means that once a volume is created from a snapshot, there is no need to wait for all of the data to transfer from Amazon S3 to your Amazon EBS volume before your attached instance can start accessing the volume and all of its data. If your instance accesses a piece of data which hasn’t yet been loaded, the volume will immediately download the requested data from Amazon S3, and then will continue loading the rest of the volume’s data in the background.

---

The creation of an AMI is a multiple-step process.

1. The Snapshot of the current machine is started (that's darn near instantaneous)
2. The snapshot copies the "changed blocks" from the base AMI to the snapshot lazily (that's pretty quick too)
3. The underlying Windows image is then prepared to be an AMI base image this starts with booting a "ghost" instance from the image with the snapshot as the disk image.
4. A SYSPREP is started to "reseal" the machine so it gets new machine SIDs.
5. The new image is then re-snapshotted
6. The AMI is marked "complete"