Making snaps faster
The solution to our problem was to just wait
Not even a month after I had published this post about benchmarking the restore performance of EBS snapshots from Amazon S3, AWS go a released Fast Snapshot Restore (FSR) feature!
Initially I thought this was the answer to all of my problems, but as it turns out my original solution does still have some merit.
You see the key is in the name - “Fast Snapshot Restore” not “Instant Snapshot Restore”
So we have broken the boundaries of physics yet and found some way to instantly restore data from S3 to EBS. There is still a period of time between enabling the FSR and it being fully available. There is more info on the site here, but it does say “It takes 60 minutes per TiB to optimize a snapshot.”
So in my scenario the increase in overhead without using this was less than 1/2 an hour and I am working with multi TB volumes, so using FSR is going to introduce a lot more time delay than would be acceptable.
As I suspected previously, this is due to use dealing largely with the transaction log data to pick up the delta’s and not have to reload the entire volume. So I can see a place for FSR if we did need to do this.
I have updated the automation script to enable FSR for the volumes.