EFS, EBS и S3: как выбрать правильное облачное хранилище данных

Знаете это чувство, когда вы запускаете приложение, оно работает идеально на локальной машине, а потом падает в облаке с ошибкой "disk full" или "permission denied"? Это классика. Проблема редко бывает в коде - чаще всего мы просто неправильно выбираем тип облачного хранилища. Многие разработчики и админы путают блочные устройства с файловыми системами или пытаются использовать объектные хранилища там, где нужна низкая задержка. Разберемся, чем отличаются Amazon EFS, EBS и S3, чтобы вы перестали платить лишние деньги и не ломали голову над архитектурой.

Что вообще такое облачное хранилище и зачем его делить?

Давайте сразу договоримся о терминах. Облако - это не одна большая жесткая дискета. Это набор сервисов, каждый из которых оптимизирован под свою задачу. Если вам нужно хранить фотографии для сайта, лог-файлы сервера или базу данных SQL, подход будет разным. Ошибка выбора приводит к двум вещам: либо вы платите космические суммы за избыточную производительность, либо ваше приложение тормозит, потому что пытается делать то, для чего хранилище не создано.

В экосистеме Amazon Web Services (AWS) есть три кита хранения данных:

• Amazon S3 (Simple Storage Service) - объектное хранилище для неструктурированных данных любого размера.
• Amazon EBS (Elastic Block Store) - блочное хранилище, которое подключается к одной виртуальной машине как обычный жесткий диск.
• Amazon EFS (Elastic File System) - сетевая файловая система, доступная одновременно множеству серверов.

Каждый из этих сервисов решает конкретные задачи. Понимание их внутренних механизмов поможет вам строить отказоустойчивые системы без лишних костылей.

Amazon S3: король объектных хранилищ

Начнем с самого популярного сервиса. S3 хранит данные как объекты внутри контейнеров, которые называются ведрами (buckets). Объект - это файл плюс метаданные. У него есть уникальный ключ (имя), размер и содержимое. Важно понимать: S3 не является файловой системой в привычном понимании. Вы не можете открыть файл, изменить одну строку в середине и сохранить обратно. Чтобы обновить объект, нужно перезаписать его целиком.

Почему это круто? Потому что масштабируемость здесь бесконечная. Вам не нужно заранее резервировать место. Загрузили терабайт логов - заплатили за терабайт. Загрузили петабайт видео - заплатили за петабайт. Доступ к данным идет через HTTP-запросы (REST API). Это делает S3 идеальным выбором для статического контента: картинок, CSS, JS, бэкапов, архивов.

Однако у медали есть обратная сторона. Задержка при первом обращении к объекту может быть выше, чем при чтении с локального диска. Плюс, если вам нужно часто читать и писать маленькие файлы, накладные расходы на запросы могут сделать работу приложения медленной. Для таких задач лучше подходят другие инструменты.

*Примечание: существуют специальные конфигурации Multi-Attach для SSD томов gp3/io2, но они имеют ограничения по количеству подключений и используются редко.

Amazon EBS: ваш личный виртуальный диск

Если S3 - это полка в библиотеке, куда можно положить книгу и забыть, то EBS - это жесткий диск вашего ноутбука, только виртуальный. Он подключается к конкретной виртуальной машине (EC2 instance) как устройство /dev/xvda или /dev/sda1. Операционная система видит его как обычный блок памяти.

Главная фишка EBS - возможность менять размер и тип тома «на лету», не останавливая сервер. Нужен быстрый диск для базы данных MySQL? Подключайте gp3 или io2. Нужен дешевый архивный диск? Берите st1 или sc1. Но есть критическое ограничение: стандартный том EBS можно подключить только к одному экземпляру EC2 в одной зоне доступности. Если этот экземпляр упадет, данные останутся на томе, но пока вы не отцепите его и не прикрепите к новому серверу, никто другой их не увидит.

Когда использовать EBS?

• Для установки операционной системы.
• Для реляционных баз данных (PostgreSQL, MySQL, Oracle), которым нужны транзакции и низкая задержка.
• Для временных файлов обработки, которые нужны только этому серверу прямо сейчас.

Будьте осторожны с производительностью. Не все типы дисков одинаковы. Например, магнитные диски (st1) хороши для потокового чтения больших файлов, но ужасны для случайного доступа к маленьким записям в базе данных. Всегда смотрите на показатели IOPS (операций ввода-вывода в секунду) и Throughput (пропускную способность).

Amazon EFS: общий сетевой ресурс

А теперь представьте ситуацию: у вас кластер из десяти веб-серверов. Каждый должен иметь доступ к одним и тем же загруженным пользователям фотографиям или файлам конфигурации. С EBS это боль - нужно синхронизировать данные вручную или использовать сложные репликации. Тут на сцену выходит EFS. Это полностью управляемая сетевая файловая система, которая реализует протокол NFSv4. Она позволяет множеству экземпляров EC2 одновременно читать и писать данные.

EFS автоматически растет и уменьшается в зависимости от объема данных. Вы не создаете тома фиксированного размера. Просто монтируете файловую систему к своим серверам, и она становится видна всем им сразу. Это идеально для WordPress, Drupal, Docker-контейнеров, которые шарят общие ресурсы, или для рабочих процессов машинного обучения, где несколько GPU-серверов читают одни и те же датасеты.

Но есть нюанс: цена. EFS стоит дороже за гигабайт, чем EBS или S3. Кроме того, хотя задержка ниже, чем у S3, она все равно выше, чем у локального диска EBS. Поэтому для высоконагруженных баз данных EFS обычно не подходит. Он создан для удобства совместного доступа, а не для гоночных скоростей.

Как выбрать: практический чек-лист

Давайте упростим выбор до простых вопросов. Ответьте себе честно:

1. Нужен ли доступ к данным нескольким серверам одновременно?
   • Нет → Смотрите на EBS или S3.
   • Да → Смотрите на EFS или S3.
2. Это структурированные данные (база данных) или файлы?
   • База данных → Только EBS (если один сервер) или специализированные RDS/DynamoDB.
   • Файлы → EFS или S3.
3. Часто ли вы меняете содержимое файлов?
   • Редко, пишем один раз, читаем много → S3.
   • Часто, редактируем кусками → EFS или EBS.
4. Какой бюджет?
   • Максимально дешево для хранения холодных данных → S3 Glacier или Deep Archive.
   • Средне для активных данных → EBS Standard/GP3.
   • Премиум за удобство и автоматизацию → EFS.

Частая ошибка новичков: пытаться использовать EFS вместо S3 для хранения статики сайта. Да, это работает, так как браузеры могут грузить картинки через CDN, указывающий на Origin в виде балансировщика нагрузки перед EFS. Но это дорого и сложно администрировать. S3 + CloudFront - стандарт де-факто для статики.

Еще одна ловушка - использование EBS для бэкапов. Том EBS живет только в одной зоне доступности. Если зона упадет (что случается редко, но бывает), ваши данные станут недоступны, пока вы не восстановите экземпляр в другой зоне. Для надежных бэкапов всегда используйте S3, который реплицирует данные между несколькими зонами автоматически.

Интеграция и безопасность: о чем молчат туториалы

Выбор типа хранилища неразрывно связан с безопасностью. В S3 вы управляете правами доступа через Bucket Policies и ACLs. Здесь легко ошибиться и открыть весь бакет на чтение всему интернету. Используйте блокировку публичного доступа по умолчанию.

С EBS и EFS история другая. Права доступа определяются на уровне файловой системы внутри вашей виртуальной машины и групп безопасности VPC. Если вы используете EFS, убедитесь, что правила безопасности разрешают трафик по порту 2049 (NFS) от ваших EC2 инстансов. Без этого монтирование просто зависнет.

Шифрование - еще один важный аспект. Все три сервиса поддерживают шифрование данных «в состоянии покоя» (at rest) и «при передаче» (in transit). По умолчанию включено шифрование AES-256. Но если вам нужны комплаенс-требования (например, GDPR или ФЗ-152), рассмотрите использование ключей KMS (Key Management Service), которыми управляете вы сами. Это даст дополнительный контроль над тем, кто может расшифровать данные.

Стоимость: где утекает бюджет

Разберем экономику на пальцах. Предположим, у нас есть 100 ГБ данных.

• S3 Standard: ~$2.30 в месяц. Дополнительно оплачиваются запросы на чтение/запись и исходящий трафик. Если данных мало, а запросов много, счет может вырасти.
• EBS gp3: ~$8.00 в месяц за объем + плата за IOPS и Throughput, если превысите бесплатные лимиты. Цена фиксирована, независимо от количества обращений.
• EFS Standard: ~$30.00 в месяц. Да, в 10 раз дороже S3. Но вы получаете готовую файловую систему с блокировками и правами Unix.

Видите разницу? Если вам нужно просто хранить логи на год, S3 Glacier Instant Retrieval будет стоить копейки по сравнению с EFS. Но если эти логи нужно постоянно анализировать в реальном времени разными скриптами, экономия на S3 съестся стоимостью разработки интеграций.

Заключение: нет универсального решения

Не существует «лучшего» хранилища. Есть лучшее решение для конкретной задачи. S3 - для масштабируемого хранения объектов. EBS - для высокой производительности и изоляции одного сервера. EFS - для простоты совместного использования файлов.

Попробуйте начать с архитектуры, которая максимально проста для вашей текущей стадии развития продукта. Не усложняйте мир EFS, если справится один сервер с диском EBS. Не используйте S3, если вам нужна скорость реакции менее миллисекунды. И помните: мигрировать данные между этими сервисами можно, но это требует времени и усилий. Лучше потратить час на проектирование сегодня, чем неделю на переделку завтра.