Temporal Aggregation

Temporal aggregation groups observations by time and calculates a summary for each interval. For example, an application might record request latency for every request, then report the average, maximum, and request count for each minute. This differs from aggregating across resources: combining measurements across time is temporal aggregation, while combining measurements from multiple servers is aggregation across series. A monitoring query can perform both, but they answer different questions.

The aggregation window defines which observations belong together. Fixed, nonoverlapping windows, such as consecutive five-minute intervals, are useful for dashboards and reporting. Sliding windows summarize a moving interval and are useful for continuously updated operational indicators. Window boundaries, timestamp selection, and late-arriving observations affect the result. Distributed applications should use consistent timestamps and define whether processing follows event time or arrival time.

Choose the statistic according to the measurement's meaning. Sum is appropriate for counts of events occurring during an interval; Average is useful for sampled utilization; Maximum can expose brief saturation. For a metric whose values represent request counts per interval, dividing the interval's Sum by its duration in seconds produces requests per second. A cumulative counter requires calculating increases and handling resets instead of simply summing its readings. Missing observations should not automatically be interpreted as zero.

Aggregation must preserve enough information for later calculations. If one minute contains 100 requests averaging 20 milliseconds and another contains 10 requests averaging 200 milliseconds, averaging the two averages produces 110 milliseconds, which is incorrect for the combined workload. The correct request-weighted average is approximately 36.4 milliseconds. Retaining sums and sample counts allows accurate recomputation. Likewise, averaging per-minute percentiles does not produce a valid percentile for the combined period; retain observations or an appropriate mergeable distribution representation when that analysis is required.

In Amazon CloudWatch, a metric is identified by its namespace, metric name, and dimensions within an account and Region. Dimensions distinguish series, such as latency for one application instance versus another; they do not define time windows. Custom metrics with different dimension combinations are separate metrics, and CloudWatch does not automatically aggregate them across dimensions. Select or explicitly combine the intended series before interpreting a time-based summary.

CloudWatch distinguishes metric resolution from the retrieval or alarm period. Standard-resolution custom metrics have one-minute granularity, while high-resolution custom metrics support one-second granularity through StorageResolution set to 1. A query period determines the interval over which a statistic is calculated. Selecting a shorter period cannot reconstruct detail that was never published or has already been rolled up. High-resolution retrieval supports periods of 1, 5, 10, 20, or 30 seconds, as well as multiples of 60 seconds; available periods also depend on data age.

Retention makes this distinction operationally important. CloudWatch retains data with periods below 60 seconds for three hours, one-minute data for 15 days, five-minute data for 63 days, and one-hour data for 455 days. Older data becomes available at coarser resolution, so historical queries must use appropriate periods. A ten-second incident may be visible in recent high-resolution data but obscured in a long-term average.

Short windows improve visibility into transient failures but increase data volume, processing demands, and sensitivity to noise. Longer windows simplify trend analysis but can hide spikes and delay detection. Alarm evaluation also has its own configuration: an alarm period defines each evaluated interval, while evaluation periods and datapoints-to-alarm determine how multiple intervals trigger a state change. For a critical API, use short-window latency and error monitoring for incident detection, longer-window views for capacity trends, and retained request logs when detailed investigation must outlast metric granularity.