cloud / sistemas
Eu queria entender melhor como meu site se comporta em navegadores reais. Os logs do servidor mostram requisições e ajudam a estimar visualizações de página provavelmente feitas por pessoas, mas não revelam tudo sobre a experiência no dispositivo de quem visita o site.
Por isso, preparei o Amazon CloudWatch Real User Monitoring (RUM). O nome parece mais conclusivo do que os dados permitem, então é importante explicar com clareza o que essa configuração pode e não pode mostrar.
Um sinal pequeno e opcional
A integração planejada no navegador é intencionalmente limitada. Primeiro, o site pergunta; o cliente da AWS só é carregado depois que a pessoa escolhe Permitir. Se ela recusar, nenhum dado de RUM é enviado. A escolha fica salva no navegador, e a pessoa pode retirar o consentimento depois.
Apenas uma amostra das sessões com consentimento é selecionada: cinco por cento. Esse é um parâmetro de amostragem, não uma promessa de que cinco por cento das pessoas serão contabilizadas. A amostragem é probabilística, e quem não consente não aparece nos dados de RUM.
A configuração se concentra em eventos de visualização de página e de sessão. A reprodução de sessões, os cookies de RUM, o X-Ray e os coletores de erros, HTTP e desempenho estão desativados. A AWS retém os eventos por 30 dias na região US East (N. Virginia). A requisição de rede necessariamente expõe um endereço IP; os dados dos eventos também podem incluir o caminho da página, o horário, detalhes técnicos do navegador e do dispositivo, além de identificadores pseudônimos de sessão ou do Cognito. O caminho da página não inclui parâmetros de consulta.
O sinal não é uma contagem de pessoas
A amostragem de cinco por cento, combinada com o consentimento opcional, gera um sinal esparso e seletivo. Ele não representa todas as visitas e não permite determinar quantas pessoas únicas usam o site. Sessões do navegador, visualizações de página registradas no servidor e requisições à CDN são medidas diferentes, cada uma com seus próprios pontos cegos.
Vou manter essas medidas separadas. O RUM pode ajudar a observar uma amostra da atividade nos navegadores. Os contadores existentes no servidor continuam sendo estimativas baseadas na filtragem de requisições, não identidades verificadas. Os totais de requisições à CDN incluem arquivos do site e tráfego automatizado. Juntar tudo em um único número de “visitantes” deixaria o resultado menos honesto, não mais útil.
As proteções de custo têm limites
Os eventos de RUM e os serviços da AWS que dão suporte a eles podem gerar custos. A amostragem de cinco por cento reduz o volume esperado, mas não é uma cota: um cliente autorizado pode ser chamado diretamente, e alguém mal-intencionado pode enviar eventos sem passar pela lógica de amostragem do navegador.
O projeto inclui um alarme que monitora picos de eventos ingeridos e uma função Lambda que adiciona uma negação explícita de IAM à função de convidado. Assim, posso interromper novas ingestões depois que o alarme e as mudanças de IAM entrarem em vigor. Isso não retira eventos já aceitos, e tanto o monitoramento quanto o bloqueio levam algum tempo para se propagar. É uma proteção, não um limite de gastos garantido.
Também mantenho o bloqueio mensal de mudanças já existente para toda a conta e exijo uma nova análise de custos antes de mudanças na AWS. Esses controles são úteis, mas nenhum deles garante uma fatura exata em tempo real. Um pico repentino pode gerar custos antes que o alarme responda. Esse risco residual faz parte da decisão; um painel tranquilizador não consegue eliminá-lo.
Ativado, com evidências ainda por reunir
O cliente de consentimento e o aviso de privacidade localizado já fazem parte do site. O cliente pergunta primeiro e só carrega o SDK da AWS depois que a pessoa escolhe Permitir. O runbook de ativação registra que a permissão específica para ingestão de RUM foi liberada em 11 de novembro de 2026. A amostragem de cinco por cento das sessões só se aplica depois do consentimento; ela não representa uma contagem de todos os visitantes.
Isso mostra que o caminho está aberto, mas não como é o sinal em produção. Ainda não confirmei eventos reais de navegadores nem verifiquei a fatura resultante. Também não fiz um teste real do limite do alarme. O mecanismo de alerta configurado monitora se pelo menos 20 eventos são ingeridos em 60 segundos e solicita que uma função Lambda adicione uma negação de IAM à função de convidado. Ele não remove eventos já aceitos, e o monitoramento, as notificações e as mudanças de IAM levam tempo para se propagar. Um pico repentino pode gerar mais custos antes que o bloqueio entre em vigor.
Esse mecanismo é uma resposta útil, não um limite rígido de gastos. O bloqueio de segurança mensal da conta impede novas mudanças feitas por agentes quando o limite é atingido; ele não garante uma fatura exata nem interrompe serviços existentes. Esses limites precisam acompanhar qualquer resultado de RUM, especialmente enquanto o volume real de eventos e os custos não forem verificados.
Quero manter a medição modesta e fácil de entender: perguntar antes, incluir na amostra apenas uma pequena parte das sessões com consentimento, manter separadas as medidas existentes do servidor e da CDN e explicar com clareza o que os dados e as proteções não conseguem garantir.