cloud / sistemas
Quería entender mejor cómo se comporta mi sitio web en navegadores reales. Los registros del servidor muestran solicitudes y ayudan a estimar las visitas a páginas probablemente humanas, pero no pueden contarme todo sobre la experiencia en el dispositivo de quien visita el sitio.
Por eso preparé Amazon CloudWatch Real User Monitoring (RUM). El nombre suena más concluyente de lo que permiten los datos, así que conviene explicar con claridad qué puede decir esta configuración y qué no.
Una señal limitada y con consentimiento
La integración prevista en el navegador tiene límites deliberados. El sitio pregunta primero; el cliente de AWS solo se carga después de que la persona visitante acepta. Si rechaza, no se envían datos de RUM. La elección se guarda en el navegador y puede retirarse más adelante.
Solo se selecciona una muestra de las sesiones con consentimiento: el cinco por ciento. Es un ajuste de muestreo, no una promesa de que se contabilizará al cinco por ciento de las personas. El muestreo es probabilístico, y quienes no dan su consentimiento quedan completamente fuera de los datos de RUM.
La configuración se centra en eventos de visitas a páginas y sesiones. La reproducción de sesiones, las cookies de RUM, X-Ray y los recopiladores de errores, HTTP y rendimiento están desactivados. AWS conserva los eventos durante 30 días en la región US East (N. Virginia). La solicitud de red expone necesariamente una dirección IP; los datos del evento también pueden incluir la ruta de una página, una marca de tiempo, detalles técnicos del navegador y del dispositivo e identificadores seudónimos de sesión o de Cognito. La ruta de la página no incluye parámetros de consulta.
La señal no es un recuento de personas
El muestreo del cinco por ciento, junto con el consentimiento opcional, produce una señal escasa y selectiva. No puede representar a todas las personas visitantes ni determinar cuántas personas únicas usan el sitio. Las sesiones del navegador, las visitas a páginas registradas en el servidor y las solicitudes al CDN son mediciones distintas, cada una con sus propios puntos ciegos.
Mantendré esas mediciones separadas. RUM puede ayudarme a observar actividad del navegador capturada mediante muestreo. Los contadores existentes del servidor seguirán siendo estimaciones basadas en el filtrado de solicitudes, no identidades verificadas. Los totales de solicitudes al CDN incluyen recursos y tráfico automatizado. Combinarlos en una sola cifra de «visitantes» sería menos honesto y no aportaría más utilidad.
Las salvaguardas de costes tienen límites
Los eventos de RUM y los servicios de AWS que los respaldan pueden generar costes. El muestreo del cinco por ciento de las sesiones reduce el volumen previsto, pero no es una cuota: se puede invocar directamente a un cliente autorizado, y un atacante podría enviar eventos sin pasar por la lógica de muestreo del navegador.
El diseño incluye una alarma que vigila los aumentos bruscos de eventos ingeridos y una función Lambda que añade una denegación explícita de IAM al rol de invitado. Esto me permite detener la ingesta posterior una vez que la alarma y los cambios de IAM surtan efecto. No puede retirar los eventos que ya se hayan aceptado, y tanto la supervisión como el bloqueo tienen retrasos de propagación. Es una salvaguarda, no un límite de gasto garantizado.
También mantengo el bloqueo mensual de cambios que ya existe para toda la cuenta y exijo una nueva revisión de costes antes de hacer cambios en AWS. Esos controles son útiles, pero ninguno puede garantizar el importe exacto de la factura en tiempo real. Un aumento repentino podría generar costes antes de que responda la alarma. Ese riesgo residual forma parte de la decisión; un panel tranquilizador no puede eliminarlo.
Activado, aún quedan evidencias por reunir
El cliente de consentimiento y el aviso de privacidad localizado ya forman parte del sitio. El cliente pregunta primero y solo carga el SDK de AWS después de que la persona visitante acepta. El runbook de activación deja constancia de que el permiso acotado para ingerir datos de RUM se desbloqueó el 11 de noviembre de 2026. El muestreo del cinco por ciento de las sesiones se aplica únicamente después del consentimiento; no representa un recuento de todas las visitas.
Esto me indica que el acceso está abierto, pero no cómo es la señal en producción. Todavía no he confirmado eventos de navegadores reales ni verificado la factura resultante. Tampoco he probado en vivo el umbral de la alarma. El umbral configurado vigila si se ingieren al menos 20 eventos en 60 segundos y solicita a una función Lambda que añada una denegación de IAM al rol de invitado. No puede eliminar los eventos ya aceptados, y la supervisión, las notificaciones y los cambios de IAM tardan en propagarse. Un aumento repentino podría generar costes antes de que se aplique el bloqueo.
El umbral es un mecanismo de respuesta útil, no un límite estricto de gasto. El mecanismo mensual de seguridad de la cuenta bloquea nuevos cambios de los agentes cuando se alcanza su umbral; no garantiza una factura exacta ni detiene los servicios existentes. Estos límites deben acompañar a cualquier resultado de RUM, sobre todo mientras el volumen real de eventos y sus costes sigan sin verificarse.
Quiero que la medición siga siendo moderada y fácil de entender: preguntar primero, muestrear solo una pequeña parte de las sesiones con consentimiento, mantener separadas las mediciones existentes del servidor y del CDN, y explicar con claridad qué no pueden garantizar los datos ni las salvaguardas.