Monitoreo y observabilidad en AWS: guía práctica para equipos cloud

Cuando un workload crítico falla a las 3 a.m., la diferencia entre 4 minutos y 40 minutos de downtime no está en cuántos dashboards tienes, sino en si puedes responder tres preguntas en segundos: qué está roto, dónde y por qué. Esa es la brecha real entre monitoreo y observabilidad, y es donde la mayoría de equipos en AWS pierde dinero sin darse cuenta.

En la práctica vemos dos extremos. Equipos que sobre-instrumentan todo con CloudWatch Logs, Metrics, X-Ray y una herramienta APM externa, y terminan con facturas de observabilidad que superan el costo del cómputo. Y equipos que solo miran CPU y memoria, y se enteran de un incidente por un cliente en soporte. Ninguno es sostenible.

Esta guía resume cómo estructurar monitoreo y observabilidad en AWS de forma útil: qué pilares cubrir, qué usar del stack nativo, cuándo tiene sentido Datadog o Grafana, cómo definir alertas que no generen fatiga, y cómo evitar que la factura de observabilidad se vuelva el segundo mayor costo de tu cuenta AWS.

Monitoreo vs observabilidad: diferencia

El monitoreo responde preguntas que ya sabes hacer: ¿está arriba el servicio?, ¿la latencia P95 está bajo 300 ms?, ¿hay errores 5xx? Opera sobre métricas predefinidas y dashboards conocidos. Funciona bien cuando el sistema es predecible.

La observabilidad responde preguntas que no anticipaste: ¿por qué este usuario específico vio timeout en el checkout a las 14:23 desde un dispositivo Android en Bogotá? Requiere datos lo suficientemente ricos como para explorar hipótesis nuevas sin desplegar código. En arquitecturas distribuidas —microservicios, Lambda, EKS, colas— el monitoreo clásico se queda corto porque los modos de falla son combinatorios.

En AWS esto se traduce así: CloudWatch Metrics es monitoreo. CloudWatch Logs Insights + X-Ray trace search + métricas de alta cardinalidad empiezan a ser observabilidad. No es una u otra; es una progresión según la criticidad y complejidad del sistema.

Los 3 pilares: logs, métricas, traces

La taxonomía estándar —popularizada por el libro Distributed Systems Observability de Cindy Sridharan— divide la señal en tres pilares:

• Métricas: series temporales numéricas agregadas (CPU, latencia, RPS). Baratas de almacenar, rápidas de consultar, pobres en contexto.
• Logs: eventos discretos con texto estructurado. Ricos en contexto, caros a escala, difíciles de agregar si no están estructurados en JSON.
• Traces: el recorrido de una request a través de múltiples servicios, con timing por span. Clave para entender latencia en sistemas distribuidos.

Una regla práctica: métricas para saber que algo pasa, logs para saber qué pasó, traces para saber dónde pasó. Si tu equipo solo tiene logs, está pagando mucho por poca respuesta. Si solo tiene métricas, está ciego ante incidentes nuevos.

La tendencia actual es unificar los tres bajo OpenTelemetry como estándar de instrumentación, lo cual te permite cambiar el backend (CloudWatch, Datadog, Grafana) sin reescribir código.

Stack nativo AWS: CloudWatch, X-Ray, CloudTrail

AWS ofrece un stack completo que muchos equipos subutilizan. Los componentes clave:

• CloudWatch Metrics: métricas nativas de todos los servicios AWS más custom metrics. Soporta métricas de alta resolución (1 segundo) y Metric Math para combinaciones.
• CloudWatch Logs + Logs Insights: ingesta de logs con query language propio. Útil para búsquedas ad-hoc sin mover data.
• CloudWatch Alarms: alarmas basadas en umbrales o anomaly detection (ML) sobre cualquier métrica.
• AWS X-Ray: distributed tracing integrado con Lambda, API Gateway, ECS, EKS. Mapea dependencias y latencia por segmento.
• CloudTrail: no es observabilidad de performance sino de quién hizo qué en la cuenta. Crítico para auditoría y forense de seguridad.
• CloudWatch Synthetics + RUM: monitoreo sintético (canaries) y real user monitoring para frontends.

Para la mayoría de cargas de trabajo medianas, este stack basta. Se vuelve limitado cuando necesitas correlación cross-cuenta agresiva, dashboards muy personalizados o retención larga de logs a costo razonable. Si estás planeando una migración a AWS, vale la pena dejar la estrategia de observabilidad definida antes de mover workloads; lo cubrimos en detalle en nuestra guía empresarial de migración a AWS.

Alternativas: Datadog, New Relic, Grafana+Prometheus

Cuando el stack nativo no alcanza, hay tres caminos comunes:

Datadog. APM maduro, UX superior, correlación automática logs-métricas-traces. Es el estándar de facto en empresas que quieren sacrificar costo por velocidad de implementación. Su pricing por host + por custom metric + por log ingerido escala agresivamente; sin gobernanza, los costos pueden superar [VERIFICAR: múltiplo habitual de lo que costaría CloudWatch equivalente, idealmente con fuente Datadog pricing 2025] el equivalente en CloudWatch.

New Relic. Competidor directo de Datadog con modelo de pricing basado en usuarios + GB ingeridos, que a veces resulta más predecible. Buena opción cuando el equipo de SRE es chico y el volumen de data es alto.

Grafana + Prometheus (+ Loki + Tempo). Open source, self-hosted o con Grafana Cloud / Amazon Managed Grafana + Amazon Managed Service for Prometheus. Pricing más lineal, control total, pero exige madurez operativa. Ideal para equipos con plataforma de Kubernetes consolidada.

La decisión no es técnica sino de TCO y madurez. Un equipo de 5 ingenieros con 20 servicios rara vez justifica self-hosting; uno de 50 ingenieros con 300 servicios sí.

Alertas que sí importan (y las que son ruido)

La fatiga por alertas es la causa silenciosa de incidentes mal manejados. Si tu canal de #alerts recibe más de 10 notificaciones al día que nadie acciona, el problema no es la gente: es el sistema de alertas.

Criterios para una alerta útil:

• Accionable: si dispara, alguien debe hacer algo concreto en minutos. Si no, es un dashboard, no una alerta.
• Ligada a experiencia del usuario: latencia P95 de checkout, tasa de error de login, disponibilidad de API pública. No CPU al 80% por sí sola.
• Con contexto en el payload: runbook link, servicio afectado, severidad, owner.
• Sin duplicados: una falla raíz no debe generar 40 alertas en cascada. Usa alarm composite en CloudWatch o dependencias en Datadog.

Una heurística: si durante la última guardia tu equipo silenció o ignoró más del 30% de las alertas recibidas, revisa umbrales antes de agregar más monitoreo. Y prefiere alertar sobre síntomas (lo que el usuario percibe) antes que sobre causas (lo que pasa internamente); las causas van al dashboard de diagnóstico.

SLI, SLO, error budget

El marco SRE popularizado por Google convierte la discusión de "cuándo alertar" en una decisión de negocio.

• SLI (Service Level Indicator): la métrica que refleja experiencia del usuario. Ej: % de requests exitosas en < 500 ms.
• SLO (Service Level Objective): el objetivo sobre el SLI. Ej: 99.5% mensual.
• Error budget: el complemento del SLO. Si tu SLO es 99.5%, tu presupuesto de error es 0.5% del mes (~3.6 horas). Ese presupuesto se consume con incidentes, deploys fallidos o degradación.

Cuando el error budget se está agotando, la política es clara: se congela shipping de features y el equipo prioriza confiabilidad. Cuando sobra, se puede asumir más riesgo. Esto evita las discusiones subjetivas de "¿es estable el sistema?".

En AWS, CloudWatch permite construir SLIs básicos con métricas personalizadas. Para SLO tracking serio, herramientas como Nobl9, Datadog SLO o los SLO de Grafana son más completas. Empieza con 3-5 SLOs para tus servicios más críticos, no con 50.

Costos de observabilidad: pitfalls

La factura de observabilidad puede pasar del 3% al 15% del gasto cloud sin que nadie lo note. Los pitfalls más comunes:

Pitfall	Costo oculto
Logs sin estructurar y sin filtro en la app	Ingesta 5-10x mayor a la necesaria
Retención por defecto en CloudWatch Logs (never expire)	Storage acumulado crece indefinidamente
Custom metrics de alta cardinalidad	En Datadog, cada combinación de tags es una métrica facturable
X-Ray sin sampling	100% de traces es caro e innecesario; sampling del [VERIFICAR: 5-10% típico recomendado AWS para producción] suele ser suficiente
DEBUG logs en producción	Multiplica ingesta sin valor operativo

Recomendaciones prácticas: define retención por log group (7/30/90/365 días según criticidad), muestrea traces agresivamente, exporta logs fríos a S3 + Athena en vez de dejarlos en CloudWatch Logs, y audita trimestralmente las custom metrics que nadie consulta. Este tipo de optimización se integra bien con una práctica FinOps; lo desarrollamos en FinOps en AWS: optimización de costos.

Una regla útil: la observabilidad debería costar entre el 3% y el 7% del gasto de cómputo. Si estás arriba del 10%, hay ingesta sin propósito.

Próximo paso

Si estás diseñando la estrategia de observabilidad de una plataforma crítica en AWS —o corrigiendo una que se volvió ruidosa y cara— podemos ayudarte a estructurarla con SLOs, alertas accionables y control de costos. Contáctanos para un diagnóstico de 30 minutos con un ingeniero cloud senior.

Preguntas frecuentes

¿CloudWatch es suficiente o necesito Datadog?

Para la mayoría de equipos medianos con cargas AWS-nativas, CloudWatch + X-Ray cubre bien logs, métricas y traces. Datadog aporta valor cuando necesitas correlación automática muy rápida, UX superior para investigación de incidentes, o cuando operas multi-cloud. La decisión es de TCO y madurez del equipo, no puramente técnica.

¿Qué es más importante: logs, métricas o traces?

Depende de la arquitectura. En un monolito, métricas + logs estructurados suele bastar. En microservicios o arquitecturas event-driven, los traces son críticos para entender latencia y fallos distribuidos. El estándar moderno es instrumentar los tres con OpenTelemetry desde el inicio.

¿Cómo defino un buen SLO?

Empieza por un SLI que refleje experiencia real del usuario (latencia de una operación clave, tasa de éxito de una transacción), mide el baseline actual durante 2-4 semanas, y fija el SLO ligeramente por debajo del baseline para que sea alcanzable pero ambicioso. Evita SLOs de 99.99% sin justificación de negocio: son caros de mantener.

¿Cuánto debería costar la observabilidad?

Un rango sano es 3%-7% del gasto de cómputo cloud. Arriba del 10% suele indicar ingesta sin propósito: logs DEBUG en producción, métricas de alta cardinalidad sin uso, o retención excesiva. Una auditoría trimestral de log groups y custom metrics suele recuperar gasto significativo.

¿Qué hago con las alertas que nadie atiende?

Silenciarlas no es la solución. Revísalas en retrospectivas: si no son accionables, conviértelas en dashboards o elimínalas. Si son accionables pero se ignoran, el problema es de ownership o runbooks. Una alerta sin dueño claro y sin pasos concretos no es una alerta, es ruido.

¿OpenTelemetry vale la pena adoptarlo hoy?

Sí, especialmente para instrumentación nueva. Es el estándar que soportan CloudWatch, X-Ray, Datadog, New Relic y Grafana, lo cual te da portabilidad real entre backends. El esfuerzo inicial de configuración se paga la primera vez que cambias de herramienta o agregas una nueva sin reinstrumentar.