Métricas y logs de CloudWatch

Todos los demás temas de este curso terminan leyendo un número o una línea de log de CloudWatch. Una política de escalado necesita una métrica. Un runbook de remediación necesita un evento. Un ajuste de rendimiento necesita la prueba de que funcionó. Este tema construye esa base: qué mide AWS por ti, qué tienes que instrumentar tú y cómo sacar una respuesta del resultado sin perder tiempo.

También traza la línea sobre la que giran muchas preguntas del examen. CloudWatch registra qué están haciendo tus recursos. CloudTrail registra quién les pidió que lo hicieran. Los dos están acá, porque los incidentes normalmente necesitan ambos.

Qué cubre este tema

• Identidad y almacenamiento de una métrica: namespaces, dimensiones, resolución, estadísticas y percentiles, y el rollup de retención que decide qué vas a poder consultar meses después
• Estructura y retención de CloudWatch Logs, más las tres formas en que los datos de log se vuelven útiles: metric filters, subscription filters y consultas de Logs Insights
• Desplegar el agente unificado de CloudWatch en toda una flota con Systems Manager y Parameter Store, y el límite de IAM entre la política de servidor y la de administrador
• CloudTrail para operaciones: historial de eventos frente a trails, los cuatro tipos de evento, organization trails, CloudTrail Lake y cómo alarmar sobre la actividad de la cuenta
• Telemetría de contenedores con Container Insights en ECS y EKS, y cuándo Amazon Managed Service for Prometheus con Amazon Managed Grafana encaja mejor
• Monitoreo serverless y de IA: métricas de Lambda y la trampa de throttle contra error, Lambda Insights, X-Ray, el desglose de latencia de API Gateway y el seguimiento del uso de Amazon Bedrock

Por qué importa

Las preguntas de esta parte del examen son diagnósticas, no de definición. Te dan un síntoma (una alarma atascada en INSUFFICIENT_DATA, una instancia EC2 sin métrica de memoria, una función Lambda cuyos logs nunca aparecen, una tasa de error que se ve sana mientras los usuarios reportan fallas) y te preguntan qué revisar. Reconocer nombres de servicios no te lleva ahí.

Lo que sí te lleva es saber qué métricas publica AWS de forma predeterminada, cuáles necesitan un agente, qué funcionalidades están apagadas hasta que alguien las enciende y cuánto sobrevive cada tipo de dato. Ese conocimiento también es el núcleo del trabajo diario de CloudOps, y pasa directo a las alarmas, al auto scaling y a la remediación automática de los temas que siguen.