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 (covered in the next section), 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.

Match each risk to the service that already produces the signal before reaching for custom logic. Each source observes one kind of evidence and cannot stand in for another: GuardDuty reads network, DNS and API telemetry for malicious behavior, Config records and evaluates resource configuration, and health metrics describe availability. A requirement about hostile activity needs a threat detector, not a configuration rule or a health metric. 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.

A resource health check answers one question: can the thing still do its job, seen from where its users are? Pick the check by vantage point, because each one sees a different failure.

Two design rules follow. First, for outside-in monitoring of a public site, use a Route 53 endpoint health check on the URL and put a CloudWatch alarm on its HealthCheckStatus metric (Route 53 publishes it in us-east-1) with an SNS action. Instance and target checks can all be green while users cannot reach the site because of a DNS or certificate problem. Second, for private resources, such as internal load balancers behind failover records in a private hosted zone, the Route 53 checkers cannot reach the endpoint and you should not open the subnets to them. Instead, create a CloudWatch alarm on a health metric (for example the internal ALB's HealthyHostCount) and a Route 53 health check that monitors that alarm. DNS failover then works with no inbound internet path and no custom code. A calculated health check is a separate tool: it reports status from how many of its child Route 53 health checks are healthy, which summarizes several checks into one; its inputs are always other health checks.

AWS Security Hub CSPM is the aggregation layer for findings: the answer whenever a scenario asks for a single view of security findings across all accounts and Regions, managed from one account. (In 2025 AWS renamed the original service AWS Security Hub CSPM and launched a new AWS Security Hub (public preview June 2025, generally available December 2025), which works in the Open Cybersecurity Schema Framework (OCSF) and correlates signals from GuardDuty, Inspector, Macie and Security Hub CSPM into exposure findings. Delegated administration, central configuration, security standards and cross-Region aggregation as described here are Security Hub CSPM features, which keeps its own finding format, ASFF.)

Delegated administration. The Organizations management account designates a member account, by convention a dedicated security tooling account, as the Security Hub CSPM delegated administrator. That account sees and manages findings for every member. Keeping day-to-day security operations out of the management account is an exam-favored best practice.

Central versus local configuration. This choice decides how much per-account work remains.

Under central configuration, the management account designates the administrator but does not author policies; the delegated administrator does, from the home Region. A node with no direct association inherits the policy of its nearest parent, so one policy on the root and an override on a single OU covers the whole organization. A node can also be designated self-managed: its accounts choose their own standards and controls in each Region, and the administrator's policies do not override them. Designating an OU self-managed also makes its child OUs and accounts, including accounts added later, self-managed by inheritance, so you designate the OU rather than each account. Self-managed is set from the home Region like everything else in central configuration.

Cross-Region aggregation. You choose one aggregation (home) Region and link the others. What replicates into the home Region: findings, updates to findings (in both directions, so setting a finding to RESOLVED in the home Region also updates it in its linked Region), insight results, and control statuses, so security scores in the home Region count the linked Regions. What does not replicate: enablement, standards and control settings under local configuration, and visibility. A member account still sees only its own findings. The architectural consequence: finding events for every member account surface in the administrator account, and events for every linked Region surface in the home Region. Build your EventBridge rules, ticketing integrations and dashboards once, in the administrator account in the home Region.

Security Hub CSPM also has two roles worth keeping apart. As a standards engine it runs its own controls (AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark, PCI DSS, NIST) and produces control findings and security scores. As an aggregator it ingests findings from GuardDuty, Macie, Inspector, Config and partner tools.

Amazon GuardDuty is the managed threat detector: it continuously analyzes CloudTrail management events, VPC Flow Logs and DNS query logs for signs of compromise, such as credential exfiltration, cryptomining, command-and-control callbacks and anomalous API behavior. These foundational data sources are collected through an independent feed directly from AWS infrastructure. You do not need a trail, published flow logs or Resolver query logging for GuardDuty to work, and turning those logs off to save money does not blind it (for DNS, this holds while the VPC uses the Amazon-provided resolver).

Organization rollout is Regional. GuardDuty is a Regional service, and so is its organization setup. The management account designates the delegated administrator in each Region where you use GuardDuty (use the same account everywhere), and in each Region the administrator sets the auto-enable preference:

• ALL enables GuardDuty for every member account, existing and new. Use it to close gaps in accounts that were missed.
• NEW enables it only for accounts that join the organization from now on. Existing accounts that lack a detector stay uncovered.
• NONE leaves enablement to you.

A delegated administrator set up in one Region does nothing for the others. Uneven coverage therefore traces to one of two causes: a Region where no delegated administrator was designated, or an auto-enable preference that never applied to accounts already in the organization. Protection plans have their own auto-enable preferences, set the same way. Member findings are delivered to the administrator account in the same Region, and GuardDuty also sends them to Security Hub CSPM and EventBridge.

Protection plans add coverage beyond the foundational sources. Each one watches a specific kind of activity:

Two pairs are easy to confuse. EKS Protection sees the Kubernetes control plane (the audit log); Runtime Monitoring sees what runs inside nodes and containers. Most EKS designs need both. S3 Protection watches who accesses objects; Malware Protection for S3 checks what is inside new objects. Runtime Monitoring does not cover Lambda; Lambda Protection does.

Runtime Monitoring needs its agent. With automated agent configuration, GuardDuty installs and updates the agent for you: on EKS as a managed add-on, on Fargate as a sidecar, and on EC2 through Systems Manager. That means EC2 instances must be SSM managed instances for automated configuration to reach them. Set the plan's auto-enable to ALL so existing accounts are included.

Findings carry a severity (Low, Medium, High, Critical) and support suppression rules that auto-archive known-benign patterns, such as an authorized vulnerability scanner, so alert fatigue does not bury real signal.

Amazon Macie finds sensitive data (personal, financial and credential data, through managed and custom data identifiers) in S3, and it offers two ways to look. They trade coverage against cost.

In an organization, the Macie administrator account turns on automated discovery for members and sees the results.

Publishing to Security Hub CSPM. When Macie and Security Hub CSPM are both enabled, the integration is on automatically, but by default Macie publishes only policy findings (bucket-level issues, such as public access or disabled encryption). Sensitive data findings are not published until you change the publication settings. Who must change them matters: only the account that creates a discovery job can publish that job's findings, and only the Macie administrator can publish the findings that automated discovery produces for the organization. Publication therefore follows ownership of the analysis: organization-wide automated-discovery results are published from the Macie administrator account, and each job's results from the account that ran it. Policy findings follow bucket ownership in the same way: as administrator, Macie publishes policy findings only for buckets the administrator account owns, not for members' buckets.

Amazon Security Lake answers a different question than Security Hub CSPM: 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 CSPM 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. A data-access subscriber is notified of each new object, through an SQS queue or an HTTPS endpoint, and reads it from S3 into its own store. That is the path for a consumer that keeps its own copy and wants to be told as data arrives rather than scanning for it. A query-access subscriber queries the Lake Formation-managed tables in place, for example with Amazon Athena, and keeps no copy. 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. Collecting logs is not detecting anything in them: managed threat detection still needs a producer such as GuardDuty, whichever store or SIEM receives the data. It complements Security Hub CSPM rather than replacing it — Security Hub CSPM 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.

EventBridge rules turn findings into pages and tickets with no code: match on finding attributes and send to targets. Two rules on the severity label are the standard pattern, for example High and Critical to an SNS paging topic and Low and Medium to a ticketing queue. Each rule's event pattern does the filtering, so the routing itself needs no code. A Security Hub CSPM automation rule changes finding fields (such as severity or workflow status); it does not notify anyone.

Where you create the rules follows the aggregation design. Security Hub CSPM sends member findings to the administrator account and linked-Region findings to the home Region, so rules in the administrator account in the home Region see the whole organization.

Know which events Security Hub CSPM emits, because pattern bugs cause repeat pages:

• Security Hub Findings - Imported: sent for every new finding and every update to an existing finding, including an analyst changing the workflow status and a finding being archived.
• Security Hub Findings - Custom Action: sent only when an analyst chooses a custom action in the console.
• Security Hub Insight Results: sent for insight results chosen with a custom action.

Because updates re-emit Imported events, a rule that matches only on severity pages again each time someone triages the finding. To page only for untriaged, live findings, also match Workflow.Status = NEW and RecordState = ACTIVE. These fields belong to the AWS Security Finding Format (ASFF), the common schema Security Hub CSPM uses for findings from every producer, so one pattern works the same for GuardDuty, Macie, Inspector, control and partner findings.

Use CloudWatch metrics and alarms for signals that are rates rather than discrete findings. With CloudTrail delivering to a CloudWatch Logs log group, a metric filter turns a log pattern (console sign-in failures, AccessDenied errors, security group changes) into a metric, and an alarm with an SNS action notifies on it. No code runs. A subscription filter, by contrast, streams matching events to a destination such as a Lambda function; it is the tool for processing events, not for counting them.

Choose the alarm type by whether you can state the limit:

Anomaly detection flags deviation from baseline; it does not know intent, so treat it as an investigation trigger, not a verdict.

Per-principal baselines need dimensions. A metric filter can add up to three dimensions taken from fields in JSON log events. With a dimension on the calling role, each role gets its own metric, so you can put an anomaly detection alarm on each one and judge every role against its own normal level, rather than against one combined total dominated by the busiest roles. For roles, use the role ARN in userIdentity.sessionContext.sessionIssuer.arn; the session ARN in userIdentity.arn changes with every session. Keep dimension values low in cardinality, because each unique value creates a separate metric. CloudTrail Insights is a different tool: it detects unusual call volume or error rates per API across the account, not per principal.

Dashboards and cross-account visibility. CloudWatch dashboards give the SOC persistent views: findings by severity over time, alarm states, failed sign-ins and metric-filter hits. For many accounts, use CloudWatch cross-account observability: link the workload accounts as source accounts to a central monitoring account (you can link a whole organization or OU). The monitoring account can then read their metrics, logs and traces, and you build the dashboards and create the alarms there, on the shared metrics. Source-account alarms are not shared. This replaces the older cross-account console, which needed a sharing role in every account, and avoids building metric-stream pipelines just for visibility. Links are set up per Region.

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. 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. Choose the deployment method by scope:

The practical difference is scoping: when the target is defined by OU, the StackSet route follows OU membership automatically, whereas an organization pack can narrow its scope only through a list of excluded account IDs that someone has to maintain. Either way, the Config recorder must already be on in the target accounts.

Security Hub CSPM standards assess at the account-posture level. Enabling AWS Foundational Security Best Practices or the CIS AWS Foundations Benchmark runs the controls continuously and yields a security score per account and per standard. Name this mechanism when a scenario wants ongoing measurement against a named benchmark, with findings raised for failed controls. Most Security Hub CSPM controls are backed by service-linked 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. Target associations by tag or to all managed instances so instances launched later are included. Compliance status appears in Systems Manager Compliance. To bring it into the Config view the compliance team already uses, including a Config aggregator, add the Config managed rule ec2-managedinstance-association-compliance-status-check: it marks an instance noncompliant when its association last failed. This works because an association is stateful: Systems Manager records whether each association last succeeded on each instance, and that recorded status is what compliance reporting reads.

The selection heuristic: resource configuration ⇒ Config conformance packs; account posture against a benchmark ⇒ Security Hub CSPM standards; in-instance state ⇒ State Manager, reported through Config when you need it in an aggregator.

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 (in each of the three Regions), Security Hub CSPM, Macie and Config. Security operations never live in the management account.
2. Enable detection org-wide. In each Region, enable GuardDuty with auto-enable set to ALL, and choose protection plans per requirement, for example S3 Protection for regulated buckets and Runtime Monitoring with automated agent configuration for SSM-managed instances. Enable Macie automated sensitive data discovery, and set the Macie administrator's publication settings to publish sensitive data findings.
3. Aggregate. Turn on Security Hub CSPM cross-Region aggregation with one home Region linking the other two, then use central configuration: a policy on the root with the foundational standard, and a stricter policy on the production OUs. Every finding from every service, account and Region now lands in the administrator account in the home Region.
4. Alert. In that account and Region, create EventBridge rules on Security Hub Findings - Imported: High and Critical findings with workflow status NEW and record state ACTIVE to SNS for paging, and the rest to the ticketing integration.
5. Monitor health and rates. Add Route 53 health checks for public endpoints, alarm-based health checks for private ones, and metric filters with anomaly detection alarms on security metrics, viewed through cross-account observability in a monitoring account.
6. Assess continuously. Deploy an operational-best-practices conformance pack org-wide from the Config delegated administrator in each Region, and use State Manager associations to verify agents and hardening baselines on instances.
7. Retain and analyze. Enable Security Lake collecting CloudTrail, flow logs, Resolver logs and Security Hub CSPM findings, with the SIEM attached as a data-access subscriber.

When account 51 is vended, auto-enable and the root configuration policy cover it. Nobody configures anything.