CloudWatch pricing in Tokyo: what drives the bill

When a CloudWatch bill rises, find the growing line item before changing platforms. Shorter retention reduces storage; it does little for an ingestion-heavy bill. Removing dashboards will barely help when custom metrics account for most of the spending.

In Tokyo, Standard log ingestion costs US$0.76/GB, storage US$0.033/GB-month, and the Logs Insights meter used here US$0.0076 per GB scanned. Each pays for different work. If AWS-native monitoring already meets the team's needs, I would first adjust what is collected, retained and queried. A platform migration should solve a problem that remains after that work.

Guance Editorial Team. AWS public rates checked on 27 October 2026. The examples use USD list rates and assumed quantities; they are not customer invoices or performance measurements.

Tokyo rates and the allowances that apply

The region is ap-northeast-1. The AWS Price List published on 7 October 2026 provides the regional rates below. Additional CloudWatch features add their own charges.

Free allowances have specific boundaries. The monthly million-request general API allowance excludes GetMetricData, GetInsightRuleReport and GetMetricWidgetImage. The ten free alarm metrics apply to standard-resolution alarms that specify metrics directly, not Metrics Insights query alarms, high-resolution alarms or composite alarms. Free Tier conditions

Three Basic custom dashboards are free when each references at most 50 metrics. Extended dashboards with more metrics also cost US$3.00/month but do not qualify for that allowance; automatic dashboards are free. Paid dashboard SKUs use location=Any and appear in the complete price list, rather than being Tokyo-specific.

Standard log ingestion, storage and Logs Insights have separate Global 0–5 GB free SKUs. Live Tail includes 1,800 minutes a month. The calculations below use quantities after AWS has allocated the applicable free usage. Credits, taxes and contract adjustments are separate.

A short list of metric names can produce many series

CloudWatch identifies a metric by its name, namespace and dimensions. Different service, endpoint and status values can produce separate series even when every record is called request_count. Metrics and dimensions

For an illustrative workload, 20 services each emitting all combinations of 10 endpoints and five statuses produce 1,000 series from one metric name. Fewer emitted combinations produce fewer series. A request ID introduces a much less bounded dimension, so decide whether that level of aggregation is useful before publishing it.

The rate tiers apply incrementally. At 12,000 billable metric-months, the first 10,000 cost US$0.30 each and the remaining 2,000 cost US$0.10, giving US$3,200 for metrics.

M = billable custom metric-months

metric_cost(M)
= min(M, 10,000) * 0.30
+ min(max(M - 10,000, 0), 240,000) * 0.10
+ min(max(M - 250,000, 0), 750,000) * 0.05
+ max(M - 1,000,000, 0) * 0.02

estimated_subtotal
= metric_cost(M)
+ billable_general_api_requests * 0.00001
+ get_metric_data_metrics_requested * 0.00001
+ metric_stream_updates * 0.000003
+ standard_alarm_metric_months * 0.10
+ high_resolution_alarm_metric_months * 0.30
+ composite_alarm_months * 0.50
+ billable_basic_custom_dashboard_months * 3.00
+ standard_log_ingestion_gb * 0.76
+ log_storage_gb_month * 0.033
+ logs_insights_scanned_gb * 0.0076
+ paid_live_tail_minutes * 0.01

M is billable custom metric-months. Use time-adjusted quantities for metrics, alarms and dashboards, retaining precision through the calculation and rounding only the displayed dollar amount.

What a US$3,281.71 example tells us to fix first

These assumed quantities are already net of the applicable free allowances. Other CloudWatch features, associated AWS services, credits and taxes are outside the calculation.

Metrics contribute US$3,200; everything else adds up to US$81.71. Here, unused dimensions, extra series created by overlapping collection, and metrics nobody consumes deserve attention before log retention. The latter cannot materially change the dominant charge.

Changing only metric-months makes the relationship clear:

Removing unused series is different from losing the resolution needed to diagnose a failure. The monitoring should still do its job after the bill falls.

Ingestion, storage and queries need different changes

An ingestion increase points toward source log levels and duplicate forwarding. A storage increase points toward log-group retention. An increase in Logs Insights suggests reviewing time windows, selected log groups and repeated execution.

For example, once 1,000 billable GB has been ingested, its US$760 ingestion charge has occurred. Shortening retention changes subsequent storage. A query scanning 1,000 GB costs US$7.60 at the listed rate. Retaining less history and scanning narrower windows act on different parts of the bill.

These are Standard-log rates and the specific Logs Insights meter in the table. Infrequent Access, Vended Logs, S3/Firehose delivery and data protection have separate pricing conditions. Set the retention needed for investigations and audit before trimming the excess.

Follow UsageType back to the workload

Filter Cost Explorer to CloudWatch, compare equal-length periods, then examine Usage Type and switch the grouping to API Operation and Region as needed. Tokyo-specific entries often start with APN1-; dashboards and free allowances can be region-neutral. CloudWatch billing investigation

Price List operation and CUR line_item_operation are different fields. A blank value in the former does not prevent the latter from identifying the writer. For logs, continue to the log group and emitting service. The workload producing data usually explains more than the number of people opening the console. With resource-level data enabled, Cost Explorer's resource view covers the previous 14 days; CUR supports longer resource-level investigations.

This Athena example shows the aggregation. Substitute the table and UTC interval for your own CUR schema.

SELECT
  line_item_usage_type,
  line_item_operation,
  SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS unblended_cost
FROM <cur_table>
WHERE line_item_product_code = 'AmazonCloudWatch'
  AND line_item_usage_start_date >= TIMESTAMP '<start_utc>'
  AND line_item_usage_start_date <  TIMESTAMP '<end_utc>'
  AND line_item_line_item_type NOT IN
      ('Tax', 'Credit', 'Refund', 'EdpDiscount', 'Fee', 'RIFee')
GROUP BY 1, 2
ORDER BY 3 DESC;

Keep CloudWatch where the work stays inside AWS

CloudWatch remains a sensible choice when the job is monitoring EC2, RDS and Lambda and handling alerts within AWS. Reusing basic metrics and established integrations, then tracing the increased charge to its source, is often a smaller change than replacing the platform.

The calculation changes when engineers need to explain AWS costs alongside applications and services in other environments. Guance's AWS Billing integration brings billing data into the platform for analysis. That can put daily cost review and operational monitoring in one place. Billing data follows the source API and collection schedule, so it should be read on its own update cadence rather than as a real-time request signal.

Keeping CloudWatch queries or log delivery also keeps their AWS charges. Separate work CloudWatch already handles from investigations that need a broader view; that makes the purpose of an additional platform easier to judge. The Japan AWS monitoring guide develops that deployment choice.

For a yen-denominated budget, use the actual invoice currency, conversion rules and taxes. This subtotal excludes additional Application Signals, X-Ray, RUM, Synthetics, Insights products and data transfer. Add the features in use for the same billing period before treating it as an account estimate.