Preventive controls guarantee a correct starting state. They say nothing about tomorrow. This module is about the other half of governance — recording what your resources actually look like, evaluating that against the rules you care about, and closing the gap automatically when something drifts.
Two modules of this course have been about getting resources into existence correctly. A landing zone gives you the account structure. Service Catalog gives builders a way to provision inside guardrails. Between them, a new resource starts life the way your platform team intended. That is genuinely valuable — and it is also the easy half.
A preventive control is evaluated at the moment of the API call. Once the call succeeds, the control has done its job and stopped caring. Everything that happens next is outside its field of view.
Consider a bucket that AnyCompany's platform team provisions through an approved catalogue product, with versioning enabled and public access blocked. Three months later an engineer debugging a lifecycle problem turns versioning off “temporarily” and never turns it back on. Nothing was violated at launch. Nothing was blocked. The resource is now non-compliant and no preventive mechanism anywhere in your account will tell you.
That drift has three common causes, and none of them are malicious: a console change made under time pressure, a template edited outside the catalogue, or a service default that shifted underneath you. Detective controls exist because the state of a cloud environment is continuously rewritten by ordinary work.
The course frames the operational half of governance as four activities that build on each other. Each one answers a different question, and each one has a different service behind it.
Visibility into how workloads behave and perform. This is the metrics and dashboards layer, and it is where CloudWatch lives. Without it the rest of the chain has nothing to reason about.
The record of settings and of activity. What does this resource look like right now, what did it look like last Tuesday, which principal changed it, and which policies were in force at the time.
Operational action against groups rather than individuals, without hand-logging into servers. Grouping, automation documents, and repeatable runbooks. This is the Systems Manager half of the module.
The long game. Analysing what the first three stages produced, reducing waste, tightening security posture, and feeding the findings back into the rules you define. This is where a governance programme either compounds or stalls.
AWS groups its management and governance portfolio into four bands. The point of the grouping is not taxonomy for its own sake — it is that these services are designed to hand data to each other, so a detection in one becomes an action in another.
| Band | Services | What it contributes to the loop |
|---|---|---|
| Enterprise governance and control | Control Tower Organizations | The boundary and the inheritance model. Also the source of organisation-level events worth alerting on, such as an account being created or a member account attempting to leave. |
| Provisioning and orchestration | CloudFormation Service Catalog | Turns approved designs into deployed resources. This is the preventive half, covered in M02 and M03. |
| Monitoring and observability | CloudWatch | Metrics, dashboards, and the event bus. The nervous system that carries a detection from the service that noticed it to the thing that fixes it. |
| Centralised operations management | CloudTrail Config Systems Manager Security Hub GuardDuty | The subject of this module. Activity history, configuration state and rule evaluation, grouped action, aggregated findings, and threat detection. |
Strip the tooling away and operational governance rests on exactly two capabilities. One tells you what you have and how it got that way. The other tells you whether what you have is acceptable. Build the first without the second and you have a very detailed inventory of unknown risk. Build the second without the first and your compliance report has nothing underneath it.
The clearest way to understand this pillar is by the questions it lets you answer. Each question maps to a concrete Config capability, and each one is a question you will be asked at some point by an auditor, an incident responder, or a finance team.
The second pillar takes the inventory as input and applies judgement to it. It is the difference between a database and a control.
Decisions made against accurate configuration data instead of assumptions, and a measurable reduction in the class of incidents caused by something being set up wrong and nobody noticing.
Inventory without compliance means you can describe your estate in detail and still cannot say whether it is safe. Compliance without inventory means your rules only cover the resources somebody remembered to register.
Config is two things wearing one name, and separating them makes the service far easier to reason about. The recorder discovers resources and captures their state over time. The rule engine takes that state and asks whether it matches what you declared. You can run the recorder without a single rule and still get value; you cannot run rules without the recorder.
Config finds supported resources in the account on its own. For the recording and rule-evaluation story there is nothing to install, no sensor fleet, and no per-instance onboarding step.
Every change produces a new configuration item, and the series is retained — seven years by default. That retention window is why Config doubles as forensic evidence rather than just a dashboard.
A large library of predefined managed rules covers the common cases. When your requirement is specific to your organisation, write a custom rule and back it with a Lambda function or a Guard policy.
Evaluation results publish to SNS and onto the event bus, so a rule going from compliant to non-compliant becomes an event other systems can subscribe to within moments of the change.
Single-account Config is a useful audit tool. Organisation-wide Config is a governance capability. The difference is the aggregator, and it is the feature that makes this module part of a governance at scale course rather than a service tour.
Config tells you something is wrong. Systems Manager is how you do something about it without opening a terminal. The organising idea behind the whole service is that at scale the unit of operation is a group of resources, defined by a shared property, not a hostname you remember.
Ask what “patch the fleet” means in practice. In an environment of thirty instances it means a script and a maintenance window. In an environment of three thousand instances spread across a dozen accounts, addressing hosts individually is not slow — it is impossible to do correctly, because the list is out of date before you finish it.
Systems Manager inverts that. You describe the set by its properties — every instance tagged env=prod and tier=web, or every resource belonging to a named application — and the service resolves the membership at execution time. New instances that match the description are covered automatically. Decommissioned ones drop out. You maintain the definition, not the roster.
A group is also not limited to compute. Instances, buckets and databases can all belong to the same application group, which is what lets one dashboard reflect an application rather than a resource type.
Build logical groups across services using tags and other properties. Search and act by group rather than by identifier.
One interface aggregating operational data from many services, scoped to the group you are looking at.
Run automation documents against the whole group. No SSH session, no bastion, no per-host login.
Systems Manager is a large service with many features. These are the ones that carry weight in a governance conversation.
Treating automation documents as scripts to run by hand. If a human has to click it, it is not a control — it is a runbook with better formatting. The value appears when the document is invoked by an event, not by a person.
Requirements that are boring, high-volume and mechanical: patch levels, agent versions, tag hygiene, log-shipping configuration. These are exactly the things that erode slowly and are never anyone's priority until an audit.
Every service in this module is one leg of a single loop. Draw the loop once and the service list stops being four things to memorise and becomes one mechanism with four moving parts. Step through it below with a concrete case: an engineer at AnyCompany creates an S3 bucket and leaves versioning switched off.
| Stage | Owning service | What it produces | What breaks without it |
|---|---|---|---|
| Define | AWS Config Security Hub | A machine-readable statement of desired state, scoped to the resources it applies to. | Nothing to measure against. “Secure” stays an opinion. |
| Detect | AWS Config GuardDuty | An evaluation result or a finding, tied to a specific resource at a specific time. | You have rules nobody checks. This is the most common failure mode in real environments. |
| Alert | EventBridge SNS Security Hub | An event other systems can subscribe to, and a human-visible notification. | The detection sits in a console nobody has open. Detection latency becomes discovery latency. |
| Remediate | Systems Manager Lambda | A changed resource, and a record of what was changed and why. | A very well-documented backlog of known problems. Detection without remediation is just a tidier inbox. |
C. Define the rules and requirements, monitor the estate against them, detect violations, raise the alert in real time, then take action.
The two wrong answers worth thinking about are A and B. A drops detection entirely, which leaves you remediating something you never established was broken. B has all four steps but swaps the last two — and that ordering is exactly the accountability problem described in the callout above. D introduces a step that is not part of the framework at all.
Config asks a settings question: does this resource match the shape I declared? GuardDuty asks a behaviour question: does this activity look like an attack? Security Hub asks neither — it collects the answers everything else produced and tells you which one to deal with first. Three different jobs, and confusing them is the fastest way to build a monitoring estate with gaps in it.
GuardDuty reads logs you already generate, plus one you cannot normally read at all, and applies threat intelligence, anomaly detection and machine learning to spot activity that looks wrong. You enable it from the console; there are no sensors, appliances or agents to deploy.
Instances doing sustained work nobody asked for, talking to mining pools. Usually the first visible symptom of a compromised workload.
Instance credentials appearing from outside AWS, or a principal suddenly behaving unlike its own history — new Regions, new services, new API patterns.
Object-level activity that does not fit the established pattern for a bucket, including access from anonymised networks or unfamiliar geographies.
Communication with hosts on curated threat-intelligence lists, including feeds contributed by commercial security vendors and maintained for you.
API activity originating from addresses already associated with malicious behaviour, which is often how a credential leak is discovered.
Enable through Organizations across existing and new accounts, and aggregate findings into a single administrator account so the security team reads one queue.
D. GuardDuty is the one processing log streams through anomaly detection, behavioural models and threat-intelligence feeds to rank what is worth your attention.
The distractors are each doing a real job, just not this one. Config describes configuration and its history. Systems Manager is the operations hub that acts on resources. Security Hub gathers findings from many sources — including GuardDuty — and measures your environment against standards. Only GuardDuty is generating the threat detections in the first place.
Security Hub exists because mature environments have a finding-volume problem, not a finding-shortage problem. It normalises findings from AWS security services and partner products into one place, runs its own standards checks, and correlates the result so the highest-priority items surface.
Continuous account-level and resource-level checks against published benchmarks — PCI DSS and the CIS AWS Foundations Benchmark among them. When something deviates, Security Hub flags it and suggests the remediation, so the framework stops being a spreadsheet you reconcile once a year.
Findings from every connected account and product land in one console in a common format, correlated so trends and the highest-severity items rise to the top. The time you were spending assembling the picture goes back into acting on it.
Select findings in the console and fire a defined action — open a ticket, post to a channel, email an owner, or invoke an automated fix through the event bus and Lambda. This is the manual escape hatch that keeps the automated path honest.
Connect member accounts and consolidate findings centrally. Combined with a set of Config rules and partner integrations, one team can hold a defensible view of an entire organisation's posture.
This is the comparison worth carrying out of the module. Every one of these services touches remediation, but they arrive at it from different directions.
| Role in the loop | AWS Config | Systems Manager | Amazon GuardDuty | AWS Security Hub |
|---|---|---|---|---|
| Defines the policy | Yes — declares and evaluates configuration policy. | Indirectly — patch baselines and configuration policies. | No — detection logic is managed for you. | Yes — through the standards you enable. |
| Detects the problem | Configuration drift against the rule. | Non-compliance against patch and configuration scans. | Malicious or anomalous behaviour in logs. | Nothing directly — ingests findings from the others. |
| Alerts | Non-compliance notifications via SNS and the event bus. | Compliance reporting on managed resources. | Prioritised findings with attacker and resource detail. | Validated, searchable, correlated findings in one console. |
| Remediates | Initiates auto-remediation actions. | Performs the remediation — the muscle for all four. | Initiates remediation through events. | Initiates remediation through custom actions. |
If you keep six things from this module, keep these.
D. Config is the service that maintains a resource inventory, keeps a configuration history, emits change notifications, and evaluates recorded state against rules. Both halves of the question — recording and evaluating — point at it.
Control Tower is tempting because it enables detective controls, but it does so largely by turning on Config rules underneath; it is the orchestration layer, not the recorder. CloudWatch carries metrics and events rather than configuration state. CodeBuild belongs to the build toolchain and has no governance role here.
This module has two labs, and they split neatly along the two halves of the loop. Take them in order — the second one makes more sense once you have run an automation by hand.
Group resources by a shared requirement instead of naming them one at a time, read the aggregated operational data for that group, then run an automated action across the whole group in one pass.
Apply managed rules to selected resources, use the Config dashboard to see what fails, then attach automatic remediation so the fix runs without a human in the path. The moment the remediation action attaches is the moment the rule becomes a control.
Implement, provision, operate — then back to implement. Follows one requirement all the way round the loop and shows which service owns each leg, where the handoffs are, and where most organisations break the cycle.
Service Catalog, launch constraints and budget enforcement live in Module 03. Read it alongside this one — the two modules are a single argument split across a break.
The preventive vs detective deep dive expresses one governance requirement twice — once as an SCP that refuses the call, once as a Config rule that notices afterwards.
Every link on this page, plus the rest of the course, is collected and annotated in the resource library.
This is the module where the ground moved most. The control loop on the Detect & respond tab is still the right model — but almost every service that implements a leg of it has shifted. One of them changed its name, which means the console you open after this class will not match the console in the slides. Start with that, then work down the list.
The service this module calls Security Hub — the one that runs the CIS Benchmark and PCI DSS standards and reports control-level pass and fail — is now called AWS Security Hub CSPM. The bare name AWS Security Hub was reassigned to a newer risk-analytics layer that sits above it. Same console family, two products, and the deck predates the split.
This is what the deck means by Security Hub. Cloud Security Posture Management: security standards, automated control checks against your configuration, compliance scores, finding aggregation in ASFF. Everything on the GuardDuty & Security Hub tab about standards and controls describes this service.
New, and a layer up. A risk-analytics service that correlates and enriches signals from GuardDuty, Inspector and CSPM into exposure findings, with a security-focused resource inventory and attack path visualization. It consumes what CSPM produces rather than replacing it.
The new service correlates and enriches signals from GuardDuty, Inspector and Security Hub CSPM, and introduces four things the older posture service did not have: exposure findings, a security-focused resource inventory, attack path visualization, and automated response workflows with ticketing integration. Enable it for a single account or across an organisation with centralized deployment. Pricing was streamlined at the same time.
Why it matters here The GuardDuty & Security Hub tab presents Security Hub as the aggregation point — the place where findings from everything else land and get prioritised. That job is now split across two layers: CSPM still produces standards findings, and the new service reasons across those findings to say which combination of them actually adds up to a reachable risk. The prioritisation argument in this module got stronger, not weaker; it just moved up a floor.
For an exposure finding, Security Hub now evaluates the effective permissions of the IAM principals attached to the exposed resource and identifies the downstream resources reachable beyond it, including privilege-escalation paths. A new Impact Assessment tab lists the prioritized resource sequence and names the permission that makes each hop possible, and the size of the impact scope feeds into severity scoring.
Why it matters here This is the answer to the question the Detect & respond tab raises and cannot resolve with Config alone: two findings of identical severity are rarely equally urgent. A misconfigured resource with no onward permissions and one that can assume a role into your logging account are different incidents. Severity that accounts for reachability is a better queue order than severity that does not.
Enabling Security Hub for an organisation now automatically creates a service-linked IAM Access Analyzer in each member account. It evaluates IAM principals against 90 days of actual access activity to surface unused permissions, roles and credentials, correlates those identity findings with exposure context, and will generate a least-privilege policy on demand from what the principal genuinely used. Included with Security Hub Essentials at no additional cost.
Why it matters here The Two pillars tab frames detective controls as configuration questions. This is a third kind of question: not “is this resource configured correctly?” but “is this permission still being used?” Note the deployment behaviour too — a service that provisions an analyzer into every member account by itself is the same pattern as Config service-linked recorders, and it belongs in the same “who owns this resource” conversation.
Security Hub auto-discovers Azure VMs, Container Registry, Function Apps and Azure identities, and runs posture checks using CIS Benchmarks for Microsoft Azure Foundations. Azure and AWS findings appear in one prioritized view with the same finding formats and automation. Thirty-day free trial, then the same pricing as AWS resources. Not available in Middle East (UAE), Middle East (Bahrain), Asia Pacific (Taipei) or Asia Pacific (New Zealand).
Why it matters here Everything in this module assumes the estate is AWS. Most organisations sitting in this room are not purely AWS, and the honest weakness of a single-cloud detective stack is that the compliance report has a hole in it. One prioritized queue across two providers changes the shape of that conversation.
CSPM added support for CIS AWS Foundations Benchmark v5.0 with 40 controls, enabled organisation-wide through CSPM central configuration. It then added an AI Security Best Practices standard with 31 automated controls, identifier standards/ai-security-best-practices/v/1.0.0, covering network isolation, encryption, VPC placement, KMS key usage, private container registry and authorization. It applies to Bedrock AgentCore runtimes, gateways, memory stores and custom browsers, and to SageMaker notebook instances, endpoints, models, monitoring jobs and feature groups. Free for the first 30 days.
Why it matters here The standards list on the GuardDuty & Security Hub tab is a snapshot, and the version numbers on it age fastest of anything in the module. Check the benchmark version before you claim a compliance posture — enabling “CIS” is not a fixed target. The AI standard is worth noting even if you have no AI workloads yet, because it is the pattern by which a new workload class gets a detective baseline.
A local MCP server exposes Security Hub exposure findings to Claude Desktop, so findings can be queried conversationally rather than through the console. Preview.
Why it matters here Small item, but it points at where triage is going. The bottleneck in the loop on the Detect & respond tab has never been detection volume — it is the human time between a finding arriving and someone understanding it well enough to act. Treat it as directional, not as something to build a process on while it is in preview.
The single biggest conceptual shift in GuardDuty since the deck: the unit of output is no longer always one finding about one event. Extended Threat Detection correlates activity over time into a single finding that describes a sequence, which is a different thing to triage and a different thing to alert on.
For Amazon EKS, GuardDuty correlates audit logs, runtime behaviour, malware execution and API activity, and the resulting finding carries an incident summary, an event timeline, a MITRE ATT&CK mapping and remediation recommendations. Coverage then extended to EC2 and ECS with two new critical finding types: AttackSequence:EC2/CompromisedInstanceGroup and AttackSequence:ECS/CompromisedCluster. Auto-enabled at no additional cost — but how much it sees depends on which protection plans are active, so Runtime Monitoring needs to be on for EC2, and for Fargate or EC2 in the ECS case.
Why it matters here The GuardDuty & Security Hub tab describes GuardDuty as answering a behaviour question about activity. It now also answers a narrative question: which of these events belong to the same intrusion? That matters for the alerting design on the Detect & respond tab, because one AttackSequence: finding replaces a flurry of individually unremarkable ones — and a routing rule that only knows severity will treat it like any other critical finding.
AI Protection analyses CloudTrail management and data events from AWS AI services to detect anomalous model invocations, cost harvesting — forcing excessive GPU or token consumption — and prompt injection attempts, the latter through integration with Amazon Bedrock Guardrails. Enable from the GuardDuty or Security Hub console, or organisation-wide through AWS Organizations. Findings flow into Security Hub. Thirty-day free trial.
Why it matters here Worth pausing on the cost-harvesting detection, because it is the same idea this course makes in M01 about budgets as a control — a cost signal is a security signal. An attacker who cannot exfiltrate your data may still be able to spend your money. That is a threat detection, not a finance report.
GuardDuty can run an investigation itself, using knowledge graphs, threat intelligence and machine learning. The output is a disposition assessment with confidence scoring, MITRE ATT&CK classification, the supporting evidence it relied on, and recommendations covering suppression, containment or remediation. Available in 10 Regions through the console, CLI, API or the AWS MCP Server. Preview.
Why it matters here The loop on the Detect & respond tab has a human-shaped hole between alert and remediate. This is an attempt to fill it. Note what the output actually is — an assessment with a confidence score and a recommendation, not an action. The decision about whether to auto-remediate is still yours, which is exactly the judgement Lab 3 asks you to exercise.
Custom entity lists are generally available and supersede the legacy IP-list format. A single list can hold IP addresses, domains, or both, and lists work in either direction — flagging malicious sources or suppressing alerts from trusted ones. Domain matching added the finding type Impact:EC2/MaliciousDomainRequest.Custom. Permission management is simpler and the change avoids the IAM policy size limits the old approach could hit. Not available in China or GovCloud (US).
Why it matters here If your notes from this module say “threat lists and trusted IP lists”, that is the superseded terminology. The functional gain is domains: a threat list of IP addresses ages badly against infrastructure that rotates addresses, and a domain entry survives that rotation.
Runtime Monitoring added Persistence:Runtime/SensitiveFileModified, PrivilegeEscalation:Runtime/SensitiveFileModified and DefenseEvasion:Runtime/SensitiveFileModified. All three watch five file operations — open-for-write, rename, symlink, link and unlink — which catches obfuscated techniques that slip past monitoring based only on command lines. Requires Runtime Monitoring enabled on EC2, EKS or ECS.
Why it matters here Note the same finding subject appearing under three different threat purposes. That is a useful illustration of why GuardDuty finding names are structured the way they are: the prefix tells you what the attacker was trying to achieve, which is what determines your response, and the suffix only tells you what they touched.
The AWS Config tab splits the service into a recorder and a rule engine, and treats both as yours to configure. That is still true of the ones you create. It is no longer the whole picture, because AWS services now create their own.
Config already supported service-linked recorders. It now supports internal service-linked rules: an AWS service such as Security Hub CSPM can run Config managed rules itself, deliver the results directly back to the deploying service, and do so at no additional Config cost, operating independently of your own recorders and your own rules. Commercial Regions, GovCloud and China.
Why it matters here This resolves a genuinely confusing question that comes up whenever someone opens the Config console in an account governed by Control Tower or Security Hub: who created this recorder and these rules, and can I change them? The answer is that some of them are not yours. They are owned by the service that deployed them, updated through that service, and billed differently. Before you “clean up” an unfamiliar recorder or rule, find out which service put it there.
Conformance packs and organisation-level conformance-pack management became available in Asia Pacific (Malaysia), Asia Pacific (New Zealand), Asia Pacific (Thailand), Asia Pacific (Taipei) and Mexico (Central), deployable through the console, the CLI or CloudFormation. Charging is per conformance pack evaluation, per account, per Region.
Why it matters here Region availability is the sort of detail that decides whether a governance design is deployable or merely designed. It also carries a cost note this module should be honest about: an organisation conformance pack multiplies across accounts and Regions, so the cheapest lever on a Config bill is usually narrowing the Region scope, not removing rules.
AWS::Organizations::PolicyConfig adds resource types continuously: 30 in March 2026 covering Bedrock AgentCore, Cognito, AppSync, IoT and Scheduler; 8 in June including AWS::EC2::VPCEncryptionControl, AWS::NetworkFirewall::ContainerAssociation and AWS::S3Vectors::VectorBucket; 15 in August across Bedrock, OpenSearch Serverless and SageMaker; and 60 in September spanning Bedrock, EC2, SageMaker, AppSync, EKS and AWS Organizations — which is where AWS::Organizations::Policy arrives. New types are tracked automatically if you record all resource types, and are immediately usable in rules and aggregators. Separately, since September 2025 Config records resource tags for IAM policies, so you can scope managed and custom rule evaluations by tag and aggregate IAM policies selectively across accounts — at no additional cost.
Why it matters here Two things. First, the recordable-types list is the real boundary of your detective coverage, and it moves every few months — treat the documentation page as the source of truth rather than any list in any deck. Second, AWS::Organizations::Policy closes a loop back to M01: the SCPs and RCPs in your inheritance hierarchy are now recordable configuration items, so a change to a guardrail leaves a Config timeline entry the same way a change to a bucket does. The governance layer becomes subject to the same detective controls it enforces.
This module draws a line between CloudTrail and Config: one records the API call, the other records the resulting resource state. That line still holds, and the changes below sharpen it — because CloudTrail has grown detective capability of its own rather than only feeding somebody else’s.
UserIdentityAdvanced event selectors for VPC endpoint network activity events now accept UserIdentity as a filter, so you can log only the events that matter — for example access-denied events where the caller is not on a trusted list — and combine that with eventName or vpcEndpointId. The stated aim is detecting exfiltration through VPC endpoints while keeping logging cost down.
Why it matters here Selectivity is what makes a log source affordable enough to leave switched on. The failure mode this module should warn about is not “we forgot to log” — it is “we logged everything, the bill arrived, and someone narrowed it to nothing.” A filter that keeps the denials and drops the routine successes is the shape of a log source that survives its own cost review.
High-volume data events can be consolidated into five-minute summaries across API activity, resource access and user activity, with pre-built templates, configured through the console or CLI. Charging is based on the data events analysed. All commercial Regions.
Why it matters here Data events are where a CloudTrail bill goes wrong — object-level S3 activity produces orders of magnitude more records than management activity. A summary is a different analytical object to a raw event, and it is worth being clear which one you need: summaries answer “did the volume of this activity change?”, raw events answer “who did this specific thing?” The Detect & respond tab needs the second for its investigation step.
Insights previously baselined management-event activity only. It now baselines data-access patterns too, flagging anomalies such as a spike in S3 delete-object calls or a jump in Lambda invocation error rates, and returning the events from the anomaly window so you can look at what actually happened. Charged separately.
Why it matters here This is the distinction the module’s CloudTrail-versus-Config callout is built on, made sharper. Config tells you the bucket’s configuration did not change. Insights tells you the rate at which objects are being deleted from it has. Neither of those is visible to the other, and a mass deletion with no configuration change at all is precisely the incident a Config-only detective stack cannot see.
Lake events can be enriched at ingestion with resource tags and selected AWS global condition keys, and the maximum event size was increased.
Why it matters here Tags are the join key across this entire module — Lab 2 targets resource groups by tag, Config scopes rule evaluations by tag, and CloudWatch enablement rules select accounts by tag. An audit event that already carries the tag can be attributed to a team or an environment without a second lookup against a resource that may since have been deleted.
This one is not an improvement to a service in the module. It is a mechanism that did not exist when the deck was written, and it belongs in the same mental category as an SCP or a declarative policy: something you set once, centrally, that applies to accounts and resources created after you set it. Enablement rules in CloudWatch Telemetry Config turn logging on across an organisation — and they use Config service-linked recorders underneath, which is why they belong on this page rather than anywhere else.
An enablement rule in CloudWatch Telemetry Config turns VPC flow logs on across a whole organisation, across named accounts, or scoped by resource tag such as env:production. It applies to existing VPCs and to VPCs created afterwards. Billing is per Config configuration item plus the vended logs themselves.
Why it matters here Compare this with how the module currently gets logging into a new account: the landing zone configures it at vend time, and anything created outside that path is a gap you find later with a Config rule. An enablement rule is a standing instruction rather than a provisioning step, so a VPC created by hand next month is covered without anyone remembering. That is a preventive-shaped answer to a detective problem, and it is worth adding to the argument on deep-dive-governance-lifecycle.html about closing the loop.
Automatic telemetry configuration extended beyond flow logs to six additional sources: CloudTrail management events, CloudTrail data events, Route 53 Resolver query logs, EKS control plane logs, Network Load Balancer access logs and WAF WebACL logs, across 16 commercial Regions. Alongside it, CloudTrail delivery into CloudWatch Logs was simplified using service-linked channels — no trail required — with safety checks and termination protection. Both CloudTrail delivery charges and CloudWatch Logs ingestion charges apply.
A follow-on change in April 2026 made enablement rules cross-Region: you can now audit and enable telemetry across selected Regions, or all supported Regions, from one Region, and a rule scoped to “all Regions” picks up new Regions as they arrive.
Why it matters here The service-linked channel is the same ownership pattern as the internal service-linked Config rules above: a delivery path created and owned by a service, not a trail you configured. If your runbook for “is CloudTrail going to CloudWatch?” is to list trails, that check now has a blind spot. The cross-Region rules matter for the same reason Region coverage matters in M02 — a Region nobody enabled logging in is a Region with no detective controls at all.
CSPM findings can be delivered into CloudWatch Logs in both ASFF and OCSF, then queried with Logs Insights, turned into metric filters, or integrated with S3 Tables. Enablement is per account or organisation-wide through the same enablement-rule mechanism. All commercial Regions, tiered pricing.
Why it matters here A metric filter over findings gives you something the finding console does not: a number over time that you can alarm on. “Critical findings in production rose above ten” is a monitorable condition; a list of findings is not. That is the missing piece between the detect and alert legs of the loop on the Detect & respond tab.
Lab 2 builds on Automation and resource-group targeting, so two of these matter directly to work you will do in this class. One of them is a cost change that nobody enjoys discovering after the fact.
The Automation free tier of 100,000 steps and 5,000 script-seconds per month is closed to new customers, and ended on 31 December 2025 for existing ones. Underlying pricing did not change: $0.002 per step and $0.00003 per script-second. The same release added useful things — re-executing a runbook from the console with parameters pre-populated from the previous run, automatic retries of throttled API calls under high concurrency, and nested organisational units in target selection.
Why it matters here Two consequences for this module. The cost one first: an auto-remediation design that runs a runbook per non-compliant resource per evaluation used to be effectively free at small scale and now is not, so the per-step cost belongs in the decision Lab 3 asks you to make about whether something should be auto-remediated at all. The targeting one second: nested OU support means an Automation target can follow your inheritance hierarchy from M01 rather than needing a flat account list, which is a meaningful improvement on the resource-group targeting Lab 2 demonstrates.
Patch Manager added the AvailableSecurityUpdate patch state for Windows. It reports security patches that are available but do not conform to the baseline, regardless of severity, and instances in that state are marked Non-Compliant by default. The target case is an instance sitting unpatched behind a long ApprovalDelay while reporting as compliant. The previous behaviour is still available through configuration. No additional charge.
Why it matters here This is a good example of a detective control that was wrong rather than absent — the worst failure mode in this whole module. A missing check produces no signal, which you eventually notice. A check that reports compliant when a patch has been available for six weeks produces a reassuring signal, which nobody investigates. If you run Windows fleets with a long approval delay, this changes your compliance numbers, and the new numbers are the accurate ones.
Run Command supports interpolating parameters into environment variables and handles them as literal strings, which prevents unintended command injection.
Why it matters here Remediation tooling runs with elevated permissions across a fleet by design, which makes it a high-value target. A parameter that reaches a shell unquoted turns your remediation path into an execution path for whoever can influence that parameter — often a resource tag, which is far easier to set than a runbook is to edit.
Systems Manager can manage Azure VMs without manual agent installation or per-instance tier fees, through a Cloud Connector that deploys the SSM Agent at scale. Separately, onboarding to the new Systems Manager experience became customisable — you can choose whether default EC2 instance permissions are applied, and set the frequency of inventory metadata collection and SSM Agent auto-update.
Why it matters here The onboarding options are the more governance-relevant of the two. Default instance permissions and automatic agent updates are convenience settings with real security consequences in both directions, and being asked to choose is better than having them chosen for you. Multicloud agent management pairs with the Azure posture support in Security Hub above: detection and remediation extending to the same non-AWS estate.
Each module page carries its own What’s new tab covering the services it owns. Organizations and the policy types are in M01, Control Tower and the landing zone in M02, and Service Catalog and CloudFormation Hooks in M03. This page covers the detective stack: Config, Systems Manager, GuardDuty, Security Hub, CloudTrail and CloudWatch.