Compliance

Enable AWS security tooling (Config, Access Analyzer, SSM)

One capability across AWS Config, IAM Access Analyzer and Systems Manager: switch on the services that record, detect and manage your estate so the rest of your security posture has something to stand on.

14 min·10 sections·AWS

Last reviewed 16 June 2026

Remediates AWS Security Hub: Config.1 IAM.28 SSM.1 SSM.3

Enabling security tooling: the basics

What does it mean to switch the foundational services on?

Most security controls assume that a handful of foundational services are already running. AWS Config records what exists in your estate and every change to it. IAM Access Analyzer tells you which of your resources are reachable from outside your account. Systems Manager (SSM) gives you a managed plane to patch, inventory and shell into EC2 without opening a port. This capability is about making sure those switches are on, because everything downstream depends on them.

AWS Security Hub turns each switch into its own control, so an estate that has never enabled these services fails several at once. Config.1 checks that AWS Config is recording with the service-linked role. IAM.28 checks that an external access analyzer exists in the Region. SSM.1 checks that EC2 instances are enrolled and managed by Systems Manager. SSM.3 checks that managed instances are compliant with their declared State Manager associations. They read as separate findings, but they are one capability: turn on the tooling that records, detects and manages.

The danger here is the silent one. A disabled recorder, a missing analyzer or an unmanaged instance does not break anything. The dashboard stays green, the application keeps serving, nobody gets paged. The gap only becomes visible the day an auditor asks for evidence, an attacker finds an exposed bucket before you do, or a critical patch cannot be pushed to a box nobody knew was unmanaged. Switching the tooling on is what makes the rest of your posture real rather than assumed.

In this lesson you will learn what each foundational service records, detects or manages, why Security Hub cannot function without them, and how to confirm they are switched on across an estate. The Controls this lesson covers section lists every Security Hub control in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The all-green account that could see nothing

A security team onboarding a newly acquired business unit opened its Security Hub dashboard and found an almost spotless score, a handful of low findings and nothing critical. It looked like the cleanest account in the portfolio. The reason was that AWS Config had never been enabled there: with no configuration items recorded, the vast majority of controls had simply never run. The best account in the org was the only one nobody could see into. Once Config was switched on with the service-linked role, the score dropped from 96% to 61% overnight, not because anything changed but because the recorder could finally see what was there.

Confirming the foundations are on across an estate

Devin is setting up Security Hub across a new workload account and notices the posture score is suspiciously high, 94% with barely any findings. Before celebrating, he checks the one thing that explains an unexpectedly clean account: whether the foundational tooling is actually running.

Rather than work the findings one by one, he starts with the recorder, because if Config is off the rest of the score is built on nothing. An empty configuration-recorder list is the silent blind-spot case the whole capability exists to catch.

Start with AWS Config, the service everything else reads from. An empty recorder list means the posture score is built on missing data.

$ aws configservice describe-configuration-recorders --query 'ConfigurationRecorders[].{Name:name,AllSupported:recordingGroup.allSupported}' --output table

-----------------------------------------------

| DescribeConfigurationRecorders |

+----------------------------------------------+

| (empty) |

+----------------------------------------------+

# No recorder configured. Config.1 fails and every control that reads Config has nothing to evaluate.

An empty recorder list is the dangerous case. The dashboard looks clean because nothing is being recorded.

How AWS decides the tooling is ondeep dive

Each control resolves to a presence-or-state check. Config.1 wants a configuration recorder that is in the started state and bound to the service-linked role AWSServiceRoleForConfig, because a hand-rolled role can silently lack permissions and skip resource types. IAM.28 wants an external access analyzer to exist in the Region, since IAM Access Analyzer is Regional and an analyzer in one Region tells you nothing about another. SSM.1 wants each running EC2 instance to appear in describe-instance-information, which means the SSM agent has authenticated with the AmazonSSMManagedInstanceCore policy over a reachable endpoint. SSM.3 then wants those managed instances to be compliant with their State Manager associations.

These controls are evaluated through AWS Config, mostly on a periodic cycle, so switching a service on does not flip the finding to PASSED instantly. The control-plane change is immediate; the report catches up on the next evaluation. That lag matters when you are gathering audit evidence against a deadline, so query the underlying service directly to confirm state rather than waiting on Security Hub.

The strongest version of this capability is central enablement. AWS Config enabled via AWS Organizations, Access Analyzer baked into the account-provisioning baseline, and Systems Manager Default Host Management Configuration that auto-enrolls every new EC2 instance at launch turn these from a thing someone remembers into a property of how accounts are built. That is the difference between checking the tooling is on today and guaranteeing it is on tomorrow.

What is the impact of leaving the tooling off?

The first impact is a false sense of security. With AWS Config off or partially recording, the controls that depend on it produce no findings, and the posture score reflects only the handful of controls that do not need Config. A 95% score on an account with no recorder is not a 95%; it is an unknown wearing a 95% costume, and decisions made on it are made blind.

The second impact is undetected exposure and unreachable compute. Without an external access analyzer you have no continuous answer to which resources are reachable from outside the account, so a stray cross-account grant goes unnoticed until a third party or a breach surfaces it. Without Systems Manager enrollment, Patch Manager cannot push to an instance, Session Manager cannot reach it, and when a Log4Shell-scale CVE lands the unmanaged fleet is the part you cannot fix from the console.

On the compliance side, every modern framework, SOC 2, ISO 27001, HIPAA, PCI DSS and FedRAMP, expects evidence that you record configuration, detect external access and patch your fleet. A passing set of foundational controls across every account is the cheapest and most defensible artefact you can hand an auditor; a failing set is a gap that stalls a certification or a customer security review at exactly the wrong moment.

How do you switch the foundations on safely?

Work the capability as one loop rather than chasing individual findings. Confirm what is missing, switch each service on with the right role, then enforce it centrally so a new account cannot ship without it.

1. Inventory what is off, in every Region and account

For each Region you use Security Hub in, check that a configuration recorder exists and is recording, that an external access analyzer is present, and that every running EC2 instance appears in the SSM managed list. Do not assume a service is on because it is on somewhere; Config and Access Analyzer are evaluated per Region, and a launch Region or a sandbox account spun up outside the baseline is the usual culprit.

2. Enable AWS Config with the service-linked role

Create the recorder bound to AWSServiceRoleForConfig with allSupported recording, attach a delivery channel, and start it. Record IAM global resources in the home Region only to avoid duplicate configuration items. The service-linked role always carries the permissions Config needs, including for newly supported resource types, so avoid hand-rolled recording roles that can silently skip resources.

3. Create an external access analyzer and enroll EC2 in SSM

Create an ACCOUNT-type (or one ORGANIZATION-type) external access analyzer in every Region you operate in; the first scan runs within minutes and surfaces any genuinely exposed resources to triage. For Systems Manager, attach AmazonSSMManagedInstanceCore to instance roles and confirm the agent, network path and clock so each instance checks in. Resolve any non-compliant State Manager associations once the instances are managed.

4. Make it durable with central enablement

Enable AWS Config via AWS Organizations, bake the analyzer into your landing-zone baseline, and turn on Systems Manager Default Host Management Configuration so new instances enroll at launch. Back each with an AWS Config rule or Service Control Policy so the foundations cannot be quietly disabled. The goal is that the tooling being on everywhere is the enforced default, not a thing someone remembers to do.

# 1. AWS Config: bind to the service-linked role, record all resources, then start.
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
aws iam create-service-linked-role --aws-service-name config.amazonaws.com 2>/dev/null || true
aws configservice put-configuration-recorder \
  --configuration-recorder "name=default,roleARN=arn:aws:iam::${ACCOUNT}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig,recordingGroup={allSupported=true,includeGlobalResourceTypes=true}"
aws configservice start-configuration-recorder --configuration-recorder-name default

# 2. IAM Access Analyzer: create an external access analyzer in this Region.
aws accessanalyzer create-analyzer --analyzer-name external-access --type ACCOUNT

# 3. Systems Manager: enroll an instance role, then confirm it is managed.
aws iam attach-role-policy --role-name app-instance-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws ssm describe-instance-information \
  --query 'InstanceInformationList[].{Id:InstanceId,Ping:PingStatus}' --output table

Quick quiz

Question 1 of 5

A newly acquired account shows a 94% Security Hub posture score with almost no findings, and describe-configuration-recorders returns an empty list. What is the right interpretation?

Keep learning

Go deeper on the foundational services this capability switches on.

You can now treat the foundational tooling as one capability rather than a scatter of findings: confirm what is off in every Region, switch AWS Config on with the service-linked role, create an external access analyzer and enroll EC2 in Systems Manager, then enforce central enablement so a new account cannot ship without it. The Controls this lesson covers section below links every control in this group to its deep page and fix.

Back to the library

Enabling security tooling: the cost and assurance view

A small, mostly metered set of services that underwrites every compliance number you report

These foundational services are the system of record for your security posture. AWS Config is the one with a real, direct cost, billing per configuration item recorded, so it shows up as a line on the bill and sometimes prompts a well-meaning cost question. IAM Access Analyzer's external access analysis is free. Systems Manager enrollment adds no recurring charge. So most of this capability is free to switch on, and the part that is metered is the part you should defend rather than cut.

The framing for finance is that Config spend is the price of assurance and it is small relative to what it underwrites. Turning Config off, or narrowing its scope to save a few hundred pounds a month, quietly disables the evidence base for every compliance framework you are trying to satisfy. The right move is not to minimise it but to make it visible, predictable and explicitly owned, so nobody switches it off in a cost-cutting sweep without understanding what they have also switched off.

Treat a disabled foundational service as a coverage gap rather than a saving. An account without Config recording reports a posture score built on missing data; an account without an analyzer is blind to external exposure; an unmanaged fleet is invisible to patching, rightsizing and audit. Each is cheap or free to close, and the cost of leaving it is the documented cost of an audit failure or a breach the tooling would have caught.

This lesson is for the finance partner who sees AWS Config on the bill and a cluster of tooling findings on the security report and wants to know what the right response is and what it costs. It covers why most of these controls are free to switch on, why Config spend is the one cost to defend rather than cut, and how to keep the foundations funded and protected so nobody disables them in a cost sweep.

Fun fact

The all-green account that could see nothing

How a finance partner frames the foundational-tooling findings

Priya is the finance and risk partner for a multi-account platform team. Security Hub surfaces a cluster of tooling findings on a newly onboarded account: Config.1 failing with no recorder, IAM.28 failing in three Regions, and a batch of SSM.1 findings on EC2 instances that never enrolled. Her first reaction is not to ask what closing them costs, because she already knows the answer is close to nothing. IAM Access Analyzer external access analysis is free, SSM enrollment is an IAM policy attachment with no recurring charge, and the only metered service in the set, AWS Config, bills a small per-configuration-item amount that is trivial next to what it underwrites.

She reads the findings as a coverage question rather than a spend question. The Config.1 failure is the one that worries her most: with no recorder, the account's posture score is built on missing data, so every other compliance number she reports off that account is unreliable until it is switched on. Her output for the risk pack is short. AWS Config is classified as assurance spend, forecast against estate size so its growth is expected rather than alarming, and protected by a sign-off requirement so nobody trims it in a cost sweep without understanding they are also disabling the evidence base. The free fixes, the analyzer and SSM enrollment, are simply scheduled. The number she tracks is accounts without the foundations enabled, where anything above zero is a coverage gap, not a saving.

Why the foundations belong on the assurance line, not the chopping block

The cost model here is unusual. Most of the capability is free to switch on: IAM Access Analyzer's external access analysis costs nothing, and Systems Manager enrollment is an IAM policy attachment with no recurring charge. The one metered service is AWS Config, which bills per configuration item recorded and so grows with the estate. That growth tends to make it a recurring target in cost reviews, and the instinct to trim it is understandable and almost always wrong.

What the Config spend underwrites is the compliance evidence behind every framework you report against and every customer security questionnaire you answer. Disabling it or narrowing its scope to save money does not reduce risk-adjusted cost; it converts a visible, defensible expense into an invisible liability. The few hundred pounds saved are dwarfed by the cost of a failed audit, a breached contract clause or an incident you cannot reconstruct because the configuration history was not being recorded.

The right financial treatment is to classify Config as assurance spend rather than discretionary infrastructure, forecast it against estate size so its growth is expected, and require security sign-off before any service in this capability is disabled or scope-reduced. Track accounts without the foundations enabled as a risk metric; a number above zero is a coverage gap, not a saving.

What finance can do about the foundational-tooling gap

Finance cannot enable a recorder or create an analyzer, but it can stop the one metered service in this group from being cut by mistake and turn a scatter of tooling findings into a funded, owned default. Three levers.

1. Classify AWS Config as assurance spend, not discretionary infrastructure

AWS Config is the one service here with a real per-configuration-item cost, and because it grows with the estate it becomes a recurring target in cost reviews. Reclassify it as assurance spend that underwrites every compliance framework and customer security questionnaire the business answers, and forecast it against estate size so its growth is expected rather than flagged as an anomaly. The few hundred pounds a month it costs is the price of the evidence base, and trimming it converts a visible expense into an invisible liability.

2. Separate the free fixes from the one metered service

Make explicit that IAM Access Analyzer external access analysis and Systems Manager enrollment add no recurring charge, so there is nothing to fund there, only engineering minutes to schedule. The cost conversation begins and ends with AWS Config. Keeping that distinction clear stops a cost question about one Config line item from accidentally sweeping the free controls into a deferral, and stops anyone treating the analyzer or SSM as a budget item that needs approval before it can be switched on.

3. Track accounts without the foundations as a risk metric and require sign-off to disable

Put accounts-without-the-foundations on the risk register as a coverage number, where anything above zero is a gap rather than a saving, and report it alongside the estimated exposure of running blind in those accounts. Then require security sign-off before any service in this capability is disabled or scope-reduced, so the foundation of the compliance story can never be removed by accident in a cost-cutting sweep. Keep any deliberate scope reduction finance-visible rather than silently applied.

Quick quiz

Question 1 of 5

What is the cost profile of the three foundational services in this capability?

Keep learning

Go deeper on the foundational services this capability switches on.

You have finished the finance view of foundational security tooling. You know that most of this capability is free to switch on, that AWS Config is the one metered service and the one to defend rather than cut because it underwrites every compliance number you report, and that the right treatment is to classify Config as assurance spend, forecast it against estate size, and require sign-off before anyone disables it. Next time a cluster of tooling findings lands, you will fund and protect the recorder rather than ask how to trim it, and you will track accounts without the foundations as a coverage gap.

Back to the library

Enabling security tooling: the headline

Whether the services your whole security posture rests on are actually switched on

Every compliance and posture number the organisation reports is read from a small set of foundational services: the recorder that tracks what exists in the cloud, the detector that watches for external exposure, and the management plane that patches and inventories your servers. This capability is about confirming those switches are on, because a green dashboard with the recorder off means nothing.

The leadership question is not the count of findings; it is whether these foundations are enabled everywhere by default rather than left to whoever remembers. The defensible end state is that AWS Config, IAM Access Analyzer and Systems Manager are on in every account and Region, enforced centrally, with any disabling requiring explicit security sign-off.

Most of this is free. The one metered service, AWS Config, is a cost worth defending, not cutting. This is a governance decision about whether your posture sits on a real foundation or only on the assumption that someone enabled it.

A short read for the leader who needs to know why one small set of services sits underneath the entire compliance story, what their absence means for the credibility of posture reporting, and the single governance guardrail worth insisting on: enabled everywhere by default, disabled only with sign-off.

Fun fact

The all-green account that could see nothing

What it looks like when the foundations are on by default

After a newly acquired business unit was onboarded and its Security Hub score sat suspiciously high at 96%, the CTO asked the security team one question: are we confident that score reflects reality, or are we just not recording anything. The honest answer was the latter. AWS Config had never been enabled in that account, so the vast majority of controls had never run, and switching the recorder on dropped the score to 61% overnight, not because anything had changed but because the recorder could finally see what was there.

The team stopped treating foundational tooling as a per-account checklist and made it a property of how accounts are built. AWS Config is now enabled centrally through AWS Organizations, IAM Access Analyzer is baked into the landing-zone baseline so every Region gets an analyzer, and Systems Manager Default Host Management Configuration auto-enrolls every new EC2 instance at launch. Service Control Policies and Config rules back each one so the tooling cannot be quietly disabled in a cost-optimisation drive or a provisioning shortcut. The next onboarding answered the CTO differently: the foundations were on before anyone looked at the dashboard, and the score read clean because it was clean. That standing default, enforced and exception-only, is the governance signal, not the individual control ticks.

Why this sits underneath everything

Most controls answer whether one thing is configured safely. This capability answers a more fundamental question: can we see, detect and manage at all? A disabled recorder, a missing analyzer or an unmanaged fleet does not create one gap; it silently disables the visibility, detection and management layers the entire posture depends on. A high score on top of that is the single most misleading state in cloud security.

The risk leadership should hold is that the foundations get disabled for right-sounding wrong reasons: a cost-optimisation initiative, an account cleanup, a provisioning shortcut. Each is reasonable in isolation and each can invalidate the assurance the business reports. The durable move is a guardrail. The tooling stays on everywhere, enforced centrally, and turning it off requires explicit security sign-off, so the foundation of the compliance story can never be removed by accident.

The leadership move on foundational tooling

The executive handle is not to approve each control individually but to insist the foundations are on everywhere by default and can only be turned off deliberately, so the posture sits on a real foundation rather than an assumption. Three moves.

1. Set a default: the tooling is on in every account and Region

Make it policy that AWS Config, IAM Access Analyzer and Systems Manager are enabled everywhere by default, enforced through AWS Organizations and the landing-zone baseline rather than left to whoever remembers at account-creation time. The right place to enforce this is the account-provisioning process, so a new account cannot ship without the recorder, an analyzer in each Region, and auto-enrollment for new instances. Central enablement turns the failing-control count into an exception report, not a to-do list.

2. Demand proof the foundations cannot be silently disabled

A clean report is not the proof; the proof is that the tooling cannot be turned off by accident. Ask to see the Service Control Policies and AWS Config rules that prevent a recorder being stopped, an analyzer being deleted, or Default Host Management being disabled, and confirm that disabling any of them requires explicit security sign-off. The foundations get switched off for right-sounding wrong reasons, a cost initiative, an account cleanup, a provisioning shortcut, and a guardrail is what stops a reasonable-in-isolation decision invalidating the whole assurance story.

3. Ask for the coverage rate, not the finding count

At the operational review the question worth asking is not how many tooling findings are open but what percentage of accounts and Regions have all three foundations enabled, and what the documented exceptions are. A coverage rate consistently at or near 100% with the rare exception on the record is a healthy signal that posture reporting can be trusted. A rate below that, or accounts where the recorder is off and the dashboard still reads green, is the most misleading state in cloud security and an accountability conversation.

Quick quiz

Question 1 of 5

What is the central leadership question about this set of foundational services?

Keep learning

Go deeper on the foundational services this capability switches on.

Two takeaways: a green dashboard with the recorder off means nothing, so this is a governance decision about whether your posture sits on a real foundation or only on the assumption that someone enabled it; and the right end state is AWS Config, IAM Access Analyzer and Systems Manager on in every account and Region, enforced centrally, with any disabling requiring explicit security sign-off. The cost is small and mostly free; the foundation is non-negotiable.

Back to the library

Controls this lesson covers

One capability, many AWS Security Hub controls. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Enable AWS security tooling (Config, Access Analyzer, SSM)

Enabling security tooling: the basics

The all-green account that could see nothing

Confirming the foundations are on across an estate

How AWS decides the tooling is ondeep dive

What is the impact of leaving the tooling off?

How do you switch the foundations on safely?

1. Inventory what is off, in every Region and account

2. Enable AWS Config with the service-linked role

3. Create an external access analyzer and enroll EC2 in SSM

4. Make it durable with central enablement

Quick quiz

Keep learning

Enabling security tooling: the cost and assurance view

The all-green account that could see nothing

How a finance partner frames the foundational-tooling findings

Why the foundations belong on the assurance line, not the chopping block

What finance can do about the foundational-tooling gap

1. Classify AWS Config as assurance spend, not discretionary infrastructure

2. Separate the free fixes from the one metered service

3. Track accounts without the foundations as a risk metric and require sign-off to disable

Quick quiz

Keep learning

Enabling security tooling: the headline

The all-green account that could see nothing

What it looks like when the foundations are on by default

Why this sits underneath everything

The leadership move on foundational tooling

1. Set a default: the tooling is on in every account and Region

2. Demand proof the foundations cannot be silently disabled

3. Ask for the coverage rate, not the finding count

Quick quiz

Keep learning

Controls this lesson covers

Config

IAM

SSM

Related compliance lessons