我们的组织是AWS的长期用户。在AWS中，我们创建一个具有Root访问权限的帐户，然后通过IAM将用户添加到该帐户中，分配用户名并提供现有的电子邮件地址。每个用户在整个帐户中都分配有一个或多个角色。使用此模型，我们可以使用现有人员的电子邮件（在我们的电子邮件域或其他地方）轻松地添加/删除单个员工和承包商。现在，我们需要部署一个为Google Cloud Platform GAE编写的应用程序：我们针对sys admin的Google用户帐户设置了一个试用版Google Cloud Platform帐户。我们如何按照上述混合的员工与承包商的用例向该Google Cloud Platform帐户添加帐户范围内的用户？
我们可以将任何Google用户以及可能的其他特定资源添加到GAE项目中，但不能添加到整个帐户中。在帐户中，我们将其“升级”为免费试用版中提示的任何默认值，其中有一个设置组织的选项。这似乎是设置帐户范围内的用户访问权限的方法，但是令人困惑的部分是，需要注册Cloud Identity，提供我们需要通过CNAME或html展示所有权的组织域，而不仅仅是TXT ？我们主要组织的域和电子邮件系统位于AWS上，我们不希望使用其路由或服务器。此外，该指南还指出，该域上的所有用户都将默认访问GCP帐户-这没有意义，因为只有Google用户似乎可以链接到GCP。因此，相当混乱。
感觉就像我们需要为GCP建立一些“新”组织，可能是针对我们拥有的备用，未使用的域名之一，我们可以在其中开始添加Google用户-这是最好的选择吗？请记住，我们已经为Google文档和Search Console设置了一些帐户-这些帐户目前似乎与GCP身份验证概念完全分开。
Google Cloud Identity Organization是必须设置的实体，以便内部IT和顾问管理您的GCP资源的多个用户（除非您使用G Suite-谷歌邮件等-然后阅读有关将其链接到GCP的信息）。设置单位可能应该是创建第一个GCP帐户的第一步，而不是弹出的默认“免费帐户”选项。从免费帐户到通过Org管理的帐户之间存在一条迁移路径，但是如果在进入GCP时已将Org设置为Step-1，则可以避免这种迁移。
组织中的每个用户都有一个用户名，后缀是您为组织选择的@“域”，并且“用户名” @“域”的组合必须是有效的可交付给电子邮件地址。因此，该域应该是您可以添加DNS TXT记录以进行所有权验证的现有电子邮件域，也可以是可以设置为现有电子邮件系统中的别名的任何域。如果您的用户已经在域中为其自己的电子邮件设置了自己的google ID，则现有域可能会导致google中的用户ID重叠。一旦在单位中设置了他们，他们可能需要删除这些ID。
了解有关为组织指定和保护创建者/管理员帐户的最佳做法（在开始创建GCP帐户和组织之前）。在组织中，您可以创建用户并分配GCP范围内的访问角色，而在没有组织的情况下，只有项目范围内的角色可以使用。换句话说，需要组织来允许多个用户创建项目。无需在组织中设置具有按项目访问权限的顾问-可以使用现有的Google ID将他们添加到单个项目中，并获得适当的权限（如果您不太关心他们如何保护/共享）参与之外的用户ID）。扩大规模时，当然可以创建和管理特定的组织范围内的角色。