Designing Security Monitoring and Alerting Across an AWS Organization

Monitoring requirements come from analyzing the workload, not from enabling every service AWS offers. For each workload, establish four facts: which services sit in the request and data path, which identities (human and machine) can touch it, what classification of data it processes, and which compliance regime applies. Each fact maps to a signal you must collect. Identities and control-plane changes demand API activity monitoring; network-exposed components demand traffic telemetry; regulated data demands data-access and sensitive-data monitoring; compliance regimes demand continuous configuration assessment.

The exam's example for workload monitoring strategy is resource health checks, and the security angle matters: availability is a security signal. A Route 53 health check that starts failing, an ELB target group draining to zero healthy targets, or a CloudWatch alarm on 5XX error rates can be the first visible symptom of a denial-of-service event, resource exhaustion by cryptomining, or an attacker breaking a component during lateral movement. Health checks also verify that your detective controls themselves are alive — an alarm on missing metric data catches an agent that silently stopped reporting.

Write the strategy down per signal: the source (service or agent), where it aggregates (account and Region), the alerting threshold and severity, and the owning team. A design that cannot answer “who gets paged and why” for each signal is incomplete, and exam scenarios frequently hinge on picking the design where alerts reach an owner rather than the one that merely collects more data.

AWS Security Hub is the aggregation layer: the answer whenever a scenario asks for a single view of security findings across all accounts and Regions. Two mechanisms deliver that view. First, delegated administration: the Organizations management account designates a member account — by convention a dedicated security tooling account — as the Security Hub delegated administrator. That account sees and manages findings for every member, and central configuration lets it enable Security Hub, choose standards, and set controls organization-wide by policy. Keeping day-to-day security operations out of the management account is itself an exam-favored best practice.

Second, cross-Region aggregation: you choose one aggregation (home) Region, and findings from linked Regions replicate into it continuously — including updates, so workflow status changes flow both ways. The architectural consequence is that your EventBridge rules, ticketing integrations, and dashboards only need to exist in the aggregation Region instead of being duplicated per Region.

Keep the two roles of Security Hub distinct, because questions test the difference. As a standards engine, it runs its own controls (AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark, PCI DSS, NIST) and generates control findings with a security score. As an aggregator, it ingests findings from GuardDuty, Macie, Inspector, Config, and partner tools. Every finding, whatever its producer, is normalized into the AWS Security Finding Format (ASFF) — one JSON schema with common fields for severity, resource, and workflow state — which is what lets one EventBridge rule or one automation handle findings from any source.

Amazon GuardDuty is the managed threat detector: it continuously analyzes CloudTrail management events, VPC Flow Logs, and DNS query logs for signs of compromise — credential exfiltration, cryptomining, command-and-control callbacks, anomalous API behavior. A point the exam probes: GuardDuty consumes these data sources directly from AWS infrastructure. You do not need a trail, flow logs, or Resolver query logging enabled for GuardDuty to work, and disabling those logs does not blind it.

At organization scale, the pattern mirrors Security Hub: the management account designates a delegated administrator, which enables GuardDuty for existing members and configures auto-enable so every new account joining the organization is protected from creation with no per-account action. This closes the classic gap where a newly vended account sits unmonitored.

Beyond the foundational data sources, protection plans extend coverage and are enabled individually: S3 Protection (analyzes S3 data events for suspicious object access), EKS Protection (analyzes Kubernetes audit logs), Runtime Monitoring (agent-based visibility into processes on EC2, ECS, and EKS workloads), Malware Protection (scans EBS volumes attached to suspicious instances), plus RDS and Lambda protection plans. Know them at the level of what each watches — the delegated administrator can auto-enable plans org-wide.

Findings carry a severity (Low, Medium, High, Critical), flow automatically to Security Hub and EventBridge, and support suppression rules to auto-archive known-benign patterns — such as expected scanning from an authorized vulnerability scanner — so alert fatigue does not bury real signal.

Amazon Security Lake answers a different question than Security Hub: not “what needs attention now” but “where is all my security data, in one queryable, normalized form, retained on my terms.” It is a purpose-built security data lake that collects logs and events across accounts and Regions into S3 buckets it manages in your account, and — its defining feature — normalizes everything into the Open Cybersecurity Schema Framework (OCSF), stored as Apache Parquet. When a scenario says “normalize security data into a standard open schema” or “feed AWS security data to a third-party SIEM without writing custom parsers,” Security Lake is the answer.

Native sources include CloudTrail management events, S3 and Lambda data events, VPC Flow Logs, Route 53 Resolver query logs, EKS audit logs, and Security Hub findings; custom sources let applications and third-party tools contribute, provided data lands in OCSF. Like the other detection services, it supports a delegated administrator and org-wide, multi-Region collection with configurable rollup Regions.

Consumption happens through subscribers: data-access subscribers are notified of new objects and read them (the SIEM integration path), while query-access subscribers query the Lake Formation-managed tables in place with Amazon Athena. Retention is yours to set through lifecycle configuration — which is why Security Lake also serves long-term compliance retention.

Position it correctly in a design: Security Lake stores and normalizes; it does not generate findings or alerts. It complements Security Hub rather than replacing it — Security Hub for triage and response, Security Lake for analytics, hunting, and retention.

Exam questions frequently reduce to matching a need to the one service built for it. The mapping to internalize:

Two distinctions carry most of the weight. GuardDuty finds threats (someone acting maliciously); Inspector finds vulnerabilities (weaknesses nobody has exploited yet). And Macie is the only one that reads your data itself — the answer to any “find PII in S3” requirement. Distractors typically offer a plausible-sounding service from the wrong row of this table.

Alerting turns aggregated findings into action, and CloudWatch and EventBridge split the work. Use EventBridge rules to route findings by attribute: because GuardDuty findings and Security Hub ASFF events carry structured severity fields, one rule can match High and Critical findings and target an SNS topic that pages on-call, while a second rule sends everything to a ticketing queue or archive. With Security Hub cross-Region aggregation, write these rules once in the aggregation Region — replicated findings raise events there.

Use CloudWatch metrics and alarms for signals that are rates rather than discrete findings. Metric filters on CloudWatch Logs remain the standard mechanism for turning log patterns — console sign-in failures, calls rejected for missing MFA, security group changes — into metrics you can alarm on. Static thresholds work when you can state a hard limit; CloudWatch anomaly detection fits when you cannot. It trains a model on a metric's history and draws an expected-value band, and the alarm fires when the metric leaves the band — catching a gradual rise in AccessDenied errors or an unusual surge in data-transfer volume that a fixed threshold would either miss or false-alarm on. Anomaly detection flags deviation from baseline; it does not know intent, so treat it as an investigation trigger, not a verdict.

Finally, CloudWatch dashboards give the SOC persistent visibility: findings by severity over time, alarm states, meter-style views of failed sign-ins and metric-filter hits. Cross-account observability lets a monitoring account render dashboards over source-account data, keeping SOC visibility consistent with the centralized model.

Continuous posture assessment means scheduled, automated evaluation — never a human periodically clicking through consoles. Three mechanisms cover the exam's scope, each assessing a different layer.

AWS Config conformance packs bundle Config rules and their remediation actions into a single deployable unit — a YAML template you can roll out organization-wide from a delegated administrator. AWS publishes sample packs for common frameworks, and because Config evaluates on configuration change as well as on schedule, a conformance pack is standing assessment of resource configuration: every noncompliant resource surfaces as an evaluation result you can alert on or auto-remediate.

Security Hub standards assess at the account-posture level. Enabling AWS Foundational Security Best Practices or the CIS Benchmark runs the controls continuously and yields a security score per account and per standard — the mechanism to name when a scenario wants ongoing measurement against a named benchmark with findings raised for failures. Many Security Hub controls are, under the hood, backed by Config rules, which is why Config recording must be on for them to evaluate.

Systems Manager State Manager assesses and enforces state inside instances, where Config rules cannot see. An association applies a document to targets on a schedule — verify the CloudWatch agent is running, ensure a hardening baseline holds, confirm agents report — and re-applies it on drift, with compliance status surfaced through Systems Manager Compliance.

The selection heuristic: resource configuration ⇒ Config conformance packs; account posture against a benchmark ⇒ Security Hub standards; in-instance state ⇒ State Manager.

A company runs 50 accounts under AWS Organizations across three Regions and wants every account monitored, findings in one place, on-call paged for critical threats, and posture measured continuously — with new accounts covered automatically. The design:

1. Delegate administration. From the management account, designate the security tooling account as delegated administrator for GuardDuty, Security Hub, Macie, Inspector, and Config. Security operations never live in the management account.
2. Enable detection org-wide. In the delegated administrator, enable GuardDuty with auto-enable for all members and new accounts, choosing protection plans (Runtime Monitoring, S3 Protection) per requirements. Enable Macie with automated sensitive data discovery for the accounts holding regulated S3 data.
3. Aggregate. Enable Security Hub via central configuration across all accounts, turn on AWS Foundational Security Best Practices, and configure cross-Region aggregation with one home Region linking the other two. Every finding from every service, account, and Region now lands in one place, in ASFF.
4. Alert. In the aggregation Region, create an EventBridge rule matching High and Critical findings targeting SNS for paging, and a second rule sending all findings to the ticketing integration.
5. Assess continuously. Deploy an operational-best-practices conformance pack org-wide from the Config delegated administrator; use State Manager associations to verify agents and hardening baselines on instances.
6. Retain and analyze. Enable Security Lake collecting CloudTrail, flow logs, Resolver logs, and Security Hub findings, with the SIEM attached as a data-access subscriber.

When account 51 is vended, auto-enable covers it — nobody configures anything.