Data Classification and Amazon Macie

Your organization has 3,200 S3 buckets. Someone in compliance asks a reasonable question: which of them hold customer personal data? The honest answer, in most accounts, is that nobody knows.

That gap is not just an audit problem. Every control you might apply has a cost. Encrypting with a customer managed key, enabling object-level CloudTrail data events, restricting cross-account sharing, pinning data to approved Regions: apply all of it everywhere and the bill and the friction become unbearable. Apply none of it and one bucket eventually ends the company's week.

Data classification is how you escape that trap. Exam skill 4.2.1 asks you to implement and enforce a classification scheme, and those are 2 different jobs. Implementing it is defining tiers and labeling data. Enforcing it means the label actually changes what AWS permits.

A tier is a set of handling rules, not a sticker

A classification scheme is a small number of levels, each bound to a baseline of controls. A common shape looks like this:

The tier names matter less than the second column and the third. A label with no handling rules attached to it is decoration. A handling rule with no label to attach to has nothing to apply to.

Here is where teams predictably go wrong. It is tempting to classify everything at the highest tier on the theory that too much protection is never harmful. AWS states the opposite plainly: over-classification incurs unwarranted expense through costly controls, disrupts business operations, and diverts attention away from the datasets that genuinely need it. Standards bodies including ISO and NIST recommend tiered schemes for exactly this reason and advise against practices that treat all data equally. If your scheme puts 90% of the estate in the top tier, the scheme has failed even though every dataset is "protected".

The 5 steps, and where AWS services attach

AWS describes classification as a repeatable process rather than a one-time project. Each step has a service that carries it:

1. Establish a data catalog. Inventory the data types you hold, how they are used, and which are governed by a regulation. AWS Glue Data Catalog stores and shares that metadata with schema change tracking.
2. Assess business criticality and impact. For each data type, what happens to the business if it is disclosed, altered, or lost? This is the step that decides the tier, and it is not a technical step.
3. Label the information. Attach the tier to the actual resources. On AWS this is tagging, and it is covered next.
4. Handle assets according to the tier. The controls in that third column become real policies, keys, and settings.
5. Monitor continuously. Verify that labels still match reality and that handling is still applied. This is where Macie and AWS Config live.

Step 3 and step 5 are the pair that most schemes get wrong. Labeling is a declaration made by whoever created the resource. Monitoring is verification of that declaration against the bytes actually stored. A scheme with labeling and no verification is a scheme built on hope.

Tags are the handle the scheme grabs

On AWS the practical label is a tag, and a single tag key used consistently is worth more than an elaborate taxonomy nobody applies. Something like DataClassification with values public, internal, confidential, and restricted.

The reason to standardize on one key is that the tag becomes a policy condition. A bucket policy can require a matching principal tag:

{
  "Sid": "RestrictedDataNeedsMatchingClearance",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-data-lake/*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalTag/DataClearance": "restricted"
    }
  }
}

The same idea works on a KMS key policy, so the confidential-tier key can only be used by principals carrying the matching clearance tag. That is attribute-based access control applied to a classification scheme, and it is the difference between a label and a control.

Two mechanisms keep the tags honest:

• Prevention. An SCP with an aws:RequestTag condition can deny resource creation when the classification tag is missing, for the services that support tagging at creation time. This stops untagged resources from appearing.
• Detection. The AWS Config managed rule required-tags flags resources missing the tag, and it can carry an automatic remediation action. This catches everything prevention missed.

Neither of them can tell you whether the tag is correct. A bucket tagged internal that quietly accumulates passport numbers passes both checks. That specific blind spot is what Macie exists to close.

Macie starts with an inventory, not a scan

Enable Amazon Macie in an account and the first thing it does is generate and maintain an inventory of your S3 general purpose buckets, then evaluate and monitor them for security and access control. No object contents are read yet. This stage is metadata: public access settings, encryption settings, sharing, replication, object counts, and how much of the bucket Macie could analyze if asked.

When a bucket's settings change in a way that reduces its security or privacy, Macie writes a policy finding:

One property of policy findings catches people out constantly, so name it before it bites you: Macie generates a policy finding only if the change occurs after you enable Macie for the account. A bucket whose block public access settings were already disabled when you turned Macie on, and which stayed that way, produces no finding at all. Macie is watching for changes, not auditing a baseline. To see the pre-existing state you read the bucket inventory and its public access breakdown, which is why the inventory is a first-class feature and not a side effect.

Policy findings are stored for 90 days. If a policy finding recurs, Macie updates the existing finding and increments the occurrence count rather than creating a new one.

Two ways to look inside the objects

Reading object contents is a separate, billed activity, and Macie gives you 2 methods with genuinely different jobs.

Automated sensitive data discovery is the breadth option. Macie continually evaluates your bucket inventory, uses sampling to pick representative objects, and analyzes them, one cycle per day. By default it covers every S3 general purpose bucket, and for a Macie administrator that includes buckets owned by member accounts. You narrow it by excluding buckets, which is worth doing for buckets that hold nothing but logs. By default it uses the set of managed data identifiers AWS recommends for automated discovery, and you can swap in specific managed identifiers, your own custom identifiers, or both. The output is sensitive data findings, sensitivity scores per bucket, and an interactive heat map of the estate.

Sensitive data discovery jobs are the depth option. You define the buckets, the sampling depth, and criteria drawn from object properties, then run the job once for an on-demand assessment or on a recurring schedule.

The cost boundary is worth memorizing because it shapes the answer to scenario questions. When you first enable Macie, the account is enrolled in a 30-day free trial covering bucket evaluation and, depending on account settings, automated sensitive data discovery. Discovery jobs are not included in the free trial. If a question mentions a team that enabled Macie, saw no charges, then got a surprise bill, a discovery job is the usual culprit.

What Macie looks for, and what it ignores

Three components decide the detection surface:

• Managed data identifiers are AWS's built-in criteria, using machine learning and pattern matching. They cover a large and growing list of sensitive data types across many countries and regions: multiple kinds of PII, financial information, and credentials data.
• Custom data identifiers are yours. A regular expression that defines a text pattern, optionally refined with character sequences and a proximity rule. This is how you detect proprietary identifiers, internal codenames, or an in-house account number format.
• Allow lists define text and text patterns Macie should ignore. The canonical use is your own organization's public phone numbers and named representatives, or test fixture data that trips PII detectors every single run.

Allow lists are the tuning knob people forget exists. If a finding type fires repeatedly on data that is deliberately public, the fix is an allow list, not suppression rules layered on top of a noisy detector.

When Macie does find something, it writes a sensitive data finding naming the category:

Unlike policy findings, every sensitive data finding is treated as new and unique, even for the same object across runs. They are also stored for 90 days, which is a retention ceiling you should plan around: if the evidence needs to outlive 90 days, export it through EventBridge or Security Hub CSPM into storage you control.

Macie across an organization

Macie integrates with AWS Organizations, and the rules are specific enough to be exam material.

The Organizations management account designates a delegated Macie administrator, and only the management account can make, change, or remove that designation. An organization has exactly one Macie administrator, and an account cannot be an administrator and a member at the same time.

Then the property that trips up multi-Region setups: Macie is a Regional service, but AWS Organizations is global. The administrator designation is per Region. If the management account designates an administrator in us-east-1, that administrator can manage member accounts only in us-east-1. Covering 4 Regions means signing in to each one and designating the administrator 4 times. The designated account must be the same in every Region, but the designation itself is repeated.

Three more rules worth carrying:

• A Macie administrator can be associated with no more than 10,000 member accounts in each Region.
• The administrator cannot enable Macie for the Organizations management account. If you want the management account as a member, a user in that account has to enable Macie there first.
• A member account cannot disassociate itself. Only the administrator can remove it, and removal leaves Macie enabled in the account as a standalone account rather than turning it off.

Closing the loop from finding to control

A finding that nobody acts on is a slower version of not looking. Macie publishes findings to Amazon EventBridge as events, which routes them to targets such as Lambda functions and SNS topics for near real time processing. You can also configure Macie to publish findings to AWS Security Hub CSPM, which aggregates them alongside findings from GuardDuty, Inspector, and the rest, and supports cross-Region aggregation into a single Region.

The enforcement pattern that satisfies skill 4.2.1 looks like this end to end:

1. Macie's automated discovery finds SensitiveData:S3Object/Financial in a bucket tagged DataClassification=internal.
2. The finding lands on EventBridge, matched by a rule filtering on the finding type and severity.
3. A Lambda target re-tags the bucket to confidential and opens a ticket naming the owner from the bucket's owner tag.
4. Because the bucket policy and KMS key policy are already keyed to DataClassification, the tier's handling rules take effect the moment the tag changes.

Step 4 is the whole point. If the tag is not wired to anything, the automation just renamed a problem.

Exam tips

• Skill 4.2.1 says implement and enforce. An answer that only detects and reports is incomplete when another option connects the label to a permission.
• Over-classification is a wrong answer, not a cautious one. Watch for options proposing the strictest control for all data.
• Macie analyzes Amazon S3 general purpose buckets. If a question involves RDS, EBS, or DynamoDB content, Macie is not the answer.
• Policy findings only fire for changes made after Macie is enabled. Pre-existing weaknesses show in the bucket inventory, not as findings.
• Automated sensitive data discovery = broad, continuous, sampled, all buckets by default, included in the 30-day free trial. Discovery job = targeted, on demand or scheduled, depth you configure, not in the free trial.
• Custom data identifier = a regex for something AWS does not know about. Allow list = text to ignore. They point in opposite directions.
• Both finding categories are stored for 90 days. Policy findings update in place on recurrence; sensitive data findings are always new.
• Macie is Regional. Delegated administrator designation, member associations, and the 10,000 member quota are all per Region, and only the Organizations management account can designate the administrator.
• Findings reach automation through EventBridge, and reach a consolidated posture view through Security Hub CSPM.

The one thing to carry forward: classification is what makes every later control in this topic affordable. Encryption, key policies, certificate scope, and secret rotation all get cheaper and sharper when they apply to the right subset instead of to everything. The next lesson takes the confidential tier's handling rule literally and builds it with KMS.