Облачные хранилища для мобильных приложений: сравнение S3, Google Cloud Storage и Azure Blob

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

Я регулярно вижу эту картину в продуктах, где объектное хранилище сначала появляется как техническая деталь, а затем становится частью пользовательского опыта. Фотографии товаров, голосовые сообщения, документы, офлайн-карты, резервные копии, медицинские изображения, медиа из чатов — для человека в приложении это просто «файл открылся» или «файл не открылся». Для команды за этим стоят Amazon S3, Google Cloud Storage или Azure Blob Storage, политика доступа, регион, CDN, жизненный цикл данных и, отдельно, стоимость каждого гигабайта, который покинул облако.

На рынке лидирует Amazon S3: в 2025 году его доля оценивается в 33%. У Azure Blob Storage — 24%, у Google Cloud Storage — 11%. Но лидерство S3 не означает автоматического ответа на вопрос, какое облако выбрать для мобильного приложения. Если продукт уже живёт на Microsoft Azure, а корпоративные пользователи проходят через Entra ID, Azure Blob часто даёт более бесшовный путь. Если аналитика, бэкенд и ML-пайплайны собраны вокруг GCP, Google Cloud Storage уменьшает число интеграционных швов. И наоборот: перенос одного бакета в «более дешёвое» облако может создать больше операционных расходов, чем сэкономить на тарифе.

Архитектурная база: данные должны быть видны сразу

В облачных хранилищах для мобильных приложений сравнение часто начинают с классов хранения и прайс-листов. Я бы начинала с другой вещи — с модели согласованности. Она определяет, что увидит пользователь после загрузки файла.

Представим обычный сценарий: приложение отправляет фотографию чека, получает подтверждение загрузки и сразу показывает превью в истории расходов. Если хранилище подтверждает запись, но следующий запрос ещё некоторое время видит старую версию объекта или не видит объект вовсе, интерфейс начинает вести себя странно. Пользователь нажал «Готово», а на экране пустое место. Он повторяет действие. В системе появляются дубликаты, в поддержке — тикеты, у команды — ложное ощущение, что проблема в мобильной сети.

У всех трёх сервисов сегодня есть строгая согласованность данных: успешная запись объекта сразу доступна для последующего чтения и листинга. Для AWS это важный исторический сдвиг: S3 получил строгую согласованность для всех операций в декабре 2020 года. Google Cloud Storage и Azure Blob Storage строились с этой моделью изначально.

На практике это снимает один из старых архитектурных компромиссов. Команде не нужно добавлять искусственные задержки после загрузки, повторно опрашивать наличие файла или объяснять в интерфейсе, что «обработка может занять несколько минут», если самой обработки нет.

Различие в терминологии кажется мелочью только в первый месяц проекта. В S3 команда обычно живёт на уровне бакетов и объектов. В Google Cloud Storage картина похожа. В Azure появляется дополнительный слой: аккаунт хранения, внутри которого находятся контейнеры, и уже в них — blob-объекты. Для разработчика это несложно, но для продуктовой команды и DevOps это влияет на границы доступа, биллинг, настройку окружений и дисциплину именования.

Я бы не пыталась искусственно выравнивать эти модели. Если компания использует Azure для идентификации сотрудников, серверных приложений и корпоративных данных, контейнерная модель Blob Storage будет восприниматься естественно. Если инфраструктура уже построена вокруг IAM-политик AWS, S3 окажется менее когнитивно тяжёлым. В выборе облачного хранилища для мобильного приложения ценность часто создаёт не отдельная функция, а количество решений, которые команде не приходится принимать заново.

Пользователь оценивает не бакет и не контейнер. Он оценивает, появился ли его файл в приложении с первого раза и без лишнего ожидания.

Безопасность мобильного клиента: не давать приложению ключи от облака

Самая опасная ошибка в мобильной интеграции — положить постоянные облачные ключи в приложение. Даже если они спрятаны в конфигурации, обфусцированы или «доступны только для чтения», это не безопасный контур. Мобильный клиент находится на устройстве пользователя, а значит, его можно исследовать, модифицировать и использовать вне задуманного сценария.

Корректная модель устроена иначе: мобильное приложение проходит аутентификацию в вашем бэкенде, бэкенд проверяет права и выдаёт короткоживущий механизм доступа к конкретному объекту или ограниченному набору операций. Затем файл загружается напрямую в хранилище. Это особенно полезно для больших видео, аудио, архивов и пользовательских фото: сервер не становится дорогим и медленным промежуточным шлюзом для каждого байта.

У трёх провайдеров логика похожая, но язык и детализация разные:

1. Amazon S3: pre-signed URLs. Сервер создаёт предварительно подписанный URL для загрузки или скачивания конкретного объекта. В ссылку уже встроены разрешённое действие и срок жизни. Для мобильного потока это очень понятная схема: приложение получает URL, отправляет файл напрямую и сообщает бэкенду о результате.

2. Google Cloud Storage: signed URLs. Механика близка к S3: временная подписанная ссылка предоставляет доступ к конкретному действию над объектом. Это удобный выбор, когда команда уже использует сервисные аккаунты и IAM-модель GCP, а файловый контур должен оставаться прямым и предсказуемым.

3. Azure Blob Storage: Shared Access Signatures, SAS. SAS-токен может давать более широкий или, наоборот, очень детально ограниченный доступ — к объекту, контейнеру или набору разрешений на заданный период. Гибкость полезна в корпоративных сценариях, но требует аккуратной политики: слишком широкий SAS для контейнера способен открыть больше, чем задумывала команда.

В UX-исследованиях я обычно отделяю безопасность от пользовательского трения, хотя в реализации они тесно связаны. Если временная ссылка живёт слишком мало, загрузка большого ролика на слабой сети оборвётся на середине. Если живёт слишком долго, растёт окно риска. Если приложение получает разрешение только на загрузку, но не на чтение, оно должно корректно обработать следующий шаг: запросить новый URL для превью или дождаться серверной обработки.

Надёжный мобильный поток обычно выглядит так:

• приложение заранее узнаёт допустимый размер, MIME-тип и назначение файла;
• бэкенд выдаёт временный доступ только к нужной операции;
• клиент показывает прогресс загрузки и умеет переживать повторную отправку;
• сервер после загрузки валидирует объект, а не доверяет одному факту успешного HTTP-ответа;
• публичная выдача, если она вообще нужна, отделяется от приватного хранения оригиналов.

Последний пункт особенно часто недооценивают. Оригинал паспорта, медицинский файл или внутренний договор не должны становиться «доступными по ссылке» только потому, что так быстрее собрать прототип. Сервис может показывать пользователю документ через короткоживущий URL, а хранить его в приватном контуре. Это немного сложнее на старте, но именно так продукт не превращает удобство в будущий инцидент.

Экономика: считать нужно не только хранение

Когда команда спрашивает про s3 vs google cloud storage vs azure blob, разговор почти всегда быстро приходит к цене гигабайта в месяц. Это понятный показатель, но для мобильного продукта он часто не главный. Медиа-сервис, маркетплейс или приложение с каталогом изображений может платить больше не за хранение, а за исходящий интернет-трафик — egress.

Для первых 10 ТБ исходящего трафика заявленная стоимость у AWS S3 составляет $0,09 за ГБ. При этом AWS предусматривает 100 ГБ бесплатного исходящего трафика в месяц. У Azure Blob Storage ориентир — $0,087 за ГБ. У Google Cloud Storage — от $0,11 до $0,12 за ГБ в зависимости от конкретной конфигурации.

Разница в долях цента на гигабайт выглядит незначительной, пока не появляется массовая раздача медиа. Возьмём условное приложение, в котором пользователи за месяц скачивают 5 ТБ изображений, документов и превью. Даже без сложных расчётов видно, что стоимость определяется не только числом файлов в бакете, но и частотой их повторной выдачи. А она зависит от продуктовых решений: автоплей видео, агрессивное обновление изображений, отсутствие кэширования, бесконечная лента, повторные скачивания после смены устройства.

Здесь я бы удержалась от соблазна объявить Azure дешевле, а Google Cloud дороже — выбор нельзя свести к одной строке тарифа. Реальный счёт меняют регион, тип хранилища, запросы, операции, резервирование, репликация, CDN и взаимный трафик между сервисами. Но сами ставки egress дают хороший сигнал: если приложение раздаёт много файлов наружу, этот показатель должен быть частью финансовой модели с первого архитектурного решения.

Полезная привычка — считать не «стоимость хранения одного терабайта», а стоимость одного активного пользователя или одного сценария. Например: сколько обходится тысяча просмотров карточек товара, один экспорт отчёта, одна загрузка видео, один пакет офлайн-карт. Тогда инфраструктурная экономика перестаёт быть абстрактной строкой у DevOps и становится предметом продуктовой работы.

В мобильном продукте самый дорогой файл — не тот, который лежит в хранилище, а тот, который приложение скачивает снова и снова без пользы для человека.

Управление жизненным циклом: данные не обязаны храниться одинаково

Почти в каждом продукте данные стареют неравномерно. Фотография профиля нужна часто. Чек, загруженный вчера, может понадобиться бухгалтеру в ближайший месяц. Лог диагностики обычно полезен несколько дней. Архивная копия документа должна остаться доступной, но к ней обращаются редко.

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

AWS предлагает S3 Intelligent-Tiering: сервис автоматически отслеживает паттерны доступа и перемещает объекты между уровнями хранения. Это полезно, когда команда не может надёжно предсказать, какие пользовательские файлы останутся активными, а какие станут архивом. Например, в сервисе для дизайнеров старый проект может месяц не открываться, а затем внезапно понадобиться на встрече с клиентом.

Google Cloud Storage использует Autoclass — инструмент, который также автоматизирует выбор класса хранения на основе активности. Для продуктов в экосистеме GCP это снижает ручную работу по созданию множества правил, хотя правила жизненного цикла всё равно остаются нужны там, где срок хранения диктует бизнес-процесс или регулирование.

В Azure Blob Storage основной инструмент — lifecycle management policies. В 2023 году Microsoft добавила Cold Tier: он рассчитан на редко используемые данные, при этом даёт мгновенный доступ. Это важное различие для сценариев, где файл должен оставаться доступен пользователю без долгого восстановления, но обращаться к нему будут нечасто: история заявлений, старые вложения в CRM, архивные результаты обследований.

Я бы разделяла здесь две задачи:

• Оптимизация по фактическому использованию. Она нужна, когда поведение пользователей трудно прогнозировать. Здесь сильны Intelligent-Tiering и Autoclass.
• Управление по бизнес-правилу. Оно нужно, когда компания заранее знает, что через 90 дней документ должен перейти в архив, а через установленный срок — быть удалён. Здесь важнее чёткие lifecycle-политики и контроль их исполнения.

Это также место, где продукт и юристы, безопасность и разработка должны говорить друг с другом до запуска функции. Нельзя честно пообещать человеку удалить данные, а затем оставить резервные копии без определённого жизненного цикла. И нельзя бесконечно хранить всё «на всякий случай»: это увеличивает и расходы, и площадь риска.

Производительность и география: миллисекунды не живут отдельно от сети

Для мобильного пользователя скорость хранилища — это не лабораторная цифра. На путь файла влияют радиосеть, качество домашнего Wi‑Fi, регион, CDN, размер объекта, повторные попытки, работа самого приложения и серверная авторизация. Поэтому я не стала бы обещать, что одно облако гарантированно даст меньшую задержку именно на телефоне в любой стране: такой вывод нельзя получить без измерений для конкретной географии и архитектуры.

Но возможности для высокопроизводительных сценариев у провайдеров различаются.

AWS предлагает S3 Express One Zone с задержкой в единицы миллисекунд. Это вариант для интенсивных задач, где важна быстрая работа с объектами, но его нужно оценивать вместе с требованиями к размещению и устойчивости данных.

Google Cloud предлагает Rapid Storage с субмиллисекундной задержкой на базе файловой системы Colossus. Такой класс ориентирован на производительные нагрузки и особенно логично рассматривается там, где остальной стек уже использует вычислительные и аналитические сервисы GCP.

Azure отвечает Premium Block Blobs для транзакционных сценариев с низкой задержкой. Это может быть уместно для приложений, которым нужна частая работа с объектами и предсказуемая производительность в контуре Azure.

Для большинства мобильных приложений более заметный эффект дают не премиальные классы, а четыре инженерных решения:

1. Регион, близкий к основной аудитории. Это сокращает сетевой путь до хранилища и бэкенда, хотя не отменяет необходимость продумать требования к локализации данных.

2. CDN перед публичной или условно-публичной раздачей. Изображения товаров, обложки, аудиопревью и другие повторно запрашиваемые объекты не должны каждый раз путешествовать из исходного хранилища до устройства без кэширования.

3. Адаптация контента под мобильный экран. Отдавать исходную фотографию на несколько мегабайт для маленького превью — это одновременно плохой UX, лишний egress и лишняя нагрузка на батарею.

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

Отдельно стоит посмотреть на георепликацию. Google Cloud Storage и Azure Blob Storage поддерживают автоматическую георепликацию в мультирегиональных конфигурациях. В Amazon S3 для межрегиональной репликации требуется вручную настроить Cross-Region Replication, CRR.

Это не недостаток S3 как такового, а другой характер решения. Ручная CRR даёт команде контроль: можно выбрать исходный и целевой регион, условия и объекты для репликации. Но этот контроль нужно спроектировать, протестировать и сопровождать. В Azure и GCP часть этой сложности снимается в мультирегиональной конфигурации, что особенно ценно для небольшой команды без выделенного специалиста по платформе.

При этом репликация не должна появляться в архитектуре только потому, что «так надёжнее». Она увеличивает объём хранимых данных, меняет стоимость и усложняет понимание того, где находится актуальная копия. Её оправдывают конкретные требования: доступность в нескольких географиях, план восстановления, требования заказчика или допустимое время простоя.

Что выбирать команде на практике

AWS S3 остаётся сильным и зрелым выбором для продукта, который уже работает в AWS, нуждается в широкой экосистеме интеграций и готов явно настраивать такие вещи, как межрегиональная репликация. S3 особенно удобен, когда в команде уже есть привычка к IAM, CloudFront, Lambda и дисциплина управления политиками доступа.

Google Cloud Storage естественно ложится в приложения, где данные дальше участвуют в аналитике, машинном обучении и сервисах GCP. Autoclass снимает часть рутины с управления классами хранения, а мультирегиональная модель может уменьшить число инфраструктурных решений на раннем этапе.

Azure Blob Storage я бы рассматривала в первую очередь для продуктов, встроенных в Microsoft-контур: корпоративные приложения, B2B-сервисы, решения с существующей идентификацией и управлением устройствами Azure. SAS даёт гибкий механизм временного доступа, а Cold Tier и lifecycle-политики хорошо закрывают сценарии с большим архивом и редкими чтениями.

Выбор облачного хранилища для мобильного приложения не должен начинаться с вопроса «кто из трёх лучший». Правильнее сформулировать его так: где живут пользователи, как часто они читают и загружают файлы, какие данные нельзя делать публичными, что уже есть в инфраструктуре компании и кто будет поддерживать эту систему через год.

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

Материалы сети: sakalekimii.com.