B2B хостинг изображений 2026: чек-лист RFP из 15 пунктов
Выбор image hosting и выбор СУБД — один и тот же процесс: нельзя принимать решение по hero section на лендинге.
На работе попросили оценить альтернативный вариант. Я собрал все ошибки, на которые наступил за три года в продакшене, и свел их в чеклист. Это не документ для сравнения количества CDN-нод. Это таблица, которую вставляешь прямо в ТЗ, а вендор отвечает «Да / Нет / Частично» по каждому пункту. Снаружи все image hosting одинаковые, но архитектура под капотом отличается кардинально.
Если нужен просто бесплатный или дешевый вариант, начните с сравнения бесплатных image hosting или альтернатив Imgur. Эта статья для техлидов, ответственных за закупки SaaS, и DevOps-инженеров.
Почему B2B-выбор и персональное использование — разные вселенные
Обычный пользователь думает: «Загрузилось? Ссылка шарится?»
Компания думает иначе. Прописан ли SLA в договоре? Как деградирует rate limit при пиковой нагрузке? Не удвоится ли egress-счет в случайном месяце? Когда аудитор по 152-ФЗ спросит срок хранения EXIF-данных, будет ли что ответить?
По сути, B2B-закупка image hosting — это покупка трех вещей: предсказуемая кривая затрат, верифицируемые гарантии системы, интегрируемые протокольные интерфейсы. Все 15 пунктов ниже построены вокруг этих трех осей.
Я это понял после инцидента в проде: бесплатный тариф держит демо, но не держит реальный трафик.
Российский контекст: 152-ФЗ и локализация данных
Для российских компаний (и тех, кто обрабатывает данные российских пользователей) есть специфика, которую нельзя игнорировать:
- 152-ФЗ о персональных данных: Персональные данные граждан РФ должны храниться на территории России (или должно быть обоснование трансграничной передачи). EXIF с GPS-координатами — это персональные данные.
- Роскомнадзор: Если ваш сервис попадает в реестр ОРИ (организаторов распространения информации), требования к хранению данных ужесточаются.
- Yandex Cloud / VK Cloud: Если нужна локализация в РФ, рассмотрите этих провайдеров как альтернативу или дополнение к глобальным вендорам. Yandex Object Storage S3-совместим.
- Трансграничная передача: С 2023 года для передачи ПД за рубеж требуется уведомление Роскомнадзора.
В ТЗ явно спрашивайте: «Есть ли у вас дата-центр в РФ или возможность размещения данных в российской юрисдикции?»
Чеклист из 15 пунктов для ТЗ (копируйте в закупочный документ)
Эта таблица — рабочая версия, которую я реально использовал при оценке вендоров. У каждого пункта есть метод верификации. Спрашивать «вы поддерживаете?» бесполезно — вендор всегда ответит Да.
| # | Спецификация | Метод верификации | Критерий приемки |
|---|---|---|---|
| 1 | Совместимость API S3 | Запустить s3api list-objects-v2 --prefix |
Схема ответа идентична AWS |
| 2 | Multipart Upload | Загрузить файл 500MB, прервать и возобновить | Поддержка part retry |
| 3 | Pre-signed URL | Сгенерировать URL на 15 мин, проверить подпись | HMAC-SHA256, настраиваемый TTL |
| 4 | Webhook-события | Триггерить upload/delete | HMAC-подпись + retry |
| 5 | Политика Rate Limit | Burst-тест | Возврат 429 + Retry-After |
| 6 | Условия SLA | Прочитать MSA | >=99.9%, service credit |
| 7 | Зоны доступности | Запросить список регионов | >=2 региона, cross-region sync |
| 8 | Биллинг Egress | Запросить прайс-лист | Прозрачные цены, скидки по объему |
| 9 | Пайплайн обработки изображений | Тест on-the-fly transform | WebP/AVIF, URL-параметры |
| 10 | CDN edge-ноды | Глобальный ping-тест | >=50 PoP, включая РФ/СНГ |
| 11 | Контроль EXIF / Metadata | Загрузить фото с GPS | Выборочное удаление |
| 12 | Методы аутентификации | Документация API | OAuth2 + ротация API Key |
| 13 | Аудит-логи | Запросить retention | >=90 дней, экспорт |
| 14 | Сертификаты compliance | Запросить SOC 2 / ISO 27001 | Минимум один |
| 15 | Резидентность данных и удаление | Условия DPA | Выбор региона + hard delete |
Не ограничивайтесь галочками Да/Нет. По каждому пункту требуйте от вендора ссылку на документацию или шаги технической верификации. Что не приложено — на практике в девяти случаях из десяти «запланировано, но не реализовано».
Детали реализации ключевых спецификаций
Таблица — каркас. Ниже разбираем пункты, где вендоры чаще всего мутят воду на переговорах.
Совместимость S3 — это не одна фраза
«Мы S3-совместимы» — любимая фраза вендоров image hosting. Но в S3 API больше 200 операций, а проверять нужно именно те, которые вы будете использовать.
Базовые GetObject, PutObject есть у всех. Идем дальше:
# Тест multipart
aws s3api create-multipart-upload --bucket test --key big.mp4 \
--endpoint-url https://vendor.example.com
# Тест versioning
aws s3api put-bucket-versioning --bucket test \
--versioning-configuration Status=Enabled
# Тест lifecycle
aws s3api put-bucket-lifecycle-configuration ...
Я сам проверил — все три теста проходят меньше 60% вендоров. Особенно bucket lifecycle и object lock. Без них compliance-аудит превращается в проблему.
Pre-signed URL: TTL и алгоритм подписи
Самый распространенный метод аутентификации в B2B. У пользователя нет ваших credentials, вы выдаете ему тикет с ограниченным сроком.
Под капотом HMAC-SHA256: method, path, expiry, headers упаковываются в строку для подписи секретным ключом. Хороший вендор дает:
- Настраиваемый TTL (от 1 минуты до 7 дней)
- Привязку к IP источника (
aws:SourceIp) - Ограничение HTTP-метода
- Поддержку SigV4 (SigV2 устарел — кто еще на SigV2, отсеиваем сразу)
Плохой вендор выдаст «вечную публичную ссылку» и назовет ее signed. Вот почему pre-signed URL должен быть явно в ТЗ.
Подпись Webhook — грабли, на которые я наступил
Webhook — ядро событийной архитектуры. Загрузка завершена, вирус просканирован, транскодинг закончен — каждое событие должно пушиться.
Безопасность webhook — место, где вендоры экономят больше всего. Плохие реализации, которые я видел:
- Никакой подписи, голый POST
- Подпись есть, но secret в query string
- Подпись через MD5
- Подпись без timestamp — replay-атака в подарок
Правильный webhook:
- HMAC-SHA256 подпись в заголовке
X-Signature X-Timestamp, отклонять запросы старше 5 минут- Авто-retry при ошибке (экспоненциальный backoff, минимум 3 попытки)
- Dead letter queue или replay API
Go-код верификации webhook:
func verifyWebhook(body []byte, sig, ts, secret string) bool {
if time.Since(parseTS(ts)) > 5*time.Minute {
return false
}
mac := hmac.New(sha256.New, []byte(secret))
mac.Write([]byte(ts + "." + string(body)))
expected := hex.EncodeToString(mac.Sum(nil))
return hmac.Equal([]byte(sig), []byte(expected))
}
Уберите проверку timestamp — replay-атака ломает всю событийную систему.
Rate Limit: два уровня анализа
Rate limit оценивается на двух уровнях: какая у вас квота и что происходит при превышении.
Квота обсуждаема, обычно прописана в тарифе как per-second / per-minute. Критично поведение при превышении:
| Поведение | Оценка |
|---|---|
| 503, разрыв соединения | Неприемлемо |
| 429 без Retry-After | Частично |
| 429 + Retry-After | Приемлемо |
| 429 + Retry-After + quota header | Отлично |
Бонус: заголовок X-RateLimit-Remaining, чтобы можно было троттлить проактивно, а не получать 429 пассивно.
SLA: дьявол в exclusion clause
Все пишут 99.9%. Это 43.2 минуты простоя в месяц. 99.95% — 21.6 минут. 99.99% — 4.3 минуты.
Но реальная ценность SLA не в цифре, а в exclusion clause. Проверяйте построчно:
- Плановое обслуживание считается простоем?
- Региональные сбои считаются?
- DDoS-атаки считаются?
- Зависимости от третьих сторон (upstream DNS и т.д.) считаются?
Еще важнее: механизм service credit. Сколько вернут, если SLA не выполнен? Кредит на аккаунт или деньги? Кредит накапливается или сгорает?
Честно говоря, большинство SLA красиво написаны, но при реальной претензии exclusion clause блокирует почти все. Поэтому при закупке не смотрите только на процент: запрашивайте реальную историю инцидентов за последние 12 месяцев. Это можно получить под NDA.
Биллинг Egress — черная дыра бюджета
Egress (исходящий трафик) — главная причина перерасхода бюджета в image hosting. Любимая тактика вендоров: хранение дешевое, egress дорогой.
По данным рынка, разница в стоимости egress между крупными вендорами может достигать 10 и более раз. Cloudflare R2 дает zero egress (в своей сети), Cloudinary работает по кредитной модели, imgix берет за request. Что выгоднее — зависит от профиля трафика.
Перед закупкой уточните три вещи:
- Есть ли скидки по объему? Обычно от 10TB/мес начинаются ощутимые скидки
- Внутренний cross-region трафик считается egress?
- CDN cache hit считается egress? Некоторые вендоры включают его в тарифицируемый трафик
Я на этом обжегся: тестовая среда 200GB/мес — все нормально. После запуска в прод трафик взлетел до 8TB, в счете появился лишний ноль. До подписания контракта не уточнил поведение при overage.
Три спецификации, о которых забывают
Этих пунктов нет в типичных «сравнительных таблицах image hosting», но в реальной эксплуатации они создают боль.
EXIF и Metadata: от 152-ФЗ до Telegram-пересылок
EXIF содержит GPS-координаты, серийный номер камеры, время съемки. При загрузке на публичный image hosting все эти данные идут по умолчанию.
В B2B-контексте спрашивайте:
- Выборочное удаление EXIF (убрать GPS, сохранить copyright)?
- Поддержка операций с IPTC / XMP metadata?
- Обработка metadata при загрузке или on-the-fly?
152-ФЗ и GDPR классифицируют GPS-координаты как персональные данные. Неправильная обработка — и compliance-риск ложится на вашу компанию. В российском контексте это особенно актуально: пользователи массово шарят фото через Telegram, часто не задумываясь о метаданных.
Смешанная аутентификация: OAuth2 + API Key
Старые image hosting дают только API Key. Современный B2B требует гибридный подход:
- Система-система: API Key + IP allowlist
- Пользовательский SPA: OAuth2 PKCE flow
- Временный доступ: Pre-signed URL
Если вендор дает одну постоянную API Key и говорит «разбирайтесь со scope сами», он перекладывает security-риск на вас. Правильное решение: scoped tokens, автоматическая ротация, API отзыва.
Hard delete и хранение данных
GDPR требует исполнения «права на забвение» в течение 30 дней. 152-ФЗ также предусматривает обязанность уничтожения ПД по требованию субъекта. Многие image hosting заявляют «мы удалим», а фактически делают soft delete — объект остается в S3, в кэше CDN, на backup-лентах.
При закупке подтвердите:
- Удаление прописано в DPA?
- В цикле бэкапов есть соответствующий механизм удаления?
- Могут ли предоставить подтверждение удаления?
Реальный кейс из моей практики: клиент получил запрос на удаление по GDPR, а cold storage backup вендора хранился 365 дней без возможности модификации. Юридическая переписка длилась три месяца.
Альтернативы для российского рынка
Если требуется локализация данных в РФ, глобальные вендоры вроде Cloudinary или imgix не всегда подходят. Варианты:
- Yandex Object Storage: S3-совместимый, дата-центры в РФ, интеграция с Yandex CDN. Подходит для compliance по 152-ФЗ.
- VK Cloud (бывший Mail.ru Cloud): Object Storage + CDN, российская юрисдикция.
- Selectel: Российский провайдер с S3-совместимым хранилищем.
- Гибридная схема: Основное хранение в РФ (Yandex/VK Cloud), CDN-раздача через Cloudflare. Проверяйте, не нарушает ли это требования 152-ФЗ о трансграничной передаче.
Чеклист из 15 пунктов выше применим и к этим вендорам. Особенно проверяйте пункты 4 (webhook), 5 (rate limit) и 12 (аутентификация) — у российских провайдеров тут бывают пробелы.
Позиционирование lpic.cc
Скажу прямо: lpic.cc сейчас не enterprise B2B-решение.
Мы ориентированы на индивидуальных разработчиков, блогеров, форумное использование — бесплатная загрузка, защита паролем, хранение 30 дней. Бэкенд на облачном объектном хранилище + собственный API. В архитектуре используются некоторые спецификации из этой статьи (pre-signed URL, webhook, обработка EXIF), но enterprise SLA нет, SOC 2 нет, DPA нет.
Если вы техлид и ищете production-grade image hosting, берите этот чеклист и оценивайте Cloudinary, imgix, Cloudflare Images, ImageKit (или Yandex Object Storage, если нужна локализация в РФ). Если нужно легковесное решение для личного или командного использования — попробуйте lpic.cc: бесплатная загрузка, чтобы понять, подходит ли под ваш сценарий.
FAQ
Q1: Маленькой команде нужен enterprise image hosting?
Не обязательно. MAU до 10 000, трафик до 500GB/мес — Cloudflare R2 + Workers хватит, стоимость ниже $5/мес. Ценность enterprise-решения в SLA, compliance и поддержке. Маленькой команде это может быть не нужно. Но если вы обслуживаете B2B-клиентов и в их контракте прописаны требования DPA, выбора нет.
Q2: Совместимость с S3 действительно важна?
Очень. S3 API — де-факто стандарт. Поддержка означает: зрелые SDK, Terraform-провайдеры, инструменты бэкапа. Нет поддержки — вы залочены в проприетарном API вендора, миграция будет стоить дорого. Классический индикатор vendor lock-in.
Q3: Webhook vs polling — зачем webhook?
Polling: каждые N секунд спрашиваете «готово?». Webhook: вендор пушит по завершении. Разница в задержке (секунды vs миллисекунды) и стоимости (ваши API-вызовы vs ноль). Для событий upload complete, transcoding, virus scan без webhook real-time UX невозможен.
Q4: 99.9% SLA vs 99.99% — разница существенна?
В цифрах: 43 минуты vs 4 минуты в месяц. Реальное влияние зависит от бизнеса. Если это изображения товаров в checkout-процессе e-commerce, каждая минута — потерянная выручка. Если картинки во внутреннем справочнике сотрудников, хватит и 99%. Привязывайте требования SLA к реальному бизнес-импакту, не гонитесь за цифрой.
Q5: Cloudflare R2 с zero egress — берем не глядя?
Нет. Zero egress R2 работает только внутри сети Cloudflare (через Workers или CDN). Вытаскивать данные из другого облака — платно. Плюс Class A операции (запись) у R2 недешевые. В сценарии write-heavy/read-light может быть невыгодно. Считайте total cost по вашему соотношению read/write.
Источники
- Best S3-Compatible Storage Providers Top 5 in 2026
- S3-Compatible Object Storage What It Means for Enterprises
- Cloudflare Images Pricing Explained 2026
- Image Transform Pricing Compared
- Cloudinary vs Imgix Comparison
- How to Implement SHA256 Webhook Signature Verification
- Google Cloud CDN Signed URLs
- Webhooks Security Best Practices - Stytch
- What is an Uptime SLA Guarantee - Uptime.com
- Федеральный закон 152-ФЗ «О персональных данных»
Автор
Harvey ZhangСооснователь и технический директор
Бэкенд-инженер, ставший архитектором, предлагает глубокий технический анализ инфраструктуры хостинга изображений.