Ваша причина отказа от использования EBS в том, что он работает медленно. Возможно, вы захотите протестировать оптимизированные экземпляры EBS, а также подготовленные тома IOPS EBS (которые даже могут быть RAID-массивами для более высоких IOPS). Это упростит доступ к данным для новых экземпляров.
Обратите внимание, что том EBS требует времени, чтобы сделать все данные доступными с максимальной производительностью. Т.е. производительность, которую вы получаете на новом томе EBS, ниже, чем производительность после заполнения блоков тома.
Вот статья, которую я написал, в которой рассказывается об этом процессе, в том числе об одном способе определить, когда том EBS завершил инициализацию из моментального снимка (хотя в любом случае он в основном включает в себя передачу всего тома через сеть):
http://alestic.com/2010/03/ebs-volume-initialization-from-snapshot
Если ваше приложение хочет запустить сразу за счет некоторой медлительности, когда ему требуется доступ к ранее непрочитанным данным, я бы порекомендовал оптимизированные экземпляры EBS плюс подготовленные тома IOPS EBS, возможно, в RAID-0. После заполнения тома скорость приложения должна значительно возрасти.
В противном случае название игры при загрузке данных из S3 - распараллеливание. У вас может быть сотня одновременных соединений, загружающих фрагменты данных из супермасштабируемой службы S3, если вы используете тип экземпляра с достаточно высоким IO.
Однако даже при использовании интерфейса 1 Гбит / с загрузка 500 ГБ займет более часа.
Вот возможный прием: с оптимизированным экземпляром EBS вы получаете выделенный сетевой интерфейс для подсистемы EBS, отдельный от стандартного сетевого интерфейса. Возможно, вам удастся сократить время загрузки данных вдвое, если вы загрузите половину данных с S3, а другую половину с тома EBS.
На всякий случай, если вы не учли это: убедитесь, что ваши данные сжаты в хранилище, чтобы сократить время передачи.
