Мультиаккаунтная архитектура AWS: SCP, SSO и централизованный биллинг

Почему один аккаунт AWS ломает управление

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

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

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

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

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

Что даёт мультиаккаунтная архитектура AWS

Скорость выдачи аккаунта

Новый аккаунт в AWS Organizations создаётся через централизованный шаблон: базовая сеть, роли доступа, политики и привязка к биллингу разворачиваются автоматически. Вместо дней переписки и ручной настройки команда получает готовую среду за минуты — и сразу с нужными ограничениями.

Радиус поражения инцидента

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

Прозрачность расходов

Централизованный биллинг собирает счета всех аккаунтов в один отчёт с разбивкой по командам, проектам и средам. Видно, какое подразделение сколько потребляет, — и решения о бюджете принимаются по фактам, а не по догадкам.

Единые политики

Service Control Policies задают правила на уровне организации: какие сервисы и регионы доступны, что запрещено. Политика применяется ко всем аккаунтам сразу, поэтому новый проект не может случайно обойти требования безопасности или комплаенса.

Управляемость

Единая точка входа через SSO, централизованный аудит действий и общий каталог аккаунтов. Администратор видит всю картину и управляет доступом из одного места, а не собирает данные по разрозненным учётным записям.

SCP, SSO и централизованный биллинг: сравнение подходов

Единый аккаунт удобен ровно до момента, когда в нём появляются вторая команда и второй продукт: права у всех максимальные, бюджеты смешаны, а инцидент в одном сервисе роняет соседний. Дальше выбор идёт не между «сложно и просто», а между четырьмя рабочими схемами управления — и у каждой есть своя цена в виде ограничений.

AWS Organizations здесь — не самоцель, а рамка: он задаёт дерево подразделений, на которое навешиваются политики и роли. Ниже — сравнение по тому, что реально влияет на эксплуатацию: изоляция отказов, управляемость доступов и предсказуемость счетов.

Практика показывает: SCP и SSO решают разные задачи и не заменяют друг друга. Политика запрещает нежелательные действия — например, вывод данных за пределы подразделения или запуск ресурсов вне разрешённых регионов. Федерация отвечает за то, кто и на какую роль входит, и убирает ручные ключи доступа. Централизованный биллинг поверх Organizations даёт разделение расходов по подразделениям и тегам — без него счёт остаётся общей суммой, которую никто не может разложить по командам.

Гибрид с внешним каталогом берут там, где вход и увольнение должны отражаться в доступах автоматически. Цена — синхронизация каталога и ролей становится отдельным сервисом, за которым нужно следить.

Как мы внедряем AWS Organizations: этапы работ

Внедрение AWS Organizations — это не «включить консолидацию счетов», а перестроить управление доступом и политиками поверх уже работающих аккаунтов. Поэтому начинаем с инвентаризации: какие аккаунты существуют, кто в них ходит, какие сервисы и данные живут, где пересекаются сети и роли. Без этой карты любой перенос OU или включение SCP ломает прод.

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

1. Аудит ландшафта. Собираем список аккаунтов, владельцев, критичных сервисов, текущих IAM-ролей и сетевых связей. Фиксируем, что нельзя трогать без окна обслуживания.
2. Проектирование OU. Раскладываем аккаунты по организационным юнитам: прод, стейджинг, песочница, безопасность, инфраструктура. Отдельно — изолированные OU для регуляторных или платёжных данных.
3. Настройка SCP. Пишем политики на уровне OU, а не отдельных аккаунтов: запрет выхода из организации, ограничение регионов, блокировка отключения логирования. Сначала в режиме аудита, потом — в enforcement.
4. Подключение SSO. Настраиваем единый вход и маппинг групп на роли в аккаунтах, чтобы доступ выдавался через каталог, а не через локальные IAM-пользователи. Это снимает ручное управление доступами.
5. Миграция аккаунтов. Переносим по одному: привязка к OU, применение SCP, проверка рабочих процессов команды. Откат возможен на каждом шаге, пока аккаунт не закреплён в целевой структуре.
6. Проверка. Прогоняем сценарии: доступ разработчика, деплой, реакция на запрещённое действие, работа биллинга и тегов. Смотрим, что политики не блокируют легитимные операции.
7. Передача. Отдаём карту OU, набор SCP, схему ролей и регламент добавления новых аккаунтов — чтобы команда расширяла структуру без нас.

Опишите текущий ландшафт — вернёмся с оценкой и планом по этапам.

Политики доступа и IAM-роли в мультиаккаунтной среде

В мультиаккаунтной среде доступ описывается не разовыми настройками, а набором артефактов, которые живут в репозитории и проходят ревью как код. Ниже — что заказчик получает на руки после внедрения: каждый пункт можно передать внутренней команде или подрядчику на сопровождение без устных пояснений.

• SCP-конфигурации — политики на уровне Organizations: запрет выхода из организации, блокировка неразрешённых регионов, защита от отключения аудита и удаления журналов, ограничения на создание публичных ресурсов. Каждое правило привязано к конкретной OU, а не ко всему дереву.
• Схемы OU — иерархия подразделений с назначением: sandbox, рабочие среды, продакшн, изолированный контур, инфраструктурный аккаунт. Схема фиксирует, куда попадает новый аккаунт и какие политики наследует по умолчанию.
• Политики доступа — роли и политики для людей и сервисов: разделение прав по принципу минимально необходимых, отдельные роли для чтения, развёртывания и администрирования, условия на источник запроса и обязательную многофакторную аутентификацию.
• IAM-роли и федерация — вход через единый провайдер идентификации, временные учётные данные вместо долгоживущих ключей, роли для автоматизации с ограниченным сроком действия и привязкой к конкретному аккаунту.
• Регламенты — порядок запроса доступа, сроки пересмотра прав, процедура вывода аккаунта из организации, правила реагирования на срабатывание запрета.
• Документация — карта аккаунтов и OU, схема ролей, матрица «кто что может», инструкции для дежурной смены и для аудита.

Отдельно передаём схему отката: как снять политику, если она блокирует рабочий процесс, и в каком порядке это делать, чтобы не потерять доступ к управляющему аккаунту. Опишите вашу текущую структуру аккаунтов — вернёмся с оценкой и планом внедрения.

Кейс: как сократили радиус инцидента и время выдачи аккаунта

Заказчик пришёл с классической болью: аккаунты под команды и среды выдавались вручную, у каждого — свой root-доступ и свои ключи, а биллинг растекался по десятку счетов. Инцидент с утёкшим ключом в одном сервисе затрагивал общие ресурсы, и понять границу поражения можно было только перебором. Разбирали на базе AWS Organizations — централизованное управление деревом аккаунтов, политики и единый вход.

Что было до

Выдача нового аккаунта под команду занимала в среднем 3 рабочих дня: заявка, ручное создание, рассылка доступов, отдельная настройка биллинга. Доля ручных операций в провижининге держалась около 80% — каждая ошибка в правах всплывала уже в проде. Радиус инцидента при компрометации ключа охватывал 6-8 аккаунтов из-за общих ролей и сквозных доступов, а на локализацию уходило до 4 часов.

Что изменили

• Аккаунты разнесли по организационным единицам (prod, staging, sandbox, shared) с наследованием SCP — запрет на отключение логирования, ограничение регионов, блок root-операций.
• Доступ перевели на федерацию через единый вход: человек получает роль в конкретном аккаунте на время, постоянных ключей нет.
• Биллинг свёл в управляющий аккаунт с разметкой по командам — расходы видно по подразделению, а не по счёту целиком.
• Выдачу аккаунта завернули в шаблон: организационная единица, SCP, базовые роли и бюджет-алерт поднимаются одной операцией.

Что стало

Выдача аккаунта сократилась с 3 дней до 15-20 минут, доля ручных операций упала примерно до 10% — остались только согласования. Радиус инцидента сузился до одного аккаунта: компрометация ключа больше не даёт доступа к соседним средам, а время локализации упало с 4 часов до 20-30 минут за счёт изоляции и централизованного аудита.

Отдельный эффект — предсказуемость расходов: разметка по командам показала, какие среды тянут бюджет впустую, и часть sandbox-ресурсов свернули без потери для разработки.

Чем SCP отличается от IAM-политик и когда что применять

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

Ключевое свойство SCP — она работает как фильтр, а не как источник разрешений. Даже если IAM-политика разрешает действие, но SCP его не допускает, действие не пройдёт. Обратное неверно: SCP не даёт прав сама по себе — без разрешающей IAM-политики доступ всё равно закрыт. Поэтому SCP применяют для жёстких организационных границ: запрет выхода за разрешённые регионы, блокировка отключения журналирования и защиты, запрет создания публичных хранилищ, ограничение используемых сервисов. Это рамка, которую нельзя обойти правами внутри аккаунта.

IAM-политики решают другую задачу — тонкую настройку доступа. Здесь описывают, кто и к каким ресурсам обращается, при каких условиях, с какими тегами и через какие роли. Именно на этом уровне живёт повседневная работа: доступ разработчиков к нужным сервисам, права сервисных ролей, ограничения по источнику запроса. Меняется команда или процесс — меняется IAM-политика, и это не затрагивает остальные аккаунты организации.

Практическое правило применения простое. Границы, которые должны действовать для всех аккаунтов и не зависят от текущих задач, выносите в SCP — они наследуются и централизованно управляются. Всё, что касается конкретных людей, ролей и ресурсов внутри одного аккаунта, оставляйте в IAM. Смешение уровней приводит к двум крайностям: либо SCP пытаются использовать как раздачу прав и получают неработающий доступ, либо в IAM дублируют организационные запреты, которые потом расходятся между аккаунтами.

Отдельно стоит учитывать порядок внедрения. SCP применяется к аккаунту целиком, включая корневого пользователя и служебные роли, поэтому неверно составленное правило способно заблокировать управление. Безопаснее вводить ограничения поэтапно: сначала на тестовном подразделении, затем раскатывать на остальные, проверяя, что штатные сценарии не задеты. IAM-политики такой опасности не несут — их область ограничена аккаунтом, и ошибка не выходит за его пределы.

Частые технические сомнения при переходе на AWS Organizations

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

Как не сломать прод при включении политик?

SCP применяются поэтапно: сначала на тестовом OU, где прогоняются реальные сценарии деплоя и отката, затем на непроде, и только потом на проде. Политики пишутся так, чтобы запрещать конкретные опасные действия, а не «всё, кроме разрешённого» — иначе один пропущенный сервис роняет рабочий процесс. На каждом шаге остаётся точка отката: политику можно снять с OU, и аккаунты возвращаются к прежнему поведению без пересоздания ресурсов.

Пользователи заходят через внешний каталог — SSO это сломает?

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

Можно ли откатиться, если что-то пойдёт не так?

Да. Перенос обратим на каждом этапе: аккаунт можно вывести из организации, SCP — снять, а доступ вернуть к прежней схеме. Мы фиксируем состояние до изменений и держим план отката, поэтому переход идёт без простоя прода и без потери данных.

Обсудим вашу задачу по мультиаккаунтной архитектуре

Чтобы оценка была точной, а не «плюс-минус порядок», нам нужно понять текущий ландшафт: сколько аккаунтов уже живёт под AWS Organizations, есть ли Control Tower, как устроены SSO и роли, где сейчас лежат данные и какие требования по изоляции сред. Опишите задачу в свободной форме — дальше мы зададим уточняющие вопросы и вернёмся с оценкой и планом работ.

Что полезно приложить к описанию:

• список аккаунтов и их назначение (прод, стейдж, песочницы, общие сервисы, безопасность);
• текущая структура подразделений и как она должна маппиться на организационные единицы;
• как сегодня выдаются доступы: через какой провайдер идентификации, какие роли и группы используются;
• какие политики уже применяются и что мешает — где ручные исключения, где правила обходятся;
• требования к изоляции: что и кому должно быть видно, какие данные нельзя смешивать между аккаунтами;
• как сейчас собирается биллинг и по каким признакам расходы раскладываются по командам и проектам;
• ограничения: сроки, регламенты, уже принятые архитектурные решения, которые нельзя ломать.

В ответ вы получите оценку трудозатрат с разбивкой по этапам, план внедрения с порядком работ и точками отката, схему целевой структуры аккаунтов и политик, а также список рисков и зависимостей, которые нужно закрыть до старта. Если часть данных пока недоступна — не страшно, начнём с того, что есть, и уточним по ходу разбора.

Опишите задачу — вернёмся с оценкой и планом.