Облачные технологии — итоги
Кратко — что стоит унести из раздела "Облачные технологии". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Типичные сбои и ситуации, с которыми сталкиваются новички после раздела. Здесь — что делать и где копать в главах; определения для зачёта — в чек-листе.
Вопрос. Счёт облака вырос в несколько раз, хотя "ничего нового не запускали".
Ответ. Частые причины — забытые ВМ и диски в dev, платный egress (исходящий трафик), snapshots без политики удаления, serverless с постоянными вызовами. Откройте Cost Explorer или аналог, включите теги и бюджеты, выключите ресурсы без владельца. Подробнее здесь — глава 12, глава 1.
Вопрос. Поднял тестовую ВМ на выходных и забыл — это опасно?
Ответ. Да: ресурс крутится 24/7, пока его явно не остановят или не удалят. Для экспериментов ставьте auto-shutdown, используйте отдельный dev-аккаунт и календарное напоминание "проверить облако". Подробнее здесь — глава 1.
Вопрос. Bucket с файлами оказался доступен "всем в интернете" — как так вышло?
Ответ. Публичная политика bucket или ACL на объекты — типичная ошибка новичка. Проверьте Block Public Access, политики IAM и audit-логи; закройте доступ, ротируйте ключи, если данные чувствительные. Подробнее здесь — глава 11, глава 12.
Вопрос. Ключ доступа к облаку случайно попал в GitHub — что делать первым делом?
Ответ. Немедленно отозвать ключ в консоли провайдера, выпустить новый, проверить CloudTrail/журналы на подозрительные действия. Удаление коммита не отменяет утечку — ключ уже могли скопировать боты. Секреты храните в vault или переменных CI, не в репозитории. Подробнее здесь — глава 11, 8.03 / секреты.
Вопрос. Руководство считает, что "раз в облаке — безопасность на провайдере".
Ответ. По модели shared responsibility провайдер отвечает за гипервизор и дата-центр, а вы — за ОС, порты, ключи, данные и политики доступа. Открытый SSH и утёкший root-токен — ваша зона. Подробнее здесь — глава 11, глава 1.
Вопрос. Можно ли хранить бэкапы продакшена в том же bucket, что и рабочие файлы?
Ответ. Лучше отдельный bucket и регион, версионирование, lifecycle и правило 3-2-1. Один bucket без версий — риск случайного delete всего сразу. Подробнее здесь — глава 11.
Вопрос. Яндекс.Диск для семьи и S3 для приложения — это "одно и то же облако"?
Ответ. Нет. Синхронизация файлов — для людей; object storage — для API, статики и бэкапов с ключами объектов. Смешивать удобство личного диска и продакшен-bucket опасно для безопасности и стоимости. Подробнее здесь — глава 1, глава 12.
Вопрос. Локально всё работает, на ВМ в облаке — "Connection refused".
Ответ. Проверьте security group / firewall, слушает ли процесс нужный порт, правильный bind (0.0.0.0 vs 127.0.0.1) и маршрут из интернета. "Облако" не открывает порты само. Подробнее здесь — глава 1, 2.06 / сеть.
Вопрос. Первый pet-проект — тащить всё в IaaS или сразу PaaS?
Ответ. Для учебного API часто хватает PaaS или managed БД; IaaS даёт контроль, но требует патчить ОС и следить за firewall. Не выбирайте IaaS "из привычки", если задача — быстро выкатить HTTP-сервис. Подробнее здесь — глава 1.
Вопрос. Serverless-функция "иногда тормозит" первые секунды после простоя.
Ответ. Это cold start — платформа поднимает runtime с нуля. Для редких задач нормально; для жёсткой latency нужен provisioned concurrency, другой сервис или постоянная ВМ. Подробнее здесь — глава 1.
Вопрос. Включил "шифрование в покое" — bucket всё равно утекает. Как?
Ответ. Шифрование на диске провайдера не заменяет контроль доступа. Публичная политика или скомпрометированный ключ дают расшифровку легитимным путём. Нужны приватность bucket, IAM и MFA. Подробнее здесь — глава 11.
Вопрос. Presigned URL для скачивания "утёк" в чат — файл уже у всех?
Ответ. Пока URL действует, любой с ссылкой может скачать объект. Делайте короткий TTL, одноразовые ссылки для чувствительных данных, отзывайте через смену ключей при инциденте. Подробнее здесь — глава 12.
Вопрос. Выбрали регион "дешевле", пользователи в другой стране — сайт медленный.
Ответ. Задержка растёт с расстоянием; регион выбирают под аудиторию и закон, не только под цену. Для статики помогает CDN у края сети. Подробнее здесь — глава 12.
Вопрос. "Облако отказоустойчивое" — но после сбоя AZ приложение легло.
Ответ. Отказоустойчивость проектируют: multi-AZ, реплики БД, health checks. Одна ВМ в одной AZ — single point of failure, как один сервер в офисе. Подробнее здесь — глава 12.
Вопрос. Скачали большой дамп из bucket — счёт вырос неожиданно.
Ответ. Egress (исходящий трафик) часто тарифицируется отдельно и дороже хранения. Бэкапы в другой регион, CDN и сжатие снижают удар по бюджету. Подробнее здесь — глава 12.
Вопрос. Взломали аккаунт облака — MFA не была включена.
Ответ. Включите MFA на root и admin, уникальные пароли, отдельные роли вместо постоянных ключей root. После инцидента — аудит ресурсов, ротация ключей, contact support провайдера. Подробнее здесь — глава 11.
Вопрос. Бухгалтерия спрашивает про CapEx и OpEx — зачем это разработчику?
Ответ. Облако переводит закупку железа в ежемесячный OpEx — гибко, но без контроля счёт "ползёт". Теги, бюджеты и выключение dev-ресурсов — часть профессиональной гигиены. Подробнее здесь — глава 1, глава 12.
Вопрос. Дешёвый VPS у хостера и AWS — в чём подвох сравнения "цены за месяц"?
Ответ. Hyperscaler даёт экосистему сервисов, SLA и масштаб, но сложнее в биллинге. VPS проще для одной ВМ, но масштаб и managed-сервисы придётся собирать сами. Сравнивайте TCO, не только строку "тариф". Подробнее здесь — глава 1.
Вопрос. SaaS CRM хранит данные клиентов — это уже "наше облако"?
Ответ. Данные у провайера SaaS; вы отвечаете за договор, DPA, регион и политики доступа сотрудников. Резервное копирование и экспорт — уточняйте в SLA, не предполагайте автоматически. Подробнее здесь — глава 1.
Вопрос. Spot/preemptible ВМ внезапно выключились посреди задачи.
Ответ. Так задумано: провайдер забирает ресурс при нехватке. Spot — для прерываемых batch-задач с checkpoint, не для единственной prod-БД. Подробнее здесь — глава 12.
Вопрос. API вернул "Service limit exceeded" — ресурсы вроде есть.
Ответ. У аккаунта квоты на число ВМ, elastic IP, VPC. Запросите повышение лимита в support или освободите неиспользуемые ресурсы. Подробнее здесь — глава 1.
Вопрос. Настроил всё кликами в консоли — через месяц никто не помнит, что где.
Ответ. Ручная консоль без IaC ведёт к drift и "bus factor". Terraform или CloudFormation фиксируют желаемое состояние в Git. Подробнее здесь — 8.04 / IaC, глава 12.
Вопрос. Dev, test и prod в одном аккаунте без тегов — эксперимент снес prod.
Ответ. Разделяйте аккаунты или проекты, теги Environment=prod, IAM с наименьшими привилегиями. Один root на всё — частая история инцидентов. Подробнее здесь — глава 11.
Вопрос. Статический сайт на object storage отдаёт 403 Forbidden.
Ответ. Проверьте policy bucket, index.html, публичность только там, где нужно, или CloudFront/OSS с правильным origin. Ошибка конфигурации, не "сломанное облако". Подробнее здесь — глава 12.
Вопрос. Хотим уйти с одного облака на другое — оказалось "привязаны" к сервисам.
Ответ. Это vendor lock-in: proprietary API, managed-only функции. Снижают риск Kubernetes, стандартные форматы (S3 API, Postgres), документированный экспорт. Подробнее здесь — глава 12.
Вопрос. Мониторинг не настроен — о проблеме узнали от пользователей, а не из алертов.
Ответ. Базовые метрики, логи и алерты — ваша зона ответственности. CloudWatch и аналоги не включат сами осмысленные пороги. Подробнее здесь — глава 11, Prometheus-практикум.
Вопрос. Гибридное облако — это "половина в Azure, половина дома" без плана?
Ответ. Гибрид — осознанная схема: что остаётся on-prem (legacy, регуляторика), что в public cloud, как связаны сеть и identity. Хаотичный mix без VPN/SSO усложняет поддержку. Подробнее здесь — глава 1.
Вопрос. Что такое облачные технологии простыми словами?
Ответ. IT-ресурсы (серверы, хранилища, базы, функции) берут по сети как услугу — платите за использование, масштабируете без своего ЦОД. Подробнее здесь — глава 1.
Вопрос. Чем IaaS отличается от PaaS и SaaS — таблица для новичка?
Ответ. IaaS — аренда ВМ и сети; PaaS — платформа под код; SaaS — готовое приложение в браузере. Граница ответственности смещается к провайдеру по мере роста "SaaS-ности". Подробнее здесь — глава 1, глава 12.
Вопрос. AWS, Azure или Google Cloud — что выбрать начинающему?
Ответ. Для учёбы подойдёт любой hyperscaler с free tier и документацией; в проде смотрят экосистему, регион, договор и команду. Сравнение сервисов по категориям — в главе 12.
Вопрос. Что такое Amazon S3 и аналоги (Object Storage)?
Ответ. Объектное хранилище — файлы по ключам в bucket, доступ через API; для статики, бэкапов и медиа. Не путать с личным облаком вроде Google Drive. Подробнее здесь — глава 1, глава 12.
Вопрос. VPS или облако hyperscaler — в чём разница?
Ответ. VPS у хостера — чаще одна ВМ с фиксированным тарифом; hyperscaler — экосистема managed-сервисов, сложный биллинг и масштаб. Для одного сайта VPS проще; для микросервисов — облако. Подробнее здесь — глава 1.
Вопрос. Что такое serverless и AWS Lambda?
Ответ. Serverless (FaaS) — код запускается по событию, платформа крутит runtime, вы не админите ВМ. Lambda — пример в AWS; уместен для редких задач и webhook. Подробнее здесь — глава 1.
Вопрос. Облако или свой сервер в офисе — что выгоднее?
Ответ. Зависит от нагрузки, штата, регуляторики и TCO на 3–5 лет. Облако гибче по OpEx; свой ЦОД — контроль и CapEx. Универсального "дешевле" нет. Подробнее здесь — глава 12.
Вопрос. Что такое зона доступности (Availability Zone)?
Ответ. Изолированный дата-центр внутри региона; отказ одной AZ не должен ронять систему, если архитектура multi-AZ. Одна ВМ в одной AZ — не HA. Подробнее здесь — глава 12.
Вопрос. Shared Responsibility Model — кто за что отвечает в облаке?
Ответ. Провайдер — физика и гипервизор; клиент — данные, доступы, ОС на IaaS, конфигурация. Типичная ошибка — считать, что "облако само закроет порты". Подробнее здесь — глава 11.
Вопрос. Как сэкономить на облаке (FinOps для новичка)?
Ответ. Теги, бюджеты, выключение dev ночью, reserved instances, контроль egress, удаление неиспользуемых дисков и IP. Подробнее здесь — глава 12.
Вопрос. Что такое egress и почему "скачивание из облака" дорогое?
Ответ. Egress — исходящий трафик из региона провайдера; часто тарифицируется отдельно от хранения. Бэкапы в другой регион и CDN планируют заранее. Подробнее здесь — глава 12.
Вопрос. Бесплатный облачный сервер для учёбы — где взять?
Ответ. Free tier у AWS, GCP, Azure и российских провайдеров — с лимитами и сроком. Ставьте billing alert, выключайте ресурсы после лабораторной. Подробнее здесь — глава 1, AZ-900 / Learn.
Вопрос. Что такое виртуальная машина в облаке (EC2, Compute Engine)?
Ответ. Арендованный сервер с выбранной ОС и размером; модель IaaS. Вы патчите ОС, открываете порты, ставите приложение. Подробнее здесь — глава 1.
Вопрос. Публичное, частное и гибридное облако — определения?
Ответ. Public — ресурсы провайдера многим клиентам; private — только вашей организации; hybrid — связанная связка on-prem и public. Подробнее здесь — глава 1.
Вопрос. Что такое CDN и зачем кэшировать статику у края сети?
Ответ. CDN раздаёт копии файлов ближе к пользователю — меньше latency и egress с origin. Картинки и JS сайта — типичный кейс. Подробнее здесь — глава 12.
Вопрос. Cloud-native приложение — что это значит?
Ответ. Проектировали под контейнеры, масштабирование, managed-сервисы, а не "подняли старый монолит на одной ВМ". Связь с Kubernetes и CI/CD. Подробнее здесь — 8.06 контейнеры, глава 1.
Вопрос. AZ-900 — стоит ли сдавать сертификат Microsoft Azure?
Ответ. AZ-900 — базовая терминология облака и Azure; полезен новичку для структуры, не заменяет практику. Маршрут — Microsoft Learn, карьера IT.
Вопрос. Vendor lock-in в облаке — как избежать?
Ответ. Стандартные API, переносимые форматы, Kubernetes, документированный export; осознанный multi-cloud только где нужен. Подробнее здесь — глава 12.
Вопрос. Что такое IAM и роль в облаке?
Ответ. Identity and Access Management — кто может какие действия с ресурсами; роли вместо root-ключей, least privilege. Подробнее здесь — глава 11, 8.07.
Вопрос. Правило бэкапа 3-2-1 в облаке — как применить?
Ответ. Три копии, два носителя, одна офлайн или другой регион. Версионирование bucket и отдельный backup-account — практика, не галочка "backup enabled". Подробнее здесь — глава 11.
Вопрос. Terraform и облако — зачем Infrastructure as Code?
Ответ. Инфраструктура в Git: повторяемость, review, plan/apply вместо кликов в консоли. Старт — 8.04 Terraform. Подробнее здесь — глава 12.
Вопрос. Облако для стартапа — с чего начать развёртывание?
Ответ. Managed БД + PaaS или контейнеры, отдельные env, секреты вне кода, мониторинг с первого prod. Не тащите весь стек на IaaS "для серьёзности". Подробнее здесь — глава 1, DevOps intro.
Вопрос. MLaaS — машинное обучение в облаке что это?
Ответ. Готовые API и тренировочные кластеры (Vision, Speech, SageMaker и аналоги) без своей фермы GPU. Оплата за inference и обучение. Подробнее здесь — глава 12.
Вопрос. Zero Trust в облаке — кратко для практика?
Ответ. Не доверять "внутренней сети" по умолчанию: MFA, сегментация, проверка каждого запроса. Особенно при remote work и SaaS. Подробнее здесь — 8.07 / Zero Trust.
Что запомнить
Итоги раздела
Главная идея
Облако — это способ брать IT-ресурсы по сети как услугу — платите за использование, масштабируете быстрее, чем при закупке своего ЦОД. Это чёткое разделение: провайдер даёт платформу, вы приносите приложение и отвечаете за данные и доступ.
Три модели обслуживания
| Модель | Одной фразой |
|---|---|
| IaaS | Арендуете ВМ и сеть — ОС и приложение свои |
| PaaS | Приносите код — платформа крутит runtime |
| SaaS | Пользуетесь готовым приложением в браузере |
Подробные таблицы и схемы — в главе 1 и главе 12.
Хранилища
- Object (S3 и аналоги) — для приложений, статики, бэкапов, API.
- Синхронизация (Drive, Диск) — для людей и офиса.
- Block — диски к ВМ и БД.
Не смешивайте "личное облако" и bucket продакшена.
Ответственность и деньги
- Shared responsibility — провайдер не чинит ваши открытые порты и утёкшие ключи в Git.
- CapEx → OpEx — гибкость счёта требует тегов, бюджетов и выключения лишнего.
- Регионы и AZ — отказоустойчивость проектируется, а не "включается галочкой".
Безопасность (минимум)
MFA, уникальные пароли, приватные bucket, секреты вне репозитория, бэкап 3-2-1 — глава 11.
Три правила на каждый день
- Выбирайте модель под задачу: не тащите всё в IaaS "из привычки" и не храните секреты в SaaS без политик.
- Следите за счётом и забытыми ресурсами в dev.
- Считайте безопасность и бэкапы своей зоной, даже если "всё в облаке".
Куда идти дальше
- Чек-лист — сначала вопросы "базового уровня".
- Контейнеры 8.06 — после понимания IaaS/PaaS.
- Microsoft Learn / AZ-900 — закрепление терминологии.
Куда идти дальше
Полный маршрут — на странице о разделе.
Проверьте себя: Чек-лист самопроверки.