MLOps y escalado en AWS

Un modelo que funciona en un notebook no es un sistema. En el momento en que un segundo ingeniero debe reproducir la ejecución de entrenamiento, en el momento en que el tráfico se duplica a las 09:00, y en el momento en que los datos de entrenamiento se desvían seis meses después, dejas de hacer machine learning y empiezas a hacer operaciones, y AWS te da dos familias distintas de herramientas para eso: una capa de pipeline / registry / CI-CD que decide cómo llega un modelo a producción, y una capa de escalado que decide qué cómputo lo sirve. El examen AIF-C01 prueba si puedes nombrar cada herramienta con precisión, citar sus límites y rechazar las opciones que suenan plausibles pero que están documentadas para otro servicio.

Al terminar esta lección podrás:

• situar una práctica de ML en el modelo de madurez de tres niveles de AWS (0, 1, 2) y separarlo de las variantes de Google, Azure y del blog de AWS del mismo marco;
• leer un SageMaker Pipeline como un DAG JSON y decir qué aristas llevan datos (properties) frente a solo ordenación (DependsOn);
• seleccionar el tipo de paso correcto para una tarea, incluidos Condition, Fail, Callback, Lambda, ClarifyCheck y QualityCheck, y citar cuántos tipos existen;
• configurar ParallelismConfiguration y la caché de pasos (ExpireAfter en ISO 8601, solo ejecuciones exitosas) correctamente;
• impulsar el despliegue a través del Model Registry: numeración de versiones, ModelApprovalStatus y las cuatro transiciones de aprobación que inician o no CI/CD;
• construir o adoptar un SageMaker Project con CodePipeline / Jenkins, explicar por qué las plantillas de CodeCommit desaparecieron el 28 de octubre de 2024 y nombrar el tag y las acciones IAM de CodeConnections necesarias para GitHub;
• elegir entre Experiments (Studio Classic) y MLflow on SageMaker AI, y decir dónde viven físicamente los datos de tracking y los artefactos;
• configurar target tracking, step scaling y acciones programadas con el ServiceNamespace, ResourceId y ScalableDimension correctos, y hacer la aritmética de capacidad con división hacia arriba;
• despertar un endpoint asincrónico desde cero con una política de paso más una alarma HasBacklogWithoutCapacity;
• elegir la opción de inferencia correcta a partir de la carga útil, la latencia, la duración y los requisitos del endpoint, y defender la elección en términos de coste;
• conectar el volante de MLOps: Model Monitor → CloudWatch → EventBridge → StartPipelineExecution;
• defender el Veredicto comparativo: MLOps gestionado frente a scripts DIY frente a operaciones manuales.

---

1. Madurez de MLOps: nivel 0, nivel 1, nivel 2

1.1 El estándar AWS de tres niveles

AWS enmarca MLOps como un modelo de madurez de tres niveles, y el examen espera que reconozcas el nivel a partir de una descripción y que nombres las herramientas que te llevan allí. La pregunta distintiva nunca es «cuánto ML haces», sino cuál es el artefacto desplegado.

1.2 Dónde encaja esto en el examen

MLOps pertenece al Dominio 1, Tarea 1.3 de la guía AIF-C01. El examen en sí es de 65 preguntas = 50 puntuadas + 15 sin puntuar, sin penalización por adivinar y con pesos de dominio publicados de 20 / 24 / 28 / 14 / 14 %. AWS publica solo los pesos de dominio, el número de preguntas por tarea no se publica, así que trata cualquier dimensionamiento por tarea que leas en otra parte como orientación, no como presupuesto.

• 📚 ¿Sabías que…? Las 15 preguntas sin puntuar de un examen AIF-C01 son indistinguibles para ti mientras rindes el examen: se intercalan con las 50 puntuadas y se usan para recopilar estadísticas antes de que cualquier ítem sea puntuado. La consecuencia práctica es un punto de estrategia, no un dato curioso: nunques saltes una pregunta pensando «esta podría no contar». Cada pregunta consume el mismo tiempo, y solo las 50 puntuadas deciden tu resultado, así que el movimiento racional es responder las 65 con toda tu capacidad.

---

2. SageMaker Pipelines: el contrato del DAG

2.1 Qué es un pipeline

Un SageMaker Pipeline es un grafo acíclico dirigido expresado en JSON. Cada nodo es un paso, cada arista es una dependencia, y los ciclos se rechazan, un DAG con bucles no es un pipeline más lento, es una definición inválida. La definición sigue el SageMaker AI Pipeline Definition JSON Schema y puede ser producida por cuatro productores equivalentes: el editor visual en Studio, el SageMaker SDK, boto3 y AWS CloudFormation. Las ejecuciones de pipeline se facturan como los jobs subyacentes (processing, training, transform) más el uso de Studio, la capa de orquestación en sí no es un SKU independiente y pesado.

Existen dos tipos de arista, y confundirlas es el error arquitectónico más común en esta zona:

La regla práctica: si el valor fluye, es una referencia properties; si solo importa el timing, es DependsOn. ParallelismConfiguration no es un mecanismo de ordenación en absoluto: limita cuántos pasos ya elegibles se ejecutan a la vez.

2.2 El DAG del pipeline

Esta es la forma canónica que describe el examen: preprocesar → entrenar → evaluar → registrar solo si la métrica pasa, y fallar en caso contrario con un mensaje.

2.3 Ejemplo resuelto 1: la puerta del MSE, de principio a fin

Un pipeline de regresión para un modelo tabular tipo abulón, construido con el SageMaker SDK:

1. Los parámetros se declaran una vez y se reutilizan en todas partes: processing_instance_count, instance_type, model_approval_status (por defecto PendingManualApproval), input_data, batch_data, mse_threshold.
2. Process produce las salidas train_data y test_data. El paso de entrenamiento las consume con step_process.properties.ProcessingOutputConfig.Outputs["train_data"].S3Output.S3Uri: esa cadena es la arista del DAG, no un comentario.
3. Eval es un paso Processing con property_files, de modo que su salida evaluation.json (que contiene regression_metrics.mse) se expone a los pasos posteriores como una propiedad estructurada en lugar de como una ruta de S3 que tengas que analizar tú mismo.
4. MSECond es un paso Condition: if_steps = [RegisterModel], else_steps = [Fail]. El paso Fail lleva un mensaje compuesto como "MSE above threshold " + mse_threshold y termina la ejecución con estado Failed: la ejecución no «termina con una advertencia».
5. .start() la ejecuta. Pasar ModelApprovalStatus="Approved" como valor de parámetro hace que el registro sea desplegable de inmediato (un atajo de desarrollo/pruebas), y CacheConfig(enable_caching=True, expire_after="PT1H") permite que los pasos sin cambios reutilicen sus salidas anteriores.

---

3. Los 16 tipos de paso, y los dos que deciden resultados

3.1 El mapa completo de pasos

AWS documenta 16 tipos de paso. Aprende la tabla por la columna de «gancho de examen»: el examen rara vez pregunta «qué hace un paso Training», pregunta qué paso debe usarse para X.

3.2 Condition y Fail como puerta de evaluación

El patrón documentado es mecánico y vale la pena memorizarlo:

1. El paso Processing de evaluación declara property_files=["evaluation.json"].
2. El paso Condition lee evaluation.json y compara un escalar: por ejemplo regression_metrics.mse contra el parámetro del pipeline mse_threshold.
3. Rama true → Register model (opcionalmente precedido por Create model, y seguido de un paso Transform para una pasada de cordura por lotes).
4. Rama false → Fail con un error_message compuesto mediante Join(...), produciendo un estado de ejecución de Failed.

Una segunda variante igual de común coloca un paso QualityCheck o ClarifyCheck delante del registro: el baseline se produce con register_new_baseline=true y skip_check=true en la primera ejecución, y las ejecuciones posteriores comparan contra ese baseline. Misma forma: una puerta cuya rama falsa es un paso Fail.

• 📚 ¿Sabías que…? El paso Fail no es un fallo del sistema: es una terminación controlada. El paso en sí termina haciendo bien su trabajo, y lo que acaba como Failed es la ejecución del pipeline, con tu mensaje adjunto. Esa distinción importa cuando construyes una regla de EventBridge: reaccionas al estado de la ejecución, no a una excepción lanzada en tu código Python, de modo que un paso Fail te da una señal limpia y estable en su esquema que no da un exit 1 de un script de shell.

---

4. Paralelismo y caché: las dos perillas que cambian el coste de ejecución

4.1 El paralelismo es por ejecución, no por pipeline

Los pasos independientes se ejecutan en paralelo por defecto: lo que esté elegible se ejecuta. Tú limitas eso con ParallelismConfiguration(MaxParallelExecutionSteps). Dos propiedades de este ajuste importan para el examen:

• se aplica por ejecución: el ejemplo documentado de 50 significa que una ejecución ejecuta como máximo 50 pasos a la vez, y dos ejecuciones concurrentes pueden por tanto ejecutar 100 pasos a la vez;
• se puede sobreescribir al iniciar, reintentar y actualizar, de modo que es un valor por defecto de política, no una propiedad inmutable del pipeline.

El paralelismo no es un mecanismo de dependencia. Poner MaxParallelExecutionSteps = 2 no hace que el paso B espere al paso A; solo limita cuántos pasos listos se ejecutan simultáneamente.

4.2 La caché es optativa, en ISO 8601 y solo para ejecuciones exitosas

El uso práctico es un bucle de desarrollo: re-ejecutas un pipeline de cinco pasos tras tocar solo el informe, y PT1H permite que Process, Train y Eval devuelvan sus artefactos anteriores en segundos mientras el paso modificado se ejecuta de verdad.

---

5. Model Registry: versiones y la aprobación que impulsa el despliegue

5.1 Estructura del registry

El registry organiza los modelos en grupos de modelos, y un grupo contiene paquetes/versiones. Las versiones son sencillas y estrictamente ordenadas: comienzan en 1 y aumentan en 1 por cada paquete añadido al grupo. Un paquete versionado debe pertenecer a un grupo, y su ARN lleva las coordenadas: …:model-package-group/name/version.

5.2 ModelApprovalStatus

Cada paquete de modelo lleva un estado tomado de exactamente tres valores:

Un modelo versionado debe estar en Approved para ser desplegado. El estado puede configurarse mediante update_model_package, mediante Studio, mediante un paso Condition dentro de un pipeline, o pasarse como un parámetro del pipeline cuyo valor por defecto es PendingManualApproval.

5.3 Las cuatro transiciones de aprobación

Esta es la tabla de mayor rendimiento de la lección, porque el examen pregunta «¿qué acción inicia el despliegue?»:

5.4 Ejemplo resuelto 2: de la aprobación a producción

1. Se crea un SageMaker Project desde la plantilla «Model building, training, and deployment with third-party Git repositories using CodePipeline», con dos repositorios de GitHub y un ARN de CodeConnections con tag sagemaker=true.
2. Un commit al repositorio de construcción del modelo dispara la acción de origen (DetectChanges), que ejecuta source → build: CodeBuild crea o actualiza el SageMaker Pipeline y lo inicia.
3. El pipeline registra la versión 7 con ModelApprovalStatus = PendingManualApproval.
4. Un revisor cambia la v7 a Approved (Studio, CLI o un paso Condition alimentado por un parámetro de aprobación).
5. La regla de EventBridge de la plantilla inicia el pipeline de despliegue: source → build → deploy-staging (pila de CloudFormation) → aprobación manual → deploy-prod.
6. Si en staging aparece un defecto y la v7 se cambia de Approved a Rejected, se redespliega el paquete aún Approved más reciente: ese es tu rollback documentado. En un bucle puro de dev/test saltas los pasos 4 to 5 pasando ModelApprovalStatus="Approved" como parámetro del pipeline.

---

6. SageMaker Projects, Git y CI/CD

6.1 Qué es realmente un Project

Los SageMaker Projects son productos de AWS Service Catalog respaldados por CloudFormation. Crear uno aprovisiona, como una sola unidad: repositorios Git, un SageMaker Pipeline, CodePipeline o Jenkins, un grupo de modelos, un bucket de S3, un registro de ECR y reglas de EventBridge. Existen dos formas canónicas:

Las familias de plantillas proporcionadas cubren build/train/deploy con Git de terceros (CodePipeline o Jenkins), Model Monitor y construcción de imágenes (ECR + CodeBuild + EventBridge).

6.2 El cambio del 28 de octubre de 2024 en CodeCommit

La mecánica de la acción de origen de GitHub merece citarse con precisión:

• la acción de CodePipeline es CodeStarSourceConnection;

• la conexión debe ser una conexión de CodeConnections con el tag sagemaker=true;

• el rol del pipeline necesita ambas codestar-connections:UseConnection y codeconnections:UseConnection;

• la detección de cambios es DetectChanges en el commit, de modo que la build arranca sin un disparador manual;

• el CloudFormation de una plantilla personalizada debe declarar SageMakerProjectName y SageMakerProjectId.

• 📚 ¿Sabías que…? «CodeStar» sobrevive en el nombre de la acción (CodeStarSourceConnection) mucho después de que el producto fuera reemplazado por CodeConnections. Por eso la política IAM necesita dos acciones casi idénticas: una para el espacio de nombres heredado y otra para el servicio actual. Los candidatos que memorizan solo una de las dos suspenden sistemáticamente este ítem, y los propios recorridos de AWS listan ambas.

---

7. Experiments y MLflow: dónde vive ahora el tracking de ejecuciones

7.1 La migración

La API de SageMaker Experiments, CreateExperiment, Trials como grupos de ejecución, trial components como ejecuciones individuales, está documentada como disponible solo en Studio Classic. Para la experiencia nueva de Studio, AWS recomienda MLflow on SageMaker AI. En términos de examen: una opción que describa Trials y trial components como la forma actual y recomendada de rastrear ejecuciones está describiendo una superficie heredada.

La división es el punto del examen: el cómputo y el almacén de backend se ejecutan en la cuenta de servicio de SageMaker, pero los artefactos viven en un S3 que tú posees y pagas: que es exactamente lo que un revisor de cumplimiento quiere oír sobre reproducibilidad.

---

8. Autoescalado de endpoints: target tracking, step scaling, acciones programadas

8.1 Los identificadores

El escalado de endpoints se ejecuta a través de Application Auto Scaling (RegisterScalableTarget más PutScalingPolicy) o a través del asistente de la consola. Cita las coordenadas exactamente:

AWS ofrece tres estrategias, target tracking (recomendado), step scaling y acciones programadas (CLI/API), y, para el target tracking, AWS gestiona las alarmas por ti.

8.2 Las métricas

8.3 Ejemplo resuelto 3: aritmética de capacidad con target tracking

La capacidad siempre redondea hacia arriba: ese es el comportamiento de ajuste documentado, y es aritmética examinable:

1. La prueba de carga muestra 210 invocaciones/min, objetivo 70 → 210 / 70 = 3 instancias.
2. El tráfico sube a 351/min → 351 / 70 = 5,01, redondeado hacia arriba → 6 instancias (nunca 5).
3. Registra el objetivo: register_scalable_target(ServiceNamespace="sagemaker", ResourceId="endpoint/prod/variant/AllTraffic", ScalableDimension="sagemaker:variant:DesiredInstanceCount", MinCapacity=1, MaxCapacity=10).
4. Adjunta la política: put_scaling_policy(PolicyType="TargetTrackingScaling", {"TargetValue": 70.0, "PredefinedMetricSpecification": {"PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"}, "ScaleInCooldown": 600, "ScaleOutCooldown": 300}).
5. Efecto: scale-out en unos un minuto; el cooldown de scale-in de 600 s suprime el vaivén tras una ráfaga, y el cooldown de scale-out de 300 s evita el sobreaprovisionamiento durante un tren de picos.

8.4 Ejemplo resuelto 4: aritmética de concurrencia de alta resolución

1. Con ConcurrentRequestsPerModelHighResolution en el objetivo 5, una carga de 18 peticiones concurrentes → 18 / 5 = 3,6, redondeado hacia arriba → 4 instancias.
2. La métrica emite cada 10 segundos en lugar de cada 1 minuto: detección aproximadamente 6× más rápida para el scale-out; el timing del scale-in no cambia.
3. ¿Usas componentes de inferencia? La métrica pasa a ser InferenceComponentConcurrentRequestsPerCopyHighResolution.
4. Varias políticas de target tracking pueden compartir un objetivo escalable: añade una segunda política sobre CPUUtilization con TargetValue = 50, y ambas mantienen sus propios objetivos contra el mismo DesiredInstanceCount.

8.5 La comparación de estrategias de escalado

---

9. Inferencia asincrónica: escalado desde cero

9.1 Por qué la asincrónica es especial

Los endpoints asincrónicos tienen una cola delante, lo que significa que el backlog, no la tasa de peticiones, es la señal que importa. AWS documenta estas métricas de cola:

9.2 El diseño de escalado desde cero

9.3 Ejemplo resuelto 5: aritmética de la cola y el despertar

1. Configura MinCapacity=0, MaxCapacity=5 y una política de target tracking sobre ApproximateBacklogSizePerInstance con TargetValue = 5.
2. Una ráfaga encola 27 peticiones con 1 instancia en ejecución → 27 / 5 = 5,4, redondeado hacia arriba → 6 → limitado a MaxCapacity = 5.
3. El tráfico se detiene; el scale-in devuelve el endpoint a 0 instancias y el gasto ocioso va a cero. Las peticiones que llegan mientras tanto se encolan, no se pierden: ApproximateAgeOfOldestRequest informa de cuánto ha esperado la más antigua.
4. La siguiente petición tras el reposo: HasBacklogWithoutCapacity cambia a 1, se sostiene durante 2 periodos de evaluación de 60 s, dispara la alarma, la política de paso añade +1 instancia tras el cooldown de 300 s, y el target tracking se reanuda.

---

10. Elegir la opción de inferencia

10.1 Las cuatro opciones y sus límites duros

Detalles de la transformación por lotes: MaxPayloadInMB como máximo 100, y MaxConcurrentTransforms × MaxPayloadInMB como máximo 100 MB.

Exclusiones de serverless (memoriza la lista): sin GPUs; sin imágenes de Marketplace ni registros privados; sin endpoints multi-modelo; sin configuración VPC; sin captura de datos; sin Model Monitor; sin múltiples variantes; sin pipelines de inferencia; imagen del contenedor como máximo 10 GB; convertir un endpoint de tiempo real existente a serverless se rechaza; Provisioned Concurrency es opcional.

10.2 La decisión

10.3 Ejemplo resuelto 6: 40 GB, cada noche, sin usuarios

Un equipo de fraude pide «un endpoint de tiempo real para nuestro trabajo nocturno de puntuación de 40 GB». La respuesta correcta es transformación por lotes:

1. Sin tráfico interactivo → la única ventaja del tiempo real (la latencia) no tiene valor, y su forma de coste, pagar por instancias aprovisionadas incluidas las horas ociosas, es un desperdicio puro para un trabajo que se ejecuta una vez al día.
2. 40 GB se sale del techo de 4 MB de serverless y del techo de 1 GB de la asincrónica; es territorio claramente de «datos de escala GB durante días».
3. La transformación por lotes ejecuta instancias solo para el job: MaxPayloadInMB ≤ 100 y MaxConcurrentTransforms × MaxPayloadInMB ≤ 100 MB mantienen cada petición dentro de los límites, S3Output recoge los registros puntuados, y no existe endpoint entre ejecuciones: así que nada se factura a las 03:00.
4. La monitorización usa BatchTransformInput en lugar de Model Monitor; si el equipo quiere más adelante detección de deriva, eso es una decisión separada sobre un endpoint de tiempo real o asincrónico.

• 📚 ¿Sabías que…? La guía de optimización de costes de AWS para inferencia se reduce a una frase: ajusta la elección a la forma del tráfico. La asincrónica se dimensiona para una tasa de procesamiento óptima más escalado a cero; serverless es por petición; el tiempo real es capacidad aprovisionada; y en todos ellos pueden comprarse SageMaker Savings Plans de 1 o 3 años que se aplican sobre Studio, procesamiento, entrenamiento, inferencia de tiempo real y transformación por lotes. Comprar un Savings Plan para un trabajo que se ejecuta 20 minutos cada noche es el desajuste clásico: el plan descuenta el uso comprometido, y un batch nocturno casi no tiene.

---

11. EventBridge y el volante de MLOps

11.1 Qué envía AWS, y a qué

SageMaker emite eventos a EventBridge casi en tiempo real para jobs, endpoints, paquetes de modelo, ejecuciones de pipeline y pasos de pipeline, y cambios de imagen. Los objetivos incluyen Lambda, Step Functions, Kinesis y SNS, y, de forma crítica, el propio SageMaker Pipelines es un objetivo:

11.2 El volante

11.3 Ejemplo resuelto 7: monitorizar, alarmar, reentrenar, aprobar, desplegar

1. Activa la captura de datos en el endpoint de producción para que las peticiones y respuestas aterricen en S3, y programa Model Monitor de forma horaria (CronExpressionGenerator.hourly()).
2. Produce el baseline con un paso QualityCheck usando register_new_baseline=true y skip_check=true en la primera ejecución; las ejecuciones posteriores comparan contra él.
3. Cuando la deriva supera la restricción, la alarma de CloudWatch entra en ALARM → la regla de EventBridge se dispara → objetivo = SageMaker Pipeline, invocando StartPipelineExecution con un SageMakerPipelineParameter mapeado.
4. El pipeline reentrena, evalúa, supera el paso Condition, registra una nueva versión como PendingManualApproval → la aprobación la cambia a Approved → la regla de la plantilla de despliegue actualiza el endpoint.
5. Ejecuta el disparador de calendario junto al disparador de deriva: cron(0 12 1 * ? *) reentrena el día 1 de cada mes a las 12:00 UTC, o usa PipelineSchedule(name, cron="15 10 ? * 6L 2022-2023") para una programación acotada. Recuerda como máximo 5 objetivos por regla y sin programación en buses de eventos custom o partner.

11.4 Infraestructura como código para toda la pila

Todo en esta lección es describible como código, y la guía de AWS apunta a CloudFormation directamente o a través de la AWS CDK: cdk synth emite una plantilla de CloudFormation por pila, y los constructos L1 Cfn* cubren la superficie: sagemaker.CfnEndpointConfig (incluido AsyncInferenceConfig), sagemaker.CfnPipeline, más los nativos AWS:SageMaker:Domain, AWS:SageMaker:UserProfile y AWS:SageMaker:Pipeline.

Codifica, como mínimo: VPC, KMS, el bucket de S3, el rol de ejecución del pipeline, el Model Package Group, CodePipeline + CodeBuild + CodeConnections, las reglas de EventBridge y el objetivo escalable con sus políticas. Para plantillas de proyecto AWS prefiere plantillas alojadas en S3 vía CfnTemplateProvider a los portafolios de Service Catalog, y una plantilla personalizada debe exponer SageMakerProjectName y SageMakerProjectId. Dividir la pila en DevStack y ProdStack te permite testear la infraestructura por unidad antes de que toque producción.

11.5 Actualizaciones de 2025 to 2026

Tres cambios verificados de 2025 to 2026 tocan el material de las secciones 8 a 13, y AWS ahora los anuncia mediante vocabulario de ciclo de vida en lugar de mediante retiras silenciosas. Los tres están documentados, fechados y son examinables.

1. El nombre del producto cambió. AWS documenta que «el Amazon SageMaker actual ha sido renombrado a Amazon SageMaker AI» (3 de diciembre de 2024), junto a una generación separada de SageMaker de nueva generación (Unified Studio, Catalog, Lakehouse, zero-ETL). Una opción de examen que diga SageMaker AI es actual, no exótica, y los identificadores que citas de la sección 8 no cambiaron con el renombrado: ServiceNamespace = sagemaker, ResourceId = endpoint/…/variant/…, SageMakerVariantInvocationsPerInstance y la acción del rol SageMaker:StartPipelineExecution siguen escribiéndose a la manera antigua.

2. Model Monitor y Clarify están en mantenimiento. El End of Support Notice de SageMaker AI lista Model Monitor y Clarify: junto con Ground Truth, A2I, Studio Lab, Debugger, Role Manager, Geospatial y Mechanical Turk: como «ya no abiertos a nuevos clientes a partir del 30 de julio de 2026». Lee esa frase con precisión: el estado es mantenimiento = sin clientes nuevos, sin funciones nuevas, los clientes existentes siguen usándolos. No es un cierre total, y no es un rebranding hacia Bedrock Model Evaluations. El volante de deriva de 11.2 sigue funcionando por tanto para los clientes existentes; para trabajo nuevo AWS apunta a métricas de CloudWatch y detección de anomalías, CloudWatch Evidently, EventBridge + Lambda, SHAP y, en el lado generativo, Bedrock Model Evaluations: que es exactamente por lo que el ejemplo 4.2.2 de la guía del examen ahora dice «Clarify más Bedrock Model Evaluations».

3. La guía del examen se movió. El historial de cambios de AWS lista v1.0 publicada el 26 de marzo de 2026 y v1.1 publicada el 30 de abril de 2026, y afirma que las actualizaciones aparecen en el examen aproximadamente un mes después de la publicación (trata la v1.1 como el ancla fiable; la fecha de la v1.0 es una republicación de documentación). Ejemplos cambiados que tocan esta lección: 1.1.3 (inferencia asincrónica y serverless), 1.3.4 (Bedrock, Amazon Quick, Kiro, SageMaker AI) y 4.2.2 (Clarify más Bedrock Model Evaluations). Sin cambios, y por tanto seguro seguir citando: 65 preguntas (50 puntuadas + 15 sin puntuar), 90 minutos, aprobación 700 / 1000, validez de 3 años, dominios 20 / 24 / 28 / 14 / 14 %.

Vocabulario de ciclo de vida (AWS General Reference): Maintenance = sin clientes nuevos, sin funciones nuevas, aún soportado · Sunset = fin de operaciones planificado, normalmente unos 12 meses · Full Shutdown = eliminado del portafolio.

• 📚 ¿Sabías que…? AWS declara que los cambios en la guía del examen aparecen en el examen en vivo aproximadamente un mes después de la publicación: así que el material de la v1.1 (30 de abril de 2026) fue examinable desde alrededor de finales de mayo de 2026. El corolario corre en ambas direcciones: una función anunciada después de la versión de tu guía no es automáticamente evaluable, mientras que un ejemplo cambiado como 4.2.2 → Clarify más Bedrock Model Evaluations es evaluable mucho antes de que cualquier fecha de retiro importe. Lee el historial de cambios, no el blog de lanzamientos.

---

12. Veredicto comparativo: MLOps gestionado frente a scripts DIY frente a operaciones manuales

---

13. Trampas del examen y los números que merecen memorizarse

Marcado como no verificado en esta lección (no lo afirmes en el examen): la frase «requests per target» tal como aparece en algunos dumps de estudio, se mapea al ALBRequestCountPerTarget genérico, que no está documentado para endpoints de SageMaker, así que trátalo como InvocationsPerInstance salvo que haya un ALB en la arquitectura; el recuento exacto de plantillas de proyecto proporcionadas (AWS enumera familias, no una lista numerada); la hoja de ruta del endpoint multi-modelo (docs vivos y sin deprecar en octubre de 2026, pero sin página pública de roadmap); el peso por pregunta de MLOps específicamente (solo se publican pesos de dominio); cualquier fecha de fin de soporte de Experiments en Studio Classic; precios del servidor de MLflow; los tamaños de memoria y la concurrencia máxima de los endpoints serverless; cuotas de endpoint (instancias por variante, variantes por endpoint); el valor numérico por defecto de MaxParallelExecutionSteps (los docs muestran cómo configurarlo, ejemplo 50, pero no publican un valor por defecto); y GitHub Actions como respuesta de examen, aparece solo en un blog y en una plantilla personalizada de aws-samples, mientras que las respuestas seguras son CodePipeline / CodeBuild y Jenkins.

• 📚 ¿Sabías que…? El paso Lambda de SageMaker tiene por defecto un timeout de 2 minutos y permite hasta 10 minutos: un techo deliberadamente pequeño, porque el paso existe para trabajo de orquestación ligero (cambiar una aprobación, llamar a una API, mover un archivo), no para ejecutar un job de entrenamiento. Si tu «paso» necesita una hora, es un paso Processing disfrazado.

---

14. Casos Reales

AWS publica historias de clientes porque cada una es una versión documentada de una decisión que esta lección enseñó en abstracto. Los cinco de abajo son los casos relevantes para MLOps, pipelines e inferencia, citados con los servicios AWS exactos, las cifras impresas exactas y la página de origen: un porcentaje sin fuente es marketing, y un porcentaje sin «antes» es peor.

14.1 Forethought: la inferencia es una decisión de pipeline con una factura pegada

• Servicios: endpoints multi-modelo de SageMaker, Serverless Inference y Model Deployment, reemplazando Amazon EKS autoadministrado.
• Cifras: −66 % de coste de inferencia con endpoints multi-modelo y mejor latencia; ≈ −80 % con Serverless Inference (titular hasta −80 %); más del 80 % de la inferencia con GPU se ejecuta ahora en SageMaker; 30 M de interacciones/año; un equipo de 3 personas que ya no podía ejecutar los modelos y Kubernetes (excepciones de memoria, caídas).
• Fuente: aws.amazon.com/solutions/case-studies/forethought-technologies-case-study (la página no lleva chip de año: trata la fecha como no declarada).
• Ángulo de examen: esta es la sección 10 con una factura adjunta. Capacidad GPU compartida → endpoints multi-modelo; pequeños clasificadores con picos → serverless. El coste que eliminaron fue el impuesto DIY de servir: la columna de «scripts DIY» del Veredicto comparativo, aplicada a la inferencia en lugar de a CI/CD.

14.2 HAYAT HOLDING: entrenamiento y ajuste gestionados en lugar de entornos construidos a mano

• Servicios: AWS IoT Greengrass (SiteWise Edge Gateway) → Model Training + Automatic Model Tuning + Model Deployment de SageMaker, con SageMaker Edge Manager sirviendo el modelo en el dispositivo.
• Cifras: 194 sensores transmitidos por OPC-UA; los entornos de ML construidos a mano eran «laboriosos y engorrosos»; resultado documentado: 300.000 USD al año ahorrados más mayor calidad de panel.
• Fuente: aws.amazon.com/blogs/machine-learning/hayat-holding-uses-amazon-sagemaker-to-increase-product-quality-and-optimize-manufacturing-output-saving-300000-annually (2023).
• Ángulo de examen: esto es madurez de Nivel 1 en una fábrica: un pipeline automatizado desde el sensor hasta el modelo ajustado, con Automatic Model Tuning reemplazando el barrido manual de hiperparámetros con 104 entras... con 194 entradas y Edge Manager poseyendo el camino de despliegue en el dispositivo.

14.3 RareJob: el entrenamiento Spot arregló un problema de cola, no un problema de modelo

• Servicios: entrenamiento en SageMaker sobre spot gestionado, alimentado por AWS Glue y Amazon Athena, reemplazando un PC local y después una configuración EC2/ECS con cuello de botella.
• Cifras: −25 % de tiempo de entrenamiento, más de 10× de eficiencia de desarrollo, 100 horas al mes ahorradas, resultados de puntuación en 2 to 3 minutos; un modelo por desarrollador era el techo antes del cambio.
• Fuente: aws.amazon.com/solutions/case-studies/rare-job-case-study (2020).
• Ángulo de examen: el cuello de botella era el rendimiento de los experimentos, no la exactitud. Los trabajos Spot paralelos son la palanca de coste documentada para entrenar, y la misma lógica de «pagar capacidad interrumpida con un descuento» que convierte a un Savings Plan o a una estrategia Spot en una respuesta del Dominio 4 (coste).

14.4 Chronomics: cuatro meses de DIY frente a tres semanas de AutoML gestionado

• Servicios: Amazon Rekognition Custom Labels (AutoML), puntuado con DetectCustomLabels.
• Cifras: 4 meses de visión por computador personalizada interna nunca alcanzó el objetivo; Custom Labels se entregó en 3 to 4 semanas con 96,5 % de exactitud / F1 97,9 %. Subir el umbral de confianza a 0,99 da una precisión de 99,6 % mientras se descartan el 5 % de las predicciones; 0,999 da 99,87 % descartando el 27 %.
• Fuente: aws.amazon.com/blogs/machine-learning/chronomics-detects-covid-19-test-results-with-amazon-rekognition-custom-labels (2022).
• Ángulo de examen: dos lecciones. Primero, para una tarea de visión estrecha, la capa gestionada gana a una construcción interna: el patrón de fallo documentado es CV hecho a mano. Segundo, cada umbral que subes crea una cola descartada que necesita un camino humano (la razón por la que existe A2I), de modo que una pregunta de precisión es siempre también una pregunta de cobertura.

14.5 Sun Finance: un pipeline multi-paso donde el primer prototipo fue rechazado

• Servicios: Amazon Textract (OCR) → Amazon Rekognition (respaldo y comprobaciones faciales) → Claude Sonnet 4 (solo estructuración) → reglas de validación → Amazon Titan Multimodal Embeddings en S3 Vectors para similitud de fraude; construido con el AWS Generative AI Innovation Center, evaluado en 585 imágenes.
• Cifras: exactitud 79,73 % → 90,80 % (número de ID 74,32 → 89,40 %, tipo de documento 78,43 → 96,40 %), −91 % de coste por documento, 20 horas → menos de 5 segundos, detección de fraude 81 %. Intento 1, solo Claude Sonnet 4, obtuvo 61,8 % en general y 43 % en el número de ID y fue rechazado.
• Fuente: aws.amazon.com/blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (2026).
• Ángulo de examen: esto es una mentalidad de paso Condition en forma de producción: construir la baseline, medir, rechazar el intento fallido, re-arquitectar (separar el OCR del razonamiento), volver a medir. La evaluación es una fase, no una casilla, y la extracción de PII solo con LLM es el prototipo fallido documentado.

Tabla 14-A: Antes / después, exactamente como AWS los imprimió

Tabla 14-B: Elegir la capa: prefabricado → ML gestionado a medida → generativo

• 📚 ¿Sabías que…? AWS publica exactamente una cifra de tasa de producción para su propio trabajo de IA generativa: el 65 % de los proyectos del Generative AI Innovation Center llegaron a producción en 2025, de más de 1.000 implementaciones, con el más rápido en 45 días, y AWS enmarca el método como las Five V's: Value → Visualize → Validate → Verify → Venture. El número que vale la pena interiorizar es el otro 35 %: AWS espera que planifiques para proyectos que se estancan, y es por lo que baseline antes de construir y evaluación como fase aparecen en cada caso de arriba.

---

Preguntas de Práctica (Practice Questions)

---