Основы AWS: аккаунты, IAM, регионы и VPC

Java · Go · Node · Python

Знакомство с AWS для начинающих: что такое аккаунт, как IAM решает кто что может, зачем регионы и зоны доступности и как устроена сеть VPC — простыми словами и с примерами.

Опубликовано 6 июня 2026 обновлено 5 октября 2026 ~14 мин чтения

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

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

Четыре опоры, на которых стоит остальное: аккаунт отвечает «где и за чей счёт», IAM «кому что можно», регион и зоны «где физически и как пережить сбой», VPC «кто до кого дотянется по сети».

Обязательно

Как вообще попасть в аккаунт

Прежде чем что-то создавать, надо войти, и здесь у AWS есть две принципиально разные двери.

Root-пользователь — та учётная запись, на которую регистрировали аккаунт (email плюс пароль). Она может всё и её нельзя ограничить никакой политикой: это владелец квартиры с универсальным ключом. Поэтому первое, что делают в новом аккаунте, — три вещи:

Включают на root второй фактор (MFA). Без этого один подобранный пароль означает потерю аккаунта.
Удаляют у root ключи доступа, если они есть. Программе root-доступ не нужен никогда.
Заводят обычного администратора и дальше работают под ним.

После этого root открывают редко: сменить платёжные данные, закрыть аккаунт, изменить план поддержки — список короткий и лежит в документации.

Обычный вход для людей — это либо пользователь IAM с паролем, либо, что правильнее, IAM Identity Center (прежнее имя — AWS SSO). Это отдельный сервис: он один раз подключается к вашему каталогу сотрудников (собственный каталог Identity Center, Active Directory или внешний провайдер входа), и дальше человек входит один раз и попадает в портал, где перечислены доступные ему аккаунты и роли в них.

Связь с Organizations здесь прямая и её стоит понять: Identity Center включается на уровне организации и раздаёт доступ сразу во все аккаунты организации. То есть схема выглядит так: организация содержит аккаунты, Identity Center содержит людей и наборы прав, а назначение связывает «этот человек — в этом аккаунте — с такими правами». Один сотрудник, десять аккаунтов, один вход и разные права в каждом.

Что это меняет на практике: у людей перестают существовать долгоживущие ключи доступа. Вход даёт временные учётные данные на несколько часов, в том числе для командной строки (aws sso login), и утечка ключа перестаёт быть катастрофой, потому что ключа нет. Именно поэтому в современных руководствах пользователей IAM для людей уже не создают — только для редких служебных случаев, которые нельзя закрыть ролью.

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

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

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

Зачем так:

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

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

Что именно не пересекает границу аккаунта

Раз аккаунт — граница, полезно знать, что через неё не проходит, а что, наоборот, общее для всех аккаунтов сразу.

Не проходит. Сеть: VPC принадлежит аккаунту, и ресурсы из другого аккаунта в неё не попадут просто так (для этого есть отдельные механизмы — общий доступ к подсетям или соединение сетей). Права: роли и политики IAM живут внутри своего аккаунта, «пользователь из соседнего аккаунта» в правилах не появляется без явного доверия. Квоты: почти все ограничения (сколько машин, сколько адресов, сколько функций) считаются на аккаунт и на регион, и это приятная сторона разделения — сосед не съест ваш лимит. Счёт: платит каждый аккаунт за себя, хотя в организации счета обычно сводятся в один платёж.

Общее для всех. Имена бакетов в хранилище объектов уникальны глобально: если имя orders-prod занял кто-то в другом аккаунте на другом континенте, вам оно недоступно. Сам IAM глобален внутри аккаунта — роль не привязана к региону (об этом ниже). И несколько сервисов по своей природе не имеют региона: управление доменами, сеть доставки контента, сертификаты для неё.

Отсюда практическое следствие для имён: к имени бакета сразу добавляют что-то своё — название компании и аккаунта (acme-orders-prod-eu-central-1), иначе половина осмысленных имён окажется занята. И обратное следствие для отладки: «ресурс не создаётся, имя занято» в хранилище объектов не означает, что он у вас есть, — возможно, его занял чужой аккаунт.

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), сама платформа выдаёт ей роль, а библиотека для работы с AWS (AWS SDK) находит временные ключи этой роли автоматически. Ключи, прописанные в конфиге, в переменных сборки или, тем более, закоммиченные в git — это классический путь к утечке. Подробнее о том, как это работает в коде, — в интеграции с AWS SDK.

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

IAM глобален

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

IAM в этот список не входит: он глобален. Роль, политика, пользователь, поставщик входа — все они существуют в аккаунте целиком и видны из любого региона. Отсюда две практические вещи. Роль, созданную «в Ирландии», не надо создавать заново «во Франкфурте» — она уже там. И наоборот: удаление роли затрагивает все регионы сразу, поэтому «уберу, тут же ничего не работает» — плохая идея.

Кроме IAM, региона не имеют ещё несколько сервисов: управление доменными именами, сеть доставки контента, а также записи о партнёрах и организации. Всё остальное, что вы будете создавать, региональное — и первый вопрос при «ресурс не виден» всегда один: а в том ли регионе вы смотрите.

Регионы и зоны доступностиспросят на собеседовании

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

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

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

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

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

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

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

Подсети (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.
Well-Architected Framework — взгляд на всё это с точки зрения проверенных практик.

Дополнительно: при первом чтении можно пропустить

Глубже: как выбирают регионрасширенное

Регион — это не «поближе к дому», а решение по четырём признакам, и принимают его один раз, потому что переезд ресурсов между регионами — это отдельный проект.

Близость к пользователям. Каждая тысяча километров — это примерно 10 миллисекунд в одну сторону, то есть 20 на обращение. Для сервиса, где страница собирает десяток запросов к бэкенду, разница между «регион рядом» и «регион на другом континенте» — это секунды, которые пользователь чувствует.

Требования к хранению данных. Если по закону или по договору персональные данные обязаны лежать в определённой стране, выбор сводится к одному-двум регионам, и остальные признаки не обсуждаются. Это первый вопрос, который стоит задать, а не последний.

Цена. Одинаковая машина в разных регионах стоит по-разному, и разброс доходит до десятков процентов; самый дешёвый обычно север Вирджинии. На заметную сумму это влияет только на больших объёмах, но знать про разницу стоит.

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

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

Глубже: что тихо капает в счётрасширенное

«Затраты видно по аккаунтам» — правда, но новичка удивляет не размер счёта, а его состав: платить приходится за то, о чём он не думал как об услуге. Три позиции, которые появляются в счёте почти у всех.

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

Лечится это двумя способами. Обращения к хранилищу объектов и к DynamoDB заворачивают через бесплатную точку доступа внутри сети (gateway endpoint) — тогда трафик к ним вообще не идёт через шлюз. Для остальных сервисов есть точки доступа второго вида (interface endpoint), но они платные — почасово за каждую зону плюс за трафик, — поэтому их считают, а не включают все подряд.

Трафик между зонами доступности. Запрос из зоны A в зону B тарифицируется, причём в обе стороны: примерно по центу за гигабайт с каждой стороны. Обычно это мелочь, но бывает и заметно: приложение в одной зоне, база в другой, между ними сотни гигабайт в сутки — и в счёте появляется строка, которой никто не заказывал. Отсюда практика «держать общающиеся компоненты в одной зоне, а дублирование делать между зонами».

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

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

Коротко

Root защищают вторым фактором и лишают ключей доступа; работают под обычным администратором, а людям дают вход через IAM Identity Center с временными учётными данными.
Аккаунт это граница ресурсов, прав и счёта: боевую среду, тестовую и песочницу разносят по аккаунтам под AWS Organizations, а между аккаунтами ходят принятием роли, не ключами.
Имена бакетов глобальны, IAM глобален внутри аккаунта, всё остальное живёт в регионе: «ресурс не виден» почти всегда значит «не тот регион».
Коду не дают ключей: платформа выдаёт роль, SDK берёт временные учётные данные сам; права выписывают по минимуму.
Отказоустойчивость строят на нескольких зонах одного региона; регион выбирают по близости к пользователям, требованиям к данным, цене и наличию сервисов, и всё, что работает вместе, держат в одном регионе.
База и сервисы живут в приватных подсетях, снаружи доступен только балансировщик; правила security group пишут ссылками на другие группы, а не адресами.
В счёт тихо капают NAT-шлюз, трафик между зонами и забытые ресурсы: отчёт по затратам, оповещение по бюджету и метки на ресурсах ставят на первой неделе.

Что почитать дальше

Сеть в AWS — подсети, маршруты, NAT и security groups по шагам.
IAM в AWS — роли, политики и разбор отказов в доступе.
Где запускать сервис — машины, контейнеры или функции.
Основы инфраструктуры как кода — чтобы не создавать всё руками в консоли.