AWS, как привязка аккаунта и консолидированный биллинг в GCP

Question

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

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

Answer 1

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

Вы можете создать аналогичную иерархию вGoogle Cloud.

Я могу пригласить учетные записи DBA в бизнес-организацию и связать их так, чтобы бизнес-организация стала плательщиком.

Это можно сделать с помощью Google Cloud, нопо-другому. Вы не можете сделать одну организацию филиалом / дочерним объектом другой организации, но вы можете добавить ее членов (идентификационные данные) в другую организацию. Ключ к этому - члены фактически не являются частью организации. Идентификационные данные независимы, легко добавляются и удаляются.

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

Google Cloud поддерживает одинили больше платежных аккаунтов. Счета счета могут быть назначены на проекты независимо от организаций. Я могу назначить свою платежную учетную запись ответственной за любой проект Google (упрощение).

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

У Google нет такой гибкости без усилий. В Google Cloud я бы не объединял проекты в организации, если бы эта цель не была постоянной. Вместо этого я бы добавил членов, необходимых для доступа к этому проекту, в IAM.

Проекты, независимые от организации, могут по-прежнему участвовать в другой организации и наоборот. Облачное управление идентификацией и доступом к Google (IAM) очень гибкое. Если я хочу, чтобы bob@example.com имел доступ к Project ABC, я могу добавить его адрес электронной почты в IAM и назначить роли. Вы также можете добавить целый домен пользователей *@example.com в Google IAM. Есть еще много вариантов.

Вы можете перемещать проекты внутри организации, но вы не можете перемещать проекты в другую организацию самостоятельно - для этого необходимо открыть заявку в службу поддержки в Google Cloud Support.

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

Облако Google не привязано к имени домена, как Google G Suite. Если вы планируете также использовать G Suite для нескольких администраторов баз данных, у меня будут отдельные учетные записи Google, и я не буду объединять G Suite с моими ресурсами в Google Cloud. Примечание. G Suite поддерживает несколько доменов;для одной организации, связывающей G Suite и Google Cloud, это нормально.

Я считаю, что метод организации, папок, проектов и IAM в Google Cloud более гибкий, чем AWS.

AWS и Google имеют мощные системы IAM. Я хорошо знаю оба, у каждого есть свои плюсы и минусы.

Answer 2

Хотя ответ Джона говорит о том, что все возможно, в нем не было подробностей о том, как это сделать. После долгих поисков в Интернете и экспериментов мне удалось сделать то, что я хотел. Ниже приведены шаги с использованием ссылок "business" и "dba" в моем вопросе.

1. Создайте профиль оплаты с основным контактом, скажем, billing @ businessdomain
2. Убедитесь, что тип учетной записи указанБизнес а не Индивидуальный. В моём случае я каким-то образом оказался с индивидуальным аккаунтом. Не разрешается изменять тип учетной записи после создания. Не знаю почему, но это было мое первое препятствие.
3. С типом бизнес-аккаунта можно приглашать других пользователей.
4. Я не был уверен, как создать бизнес-аккаунт и могу ли я использовать тот же адрес электронной почты для типа бизнес-аккаунта. Изнутри GCP я пошел дальше и выполнил настройку биллинга. Исходя из моего логина, у которого был индивидуальный профиль оплаты, он установил профиль по умолчанию, но позволил мне создать новый профиль. Я выбрал тип учетной записи как «Бизнес», но все остальные данные были такими же, как в другой личной учетной записи, которая была создана. К счастью, это было сделано и создало профиль бизнес-платежей.
5. После того, как у меня появился профиль бизнес-платежей, я мог пойти дальше и пригласить пользователя из моего dba, указав адрес электронной почты, скажем, billing @ dbadomain
6. Это письмо получило приглашение и после его принятия былосвязаны с тем же платежным профилем. Это ключ! По сути, это позволяет использовать профиль оплаты, связанный с одним доменом (организацией), для платежного счета другого домена (организации).
7. В этот момент я даже закрыл профиль оплаты с типом индивидуального счета, и он, похоже, сработал. До сих пор у меня не было никаких транзакций, и, похоже, он никогда не должен существовать. Хотелось бы, чтобы можно было изменить тип учетной записи для таких профилей.

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