Начать работу с AWS Organizations

Попробуйте AWS Organizations

Сервис AWS Organizations доступен всем клиентам AWS бесплатно.

Вопрос: Что такое AWS Organizations?

AWS Organizations предлагает управление множеством аккаунтов AWS на основе политик. С помощью сервиса AWS Organizations можно создавать группы аккаунтов и затем применять к ним определенные политики. Сервис AWS Organizations позволяет централизованно управлять политиками для множества аккаунтов, при этом не требуется создавать скрипты или выполнять какие-либо действия вручную.

Вопрос: Какие административные задачи позволяет выполнять сервис AWS Organizations?

Сервис AWS Organizations позволяет выполнять следующие административные задачи:

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

Вопрос: Какие средства управления доступны в текущей версии AWS Organizations?

В этом релизе можно назначать и использовать операции на уровне сервисов AWS, например RunInstances сервиса Amazon EC2, для различных аккаунтов AWS в пределах организации.

Вопрос: Потребуется ли переходить из семейства Consolidated Billing в AWS Organizations?

Нет, AWS автоматически выполняет миграцию семейств сервиса Consolidated Billing в AWS Organizations с сохранением возможностей только консолидированной оплаты.

Вопрос: Как начать работу с сервисом?

Чтобы начать работу, нужно сначала определить, какой из ваших аккаунтов AWS будет основным аккаунтом. Если вы уже использовали семейство Consolidated Billing, аккаунт AWS, являющийся плательщиком в семействе, автоматически превратится в основной аккаунт. Если у вас нет семейства Consolidated Billing, вы можете либо создать новый аккаунт AWS, либо выбрать один из существующих.

Необходимые действия для клиентов, использующих Consolidated Billing

  1. Перейдите в консоль Consolidated Billing. AWS перенаправит вас в новую консоль сервиса AWS Organizations.
  2. AWS автоматически преобразует ваше семейство Consolidated Billing, поэтому можно будет сразу пользоваться организационными возможностями нового сервиса.
Необходимые действия для клиентов, не использующих Consolidated Billing
 
Вам потребуется создать новую организацию, выполнив следующие простые действия.
 
  1. Войдите в Консоль управления AWS как администратор, используя аккаунт AWS, который будет основным для управления вашей организацией.
  2. Перейдите в консоль AWS Organizations.
  3. Выберите Create Organization
  4. Выберите, какие возможности планируется использовать для организации. Предлагаются варианты использования consolidated billing only features или all features.
  5. Добавьте аккаунты AWS к организации с помощью одного из двух методов.
    1. Пригласите вступить в организацию существующий аккаунт AWS, используя ID этого аккаунта или связанный с ним электронный почтовый адрес.
    2. Создайте новый аккаунт AWS.
  6. Смоделируйте иерархическую структуру вашей организации путем группировки аккаунтов AWS в организационные единицы (OU).
  7. Если вы включили все возможности для вашей организации, можно будет создавать средства управления и назначать их соответствующим OU.

Для выполнения аналогичных действий по созданию новой организации также можно использовать интерфейс командной строки AWS (для доступа из командной строки) или SDK (для программного доступа).

Примечание. Создание новой организации можно инициировать только из аккаунта AWS, который не является членом другой организации.
 
Подробнее см. в разделе Начало работы с AWS Organizations.

Вопрос: Что такое организация?

Организация – это набор аккаунтов AWS, которые можно организовать иерархически и для которых можно использовать централизованные инструменты управления.

Вопрос: Что такое аккаунт AWS?

Аккаунт AWS – это контейнер ваших ресурсов AWS. Пользователи создают ресурсы AWS и управляют ими на уровне аккаунта AWS, в котором предусмотрены возможности администрирования для обеспечения доступа и управления счетами.

Вопрос: Что такое основной аккаунт?

Основной аккаунт – это аккаунт AWS, используемый для создания организации. Из основного аккаунта можно создавать новые аккаунты организации, приглашать существующие аккаунты и управлять приглашениями вступить в организацию, а также удалять аккаунты из организации. Можно также назначать политики определенным сущностям, таким как пользователи с административным доступом root, организационные единицы (OU) или аккаунты, принадлежащие к организации. Основной аккаунт является плательщиком и несет ответственность за оплату всех ресурсов, использованных аккаунтами организации. Роль основного аккаунта организации нельзя переназначить.

Вопрос: Что такое аккаунт-участник?

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

Вопрос: Что представляет собой административный доступ root?

Административный доступ root – это начальная точка управления аккаунтами AWS в организации. Пользователь с административным доступом root – это самый верхний элемент в иерархии вашей организации. Имея доступ root, можно создавать OU для логической группировки аккаунтов и организовывать эти OU в иерархическую структуру, наилучшим образом отвечающую практическим потребностям организации.

Вопрос: Что такое организационная единица (OU)?

Организационная единица (OU) – это группа аккаунтов AWS в рамках организации. В OU могут также входить другие OU, что позволяет создавать иерархическую структуру. Например, можно сгруппировать все аккаунты, относящиеся к одному отделу, в OU отдела. Аналогичным образом можно сгруппировать все аккаунты, относящиеся к рабочим сервисам, в рабочую OU. OU удобно использовать тогда, когда требуется применить одни и те же параметры к некому набору аккаунтов организации. Вложенные OU дают возможность создать более мелкие единицы управления. Например, в OU отдела можно сгруппировать аккаунты, относящиеся к отдельным группам сотрудников в OU уровня групп сотрудников. Кроме подчинения непосредственно назначенным политикам, эти OU уровня групп сотрудников наследуют политики от родительских OU.

Вопрос: Что такое политика?

Политика – это «документ», содержащий одно или более выражений, описывающих директивы, которые требуется применить к группе аккаунтов AWS. В рамках текущего релиза сервис AWS Organizations поддерживает особый тип политики, называемый политикой управления сервисом (SCP). SCP определяет операции на уровне сервисов AWS, например RunInstances сервиса Amazon EC2, доступные для тех или иных аккаунтов в пределах организации.


Вопрос: Можно ли управлять организацией и определять параметры для нее с учетом регионов?

Нет. Все сущности организации доступны глобально, аналогично тому, как сейчас работает сервис AWS Identity and Access Management (IAM). При создании организации и управлении ею регион указывать не требуется. Пользователи ваших аккаунтов AWS могут использовать сервисы AWS в любом географическом регионе, где доступен данный сервис.

Вопрос: Можно ли назначить другой аккаунт AWS основным?

Нет. Основной аккаунт AWS переназначить нельзя. Поэтому следует тщательно подходить к выбору основного аккаунта.

Вопрос: Как добавить аккаунт AWS к организации?

Для добавления аккаунта AWS к организации воспользуйтесь одним из следующих методов.

Метод 1. Приглашение в организацию существующего аккаунта

  1. Авторизуйтесь как администратор основного аккаунта и перейдите в консоль AWS Organizations.
  2. Выберите вкладку «Accounts».
  3. Выберите «Add account», затем «Invite account».
  4. Укажите адрес электронной почты приглашаемого аккаунта или его идентификатор.

Примечание. Чтобы пригласить несколько аккаунтов AWS, введите их адреса электронной почты или идентификаторы через запятую.

Указанные аккаунты AWS получат электронные письма с приглашением присоединиться к организации. Администратор приглашаемого аккаунта AWS должен принять или отклонить запрос с помощью консоли AWS Organizations, интерфейса командной строки AWS или API сервиса AWS Organizations. Если администратор принимает приглашение, аккаунт становится видимым в списке аккаунтов-участников вашей организации. Любые соответствующие политики, такие как SCP, будут применены к добавленному аккаунту автоматически. Например, если в организации есть SCP, назначенная на уровне root организации, она будет применена напрямую ко всем создаваемым аккаунтам.

Метод 2. Создание нового аккаунта AWS в организации

  1. Авторизуйтесь как администратор основного аккаунта и перейдите в консоль AWS Organizations.
  2. Выберите вкладку «Accounts».
  3. Выберите «Add account», затем «Create account».
  4. Введите имя и адрес электронной почты для нового аккаунта.

Аккаунт можно также создать с помощью AWS SDK или командной строки AWS. При использовании любого из методов добавленный аккаунт можно переместить в организационную единицу (OU). Новый аккаунт автоматически наследует все политики, назначенные на уровне OU.

Вопрос: Может ли аккаунт AWS принадлежать к нескольким организациям одновременно?

Нет. Аккаунт AWS может принадлежать только к одной организации.

Вопрос: Как осуществляется доступ к аккаунту AWS, созданному в организации?

При создании нового аккаунта AWS сервис AWS Organizations создает роль IAM с полным набором прав администратора для этого аккаунта. Пользователи и роли IAM основного аккаунта, имеющие соответствующие разрешения, могут использовать эту роль IAM для доступа к созданному аккаунту.

Вопрос: Можно ли программно настроить многофакторную аутентификацию (MFA) для аккаунта AWS, созданного в организации?

Нет. Такая возможность в настоящее время отсутствует.

Вопрос: Можно ли переместить аккаунт AWS из организации, где он был создан с помощью AWS Organizations, в другую организацию?

Нет. Такая возможность в настоящее время отсутствует.

Вопрос: Можно ли удалить из организации аккаунт AWS, созданный с помощью AWS Organizations, и сделать его независимым аккаунтом?

Да. Однако когда аккаунт создается в рамках организации с помощью консоли AWS Organizations, API или команд интерфейса командной строки, автоматически собирается не вся информация, требуемая для независимых аккаунтов. Для каждого аккаунта, который нужно сделать независимым, сначала требуется принять Пользовательское соглашение AWS, выбрать план поддержки, предоставить и подтвердить необходимую контактную информацию и указать текущий способ оплаты. AWS использует предоставленный способ оплаты для взимания средств за любую платную (то есть выходящую за пределы уровня бесплатного пользования AWS) активность аккаунта, не привязанного к организации. Подробнее см. в процедуре To leave an organization when all required account information has not yet been provided (console) в документации.

Вопрос: Сколько аккаунтов AWS может принадлежать к организации?

Возможны различные варианты. Если вам требуются дополнительные аккаунты, перейдите в Центр AWS Support и подайте заявку на увеличение лимита.

Вопрос: Как удалить из организации аккаунт-участник?

Аккаунт-участник можно удалить, используя один из описанных далее методов. Чтобы удалить аккаунт, созданный с помощью AWS Organizations, возможно, придется предоставить дополнительную информацию. Если попытка удалить аккаунт не удалась, перейдите в Центр AWS Support и обратитесь за помощью в удалении аккаунта.

Метод 1. Удаление аккаунта-участника от имени основного аккаунта

  1. Авторизуйтесь как администратор основного аккаунта и перейдите в консоль AWS Organizations.
  2. В панели слева выберите Accounts.
  3. Выберите аккаунт, который требуется удалить, затем выберите Remove account.
  4. Если для аккаунта не указан действительный метод оплаты, его потребуется указать.

Метод 2. Удаление аккаунта-участника от имени аккаунта-участника

  1. Авторизуйтесь как администратор аккаунта-участника, который требуется удалить из организации.
  2. Перейдите в консоль AWS Organizations.
  3. Выберите Leave organization.
  4. Если для аккаунта не указан метод оплаты, его потребуется указать.

Вопрос: Как создать организационную единицу (OU)?

Чтобы создать OU, выполните следующие действия.

  1. Авторизуйтесь как администратор основного аккаунта и перейдите в консоль AWS Organizations.
  2. Выберите вкладку Organize accounts.
  3. Перемещайтесь по иерархической структуре до места, где нужно создать OU. Ее можно создать прямо на корневом уровне или внутри другой OU.
  4. Выберите Create organizational unit и укажите имя для OU. Имя должно быть уникальным в пределах организации.

Примечание. Позднее OU можно будет переименовать.

Теперь можно добавлять аккаунты AWS в созданную OU. Для создания OU и управления ими также можно использовать интерфейс командной строки и API AWS.

Вопрос: Как добавить аккаунт-участник AWS в OU?

Для добавление аккаунта-участника в OU выполните следующие действия.

  1. В консоли AWS Organizations выберите вкладку «Organize accounts».
  2. Выберите аккаунт AWS, затем выберите «Move account».
  3. В диалоговом окне выберите OU, в которую требуется переместить выбранный аккаунт AWS.

Кроме того, для добавления аккаунтов AWS в OU можно использовать интерфейс командной строки или API AWS.

Вопрос: Может ли один аккаунт AWS одновременно принадлежать к разным OU?

Нет. Один аккаунт AWS может принадлежать только к одной OU.

Вопрос: Может ли OU одновременно принадлежать нескольким OU?

Нет. Один аккаунт AWS может принадлежать только одной OU.

Вопрос: Сколько уровней может быть в иерархии OU?

Максимальный уровень вложений OU равен пяти. Если считать корневой уровень и аккаунты AWS, созданные в самой нижней OU, в вашей иерархии может быть пять уровней.


Вопрос: Как можно предоставлять права для управления организацией?

Предоставление прав для управления организацией и ее ресурсами осуществляется так же, как и предоставление доступа к другим ресурсам AWS. Для этого нужно связать политики IAM с определенными пользователями, группами или ролями IAM в основном аккаунте. С помощью политик IAM можно выполнять следующие действия:

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

Вопрос: Почему в каждом аккаунте, который я создаю с помощью AWS Organizations, определена роль IAM?

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

Вопрос: Можно ли предоставлять разрешения на управление организацией пользователям IAM любого аккаунта – участника организации?

Да. Чтобы предоставить пользователю IAM аккаунта-участника разрешение на управление всей организацией или ее частями, можно использовать роли IAM. Потребуется создать роль с соответствующими разрешениями в основном аккаунте и разрешить пользователям или ролям в аккаунте-участнике принимать эту новую роль. При этом используется тот же метод взаимодействия между аккаунтами, что и для предоставления пользователю IAM одного аккаунта доступа к ресурсам (например, к таблицам Amazon DynamoDB) другого аккаунта.

Вопрос: Может ли пользователь IAM в аккаунте-участнике выполнить вход в организацию?

Нет. Пользователи IAM могут выполнять вход только в свои аккаунты-участники, связанные с организацией.

Вопрос: Может ли пользователь IAM выполнить вход в OU организации?

Нет. Пользователи IAM могут выполнять вход только в свои аккаунты AWS, связанные с организацией.

Вопрос: Можно ли в рамках аккаунта AWS определить пользователей, которые смогут принимать приглашения для присоединения к организации?

Да. С помощью разрешений IAM можно предоставлять пользователям аккаунта возможность принимать или отклонять приглашения присоединиться к организации. Следующая политика предоставляет доступ для просмотра приглашений и управления ими в аккаунте AWS.

{

    "Version": "2012-10-17",

    "Statement":[

        {

            "Effect": "Allow",

            "Action":[

                "organizations:AcceptHandshake",

                "organizations:DeclineHandshake",

                "organizations:DescribeHandshake",

                "organizations:ListHandshakesForAccount"

            ],

            "Resource":" *"

        }

    ]

}


Вопрос: На каких уровнях организации можно применять политики?

Политики можно применить на уровне root организации (действует для всех аккаунтов организации), на уровне отдельной организационной единицы (действует для всех аккаунтов данной OU, включая вложенные OU) или на уровне отдельных аккаунтов.

Вопрос: Как можно назначить политику?

Назначить политику можно одним из двух способов.

  • В консоли AWS Organizations выберите объект, которому требуется назначить политику (root, OU или конкретный аккаунт), затем выберите Attach Policy.
  • В консоли AWS Organizations перейдите на вкладку Policies и выполните одно из следующих действий.
    • Выберите существующую политику, затем выберите пункт Attach Policy в раскрывающемся списке Actions, и укажите root, OU или аккаунт, которым требуется назначить политику.
    • Выберите Create Policy, и затем, в процессе создания политики, выберите root, OU или аккаунт, которым требуется назначить новую политику.

Подробнее см. в разделе Управление политиками.

Вопрос: Наследуются ли политики через иерархические связи в организации?

Да. Предположим, аккаунты AWS сгруппированы в несколько OU в соответствии с этапами разработки приложений: DEV, TEST и PROD. Политика P1 назначена на уровне root организации, политика P2 назначена на уровне OU DEV, а политика P3 назначена аккаунту AWS A1, входящему в OU DEV. В этом случае к аккаунту A1 применяются все три политики: P1, P2, и P3.

Подробнее см. в разделе О политиках управления сервисами.

Вопрос: Какие типы политик поддерживает сервис AWS Organizations?

В настоящее время сервис AWS Organizations поддерживает политики управления сервисами (SCP). С помощью SCP можно назначать и обеспечивать выполнение операций, которые пользователи, группы и роли IAM могут выполнять в соответствующих аккаунтах, где применяются SCP.

Вопрос: Что такое политики управления сервисами (SCP)?

Политики управления сервисами (SCP) позволяют определить, какие операции сервисов AWS доступны основным сущностям (таким как аккаунт с правами root, пользователь IAM и роль IAM) в аккаунтах организации. SCP является необходимым, но не единственными средством управления, определяющим, к каким ресурсам могут иметь доступ основные сущности аккаунта. Фактические разрешения для основных сущностей аккаунта, к которому применена SCP, являются пересечением множества разрешений, явно заданных этой политикой, и множества разрешений, явно назначенных данной основной сущности. Например, если примененная к аккаунту SCP допускает только операции сервиса Amazon EC2, а разрешения основной сущности этого же аккаунта AWS допускают операции сервисов EC2 и Amazon S3, то у основной сущности будет доступ только к операциям сервиса EC2.

Кроме того, основные сущности аккаунта-участника (включая пользователя с правами root аккаунта-участника) не могут удалять или изменять примененные к аккаунту SCP.

Вопрос: Как выглядит структура SCP?

SCP следуют тем же правилам и используют тот же синтаксис, что и политики IAM, за исключением того, что в них нельзя указывать условия и в разделе «Resource» должно указываться значение «*». С помощью SCP можно предоставлять или запрещать доступ к операциям на уровне отдельных сервисов AWS.

Пример «белого» списка

Следующая SCP предоставляет доступ ко всем операциям сервисов EC2 и S3 в аккаунте AWS. Все основные сущности (аккаунт root, пользователь IAM и роль IAM) аккаунта, к которому применена данная SCP, не будут иметь доступа к любым другим операциям, независимо от того, какие политики IAM назначены непосредственно для них. Эти политики IAM должны явно разрешать операции сервисов EC2 или S3, чтобы основные сущности имели к ним доступ.

{

    "Version": "2012-10-17",

    "Statement":[

        {

            "Effect": "Allow",

            "Action":["EC2:*","S3:*"],

            "Resource":" *"

        }

    ]

}

Пример черного списка

Следующая SCP предоставляет доступ ко всем операциям сервисов AWS, кроме операции PutObject сервиса S3. Все основные сущности (аккаунт с правами root, пользователь IAM и роль IAM) с соответствующими, непосредственно им назначенными разрешениями на уровне аккаунта, с применением этой SCP будут иметь доступ к любым операциям, кроме операции PutObject сервиса S3.

{

    "Version": "2012-10-17",

    "Statement":[

        {

            "Effect": "Allow",

            "Action": "*:*",

            "Resource":" *"

        },

        {

            "Effect":"Deny",

            "Action":"S3:PutObject",

            "Resource":" *"

        }

    ]

}

Другие примеры см. в разделе Стратегии использования SCP.

Вопрос: Если аккаунту AWS назначена пустая SCP, значит ли это, что в данном аккаунте AWS разрешены все операции сервисов AWS?

Нет. SCP действуют точно так же, как и политики IAM, а пустая политика IAM эквивалентна отказу по умолчанию. Применение к аккаунту пустой SCP равнозначно назначению политики, явно запрещающей все операции.

Вопрос: Можно ли в SCP указать ресурсы и основные сущности?

Нет. В текущем релизе в SCP можно указать только сервисы и операции AWS. Ресурсы и основные сущности можно указать только с помощью разрешающих политик IAM в рамках аккаунта AWS. Подробнее см. Синтаксис политик управления сервисами (SCP)

Вопрос: Какими будут фактические разрешения, если применить SCP к организации, основным сущностям которой уже назначены политики IAM?

Фактические разрешения для основных сущностей аккаунта (таких как аккаунт с правами root, пользователь IAM и роль IAM) аккаунта AWS, к которому применена SCP, являются пересечением множества разрешений, заданных этой политикой, и множества разрешений, назначенных основным сущностям разрешениями политик IAM. Например, если для пользователя IAM указано "Allow": "ec2:* " и "Allow": "sqs:* ", и в SCP, назначенной аккаунту, указано "Allow": "ec2:* " и "Allow": "s3:* ", результирующее разрешение для пользователя IAM будет "Allow": "ec2:* ". Основная сущность не сможет выполнять никаких операций сервиса Amazon SQS (нет разрешения SCP) или сервиса S3 (не разрешены политикой IAM).

Вопрос: Можно ли смоделировать результат действия SCP на уровне аккаунта AWS?

Да, симулятор политик IAM может смоделировать и результат действий SCP. Можно использовать симулятор политик в аккаунте-участнике организации, чтобы увидеть влияние политики на отдельные основные сущности аккаунта. Администратор аккаунта-участника с соответствующими разрешениями AWS Organizations может видеть, влияет ли SCP на доступ основных сущностей (аккаунт root, пользователь IAM и роль IAM) в аккаунте-участнике.

Подробнее см. в разделе Политики управления сервисами.

Вопрос: Можно ли создать организацию и управлять ею, не используя SCP?

Да. Набор политик для использования определяется пользователем. Например, можно создать организацию, в которой будут использоваться только возможности Consolidated Billing. Это позволяет использовать единый аккаунт-плательщик для всех аккаунтов организации и автоматически получать преимущества по умолчанию, связанные с уровнями цен.


Вопрос: Сколько стоит использование сервиса AWS Organizations?

Дополнительная плата за использование сервиса AWS Organizations не взимается.

Вопрос: Кто отвечает за оплату расходов аккаунтов AWS, входящих в организацию?

За оплату всех видов пользования, за использование данных и ресурсов аккаунтами организации отвечает владелец основного аккаунта.

Вопрос: Можно ли сравнить возможности AWS Organizations и Consolidated Billing?

Возможности сервиса Consolidated Billing теперь являются частью сервиса AWS Organizations. AWS Organizations позволяет использовать консолидированную оплату для множества аккаунтов AWS в рамках компании путем назначения одного аккаунта-плательщика. Подробнее см. Consolidated Billing и AWS Organizations.

Вопрос: Отображается ли в счетах структура организационных единиц (OU), созданная в организации?

Нет. В настоящий момент в счете не отображается структура, заданная для организации. Для категоризации и отслеживания затрат на ресурсы AWS можно использовать теги для распределения расходов отдельных аккаунтов AWS. Это распределение будет отображено в консолидированном счете организации.