Amazon SAP-C02: Complejidad Organizacional y Estrategia de Múltiples Cuentas — Guía de estudio
Forma parte de la AWS Solutions Architect Professional SAP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.
Estrategia de múltiples cuentas y distribución de cuentas (account vending)
Una estrategia de múltiples cuentas comienza con una clara separación de responsabilidades: seguridad y auditoría, redes compartidas, cargas de trabajo de producción y cuentas de sandbox o para desarrolladores. El uso de AWS Organizations, ya sea con AWS Control Tower o con una landing zone personalizada, impone esta separación desde el primer día. El Account Factory de Control Tower proporciona un patrón de distribución de cuentas (account vending) que automatiza la creación de cuentas, los roles de IAM base, las plantillas de VPC y los guardrails, mientras que una landing zone personalizada construida con CloudFormation/CDK y Service Catalog ofrece más flexibilidad para redes y gobernanza a medida. La principal disyuntiva es la sobrecarga operativa frente a la reducción del radio de impacto (blast radius): más cuentas aumentan la superficie de gestión (automatización, roles entre cuentas, visibilidad de la facturación), pero limitan la exposición a la compromisión de un dominio y simplifican el cumplimiento normativo por cuenta. Las decisiones de red —compartir VPC con AWS Resource Access Manager, un modelo hub-and-spoke con Transit Gateway o VPCs aisladas con VPC peering— conllevan disyuntivas de costo y latencia. Los servicios compartidos (DNS, NAT, Active Directory) suelen residir en una cuenta de redes o de servicios compartidos; la distribución de cuentas debería adjuntar automáticamente las nuevas cuentas a estos recursos compartidos o aprovisionar VPCs delegadas. Planifique las cuotas y la automatización: centralice las canalizaciones (pipelines) para los artefactos base, de modo que el escalado de cuentas no multiplique el trabajo manual.
Gobernanza: SCPs, guardrails de Control Tower y políticas organizacionales
La gobernanza en un entorno de AWS con múltiples cuentas depende de la aplicación de políticas a nivel de la organización y de controles delegados en tiempo de ejecución. Las Políticas de Control de Servicios (SCPs) establecen el límite máximo para las acciones permitidas en todas las cuentas; son potentes pero implacables: las reglas de denegación (deny) en la OU raíz impiden incluso a los administradores crear roles vinculados a servicios o utilizar servicios a menos que se permitan explícitamente. Control Tower ofrece guardrails predefinidos (obligatorios, muy recomendados, electivos) que implementan SCPs y reglas de Config comunes, pero puede ser restrictivo para patrones de servicio avanzados. La decisión de diseño se centra en la gobernanza centralizada frente a la delegada: una lista de denegación (deny-list) estricta a nivel raíz maximiza el cumplimiento normativo, pero aumenta la fricción para los equipos de producto y la automatización, mientras que las líneas base permisivas con límites de permisos (permission boundaries) y controles de roles de IAM permiten una mayor velocidad para los desarrolladores. Las políticas de registro y auditoría (CloudTrail de la organización, agregador de AWS Config, administradores delegados de Security Hub y GuardDuty) deben aplicarse desde la cuenta de gestión para garantizar pistas de auditoría inmutables. Un enfoque pragmático es la gobernanza por capas: SCPs de la organización para restricciones de alto impacto, límites de permisos (permission boundaries) para el alcance de los desarrolladores y guardrails automatizados aplicados por el CI/CD de la landing zone para mantener la consistencia sin bloqueos manuales.
Límites de seguridad: roles entre cuentas, KMS y políticas de recursos
El acceso entre cuentas (cross-account) es un patrón fundamental y debe implementarse con el mínimo privilegio y con fuertes controles de confianza. El patrón común delega el acceso a través de roles de IAM en cada cuenta que entidades principales de confianza asumen con STS: los roles para despliegues de CICD, monitorización (CloudWatch/SSM) e integraciones de terceros deberían requerir MFA cuando sea apropiado y usar IDs externos para el acceso de socios. Las políticas basadas en recursos en buckets de S3, colas de SQS y claves de KMS permiten el acceso directo entre cuentas, pero KMS añade complejidad: la política de una clave de KMS debe permitir explícitamente a las entidades principales y servicios de la cuenta que confía, y pueden ser necesarios grants o grants-with-constraints para el acceso temporal. Usar una clave de KMS centralizada en la cuenta de registro o de seguridad simplifica el cifrado centralizado, pero crea un acoplamiento operativo y posibles consideraciones de disponibilidad; las claves por cuenta reducen el radio de impacto (blast radius), pero multiplican la rotación de claves y la gestión de grants. Algunas trampas comunes incluyen SCPs que deniegan inadvertidamente la creación de claves de KMS o de roles vinculados a servicios, políticas de bucket que entran en conflicto con las SCPs y olvidar añadir el rol de delegación a Config/CloudTrail en la cuenta colectora. Las decisiones de diseño deben sopesar la simplicidad administrativa, el mínimo privilegio y la latencia entre cuentas.
Todos los dominios · Redes y Conectividad Híbrida →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →