Когда выбираете, где хранить файлы проекта, спор часто сводится к двум вариантам: «положим на диск сервера» или «вынесем в S3 object storage». На практике это не взаимозаменяемые хранилища, а два разных инструмента с разной моделью производительности, надежности и расходов. Ниже разберём сценарии и типовые ошибки: статика, бэкапы, логи, а также то, как на решение влияют latency, IOPS, throughput, presigned URL, multipart upload, lifecycle policy, versioning, egress cost и итоговый TCO.
Коротко о терминах: что именно сравниваем
S3 object storage — объектное хранилище: вы работаете с объектами (файлами) по API/HTTP, а не с «файловой системой» в привычном смысле. Обычно это огромная емкость, высокая долговечность данных и удобная автоматизация политиками, но другая модель задержек и операций.
VDS disk — блочное хранилище (виртуальный диск) внутри вашей VDS: вы монтируете файловую систему и работаете с ней локально. Обычно это низкая задержка, высокая предсказуемость для случайного I/O и полноценные POSIX-операции, но меньше встроенных механизмов ретенции и версионирования, и больше ответственности на вашей админке.
Правильный вопрос не «что быстрее», а «какая модель доступа и управления данными соответствует моему сценарию и бюджету».
S3 object storage vs VDS disk: latency, IOPS, throughput
В производительности важно разделять три метрики:
- Latency — задержка одной операции (например, открыть или прочитать небольшой фрагмент).
- IOPS — сколько операций ввода-вывода в секунду вы делаете (критично для «много мелких файлов» и случайного доступа).
- Throughput — пропускная способность: сколько МБ/с вы стабильно читаете или пишете большими блоками.
Диск VDS почти всегда выигрывает по latency и предсказуемости мелких операций: чтение маленьких файлов, частые stat(), обновления индексов, множество мелких записей — это «родная» задача локальной файловой системы.
S3 часто показывает хороший throughput на крупных объектах и параллельных потоках, но у него выше «порог входа» по задержке: HTTP, TLS, маршрутизация и внутренняя инфраструктура. Для приложения это не «диск», а удалённый сервис.
Практическое правило:
- Если у вас много случайного доступа и мелких операций — VDS-диск обычно проще и быстрее.
- Если у вас крупные объекты, потоковая отдача, хранение «впрок» и автоматизированная ретенция — S3 часто удобнее.
Если вы как раз подбираете сервер под «дисковые» нагрузки (много I/O, базы, индексы, очереди), полезно заранее прикинуть баланс CPU/RAM/диска: см. как выбрать конфигурацию VDS по CPU и RAM под реальную нагрузку.
Сценарий 1: статика и медиа (s3 static files)
Под «статикой в S3» чаще всего понимают изображения, JS/CSS, документы, архивы и пользовательские загрузки (а иногда и фрагменты видео). Здесь важно не столько «S3 быстрее/медленнее», сколько где вам выгоднее держать исходники и как организовать выдачу.
Когда S3 для статики — удачное решение
- Много неизменяемых файлов (immutable): версии ассетов с хешами в имени, редкие перезаписи.
- Нужно разгрузить сервер по диску и по отдаче файлов (особенно если веб-приложение тяжёлое).
- Нужна масштабируемость по объёму: медиа растёт — вы не расширяете диск и не переносите данные.
Но учтите: если пользователи географически далеко, а объектное хранилище в одном регионе, без CDN «время до первого байта» может быть заметно выше, чем при отдаче с ближайшего к пользователю кэша. Это не «минус S3», это физика сети и удалённого доступа.
Когда VDS-диск для статики проще и дешевле
- Файлов мало, объём небольшой, проект не растёт или растёт медленно.
- Статика активно используется приложением локально: генерация превью, частые перезаписи, временные файлы.
- Важна минимальная задержка доступа (например, SSR/рендер, где страница собирается из множества мелких ресурсов без агрессивного кеша).
Практика: гибридная схема
Часто выигрывает комбинированный подход: оригиналы и «холодные» файлы в S3, а на VDS — локальный кэш и результаты обработки (превью, оптимизированные версии). Так вы снижаете требования к диску и сохраняете быстрый доступ там, где он критичен.
Сценарий 2: бэкапы и архивы (s3 backups)
S3 как цель для бэкапов обычно «попадает в точку»: бэкап — это последовательная запись крупных объектов и редкие чтения (восстановления). Именно под такую нагрузку объектные хранилища подходят хорошо, а ещё позволяют держать копии отдельно от продовой VDS.
Почему S3 удобен для бэкапов
- Разделение рисков: бэкап не лежит на том же диске, что и прод (полезно при ошибках админа, сбоях диска, переполнении).
- Автоматизация ретенции через lifecycle policy: удалять или архивировать старые бэкапы можно без cron-скриптов на сервере.
- Версионирование (versioning) в некоторых задачах помогает пережить случайные перезаписи и удаления.
Где чаще всего ошибаются
- Хранят миллионы мелких файлов вместо архивов или чанков: и по производительности, и по учёту операций это может быть неожиданно дорого.
- Не планируют восстановление: бэкап есть, но никто не проверял скорость реального restore и доступы.
- Забывают про egress cost: чтение или выгрузка данных наружу может тарифицироваться отдельно, особенно при большом восстановлении.
RPO/RTO и политика хранения: увязываем заранее
Для бэкапов важно заранее ответить на два вопроса:
- RPO: сколько данных вы готовы потерять (час, сутки)?
- RTO: сколько времени у вас есть на восстановление?
Если RTO небольшое, «холодное» хранение с долгим разогревом может не подойти. Если RPO маленькое, придётся делать частые инкрементальные бэкапы, а значит — продумать схему именования, дедупликации и политику хранения.
Мини-чеклист по выгрузке бэкапов в S3
- Пакуйте бэкап в архив или управляемые чанки (чтобы не плодить миллионы объектов).
- Проверьте восстановление на отдельной машине: доступы, скорость скачивания, распаковку, прогон миграций.
- Настройте ретенцию: удаление старых копий, правила для старых версий (если включили versioning).
Сценарий 3: логи, аудит и ретенция (s3 logs)
Логи — особый тип данных: запись частая, чтение редкое, но когда чтение нужно (инцидент), оно становится срочным. Поэтому для «длинного хвоста» логов часто выбирают объектное хранилище: локально держим оперативный буфер, а дальше — складываем пачками и управляем ретенцией политиками.
Как обычно строят поток логов
- На VDS логи пишутся локально (быстро и без зависимости от сети).
- Затем ротируются и пачками отправляются в S3 (например, каждый час или день).
- В S3 включают lifecycle policy: хранить N дней, потом удалять или переводить в более дешёвый класс (если доступно у провайдера).
Так вы не нагружаете приложение сетевыми задержками и защищаетесь от бесконтрольного разрастания диска на сервере.
Что учесть по безопасности и доступам
Логи нередко содержат персональные данные, идентификаторы сессий и токены. Держите доступ по принципу минимальных привилегий: кто может писать, кто читать, кто удалять. Полезно разделять бакеты или префиксы по окружениям (prod/stage) и по типам логов.
Если вы рассчитываете на логи при расследовании инцидентов, заранее проверьте: кто сможет прочитать нужный фрагмент, чем именно, и за какое время.
Presigned URL: как отдавать и принимать файлы мимо приложения
Presigned URL — временная подписанная ссылка, по которой клиент может загрузить или скачать объект напрямую из S3, не получая постоянных ключей доступа. Для веб-приложений это один из самых полезных паттернов:
- разгружает бэкенд по трафику и CPU (не нужно проксировать гигабайты через приложение);
- упрощает архитектуру загрузок;
- даёт контроль по времени жизни и условиям доступа.
На что обратить внимание в эксплуатации:
- TTL ссылки: делайте минимально достаточным, особенно для чувствительных данных.
- Ограничения: где возможно, ограничивайте методы (GET/PUT) и размер.
- Кэширование: подписанные URL обычно плохо дружат с публичным кэшированием, потому что URL уникален и краткоживущий.
Multipart upload: загрузка больших файлов без боли
Multipart upload нужен, когда вы загружаете большие объекты: файл режется на части, части грузятся параллельно и независимо, а затем «склеиваются» на стороне S3. Это решает несколько проблем разом:
- устойчивость к обрывам связи (дозаливаете часть, а не весь файл);
- ускорение за счёт параллельной отправки;
- контроль времени ожидания в браузере или клиенте.
Типовая операционная задача — не забыть про уборку незавершённых мультипарт-загрузок. Практика: включать авто-очистку «aborted multipart uploads» (если провайдер поддерживает) или внедрять периодический аудит.
Versioning: когда включать, а когда лучше не надо
Versioning выглядит как «страховка от всего», но в TCO может быть неприятным сюрпризом: каждая перезапись объекта начинает накапливать историю, и объём растёт быстрее, чем ожидается.
Хорошие случаи для versioning:
- бэкапы, артефакты, конфиги, где важно иметь историю;
- редко обновляемые, но критичные объекты.
Сомнительные случаи:
- аватарки и другие файлы, которые часто перезаписываются «по одному и тому же имени»;
- кэш и миниатюры, которые легко пересоздать.
Если включили versioning — сразу проектируйте lifecycle policy на старые версии. Иначе через несколько месяцев вы платите за то, что никто никогда не восстановит.
Egress cost и TCO: почему «дешёвое хранилище» иногда выходит дорогим
В сравнении «S3 vs диск VDS» часто считают только цену за гигабайт. Но итоговый TCO складывается из нескольких частей:
- Хранение: сколько данных лежит постоянно (и сколько «теневых» данных из-за versioning).
- Операции: запросы на чтение/запись/листинг (особенно при миллионах объектов и частых листингах).
- Egress cost: исходящий трафик из хранилища наружу (восстановления бэкапов, раздача публичных файлов без кеша, выгрузки для аналитики).
- Сеть и время разработки: SDK, ретраи, идемпотентность, обработка ошибок, мониторинг.
- Администрирование: кто и как управляет доступами, ключами, аудитом и политиками.
VDS-диск обычно проще по модели расходов: платите за размер диска (и иногда за снапшоты) и не думаете об операциях API. Но рост объёма означает расширения и миграции, а отказоустойчивость вы проектируете сами.
Частые архитектурные выборы (и почему они работают)
1) База и приложение на VDS, файлы в S3
Классическая схема для веба: база данных и приложение чувствительны к задержкам и требуют локального диска, а пользовательские файлы и статика живут отдельно. Если у вас ещё не выбрана платформа под проект, начать можно с VDS, а файловую часть вынести в объектное хранилище.
2) Бэкапы и долгие логи — в S3, оперативные логи — на VDS
Оперативные логи нужны «прямо сейчас», поэтому пишутся локально. Дальше — выгрузка пачками в S3 с ретенцией через lifecycle policy. Это компромисс между скоростью, удобством и стоимостью.
3) S3 как «истина», VDS как кэш и воркеры
Если у вас есть фоновые задачи обработки (превью, архивирование, транскодирование), удобно хранить исходники в S3, а обработку делать на VDS, складывая результат обратно в S3. Тогда VDS можно горизонтально масштабировать воркерами под нагрузку.
Чеклист выбора: S3 или диск VDS
- Профиль I/O: много мелких операций или крупные объекты?
- Критичен ли latency в запросе пользователя, или можно компенсировать кешем/CDN?
- Нужны ли lifecycle policy и versioning как встроенные функции?
- Есть ли сценарии массового чтения (restore, аналитика) и как на них повлияет egress cost?
- Сколько стоит администрирование: поддерживать диски/ретенцию на VDS или управлять доступами/политиками в S3?
- План восстановления: сколько времени займёт полный restore и кто его делает?
Итоги
Сравнение S3 object storage vs VDS disk — не про «что лучше», а про правильное размещение данных. Диск VDS обычно выигрывает там, где важны низкая задержка и множество мелких операций. S3 выигрывает там, где нужны большие объёмы, длительное хранение, удобные политики ретенции и разгрузка сервера от файлов.
Самый практичный подход для большинства проектов: держать на VDS то, что чувствительно к latency и требует локальной файловой системы, а S3 использовать для статики (особенно медиа), для бэкапов и для длинного хвоста логов, обязательно учитывая egress cost и общий TCO.
