Config Says CloudTrail Isn't Logging a Region: The Fix

If AWS Config is telling you CloudTrail isn't logging a region, the fix is almost never "turn CloudTrail on" — it's already on. The real problem is usually that your trail is single-Region, or the flagged Region is an opt-in Region CloudTrail was never told to watch, or AWS Config itself was never turned on in that Region to check. And here's the part that catches even experienced admins off guard: a trail can say Multi-region trail: Yes in the console and still leave gaps, because "multi-Region" only means new Regions get added automatically going forward — it says nothing about whether AWS Config, in that specific Region, was ever switched on to notice.

Jake found out the hard way, on a Tuesday, mid-lunch rush.

He runs a phone repair and resale shop, and a couple of years back he built a small AWS-hosted storefront so he could sell refurbished handsets online without paying a marketplace's cut. A wholesale supplier he'd been trying to land for months finally sent over a security questionnaire before signing the contract — standard stuff, the kind cyber-insurance brokers and B2B partners send everyone now. One line stopped him cold: "Confirm AWS CloudTrail is enabled and logging management events in all AWS Regions used by the account." He logged into AWS Config, found the compliance dashboard, and saw it in red: multi-region-cloudtrail-enabled — NON_COMPLIANT.

"I turned CloudTrail on when we built the thing," he told Ethan on the phone. "It's right there, on, green checkmark and everything. Why does this other tool say it's broken?"

What "CloudTrail not logging a Region" actually means

CloudTrail is AWS's audit log — every time someone creates an access key, deletes a security group, or logs into the console, CloudTrail is the service that writes that action down. AWS Config is a separate service that continuously checks whether your account's settings match a set of rules you, or a security team, chose to enforce. Config doesn't do the logging itself; it just grades your homework against a rubric, on a schedule, and reports pass or fail.

So "AWS Config: CloudTrail not logging a Region" isn't one specific error message. It's the plain-English way people describe what happens when one of three AWS Config managed rules — cloudtrail-enabled, multi-region-cloudtrail-enabled, or cloudtrail-security-trail-enabled — comes back NON_COMPLIANT, usually accompanied by a note about a Region with no activity, or an auditor's checklist item asking you to prove logging covers every Region the account can touch.

The single most common cause, by a wide margin, is a trail that was created as single-Region — often years ago, often by a script or a CloudFormation template someone copy-pasted — and was never converted. The second most common is a legitimately multi-Region trail that still has a gap in one specific opt-in Region. The third is AWS Config itself not being switched on in the Region that's showing the gap, which produces a confusing "no data" result that looks like a logging failure but isn't one. Further down this page you'll also find the two quieter causes — excluded management event sources, and silent delivery failures — that don't show up until you've already ruled out the obvious ones.

The three AWS Config rules that raise this flag

Before you touch anything, open AWS Config, find the exact rule name showing NON_COMPLIANT, and match it here. Fixing the wrong thing — say, re-encrypting a trail that was already multi-Region — wastes an afternoon and doesn't move the needle on the rule that's actually failing.

That last row is the one that trips people up. cloudtrail-security-trail-enabled is a bundled "best-practices" rule — it's COMPLIANT only if one trail in the account satisfies every condition on the list simultaneously. If your multi-Region trail is missing KMS encryption, or your encrypted trail isn't multi-Region, the rule reports NON_COMPLIANT even though you technically have two trails that, added together, cover everything. Config doesn't add trails together. It needs one trail doing all seven jobs.

Symptom-first triage: match what you're seeing to the cause

Ethan's habit, before he touches a single setting, is to ask exactly what's on screen. "Half the time," he says, "people are about to fix a problem they don't have, because two different failures produce the same-looking red X."

1. Trail details page shows "Multi-region trail: No." This is cause #1 — a single-Region trail. Skip to converting it.
2. Trail shows "Multi-region trail: Yes," but one specific Region still shows gaps or "no data" in Config. Check whether that Region is an opt-in Region. Go to opt-in Regions.
3. The trail looks correct everywhere you check, but AWS Config itself shows "No data" for that Region, not NON_COMPLIANT. That's not a CloudTrail problem — it's Config's own recorder. Go to the recorder cause.
4. Trail is multi-Region and encrypted, but multi-region-cloudtrail-enabled or the security rule still fails. Check event selectors for excluded management events. Go to excluded events.
5. Config sees the trail, but the trail's own status page shows a delivery error. Go to delivery failures — events may be generated but never actually landing anywhere.
6. Everything above checks out, but you manage more than one account. The gap may be visible only in an aggregator view, or only in one member account of an organization. Go to multi-account gaps or the organization trail section.

Cause 1: the trail was never made multi-Region

This was Jake's problem, and it's the most common one on this whole page. A single-Region trail only captures management events happening in that one Region. Every other Region — every EC2 instance spun up in Mumbai, every S3 bucket created in Frankfurt, every console login from an unexpected place — goes completely unlogged for that trail. It isn't a partial record. It's a blind spot, and blind spots are exactly what an attacker or a runaway automation script is most likely to use, precisely because nobody is watching there.

When you create a brand-new trail through the CloudTrail console, it applies to all Regions by default, and there's a toggle right there letting you confirm that. The trap is existing trails — ones set up years ago via a script, an old CloudFormation stack, or a rushed console session where that toggle got flipped off without anyone noticing. Those don't fix themselves just because AWS added new Regions since, and they don't fix themselves just because someone else on the team assumed "of course it covers everywhere, why wouldn't it."

Worth knowing before you flip that switch: converting to multi-Region doesn't touch anything already sitting in your S3 bucket, and it doesn't cost you the trail's name, its existing bucket policy, or its KMS key setup. It's purely a scope change — instead of "watch this one Region," the instruction becomes "watch every Region currently enabled on this account, and any new one AWS adds later." That last part matters more than it sounds like; it's the reason multi-Region trails exist in the first place, since it means you're covered the day a new Region launches without having to remember to do anything.

Cause 2: the missing Region is an opt-in Region

Here's the term that trips up almost everyone who hasn't hit it before: an opt-in Region. Most AWS Regions are switched on for your account automatically the day you sign up. A smaller group — generally the newer ones, things like the Middle East, parts of Africa, and a handful of Asia-Pacific locations — are switched off by default. You have to explicitly enable them under Account settings before AWS will let anything run there.

Multi-Region CloudTrail logs activity from every Region enabled on the account. That's the important nuance: multi-Region doesn't mean "every Region AWS has ever built." It means every Region you've turned on. If an opt-in Region has never been switched on, there's nothing for CloudTrail to log there anyway — but if it has been switched on, maybe by a developer testing something once, two years ago, and forgotten about, and CloudTrail's multi-Region trail was created before that Region existed or was enabled, you can end up with a genuine coverage gap that Config correctly flags.

If nobody actually needs that opt-in Region — it was enabled once by accident and nothing runs there — the honest fix for a lot of shops is disabling the Region again, which removes it from the account's active footprint entirely and, as a side effect, removes it from the list Config expects your trail to cover. If it's legitimately in use, your multi-Region trail should already be picking it up automatically once it's enabled; if it isn't, that's usually a sign the trail predates the Region being switched on, and re-saving the trail — even without changing anything visible — or re-running the update-trail command again will re-sync its Region list against the account's current Region roster.

Cause 3: AWS Config's own recorder isn't running there

This is the cause that gets misdiagnosed most often, because it looks exactly like a CloudTrail failure but has nothing to do with CloudTrail at all.

AWS Config, unlike CloudTrail, is not automatically Regional-aware the same way. You have to explicitly turn on Config — specifically, its configuration recorder, the component that actually watches for changes and records them — in every single Region where you want it evaluating rules. If you enabled Config in your home Region (say, US East, N. Virginia) and never touched Config's settings anywhere else, then Config in every other Region simply has no recorder running, no data, and nothing to evaluate. It's not that CloudTrail failed the rule in that Region. It's that nobody asked Config to check.

Enabling the recorder in a new Region is a short, one-time setup: switch the console to that Region, open AWS Config, and if it hasn't been touched before you'll land on a "Get started" page rather than a dashboard — that alone is a signal Config has never run there. From that page you choose whether to record all supported resource types or a narrower list, whether to include global resource types like IAM (you generally only want that checked once, in one Region, to avoid duplicate global-resource records), and which S3 bucket and, optionally, SNS topic to use for delivery. None of this changes anything about CloudTrail. It's a completely separate service switch that happens to live right next to the compliance dashboard people assume CloudTrail owns.

This matters even more if your organization uses an aggregator to pull compliance data from multiple accounts and Regions into one dashboard, which is exactly where this cause tends to disappear into the noise — more on that below.

Cause 4: management events are quietly excluded

A trail can be perfectly multi-Region and still fail multi-region-cloudtrail-enabled or the bundled security rule because of a setting almost nobody looks at twice: the event selector's ExcludeManagementEventSources field.

This field lets a trail deliberately skip logging management events from specific noisy AWS services — historically, things like AWS Key Management Service (KMS) decrypt calls or the Amazon RDS Data API, both of which can generate an enormous volume of routine, low-value log entries if left in. It's a real, sometimes sensible cost- and noise-control feature; a busy account can rack up a surprising S3 storage bill from KMS decrypt events alone if every encrypted object read gets logged in full detail. But both Config rules that check for multi-Region coverage treat any non-empty value in that field as disqualifying — even if you're only excluding one narrow, high-volume event source for a good reason. The rule doesn't grade the exclusion on its merits. It just checks whether the field is empty.

Cause 5: events are captured but delivery is silently failing

The scariest version of this problem is the one that doesn't show up as NON_COMPLIANT at all — because Config isn't checking whether files are actually landing in your S3 bucket, only whether the trail's configuration is correct. A trail can be multi-Region, encrypted, validated, and pointed at the right bucket on paper, while actually failing to deliver a single log file, because the bucket policy changed, the KMS key was rotated without updating the trail's grant, or someone tightened an S3 bucket policy for an unrelated reason and broke CloudTrail's write permission in the process.

The trail's own details page in the console will show a delivery warning when this happens, but it's easy to miss if you're only watching the Config dashboard. The fastest way to check from the command line is get-trail-status, which returns a LatestDeliveryError field describing any Amazon S3 error CloudTrail hit while trying to write, and a separate LatestCloudWatchLogsDeliveryError field if you're also streaming to CloudWatch Logs and that leg is broken.

Fixing it from the AWS Management Console

The console works fine for reviewing a trail's current settings, and it's where you'll create a brand-new trail if you don't have one yet. Where it falls short is converting an existing single-Region trail — that specific change has to go through the CLI, covered next, so treat the console as the read-and-confirm step, not the fix itself, if you already have a trail.

1. Open the CloudTrail console and select Trails. Click the trail name that Config's finding points at — if you're not sure which trail that is, Config's finding usually names the trail's ARN.
2. Check the General details panel. Confirm the Multi-region trail value. If it already reads Yes, the problem is elsewhere on this page — jump to the triage table above rather than editing settings that are already correct.
3. If you're creating a brand-new trail instead, choose Create trail, give it a name, and make sure Apply trail to all Regions is set to Yes — this is the toggle that determines everything downstream.
4. Under Management events, choose Read and Write so both event types are captured, and leave the event source exclusion list empty unless you have a specific, deliberate reason not to.
5. Point the trail at an S3 bucket you control, and if the compliance requirement calls for it, turn on SSE-KMS encryption and log file validation on the same screen — these are two of the seven conditions the bundled security rule checks.
6. Save, then switch AWS Regions in the top-right corner of the console and confirm AWS Config shows a recorder Recording in the specific Region that was originally flagged. This step gets skipped constantly, and it's the one that actually closes out cause #3.

Fixing it from the AWS CLI

The CLI is a command-line tool that lets you type AWS commands instead of clicking through the console — think of it as texting AWS instead of navigating its website. For converting an existing single-Region trail, it's not just the more convenient option, it's the only supported one; the console can't retroactively toggle that setting on a trail that was created without it.

1. Confirm your current trail settings first. Run aws cloudtrail describe-trails and look at the IsMultiRegionTrail field in the output — this is your before-and-after check.
2. Convert the trail to multi-Region. Run aws cloudtrail update-trail --name your-trail-name --is-multi-region-trail. This changes the setting in place — no deletion, no gap in the existing log history that's already sitting in your S3 bucket.
3. Confirm the change took. Run describe-trails again and check that IsMultiRegionTrail now reads true.
4. Check for delivery problems. Run aws cloudtrail get-trail-status --name your-trail-name and read the LatestDeliveryError field. An empty value means clean delivery; anything else is a bucket permission or KMS grant problem to chase down separately.
5. If the exclusion field is your problem, check it with get-event-selectors --trail-name your-trail-name and clear ExcludeManagementEventSources using put-event-selectors with an empty exclusion list, or create a second, separate trail that carries no exclusions.

Verifying the fix actually worked

Changing the setting isn't the finish line — AWS Config rules run on a schedule, not the instant you save something, so seeing red for a while after you fix the underlying problem is normal, not a sign the fix failed.

The rules covered here are periodic, meaning Config re-checks them on its own timer rather than the moment a resource changes. If you don't want to wait, most Config rules can be manually re-evaluated from the rule's detail page in the console — look for a Re-evaluate button. Give it a few minutes after clicking it before you check the compliance status again; the evaluation itself isn't instant either.

One habit worth building here: test with a real, low-stakes action in the Region you just fixed. Log into the console with a Region-specific sign-in link, or run one harmless CLI command scoped to that Region, then check CloudTrail's Event history filtered to that same Region a few minutes later. If the event shows up, you've confirmed logging is actually flowing — not just that a checkbox looks right in a settings page.

Checking this across many accounts with an aggregator

Everything above assumes you're looking at one account, one Region at a time. Once you're past a handful of accounts, almost nobody checks compliance that way — they use an AWS Config aggregator, a resource that pulls compliance data from multiple source accounts and Regions into a single dashboard, usually sitting in a dedicated security or audit account.

The trap here is subtle and easy to miss for months at a time: an aggregator can only display what the source accounts actually recorded. If a source account never enabled the Config recorder in a given Region — cause #3 above, just multiplied across every account in your organization — that account-Region combination doesn't show up in the aggregator as non-compliant. It just doesn't show up at all. On a dashboard with dozens of accounts and a dozen Regions each, "doesn't show up" reads exactly like "nothing to worry about," which is precisely backwards.

Ethan's had this exact call before, from a different client — a small logistics firm whose overnight forecasting job only spins up compute in a second Region once a month, on payroll-processing night, because that's the one workload that needs the extra capacity there. Nobody had enabled the Config recorder in that Region, because nobody was ever in that Region long enough to notice the "Get started" page. The gap sat there for the better part of a year, invisible on the aggregator dashboard, for the same reason a printer that only jams on Mondays doesn't get fixed — it's simply not in front of anyone often enough to register as a pattern. It took a routine external audit, not an internal review, to surface it.

The fix is the same one covered above — enable the Config recorder in every Region every account actually uses, not just the Region someone happened to be sitting in the day the account was created — but at scale, doing that by hand, account by account, Region by Region, is exactly the kind of job that belongs to infrastructure-as-code or a landing-zone guardrail rather than a person clicking through consoles. More on that in the automation section below.

Edge cases: Control Tower guardrails, SCPs, and cross-account roles

A handful of setups produce Region-logging gaps for reasons that look like the causes above but need a slightly different fix.

AWS Control Tower landing zones. If your accounts were set up through Control Tower, there's usually a Control Tower-managed CloudTrail trail already covering every Region in your organization, separate from anything you'd create yourself. If Config is flagging a Region here, check whether a well-meaning team member created a second, manual trail on top of the Control Tower one — and whether that second trail is the single-Region one actually failing the check, while the Control Tower trail quietly passes. Config only needs one compliant trail, so in this situation the fix is often deleting or ignoring the redundant manual trail rather than fixing it.

Service control policies (SCPs) restricting Regions. Some organizations use an SCP to deny API calls outside an approved list of Regions, as a security control. If a Region is denied by SCP, nothing can run there — including, in some configurations, the Config recorder's own attempts to operate there. In that case a "gap" in that Region isn't a logging failure at all; it's the SCP doing exactly what it was built to do. Confirm with your organization's SCP policy before spending time trying to "fix" a Region that's deliberately locked out.

Cross-account roles and assumed-role activity. When a user in Account A assumes a role into Account B to do work, CloudTrail in Account B logs the activity performed there, under the assumed role's identity — not under the original user's identity in Account A. If you're trying to trace a specific person's actions across a Region and coming up empty, check whether the activity actually happened under an assumed role in a different account's trail, rather than assuming the Region itself has a logging gap.

Third-party and automated compliance tools — when they actually help

Plenty of cloud security posture management tools sit on top of AWS Config and CloudTrail, showing you the same NON_COMPLIANT findings in a nicer dashboard, sometimes bundled with remediation buttons. Whether they're worth adding depends almost entirely on how many accounts you're running, not on how urgent this particular finding feels.

For a single-account shop like Jake's, none of that machinery is worth the setup time. Run the CLI command once, verify it, move on — a dedicated compliance platform for one AWS account is solving a problem you don't have yet. The honest advice, and the one Ethan gives most often, is to hold off on any third-party tool until you're managing enough accounts that clicking through each one by hand has become the actual bottleneck, not before.

Automating this so it doesn't come back

Once you've fixed the finding once, the next question worth asking is how it happened in the first place — usually because trail creation was a manual, one-time console session rather than something repeatable. A few habits close that gap for good:

Bake it into infrastructure-as-code. If your account setup runs through CloudFormation, Terraform, or a similar tool, define the CloudTrail trail there with multi-Region explicitly set, rather than relying on someone remembering to check a box during a manual setup. A trail defined in code gets the same settings every single time, on every new account.

Use AWS Config's own remediation feature for a fast re-check loop. AWS Config supports attaching a remediation action to a rule, so that when a resource goes NON_COMPLIANT, an SSM Automation document can run automatically to correct it — in this case, that could mean automatically calling update-trail on a known trail name if it's ever found single-Region again. This is worth setting up once you trust the process, not on day one; automatically modifying a security-critical trail is not something to wire up untested.

Alert on the compliance change itself, not just the fix. Config can emit an event through Amazon EventBridge every time a rule's compliance status changes. Routing that to a notification channel — email, chat, whatever your team already watches — means the next time someone accidentally creates a single-Region trail, or an opt-in Region gets enabled without the Config recorder following it, you hear about it within the hour instead of finding out during the next vendor questionnaire.

The organization trail special case

If your AWS setup uses AWS Organizations with a single trail managed at the management-account level and applied across every member account, there's an extra layer to this problem. Member accounts only send their activity to that shared organization trail for Regions they've actually opted into — if the organization trail's home Region happens to be an opt-in Region itself, a member account that never enabled that specific Region simply won't forward anything to the org trail, and no amount of fiddling with the org trail's own settings will change that. The member account has to opt into the Region first.

If you're also aggregating CloudTrail event data stores rather than classic trails, there's a parallel rule — cloudtrail-event-data-store-multi-region — that checks whether an event data store ingesting live events has its multi-Region setting turned on, separately from anything the classic trail rules are checking. Don't assume fixing one automatically satisfies the other; they evaluate different resource types.

What this actually costs when nobody catches it

Jake's version of this cost him a stalled contract negotiation and an uncomfortable phone call explaining, mid-audit, why his logging had a hole in it. That's the cheap version. The expensive version is the one nobody notices until something actually goes wrong in an unmonitored Region — a compromised access key gets used to spin up resources somewhere the account owner never looks, and because the trail never covered that Region, there's no record of it happening at all. Insurance underwriters and enterprise procurement teams ask for multi-Region CloudTrail specifically because that blind spot is a real, well-understood attack pattern, not a box-ticking formality.

Ethan puts it more bluntly: "A single-Region trail isn't 90% of an audit log. It's a false sense of having one."

Frequently asked questions

Why does AWS Config say CloudTrail isn't logging a Region if the CloudTrail console shows "Multi-region trail: Yes"?

Multi-Region only means the trail covers every Region currently enabled on the account. If AWS Config itself has no recorder running in the flagged Region, Config has nothing to evaluate there and reports a gap — that's usually a Config setting, not a CloudTrail one. Delivery failures and excluded management event sources can also make a technically-multi-Region trail fail a stricter rule, so a "Yes" on that one field doesn't clear you on every rule at once.

What's the difference between cloudtrail-enabled and multi-region-cloudtrail-enabled?

cloudtrail-enabled only checks that a trail exists, optionally matching a specific bucket or ARN you name. multi-region-cloudtrail-enabled goes further, requiring that at least one trail actually be set to multi-Region and not exclude management event sources. You can pass the first and fail the second, and most accounts that hit this page are in exactly that spot.

Can I fix a single-Region trail without deleting it?

Yes. Run aws cloudtrail update-trail --name your-trail --is-multi-region-trail. It converts the existing trail in place and keeps every log file already delivered to its S3 bucket — nothing is lost, and nothing needs to be re-created.

Why is one specific Region still non-compliant after I made my trail multi-Region?

The most common reason is that AWS Config's own configuration recorder was never enabled in that Region, so Config has no data to grade. Switch to that Region in the console, open AWS Config settings, and confirm the recorder shows Recording. If it does and the finding persists, check whether the Region is an opt-in Region that was enabled after the trail was last saved.

What's an opt-in Region and how do I know if I have one?

It's an AWS Region that isn't automatically switched on for new accounts — you have to enable it explicitly under Account > AWS Regions. Most of the well-known, older Regions are enabled by default; a smaller set of newer ones are not, and the list can change as AWS launches new Regions, so it's worth checking the current status rather than assuming it matches what you remember.

Do I need to create a separate trail specifically for an opt-in Region?

No. Once the opt-in Region is enabled on the account, an existing multi-Region trail should pick it up. If it doesn't, re-saving the trail's settings or re-running the update-trail command typically re-syncs its Region coverage against the account's current Region list.

Why does AWS Config itself show "No data" instead of NON_COMPLIANT for a Region?

"No data" means Config's recorder was never enabled in that Region, so there's nothing to evaluate — that's different from a compliance failure, and it means the check hasn't run there at all, not that it ran and passed. This is also the finding that tends to hide inside multi-account aggregator dashboards.

Does enabling AWS Config in an additional Region cost extra?

AWS Config bills based on configuration items recorded and rule evaluations, and those are tracked per Region, so turning on the recorder in a Region you're actively using will add some cost tied to that Region's own resource activity — check the current AWS Config pricing page for the specific rates, since they're set independently of anything in CloudTrail.

Why is my trail multi-Region, but IAM events only show up in one Region?

That's expected and not a bug. CloudTrail logs IAM console user activity only in the US East (N. Virginia) Region, because IAM itself is a global service with a single endpoint. Filter Event history to that Region specifically when you're chasing IAM activity, rather than assuming other Regions are missing that data.

What does ExcludeManagementEventSources actually exclude?

It's an event selector setting that lets a trail skip logging management events from a specific, named AWS service source — commonly used to cut down on high-volume, routine entries from services like AWS KMS. Both multi-Region Config rules treat any non-empty value in this field as disqualifying, regardless of which service is excluded or how sensible the reason.

My S3 bucket has files from every Region — so why does Config still say non-compliant?

Config evaluates the trail's configuration, not the contents of your bucket. It's entirely possible for older log files to already exist from before a setting changed, while the trail's current configuration no longer matches what the rule requires. Check the trail's live settings with describe-trails, not the bucket's file listing.

What's the fastest way to see delivery errors from the CLI?

Run aws cloudtrail get-trail-status --name your-trail-name and check the LatestDeliveryError and LatestCloudWatchLogsDeliveryError fields — an empty result on both means delivery is currently healthy. Make this a recurring check, not a one-time one.

Do I need CloudWatch Logs as well as S3, or is S3 enough?

S3 alone satisfies the core logging rules covered on this page. CloudWatch Logs integration is a separate, optional destination that some accounts add for real-time alerting on specific events — it's checked by its own Config rule, not by the multi-Region ones, so it's not required to pass the rules discussed here.

What happens to logging in a Region if I disable it later?

Because an account may still have residual activity in a Region you're disabling — for example, AWS services cleaning up remaining resources — CloudTrail continues attempting to capture and deliver activity for any trail that isn't deleted, right up until the Region is fully disabled.

Is the AWS Management Console the only place to fix this, or should I use the CLI?

For converting an existing single-Region trail, the CLI is required — the console can review and confirm settings but can't retroactively flip that specific setting on an already-created trail. Use the console for creating a brand-new trail or reviewing status; use the CLI for the actual conversion.

Our AWS Organizations setup has an org trail — why is one member account's Region still flagged?

Member accounts only forward activity to a shared organization trail for Regions they've personally opted into. If the org trail's home Region is itself an opt-in Region, a member account that never enabled that Region won't send anything to it — the fix has to happen at the member account level, not the org trail's settings.

Revision note. Written September 2026, covering the current AWS Config managed rules for CloudTrail (cloudtrail-enabled, multi-region-cloudtrail-enabled, cloudtrail-security-trail-enabled), current opt-in Region behavior, and multi-account aggregator and Control Tower edge cases. AWS occasionally renames or consolidates managed rules, so if a rule name in your account doesn't match one listed here, check the rule's own description panel in the Config console — the underlying logic in this post will still apply even if the label has shifted. If you've been staring at a red compliance dashboard wondering what you broke: you probably didn't break anything, you just found a Region nobody had gotten around to switching the lights on for yet.