cloud / systemen
Ik wilde beter begrijpen hoe mijn website zich gedraagt in echte browsers. Serverlogs laten verzoeken zien en helpen het aantal waarschijnlijke menselijke paginaweergaven te schatten, maar vertellen niet alles over de ervaring op het apparaat van een bezoeker.
Daarom heb ik Amazon CloudWatch Real User Monitoring (RUM) voorbereid. De naam klinkt stelliger dan de gegevens rechtvaardigen. Ik wil dus duidelijk maken wat deze inrichting wel en niet kan vertellen.
Een beperkt signaal na toestemming
De geplande browserintegratie is bewust beperkt. De website vraagt eerst toestemming; de AWS-client wordt pas daarna geladen. Wie weigert, verstuurt geen RUM-gegevens. De keuze wordt in de browser bewaard en kan later worden ingetrokken.
Er wordt slechts een steekproef genomen van sessies waarvoor toestemming is gegeven: vijf procent. Dat is een steekproefinstelling, geen belofte dat vijf procent van de mensen wordt geteld. De selectie is probabilistisch, en mensen die geen toestemming geven ontbreken volledig in de RUM-gegevens.
De configuratie richt zich op paginaweergaven en sessiegebeurtenissen. Sessieopnamen, RUM-cookies, X-Ray en verzamelaars voor fouten, HTTP en prestaties zijn uitgeschakeld. AWS bewaart gebeurtenissen 30 dagen in de regio US East (N. Virginia). Voor de netwerkverbinding is het IP-adres onvermijdelijk zichtbaar. Gebeurtenissen kunnen ook het paginapad, tijdstip, technische browser- en apparaatgegevens en pseudonieme sessie- of Cognito-identificaties bevatten. Het paginapad bevat geen queryparameters.
Dit signaal telt geen bezoekers
Vijf procent steekproeven in combinatie met toestemming levert een beperkt en selectief signaal op. Het vertegenwoordigt niet alle bezoekers en laat niet zien hoeveel unieke mensen de website gebruiken. Browsersessies, serverzijdige paginaweergaven en CDN-verzoeken zijn verschillende metingen, elk met eigen blinde vlekken.
Ik houd die metingen apart. RUM kan helpen om steekproefsgewijze browseractiviteit te zien. De bestaande serverzijdige tellers blijven schattingen op basis van gefilterde verzoeken; ze bevestigen geen identiteiten. CDN-verzoeken omvatten ook bestanden en geautomatiseerd verkeer. Alles samenvoegen tot één getal voor “bezoekers” zou het resultaat minder eerlijk maken, niet nuttiger.
Kostenbescherming heeft grenzen
RUM-gebeurtenissen en ondersteunende AWS-diensten kunnen geld kosten. Steekproeven van vijf procent van de sessies verlagen het verwachte volume, maar vormen geen quotum: een gemachtigde client kan rechtstreeks worden aangeroepen en een aanvaller kan gebeurtenissen versturen buiten de steekproeflogica van de browser om.
Het ontwerp bevat een alarm dat een plotselinge toename van opgenomen gebeurtenissen bewaakt en een Lambda-functie die de gastrol expliciet via IAM kan blokkeren. Daarmee kan ik verdere gegevensverwerking stoppen zodra het alarm en de IAM-wijzigingen actief zijn. Gebeurtenissen die al zijn geaccepteerd, kan ik niet terughalen. Ook hebben zowel de bewaking als de blokkade tijd nodig om door te werken. Dit is een beveiligingsmaatregel, geen gegarandeerd uitgavenplafond.
Ik handhaaf ook de bestaande maandelijkse blokkade op wijzigingen in het hele AWS-account en eis een nieuwe kostenbeoordeling vóór AWS-wijzigingen. Die controles zijn nuttig, maar geen ervan kan het exacte factuurbedrag in realtime garanderen. Een plotselinge piek kan kosten veroorzaken voordat het alarm reageert. Dat restrisico hoort bij de beslissing; een geruststellend dashboard neemt het niet weg.
Ingeschakeld, maar er is nog bewijs nodig
De toestemmingsclient en de privacyinformatie in de verschillende talen staan al op de website. De client vraagt eerst toestemming en laadt de AWS SDK pas nadat een bezoeker Allow kiest. Volgens het activeringsdraaiboek is de beperkte RUM-ingestietoestemming op 11 november 2026 vrijgegeven. De steekproef van vijf procent geldt alleen na toestemming; het is geen telling van alle bezoekers.
Dat vertelt me dat de route openstaat, maar nog niet hoe het live signaal eruitziet. Ik heb echte browsergebeurtenissen en de bijbehorende rekening nog niet bevestigd. Ook heb ik de alarmdrempel niet live getest. De ingestelde noodstop bewaakt minstens 20 opgenomen gebeurtenissen binnen 60 seconden en laat een Lambda-functie een IAM-blokkade op de gastrol zetten. Al geaccepteerde gebeurtenissen kunnen niet worden ingetrokken. Bewaking, melding en IAM-wijzigingen hebben tijd nodig om door te werken. Een plotselinge piek kan kosten veroorzaken voordat de blokkade actief is.
De noodstop is een bruikbaar middel om te reageren, geen harde kostenlimiet. De bestaande maandelijkse AWS-stop blokkeert verdere wijzigingen door agents zodra de drempel is bereikt; ze garandeert geen exact factuurbedrag en stopt bestaande diensten niet. Die beperkingen horen bij elk RUM-resultaat zolang het echte volume en de kosten niet zijn gecontroleerd.
Ik wil de meting bescheiden en begrijpelijk houden: eerst toestemming vragen, slechts een klein deel van de toestemmende sessies steekproefsgewijs meten, de bestaande server- en CDN-cijfers apart houden en duidelijk uitleggen wat de gegevens en beveiligingsmaatregelen niet garanderen.