Migración a AWS: guía empresarial paso a paso para 2026

Migrar a AWS no es un proyecto de infraestructura, es un proyecto de operación. La mayoría de las empresas que arrancan sin Landing Zone, sin política de cuentas y sin modelo de identidades terminan con un entorno que funciona pero que nadie controla: facturas que crecen 30% cada trimestre, permisos heredados de pruebas iniciales, y workloads productivos viviendo en la misma cuenta que los sandboxes.

Esta guía está pensada para líderes técnicos (CTO, VP Engineering, Head of Cloud) que necesitan tomar decisiones arquitectónicas antes de firmar la orden de compra. No es un tutorial de botones en la consola: es el mapa de las decisiones que se pagan caro si se posponen.

Si vienes de una evaluación más general de nubes públicas, te recomendamos revisar primero la guía completa para migrar a la nube para alinear contexto antes de entrar al detalle técnico de AWS.

AWS vs competencia (breve, link a B14)

AWS mantiene el liderazgo en cuota de mercado cloud global con aproximadamente [VERIFICAR: 31% de participación en IaaS/PaaS según Gartner 2025], seguido por Azure y GCP. En la práctica, la diferencia no es el catálogo de servicios (los tres son competitivos) sino la madurez operativa: AWS tiene más años de documentación, más talento disponible en LATAM y un ecosistema de partners más denso.

Las decisiones de plataforma dependen del workload: si tu stack es heavy en datos y analítica, GCP suele competir mejor en precio/rendimiento; si hay dependencia fuerte de Microsoft (Active Directory, .NET, Dynamics), Azure reduce fricción. Para el resto de casos empresariales, AWS es la apuesta por defecto. Para un comparativo lado a lado, revisa GCP vs AWS.

Arquitectura recomendada por tamaño de empresa

No existe una arquitectura única. La complejidad debe ser proporcional al tamaño del equipo que la va a operar.

Tamaño	Cuentas AWS	Red	Gobierno
Startup (<20 ingenieros)	2–3 cuentas (prod, dev, shared)	VPC única por cuenta	IAM manual + SCPs mínimas
Mid-market (20–200)	5–10 cuentas con Organizations	Transit Gateway, VPCs segmentadas	Control Tower + SSO
Enterprise (>200)	Multi-OU, decenas de cuentas	Hub-and-spoke, Direct Connect	Control Tower + guardrails custom + auditoría centralizada

El error más común es saltar escalones: una startup que copia la arquitectura de un banco se bloquea en gobernanza antes de entregar valor. Una enterprise que opera con tres cuentas planas pierde trazabilidad y compliance.

La regla práctica: arranca con la arquitectura que corresponde a tu tamaño actual, pero deja la cuenta de management (root) y el Organizations creados desde el día uno. Agregar cuentas después es trivial; reestructurar cuentas con workloads productivos es doloroso.

Landing Zone y cuentas AWS Organization

La Landing Zone es el punto de partida no negociable. Se trata de una configuración base multi-cuenta que incluye: estructura de Organizations con Unidades Organizacionales (OUs), cuentas dedicadas para logging y auditoría, red compartida, SSO centralizado y baseline de seguridad aplicado vía Service Control Policies.

Una estructura estándar funcional:

• OU Security: cuentas log-archive (almacena CloudTrail y logs de todas las cuentas) y audit (solo lectura para SecOps).
• OU Infrastructure: cuenta shared-services (DNS, directorio, endpoints VPC) y network (Transit Gateway, firewalls).
• OU Workloads: subdividida en prod y non-prod, con una cuenta por aplicación o por equipo.
• OU Sandbox: cuentas efímeras con límite de gasto para experimentación.

Separar logs en una cuenta aislada no es opcional: si un atacante compromete una cuenta de workload, no debe poder borrar el rastro. Esa decisión arquitectónica se toma el día uno o no se toma nunca.

IAM e identidades: la base de todo

El 80% de los incidentes de seguridad en AWS que vemos tienen origen en IAM mal diseñado: claves de acceso de larga duración en repositorios, usuarios humanos en lugar de roles federados, políticas con Action: "*" sobrevividas desde el piloto.

Las reglas mínimas que debe cumplir el diseño:

• Cero usuarios IAM para humanos. El acceso humano entra por AWS IAM Identity Center (antes SSO) federado con tu IdP (Okta, Entra ID, Google Workspace).
• Roles para todo lo no humano. EC2, Lambda, pipelines CI/CD: cada carga usa un rol con permisos mínimos y credenciales temporales.
• MFA obligatorio en la cuenta management y para cualquier rol con privilegios administrativos.
• Permission boundaries para limitar el techo de permisos que los desarrolladores pueden auto-asignarse en cuentas sandbox.
• Revisión trimestral de políticas con IAM Access Analyzer para detectar permisos no utilizados.

En empresas reguladas (fintech, salud), este diseño es también la base de cumplimiento para ISO 27001, SOC 2 y PCI-DSS. Hacerlo bien al inicio ahorra auditorías dolorosas después.

Servicios core para arrancar: EC2, RDS, S3, CloudFront, VPC

AWS ofrece más de 200 servicios. El 90% de las migraciones iniciales usan cinco:

• VPC: la red privada virtual. Diseña con subnets públicas y privadas, NAT Gateways por zona de disponibilidad (no uno solo: es punto único de falla) y endpoints de VPC para S3 y DynamoDB para evitar tráfico por internet.
• EC2: instancias de cómputo. Arranca con familias de propósito general (M7i, M7g) y mueve a instancias especializadas solo con datos de uso. Usa Savings Plans o Reserved Instances para cargas estables.
• RDS: bases de datos gestionadas. Habilita Multi-AZ para producción desde el inicio y automated backups con retención mínima de 7 días. Evita administrar tu propio PostgreSQL en EC2 salvo caso extremo.
• S3: almacenamiento de objetos. Activa versioning, block public access a nivel de cuenta y cifrado por defecto con KMS. Define lifecycle policies desde el día uno o la factura crecerá sin control.
• CloudFront: CDN. Reduce latencia y costos de egress si tu aplicación sirve contenido estático o APIs a usuarios finales.

Una vez operando estos cinco, la observabilidad se vuelve crítica. Revisa nuestra guía de monitoreo y observabilidad en AWS para estructurar CloudWatch, alarmas y dashboards antes de que un incidente te obligue a hacerlo bajo presión.

Costos: pricing model y pitfalls

AWS cobra por consumo, pero el consumo se vuelve invisible rápido. Los cinco pitfalls más frecuentes que detectamos en auditorías de costo:

1. Tráfico inter-AZ y egress a internet. El egress hacia internet cuesta [VERIFICAR: ~$0.09 por GB en us-east-1 en 2026]; una app mal diseñada puede generar facturas de egress que superan el costo de cómputo.
2. Snapshots y volúmenes EBS huérfanos. Cuando se termina una EC2, el EBS no siempre se borra. Miles de dólares al mes en almacenamiento de discos que nadie usa.
3. NAT Gateway por tráfico. Cada GB procesado por NAT cuesta además de la hora de gateway. Endpoints de VPC para S3/DynamoDB eliminan ese costo.
4. Logs sin lifecycle. CloudWatch Logs sin política de retención acumula indefinidamente. Configura retención por grupo de logs (30, 90 o 365 días según caso).
5. On-demand en cargas predecibles. Workloads que corren 24/7 en on-demand pagan hasta 72% más que con Savings Plans a 3 años.

Herramientas nativas para control: AWS Cost Explorer (análisis), Budgets (alertas), Compute Optimizer (rightsizing) y Trusted Advisor. Una práctica disciplinada: tagging obligatorio por environment, team y cost-center aplicado vía SCP desde Organizations.

Cuándo usar Control Tower

AWS Control Tower es el servicio gestionado que automatiza la Landing Zone. La pregunta no es si usarlo, sino cuándo.

Úsalo desde el inicio si: tu empresa tiene más de 50 ingenieros, opera en industria regulada, o proyecta más de 10 cuentas AWS en los primeros 12 meses. El costo de rehacer una Landing Zone manual en Control Tower después es alto (migración de cuentas, reconfiguración de SSO, re-enrollment).

Pospónlo si: eres una startup con 2–3 cuentas, equipo pequeño y presupuesto ajustado. Control Tower añade guardrails y complejidad que pueden frenar velocidad de entrega temprana. En ese caso, empieza con Organizations + SCPs básicas + IAM Identity Center manual, y migra a Control Tower cuando la organización justifique la gobernanza.

Ventajas concretas: baseline de seguridad preconfigurado, cuentas nuevas provisionadas en minutos con Account Factory, detección automática de drift en guardrails, y panel unificado para compliance. Limitación: Control Tower opina sobre la estructura. Si ya tienes Organizations con OUs personalizadas y workloads productivos, el enrollment requiere planificación cuidadosa.

Próximo paso

Cada decisión de esta guía —estructura de cuentas, modelo IAM, arquitectura de red, estrategia de costos— se toma una sola vez y se paga durante años. Hacerlas bien al inicio no requiere meses de análisis: requiere un diagnóstico honesto del estado actual y un plan de 90 días priorizado.

Si estás evaluando migrar a AWS o corrigiendo una Landing Zone que creció sin control, contáctanos para un diagnóstico de 30 minutos. Revisamos tu arquitectura actual y entregamos un plan accionable, sin compromiso.

Preguntas frecuentes

¿Cuánto tarda una migración empresarial a AWS?

Depende del alcance. Una migración lift-and-shift de 20–50 workloads toma entre 4 y 9 meses incluyendo Landing Zone, pruebas y cutover. Proyectos de re-arquitectura (re-platform o refactor) suelen extenderse a 12–18 meses. El factor crítico no es la tecnología sino la disponibilidad del equipo de aplicaciones.

¿AWS es más caro que operar on-premise?

No necesariamente. Comparado contra TCO real (hardware, licencias, personal, data center, refresh cada 4 años), AWS suele empatar o ganar cuando se aplican Savings Plans y rightsizing. Pierde contra on-premise cuando se migra sin optimización y se deja todo en on-demand.

¿Qué pasa si ya tengo cuentas AWS sueltas creadas por distintos equipos?

Se pueden invitar a AWS Organizations sin pérdida de datos ni downtime. El trabajo real está en reubicarlas en la OU correcta, aplicar SCPs y migrar accesos humanos a Identity Center. Es ejercicio de semanas, no de meses.

¿Necesito un partner certificado para migrar?

No es obligatorio, pero un partner AWS Advanced o Premier acelera el proyecto, da acceso a fondos de migración (MAP) que subsidian parte del costo y reduce riesgo de decisiones arquitectónicas irreversibles. Para empresas sin equipo cloud maduro, el ROI del partner es claro.

¿Control Tower reemplaza a Terraform o CloudFormation?

No. Control Tower gestiona la estructura de cuentas y guardrails; Terraform o CloudFormation gestionan los recursos dentro de cada cuenta. Son complementarios: Control Tower provisiona la cuenta, tu IaC despliega la aplicación.

¿Cómo manejo compliance (ISO 27001, SOC 2, PCI) en AWS?

AWS provee los controles de infraestructura bajo el modelo de responsabilidad compartida. Tu trabajo es configurar CloudTrail, Config, GuardDuty y Security Hub, y documentar procesos. AWS Artifact entrega los reportes de cumplimiento de AWS que necesitas para auditorías.