🎯 El punto de partida En varios kickoffs de Landing Zone enterprise en LATAM este año se repite el mismo patrón de inventario: unos 40 servidores físicos que nadie quiere tocar porque el que sabía renunció en 2022, un cluster VMware con 200 y algo de VMs, la mitad de las aplicaciones en Windows Server 2016 cerca del fin de soporte extendido, y un roadmap que menciona "adoptar IA generativa" sin ningún detalle adicional de arquitectura, modelo o gobierno. El requerimiento que acompaña ese inventario es siempre el mismo: empezar sin deuda técnica desde el diseño. El error más común frente a este escenario aparece también en Landing Zones que recibimos para corregir: tratar el diseño como un proyecto de migración a AWS. No lo es: es el diseño de la plataforma sobre la que ese cliente va a operar los próximos cinco a siete años, con cargas que hoy no existen, con modelos de IA que hoy no están anunciados, y con requerimientos regulatorios que también van a cambiar en ese lapso. La Ley 21.719 en Chile, que entra en vigencia en diciembre de 2026, ya ha llevado a revisar controles de datos en varios proyectos activos este año. Este post es el framework de decisiones estructurales que aplicamos antes de escribir la primera línea de Terraform — no un tutorial de Control Tower, sino la secuencia que define si esa Landing Zone sigue siendo la plataforma correcta en año tres. 📐 Por qué un blueprint de 2022 ya no alcanza como referencia única Un blueprint de Landing Zone publicado entre 2021 y 2023 arrastra tres asunciones que ya no sostienen. Trata la migración como un evento con fecha fin, cuando el legacy en estos escenarios coexiste tres o cuatro años como mínimo — hay cargas que no se van a mover nunca porque el vendor cerró y el runbook desapareció con el equipo que lo mantenía. No considera identidades no-humanas como ciudadanos de primera clase: agentes autónomos, flujos MCP y cargas de Bedrock invocadas por sistemas necesitan gobierno de identidad desde el diseño, no como retrofit. Y diseña para un SDLC clásico (Dev/QA/Prod) sin anticipar que una OU de experimentación con modelos tiene requisitos casi opuestos — más permisiva en algunos ejes, mucho más restrictiva en otros. A esto se suman dos cambios de los últimos doce meses que todavía no están incorporados en la mayoría de los diseños: AWS Transform pasó a GA para VMware en mayo de 2025 y sumó capacidades enterprise en diciembre; y las cuotas de SCP subieron de 5 a 10 por root, OU o cuenta, y de 5.120 a 10.240 caracteres por política. El segundo cambio parece un detalle operativo, pero habilita una estrategia de guardrails que hasta hace meses no era práctica — volvemos a esto en la decisión de guardrails. 🧩 Las 6 decisiones estructurales del framework 1. Modelo de OU con horizonte de plataforma, no de proyecto de migración Diseñar el modelo de OU en función de la migración en curso suele dejar categorías como "Legacy OU", "VMware OU" o "Transition OU" que pierden sentido una vez terminan las primeras waves. Estas OUs nacen con fecha de vencimiento y no se vencen nunca — hemos corregido Landing Zones con OUs "temporales" que llevaban tres años ahí, con cuentas productivas críticas dentro. El modelo que aplicamos parte de la asunción contraria: la Landing Zone es una plataforma, y las cuentas del legacy son ciudadanos permanentes, no visitantes. Estructura base: Root ├── Security OU (Audit, Log Archive) ├── Infrastructure OU (Network, Shared Services, DNS) ├── Workloads OU │ ├── Prod OU (independiente de dónde vino la carga) │ ├── PreProd OU │ └── NonProd OU (Dev, QA, sandbox de negocio) ├── AI OU │ ├── AI-Sandbox OU (experimentación con Bedrock y agentes) │ └── AI-Production OU (agentes en producción, guardrails estrictos) ├── Sandbox OU └── Suspended OU La AI OU separada no es cosmética. Los agentes tienen patrones de consumo, de red y de identidad tan distintos de una app clásica que tratarlos como "otra carga más" deriva en guardrails inaplicables para uno u otro lado — volvemos sobre esto en la decisión de guardrails. 2. AWS Transform como parte del diseño, no como herramienta paralela El patrón anterior separaba el diseño de la Landing Zone del discovery: el arquitecto trabajaba en paralelo con alguien que corría un inventario en herramientas de terceros o planillas, y los dos flujos se encontraban tarde, casi siempre contradiciéndose. AWS Transform integra el assessment al diseño. El discovery tool puede descubrir directamente entornos VMware vCenter y Hyper-V, e incorporar servidores físicos u otras fuentes mediante inventarios importados. AWS Transform procesa estos datos para identificar servidores, dependencias y agrupaciones de aplicaciones, y generar escenarios de assessment y TCO. En pruebas, AWS reportó la generación de migration wave plans para 500 VMs en 15 minutos, cifra que validamos con un discovery manual en paralelo. Ese output alimenta directamente el modelo de OU y el wave planning: define qué aplicaciones son candidatas a rehost puro, cuáles requieren refactor y cuáles no se mueven, y, a partir de esa clasificación, qué cuentas destino se necesitan y en qué OUs quedarán las cargas incluidas en cada migration wave. AWS Transform también genera configuraciones de red para topologías hub-and-spoke o isolated, con soporte de migración desde NSX, Palo Alto, FortiGate y Cisco ACI, IPAM incluido y despliegue a múltiples cuentas destino — la Landing Zone se despliega ya alineada con el wave planning, no como estructura genérica a adaptar después. Dato operativo relevante: las capacidades de assessment de AWS Transform están disponibles, al momento de escribir esto, en us-east-1, eu-central-1, Mumbai, Sydney, Tokyo, London, Seoul y Canada Central. Para clientes con residencia de datos exigente en LATAM, esto condiciona qué inventarios se pueden subir antes de tener claridad regulatoria. 3. Identity Center desde el primer día Implementar Identity Center después de desplegar Control Tower y comenzar la migración deja cuentas con IAM users de tránsito, roles cruzados sin federación y mecanismos de acceso que después hay que normalizar. En este diseño, las cuentas de workload operan sin IAM users desde el primer día. La secuencia que aplicamos es habilitar IAM Identity Center inmediatamente después de create-organization y antes de Control Tower; federar contra el IdP corporativo (Entra ID, Okta, Ping, según el cliente) antes de crear la primera cuenta hija; delegar la administración de IAM Identity Center a una member account dedicada, manteniendo la instancia en la management account; y versionar los permission sets en Git desde el primer commit, con revisión obligatoria. El punto que casi siempre se omite es preparar identidades no-humanas con el mismo rigor. Los agentes Bedrock y AgentCore requieren, según el patrón de identidad, OAuth on-behalf-of, credenciales gestionadas y trazabilidad end-to-end — diseñar esto en año 2, con agentes ya en producción, implica retrofit sobre un modelo de identidad que no lo contempló. 4. Guardrails de dos velocidades: legacy pide estabilidad, AI pide experimentación Los SCPs diseñados para proteger workloads legacy —restrictivos, extensos, y con Deny amplios— terminan bloqueando cualquier experimentación con Bedrock, KnowledgeBases o Agentes. El equipo de datos pide excepciones, las excepciones erosionan el modelo, y el resultado son huecos que nadie recuerda por qué están abiertos. El modelo de guardrails se define por OU desde el inicio: Workloads OU aplica SCPs estrictos sobre servicios permitidos, regiones autorizadas, tipos de instancia habilitados y controles de red exigentes; AI-Sandbox OU con SCPs permisivos sobre Bedrock, SageMaker y servicios asociados, pero con restricciones fuertes de red (sin salida a internet, acceso a servicios AWS solo vía VPC endpoints) y sin acceso a datos productivos; y AI-Production OU con SCPs que combinan lo estricto de Workloads con controles específicos de IA — restricciones sobre bedrock:InvokeModel, condiciones de aws:PrincipalOrgID, modelos autorizados, y trazabilidad configurada por separado vía CloudTrail y Bedrock model invocation logging. Las cuotas actualizadas en mayo de 2026 —10 SCP por root, OU o cuenta, y 10.240 caracteres por SCP— dan espacio real para expresar estos controles diferenciados sin comprimir todo en un mega-SCP inauditable. Un caso de referencia: un cliente aplicó un SCP con un Deny sobre support:* directamente sobre el root de la organización, sin probarlo primero sobre una OU controlada. El deny afectó a las member accounts y dejó al equipo sin capacidad de abrir casos desde ellas durante un fin de semana. La política tuvo que corregirse desde la management account. 5. Networking híbrido + AI-ready desde el día uno La topología de red es la decisión más costosa de revertir: un error acá implica meses de refactor y, con frecuencia, pérdida de credibilidad frente al cliente. El patrón que aplicamos combina conectividad híbrida para el legacy y networking AI-ready desde el diseño inicial. Para la conectividad híbrida: Direct Connect con dos ubicaciones físicas (redundancia real, no solo dos VIFs), BGP con BFD para detección rápida de fallas, VPN de backup con IPSec HA —desde noviembre de 2025, Site-to-Site VPN soporta hasta 5 Gbps por túnel (4x el límite anterior de 1.25 Gbps), lo que amplía los escenarios donde Site-to-Site VPN puede utilizarse como respaldo de conexiones Direct Connect de mayor capacidad—, y Transit Gateway como columna vertebral, con Transit Gateway route tables separadas para prod, preprod y nonprod desde el diseño. Para el networking AI-ready: PrivateLink endpoints para Bedrock en cada VPC de AI-Production, sin invocaciones por internet pública; AgentCore Gateway con VPC egress managed cuando aplica, y self-managed VPC Lattice cuando se necesita conectividad privada cross-account; Network Firewall stateful en el egress del hub, con reglas específicas para bloquear egress a modelos self-hosted o servicios de IA externos no autorizados; y DNS resolution híbrida con Route 53 Resolver endpoints, con resolución bidireccional entre on-premises y AWS desde el día uno. La conectividad de los agentes debe resolverse en el diseño inicial. Si el hub-spoke se despliega sin contemplar VPC Lattice y PrivateLink para Bedrock, incorporarlos cuando los agentes ya están en producción obliga a modificar componentes compartidos de red. 6. FinOps con unit economics separados por dominio Un cliente con legacy y AI opera dos economías distintas: la legacy, con costo operativo bajo escrutinio, presupuesto anual fijo y optimización sobre EC2, EBS y transferencia; la de AI, con presupuesto de innovación, mayor tolerancia al gasto exploratorio, pero necesidad crítica de atribuir cada dólar a un caso de uso concreto. Mezclar ambas vistas en el mismo Cost Explorer deriva en conflicto entre CFO y equipo de datos. La solución opera sobre cuatro ejes: tagging strategy desde el primer recurso (costcenter, businessunit, application, environment, data-classification, y para AI específicamente ai-usecase y model-family); Bedrock cost allocation por IAM principal en CUR 2.0 —disponible desde abril de 2026, habilita chargeback interno por equipo y no solo por cuenta—; prompt caching y batch inference como decisiones arquitectónicas —los modelos Claude con TTL de una hora aplican hasta 90% de descuento en tokens leídos desde caché frente al costo del input sin caché y, para los modelos compatibles, Bedrock Batch Inference puede costar un 50% menos que la inferencia On-Demand—; y CUR 2.0 con Data Exports y dashboards separados por dominio desde el primer mes de operación. Medir el costo por caso de uso no es opcional a esta escala: es lo que determina qué modelos y qué patrones sobreviven después del primer año. ⚓ Principios no negociables de diseño Frente a la pregunta de qué no se negocia en este tipo de proyecto, la respuesta es consistente en todos los engagements: la Landing Zone es una plataforma, no un proyecto de migración con fecha fin. De ahí se derivan tres decisiones que sostenemos incluso bajo presión del cliente: la Security OU es intocable —no se comparte con workloads, no se relaja para acelerar nada, Audit y Log Archive son cuentas de solo lectura salvo para el equipo de seguridad—; IaC desde el primer commit sin excepciones, con SCPs, permission sets, VPC endpoints y reglas de firewall en Terraform o CDK con peer review obligatorio, donde un cambio manual en consola es un incidente, no un atajo; e Identity Center como fuente única de identidad, con cero IAM users en cuentas de workload — cuando una integración legacy los requiere, vive en una cuenta de integración específica con controles adicionales. El resto se adapta al cliente. Estos tres, no. ❌ Antipatrones de arquitectura Diseñar la Landing Zone después del assessment técnico: el assessment y el diseño de plataforma son iterativos, no secuenciales — AWS Transform habilita justamente eso. Poner el legacy en una OU temporal "hasta que se migre todo": esa OU nunca se vacía, y el modelo organizacional termina desalineado dos años después. Postergar Identity Center para "cuando ya esté todo migrado": cada IAM user creado en el interín es un ancla que después cuesta remover. Guardrails uniformes para legacy y para AI: o son demasiado permisivos para legacy, o demasiado restrictivos para AI, o ambas cosas a la vez. Direct Connect con una sola ubicación física: no cumple los modelos High Resiliency o Maximum Resiliency de Direct Connect. FinOps activado en el mes 6: los recursos creados sin tagging estructurado desde el día uno quedan como huérfanos permanentes de costo. 🧠 Cuándo NO aplica este framework Este framework tiene overhead, y no siempre se justifica. Con menos de 10 cuentas planificadas, Control Tower base con guardrails mandatorios alcanza — el framework completo no compensa el esfuerzo adicional. Sin componente de AI o agentes en el roadmap ejecutado (no en la mención genérica de un deck), las decisiones de guardrails diferenciados y networking AI-ready se simplifican considerablemente. Y en un lift-and-shift puro con sunset del datacenter en 12 meses, una OU de migración temporal es válida, aceptando explícitamente el refactor posterior. 🎬 Las preguntas de kickoff El checklist que llevamos a la primera reunión técnica determina si el diseño resultante es específico o genérico: ¿Qué workloads son mandatorios en la región local por regulación, y cuáles pueden operar en otras regiones de AWS? Define la topología multi-región y el modelo de residencia de datos. ¿Cuál es el modelo de compliance activo hoy? (PCI-DSS, HIPAA, ISO 27001, regulaciones locales) — condiciona guardrails, logging y encryption. ¿Existe una hoja de ruta explícita de retiro del datacenter físico? Determina si el legacy es convivencia larga o transición corta. ¿Hay una decisión previa sobre modelo LLM y ubicación de los datos de entrenamiento/inferencia? Bedrock cross-region inference, modelos on-demand vs. Provisioned Throughput, Batch: todo cambia el diseño de red y de identidad. ¿Cómo se maneja hoy la identidad corporativa? (Entra ID, Okta, Ping, AD on-premises) — determina cómo federamos Identity Center. ¿Existe hoy un inventario formal de aplicaciones y dependencias, o partimos con AWS Transform desde cero? Define el timeline del assessment. Una pregunta adicional, una vez ganada cierta confianza en la reunión: quién fue el arquitecto anterior y por qué se fue — ahí suelen aparecer las restricciones reales del proyecto. Happy learning on AWS 🚀