Как загружать файлы в S3: через бэкенд или напрямую

Чаще всего файлы загружают в S3 напрямую с фронтенда по pre-signed URL, а бэкенд только выдаёт эти временные ссылки и сохраняет метаданные. Через бэкенд гоняют файлы там, где нужны строгая валидация, антивирус и/или сложная обработка. На практике обычно используют гибрид: обычные медиа — напрямую, критичные и чувствительные данные — через бэкенд.

Есть две базовые схемы загрузки в S3: прямая загрузка с клиента по pre-signed URL и загрузка через бэкенд-прокси. Выбор зависит от баланса между производительностью и стоимостью трафика, с одной стороны, и уровнем контроля, безопасности и необходимой обработки файлов — с другой.

• Прямая загрузка с фронтенда по pre-signed URL (типично для пользовательских медиа и крупных файлов): фронтенд сначала обращается к вашему API, бэкенд по своим ключам генерирует временный pre-signed URL (или pre-signed POST) и отдаёт его клиенту. Дальше фронтенд загружает файл напрямую в S3 по этому URL, минуя сервер приложений. Плюсы: бэкенд не обрабатывает тяжёлый трафик, проще масштабирование, ниже задержки и стоимость при больших файлах или массовых загрузках. Минусы: сложнее делать синхронную серверную обработку, нужно аккуратно настроить CORS и политику доступа к бакету, а также продумать подтверждение успешной загрузки (обычно клиент после аплоада шлёт на бэкенд ключ объекта в S3).
• Загрузка через бэкенд (прокси-схема): клиент отправляет файл на сервер (обычно в формате multipart/form-data), бэкенд выполняет валидацию (размер, MIME-тип, бизнес-ограничения, антивирус), при необходимости обрабатывает файл (ресайз изображений, транскодирование, шифрование) и только потом сохраняет результат в S3 через SDK. Плюсы: максимальный контроль, централизованный аудит и логирование, возможность сложной бизнес-логики и гарантия, что в S3 попадают только проверенные данные. Минусы: весь трафик и нагрузка на CPU/память ложатся на бэкенд, что усложняет масштабирование и удорожает систему при больших объёмах или количестве параллельных загрузок.

Критичный момент безопасности: секретные ключи доступа к S3 никогда не должны уходить на фронтенд. Даже при «прямой» загрузке клиент сначала запрашивает у вашего API временный pre-signed URL, а API генерирует его по своим правам с ограничениями по времени, допустимому размеру, типу контента и пути в бакете.

Типичный сценарий прямой загрузки такой: пользователь аутентифицирован, фронтенд запрашивает у бэкенда ссылку для аплоада, бэкенд генерирует pre-signed URL и возвращает его вместе с будущим ключом объекта. Фронтенд загружает файл по этому URL (обычно методом PUT или POST), затем сообщает бэкенду ключ объекта, после чего бэкенд сохраняет метаданные в БД и при необходимости запускает асинхронную обработку (ресайз, транскодирование, индексирование и т.д.).

В итоге: для обычных пользовательских медиа и крупных файлов рационально использовать прямую загрузку по pre-signed URL, чтобы разгрузить бэкенд и снизить стоимость. Для чувствительных документов и всего, что требует строгой проверки, антивируса и сложной логики, обычно применяют загрузку через бэкенд или комбинированный подход (например, загрузка и проверка через бэкенд, а затем перекладка результата в S3).