AWS (Amazon Web Services) — это огромный набор облачных сервисов: серверы, базы данных, хранилища, сеть и ещё пара сотен вещей. На первый взгляд это стена из аббревиатур, и легко растеряться. Но если присмотреться, почти всё стоит на четырёх опорах. Разберитесь с ними — и остальное будет встраиваться в понятную картину.

Эти четыре опоры: аккаунты (где вообще всё лежит и кто за это платит), IAM (кто и что имеет право делать), регионы и зоны доступности (где физически живут ваши ресурсы и как пережить сбой) и VPC (как устроена ваша приватная сеть). Дальше — по порядку, простыми словами.

Аккаунты: граница безопасности и денег

Аккаунт AWS — это как отдельная квартира. Всё, что вы создаёте (серверы, базы, файлы), живёт внутри одного аккаунта, и из соседнего аккаунта этого не видно. Ресурсы, права доступа и счёт за услуги — у каждого аккаунта свои.

Поначалу кажется логичным держать всё в одном аккаунте. Но как только проект растёт, компании заводят много аккаунтов и объединяют их под зонтиком AWS Organizations — например, отдельный аккаунт под боевую систему (production), отдельный под тестовую (staging), отдельный «песочницу» для экспериментов. Часто — по аккаунту на команду.

Зачем так:

  • Ограничить ущерб. Если кто-то случайно удалит ресурсы или утечёт ключ доступа, беда не выйдет за пределы одного аккаунта. Боевая система в другом аккаунте — целее.
  • Понимать счёт. Затраты видно по аккаунтам, и сразу ясно, кто сколько потратил, без расследования.

Главный практический вывод: фраза «у нас есть AWS» всегда тянет за собой вопрос «а в каком аккаунте?». А доступ из одного аккаунта в другой делается не копированием ключей, а механизмом «принять роль» (assume role) — о ролях ниже.

IAM: кто и что может делать

IAM (Identity and Access Management) отвечает на один вопрос: кто имеет право делать что и с каким ресурсом. Это система прав доступа всего AWS. В ней три ключевых понятия.

Политика (policy) — документ в формате JSON, который описывает разрешения. Читается почти как фраза: «разрешить читать объекты из такого-то хранилища».

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::orders-export/*"
    }
  ]
}

Здесь Action — что разрешаем (s3:GetObject — скачать файл), Resource — над чем (arn:... — адрес конкретного хранилища orders-export), Effect: Allow — разрешить.

Роль (role) — это набор политик, который можно «надеть» на время. У роли нет постоянного пароля или ключа: тот, кто её принимает, получает временные учётные данные на несколько часов, после чего они протухают. Это намного безопаснее вечных ключей.

Пользователь (user) — человек или система с постоянными ключами доступа. В современном AWS это почти пережиток: люди входят через единый вход (SSO), а программы работают через роли.

Два правила, которые экономят нервы и деньги.

Первое: ваш код никогда не должен носить с собой ключи доступа. Когда программа работает на сервере AWS (на виртуальной машине EC2, в контейнере ECS или в кластере Kubernetes EKS), сама платформа выдаёт ей роль — это называется instance profile для EC2, task role для контейнеров, а в Kubernetes — IRSA (роль, привязанная к ServiceAccount). Библиотека для работы с AWS (AWS SDK) находит эти временные данные автоматически, перебирая стандартные источники по очереди (этот перебор называют credentials chain). Ключи, прописанные в конфиге, в переменных сборки или, тем более, закоммиченные в git — это классический путь к утечке. Подробнее о том, как это работает в коде, — в интеграции с AWS SDK.

Второе: минимум прав (least privilege). Давайте роли ровно то, что ей нужно: сервису заказов — читать свою очередь и писать в своё хранилище, а не «разрешить вообще всё с хранилищами», чтобы «просто заработало». Выписать узкие права — это лишние десять минут. Разгребать последствия слишком широких прав — это инцидент. Подробный разбор политик и ролей — в статье про IAM.

Регионы и зоны доступности

Регион (Region) — это географическая площадка AWS: например, Франкфурт, Стокгольм, Ирландия. Каждый регион независим от других: ресурсы привязаны к региону, и данные сами собой между регионами не путешествуют — если хотите копию в другом регионе, это надо настраивать отдельно.

Зона доступности (Availability Zone, AZ) — это изолированный дата-центр (а точнее, группа дата-центров) внутри региона. У каждой зоны своё питание, своё охлаждение, своя сеть — так сделано специально, чтобы пожар или авария в одной зоне не задели соседнюю. При этом зоны одного региона связаны быстрыми каналами: задержка между ними — единицы миллисекунд.

Зачем это знать новичку:

  • Отказоустойчивость строят на нескольких зонах одного региона. Например: основная база данных в одной зоне, её реплика — в другой; копии приложения разбросаны по разным зонам; сверху — балансировщик нагрузки. Если одна зона «упадёт» (а это иногда случается), сервис продолжит работать на оставшихся.
  • Падение целого региона — большая редкость, и защита от него (репликация в другой регион) стоит дороже и настраивается отдельно. Это тема отказоустойчивости и восстановления.
  • Трафик между зонами стоит денег. Если сервисы в разных зонах болтают друг с другом без меры, это видно в счёте.

Как строить высокую доступность на нескольких зонах — подробнее в статье про масштабирование и доступность.

VPC: ваша приватная сеть

VPC (Virtual Private Cloud) — это ваша личная изолированная сеть внутри AWS, что-то вроде огороженного двора, где живут ваши серверы и базы. Вот минимальный набор понятий, которого хватит на старте.

Подсети (subnets) бывают двух видов:

  • Публичная подсеть имеет выход в интернет через Internet Gateway (интернет-шлюз). Сюда помещают то, что должно быть доступно снаружи: балансировщики нагрузки, точки входа.
  • Приватная подсеть наружу напрямую не смотрит. Если сервису из приватной подсети нужно выйти в интернет (например, скачать обновление), он идёт через NAT Gateway — устройство, которое выпускает исходящий трафик, но не пускает входящий извне.

Правило простое: серверы и базы данных живут в приватных подсетях, а в публичных стоят только балансировщики и точки входа.

Security group (группа безопасности) — это файрвол (сетевой фильтр) на уровне ресурса. Она отвечает на вопрос «кто и на какой порт может ко мне подключиться». Хороший приём: писать правила не через IP-адреса, а через ссылки на другие группы. Например, «к базе данных может подключаться только группа app» — и неважно, какие у приложения адреса. Это близко по духу к сетевым политикам в Kubernetes.

VPC endpoints (эндпоинты к сервисам AWS) позволяют дотянуться до сервисов AWS прямо из приватной подсети, не выходя в интернет и не платя за NAT-трафик. Для хранилища S3 и базы DynamoDB есть бесплатные gateway-эндпоинты; для большинства других сервисов используются interface-эндпоинты (через PrivateLink, уже за деньги). Полезно знать различие, чтобы не удивляться счёту.

Типичная ошибка новичка — поставить базу данных в публичную подсеть «чтобы удобно подключаться с ноутбука». Удобство решается иначе (через bastion-хост или AWS SSM), а публичная база — это приглашение для сканеров и переборщиков паролей. Глубже про сетевую модель — в статье про сеть в AWS.

Где это применяется

Эти четыре опоры всплывают буквально в любой работе с AWS. Создаёте сервер — выбираете аккаунт, регион и зону. Запускаете приложение — даёте ему роль вместо ключей. Поднимаете базу — кладёте её в приватную подсеть и закрываете security group. Любой следующий сервис, который вы изучите (вычисления, бессерверные функции, управляемые базы данных), стоит на этом фундаменте.

Где спотыкаются начинающие:

  • Хранят ключи доступа в коде или в git. Самая частая и самая дорогая ошибка. Используйте роли, а ключи держите только там, где без них совсем никак.
  • Раздают слишком широкие права («разрешить всё»), чтобы поскорее заработало. Потом эти права забывают сузить, и они годами висят дырой.
  • Ставят базу в публичную подсеть ради удобства — и получают сканирование извне.
  • Путают регион и зону или не понимают, почему ресурс «не виден»: часто причина в том, что он создан в другом регионе.
  • Игнорируют трафик между зонами и через NAT — а он тихо капает в счёт.

Что учить дальше. Если вы только осваиваетесь, логичный следующий шаг — глубже разобрать сеть и IAM, затем посмотреть, где запускать сервис. Когда дело дойдёт до автоматизации, не создавайте всё руками в консоли — описывайте инфраструктуру кодом: начните с основ infrastructure as code, а дальше выберите инструмент — Terraform, CloudFormation или CDK. Если ваши сервисы крутятся в Kubernetes, многое ляжет поверх этих основ напрямую: основы Kubernetes и эксплуатация кластера. А чтобы посмотреть на всё это с высоты best practices, полезен Well-Architected Framework.