Как различать различные среды AWS - Dev, Test, Stage, Production?

Question

Я хотел бы иметь различные условия в AWS. Сначала я подумал о том, чтобы различать среды по тегам, тегам AWS Resources. Но тогда я не могу запретить пользователям изменять теги машины. Это означает, что если я разрешаю им ec2:CreateTags, они могут не только создать тег, но и изменить тег любого из ресурсов, поскольку не могут применить к нему условие - скажем, например, если он принадлежит определенному VPC или подсети. Если я не разрешаю им создавать теги, то они могут запускать экземпляр, но теги не применяются, и поэтому дальнейшая операция по экземпляру не разрешена.

Если я хочу различать среды по VPC-ID, то для таких операций, как ec2:StartInstance, не может применяться условие, позволяющее выполнять операцию только в определенном VPC-ID, но может условно разрешать на основе тега ресурсов, что по причинам предыдущего пункт не является убедительным.

На АМС documentation он упоминает

Один из подходов к сохранению такого разделения обсуждалась в Working with AWS Access Credentials, то есть использовать различные учетные записи для развития и производственных ресурсов.

Возможно, у вас есть один Платежный счет для нескольких других счетов, которые сами являются Платежными счетами? Я до сих пор не думаю, что несколько учетных записей только для разных сред - хорошая идея.

Как вы обычно различаете среду для обеспечения соблюдения политик?

Спасибо.

Answer 1

Возможно сделать consolidated billing, когда одна учетная запись выставлена ​​счет за собственное использование + использование AWS для любой другой связанной учетной записи. Однако вы не можете разделить этот счет (например, если главная учетная запись оплачивает только сервисы EC2 в связанной учетной записи, а связанная учетная запись оплачивается за другое использование, такое как S3 и т. Д.).

Что касается различий между средами, я использовал разные security groups для каждого из них (dev, staging, production) в качестве альтернативы тегам, но есть ограничения, связанные с соблюдением политик. Лучший способ иметь полный контроль над политикой - использовать разные учетные записи.

Answer 2

Различные учетные записи - путь. Есть так много мест, которые вы захотите создать изоляцию, и вы сойдете с ума, пытаясь сделать это в одной учетной записи. Подумайте об этом - есть сетевые элементы управления, все разрешения IAM для всех служб, списки управления доступом, теги, которые имеют ограничения, которые вы описываете, и так далее. Реальная изоляция возникает из-за того, что в настоящее время есть вещи в разных аккаунтах.

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

Консолидированный расчет - это ответ на оплату всего этого. Простота настройки и отслеживания. Если вам нужно больше отчетов, посмотрите в CloudAbility.

Где это действительно интересно, это место в нескольких продуктах и ​​в нескольких средах разработчиков. Есть много мнений о изоляции там. Некоторые люди объединяют все prod и dev в две учетные записи, а некоторые добавляют каждый prod и dev в свои собственные. Все зависит от вашего профиля риска. Просто не используйте CloudSpaces.

Answer 3

Я бы предложил пойти с одним VPC и использовать группы безопасности для изоляции. По мере роста вашего AWS-инфраструктуры вам понадобятся службы каталогов (серверы имен, каталог пользователей, каталог VM, службы поиска и т. Д.). Если у вас есть два VPC, совместное использование служб каталогов будет непростым. Также, если вам нужны репозитории кода (например, GitHub) или инструменты сборки (например, Jenkins), имеющие три отдельных VPC для DEV, Staging and Production сделает вещи действительно сложными.