Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Administración de identidades y control de acceso para la transición a una arquitectura de varias cuentas
El primer paso al realizar la transición a una arquitectura de varias cuentas consiste en configurar la nueva estructura de cuentas dentro de una organización. A continuación, puede agregar usuarios y configurar el acceso a las cuentas. En esta sección, se describen los enfoques para administrar el acceso humano a varias Cuentas de AWS.
**Topics**
+ [Configuración de una organización](set-up-organization.md)
+ [Crear una zona de aterrizaje](create-landing-zone.md)
+ [Agregar unidades organizativas](add-organizational-units.md)
+ [Agregar usuarios iniciales](add-initial-users.md)
+ [Administrar las cuentas miembro](manage-member-accounts.md)
# Configuración de una organización
Cuando tiene varias Cuentas de AWS, puede administrar esas cuentas de forma lógica a través de una organización en [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). Una *cuenta* en AWS Organizations es un estándar Cuenta de AWS que contiene tus AWS recursos y las identidades que pueden acceder a esos recursos. Una *organización* es una entidad que los consolida Cuentas de AWS para que pueda administrarlos como una sola unidad.
Si utiliza una cuenta para crear una organización, esa cuenta se convierte en *cuenta de administración* (también conocida como *cuenta de pagador* o *cuenta raíz*) para la organización. Una organización solo puede tener una cuenta de administración. Al añadir más Cuentas de AWS a la organización, se convierten en *cuentas de miembros*.
**nota**
Cada una de ellas Cuenta de AWS también tiene una identidad única llamada *usuario raíz*. Puede iniciar sesión como usuario raíz mediante la dirección de correo electrónico y contraseña que usó al crear la cuenta. Sin embargo, se recomienda encarecidamente no utilizar el usuario raíz para las tareas cotidianas, ni siquiera para las tareas administrativas. Para obtener más información, consulte [Usuario raíz de Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html).
También recomendamos [centralizar el acceso raíz de las cuentas de los miembros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) y eliminar las credenciales de los usuarios raíz de las cuentas de los miembros de la organización.
Las cuentas se organizan en una estructura jerárquica similar a un árbol que consta de la raíz de la organización, las unidades organizativas (OUs) y las cuentas de los miembros. La *raíz* es el contenedor principal de todas las cuentas de su organización. Una *unidad organizativa* (OU) es un contenedor para [cuentas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) dentro de la [raíz](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root). Una OU puede contener otras cuentas OUs o cuentas de miembros. Una unidad organizativa puede tener un solo contenedor principal y cada cuenta puede ser miembro de una sola unidad organizativa. Para obtener más información, consulte [Terminología y conceptos](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentación).
Una [política de control de servicios (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) especifica los servicios y las acciones que pueden utilizar los usuarios y los roles. SCPs son similares a las políticas de permisos AWS Identity and Access Management (IAM), con la salvedad de que no conceden permisos. En su lugar, SCPs defina los permisos máximos. Cuando adjuntas una política a uno de los nodos de la jerarquía, se aplica a todas las cuentas OUs y de ese nodo. Por ejemplo, si aplica una política a la raíz, se aplica a todas las [cuentas [OUs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account)y de la organización, y si aplica una política a una OU, solo se aplica a las cuentas OUs y de la OU de destino.
Una [política de control de recursos (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) ofrece un control central sobre los permisos máximos disponibles para los recursos de la organización. RCPs le ayudan a garantizar que los recursos de su cuenta se ajusten a las directrices de control de acceso de su organización.
Puede usar la AWS Organizations consola para ver y administrar de forma centralizada todas las cuentas de una organización. Una de las ventajas de utilizar una organización es que puede recibir una factura unificada que muestra todos los cargos asociados a las cuentas miembro y de administración. Para obtener más información, consulte [Facturación unificada](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) (AWS Organizations documentación).
## Prácticas recomendadas
+ No utilices una existente Cuenta de AWS para crear una organización. Comience con una cuenta nueva, que pasará a ser la cuenta de administración de la organización. Las operaciones privilegiadas se pueden realizar dentro de la cuenta de administración de una organización SCPs y RCPs no se aplican a la cuenta de administración. Por eso, debe limitar los recursos y datos de la nube que contenga la cuenta de administración únicamente a los que deben administrarse en esta cuenta.
+ Limite el acceso a la cuenta de administración únicamente a las personas que necesiten aprovisionar una nueva organización Cuentas de AWS y administrarla.
+ Se utiliza SCPs para definir los permisos máximos para la cuenta raíz, las unidades organizativas y las cuentas de los miembros. SCPs no se puede aplicar directamente a la cuenta de administración.
+ Se utiliza RCPs para definir los permisos máximos para los recursos en las cuentas de los miembros. RCPsno se puede aplicar directamente a la cuenta de administración.
+ Siga las [mejores prácticas para AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html) (AWS Organizations documentación).
# Crear una zona de aterrizaje
Una *landing zone* es un AWS entorno multicuenta bien diseñado que constituye un punto de partida desde el que se pueden implementar cargas de trabajo y aplicaciones. Ofrece una base de referencia para empezar con la arquitectura de varias cuentas, la administración de identidades y accesos, la gobernanza, la seguridad de los datos, el diseño de redes y el registro. [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) es un servicio que simplifica el mantenimiento y la gobernanza de un entorno de varias cuentas, ya que brinda barreras de protección automatizadas. Normalmente, aprovisionas una única AWS Control Tower landing zone que gestiona tu entorno en todas partes Regiones de AWS. AWS Control Tower funciona organizando otras funciones Servicios de AWS dentro de su cuenta. Para obtener más información, consulta [Qué ocurre al configurar una landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup) (AWS Control Tower documentación).
Cuando configuras una landing zone con AWS Control Tower, identificas tres cuentas compartidas: la cuenta de administración, la cuenta de archivo de registros y la cuenta de auditoría. Para obtener más información, consulte [Qué son las cuentas compartidas](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared) (AWS Control Tower documentación). Para la cuenta de administración, debe usar una cuenta existente que no aloje ninguna carga de trabajo para configurar la zona de aterrizaje. En el caso del archivo de registros y de las cuentas de auditoría Cuentas de AWS, puede optar por reutilizar las existentes o AWS Control Tower crearlas automáticamente.
Para obtener instrucciones sobre cómo configurar tu AWS Control Tower landing zone, consulta [Cómo empezar](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) (AWS Control Tower documentación).
## Prácticas recomendadas
+ Siga las prácticas recomendadas de [los principios de diseño para su estrategia de cuentas múltiples](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html) (AWS documento técnico).
+ Siga las [prácticas recomendadas para AWS Control Tower administradores](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html) (AWS Control Tower documentación).
+ Crea tu landing zone en la Región de AWS que se alojan la mayoría de tus cargas de trabajo.
**importante**
Si decides cambiar esta región después de desplegar tu zona de aterrizaje, necesitas la ayuda de AWS Support y debes desmantelar la zona de aterrizaje. No se recomienda esta práctica.
+ Al determinar qué regiones AWS Control Tower regirán, seleccione solo las regiones en las que espera implementar cargas de trabajo de forma inmediata. Puede cambiar estas regiones o agregar otras más adelante. Si AWS Control Tower gobierna una región, desplegará sus barandillas de detección en esa región como tal. [Reglas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ Tras determinar qué regiones AWS Control Tower gobernarán, deniegue el acceso a todas las regiones no gobernadas. De esta forma, se garantiza que sus cargas de trabajo y los desarrolladores solo puedan utilizar las Regiones de AWS aprobadas. Esto se implementa como una política de control de servicio (SCP) en la organización. Para obtener más información, consulte [Configurar el control de Región de AWS denegación](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) (AWS Control Tower documentación).
+ Al configurar tu landing zone en AWS Control Tower, te recomendamos que cambies el nombre de las siguientes cuentas OUs y de las siguientes:
+ Se recomienda que cambie el nombre de la unidad organizativa **Seguridad** a **Security\$1Prod** para indicar que esta OU se utilizará para las Cuentas de AWS de producción relacionadas con la seguridad.
+ **Se recomienda permitir la creación de una unidad organizativa adicional y, AWS Control Tower a continuación, cambiarle el nombre de **Sandbox** a Workloads.** En la siguiente sección, creará una unidad organizativa adicional OUs dentro de la unidad organizativa **Workloads**, que utilizará para organizar la suya. Cuentas de AWS
+ Le recomendamos que cambie el nombre del registro centralizado Cuenta de AWS de **Log Archive** a. **log-archive-prod**
+ Se recomienda cambiar el nombre de la cuenta de auditoría de **Audit** a. **security-tooling-prod**
+ Para ayudar a prevenir el fraude, es AWS necesario Cuentas de AWS tener un historial de uso antes de que puedan añadirse a una AWS Control Tower landing zone. Si utilizas una nueva Cuenta de AWS sin historial de uso, en la nueva cuenta puedes lanzar una instancia de Amazon Elastic Compute Cloud (Amazon EC2) que no esté en AWS la capa gratuita. Deje que la instancia se ejecute durante unos minutos y, a continuación, ciérrela.
# Agregar unidades organizativas
Establecer la estructura organizativa adecuada es fundamental para configurar un entorno de varias cuentas. Como utiliza políticas de control de servicios (SCPs) para definir los permisos máximos para una unidad organizativa y las cuentas que contiene, la estructura de su organización debe ser lógica desde el punto de vista de la administración, los permisos y los informes financieros. Para obtener más información sobre la estructura de una organización, incluidas las unidades organizativas (OUs), consulte [Terminología y conceptos](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentación).
En esta sección, personalizas la landing zone mediante la creación de entornos anidados OUs que te ayuden a segmentar y estructurar tus entornos, como los de producción y los de no producción. Estas prácticas recomendadas están diseñadas para segmentar la zona de aterrizaje y así separar los recursos de producción y los que no son de producción y, también, para separar la infraestructura de las cargas de trabajo.
Para obtener más información sobre cómo crear OUs, consulta [Administrar unidades organizativas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (AWS Organizations documentación).
## Prácticas recomendadas
+ Dentro de la unidad organizativa de **cargas** de trabajo en la que creó[Crear una zona de aterrizaje](create-landing-zone.md), cree lo siguiente OUs anidado:
+ **Prod**: utilice esta OU para las Cuentas de AWS que almacenan y acceden a los datos de producción, incluidos los datos de los clientes.
+ **NonProd**— Utilice esta OU para almacenar datos Cuentas de AWS que no sean de producción, como entornos de desarrollo, puesta en escena o pruebas
En la raíz de la organización, cree una OU **Infrastructure\$1Prod**. Utilice esta OU para alojar una cuenta de red centralizada.
# Agregar usuarios iniciales
Existen dos formas de conceder a las personas el acceso a las Cuentas de AWS:
+ Identidades de IAM, como usuarios, grupos y roles
+ Federación de identidades, por ejemplo, mediante el uso AWS IAM Identity Center
En las empresas más pequeñas y en los entornos de una única cuenta, es habitual que los administradores creen un usuario de IAM cuando una nueva persona se incorpora a la empresa. Las credenciales de clave de acceso y clave secreta asociadas a un usuario de IAM se conocen como *credenciales de larga duración* porque no caducan. Sin embargo, esta no es una práctica de seguridad recomendada, ya que si un atacante pone en peligro esas credenciales, entonces se deberá que generar un nuevo conjunto de credenciales para el usuario. Otro enfoque para acceder Cuentas de AWS es a través de las [funciones de IAM](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/). También puede usar [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) para solicitar temporalmente *credenciales de corto plazo*, que caducan tras un periodo configurable.
Puedes gestionar el acceso de las personas a tu cuenta a Cuentas de AWS través del Centro de [Identidad de IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). Puede crear cuentas de usuario individuales para cada uno de sus empleados o contratistas, que pueden administrar sus propias contraseñas y soluciones de autenticación multifactor (MFA), y puede agruparlas para administrar el acceso. Al configurar la MFA, puede usar tokens de software, como aplicaciones de autenticación, o puede usar tokens de hardware, como dispositivos. YubiKey
El IAM Identity Center también admite la federación de proveedores de identidad externos (IdPs), JumpCloud como Okta y Ping Identity. Para obtener más información, consulte [Proveedores de identidades compatibles](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) (documentación de IAM Identity Center). Al federarse con un IdP externo, puede gestionar la autenticación de los usuarios en todas las aplicaciones y, a continuación, utilizar el Centro de identidades de IAM para autorizar el acceso a determinadas aplicaciones. Cuentas de AWS
## Prácticas recomendadas
+ Siga las [prácticas recomendadas de seguridad](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (documentación de IAM) para configurar el acceso de los usuarios.
+ Administre el acceso a las cuentas por grupos en lugar de por usuarios individuales. En IAM Identity Center, cree nuevos grupos que representen cada una de sus funciones empresariales. Por ejemplo, puede crear grupos para ingeniería, finanzas, ventas y administración de productos.
+ A veces, los grupos se definen separando a aquellos que necesitan acceso a todas las Cuentas de AWS (a menudo acceso de solo lectura) y aquellos que necesitan acceso a una única Cuenta de AWS. Le recomendamos que utilice la siguiente convención de nomenclatura para los grupos, de modo que resulte fácil identificar el grupo Cuenta de AWS y los permisos asociados a él.
`--`
+ Por ejemplo, para el grupo `AWS-A-dev-nonprod-DeveloperAccess`, `AWS-A` es un prefijo que indica el acceso a una única cuenta, `dev-nonprod` es el nombre de la cuenta y `DeveloperAccess` es el conjunto de permisos asignado al grupo. Para el grupo `AWS-O-BillingAccess`, el prefijo `AWS-O` indica el acceso a toda la organización y `BillingAccess` indica el conjunto de permisos para el grupo. En este ejemplo, dado que el grupo tiene acceso a toda la organización, el nombre del grupo no representa el nombre de una cuenta.
+ Si utiliza IAM Identity Center con un IdP externo basado en SAML y desea requerir MFA, puede usar el control de acceso basado en atributos (ABAC) para pasar el método de autenticación del IdP a IAM Identity Center. Los atributos se envían mediante las aserciones de SAML. Para obtener más información, consulte [Habilitar y configurar los atributos para el control de acceso](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) (documentación de IAM Identity Center).
Muchos IdPs, como Microsoft Azure Active Directory y Okta, pueden usar la afirmación Authentication Method Reference (`amr`) dentro de una afirmación SAML para pasar el estado de MFA del usuario al IAM Identity Center. La reclamación utilizada para afirmar el estado de MFA y su formato varían según el IdP. Para obtener más información, consulte la documentación de su IdP.
A continuación, en el Centro de identidades de IAM, puede crear políticas de conjuntos de permisos que determinen quién puede acceder a sus recursos. AWS Cuando habilita ABAC y especifica atributos, IAM Identity Center transfiere los valores de atributo del usuario autenticado a IAM para utilizarlos en la evaluación de políticas. Para obtener más información, consulte [Crear políticas de permisos para ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html) (documentación de IAM Identity Center). Como se muestra en el siguiente ejemplo, se utiliza la clave de condición de `aws:PrincipalTag` para crear una regla de control de acceso para la MFA.
```
"Condition": {
"StringLike": { "aws:PrincipalTag/amr": "mfa" }
}
```
# Administrar las cuentas miembro
En esta sección, usted invita a su cuenta preexistente a la organización y comienza a crear nuevas cuentas en la organización. Una parte importante de este proceso consiste en definir los criterios que se utilizan para determinar si es necesario aprovisionar una cuenta nueva.
**Topics**
+ [Invitación a su cuenta preexistente](#invite-account)
+ [Personalice la configuración de VPC en AWS Control Tower](#customize-vpc-settings)
+ [Configuración de los criterios de alcance](#define-scoping-criteria)
## Invitación a su cuenta preexistente
Desde AWS Organizations allí, puede invitar a la cuenta preexistente de su empresa a su nueva organización. Solo la cuenta de administración de la organización puede invitar a otras cuentas a unirse. En el momento en que el administrador de la cuenta miembro acepta, la cuenta se une inmediatamente a la organización y la cuenta de administración de la organización se hace responsable de todos los cargos acumulados por la nueva cuenta miembro. Para obtener más información, consulte [Invitar a una Cuenta de AWS para unirse a su organización](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) y [Aceptar o rechazar una invitación de una organización](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite) (documentación de AWS Organizations ).
**nota**
Puede invitar a una cuenta a unirse a una organización solo si esa cuenta no está actualmente en otra organización. Si la cuenta es miembro de una organización existente, debe eliminarla de la organización. Si la cuenta es la cuenta de administración de otra organización que se creó por error, debe eliminar la organización.
**importante**
Si necesitas acceder a cualquier información histórica de costes o uso de tu cuenta preexistente, puedes utilizarla AWS Cost and Usage Report para exportar esa información a un bucket de Amazon Simple Storage Service (Amazon S3). Haga esto antes de aceptar la invitación para unirse a la organización. Cuando una cuenta se une a una organización, se pierde el acceso a estos datos históricos de la cuenta. Para obtener más información, consulte [Configuración de un bucket de Amazon S3 para los informes de costo y uso](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html) (documentación de AWS Cost and Usage Report ).
*Prácticas recomendadas*
+ Se recomienda que agregue su cuenta preexistente, que probablemente contenga cargas de trabajo de producción, a la unidad organizativa **Cargas de trabajo** > **Prod** que creó en [Agregar unidades organizativas](add-organizational-units.md).
+ De forma predeterminada, la cuenta de administración de la organización no tiene acceso administrativo a las cuentas miembro que están invitadas a la organización. Si desea que la cuenta de administración tenga el control administrativo, debe crear el rol de **OrganizationAccountAccessRole**IAM en la cuenta del miembro y conceder permiso a la cuenta de administración para que asuma el rol. Para obtener más información, consulte [Crear la cuenta OrganizationAccountAccessRole en un miembro invitado](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role) (AWS Organizations documentación).
+ Para la cuenta preexistente que has invitado a la organización, consulta [las prácticas recomendadas para las cuentas de miembros](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) (AWS Organizations documentación) y confirma que la cuenta sigue estas recomendaciones.
## Personalice la configuración de VPC en AWS Control Tower
Le recomendamos que aprovisione nuevos Cuentas de AWS a través de [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) en AWS Control Tower. Al usar Account Factory, puedes usar la AWS Control Tower integración con Amazon EventBridge para aprovisionar recursos en nuevos tan pronto Cuentas de AWS como se cree la cuenta.
Al configurar una nueva Cuenta de AWS, se aprovisiona automáticamente una [nube privada virtual (VPC) predeterminada](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html). Sin embargo, cuando configura una cuenta nueva a través de Fábrica de cuentas, AWS Control Tower aprovisiona automáticamente una VPC adicional. Para obtener más información, consulte [Descripción general de AWS Control Tower y VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html) (AWS Control Tower documentación). Esto significa que, de forma predeterminada, AWS Control Tower las provisiones son dos por defecto VPCs en cada cuenta nueva.
Es habitual que las empresas quieran tener más control sobre el contenido VPCs de sus cuentas. Muchos prefieren usar otros servicios AWS CloudFormation, como Hashicorp Terraform o Pulumi, para configurar y administrar sus propios servicios. VPCs Debe personalizar la configuración de Fábrica de cuentas para evitar la creación de la VPC adicional aprovisionada por AWS Control Tower. Para obtener instrucciones, consulte [Configurar los ajustes de Amazon VPC](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html) (AWS Control Tower documentación) y aplique los siguientes ajustes:
1. Deshabilite la opción **Subred accesible a Internet**.
1. En **Número de subredes privadas**, elija **0**.
1. En **Regiones para la creación de VPC**, borre todas las regiones.
1. En **Zonas de disponibilidad**, elija **3**.
*Prácticas recomendadas*
+ Elimine la VPC predeterminada que se aprovisiona automáticamente en cada cuenta nueva. Esto impide que los usuarios lancen instancias de EC2 públicas en la cuenta sin crear explícitamente una VPC dedicada. Para obtener más información, consulte [Eliminar las subredes predeterminadas y la VPC predeterminada](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc) (documentación de Amazon Virtual Private Cloud). También puede configurar [Fábrica de cuentas de AWS Control Tower para Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) (AFT) para eliminar automáticamente la VPC predeterminada en las cuentas recién creadas.
+ **Aprovisione una nueva unidad Cuenta de AWS denominada **dev-nonprod** en la unidad organizativa Workloads >. **NonProd**** Utilice esta cuenta para su entorno de desarrollo. Para obtener instrucciones, consulte [Aprovisionar cuentas de Account Factory con AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html) (AWS Control Tower documentación).
## Configuración de los criterios de alcance
Debe seleccionar los criterios que utilizará su empresa a la hora de decidir si aprovisionar una nueva Cuenta de AWS. Puede decidir aprovisionar cuentas para cada unidad de negocio o aprovisionar cuentas en función del entorno, como la producción, las pruebas o el control de calidad. Cada empresa tiene sus propios requisitos en cuanto a su Cuentas de AWS tamaño o tamaño. Por lo general, usted evalúa los tres factores siguientes al decidir el tamaño de sus cuentas:
+ **Equilibrar las cuotas** de *servicio: las cuotas* de servicio son los valores máximos de la cantidad de recursos, acciones y elementos para cada uno de ellos Servicio de AWS dentro de una Cuenta de AWS. Si muchas cargas de trabajo comparten la misma cuenta y una carga de trabajo consume la mayor parte o la totalidad de una cuota de servicio, eso podría afectar de manera negativa a otra carga de trabajo de la misma cuenta. Si es así, es posible que tenga que separar esas cargas de trabajo en cuentas diferentes. Para obtener más información, consulte [Cuotas de Servicio de AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) (Referencia general de AWS).
+ **Informes de costos**: aislar las cargas de trabajo en cuentas separadas le permite ver los costos a nivel de cuenta en los informes de costos y uso. Cuando utiliza la misma cuenta para varias cargas de trabajo, puede usar etiquetas para que lo ayuden a administrar e identificar los recursos. Para obtener más información sobre el etiquetado, consulte [Etiquetar AWS recursos](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) ()Referencia general de AWS.
+ **Control de acceso**: cuando las cargas de trabajo comparten una cuenta, debe tener en cuenta cómo va a configurar las políticas de IAM para limitar el acceso a los recursos de la cuenta, de modo que los usuarios no tengan acceso a las cargas de trabajo que no necesitan. Como alternativa, puede utilizar varias cuentas y [conjuntos de permisos](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) en IAM Identity Center para administrar el acceso a las cuentas individuales.
*Prácticas recomendadas*
+ Sigue las mejores prácticas de la [estrategia AWS multicuenta para tu AWS Control Tower landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) (AWS Control Tower documentación).
+ Establezca una estrategia de etiquetado eficaz que lo ayude a identificar y administrar los recursos de AWS . Utilice etiquetas para clasificar los recursos según su finalidad, unidad de negocio, entorno u otro criterio. Para obtener más información, consulte [Prácticas recomendadas de etiquetado](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices) (Referencia general de AWS documentación).
+ No sobrecargue una cuenta con demasiadas cargas de trabajo. Si la demanda de la carga de trabajo supera una cuota de servicio, esto puede provocar problemas de rendimiento. Puede separar las cargas de trabajo de la competencia en diferentes Cuentas de AWS o solicitar un aumento de la cuota de servicio. Para obtener más información, consulte [Solicitar un aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (documentación de Service Quotas).