As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Gerenciamento de identidade e controle de acesso para transição para uma arquitetura de várias contas
A primeira etapa ao fazer a transição para uma arquitetura de várias contas é configurar sua nova estrutura de contas dentro de uma organização. Em seguida, você poderá adicionar usuários e configurar o acesso às contas. Esta seção descreve abordagens para gerenciar o acesso humano em vários Contas da AWS.
**Topics**
+ [Configurar uma organização](set-up-organization.md)
+ [Criar uma zona de pouso](create-landing-zone.md)
+ [Adicionar unidades organizacionais](add-organizational-units.md)
+ [Adicionar usuários iniciais](add-initial-users.md)
+ [Gerenciar contas-membro](manage-member-accounts.md)
# Configurar uma organização
Quando você tem várias Contas da AWS, você pode gerenciar logicamente essas contas por meio de uma organização em [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). Uma *conta* em AWS Organizations é um padrão Conta da AWS que contém seus AWS recursos e as identidades que podem acessar esses recursos. Uma *organização* é uma entidade que consolida suas Contas da AWS para que você possa administrá-las como uma única unidade.
Quando você usa uma conta para criar uma organização, essa conta se torna a *conta de gerenciamento* (também conhecida como *conta pagante* ou *conta raiz*) para a organização. Uma organização só pode ter uma conta de gerenciamento. Quando você adiciona mais Contas da AWS à organização, elas se tornam *contas de membros*.
**nota**
Cada um Conta da AWS também tem uma única identidade chamada *usuário root*. É possível fazer login como usuário raiz usando o endereço de e-mail e a senha usados para criar a conta. No entanto, recomendamos não usar o usuário raiz para suas tarefas diárias, nem mesmo as administrativas. Para obter mais informações, consulte [usuário raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html).
Também recomendamos [centralizar o acesso root às contas dos membros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) e remover as credenciais do usuário root das contas dos membros em sua organização.
Você organiza as contas em uma estrutura hierárquica em forma de árvore que consiste na raiz da organização, nas unidades organizacionais (OUs) e nas contas dos membros. A *raiz* é o contêiner pai de todas as contas da sua organização. Uma *unidade organizacional* (OU) é um contêiner para [contas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) dentro da [raiz](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root). Uma OU pode conter outras contas OUs ou contas de membros. Uma OU pode ter apenas um pai, e cada conta pode ser um membro de apenas uma OU. Para obter mais informações, consulte [Terminologia e conceitos](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentação).
Uma [política de controle de serviços (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) especifica os serviços e ações que os usuários e as funções podem usar. SCPs são semelhantes às políticas de permissões AWS Identity and Access Management (IAM), exceto pelo fato de não concederem permissões. Em vez disso, SCPs defina as permissões máximas. Quando você anexa uma política a um dos nós na hierarquia, ela se aplica a todas as contas OUs e dentro desse nó. Por exemplo, se você aplicar uma política à raiz, ela se aplicará a todas as [OUs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit)[contas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) da organização e, se você aplicar uma política a uma OU, ela se aplicará somente às contas OUs e na OU de destino.
Uma [política de controle de recursos (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) oferece controle central sobre o máximo de permissões disponíveis para recursos em sua organização. RCPs ajudam você a garantir que os recursos em sua conta permaneçam dentro das diretrizes de controle de acesso da sua organização.
Você pode usar o AWS Organizations console para visualizar e gerenciar centralmente todas as suas contas em uma organização. Um dos benefícios de usar uma organização é que você pode receber uma fatura consolidada que mostra todas as cobranças associadas às contas de gerenciamento e contas-membro. Para obter mais informações, consulte [Faturamento consolidado](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) (AWS Organizations documentação).
## Práticas recomendadas
+ Não use um existente Conta da AWS para criar uma organização. Comece com uma nova conta, a qual se tornará sua conta de gerenciamento para a organização. As operações privilegiadas podem ser realizadas na conta de gerenciamento de uma organização SCPs e RCPs não se aplicam à conta de gerenciamento. É por isso que você deve limitar os recursos e dados da nuvem contidos na conta de gerenciamento somente àqueles que precisam ser gerenciados nessa conta.
+ Limite o acesso à conta de gerenciamento somente às pessoas que precisam provisionar novas contas Contas da AWS e administrar a organização.
+ Use SCPs para definir as permissões máximas para as contas raiz, unidades organizacionais e membros. SCPs não pode ser aplicado diretamente à conta de gerenciamento.
+ Use RCPs para definir as permissões máximas para recursos nas contas dos membros. RCPsnão pode ser aplicado diretamente à conta de gerenciamento.
+ Siga as [melhores práticas para AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html) (AWS Organizations documentação).
# Criar uma zona de pouso
Uma *landing zone* é um AWS ambiente de várias contas bem arquitetado que é um ponto de partida a partir do qual você pode implantar cargas de trabalho e aplicativos. Ele fornece uma linha de base para começar com arquitetura de várias contas, gerenciamento de identidade e acesso, governança, segurança de dados, design de rede e log. O [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) é um serviço que simplifica a manutenção e a governança de um ambiente com várias contas por meio do fornecimento grades de proteção automatizadas. Normalmente, você provisiona uma única AWS Control Tower landing zone que gerencia seu ambiente em todas as áreas Regiões da AWS. AWS Control Tower funciona orquestrando outras pessoas Serviços da AWS em sua conta. Para obter mais informações, consulte [O que acontece quando você configura uma landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup) (AWS Control Tower documentação).
Ao configurar uma landing zone com AWS Control Tower, você identifica três contas compartilhadas: a conta de gerenciamento, a conta de arquivamento de registros e a conta de auditoria. Para obter mais informações, consulte [O que são as contas compartilhadas](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared) (AWS Control Tower documentação). Para a conta de gerenciamento, você deve usar uma conta existente que não esteja hospedando nenhuma workload para configurar a zona de pouso. Para o arquivo de registros e as contas de auditoria, você pode optar por reutilizar Contas da AWS as existentes ou AWS Control Tower criá-las para você.
Para obter instruções sobre como configurar seu AWS Control Tower landing zone, consulte [Introdução](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) (AWS Control Tower documentação).
## Práticas recomendadas
+ Siga as melhores práticas nos [princípios de design para sua estratégia de várias contas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html) (AWS Whitepaper).
+ Siga as [melhores práticas para AWS Control Tower administradores](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html) (AWS Control Tower documentação).
+ Crie sua landing zone na Região da AWS que hospeda a maioria das suas cargas de trabalho.
**Importante**
Se você decidir mudar essa região depois de implantar sua zona de pouso, precisará da AWS Support ajuda e deverá descomissionar a zona de pouso. Esta prática não é recomendada.
+ Ao determinar quais regiões AWS Control Tower governarão, selecione somente as regiões nas quais você espera implantar cargas de trabalho imediatamente. É possível alterar essas regiões ou adicionar outras posteriormente. Se AWS Control Tower governar uma região, implantará suas grades de proteção de detetive nessa região como. [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ Depois de determinar quais regiões AWS Control Tower governarão, negue o acesso a todas as regiões não governadas. Isso ajuda a garantir que suas workloads e os desenvolvedores só possam usar as Regiões da AWS aprovadas. Isso é implementado como uma política de controle de serviços (SCP) na organização. Para obter mais informações, consulte [Configurar o controle de Região da AWS negação](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) (AWS Control Tower documentação).
+ Ao configurar sua landing zone em AWS Control Tower, recomendamos que você renomeie o seguinte OUs e as contas:
+ Recomendamos renomear a OU **Security** para **Security\$1Prod** para significar que essa OU será usada para Contas da AWS relacionadas à segurança da produção.
+ **Recomendamos que você permita AWS Control Tower criar uma OU adicional e depois renomeá-la de **Sandbox** para Workloads.** Na próxima seção, você cria mais OUs na UO **de cargas de trabalho**, que você usa para organizar sua Contas da AWS.
+ Recomendamos que você renomeie o registro centralizado Conta da AWS do **Log Archive** para. **log-archive-prod**
+ Recomendamos que você renomeie a conta de **auditoria de Auditoria** para **security-tooling-prod**.
+ Para ajudar a evitar fraudes, é AWS necessário Contas da AWS ter um histórico de uso antes de serem adicionados a um AWS Control Tower landing zone. Se você estiver usando uma nova Conta da AWS sem nenhum histórico de uso, na nova conta, você pode iniciar uma instância do Amazon Elastic Compute Cloud (Amazon EC2) que não esteja no nível gratuito. AWS Mantenha instância em execução por alguns minutos e, em seguida, encerre-a.
# Adicionar unidades organizacionais
Estabelecer a estrutura organizacional adequada é fundamental para configurar um ambiente com várias contas. Como você usa políticas de controle de serviço (SCPs) para definir as permissões máximas para uma OU e as contas dentro dela, sua estrutura organizacional deve ser lógica do ponto de vista de gerenciamento, permissões e relatórios financeiros. Para obter mais informações sobre a estrutura de uma organização, incluindo unidades organizacionais (OUs), consulte [Terminologia e conceitos](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentação).
Nesta seção, você personaliza o landing zone criando aninhados OUs que ajudam a segmentar e estruturar seus ambientes, como produção e não produção. Essas práticas recomendadas foram desenvolvidas para segmentar sua zona de pouso a fim de separar recursos de produção e não produção e separar a infraestrutura das workloads.
Para obter mais informações sobre como criar OUs, consulte [Gerenciamento de unidades organizacionais](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (AWS Organizations documentação).
## Práticas recomendadas
+ Na OU **de cargas de trabalho** que você criou[Criar uma zona de pouso](create-landing-zone.md), crie o seguinte OUs aninhado:
+ **Prod**: use essa OU para Contas da AWS que armazenam e acessam dados de produção, incluindo dados de clientes.
+ **NonProd**— Use essa OU para armazenar dados Contas da AWS que não sejam de produção, como ambientes de desenvolvimento, preparação ou teste
Na raiz da organização, crie uma OU **Infrastructure\$1Prod**. Use essa OU para hospedar uma conta de rede centralizada.
# Adicionar usuários iniciais
Há duas maneiras de conceder às pessoas acesso a Contas da AWS:
+ Identidades do IAM, como usuários, grupos e perfis
+ Federação de identidade, como usando Centro de Identidade do AWS IAM
Em empresas menores e ambientes de conta única, é comum que os administradores criem um usuário do IAM quando uma nova pessoa entra na empresa. As credenciais da chave de acesso e da chave secreta associadas a um usuário do IAM são conhecidas como *credenciais de longo prazo* porque elas não expiram. No entanto, essa não é uma prática de segurança recomendada, pois se um invasor comprometesse essas credenciais, seria necessário gerar um novo conjunto de credenciais para o usuário. Outra abordagem para acessar Contas da AWS é por meio de [funções do IAM](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/). Também é possível usar o [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)(AWS STS) para solicitar temporariamente *credenciais de curto prazo*, as quais expiram após um período de tempo configurável.
Você pode gerenciar o acesso das pessoas ao seu Contas da AWS por meio [do IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). Você pode criar contas de usuário individuais para cada um de seus funcionários ou contratados, eles podem gerenciar suas próprias senhas e soluções de autenticação multifator (MFA) e você pode agrupá-los para gerenciar o acesso. Ao configurar o MFA, você pode usar tokens de software, como aplicativos autenticadores, ou pode usar tokens de hardware, como dispositivos. YubiKey
O IAM Identity Center também oferece suporte à federação de provedores de identidade externos (IdPs) JumpCloud, como Okta e Ping Identity. Para obter mais informações, consulte [Provedores de identidade compatíveis](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) (documentação do IAM Identity Center). Ao federar com um IdP externo, você pode gerenciar a autenticação do usuário em todos os aplicativos e, em seguida, usar o IAM Identity Center para autorizar o acesso a determinados. Contas da AWS
## Práticas recomendadas
+ Siga as [Práticas recomendadas de segurança](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (documentação do IAM) para configurar o acesso de usuários.
+ Gerencie o acesso à conta por meio de grupos em vez de usuários individuais. No IAM Identity Center, crie novos grupos para representar cada uma das suas funções comerciais. Por exemplo, é possível criar grupos para engenharia, finanças, vendas e gerenciamento de produtos.
+ Muitas vezes, os grupos são definidos separando-se aqueles que precisam de acesso a todas as Contas da AWS (geralmente acesso somente leitura) e aqueles que precisam acessar uma única Conta da AWS. Recomendamos que você use a seguinte convenção de nomenclatura para grupos, para que seja fácil identificar Conta da AWS as permissões associadas ao grupo.
`--`
+ Por exemplo, para o grupo `AWS-A-dev-nonprod-DeveloperAccess`, `AWS-A` é um prefixo que indica acesso a uma única conta, `dev-nonprod` é o nome da conta e `DeveloperAccess` é o conjunto de permissões atribuído ao grupo. Para o grupo`AWS-O-BillingAccess`, o prefixo `AWS-O` indica acesso a toda a organização, enquanto `BillingAccess` indica o conjunto de permissões para o grupo. Neste exemplo, como o grupo tem acesso a toda a organização, o nome da conta não é representado no nome do grupo.
+ Se você estiver usando o IAM Identity Center com um IdP externo baseado em SAML e quiser exigir MFA, poderá usar o controle de acesso por atributo (ABAC) para passar o método de autenticação do IdP para o IAM Identity Center. Os atributos são enviados por meio de declarações SAML. Para obter mais informações, consulte [Habilitar e configurar atributos para controle de acesso](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)(documentação do IAM Identity Center).
Muitos IdPs, como o Microsoft Azure Active Directory e o Okta, podem usar a declaração Authentication Method Reference (`amr`) dentro de uma declaração SAML para passar o status de MFA do usuário para o IAM Identity Center. A reivindicação usada para declarar o status de MFA e seu formato variam de acordo com o IdP. Para obter mais informações, consulte a documentação do seu IdP.
No IAM Identity Center, você pode então criar políticas de conjunto de permissões que determinam quem pode acessar seus AWS recursos. Quando você habilita o ABAC e especifica atributos, o IAM Identity Center passa para o IAM o valor do atributo do usuário autenticado para uso na avaliação de políticas. Para obter mais informações, consulte [Criar políticas de permissão para o ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html) (documentação do IAM Identity Center). Conforme mostrado no exemplo a seguir, é possível usar a chave de condição `aws:PrincipalTag` para criar uma regra de controle de acesso para MFA.
```
"Condition": {
"StringLike": { "aws:PrincipalTag/amr": "mfa" }
}
```
# Gerenciar contas-membro
Nesta seção, você convidará sua conta pré-existente para a organização e começará a criar novas contas dentro da organização. Uma parte importante desse processo é definir os critérios usados para determinar se é necessário provisionar uma nova conta.
**Topics**
+ [Convidar sua conta pré-existente](#invite-account)
+ [Personalize as configurações de VPC em AWS Control Tower](#customize-vpc-settings)
+ [Definir os critérios de escopo](#define-scoping-criteria)
## Convidar sua conta pré-existente
Dentro AWS Organizations, você pode convidar a conta preexistente da sua empresa para sua nova organização. Somente a conta de gerenciamento da organização pode convidar outras contas para ingressar. Quando o administrador da conta convidada aceita o convite, a conta ingressa imediatamente na organização e a conta de gerenciamento da organização torna-se responsável por todas as cobranças geradas pela nova conta-membro. Para obter mais informações, consulte [Convidar uma Conta da AWS para se juntar à sua organização](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) e [Aceitar ou recusar um convite de uma organização](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite) (documentação do AWS Organizations ).
**nota**
Você poderá convidar uma conta para ingressar em uma organização somente se essa conta não estiver em outra organização. Se a conta for membro de uma organização existente, será necessário removê-la da organização. Se a conta for a conta de gerenciamento de uma organização diferente que foi criada por engano, será necessário excluir a organização.
**Importante**
Se precisar acessar qualquer informação histórica de custo ou uso da sua conta preexistente, você pode usá-la AWS Cost and Usage Report para exportar essas informações para um bucket do Amazon Simple Storage Service (Amazon S3). Faça isso antes de aceitar o convite para ingressar na organização. Quando uma conta ingressa em uma organização, o acesso a esses dados históricos da conta é perdido. Para obter mais informações, consulte [Configurar um bucket do Amazon S3 para relatórios de custo e uso](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html) (documentação do AWS Cost and Usage Report ).
*Práticas recomendadas*
+ Recomendamos adicionar sua conta preexistente, que provavelmente contém workloads de produção, à unidade organizacional **Workloads** > **Prod** criada em [Adicionar unidades organizacionais](add-organizational-units.md).
+ Por padrão, a conta de gerenciamento da organização não tem acesso administrativo às contas-membro que são convidadas para a organização. Se você quiser que a conta de gerenciamento tenha controle administrativo, você deve criar a função **OrganizationAccountAccessRole**do IAM na conta do membro e conceder permissão à conta de gerenciamento para assumir a função. Para obter mais informações, consulte [Criação do OrganizationAccountAccessRole em uma conta de membro convidado](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role) (AWS Organizations documentação).
+ Para a conta preexistente que você convidou para a organização, revise [as práticas recomendadas para contas de membros](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) (AWS Organizations documentação) e confirme se a conta segue essas recomendações.
## Personalize as configurações de VPC em AWS Control Tower
Recomendamos que você provisione novos Contas da AWS por meio do [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) em AWS Control Tower. Ao usar o Account Factory, você pode usar a AWS Control Tower integração com EventBridge a Amazon para provisionar novos recursos Contas da AWS assim que a conta for criada.
Quando você configura uma nova Conta da AWS[nuvem privada virtual (VPC) padrão](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) é provisionada automaticamente. No entanto, quando você configura uma nova conta via Account Factory, o AWS Control Tower provisiona automaticamente uma VPC adicional. Para obter mais informações, consulte [Visão geral de AWS Control Tower e VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html) (AWS Control Tower documentação). Isso significa que, por padrão, AWS Control Tower provisiona duas inadimplências VPCs em cada nova conta.
É comum que as empresas queiram ter mais controle VPCs sobre suas contas. Muitos preferem usar outros serviços AWS CloudFormation, como o Hashicorp Terraform ou o Pulumi, para configurar e gerenciar seus. VPCs Recomenda-se personalizar as configurações do Account Factory para evitar a criação da VPC adicional provisionada pelo AWS Control Tower. Para obter instruções, consulte [Definir as configurações da Amazon VPC](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html) (AWS Control Tower documentação) e aplique as seguintes configurações:
1. Desabilite a opção **Sub-rede acessível pela Internet**.
1. Em **Número de sub-redes privadas**, escolha **0**.
1. Em **Regiões para criação de VPC**, limpe todas as regiões.
1. Em **Zonas de disponibilidade**, escolha **3**.
*Práticas recomendadas*
+ Exclua a VPC padrão que é provisionada automaticamente em cada nova conta. Isso impede que os usuários iniciem instâncias públicas do EC2 na conta sem criar explicitamente uma VPC dedicada. Para obter mais informações, consulte [Excluir sub-redes e a VPC padrão](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc) (documentação da Amazon Virtual Private Cloud). Você também pode configurar o [AWS Control Tower Account Factory para Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) (AFT) para excluir automaticamente a VPC padrão em contas recém-criadas.
+ Provisione um novo Conta da AWS chamado **dev-nonprod** na unidade Cargas de **trabalho** > organizacional. **NonProd** Use essa conta para seu ambiente de desenvolvimento. Para obter instruções, consulte [Provision Account Factory accounts with AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html) (AWS Control Tower documentação).
## Definir os critérios de escopo
Você precisa selecionar os critérios que sua empresa usará ao decidir se deve provisionar um novo Conta da AWS. Você pode decidir provisionar contas para cada unidade de negócios ou optar por provisionar contas com base no ambiente, como produção, teste ou controle de qualidade. Cada empresa tem seus próprios requisitos de quão grande ou pequena ela Contas da AWS deve ser. Geralmente, você avalia os três fatores a seguir ao decidir como dimensionar suas contas:
+ **Equilibrando cotas** de *serviço — As cotas* de serviço são os valores máximos para o número de recursos, ações e itens de cada um AWS service (Serviço da AWS) dentro de um. Conta da AWS Se várias workloads compartilharem a mesma conta e uma workload estiver consumindo a maior parte ou toda a cota de serviços, isso poderá afetar negativamente outra workload na mesma conta. Nesse caso, talvez seja necessário separar essas workloads em contas diferentes. Para obter mais informações, consulte [Cotas do AWS service (Serviço da AWS)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) (Referência geral da AWS).
+ **Relatórios de custos**: isolar workloads em contas separadas permite que você veja os custos em nível de conta nos relatórios de custo e uso. Ao usar a mesma conta para várias workloads, é possível utilizar tags para obter ajuda para gerenciar e identificar recursos. Para obter mais informações sobre marcação, consulte [AWS Recursos de marcação](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) ()Referência geral da AWS.
+ **Controle de acesso**: quando as workloads compartilham uma conta, é necessário considerar como as políticas do IAM serão configuradas para limitar o acesso aos recursos da conta de forma que os usuários não tenham acesso a workloads de que não precisam. Como alternativa, é possível usar várias contas e [conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) no IAM Identity Center para gerenciar o acesso a contas individuais.
*Práticas recomendadas*
+ Siga as melhores práticas de [estratégia de AWS várias contas para sua AWS Control Tower landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) (AWS Control Tower documentação).
+ Estabeleça uma estratégia de marcação eficaz que ajude a identificar e gerenciar recursos da AWS . É possível usar tags para categorizar recursos por finalidade, unidade de negócios, ambiente ou outros critérios. Para obter mais informações, consulte [Melhores práticas para marcação](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices) (Referência geral da AWS documentação).
+ Não sobrecarregue uma conta com muitas workloads. Se a demanda da workload exceder uma cota de serviço, problemas de performance poderão ocorrer. Você pode separar as cargas de trabalho concorrentes em diferentes Contas da AWS ou solicitar um aumento na cota de serviço. Para obter mais informações, consulte [Solicitar um aumento de cota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (documentação do Service Quotas).