Amazon SAP-C02: Организационная сложность и стратегия использования нескольких аккаунтов — Руководство по подготовке

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Часть AWS Solutions Architect Professional SAP-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

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

Мультиаккаунтная стратегия начинается с четкого разделения обязанностей: безопасность и аудит, общие сетевые ресурсы, производственные нагрузки и песочницы или аккаунты разработчиков. Использование AWS Organizations вместе с AWS Control Tower или кастомной landing zone обеспечивает это разделение с первого дня. Account Factory в Control Tower предоставляет паттерн вендинга аккаунтов, который автоматизирует их создание, базовые роли IAM, шаблоны VPC и защитные ограждения, в то время как кастомная landing zone, созданная с помощью CloudFormation/CDK и Service Catalog, предлагает больше гибкости для индивидуальной настройки сетей и управления. Основной компромисс заключается в выборе между операционной нагрузкой и уменьшением радиуса поражения: большее количество аккаунтов увеличивает поверхность управления (автоматизация, межаккаунтные роли, видимость биллинга), но ограничивает последствия компрометации домена и упрощает соблюдение требований для каждого отдельного аккаунта. Выбор сетевой архитектуры — совместное использование VPC с помощью AWS Resource Access Manager, топология hub-and-spoke с Transit Gateway или изолированные VPC с VPC peering — определяет компромиссы между стоимостью и задержками. Общие сервисы (DNS, NAT, Active Directory) часто размещаются в аккаунте для сетевых или общих служб; вендинг аккаунтов должен автоматически подключать новые аккаунты к этим общим ресурсам или предоставлять делегированные VPC. Планируйте квоты и автоматизацию: централизуйте конвейеры для базовых артефактов, чтобы масштабирование количества аккаунтов не приводило к увеличению ручного труда.

Управление: SCP, защитные ограждения Control Tower и организационные политики

Управление в мультиаккаунтной среде AWS зависит от применения политик на уровне организации и делегированных элементов управления во время выполнения. Политики управления сервисами (SCP) устанавливают верхний предел для разрешенных действий во всех аккаунтах; они мощные, но не прощают ошибок — правила deny на уровне корневого OU не позволяют даже администраторам создавать связанные с сервисами роли или использовать сервисы, если это не разрешено явно. Control Tower предлагает готовые защитные ограждения (обязательные, настоятельно рекомендуемые, опциональные), которые реализуют распространенные SCP и правила Config, но он может быть слишком ограничивающим для сложных сценариев использования сервисов. Проектное решение сводится к выбору между централизованным и делегированным управлением: строгий список запретов (deny-list) на корневом уровне максимизирует соответствие требованиям, но создает трудности для продуктовых команд и автоматизации, в то время как разрешающие базовые настройки с границами разрешений и контролем ролей IAM обеспечивают более высокую скорость разработки. Политики логирования и аудита (CloudTrail на уровне организации, агрегатор AWS Config, делегированные администраторы Security Hub и GuardDuty) должны применяться из управляющего аккаунта для обеспечения неизменяемых журналов аудита. Прагматичный подход — это многоуровневое управление: SCP на уровне организации для ограничений с высоким уровнем воздействия, границы разрешений для определения полномочий разработчиков и автоматизированные защитные ограждения, применяемые через CI/CD в landing zone для поддержания согласованности без ручного контроля.

Границы безопасности: межаккаунтные роли, KMS и ресурсные политики

Межаккаунтный доступ — это ключевой паттерн, который должен реализовываться с соблюдением принципа наименьших привилегий и строгими механизмами доверия. Распространенный паттерн делегирует доступ через роли IAM в каждом аккаунте, которые доверенные субъекты принимают с помощью STS: роли для развертывания через CI/CD, мониторинга (CloudWatch/SSM) и интеграций со сторонними системами должны требовать MFA, где это уместно, и использовать внешние идентификаторы (external ID) для партнерского доступа. Ресурсные политики для бакетов S3, очередей SQS и ключей KMS обеспечивают прямой межаккаунтный доступ, но KMS усложняет задачу: политика ключа KMS должна явно разрешать доступ субъектам и сервисам из доверяющего аккаунта, а для временного доступа могут потребоваться гранты (grants) или гранты с ограничениями. Использование централизованного ключа KMS в аккаунте логирования или безопасности упрощает централизованное шифрование, но создает операционную связанность и потенциальные проблемы с доступностью; ключи для каждого аккаунта уменьшают радиус поражения, но усложняют ротацию ключей и управление грантами. К распространенным ловушкам относятся SCP, которые непреднамеренно запрещают создание ключей KMS или связанных с сервисами ролей, политики бакетов, конфликтующие с SCP, и ситуация, когда забывают добавить роль для делегирования в Config/CloudTrail в аккаунте-сборщике. При принятии проектных решений следует взвешивать простоту администрирования, принцип наименьших привилегий и задержки при межаккаунтном доступе.

Шаблоны централизованного логирования, биллинга и автоматизации

Централизованное логирование и биллинг — это основа для обеспечения прозрачности в масштабе предприятия. Организационный CloudTrail с трейлами, доставляемыми в бакет S3 в централизованном аккаунте безопасности или аудита, обеспечивает сбор событий с защитой от несанкционированного доступа; дополните это фильтрами подписки CloudWatch Logs на Kinesis Data Firehose для аналитики и агрегируйте данные Config с помощью агрегатора в тот же аккаунт. Для прозрачности затрат требуется консолидированный биллинг в Organizations, Cost Explorer, Budgets и отчеты Cost and Usage Reports, доставляемые централизованно; управление тегами и автоматическое применение политик тегирования через правила Config повышают точность распределения затрат. Шаблоны автоматизации, которые масштабируются на несколько аккаунтов, обычно используют общий конвейер CI/CD или аккаунт развертывания, который принимает межсетевые роли для развертывания, или CloudFormation StackSets с делегированным администратором для массового предоставления ресурсов. Используйте Systems Manager Automation и State Manager для межсетевого применения патчей и конфигураций, но помните, что каждый аккаунт должен предоставить необходимые роли и разрешения SSM. Компромиссы касаются баланса между централизацией и задержками: центральная агрегация сокращает дублирование хранилища и упрощает анализ, но создает зависимости от сети и доступности; распределенное логирование дублирует данные, но изолирует сбои. Планируйте хранение, правила жизненного цикла, межрегиональную репликацию для аварийного восстановления (DR) и управление ключами шифрования в соответствии с требованиями комплаенса.

Практическая задача: сценарий использования

Сценарий: Contoso Media управляет корпоративной средой AWS с развернутыми Organizations и Control Tower. У них есть управляющий аккаунт, аккаунт общих сетевых сервисов и 20 аккаунтов-участников с рабочими, тестовыми и девелоперскими нагрузками в двух регионах.

Задача: Contoso необходимо быстро подключить 15 новых проектных аккаунтов, обеспечив при этом централизованное логирование, соответствующие защитные ограничения SCP, автоматизированное сетевое подключение к аккаунту общих сервисов через Transit Gateway и конвейеры развертывания, не требующие ручной настройки IAM для каждого аккаунта.

Рекомендуемый подход:

1. Использовать Control Tower Account Factory или автоматизированный рабочий процесс на базе API AWS Organizations для выдачи аккаунтов с базовым шаблоном CloudFormation/CDK, который регистрирует аккаунт в AWS Config, включает организационный CloudTrail, указывающий на бакет S3 в аккаунте аудита, и применяет необходимые теги.
2. Прикрепить SCP на уровне OU, которые применяют запреты с высоким уровнем воздействия (например, запрет на удаление ключей в других регионах и использование запрещенных регионов), при этом сохраняя OU с разрешениями для разработки менее строгими; проверить SCP в «песочнице» перед широким применением.
3. Настроить Transit Gateway в аккаунте общих сетевых сервисов и создать подключения (attachments) для Transit Gateway VPC attachment каждого нового аккаунта с помощью Infrastructure-as-Code и делегированного администратора или межсетевой роли, которую принимает процесс выдачи аккаунтов, для автоматизации создания подключений и распространения маршрутов.
4. Создать централизованный конвейер развертывания CI/CD в аккаунте для инструментов, который использует межсетевые IAM-роли (assume-role), созданные в процессе выдачи аккаунтов; использовать CloudFormation StackSets (с делегированным администратором) или межсетевые действия CodePipeline для начального базового развертывания и последующих обновлений.

Обоснование: Автоматизация выдачи аккаунтов с базовыми артефактами обеспечивает управление, минимизируя ручные операции; делегирование сетевых задач и задач развертывания через межсетевые роли и Transit Gateway централизует общие сервисы, уменьшает радиус поражения и позволяет масштабировать подключение новых аккаунтов без ущерба для безопасности или возможности аудита.

Все домены · Сетевое взаимодействие и гибридное подключение →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →