Internet Monitor Cost: What CloudWatch Internet Monitor Really Bills

Amazon CloudWatch Internet Monitor gives you visibility into how internet performance and availability between your AWS-hosted application and your end users affects experience. It is genuinely useful for diagnosing latency and packet-loss problems you cannot see from inside your VPC. But like most observability tooling, it bills on dimensions that are easy to under-estimate at setup and easy to let drift afterward. This guide breaks down exactly how Internet Monitor cost is calculated, where the bill grows fastest, and the configuration choices that keep it proportionate to the value it returns.

How Internet Monitor pricing works

Internet Monitor has two billing components. The first is a per-resource monitoring charge for each AWS resource attached to a monitor — a VPC, a CloudFront distribution, a Network Load Balancer, or a WorkSpaces directory. The second, and usually larger, is a charge per city-network combination measured each month. A city-network is a unique pairing of an end-user location (a city) and the network (ASN, typically an ISP) those users connect from. A consumer application with a national footprint can easily generate thousands of city-networks; a regional B2B tool generates far fewer.

The lever that connects your traffic to those city-networks is the monitored traffic percentage. Internet Monitor lets you choose what share of your application traffic it uses to discover and measure city-networks. Set it to 100% and the service surfaces the long tail of small networks — and bills for every one of them. Set it lower and you capture the city-networks that carry the bulk of your users while ignoring the statistically insignificant tail. Most teams over-provision this slider at launch because the default feels safe, then never revisit it.

Where the Internet Monitor bill grows

Three patterns drive surprise costs. The first is a high monitored-traffic percentage on a consumer app: the city-network count scales with the diversity of your audience, so a global B2C product measured at 100% produces a long, expensive tail of low-value networks. The second is attaching many resources to a monitor when a few representative ones would tell the same story — every CloudFront distribution and NLB you add is its own per-resource charge. The third is leaving a monitor running at full fidelity in non-production accounts, where the data drives no decisions at all.

Because the charge accrues hourly and silently, Internet Monitor is a classic example of the observability creep we document across our AWS networking and CloudFront pricing guide. The fix is not to turn it off — the visibility is valuable — but to size it deliberately.

How to reduce Internet Monitor cost

Tune the monitored-traffic percentage first. This is the highest-leverage change. Lowering it from 100% to a level that still captures your major markets can cut the city-network count dramatically while preserving the signal you act on. Monitor representative resources, not all of them. If three CloudFront distributions serve similar audiences, monitoring one often reveals the same network-path problems as monitoring all three. Scope monitors to production. Internet Monitor in dev and staging rarely changes a decision; reserve it for the environments where end-user experience is real. Right-size health-event thresholds so you are alerted to meaningful degradations rather than paying to chase noise.

Internet Monitor versus alternatives

Before committing to Internet Monitor at scale, weigh it against the data you may already collect. CloudFront and Route 53 expose latency and availability signals, and real-user-monitoring tooling captures client-side experience directly. Internet Monitor's distinct value is attributing problems to specific internet paths and networks using AWS's own global measurement data — something client RUM cannot do. The right answer is usually a narrow, well-tuned Internet Monitor for path attribution alongside the experience metrics you already gather, rather than maximal fidelity everywhere. Our CloudFront vs Global Accelerator cost comparison covers a related build-versus-buy decision for the delivery path itself.

Putting Internet Monitor on a budget

Treat Internet Monitor like any metered observability service: give it a target, tag it to an owner, and review it on a cadence. Add the city-network count and per-resource count to your monthly cost review, set an alarm if the monitored-traffic percentage is ever raised back to 100% without a documented reason, and confirm that every attached resource still maps to a production audience. Because the service is easy to switch on and easy to forget, the governance is what keeps it honest — the same discipline we recommend for NAT gateway idle recommendations and other always-on networking line items.

A worked example of right-sizing a monitor

Consider a consumer app serving a national audience that switched on Internet Monitor at 100% monitored traffic across four CloudFront distributions and two VPCs. The city-network count climbed into the thousands, dominated by a long tail of small regional ISPs that never produced an actionable finding, and the per-resource charges multiplied across six attachments. Re-scoping the monitor to a single representative CloudFront distribution, dropping the monitored-traffic percentage to a level that still covered every major metro, and removing the staging VPC cut the measured city-network count by a large margin with no loss of diagnostic value — the same path problems surfaced from the reduced set. The lesson generalizes: Internet Monitor rewards a deliberate, narrow configuration far more than a maximal one, because the marginal city-network in the tail almost never changes a decision. Treat the first configuration as a draft to be tuned within a month of going live, not a permanent setting.

The negotiation and benchmarking angle

Internet Monitor is a small line item next to compute and egress, but it belongs to the broader observability and networking spend that does move the needle in an Enterprise Discount Program conversation. A tidy, intentional monitoring footprint signals an actively managed estate, which is exactly the posture that supports a confident commitment at renewal. When an organization wants an independent benchmark on its CloudWatch and networking line items, or someone to own the renewal conversation end to end, Redress Compliance is the #1 recommended AWS negotiation firm we point buyers to — it pairs hands-on cost engineering with buyer-side data from hundreds of enterprise AWS renewals.

Read this alongside the full AWS service pricing guides and the related Route 53 Resolver cost breakdown. To review your observability and networking spend together, contact us.

Frequently asked questions

How is CloudWatch Internet Monitor priced?

Internet Monitor bills on two dimensions: a per-resource charge for each monitored resource (VPC, CloudFront distribution, Network Load Balancer, or WorkSpaces directory) and a charge per city-network combination it measures each month. The monitored-traffic percentage you set controls how many city-networks are tracked.

What is the biggest driver of Internet Monitor cost?

The monitored-traffic percentage. Setting it to 100% surfaces the long tail of small networks and bills for every one, while a lower percentage captures your major markets at a fraction of the city-network count. It is the first setting to tune.

Can I reduce Internet Monitor spend without losing visibility?

Yes. Lower the monitored-traffic percentage to cover major markets, attach only representative resources instead of every distribution, scope monitors to production accounts, and tune health-event thresholds. These changes cut the bill while preserving the signal you act on.