Economía de la nube, estrategias de migración y el viaje a la nube

El Dominio 1 del examen CLF-C02 carga con el 24% del contenido puntuado, el segundo dominio más grande del examen, y es el único dominio en el que AWS te pide razonar en el lenguaje de un caso de negocio, no en el de una característica de servicio. Todo lo demás del examen (seguridad, infraestructura global, servicios, facturación) da por supuesto que ya aceptas la premisa; el Dominio 1 es la premisa. Los candidatos que llegan con una larga lista de nombres de servicios pero sin vocabulario para el coste fijo frente al variable, el capex frente al opex, o el «por qué rehostear y luego replatformear» pierden puntos que nunca esperaron tener que defender.

En esta lección vas a:

• enunciar las seis ventajas de la computación en la nube con la redacción de la propia AWS;
• separar economías de escala, alcance global, velocidad, elasticidad, escalabilidad y alta disponibilidad;
• recorrer los seis pilares del Well-Architected y los seis principios generales de diseño, y mostrar cómo los pilares se oponen entre sí;
• mapear las seis perspectivas del AWS CAF con sus propietarios y con los cuatro resultados examinables;
• elegir entre las estrategias de migración de las 6 R y las 7 R con un árbol de decisión, y nombrar las herramientas detrás de la replicación de bases de datos;
• situar el viaje Evaluar → Movilizar → Migrar y modernizar y sus recursos de apoyo en un solo mapa;
• convertir un patrimonio on-premises de coste fijo y capex en un modelo de nube de coste variable y opex;
• construir una comparación de TCO y ROI con aritmética resuelta que puedes reproducir en 90 segundos;
• decidir entre BYOL y licencia incluida, y ordenar el rightsizing antes que los descuentos;
• explicar cómo se mueve la línea de responsabilidad en EC2, RDS y Lambda;
• leer dos casos de estudio reales de migración de AWS y tratar sus números con honestidad;
• responder 10 preguntas estilo examen más tres comprobaciones interactivas;
• ampliar después el conjunto de historias con Netflix, Box y FarEye, trabajar el recuadro de actualizaciones de 2026 y practicar una comprobación de emparejamiento de casos de estudio más dos preguntas extra (clf-02-q11, clf-02-q12).

---

1. La propuesta de valor de la nube de AWS (tarea 1.1)

1.1 Las seis ventajas, textualmente

AWS publica seis ventajas de la computación en la nube en un whitepaper, y las preguntas de examen citan las frases casi palabra por palabra. Aprende la frase gatillo en negrita de cada fila: esa es la cadena que el enunciado de la pregunta va a reproducir.

AWS también declara que opera más de 200 servicios con todas las funciones (en octubre de 2026): una cifra que vale la pena recordar porque distractores como «más de 1.000 servicios» son fáciles de eliminar.

1.2 Ejemplo E1: economías de escala, aritméticamente

Las economías de escala son estructurales, no una promoción. El proveedor de nube agrega la demanda de todos los clientes, así que compra energía, hardware y espacio en planta a un precio al que ninguna sola empresa puede llegar, y traspasa parte de esa diferencia en forma de una tarifa variable más baja.

Dos clientes, cada uno con un pico de 10 unidades, pero sus picos son anticorrelacionados (uno está ocupado cuando el otro está en calma):

1.3 Alcance global, velocidad de despliegue y agilidad

• 📚 ¿Sabías que…? En octubre de 2026 AWS reporta 39 Regiones geográficas y 124 Zonas de Disponibilidad, y cada Región debe contar con un mínimo de tres AZ aisladas, físicamente separadas, todas dentro de 100 km (60 millas) entre sí. Una Zona de Disponibilidad se define como «uno o más centros de datos discretos, cada uno con energía, conectividad de red y conexión redundantes»: así que una AZ no es un rack, y una Región no es una AZ.

1.4 Ejemplo E2: «dejar de adivinar la capacidad» en números

Un equipo pronostica un pico de 100 vCPU. La práctica on-premises es comprar un 20% to 50% por encima de la demanda pronosticada en el pico para que el pronóstico no pueda morder:

Eso es lo que significa «dejar de adivinar la capacidad»: en lugar de comprar para el pico y quedarte inactivo, aprovisionas según la demanda medida en minutos y dejas que la elasticidad absorba el pico. La misma lógica se repite en cada capa posterior de esta lección: la capacidad inactiva es el enemigo en el rightsizing, en las licencias y en la tabla de TCO.

---

2. Principios de diseño: el AWS Well-Architected Framework (tarea 1.2)

2.1 Qué es el Framework

El AWS Well-Architected Framework documenta mejores prácticas para diseñar y operar cargas de trabajo seguras, fiables, eficientes, rentables y sostenibles. El detalle del proceso relevante para el examen es este: una revisión Well-Architected es «una conversación constructiva... no un mecanismo de auditoría»: nunca se te pedirá «aprobar» una, y la AWS Well-Architected Tool que la ejecuta es gratuita y está en la lista de servicios dentro del alcance.

2.2 Los seis pilares

2.3 Los seis principios generales de diseño

Los seis principios hacen el mismo movimiento subyacente: convierten el gasto inicial, fijo e inactivo en un gasto medido, bajo demanda y guiado por evidencia.

2.4 Ejemplo E3: los pilares no son intercambiables

La tarea 1.2 te pide explícitamente identificar diferencias entre los pilares. Se contradicen, y el examen comprueba si lo notas:

No hay ningún pilar que gane automáticamente. La postura correcta en el examen es un intercambio deliberado y medido, no la afirmación de que un pilar es «el más importante». Observa también que Sostenibilidad y Optimización de costos hablan ambos de reducción, y Seguridad y Confiabilidad hablan ambos de resiliencia: palabras parecidas, pilares distintos, propietarios distintos.

• 📚 ¿Sabías que…? El Cloud Adoption Framework (sección 3), el Well-Architected Framework (esta sección) y el Cloud Value Framework (sección 6) son tres listas distintas de cinco o seis elementos que los candidatos fusionan sin cesar: Well-Architected tiene 6 pilares sobre la calidad de la carga de trabajo, CAF tiene 6 perspectivas sobre la preparación organizativa, y el Cloud Value Framework tiene 5 pilares sobre el valor de negocio: de los cuales el TCO es solo el pilar 1 de 5.

---

3. El AWS Cloud Adoption Framework (tarea 1.3)

3.1 Seis perspectivas, seis propietarios

El AWS Cloud Adoption Framework (AWS CAF) agrupa sus capacidades en seis perspectivas. Cada perspectiva es una conversación con una parte distinta de la organización: por eso el examen te pide asociar una perspectiva con un interesado o con una preocupación.

Recuentos de capacidades publicados (en octubre de 2026): People 7, Governance 7, Platform 7, Security 9, Operations 9. AWS no publica un recuento de la perspectiva Business en las fuentes verificadas para esta lección, así que no memorices ningún total.

3.2 Los cuatro resultados examinables

La tarea 1.3 nombra los resultados que debes reconocer. Un programa dirigido por el CAF se juzga por:

1. Menor riesgo de negocio
2. Mejor desempeño ambiental, social y de gobernanza (ESG)
3. Más ingresos
4. Mayor eficiencia operativa

3.3 Un mapa: CAF → MAP → Well-Architected

Estos tres frameworks aparecen juntos en casi toda pregunta de migración. Responden a tres preguntas distintas, en este orden:

---

4. Estrategias de migración: las 6 R (tarea 1.3)

4.1 Las estrategias y sus glosas

El marco más antiguo y aún popular en el examen es el de las 6 R, construido sobre las cinco R que Gartner esbozó. El marco actual de AWS Prescriptive Guidance es el de las 7 R, que añade Relocate. Ambos aparecen en el material de estudio; la propia guía del examen nunca enumera ninguna de las dos listas.

4.2 Ejemplo E4: ordenar una cartera de 40 aplicaciones

Una empresa evalúa 40 aplicaciones. Usando la propia guía de orden de magnitud de AWS de que «hasta un 10% to 20% de la cartera de TI de una empresa ya no es útil y puede apagarse»:

Regla de secuenciación para migraciones grandes: primero rehost, replatform, relocate y retire; moderniza después. Pagar una fábrica de migración para mover 40 aplicaciones en paralelo es como los programas descontrolan su presupuesto; retirar 4 de ellas antes de que alguien escriba una sola línea de código es como los programas se autofinancian.

4.3 Las dos herramientas con nombre detrás de las estrategias | Preocupación | Servicio | Función |

|---|---|---| | Replicación de bases de datos (el ejemplo con nombre de la examen para la tarea 1.3) | AWS Database Migration Service (AWS DMS) | Replicación continua de la base de datos de origen al destino mientras la aplicación sigue funcionando | | Diferencias de esquema entre motores | AWS Schema Conversion Tool (AWS SCT) | Convierte esquemas, código y procedimientos almacenados para que la replicación pueda aterrizar | | Ejecución de Rehost | AWS Application Migration Service (MGN) | Lift and shift de servidores a EC2, automatizado y basado en agentes | | Descubrir lo que posees | AWS Application Discovery Service | Mapea las dependencias antes de que elijas una R |

4.4 Ejemplo E5: el chequeo de realidad de Snowball

Para transferencias a escala de petabytes sobre un enlace restringido, la respuesta clásica es un dispositivo físico: un solo Snowball Edge Storage Optimized mueve aproximadamente 210 TB (en octubre de 2026; verifica las especificaciones actuales antes de usarlo), y un trabajo debe completarse dentro de los 360 días siguientes a su preparación.

Dos advertencias que debes sostener al mismo tiempo:

• 📚 ¿Sabías que…? Snowball Edge Storage Optimized se envía con unos 210 TB de NVMe utilizables (en octubre de 2026), mientras que la variante Compute Optimized cambia almacenamiento por silicio, alrededor de 28 TB de NVMe frente a 416 GB de memoria. El dispositivo está ni en la lista de servicios dentro del alcance ni en la de fuera del alcance para CLF-C02 (ambas listas son explícitamente «no exhaustivas»), así que si es examinable no puede verificarse, trátalo como conocimiento, no como certeza.

---

5. El viaje de migración a la nube y sus recursos (tarea 1.3)

5.1 Las tres fases

El programa de migración de AWS funciona en tres fases, y el examen pregunta por el orden:

Léelo literalmente: Evaluar → Movilizar → Migrar y modernizar. Movilizar está entre el caso de negocio y la primera ola, porque las brechas encontradas en Evaluar tienen que cerrarse antes de que empiece la migración.

5.2 Los recursos que acompañan el viaje

---

6. Economía de la nube (tarea 1.4)

6.1 Coste fijo frente a coste variable

El coste fijo existe exista o no el servicio: hardware propio, espacio en planta, personal con salario. El coste variable sigue al consumo. La frase más citada del Dominio 1 es: «La nube cambia un gasto fijo por un gasto variable: solo pagas cuando consumes recursos informáticos.»

Ejemplo E6: doce meses, cifras ilustrativas (en octubre de 2026; solo números docentes, no precios de lista de AWS):

La fila on-premises es una línea plana porque lo pagaste en el año de capital: el tráfico no tiene nada que ver con ella. La fila de la nube puede caer a cero para una carga de trabajo que apagas.

6.2 Los motores de coste de un entorno on-premises

La tarea 1.4 pide específicamente los «costes asociados a los entornos on-premises». Cada fila de abajo tiene que aparecer en un modelo de TCO o el modelo está mal:

6.3 Ejemplo E7: las entradas ocultas de on-premises

La mayoría de los modelos on-premises fallan contando solo el hardware. Aquí van diez servidores durante cinco años, con todas las cifras ilustrativas (en octubre de 2026, números docentes, no precios de lista de AWS):

La propia guía de AWS para comparaciones precisas es directa: los gastos de capital suelen tener un ciclo de renovación de cinco años, el equipo se adquiere seis a nueve meses por adelantado, y los clientes sobreaprovisionan un 20% to 50% por encima de la demanda pronosticada en el pico. Un modelo que omite mano de obra, renovación e instalaciones resta valor al coste on-premises, y por eso el examen trata «comparar el precio de compra del servidor con una tarifa por hora» como el modelo de TCO clásico defectuoso.

6.4 De capex a opex

6.5 Ejemplo E8: TCO y ROI, resueltos

El TCO es la comparación a todo coste y plurianual de los costes de adquisición y de operación, hardware, software, instalaciones, mano de obra y capital, on-premises frente a AWS. No es una lista de precios, y AWS lo encuadra explícitamente como solo el pilar 1 de 5 del Cloud Value Framework.

Todas las cifras en dólares de la tabla de abajo son números docentes ilustrativos creados para esta lección (en octubre de 2026). NO son precios de lista de AWS y no deben citarse como tales.

Ahora los dos números que un entrevistador (o un enunciado de examen) realmente quiere:

Contraste de cordura con una cifra publicada: AWS cita a IDC (2022) afirmando un 50% menor coste de operación a 5 años en AWS: una afirmación citada por el cliente/AWS, sin auditar, y nuestro ilustrativo −49.9% cae en el mismo vecindario por construcción, no por coincidencia. Atribuye siempre tales cifras («IDC para AWS, 2022»), nunca las presentes como garantizadas.

6.6 Licencias: BYOL frente a licencia incluida

Licencia incluida significa instancias de Amazon EC2 que empaquetan el coste de la licencia dentro del coste de cómputo, AWS es responsable del cumplimiento de la licencia, y solo pagas mientras la instancia corre. BYOL significa que traes tu propia licencia y tus propios medios, tú eres responsable del cumplimiento. AWS License Manager es una herramienta gratuita que rastrea ambas cosas en AWS, on-premises y otras nubes.

Ejemplo E9: carga de trabajo con 30% de actividad, tarifas ilustrativas (en octubre de 2026; solo cifras docentes):

Regla: actividad variable o intermitente → licencia incluida; actividad alta y constante más licencias con descuento ya existentes → BYOL. Recuerda que una licencia de Windows puede representar el 50% o más del coste de cómputo (AWS, 2022-04-28), así que esta no es una decisión de redondeo.

6.7 Rightsizing

El rightsizing significa igualar el tamaño y el tipo de instancia con la utilización medida sin dejar de cumplir los requisitos de rendimiento. No es «elegir la instancia más barata», y el orden de las operaciones importa.

Ejemplo E10: de 12 vCPU a 4 vCPU, tarifa ilustrativa (en octubre de 2026; solo cifra docente: $0.06 por vCPU-hora):

AWS Compute Optimizer «te proporciona recomendaciones de rightsizing e identifica recursos inactivos». Solo después del rightsizing eliges un modelo de compromiso: porque comprometerte con un descuento sobre una instancia sobredimensionada solo compra un descuento sobre desperdicio. AWS documenta Savings Plans como «hasta un 72% menos en algunos casos» frente a bajo demanda y Spot como «hasta un 90% de descuento sobre el precio bajo demanda» (ambos de AWS, 2022-04-28; verifica las tarifas actuales antes de usarlas).

• 📚 ¿Sabías que…? Las cifras de utilización publicadas son el núcleo económico de esta lección: los servidores on-premises promedian un 12% to 18% de utilización, más del 30% de los servidores corren por debajo del 10% de utilización, y un centro de datos on-premises se describe como «por debajo del 15%» (blogs de AWS, 2022-04-28 y 2024-10-01). Por eso primero rightsizing, después compromiso es el orden canónico de FinOps en el examen.

---

7. Automatización, servicios gestionados y el cambio de responsabilidad (tarea 1.4)

7.1 Beneficios de la automatización

La infraestructura como código (IaC) significa aprovisionar y dar soporte a la infraestructura informática usando código en lugar de procesos y ajustes manuales. El examen nombra AWS CloudFormation, que «te permite crear y aprovisionar despliegues de infraestructura de AWS de forma predecible y repetitiva.»

7.2 Los servicios gestionados absorben el trabajo no diferenciado

La guía de examen PDF añade «Identificar servicios gestionados de AWS (por ejemplo, Amazon RDS, Amazon ECS, Amazon EKS, Amazon DynamoDB)» a la tarea 1.4. Cada uno saca trabajo de tu personal:

Menos tareas no diferenciadas significa menos tiempo del personal y menos software por licenciar: una línea directa hacia la fila de mano de obra de la tabla de TCO de la sección 6.5.

7.3 El cambio de responsabilidad compartida: EC2 frente a RDS frente a Lambda

Cuanto más gestionado es el servicio, menor es la cuota del cliente en la pila. La línea se mueve; nunca desaparece.

Constantes que nunca se mueven: la seguridad física y la seguridad de la nube siempre son de AWS; las decisiones de datos, IAM y cifrado siempre son del cliente. Los controles compartidos, gestión de parches, gestión de configuración, concienciación y formación, los posee cada parte para su propia capa.

• 📚 ¿Sabías que…? La redacción propia de AWS importa: para servicios abstractos como Amazon S3 y Amazon DynamoDB, «los clientes son responsables de gestionar sus datos (incluidas las opciones de cifrado) y de usar las herramientas de IAM para aplicar los permisos adecuados.» Y a medida que la infraestructura se moderniza, «más responsabilidad se traslada al proveedor del servicio»: lo cual es un desplazamiento de la línea, no una transferencia de tu responsabilidad sobre los datos. Serverless no es «problema de otro».

---

Casos Reales

Toda cifra de abajo es afirmada por el cliente o por AWS y sin auditar, atribuida con su fuente para que puedas verificarla. El punto examinable es siempre el patrón, qué estrategia se eligió, qué palanca se movió, nunca el número de marketing.

Capital One: «todo en AWS» (banca, regulada)

«De verdad nos lanzamos por completo a la nube, y AWS ha sido fundamental para que podamos aprovechar al máximo los beneficios de estar en la nube.»: Chris Nims, SVP de ingeniería de nube y productividad, Capital One (caso de estudio de AWS)

Shutterfly / SBS: de VMware a AWS (impresión para comercio electrónico)

«Hemos dado grandes pasos para derribar la deuda técnica y poder centrarnos en la transformación y movernos con la clase de agilidad que teníamos al principio.»: Ian Wright, VP de Infraestructura, Shutterfly/SBS (caso de estudio de AWS)

• 📚 ¿Sabías que…? Un tercer patrón de migración que vale la pena reconocer aparece en el mismo conjunto de investigación: Bangkok Flight Services usó AWS Application Migration Service (MGN) para un rehost puro, terminando en 7 meses con «sin rollback, sin interrupciones», reduciendo el tiempo de gestión de la infraestructura de TI en un 50% y reemplazando un sitio de DR inexistente con un diseño multi-AZ: mientras Philip Morris International migró 400 aplicaciones en dos años y el propio artículo de AWS registra que su primer lift and-shift agresivo «produjo resultados subóptimos». Misma R, lección opuesta: el rehost es rápido, pero rehospedar todo es un error de estrategia.

Netflix: streaming global a escala de AWS (entretenimiento)

Todas las cifras de Netflix de arriba son publicadas por AWS y consultadas en octubre de 2026; cualquier cosa sobre la historia de caídas de Netflix anterior a AWS vive en el propio sitio de Netflix y no se enseña aquí como hecho de AWS.

Box: optimización de costos con Well-Architected (SaaS empresarial)

«Nuestro uso de las mejores prácticas de AWS condujo a ahorros de más de 2 millones de dólares, estableciendo una nueva línea base…»: Clay Alvord, director de FinOps y SRE, Box (caso de estudio de AWS)

FarEye: Savings Plans + Spot + Graviton (logística SaaS)

Actualizaciones de 2026 (en octubre de 2026)

Seis cambios con fuente que afectan a la migración y a la economía de la nube desde la última vez que actualizaste tus notas: cada cifra con fecha, y los precios/límites derivan, así que verifica lo actual antes de usarlo:

• El alcance de las herramientas de migración cambió. Migration Evaluator se unió a la lista de servicios dentro del alcance (categoría Migración y transferencia) mientras AWS Snow Family pasó a la lista de fuera del alcance; las entradas dentro del alcance fueron de 128 → 111 y las de fuera del alcance de 11 → 55 (páginas oficiales dentro/fuera del alcance de CLF-C02, diff calculado en 2026-10). Ambas listas son explícitamente «no exhaustivas y sujetas a cambios».

• Llegó una nueva opción de compromiso: Database Savings Plans, lanzada el 2025-12-02 y anunciada con hasta un 35% para un compromiso de 1 año sin pago inicial (hasta 35% en serverless, hasta 20% en provisioned). Compute y EC2 Instance Savings Plans siguen sin cambios, y la guía del examen aún nombra solo «AWS Savings Plans» (AWS News Blog y What's New, 2025-12-02).

• La oferta de soporte se reescribió el 2025-12-02: Business Support+ desde 29 USD/mes, AWS Enterprise a 5,000 USD/mes y AWS Unified Operations a 50,000 USD/mes, con Basic gratuito; Developer, el Business clásico y Enterprise On-Ramp no admitieron nuevas suscripciones después del 2025-12-02 (las existentes corren hasta 2027-01-01), y la Tarea 4.3 del Dominio 4 de la guía actual del examen dice ahora «Basic Support, AWS Business Support+, AWS Enterprise Support, AWS Unified Operations» (AWS News Blog, 2025-12-02; guía del examen PDF, © 2026; precios en octubre de 2026).

• Free Tier dependió de la antigüedad de la cuenta (cambio efectivo el 2025-07-15): las cuentas creadas en esa fecha o después reciben 6 meses (o hasta agotar los créditos) más 100 USD de crédito de registro y hasta 100 USD más, hasta 200 USD, en t3.micro, t3.small, t4g.micro, t4g.small, c7i-flex.large, m7i-flex.large; las cuentas creadas antes conservan el 12 meses legado con t2.micro / t3.micro (AWS News Blog, 2025-07-15; tabla de la guía de usuario de Amazon EC2 «antes y después del 15 de julio de 2025»).

• Las herramientas de coste siguen moviéndose aunque los nombres examinables no: Cost Optimization Hub (2023-11-26), RI/SP Group Sharing disponible generalmente (2025-11-19), Target Coverage en Savings Plans Purchase Analyzer (2026-06-09) y la vista previa del Well-Architected Agent (2026-10-01, al que AWS llama «la evolución de nueva generación de AWS Trusted Advisor y de la AWS Well-Architected Tool»). El examen aún evalúa Cost Explorer, AWS Budgets, AWS Pricing Calculator, Trusted Advisor y la AWS Well-Architected Tool.

• Los precios y el egreso siguen cambiando bajo el modelo de TCO: Amazon S3 Express One Zone redujo el almacenamiento unos 31% y los precios de peticiones GET hasta un 85% (efectivo el 2025-04-10) y las instancias EC2 NVIDIA GPU hasta un 45% (2025-06-05); a la salida aún obtienes 100 GB al mes de transferencia de datos de salida gratuita desde las Regiones de AWS (un cambio de 2021, no de 2025) más una ventana aprobada de 90 días para terminar de mover datos fuera de AWS cuando te vayas (preguntas frecuentes y blogs de AWS; en octubre de 2026).

• 📚 ¿Sabías que…? La propia historia de precios de Amazon S3 es la ilustración publicada más limpia de las economías de escala: se lanzó el 14 de marzo de 2006 a $0.15 por GB al mes sirviendo «aproximadamente un petabyte de capacidad total de almacenamiento en unos 400 nodos de almacenamiento», y AWS reportó en marzo de 2026 que ahora cobra «ligeramente más de 2 centavos por gigabyte»: una reducción de aproximadamente el 85% desde su lanzamiento: mientras que el código escrito para S3 en 2006 «sigue funcionando hoy, sin cambios» (AWS News Blog, 2026-03-13; en octubre de 2026: verifica la precios actuales antes de citarlo).

• 📚 ¿Sabías que…? Algunas historias de costes de AWS son más antiguas que el material de estudio de la mayoría de los candidatos: la NASA reportó ahorrar «casi un millón de dólares en ahorro de costes cada año» el 2012-06-11, y el JPL de la NASA procesa hoy unos 4.4 TB de datos descendidos al día (generando hasta 70 TB de productos de datos finales) usando EC2 Auto Scaling con Spot Instances de hasta un 90% de descuento frente al precio bajo demanda de Amazon EC2 (caso de estudio de AWS, consultado en octubre de 2026). Las fechas importan: nunca presentes una cifra de 2012 como actual.

---

Preguntas de Práctica (Practice Questions)