Deriving monitoring requirements

Lesson 1 of 4 in Monitoring and Alerting.

Nobody passes this domain by memorising which service emits which log. The exam asks you to look at a described workload and say what must be watched, how loudly, and who acts — and then to pick the cheapest architecture that delivers it. So start where the workload is, not where the service catalogue is.

Four questions, in order, produce a monitoring requirement:

1. What is worth attacking here? A payments API has cardholder data and an outbound path to the internet. A data-science account has credentials, large buckets and expensive compute. The assets decide the threats.
2. What would that attack look like in telemetry? Credential theft shows up as an instance role used from an unfamiliar network. Exfiltration shows up as unusual egress volume, or as long random DNS labels. Mining shows up as compute cost and outbound connections to pools. Each threat has a signal shape, and the shape decides the instrument.
3. How fast must someone know? This is the real severity question. “Root user signed in” needs a page in minutes. “An S3 bucket lacks a lifecycle policy” needs a ticket this sprint. Severity is a promise about response time, not a feeling about badness.
4. Who acts, and can a machine do it? If the answer is always the same three API calls, write the automation and let the human review the result. The exam’s strong preference — on every form — is central aggregation plus automated response over per-account dashboards and human triage.

Three of those four converge on one place. A GuardDuty finding, a Security Hub control failing, a Config rule going non-compliant, a CloudWatch alarm changing state, a Macie finding — all of them appear as EventBridge events. That is why EventBridge is the spine of every answer in this domain rather than one service among many: it is the only component that sees every signal type and can fan one signal out to several fates at once — notify a human, open a ticket, invoke a Lambda, start a Step Functions runbook, or forward the event to an event bus in the security account.

Two layers sit on top of it, and the exam distinguishes them. Amazon SNS is the fan-out primitive: one topic, many subscribers (email, HTTPS, SQS, Lambda), with the topic policy as the access control and server-side encryption available on the topic. AWS User Notifications is the human-facing console layer: notification configurations with email, chat and mobile-push delivery, plus one inbox that spans accounts and Regions. Route machine consumers through EventBridge and SNS; route people through User Notifications or a chat channel. A question that says “a central place for engineers to read notifications from many accounts” is pointing at User Notifications; one that says “trigger a remediation function” is pointing at EventBridge.

Three details about User Notifications are worth holding, because they are where the service surprises people. A notification configuration is a container of event rules, each naming a service, its event types and the Regions to watch, with an optional JSON event-pattern filter for anything finer (no wildcards). Aggregation is on by default — events combine into one notification over a 5-minute or 12-hour window, or you turn it off — which matters when an exam stem complains about either alert noise or a delay between an event and the email. And notification hubs are an account-level choice of up to three Regions where notification data is stored, processed and replicated; you must pick at least one before any configuration exists.

That last one carries a residency trap: whichever hubs you choose, the configuration's data is also stored in us-east-1, which is the default Region for the service, and replicated from there to the Regions you configured rules for. A requirement phrased as “notification metadata must remain inside the EU” is therefore not satisfiable by selecting an EU-only notification hub. Related: email delivery runs through Amazon SES API endpoints, which do not exist in every Region, so events originating in an unsupported Region have their email routed via us-east-1 — or you decline to configure email for those events at all.

Note the last edge on that diagram: the automation writes its result back. A remediation pipeline that fixes things silently is indistinguishable from one that is broken, so the loop closes — update the finding’s workflow status, annotate it, and alarm on remediations that failed. “Did the fix run?” is a monitoring requirement of its own.

Resource health checks are the part of this lesson people skip, and they carry more security weight than their name suggests. A Route 53 health check can watch an endpoint (HTTP, HTTPS or TCP, from many AWS locations), can be calculated from other health checks, or can simply track a CloudWatch alarm — which means any metric you can alarm on becomes a health signal that can drive DNS failover. Load balancer target health gives you the same visibility inside a VPC. The security reading: availability loss is often the first observable symptom of an attack — a resource exhaustion attempt, a deleted security group rule, a certificate that expired because nobody was alarming on it — and a health check that goes unmonitored turns an incident into an outage. Two practical cautions: a health-check endpoint is internet-reachable by design, so it must not leak version numbers or internal hostnames; and health checks test reachability, not correctness, so pair them with a metric or log signal that proves the thing is actually working.

Key terms: Metric filter, AWS User Notifications, Delegated administrator, AWS Security Hub (CSPM)

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.