В AWS Organization есть единственное OU под названием Production, которое содержит все аккаунты. SCP-политики deny-list на корневом уровне используются для ограничения доступа к определенным сервисам. Недавно приглашенный аккаунт из приобретенного бизнес-подразделения не может обновить существующие правила AWS Config в соответствии с политикой компании. Какой подход позволит администраторам нового аккаунта внести необходимые изменения сейчас, сохраняя и обеспечивая соблюдение существующих политик с минимальным текущим обслуживанием?

Правильный подход заключается в создании временного OU Onboarding для нового аккаунта. Это позволяет прикрепить к нему SCP, который разрешает необходимые действия AWS Config, не затрагивая существующие политики в OU Production. Перемещение корневых SCP организации под OU Production гарантирует, что эти политики будут применяться ко всем аккаунтам в Production, но не к аккаунту в Onboarding. После завершения изменений аккаунт перемещается в Production, где к нему применяются стандартные политики. Остальные варианты менее оптимальны: Удаление корневых SCP и использование Service Catalog требует значительных усилий по перестройке политик и не решает проблему немедленного доступа. Создание временного OU Onboarding, но без перемещения корневых SCP, может привести к конфликтам политик, если корневые SCP по-прежнему блокируют Config. Преобразование корневых SCP в allow-list — это масштабное изменение, которое требует тщательного планирования и может нарушить работу других сервисов, а временное разрешение Config только для нового аккаунта на корневом уровне может быть сложным в управлении и небезопасным.