cloud / systems
I wanted to understand more about how my website behaves in real browsers. Server logs can show requests and help estimate likely-human page views, but they cannot tell me everything about the experience on a visitor's device.
That led me to prepare Amazon CloudWatch Real User Monitoring (RUM). The name sounds more definitive than the data deserves, so it is worth being clear about what this setup can and cannot say.
A small, opt-in signal
The planned browser integration is deliberately limited. The site asks first; the AWS client loads only after a visitor chooses Allow. Declining sends no RUM data. The choice is stored in the browser, and a visitor can withdraw it later.
Only a sample of consenting sessions is selected: five percent. That is a sampling setting, not a promise that five percent of people will be counted. Sampling is probabilistic, and people who do not consent are absent from the RUM data altogether.
The configuration focuses on page-view and session events. Session replay, RUM cookies, X-Ray, and error, HTTP, and performance collectors are disabled. Events are retained by AWS for 30 days in the US East (N. Virginia) region. The network request necessarily exposes an IP address; event data can also include a page path, timestamp, technical browser and device details, and pseudonymous session or Cognito identifiers. The page path omits query parameters.
The signal is not a head count
Five-percent sampling plus opt-in consent produces a sparse and selective signal. It cannot represent every visitor, and it does not establish how many unique people use the site. Browser sessions, server-side page views, and CDN requests are different measurements with different blind spots.
I will keep those measures separate. RUM may help me see sampled browser activity. Existing server-side counters remain estimates based on request filtering, not verified identities. CDN request totals include assets and automated traffic. Combining them into one “visitor” number would make the result less honest, not more useful.
Cost safeguards have limits
RUM events and supporting AWS services can cost money. Five-percent session sampling reduces expected volume, but it is not a quota: an authorized client can be called directly, and an attacker could send events outside the browser's sampling logic.
The design includes an alarm that watches for a burst of ingested events and a Lambda function that adds an explicit IAM deny to the guest role. That gives me a way to stop further ingestion after the alarm and IAM changes take effect. It cannot retract events already accepted, and the monitoring and shutoff have propagation delays. It is a safeguard, not a guaranteed spending ceiling.
I also keep the site's existing account-wide monthly change stop and require a fresh cost review before AWS changes. Those controls are useful, but neither can guarantee an exact bill in real time. A sudden burst could cost more before the alarm responds. That residual risk is part of the decision, not something a reassuring dashboard can remove.
Enabled, with evidence still to gather
The consent client and localized privacy notice are already part of the site. The client asks first and loads the AWS SDK only after a visitor chooses Allow. The activation runbook records that the scoped RUM ingestion permission was unlocked on 11 November 2026. Five-percent session sampling applies only after consent; it is not a count of all visitors.
That tells me the path is open, not what the live signal looks like. I have not yet confirmed real browser events or verified the resulting bill. I also did not run a live test of the alarm threshold. The configured tripwire watches for at least 20 ingested events within 60 seconds and asks a Lambda function to add an IAM deny to the guest role. It cannot remove events already accepted, and monitoring, notification and IAM changes take time to propagate. A sudden burst could cost more before the stop takes effect.
The tripwire is a useful response mechanism, not a hard spending ceiling. The account's monthly safety stop blocks further agent changes when its threshold is reached; it does not guarantee an exact bill or stop existing services. These limits belong beside any RUM result, especially while real event volume and costs remain unverified.
I want the measurement to stay modest and understandable: ask first, sample only a small share of consenting sessions, keep the existing server and CDN measures separate, and say plainly what the data and safeguards cannot guarantee.