Что такое AWS на самом деле

AWS — это коммунальная услуга, а не продукт

Понятнее всего AWS осмыслить по аналогии с электросетью. Ты не держишь генератор в подвале; ты берёшь питание из общей сети, платишь за потреблённое, а сеть отвечает за генерацию, распределение и надёжность. AWS — Amazon Web Services, запущенный в 2006 году, — это такая же коммунальная услуга, только для вычислений. Вместо покупки серверов, монтажа их в стойку, разводки сети и замены сдохших дисков в три ночи ты арендуешь эти возможности через API и платишь только за то, что используешь.

Фраза «через API» — это и есть весь сдвиг. Каждый ресурс в AWS — виртуальный сервер, терабайт хранилища, база данных, DNS-запись, правило фаервола — создаётся, меняется и уничтожается программным вызовом. Веб-консоль, по которой ты кликаешь, — лишь фронтенд над тем же API, что используют SDK и Terraform. Поэтому инфраструктура становится кодом, поэтому скрипт способен поднять целое окружение за минуты, и поэтому та же эластичность, что спасла стартап во вступлении, при небрежности так же быстро поднимет тысячу инстансов и пятизначный счёт.

Сегодня AWS — это не один сервис, а более 200 из них, доступных по запросу с оплатой по факту, работающих в 190+ странах. Все 200 никто не учит. Навык не в том, чтобы заучить сервисы, — он в том, чтобы знать категории, чтобы, столкнувшись с задачей, понимать, на какую полку смотреть.

Ментальная модель: категории сервисов

Воспринимай AWS как строительный магазин, разложенный по отделам. Тебе не нужно знать каждый товар; нужно знать, для чего каждый отдел. Шесть категорий покрывают подавляющую часть того, что использует рабочее приложение:

Типичное веб-приложение задействует по одному сервису из большинства этих отделов: код на EC2 или Lambda, файлы в S3, данные в RDS, трафик через VPC за ELB с Route 53 на входе, доступ под управлением IAM, и всё это под наблюдением CloudWatch. Сначала выучи отделы; конкретные названия товаров прицепятся сами, как только ты поймёшь, какую задачу они решают.

Managed vs self-managed: ось, определяющая AWS

Самое важное различие во всей платформе — сколько операционной работы AWS делает за тебя. Одна и та же возможность — скажем, база Postgres — доступна в нескольких точках вдоль спектра, и выбор тут — реальный трейдофф, а не дефолт.

На self-managed-конце ты запускаешь EC2 (голую виртуальную машину), сам ставишь Postgres и владеешь всем выше гипервизора: патчи ОС, апгрейды Postgres, бэкапы, репликация, фейловер, мониторинг. Ты получаешь полный контроль и самую низкую цену за час — и наследуешь все ночные пейджи в три часа. На managed-конце ты используешь RDS: AWS запускает движок базы, накатывает патчи, делает автоматические бэкапы и может автоматически переключиться на резервный экземпляр в другой зоне доступности. Ты платишь за час дороже и отдаёшь часть рычагов, но перестаёшь владеть операционной рутиной. Ещё дальше — serverless-сервисы вроде Lambda и DynamoDB, где вообще нет инстанса, который надо сайзить: тебя тарифицируют за запрос и за миллисекунду, а мощность — целиком забота провайдера.

Эта ось managed vs self-managed — линза почти для любого решения в AWS. «Брать RDS или поднять Postgres на EC2?» на самом деле значит «стоит ли операционная работа надбавки для этой нагрузки?». Для большинства команд большую часть времени ответ — купить управляемую версию и потратить сэкономленные часы на продукт, но это именно решение, и сеньоры принимают его осознанно.

Глобальная инфраструктура — в одном абзаце

AWS работает в физических локациях, называемых регионами (их 39+ по миру, например us-east-1, eu-west-1), каждый из которых — независимая географическая область. Внутри каждого региона несколько зон доступности (AZ, Availability Zone — физически изолированная площадка внутри одного региона) — всего 120+ — это физически разделённые группы дата-центров с независимым питанием и охлаждением, но связанные низколатентными каналами, так что распределение приложения по AZ переживает отказ одного дата-центра. На границе сети — сотни edge-локаций (points of presence у CloudFront), которые кэшируют контент ближе к пользователям ради низкой задержки. Всё это ты углубишь в следующем уроке; пока держи в голове иерархию регион → зона доступности → edge и правило, что высокая доступность в AWS означает работу как минимум в двух AZ.

Почему команды выбирают AWS — и чего это стоит

Команды выбирают AWS прежде всего по двум причинам. Широта: 200+ сервисов означают, что почти всегда можно собрать нужное, не изобретая его, — от очереди до управляемого кластера Kubernetes и эндпоинта машинного обучения. Эластичность: ты масштабируешься вверх за секунды под всплеск трафика и вниз, когда он спадает, платя только за использованное — ровно то свойство, что спасло стартап во вступлении. Добавь зрелость платформы и глубокий рынок найма — и AWS становится безопасным институциональным дефолтом.

Минусы столь же реальны, и их стоит назвать так, как назвал бы сеньор. Сложность стоимости: оплата по факту — палка о двух концах; ценообразование охватывает часы compute, ГБ-месяцы хранилища, число запросов и исходящий трафик (egress), который удивляет команды сильнее всего; забытый простаивающий ресурс или болтливый межрегиональный вызов тихо съедают деньги. Lock-in: чем сильнее ты опираешься на проприетарные управляемые сервисы (DynamoDB, Lambda, SQS), тем труднее и дороже уйти — удобство и lock-in — это одна и та же фича. Операционная поверхность: AWS даёт тебе огромную мощь и огромное число способов её мисконфигурировать; один только IAM — это глубокая дисциплина, и единственная слишком широкая политика или публичный бакет — это утечка. Ничто из этого не повод не использовать AWS; это вещи, которыми ты управляешь осознанно, потому что выбрал его использовать.