Amazon CloudWatch a fondo: guía completa de diseño de monitorización / logs / métricas, comparada con Cloud Monitoring (GCP) y Azure Monitor

Introducción (resumen de puntos clave)

• En este artículo tomaremos Amazon CloudWatch como eje principal y, comparándolo con Google Cloud Monitoring / Cloud Logging y Azure Monitor / Log Analytics, vamos a organizar cuidadosamente el diseño global de monitorización, logs, métricas y alertas.
• CloudWatch es la plataforma estándar de monitorización de AWS, que cubre en un único servicio recogida de métricas, agregación de logs, alarmas, dashboards, trazas (vía X-Ray) e integración de eventos.
• En GCP, Cloud Monitoring + Cloud Logging cumplen el mismo papel, y en Azure lo hacen Azure Monitor + Log Analytics / Application Insights. En todas las nubes, la esencia está en cómo combinas métricas + logs + eventos + visualización + notificaciones.
• Los puntos clave de diseño son:
  1. Qué monitorizas (cómo defines SLO/SLI)
  2. Con qué granularidad recoges métricas y logs
  3. Qué se alerta automáticamente y qué requiere juicio humano
  4. Para quién son tus dashboards y cómo los construyes
  5. Cómo equilibras coste y rendimiento (volumen y retención de logs)
• Este artículo está escrito para SRE, ingenieros de infra / plataforma, desarrolladores de aplicaciones web/enterprise, ingenieros de plataformas de datos, personal de seguridad/gobernanza, equipos de operaciones de TI corporativa y tech leads de startups.
• El objetivo es que al final seas capaz de diseñar plataformas de monitorización en GCP y Azure usando casi el mismo modelo mental, con CloudWatch como punto de referencia.

1. ¿Qué es Amazon CloudWatch? Una única “landing zone” para la monitorización

Amazon CloudWatch es un servicio gestionado de monitorización que recopila métricas (números), logs y eventos de recursos y aplicaciones en AWS, y ofrece sobre ellos alarmas, visualización y acciones automatizadas.

Dado que muchos servicios como EC2, RDS y Lambda empujan métricas estándar automáticamente a CloudWatch, se puede decir que puedes partir de la mentalidad “envía todo primero a CloudWatch y luego decide qué hacer con ello”.

Funciones representativas:

• Métricas: utilización de CPU, I/O de disco, longitud de colas SQS, métricas personalizadas, etc., recogidas en intervalos de 1 o 5 minutos.
• Logs: agregados en grupos de CloudWatch Logs a partir de logs de aplicaciones, logs de SO, logs de ALB / CloudFront, etc.
• Alarmas: alertas basadas en umbrales construidas a partir de métricas o métricas derivadas de logs, que envían notificaciones vía SNS u otras herramientas de operaciones.
• Dashboards: “paneles de estado” que visualizan métricas y alarmas en un solo lugar.
• Eventos / integración con EventBridge: ejecutar Lambda o Step Functions cuando cambie el estado de un recurso o según eventos programados.

En GCP, Cloud Monitoring (antes Stackdriver Monitoring) gestiona métricas y alertas, y Cloud Logging gestiona logs; en Azure, Azure Monitor es la plataforma de métricas y Log Analytics / Application Insights cubren logs y trazas. Conceptualmente, juegan los mismos roles.

2. Antes de diseñar la monitorización: empieza por SLO/SLI (¿qué quieres ver?)

Antes de memorizar funcionalidades de herramientas de monitorización, primero tienes que decidir qué es lo que realmente quieres monitorizar.

2.1 SLO (Service Level Objectives) y SLI (Service Level Indicators)

• SLI: métrica (indicador) que expresa la calidad del servicio.
  • Ejemplos:
    • “Tasa de peticiones exitosas por minuto”
    • “Latencia p95”
    • “Tasa de errores”
    • “Tiempo medio de finalización de jobs”
• SLO: Objetivo que define cuánta desviación toleras para un SLI.
  • Ejemplos:
    • “Tasa de éxito HTTP ≥ 99,9% en 90 días”
    • “Latencia p95 menor de 500 ms”

En CloudWatch, puedes convertir estos objetivos en métricas y conectarlas a alarmas, enlazando tus operaciones diarias directamente con tus SLO.

En GCP Cloud Monitoring y Azure Monitor, de forma similar expresas los SLI como métricas de monitorización o consultas KQL y luego reflejas los SLO en las condiciones de alerta o vistas de SLO.

2.2 Separa “métricas de infraestructura” de “métricas de experiencia de usuario”

• Lado infraestructura: CPU, uso aproximado de memoria, I/O de disco, ancho de banda de red, número de contenedores, longitud de colas, etc.
• Lado aplicación / experiencia de usuario: tasa de errores, latencia, revenue / conversiones, tasa de éxito de login, etc.

En CloudWatch, distingue conscientemente entre métricas de infra (proporcionadas por AWS) y métricas personalizadas del lado de la app, y céntrate en alertar sobre las métricas que reflejen directamente la experiencia de usuario. Así evitas la fatiga por alertas.

3. Métricas de CloudWatch: tres pilares — estándar, personalizadas y derivadas de logs

3.1 Métricas estándar

Los servicios de AWS envían métricas estándar a CloudWatch automáticamente. Por ejemplo:

• EC2: CPUUtilization, NetworkIn/Out, StatusCheckFailed, etc.
• RDS: CPUUtilization, FreeStorageSpace, DatabaseConnections, etc.
• Lambda: Invocations, Errors, Duration, Throttles, etc.
• ALB/NLB: RequestCount, TargetResponseTime, HTTPCode_ELB_5XX, etc.
• SQS: ApproximateNumberOfMessagesVisible, etc.

Estas métricas están disponibles sin coste adicional (algunas métricas de alta frecuencia se facturan), así que el camino más rápido es construir tus primeros dashboards alrededor de las métricas estándar.

3.2 Métricas personalizadas

Indicadores específicos de la aplicación (p. ej. número de pedidos, logins fallidos, tiempo de procesamiento de batches) pueden enviarse a CloudWatch usando PutMetricData (API/SDK) o CloudWatch Agent.

• Ejemplo de namespace: MyApp/Orders
• Ejemplo de dimensiones: service=frontend, region=ap-northeast-1

En GCP, puedes enviar métricas personalizadas a Cloud Monitoring; en Azure, puedes hacer lo mismo hacia Azure Monitor. La idea es idéntica: expresar éxito/fracaso/latencia de la aplicación numéricamente y ligarlo a los SLO.

3.3 Métricas derivadas de logs (log-based metrics)

Puedes crear metric filters en CloudWatch Logs para convertir patrones de log en métricas.

• Ejemplos:
  • Contar entradas de log que representen errores HTTP 500 y crear una métrica App/5xxCount, y luego construir una alerta de tasa de errores.
  • Contar logs de “payment failure” como una métrica y detectar picos anómalos.

GCP Cloud Logging + Cloud Monitoring y Azure Log Analytics también tienen mecanismos para convertir resultados de consultas de logs en métricas y alertas.

4. CloudWatch Logs: agregación, búsquedas, filtros y retención

4.1 Log groups y log streams

CloudWatch Logs organiza los logs con una jerarquía de log groups → log streams.

• Log group: unidad como una app o servicio (p. ej. /aws/lambda/app-api)
• Log stream: unidades más finas, como IDs de instancia, IDs de contenedor o fechas

Si decides la granularidad y agrupación de logs de antemano, las operaciones diarias se vuelven mucho más sencillas.

4.2 Cómo se recogen los logs

• CloudWatch Agent:
  • Recoge logs de ficheros y métricas de SO desde EC2 y entornos on-prem.
• Integraciones de servicio:
  • Lambda, API Gateway, ECS, EKS, RDS (logs mejorados), ALB, WAF, VPC Flow Logs, etc. se pueden configurar para enviar directamente a CloudWatch Logs.
• Fluent Bit / Fluentd / OpenTelemetry Collector:
  • Opciones habituales para enrutar logs desde entornos de contenedores a CloudWatch Logs.

En GCP se utiliza el agente de Logging o el Ops Agent; en Azure, el Log Analytics agent o Azure Monitor Agent. Es el mismo concepto.

4.3 Retención de logs y ciclo de vida

CloudWatch Logs permite establecer periodos de retención por log group.

• Logs de aplicaciones en producción: 30–90 días
• Logs de seguridad / auditoría: 6–24 meses (suele ser más barato exportarlos a S3 o equivalente para almacenamiento a largo plazo)

Para retención a largo plazo, un patrón común es exportar periódicamente los logs a S3 y consultarlos con Athena. GCP tiene exportaciones de Logging a Cloud Storage; Azure permite exportar desde Log Analytics a cuentas de almacenamiento, cumpliendo el mismo papel.

5. Alarmas y notificaciones: cómo elegir umbrales

5.1 Fundamentos de CloudWatch Alarm

Una alarma de CloudWatch pasa a estado ALARM cuando una métrica cumple una condición dada.

• Condiciones de ejemplo:
  • CPUUtilization > 80% durante 5 minutos consecutivos
  • Tasa de errores 5xx > 1% en al menos 2 de los últimos 10 minutos
  • App/LoginFailureCount supera 50 eventos en 1 minuto

Cuando una alarma se dispara, puedes notificar vía SNS (email, Slack, PagerDuty, etc.), o usarla como trigger para Lambda o políticas de Auto Scaling de EC2.

5.2 Evitar la fatiga por alertas

• Solo alertar sobre condiciones que deberían cambiar el comportamiento humano o del sistema
  • “CPU por encima del 70%” por sí sola rara vez es accionable; céntrate en métricas de SLI que impacten al usuario.
• Usar niveles de aviso (warning) vs crítico
  • Gestiona incidencias menores en revisiones del día siguiente; reserva los avisos nocturnos para eventos realmente críticos.
• Silenciar y revisar reglas ruidosas
  • Para reglas con falsos positivos frecuentes, pausa y revisa umbrales, ventanas temporales y métricas elegidas.

GCP y Azure tienen políticas de alerta muy flexibles; los principios son idénticos.

6. Dashboards y visualización: ten claro para quién es cada pantalla

6.1 CloudWatch Dashboards

CloudWatch Dashboards te permiten combinar múltiples métricas, alarmas y widgets en una única vista.

• Tipos de dashboard de ejemplo:
  • Equipo de plataforma: CPU / red / tasa de errores / número de alarmas a nivel global
  • Equipo de producto: latencia, tasa de errores, número de pedidos, ingresos para un servicio concreto
  • Dirección ejecutiva: unos pocos KPI de negocio clave y una vista de disponibilidad de alto nivel

6.2 Comparando dashboards en las tres nubes

• CloudWatch Dashboards: paneles centrados en métricas y alarmas.
• Dashboards de Cloud Monitoring (GCP): combinan métricas, indicadores derivados de logs, Uptime Checks, etc.
• Dashboards / Workbooks de Azure: visualizaciones ricas que mezclan métricas de Azure Monitor, consultas de Log Analytics y datos APM.

Independientemente de la plataforma, los dashboards mejoran cuando defines con precisión el público objetivo y recortas el contenido a lo que ese público realmente necesita.

7. Trazas distribuidas y unión con logs: X-Ray / Cloud Trace / Application Insights

Con microservicios, Lambda y colas de mensajes, las métricas y logs simples a menudo no bastan para ver dónde se introduce la latencia.

• AWS: conecta AWS X-Ray con CloudWatch Logs, incluye IDs de traza en los logs, y podrás visualizar por qué servicios ha pasado una petición y dónde ha invertido el tiempo.
• GCP: utiliza Cloud Trace / Cloud Profiler junto con Cloud Logging.
• Azure: las trazas de Application Insights se integran con Log Analytics.

CloudWatch en sí no es un motor de trazas, pero al enlazar logs/métricas con trazas mediante identificadores, simplificas mucho el análisis de causa raíz (RCA).

8. Diseño de costes: encontrar la “cantidad adecuada” de métricas, logs y dashboards

Las plataformas de monitorización son un área donde el coste tiende a crecer cuanto más las usas.

8.1 Principales factores de facturación de CloudWatch

• Métricas (muchas métricas estándar tienen capa gratuita; las métricas de alta resolución pueden tener coste)
• Métricas personalizadas
• Volumen de ingesta y almacenamiento de logs, y periodo de retención
• Número de dashboards
• Número de alarmas (para algunas funcionalidades)

8.2 Formas de controlar costes

1. No crees métricas personalizadas innecesarias
   • Usa métricas derivadas de logs cuando tenga sentido; busca el equilibrio.
2. Establece la retención en función del propósito del log
   • Logs de depuración de apps: solo a corto plazo
   • Logs de seguridad: retención corta en CloudWatch; archivo a largo plazo en S3, etc.
3. Reserva las métricas de alta frecuencia para donde realmente aporten valor
   • No bajes a granularidad de 10 segundos si 1 minuto es suficiente.
4. Limpia periódicamente dashboards y alarmas
   • Elimina paneles y reglas de alarma que ya no se usen.

En GCP y Azure pasa lo mismo: el volumen y la retención de logs/métricas impulsan directamente el coste, así que es vital decidir “cuánto conservar” desde el principio.

9. Patrones de diseño: tres “arquitecturas de monitorización” de ejemplo

9.1 Servicios web/API pequeños o medianos

• Objetivo: Que un servicio web/API desarrollado por uno o pocos equipos se mantenga estable.
• Configuración en AWS:
  • Métricas de CloudWatch: métricas estándar de EC2/LB/RDS/Lambda + métricas personalizadas de app (tasa de errores, latencia, etc.)
  • CloudWatch Logs: logs de app y logs de acceso de ALB
  • Alarmas: métricas basadas en SLO (tasa de éxito, latencia) e incidencias críticas de infra (p. ej. disco al límite)
  • Dashboards: uno o dos paneles centrados en el equipo + una vista global

En GCP harías lo mismo con Cloud Monitoring + Logging; en Azure, con Azure Monitor + Log Analytics.

9.2 Jobs batch y pipelines de datos

• Objetivo: Hacer visible el éxito/fracaso de batches nocturnos, ETL o jobs de streaming.
• Configuración:
  • Métricas: número de jobs, fallos, tiempo de procesamiento, latencia
  • Logs: recopilar logs por paso en CloudWatch Logs y crear métricas derivadas de patrones de fallo
  • Alarmas: notificar cuando los jobs no finalicen en un intervalo dado o se dispare la tasa de fallos

En GCP (Dataflow / Composer) y Azure (Data Factory, etc.), envías métricas/logs a Cloud Monitoring / Azure Monitor de la misma forma.

9.3 Entornos multi-cuenta / multi-cloud

• Objetivo: Monitorizar varias cuentas de AWS, o AWS + GCP + Azure en conjunto.
• Idea de arquitectura:
  • Exportar métricas/logs de cada CloudWatch / Cloud Monitoring / Azure Monitor a una plataforma compartida de visualización (por ejemplo, Grafana, Datadog).
  • Aun así, mantener la monitorización nativa en cada nube para aprovechar las funciones específicas de cada servicio.

CloudWatch, Cloud Monitoring y Azure Monitor soportan exportes/APIs para alimentar sistemas externos, lo que facilita diseños “de dos niveles”.

10. Ejemplos prácticos de configuración en CloudWatch

Para aterrizar lo anterior, unos ejemplos sencillos.

10.1 Enviar una métrica personalizada (SDK de Python)

import boto3, time

cloudwatch = boto3.client("cloudwatch", region_name="ap-northeast-1")

def put_order_count(count: int):
    cloudwatch.put_metric_data(
        Namespace="MyApp/Orders",
        MetricData=[
            {
                "MetricName": "OrderCreated",
                "Dimensions": [
                    {"Name": "service", "Value": "web"},
                    {"Name": "env", "Value": "prod"},
                ],
                "Timestamp": time.time(),
                "Value": count,
                "Unit": "Count",
            }
        ],
    )

10.2 Ejemplo de metric filter (contar errores 5xx a partir de logs)

aws logs put-metric-filter \
  --log-group-name "/aws/lambda/app-api" \
  --filter-name "5xx-count" \
  --filter-pattern '\"status\":5*' \
  --metric-transformations \
    metricName=Lambda5xxCount,metricNamespace=MyApp/API,metricValue=1

Luego puedes crear una alarma sobre MyApp/API Lambda5xxCount para disparar cuando aumenten los errores 5xx, facilitando la detección rápida de anomalías en la aplicación.

11. Errores frecuentes y cómo evitarlos

• Solo monitorizar métricas de infra y olvidarse de la experiencia de usuario
  • Solución: añade tasa de errores, latencia y métricas de negocio como métricas personalizadas y diseña alertas en torno a los SLO.
• Volcar todos los logs en CloudWatch y sufrir búsquedas lentas y costes altos
  • Solución: agrupa los logs por tipo, establece retención según propósito y archiva los logs de largo plazo en S3.
• Tantas alertas que nadie les hace caso
  • Solución:
    • Trata las alertas no relacionadas con SLI como “Warnings” a revisar diaria/semanalmente.
    • Pausa temporalmente las reglas ruidosas y revisa sus SLO/umbrales.
• Dashboards fragmentados entre equipos de dev y de ops
  • Solución: crea un dashboard de SLO compartido, y sobre él añade paneles específicos por equipo.

12. ¿Quién gana qué? (beneficios por rol)

• SRE / ingenieros de plataforma
  • Obtienes un patrón sólido para diseñar métricas, logs, alarmas y dashboards alrededor de CloudWatch. El mismo patrón escala entre nubes, reduciendo la carga operativa.
• Desarrolladores de aplicaciones
  • Puedes ver cómo se comporta tu código en producción mediante métricas y logs de CloudWatch, y te acercas a ser un ingeniero que piensa en términos de SLI.
• TI corporativa / operaciones
  • Puedes mezclar CloudWatch, Cloud Monitoring y Azure Monitor y aún así trazar una línea realista de “esto es suficiente monitorización”. Además, simplifica auditorías e informes de incidentes.
• Equipos de seguridad / gobernanza
  • El tratamiento de logs de auditoría, logs de acceso e historiales de cambios, y sus estrategias de retención, se vuelve más claro, facilitando cerrar la brecha entre políticas e implementación.
• Tech leads en startups
  • Incluso con un equipo pequeño, puedes construir una plataforma de monitorización “seria” centrada en CloudWatch, y sabrás cómo extender el mismo diseño a GCP y Azure a medida que creces.

13. Tres cosas que puedes hacer hoy mismo

1. Define solo uno o dos SLO/SLI
   • p. ej., Tasa de éxito 99,9%, latencia p95 500 ms.
2. Crea una única métrica de CloudWatch que represente ese SLI
   • Usa una métrica derivada de logs o una métrica personalizada — empieza solo con una.
3. Construye una alarma y un dashboard sencillo para esa métrica
   • Con esto ya pasas de “mirar métricas al azar” a “seguir objetivos vs realidad”.

14. Conclusión: CloudWatch es el hub que conecta números, logs y eventos

Amazon CloudWatch es mucho más que una herramienta de recogida de métricas. Centraliza:

• Métricas (SLI/SLO)
• Logs (contexto)
• Alarmas (disparadores de acción)
• Dashboards (visibilidad compartida)
• Eventos (acciones automatizadas)

En resumen, es el hub operacional de tu entorno AWS.

GCP Cloud Monitoring/Logging y Azure Monitor/Log Analytics cumplen el mismo propósito. Una vez que aprendes cómo diseñar qué indicadores recoger y cómo actuar sobre ellos, tus conocimientos se transfieren entre nubes.

Combinando los servicios que ya hemos cubierto — S3, EC2, Lambda, RDS, VPC, CloudFront — y ahora CloudWatch, deberías ver ya el camino hacia una plataforma coherente “visible, protegida y escalable” desde la infra → app → frontend → monitorización.

En el próximo capítulo veremos AWS IAM (identity and access management) y, comparándolo con Cloud IAM (GCP) y Azure AD / Entra ID + RBAC, profundizaremos en diseño de permisos, diseño de roles y cómo usar identidades para un futuro zero trust.