Tres monitores de red en CloudWatch: cual usar y cuando
Amazon CloudWatch tiene tres funciones de monitoreo de red con nombres que se parecen: Network Flow Monitor, Network Synthetic Monitor, e Internet Monitor. Los tres miden rendimiento de red. Los tres escriben a CloudWatch. Y los tres resuelven problemas distintos. El error comun es habilitar el equivocado, o habilitar los tres sin saber que hace cada uno, y terminar con datos que no responden la pregunta que tenias. Este post es como elegir el correcto en una sola decision.
El problema: tres monitores con nombres parecidos
Si abres la seccion de monitoreo de red en la consola de Amazon CloudWatch, ves tres opciones. La documentacion las lista y explica cada una por separado, pero no te dice cual elegir cuando tienes un problema concreto. Asi que la gente habilita el que suena mejor, o los tres por si acaso, y despues no sabe cual mirar cuando la aplicacion va lenta.
La buena noticia es que la eleccion se reduce a una sola pregunta.
La pregunta que decide: donde vive el trafico
Antes de comparar metricas o agentes, responde esto: donde esta el tramo de red que te preocupa.
- Dentro de AWS, entre tus recursos y hacia otros servicios de AWS.
- En el enlace hibrido, entre AWS y tu centro de datos on-premises.
- En el internet publico, entre tu aplicacion y los usuarios finales.
Cada tramo tiene su monitor. Esa es la decision principal. La segunda pregunta, activo o pasivo, solo desempata en casos de borde.
Network Flow Monitor: tu trafico dentro de AWS
Network Flow Monitor da visibilidad casi en tiempo real del rendimiento de red del trafico entre instancias de Amazon EC2, y hacia otros servicios de AWS como Amazon S3 y Amazon DynamoDB. Funciona con agentes ligeros administrados que instalas en tus instancias de Amazon EC2 y Amazon EKS. Esos agentes recolectan estadisticas de las conexiones TCP y las envian al backend de Network Flow Monitor.
Metricas que rastrea: datos transferidos, retransmisiones, tiempos de espera de retransmision (retransmission timeouts), y round-trip time. Ademas produce un Network Health Indicator (NHI), que te dice si una degradacion viene de la infraestructura de AWS o de tu lado.
Cuando lo eliges: el trafico que te preocupa vive dentro de AWS, tienes cargas TCP en EC2 o EKS, y puedes instalar agentes. Es monitoreo pasivo, del trafico real de tu carga, no de trafico sintetico.
Network Synthetic Monitor: el enlace hibrido
Network Synthetic Monitor rastrea y visualiza latencia y perdida de paquetes en conexiones de red hibridas, es decir, entre AWS y destinos on-premises. En vez de medir el trafico real, crea sondas (probes) que se envian desde tus recursos alojados en AWS hacia direcciones IP de destino on-premises. Es monitoreo activo: genera trafico de prueba para medir el camino.
Esta administrado por AWS y no requiere que instales un agente separado en los recursos monitoreados; defines las sondas dando una subred de VPC y las IPs de destino. Cuando te conectas mediante AWS Direct Connect, tambien escribe un Network Health Indicator a tu cuenta de CloudWatch para diagnosticar rapido si la degradacion esta dentro de la red de AWS.
Cuando lo eliges: tienes conectividad hibrida (AWS Direct Connect o AWS Site-to-Site VPN) y quieres saber si ese enlace entre la nube y tu centro de datos esta degradado, con latencia y perdida de paquetes continuas.
Internet Monitor: el ultimo tramo hasta el usuario
Internet Monitor usa los datos de conectividad que AWS captura de su huella de red global para calcular una linea base de rendimiento y disponibilidad del trafico de cara a internet. No mides tu red: mides el tramo de internet publico entre tu aplicacion y tus usuarios finales, desglosado por ciudad-red, es decir la combinacion de ubicacion del cliente y ASN (tipicamente el proveedor de internet o ISP).
Es completamente pasivo y sin agentes. Asocias los recursos de tu aplicacion (VPCs, Network Load Balancers, distribuciones de Amazon CloudFront, o directorios de Amazon WorkSpaces) a un monitor, y AWS publica las mediciones de internet especificas de las ciudades-red donde tus clientes acceden. Ademas sugiere mejoras, como enrutar por otra Region de AWS o usar Amazon CloudFront para reducir latencia, y envia eventos de salud a Amazon EventBridge para notificaciones.
Cuando lo eliges: tus usuarios finales se quejan de lentitud y quieres saber si el problema es un ISP especifico o una geografia, no algo dentro de tu infraestructura.
La tabla de decision
| Network Flow Monitor | Network Synthetic Monitor | Internet Monitor | |
|---|---|---|---|
| Tramo de red | Dentro de AWS (EC2, EKS, hacia S3/DynamoDB) | Enlace hibrido (AWS a on-premises) | Internet publico (app a usuarios) |
| Metodo | Pasivo, del trafico real | Activo, sondas | Pasivo, huella global de AWS |
| Agente | Agentes administrados en las instancias | Sin agente extra (sondas desde subred VPC) | Sin agente, sin instrumentacion |
| Metricas clave | Retransmisiones, RTT, datos transferidos, NHI | Latencia, perdida de paquetes, NHI | Rendimiento y disponibilidad por ciudad-red (ubicacion + ISP) |
| Que responde | Donde enfocar el troubleshooting en tu red AWS | Si el enlace hibrido esta degradado | Si el problema es un ISP o una geografia |
El arbol de decision es corto. Primero: donde vive el trafico (dentro de AWS, hibrido, o internet). Eso ya te deja un solo monitor en la mayoria de los casos. Si dudas entre dos, pregunta si quieres medir el trafico real de tu carga (pasivo, Flow Monitor) o probar activamente un camino (activo, Synthetic Monitor).
Se complementan, no compiten
No es una eleccion excluyente. Los tres publican metricas a CloudWatch y soportan alarmas, asi que puedes correr mas de uno a la vez y verlos en el mismo dashboard. Una investigacion realista de una mala experiencia de usuario los recorre en orden, de afuera hacia adentro:
- Internet Monitor te dice si el problema esta en el internet publico, en un ISP o una geografia especifica. Si ahi esta limpio, el problema es tuyo.
- Network Synthetic Monitor te dice si el enlace hibrido hacia tu centro de datos esta perdiendo paquetes o sumando latencia.
- Network Flow Monitor te dice, dentro de AWS, entre cuales recursos estan las retransmisiones y el RTT alto, y con el NHI si es infraestructura de AWS.
Tres capas, una pregunta en cada una, y CloudWatch como el lugar donde convergen.
Lo que cada uno no hace (limitaciones honestas)
Network Flow Monitor necesita agentes y es para trafico TCP en EC2 y EKS. No ve el tramo de internet publico ni prueba caminos hibridos activamente. Si no puedes instalar agentes, no es tu opcion.
Network Synthetic Monitor prueba caminos hibridos con sondas hacia IPs de destino que tu defines. No es un monitor de internet general ni ve el trafico real de tu carga dentro de AWS; mide las rutas que le indicas.
Internet Monitor solo ve el segmento de internet. No ve dentro de tu VPC ni tu enlace hibrido. Te dice que un ISP en una ciudad esta degradado, no por que una conexion entre dos de tus instancias va lenta.
Costo: cada funcion tiene su propio modelo de precios. Habilitar los tres sin necesidad suma costo. Elige por la pregunta que tienes, no por completitud.
Conclusion
Los tres monitores de red de CloudWatch no miden lo mismo, aunque se llamen parecido. Network Flow Monitor mira dentro de AWS, Network Synthetic Monitor mira el enlace hibrido, e Internet Monitor mira el tramo de internet hasta el usuario. La decision no es cual es mejor, sino donde vive el trafico que te preocupa. Responde esa pregunta y el monitor correcto se elige solo.
Recursos
- Network Monitoring en Amazon CloudWatch - Las tres funciones de monitoreo de red descritas juntas
- What is Network Flow Monitor? - Monitoreo pasivo del trafico dentro de AWS con agentes
- Using Network Synthetic Monitor - Sondas activas para enlaces hibridos
- What is Internet Monitor? - Visibilidad del tramo de internet por ciudad-red
- CloudWatch anade monitoreo de rendimiento de red con flow monitors - El anuncio con la distincion pasivo/activo/internet
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article