Компания использует AWS Control Tower с AWS Organizations и хочет ограничить учетные записи разработчиков (организованные в определенном OU) таким образом, чтобы они могли запускать только масштабируемые (burstable) типы инстансов EC2 и RDS и не могли использовать несвязанные сервисы. У разработчиков много индивидуальных учетных записей для разработки. Какой подход должен рекомендовать архитектор решений для обеспечения этих ограничений?

Правильный ответ — создание пользовательского превентивного контроля (guardrail) в AWS Control Tower. Превентивные контроли используют политики управления сервисами (SCP) AWS Organizations для предотвращения выполнения запрещенных действий до их возникновения, что соответствует требованию по ограничению типов инстансов и запрету несвязанных сервисов. Применение его к OU для разработки гарантирует, что все учетные записи в этом OU будут соблюдать эти ограничения. Создание пользовательской SCP напрямую (первый вариант) является основой превентивного контроля, но AWS Control Tower предоставляет управляемый способ их развертывания и управления как "превентивные контроли". Детективные контроли (второй вариант) только обнаруживают нарушения после их возникновения, а не предотвращают их. Правило AWS Config (четвертый вариант) также является детективным контролем и не предотвращает действия, а лишь сообщает о несоответствии.