Business Challenge
#43 listed Macie among the services that land in the security account. This is what its primary output actually asserts.
The honest version is in the definition: “a sensitivity score is a quantitative measure of the intersection of two primary dimensions: the amount of sensitive data that Macie has found in a bucket, and the amount of data that Macie has analyzed in a bucket.”
Two dimensions, one number. Which means a given score does not distinguish "we looked hard and found little" from "we have barely looked".
On enablement: “Macie automatically assigns a sensitivity score of 50 and the Not yet analyzed label to each S3 bucket.” Reasonable — a neutral starting value for work not yet done.
And then, in the considerations: “If an S3 bucket's permissions settings prevent Macie from accessing or retrieving information about the bucket or the bucket's objects, Macie can't perform automated discovery for the bucket… In your bucket inventory, the sensitivity score for these buckets is 50 and their sensitivity label is Not yet analyzed.”
Same number, same label, two unrelated situations. One resolves itself in a few days as the breadth-first sweep arrives; the other does not resolve until somebody changes the bucket policy or the key policy, because nothing is going to do that on Macie's behalf. From the inventory they are the same row.
FixMacie publishes the distinction elsewhere — AWS points to coverage data to “identify S3 buckets where this is the case”. A score of 50 older than a few days is a coverage question, not a sensitivity one.
The mechanism is explicitly statistical. Macie “uses sampling techniques to select representative S3 objects to analyze”, grouping by “bucket name, prefix, storage class, file name extension, and last modified date”, then “selects a representative set of samples from each group”.
And the caveat is AWS's own, not an inference: “Any single object sample isn't guaranteed to be conclusive. Therefore, analysis of a diverse set of objects can yield better insight into the types and amount of sensitive data that an S3 bucket might contain.”
Now read how the score moves: “If Macie doesn't find sensitive data in an object, Macie decreases the bucket's sensitivity score.” So a falling score is the accumulation of clean samples. It is evidence, and it is not proof — the unsampled objects contributed nothing to it.
FixTreat automated discovery as triage that tells you where to run a full discovery job, which is what AWS describes it as: a way to “determine where to perform a deeper investigation”.
“if an object was previously analyzed and hasn't changed since that analysis, Macie doesn't analyze the object again.”
That is the right engineering decision — re-reading unchanged bytes would be pure cost — and it has a consequence for anything that changes outside the object. Add a managed data identifier, or a custom one, and the objects already analysed under the old identifier set are not revisited unless they change.
So the sensitivity picture is built from analyses performed under whatever identifier configuration was active at the time. Changing the configuration changes what future samples detect, not what past ones concluded.
FixAfter adding an identifier that matters, run a sensitive data discovery job over the buckets you care about rather than waiting for automated discovery to notice.
Architecture
A daily cycle, a breadth-first sampler, and a score that moves on what the samples found.
How objects get chosen
The grouping is metadata-based, on the assumption that similar metadata implies similar content: “The techniques define groups of objects that have similar metadata and are likely to have similar content. The groups are based on dimensions such as bucket name, prefix, storage class, file name extension, and last modified date.”
That assumption is reasonable and it is also the thing to understand about the output. A bucket where one prefix holds exports and another holds logs will be grouped accordingly; a bucket where sensitive and non-sensitive objects share a prefix, an extension and a modification window is one group, and the samples drawn from it may land entirely on either side.
The sweep is deliberately broad before it is deep: “The sampling strategy prioritizes distributed analyses. In general, it uses a breadth-first approach… a representative set of S3 objects are selected from as many of your general purpose buckets as possible… if Macie has already analyzed and found sensitive data in objects in one bucket and hasn't yet analyzed objects in another bucket, the latter bucket is a higher priority for analysis.”
So a bucket already known to hold sensitive data is deprioritised in favour of unexamined ones. For a first pass that is correct. For a bucket you already know matters, it means automated discovery is not the tool that goes deeper into it.
“Macie then selects a representative set of samples from each group, retrieves the latest version of each selected object from Amazon S3, and analyzes each selected object… When the analysis is complete, Macie discards its copy of the object.” So the artefacts are findings and discovery results, not data. That is the right privacy posture, and it means a conclusion cannot be re-derived later from what Macie kept — if you need to know why an object scored as it did, the finding is the record.
What makes the score move, in both directions
| Event | Effect on the bucket's score |
|---|---|
| Macie finds sensitive data in an object | “Macie increases the bucket's sensitivity score” |
| Macie finds none in an object | “Macie decreases the bucket's sensitivity score” |
| A sensitive object is subsequently changed | Detections for it are “removed… from the bucket's sensitivity score” |
| A sensitive object is subsequently deleted | Same — detections removed from the score |
The last two are the familiar shape from this block. #75 had a Security Hub control going green because the failing resource was deleted. Here, deleting a sensitive object removes its detections from the score — which is correct, because the data is gone, and which also means a falling score and a cleanup are indistinguishable from the number alone.
Three populations that are not analysed, and one that is scored 1
Not classifiable. “To be eligible for selection and analysis, an S3 object must be stored in a general purpose bucket and it must be classifiable. A classifiable object uses a supported Amazon S3 storage class and it has a file name extension for a supported file or storage format.” An archived storage class or an unrecognised extension takes an object out of scope.
Encrypted with a key Macie cannot use. “If an S3 object is encrypted, Macie can analyze it only if it's encrypted with a key that Macie can access and is allowed to use.” Which makes a KMS key policy a determinant of data-discovery coverage — the key policy from #5, deciding what your classifier can read.
Excluded by you. “You can exclude as many as 1,000 buckets from analyses”, with logging buckets given as the example. Sensible, and another population whose score means nothing.
And empty buckets get a real answer. “An empty bucket is a bucket that doesn't store any objects or all the bucket's objects contain zero (0) bytes of data. If this is the case for a bucket, Macie assigns a score of 1 to the bucket and it assigns the Not sensitive label.” Which is the one case where "nothing here" is genuinely conclusive — and it is scored 1 rather than 50, so Macie does distinguish a confident absence from an unexamined one when it can.
Why This Architecture Holds Up
AWS is unusually explicit that the score is not a priority ranking
“An S3 bucket's sensitivity score and label don't imply or otherwise indicate the criticality or importance that the bucket or the bucket's objects might have for you or your organization. Instead, they're intended to provide reference points that can help you identify and monitor potential security risks.”
That is a clearer disclaimer than most metrics carry, and it is worth quoting to anybody who wants to sort a remediation backlog by it. The score says something about sensitive data density in what was sampled. It says nothing about whether the bucket is a production system of record or a developer's scratch space.
The manual override exists, and tells you what the score is for
“You can also override a bucket's calculated score by manually assigning the maximum score (100) to the bucket. If you assign the maximum score, the bucket's label is Sensitive.”
An override to maximum is how you encode knowledge the sampler cannot have — that this bucket holds the customer database exports regardless of what today's sample found. The presence of that feature is the clearest signal that the computed score is an input to judgement rather than a substitute for it.
“Members have read access to sensitive data discovery statistics and other results that Macie directly provides for their S3 buckets… The exception is sensitive data findings. Only the Macie administrator has direct access to findings that automated discovery produces.”
And the configuration is central too: “Macie uses the automated discovery settings for your administrator account when it analyzes data for the member account… Members can't review or change these settings”, nor can they see per-bucket scoring settings for buckets they own. That is a defensible split — findings quote sensitive data, so narrow access is the point — and it means remediation requires the administrator to relay what was found to the team that can fix it. A workflow, not a dashboard.
The identifier configuration is a setting with retrospective blind spots
By default Macie uses “the set of managed data identifiers that we recommend for automated sensitive data discovery”, and you can add or remove managed identifiers, custom identifiers and allow lists. Changes take effect “when the next daily analysis cycle starts”.
Next cycle, not retroactively — and combined with the rule that unchanged objects are not re-analysed, adding an identifier improves detection on objects that change or have not been sampled yet. A static bucket analysed last month under the old set keeps last month's conclusion.
Allow lists deserve a note of their own, because they are a deliberate blind spot: “an allow list specifies text or a text pattern that you want Macie to ignore in S3 objects… such as public names or phone numbers for your organization, or sample data that your organization uses for testing.” Useful, and the kind of configuration that should be reviewed on a cadence rather than set once.
Per-Region, like most of this
“Your automated discovery settings apply only to the current AWS Region… To perform automated discovery and access the resulting data in additional Regions, enable and configure automated discovery in each additional Region.”
Which means an unenabled Region does not show up as unexamined buckets with a score of 50 — it does not show up at all. The absence of rows is the signal, and absent rows are the hardest thing to notice on any inventory.
Key Architecture Decisions
| Decision | Choice | Reasoning |
|---|---|---|
| Reading a score of 50 | Check coverage data before treating it as a sensitivity statement | 50 with Not yet analyzed is both the enablement default and the value for a bucket Macie cannot read. |
| Reading a low score | "Clean in what was sampled", not "clean" | A score decreases when an object is analysed and nothing is found, and a single sample “isn't guaranteed to be conclusive”. |
| Buckets you already know matter | Run a sensitive data discovery job | Breadth-first deprioritises buckets already found to contain sensitive data. |
| After adding a data identifier | Run a job over the buckets that matter | Settings apply from the next cycle, and unchanged objects are not re-analysed. |
| Buckets that matter and the sampler cannot know it | Override to 100 | The override exists precisely to encode judgement the sampling cannot reach. |
| KMS keys on data you want classified | Grant Macie use of the key | An encrypted object is analysed only with a key Macie can access and is allowed to use. |
| Excluded buckets | Keep the list short and reviewed | Up to 1,000 can be excluded, and an excluded bucket's score means nothing. |
| Allow lists | Review on a cadence | They are text Macie is told to ignore, and they do not expire. |
| Organisation remediation | Build a relay from administrator to bucket owner | Only the administrator has direct access to the findings; members see statistics. |
| Regional coverage | Enumerate Regions independently of Macie | An unenabled Region produces no rows at all, rather than unexamined ones. |
The audit worth running
List every bucket with a score of 50 and a Not yet analyzed label, and age it. Anything still at 50 well past the point where “analysis results can begin to appear within 48 hours” is probably not queued — it is probably a bucket Macie cannot read, and that is a bucket policy or a KMS key policy to fix rather than a result to interpret.
Then reconcile your bucket inventory against Macie's. Excluded buckets, non-classifiable objects, unreadable encryption and unenabled Regions are four different ways for data to be outside the picture, and only one of them appears in it.
Closing Thought
Macie is more candid about its own limits than most of the services in this block. It says the sampling may not be conclusive, it says the score is a reference point rather than a measure of criticality, and it gives you an override for the cases it cannot see. The score is doing exactly the job it claims.
The gap is between that job and the way a bucket inventory with numbers in it gets read. A column of sensitivity scores looks like a map of your sensitive data; it is a map of the sampling so far, with one value standing in for two different kinds of not-knowing.
Which closes a run of four posts on the same theme from four directions. #72 was a resource accumulating against a ceiling. #73 was a schedule quietly not running. #74 was a detection capability quietly reduced. #75 was a metric measuring something adjacent to what it is read as measuring. This one is the same metric problem with the honest version written into the documentation — which helps only if somebody reads past the column heading.
Security & Identity — Amazon Inspector: what continuous scanning actually re-evaluates, why a finding can persist after the package is patched, and how the Inspector score relates to the CVSS base score it is derived from.
Official AWS Reference
- How automated sensitive data discovery works — the sampling technique and its dimensions, the breadth-first strategy, sensitivity scoring and labels, and the eligibility and organisation considerations
- Assessing automated sensitive data discovery coverage — further reading, and where AWS directs you to distinguish an unreadable bucket from an unexamined one; no claims in this post are drawn from it
Comments