Файлы — картинки, документы, бэкапы, статику сайта — в облаке не держат на диске виртуальной машины. Для этого есть объектное хранилище: отдельный сервис, который хранит сколько угодно файлов, доступен по сети и не требует своего сервера. В Azure это Blob Storage. Разберём основы; более общий разбор модели, применимый к любому объектному хранилищу, — в разделе Object storage (S3).
Контейнер, блоб, ключ
В объектном хранилище нет привычных папок и файлов. Модель другая:
- Учётная запись хранилища (storage account) — верхняя единица, к которой привязаны настройки и биллинг.
- Контейнер (container) — раздел внутри неё, куда складывают объекты.
- Блоб (blob) — сам файл вместе с метаданными; его адресует ключ — строка вида
images/2026/logo.png. Слэши выглядят как папки, но это просто часть имени: настоящей иерархии нет, пространство плоское.
Доступ — только через HTTP API, не как к диску: объект читается и пишется целиком. Именно поэтому объектное хранилище масштабируется до огромных объёмов. Для большинства задач используют блочные блобы (block blobs) — обычные файлы.
Уровни доступа
Одни данные читают постоянно, другие лежат годами «на всякий случай». Держать всё одинаково — переплачивать. Поэтому у блобов есть уровень доступа (access tier):
- Hot (горячий) — для частого доступа: дороже за хранение, дёшево читать;
- Cool (прохладный) — для редкого доступа;
- Cold (холодный) — ещё реже;
- Archive (архив) — для данных, к которым почти не обращаются: копейки за хранение, но доступ медленный (объект надо сначала «разморозить») и с доплатой.
Логика простая: горячие данные — в Hot, холодные (старые логи, бэкапы) — в дешёвых уровнях. Вручную это делать необязательно: lifecycle-правила сами переносят блобы в холодные уровни по возрасту и удаляют совсем старые.
SAS-токены и доступ
Контейнер по умолчанию приватный (доступ по RBAC или ключам). Чтобы дать временную ссылку на приватный объект — «скачать отчёт в течение часа» — используют SAS-токен (Shared Access Signature): подписанную ссылку с ограниченным сроком и правами, без раздачи постоянного доступа. Это аналог presigned URL в S3. Публичный доступ (объекты по прямой ссылке) включают осознанно — так раздают статику сайта.
Избыточность
Важное решение — сколько копий данных и где хранить:
- LRS (Locally Redundant Storage) — копии в пределах одного дата-центра; дёшево, но не переживёт аварию площадки;
- ZRS (Zone-Redundant Storage) — копии по нескольким зонам доступности региона; переживёт падение зоны;
- GRS (Geo-Redundant Storage) — плюс копия в парном регионе; защита даже от аварии региона.
Выбор — это баланс цены и того, какой сбой вы хотите пережить.
Из чего складывается стоимость
Счёт складывается из трёх частей: хранение (за гигабайты в месяц, зависит от уровня — архив в разы дешевле горячего), операции (за количество чтений/записей) и исходящий трафик (за данные наружу). Самая коварная статья — трафик: на раздаче популярной статики растёт незаметно. Помогает CDN (Azure CDN / Front Door) перед хранилищем — кэширует ближе к пользователю и снижает и задержку, и трафик.
Где это применяется
Blob Storage — стандартное место для файлового: пользовательские загрузки, картинки и видео, статика фронтенда, резервные копии, экспорты и логи. Приложение обычно не отдаёт файлы через себя, а кладёт их в контейнер и раздаёт ссылками — это разгружает сервис.
Типичные ошибки новичков:
- держат файлы на диске машины — теряют их при пересоздании и не масштабируются;
- раздают всё через приложение вместо ссылок или CDN — грузят сервис и переплачивают за трафик;
- делают контейнер публичным по ошибке — открывают приватные данные;
- не настраивают lifecycle — платят за горячий уровень даже за архив.
Что учить дальше: общая модель объектных хранилищ глубже — в разделе Object storage (S3); как читать и писать блобы из кода — в интеграции со Spring Boot; дешёвые уровни и трафик — часть оптимизации затрат.