CloudWatch Contributor Insights lets you define a rule over log groups instead of running an ad-hoc Logs Insights query. What does such a rule actually produce, and when would you build one rather than just querying?

## The shape of a rule A CloudWatch Contributor Insights rule for log groups is a JSON document. The essential parts are the log groups it watches, the log format, and a `Contribution` block naming the key: ```json { "Schema": { "Name": "CloudWatchLogRule", "Version": 1 }, "LogGroupNames": ["/aws/lambda/api"], "LogFormat": "JSON", "AggregateOn": "Count", "Contribution": { "Keys": ["$.tenantId"], "Filters": [ { "Match": "$.status", "GreaterThan": 399 } ] } } ``` - **`Keys`** define the contributor — the thing being ranked. A small number of keys may be combined, producing a composite contributor such as tenant plus endpoint. - **`Filters`** decide which events participate at all, so a rule can count only errors, only one route, only requests over a latency threshold. - **`AggregateOn`** chooses between counting matching events and summing a numeric field named by `ValueOf` — the difference between "who made the most calls" and "who consumed the most capacity units". - **`LogFormat`** is JSON or Common Log Format; JSON keys are addressed with JSON-path style selectors. AWS also publishes built-in rules for some services, so common cases (for example, top contributors in VPC flow logs) do not have to be authored by hand. ## What it produces Unlike a query, which reads stored history once and returns a table, a rule is **continuous**. CloudWatch evaluates it against log events as they are ingested and maintains a time series of the top contributors, which the console renders as the familiar stacked "top N" graph. Alongside the ranking it exposes aggregate measures — how many unique contributors there were in a period, and the value attributed to the leading one — and those are ordinary CloudWatch measures, so they can be graphed on a dashboard and alarmed on. That is the real payoff: "alert me when one tenant exceeds a third of all requests" is expressible with a rule and is not expressible with an ad-hoc query. ## The decision: rule or query Prefer a **rule** when all of these hold: the question recurs; it is shaped as a ranking over a high-cardinality key; and you want an answer available immediately rather than after a scan. Canonical cases are the hot partition key in a DynamoDB workload, the client IP or API key behind a throttling spike, the noisiest source of 5xx responses, and the tenant driving a cost anomaly. High cardinality is precisely where a rule beats the alternatives: you cannot put a tenant id in a metric dimension without a cardinality explosion, but a rule ranks tenants happily because it keeps only the top contributors rather than a series per tenant. Prefer a **query** when the question is exploratory or one-off, when you need the raw log lines rather than a ranking, or when the window of interest is in the past. This is the limitation that decides most arguments: a rule only sees events ingested after it exists. It cannot answer "who caused last Tuesday's spike" — for that, Logs Insights scanning history is the only option. The mature pattern is therefore sequential: use Logs Insights to work out during the first incident which key mattered, then create a rule so the second incident answers itself. ## Costs and limits worth knowing Rules are priced per rule and by the volume of matching log events, so a rule with no filters over a firehose of debug logs is a standing charge you did not intend. Filter narrowly and point rules at specific log groups. Rules can also be disabled rather than deleted, which is the right move for something you only want during a campaign. There is a per-account limit on how many rules may exist, which is a mild forcing function towards keeping the ones that earn their place. ## The trap The misconception to avoid in an interview is treating Contributor Insights as "a saved Logs Insights query". It is not: a saved query is text you re-run, still scanning history and still billed per scan; a rule is a stream processor over ingestion that produces measures. They answer different questions, and the honest answer to "which should we use" is usually "the query first, the rule once we know what to watch".