Amazon S3 buckets accumulate sensitive data fast, and most security teams find out where PII, credentials, and financial records are actually sitting only after an audit, a breach, or a compliance deadline forces the question. Amazon Macie exists to answer it proactively. It is AWS’s managed service for discovering, classifying, and monitoring sensitive data across S3, and by September 2026 it has become one of the fastest ways to close the gap between “we think our data is encrypted and access-controlled” and “we can prove it.” This tutorial walks through enabling Macie from a cold AWS account, tuning it so it doesn’t drown you in noise, wiring its findings into an automated response pipeline, and scaling it across an AWS Organization. Budget about 90 minutes for the full walkthrough, plus the 30-day free trial window AWS gives every account for bucket-level monitoring.
The problem Macie solves is what security teams sometimes call “shadow data”: copies, exports, backups, and log dumps that sprawl across dozens or hundreds of S3 buckets long after anyone remembers they exist. A customer support tool that exports a nightly CSV of ticket data. A data science notebook that pulled a training sample and left it in a public-facing bucket. A migration script that copied a production database snapshot into a bucket nobody ever cleaned up. None of these show up in an architecture diagram, and none of them get caught by access reviews focused on which IAM roles exist rather than what the data underneath actually contains. Macie is built to find that gap by reading the content itself, not just the metadata around it.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why This Matters More in 2026
Two forces are pushing sensitive-data discovery from a nice-to-have into something audit and legal teams actively demand. The first is the ongoing expansion of US state-level privacy laws layered on top of GDPR and PCI DSS 4.0’s stricter data-mapping expectations — you cannot apply the right retention policy, encryption standard, or access control to data you don’t know you have. Regulators increasingly ask not just “do you encrypt sensitive data” but “how do you know where all your sensitive data is,” and a manual spreadsheet answer no longer satisfies that question at cloud scale. The second force is the sheer growth of unstructured data volume in S3 itself, driven by AI and analytics workloads that constantly generate new exports, training samples, and intermediate datasets. Every new S3 bucket created by a data pipeline is a new place PII can end up without anyone deciding to put it there.
This is also why AWS has been investing in automated, continuous discovery rather than leaving Macie as a purely manual, job-driven tool. A security team running quarterly manual scans is always working from stale information; a team running automated discovery is working from a rolling, continuously updated picture. That shift — from point-in-time audits to continuous monitoring — is the same pattern that has already played out in vulnerability management and cloud security posture management, and Macie is AWS’s answer to the same problem applied specifically to data content rather than infrastructure configuration.
What Amazon Macie Actually Does
Amazon Macie is a security service that combines machine learning with pattern matching to find, classify, and continuously monitor sensitive data stored in S3. According to AWS’s official product page, Macie is built specifically for sensitive data discovery and protection in S3, and it operates in two layers. The first layer is bucket-level inventory and monitoring: Macie evaluates every S3 bucket in an account for security and access-control risk, flagging things like public access, missing encryption, or buckets shared outside the account. The second layer is object-level content inspection, where Macie actually reads inside objects (documents, spreadsheets, logs, exports) to find sensitive content using built-in managed data identifiers and any custom identifiers you define.
Macie ships with managed data identifiers that already understand common formats: US Social Security numbers, credit card numbers, passport numbers, AWS access keys, and, as of a March 2025 update documented in the Macie user guide, region-specific identifiers covering Argentina, Chile, Colombia, and Mexico, including Argentina’s SUBE transit card numbers and taxpayer ID formats across those countries. That regional expansion matters if you’re running S3 workloads for customers outside the US, since a US-only PII detector misses most of what regulators in Latin America and the EU actually care about.
Managed vs. Custom Data Identifiers
Managed data identifiers are AWS-maintained detectors for common sensitive data types and are what most teams start with. Custom data identifiers are regular-expression-based detectors you write yourself for internal formats Macie has no way of knowing about: employee ID numbers, internal account references, proprietary contract IDs, or anything specific to your business. A mature Macie deployment almost always ends up running both side by side, since managed identifiers cover the regulatory basics (PCI, PII) while custom identifiers cover the data types that would otherwise never get flagged.
How the Machine Learning Layer Reduces Noise
Pattern matching alone (a plain regex for a 16-digit number) produces enormous numbers of false positives, since plenty of 16-digit sequences in log files and invoices are not credit card numbers at all. Macie’s managed identifiers combine the regex layer with contextual machine learning that looks at surrounding text, document structure, and known formatting conventions to decide whether a match is plausible before surfacing it as a finding. This is also why custom data identifiers benefit from keyword and proximity settings rather than a bare regex: you’re recreating, in a simplified form, the same context-aware filtering that the managed identifiers already do automatically. Understanding this distinction up front saves a lot of trial and error later — a custom identifier that behaves like a “dumb” regex will always generate more noise than the managed identifiers sitting next to it in the same findings feed.
Prerequisites
Before starting, confirm you have the following in place. Macie is a regional, account-level service, so everything below applies per AWS account and per region you plan to monitor.
- An AWS account with billing enabled (Macie’s 30-day trial still requires a valid payment method on file)
- AWS CLI v2, latest version (run
aws --versionand update viaaws configureif you’re on an older v1 build) - IAM permissions to create roles, policies, and enable service-linked services (effectively administrator access, or a scoped policy covering
macie2:*,iam:CreateServiceLinkedRole, and S3 read permissions) - Python 3.10 or newer with boto3 installed at the latest version (
pip install --upgrade boto3) if you plan to follow the automation examples - At least one populated S3 bucket to test against — an empty bucket won’t produce meaningful findings
- If you plan to follow the multi-account section, an AWS Organizations setup with at least one member account
- Roughly 90 minutes: bucket inventory completes in minutes, but automated sensitive data discovery sampling can take longer depending on bucket size
One AWS-specific catch worth flagging up front: Macie’s dimensions are billed separately, and none of the automation in this tutorial matters if you don’t understand the cost model first. That’s the next section.
Understanding Macie Pricing Before You Enable It
Macie’s pricing is usage-based and broken into three separate billing dimensions, all pay-as-you-go and prorated daily. Every new AWS account gets a 30-day free trial that covers S3 bucket inventory and monitoring, which is the dimension most people assume is the expensive one. It isn’t — the dimension that actually drives cost on large accounts is the per-GB data inspection fee, because that’s the one that scales with how much content Macie actually reads.
| Billing Dimension | What It Covers | Typical 2026 Rate | Free Allowance |
|---|---|---|---|
| S3 bucket inventory and monitoring | Continuous evaluation of bucket security posture (public access, encryption, sharing) | ~$0.10 per bucket per month | First 30 days free per account |
| Automated sensitive data discovery (object monitoring) | Sampling S3 objects on an ongoing basis to flag new sensitive data | ~$0.01 per 100,000 objects per month (region-dependent) | None beyond the data-inspection free tier below |
| Data inspected (automated + targeted jobs) | Actual content scanned per GB, uncompressed, for both continuous sampling and one-time classification jobs | ~$1.00 per GB inspected (region-dependent) | First 1 GB per month free, ongoing |
These figures come from AWS’s published Macie pricing page and independent 2026 cost breakdowns, but region and account-level pricing can shift, so check the live pricing calculator for your region before running a job against a multi-terabyte bucket. The account-level cap for the bucket-monitoring dimension is 10,000 buckets; past that, additional buckets aren’t billed under this dimension by default. For a typical mid-size account (50 buckets, a few million objects, 200 GB scanned per month), expect a bill in the low hundreds of dollars — the actual number depends entirely on how aggressively you scope discovery jobs, which is exactly what Step 6 covers.
Walking through the math makes the cost model concrete. Fifty buckets at $0.10 per bucket per month is $5. Three million objects under automated monitoring at roughly $0.01 per 100,000 objects per month is around $0.30. The 200 GB of data inspection, after the 1 GB free allowance, comes to roughly $199 at the $1-per-GB rate. Bucket and object monitoring are almost a rounding error; data inspection is where the real budget conversation happens, and it’s also the dimension you control most directly through sampling percentage and how broadly you scope automated discovery. This is why the console’s pre-job cost estimate, added in early 2026, is worth checking every time before running a job against a bucket you haven’t scanned before — it turns a budget surprise into a number you can approve or reject up front.
Step 1: Enable Amazon Macie and Start the Free Trial
Macie is off by default in every AWS account. Enabling it is a single API call, but it’s the call that starts your 30-day trial clock, so do it in the account and region where you actually intend to run production monitoring rather than a random sandbox.
aws macie2 enable-macie \
--finding-publishing-frequency FIFTEEN_MINUTES \
--status ENABLED \
--region us-east-1The --finding-publishing-frequency flag controls how often Macie pushes findings to EventBridge and Security Hub. FIFTEEN_MINUTES is the most frequent option and is worth using if you’re building the automated response pipeline in Step 8; the other choices are ONE_HOUR and SIX_HOURS, useful if you want to batch alerts instead of reacting in near real time. You can confirm the service is active with:
aws macie2 get-macie-session --region us-east-1A successful response returns a JSON object with "status": "ENABLED" and a createdAt timestamp. If you get an AccessDeniedException here, jump to Step 2 — your IAM identity almost certainly needs the macie2 permissions added before Macie will let you do anything else.
Step 2: Set Up IAM Permissions for Macie
Macie needs a service-linked role to read S3 bucket metadata and object content on your behalf, which AWS creates automatically the first time you enable the service. What you need to configure manually is the IAM policy for the humans and automation that will operate Macie day to day. Resist the temptation to hand out full macie2:* to everyone — split read access (for analysts reviewing findings) from write access (for whoever configures jobs and identifiers).
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MacieAnalystReadOnly",
"Effect": "Allow",
"Action": [
"macie2:GetFindings",
"macie2:ListFindings",
"macie2:GetFindingsFilter",
"macie2:ListFindingsFilters",
"macie2:GetUsageStatistics",
"macie2:DescribeBuckets",
"macie2:GetMacieSession"
],
"Resource": "*"
},
{
"Sid": "MacieOperatorWrite",
"Effect": "Allow",
"Action": [
"macie2:CreateClassificationJob",
"macie2:CreateCustomDataIdentifier",
"macie2:CreateFindingsFilter",
"macie2:UpdateClassificationJob",
"macie2:PutClassificationExportConfiguration"
],
"Resource": "*",
"Condition": {
"StringEquals": { "aws:PrincipalTag/team": "security-eng" }
}
}
]
}The condition block restricts write actions to principals tagged as belonging to the security engineering team — swap the tag key and value for whatever your organization already uses to gate least-privilege access. Attach the read-only statement broadly (security analysts, incident responders, auditors) and keep the write statement tight, since a misconfigured classification job can trigger a large, unexpected data-inspection bill.
Step 3: Let Macie Complete Automated Bucket Inventory
Once enabled, Macie immediately begins evaluating every S3 bucket in the account for security posture: public accessibility, encryption status (SSE-S3, SSE-KMS, or none), bucket policies, ACLs, and whether the bucket is shared with external accounts. This inventory pass usually completes within a few minutes for accounts with a few dozen buckets, longer for accounts with hundreds. Check progress with:
aws macie2 describe-buckets \
--criteria '{"bucketName":{"eq":["my-app-uploads"]}}' \
--region us-east-1The response includes a publicAccess block, an encryption block showing the encryption algorithm in use, and a sensitivityScore field that Macie populates once at least one classification job has run against that bucket. Before any discovery job runs, that score stays at zero — bucket inventory only tells you about exposure risk, not content. Review this list first and fix any bucket flagged with public read/write access before moving on to content scanning; there’s little point spending money finding PII in a bucket that’s also publicly readable, since the access-control fix is both more urgent and free.
Step 4: Turn On Automated Sensitive Data Discovery
Automated sensitive data discovery is Macie’s always-on mode: instead of you manually scheduling scans, Macie continuously samples a subset of objects across your S3 estate and flags new sensitive data as it appears. AWS’s 2026 product messaging positions this as the core Macie capability, since most teams don’t reliably remember to run manual jobs after the initial rollout.
aws macie2 update-automated-discovery-configuration \
--status ENABLED \
--region us-east-1
aws macie2 update-resource-profile \
--resource-arn arn:aws:s3:::my-app-uploads \
--sensitivity-score-override 80 \
--region us-east-1The second command lets you manually pin a sensitivity score for a bucket you already know is high-risk (for example, a bucket holding customer export files), which is useful for prioritizing dashboards and alert routing before Macie has built up enough sampling history to score it on its own. As of early 2026, Macie also pulls live pricing data from AWS Billing and Cost Management when you configure discovery jobs, so the console now shows an estimated cost before you commit to scanning a bucket — check that number before running discovery against anything in the multi-terabyte range.
Step 5: Build Custom Data Identifiers for Your Own Data
Managed identifiers won’t catch internal formats like employee badge numbers, order reference codes, or proprietary API keys. Custom data identifiers close that gap with regex patterns plus optional keyword and proximity rules to cut false positives.
aws macie2 create-custom-data-identifier \
--name "internal-employee-id" \
--regex "EMP-[0-9]{6}" \
--keywords "employee,badge,staff" \
--maximum-match-distance 50 \
--description "Matches internal employee ID format EMP-123456" \
--region us-east-1--maximum-match-distance tells Macie how close a keyword like “employee” needs to appear to the regex match before it counts as a hit — set this too high and you’ll flag every document that happens to contain both the word “employee” and a six-digit number anywhere in the file, which is exactly the kind of noise that gets Macie findings ignored. Start narrow (30–50 characters) and widen only if you’re missing real matches. Custom identifiers run alongside managed identifiers in both automated discovery and targeted jobs — you don’t need to choose one or the other.
Step 6: Run a Targeted Classification Job via CLI
Automated discovery samples continuously but doesn’t guarantee full coverage of every object. When you need a complete, one-time sweep of a specific bucket — before a compliance audit, after a data migration, or ahead of decommissioning a bucket — use a targeted classification job instead.
aws macie2 create-classification-job \
--job-type ONE_TIME \
--name "pre-audit-full-scan-2026-09" \
--s3-job-definition '{
"bucketDefinitions": [
{
"accountId": "111122223333",
"buckets": ["my-app-uploads", "my-customer-exports"]
}
]
}' \
--custom-data-identifier-ids '["cdi-0a1b2c3d4e5f"]' \
--sampling-percentage 100 \
--region us-east-1Setting --sampling-percentage below 100 scans a random subset of objects instead of everything, which is a legitimate way to estimate exposure on a huge bucket without paying to inspect every byte — useful for a first-pass risk estimate before deciding whether a full scan is worth the cost. Track job status with aws macie2 describe-classification-job --job-id <job-id>; large jobs against buckets with millions of objects can run for hours, so this isn’t something to fire off five minutes before a meeting.
Step 7: Review and Triage Findings
Macie produces two categories of findings: policy findings (bucket-level risk, like public access or missing encryption) and sensitive data findings (content-level matches from managed or custom identifiers). Pull the current list with:
aws macie2 list-findings \
--finding-criteria '{
"criterion": {
"severity.description": { "eq": ["High"] }
}
}' \
--region us-east-1A typical high-severity finding, retrieved with get-findings, looks like this in the console and API response:
{
"type": "SensitiveData:S3Object/Financial",
"severity": { "description": "High", "score": 8 },
"resourcesAffected": {
"s3Bucket": { "name": "my-customer-exports" },
"s3Object": { "key": "exports/2026-09-01/batch-report.csv" }
},
"classificationDetails": {
"result": {
"sensitiveData": [
{
"category": "FINANCIAL_INFORMATION",
"totalCount": 342,
"detections": [
{ "type": "CREDIT_CARD_NUMBER", "count": 342 }
]
}
]
}
}
}Triage priority should follow severity first, then whether the affected bucket also has a public-access policy finding attached — a high-severity content match in a publicly readable bucket is the finding that gets escalated immediately, not queued for next week’s review. Everything else here is largely manual until you wire it into automation, which is the next two steps.
Step 8: Route Findings to EventBridge for Real-Time Response
Macie publishes both policy and sensitive-data findings to Amazon EventBridge by default whenever a new finding is created, so you don’t need to poll the API. Create a rule that matches high-severity sensitive-data findings and routes them to a Lambda function for automated first response.
aws events put-rule \
--name "macie-high-severity-findings" \
--event-pattern '{
"source": ["aws.macie"],
"detail-type": ["Macie Finding"],
"detail": { "severity": { "description": ["High"] } }
}' \
--region us-east-1
aws events put-targets \
--rule "macie-high-severity-findings" \
--targets '[{
"Id": "quarantine-lambda",
"Arn": "arn:aws:lambda:us-east-1:111122223333:function:macie-auto-quarantine"
}]' \
--region us-east-1On the Lambda side, a minimal auto-response function tags the affected object and notifies your security channel rather than taking a destructive action automatically — auto-deleting or auto-encrypting objects based on a single finding is a good way to break a production pipeline the first time Macie has a false positive.
import boto3
import json
s3 = boto3.client("s3")
sns = boto3.client("sns")
def handler(event, context):
detail = event["detail"]
bucket = detail["resourcesAffected"]["s3Bucket"]["name"]
key = detail["resourcesAffected"]["s3Object"]["key"]
s3.put_object_tagging(
Bucket=bucket,
Key=key,
Tagging={"TagSet": [{"Key": "macie-review", "Value": "pending"}]}
)
sns.publish(
TopicArn="arn:aws:sns:us-east-1:111122223333:security-alerts",
Subject=f"Macie high-severity finding: {bucket}/{key}",
Message=json.dumps(detail, indent=2)
)
return {"statusCode": 200}This gives you a tagged object plus an alert within the 15-minute publishing window set in Step 1, which is fast enough to catch an exposed credential dump before it gets indexed by anything scanning public buckets.
Step 9: Forward Findings to AWS Security Hub
If your security team already correlates alerts in AWS Security Hub, enable Macie’s Security Hub integration so findings land in the same dashboard as your other CSPM signals instead of living in a separate console. Security Hub itself has to be enabled in the account first, or Macie’s publish attempt will simply fail silently.
aws securityhub enable-security-hub --region us-east-1
aws macie2 put-findings-publication-configuration \
--security-hub-configuration '{"publishClassificationFindings": true, "publishPolicyFindings": true}' \
--region us-east-1Once both are configured, Macie findings show up as Security Hub findings using the standard AWS Security Finding Format, which means they can flow into the same suppression rules, custom insights, and ticketing integrations you’ve already built for GuardDuty, Inspector, and Config findings. This is the step that turns Macie from a standalone tool into part of your actual detection-and-response stack rather than a dashboard nobody checks.
Step 10: Tune Suppression Rules to Cut Noise
The single fastest way to get a Macie deployment ignored by its own security team is to let it generate hundreds of low-value findings in the first week. Suppression (findings filter) rules let you archive findings that match a pattern you’ve already reviewed and accepted — a known test bucket full of synthetic credit card numbers, for instance.
aws macie2 create-findings-filter \
--name "suppress-known-test-bucket" \
--action ARCHIVE \
--finding-criteria '{
"criterion": {
"resourcesAffected.s3Bucket.name": { "eq": ["qa-synthetic-test-data"] }
}
}' \
--region us-east-1Write suppression rules narrowly, one bucket or one finding type at a time, and review them quarterly. A suppression rule that’s too broad (for example, archiving all findings of a given severity rather than a specific bucket) is how real incidents get silently dropped — treat every new suppression rule as something that needs a second reviewer before it goes live.
Step 11: Automate Macie Configuration With Infrastructure as Code
Running these CLI commands by hand doesn’t scale past one account. Define the Macie session, custom identifiers, and findings filters as code so a new AWS account gets the same baseline configuration on day one. A minimal snippet covering the core resources looks like this — pair it with your existing account-vending pipeline rather than running it manually per account.
resource "aws_macie2_account" "this" {
finding_publishing_frequency = "FIFTEEN_MINUTES"
status = "ENABLED"
}
resource "aws_macie2_custom_data_identifier" "employee_id" {
name = "internal-employee-id"
regex = "EMP-[0-9]{6}"
keywords = ["employee", "badge", "staff"]
maximum_match_distance = 50
depends_on = [aws_macie2_account.this]
}
resource "aws_macie2_findings_filter" "suppress_qa" {
name = "suppress-known-test-bucket"
action = "ARCHIVE"
finding_criteria {
criterion {
field = "resourcesAffected.s3Bucket.name"
eq = ["qa-synthetic-test-data"]
}
}
depends_on = [aws_macie2_account.this]
}Keeping this in version control also gives you an audit trail for exactly when a suppression rule or custom identifier changed, which matters the first time a compliance auditor asks why a specific bucket stopped generating findings six months ago.
Step 12: Scale Across an AWS Organization
Single-account Macie is fine for a small team, but most real deployments span dozens of member accounts under AWS Organizations. Designate one account as the Macie administrator, then invite member accounts so findings roll up to a single pane instead of forty separate consoles.
aws macie2 enable-organization-admin-account \
--admin-account-id 111122223333 \
--region us-east-1
# From the delegated administrator account:
aws macie2 update-organization-configuration \
--auto-enable true \
--region us-east-1--auto-enable true means every new account added to the organization gets Macie turned on automatically, which is the setting you want if security is trying to guarantee coverage rather than rely on individual account owners to remember. The delegated administrator account can then apply organization-wide custom data identifiers and findings filters so every member account inherits the same baseline without a separate rollout per team.
Complete Working Project: Automated PII Alert Pipeline
Putting the pieces from Steps 1, 4, 8, and 9 together gives you a working pipeline: S3 buckets are continuously sampled by automated discovery, high-severity sensitive-data findings publish to EventBridge within 15 minutes, a Lambda function tags the object and posts to a security SNS topic, and everything also lands in Security Hub for correlation with GuardDuty and Inspector findings. The full sequence, assembled as a deployable set of resources, is:
- Enable Macie with 15-minute finding publishing (Step 1)
- Attach the split read/write IAM policy to your security team’s role (Step 2)
- Enable automated sensitive data discovery account-wide (Step 4)
- Deploy the custom data identifier for internal formats (Step 5)
- Create the EventBridge rule targeting high-severity findings (Step 8)
- Deploy the quarantine-tag-and-notify Lambda function with an SNS topic subscribed by your security channel (Step 8)
- Enable the Security Hub publishing configuration so findings correlate with other detections (Step 9)
- Add a findings filter suppressing any known-safe test buckets before going live (Step 10)
Deploy this as a single infrastructure-as-code module (extending the snippet from Step 11 with the Lambda function, EventBridge rule, and SNS topic as additional resources) and you have a repeatable baseline that any new AWS account can inherit through your account-vending machine. Test it end to end by uploading a file containing a synthetic, clearly fake credit card number to a monitored bucket and confirming the SNS notification arrives within the 15-minute window — never test with real customer data, even in a sandbox account.
Common Pitfalls
- Running a full-sampling job against a multi-terabyte bucket without checking the cost estimate first. At roughly $1 per GB inspected, a careless 5 TB scan can produce a bill in the thousands. Always check the console’s cost estimate (available since early 2026) or scope with
--sampling-percentagebefore running a 100% scan. - Treating automated discovery as a substitute for targeted jobs before an audit. Automated discovery samples continuously but doesn’t guarantee every object gets inspected. If you need documented, complete coverage of a specific bucket for a compliance attestation, run a targeted job with 100% sampling and keep the job ID as evidence.
- Writing custom data identifiers with no keyword or proximity constraint. A bare regex like six consecutive digits will match phone numbers, order IDs, and dates, burying real findings under noise. Always pair a regex with keywords and a sensible
maximum-match-distance. - Granting broad
macie2:*permissions instead of splitting read and write access. Anyone who can create classification jobs can also trigger significant, unbudgeted charges. Scope write access to a small, tagged group as shown in Step 2. - Forgetting that Security Hub must be enabled separately before Macie can publish to it. If findings aren’t showing up in Security Hub after configuring the publication setting, the first thing to check is whether Security Hub itself is actually turned on in that account and region.
- Writing suppression rules broad enough to hide real incidents. A filter suppressing “all medium-severity findings” rather than one specific known-safe bucket will quietly eat legitimate alerts. Scope suppression rules to the narrowest possible match.
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
AccessDeniedException on enable-macie | IAM identity lacks macie2:EnableMacie or iam:CreateServiceLinkedRole | Attach the operator policy from Step 2 or use an admin role for initial setup |
| Bucket never shows a sensitivity score | No classification job has run against it yet | Enable automated discovery (Step 4) or run a targeted job (Step 6) against that specific bucket |
Classification job stuck in RUNNING for hours | Large object count or bucket in a different region than the job | Check describe-classification-job for progress percentage; large buckets can legitimately take hours |
| Custom data identifier matches everything | Regex too permissive, no keyword constraint | Add keywords and reduce maximum-match-distance, then re-test against a small sample bucket |
| Findings not appearing in Security Hub | Security Hub not enabled in the account/region, or publishing config not set | Run enable-security-hub, then re-apply put-findings-publication-configuration |
| EventBridge rule never triggers | Event pattern doesn’t match the actual finding schema, or rule targets a Lambda missing invoke permission | Test the pattern with aws events test-event-pattern and confirm the Lambda has a resource policy allowing EventBridge to invoke it |
| Unexpectedly high monthly Macie bill | A targeted job ran with 100% sampling against a very large bucket, or automated discovery is scanning far more objects than expected | Review get-usage-statistics by account and bucket, then scope future jobs with --sampling-percentage |
| Member accounts not enrolling in organization Macie | Delegated administrator not set, or auto-enable left false | Confirm enable-organization-admin-account ran successfully and set update-organization-configuration --auto-enable true |
| Same finding keeps re-appearing after being archived | Findings filter criteria doesn’t exactly match the recurring finding’s attributes | Re-check the exact field values in the finding JSON and tighten the filter criterion to match precisely |
Advanced Tips
Once the baseline pipeline is running, a handful of refinements separate a Macie deployment that gets trusted from one that gets muted after week two.
- Export full classification results, not just findings. Use
put-classification-export-configurationto send the complete, per-object classification results (not the summarized findings) to a dedicated S3 bucket. This gives your data governance or legal team a queryable record via Athena without needing Macie console access themselves, and it’s the dataset auditors actually want when they ask “show me everywhere this data type appears,” not just the high-severity subset that generated an alert. - Confirm regional identifiers are actually enabled. If your workloads touch regulated data in Latin America, verify the regional managed identifiers added in March 2025 are turned on for your account — not every managed identifier ships enabled by default, and it’s easy to assume coverage you don’t actually have.
- Prioritize by staleness, not just sensitivity score. Combine Macie’s sensitivity scoring with S3 Storage Lens or S3 Inventory data to prioritize which of your oldest, least-accessed buckets to scan first. Buckets nobody has touched in years are disproportionately likely to hold forgotten exports, and they’re also the ones least likely to have a current owner who’d notice or fix a problem.
- Correlate through Security Lake. If you’re running a Security Lake deployment for centralized log analytics, route Macie findings there alongside GuardDuty and Config data so an analyst can correlate a sensitive-data finding with the specific IAM activity that created the object in the first place — that correlation is usually what turns a Macie finding into an actionable incident rather than a data point that sits unexplained.
- Re-run cost estimates after any bucket growth spurt. A bucket that cost $12/month to scan when it held 40 GB can quietly become a $400/month line item after six months of unmonitored growth from a new data pipeline. Revisit the per-bucket cost breakdown from
get-usage-statisticsquarterly, not just at initial rollout.
Macie vs. Manual DLP vs. Microsoft Purview
Teams evaluating Macie usually compare it against two alternatives: building detection in-house with custom scripts, or adopting a broader data governance platform like Microsoft Purview. Neither comparison is close to apples-to-apples, but the trade-offs are worth stating plainly.
| Approach | Coverage | Maintenance Burden | Best Fit |
|---|---|---|---|
| Amazon Macie | S3 only, deep AWS-native integration with Security Hub and EventBridge | Low — managed identifiers updated by AWS, pay-as-you-go | AWS-centric organizations that need fast S3 coverage without building detection logic |
| Manual/custom DLP scripts | Whatever you build — can cover any storage, but nothing by default | High — regex patterns, false-positive tuning, and regional formats all fall on your team | Highly specific internal data types Macie’s identifiers don’t cover, run alongside Macie rather than instead of it |
| Microsoft Purview | Multi-cloud and on-prem cataloging, broader governance beyond just sensitive-data detection | Medium-high — more setup, but centralizes governance across heterogeneous sources | Multi-cloud organizations where S3 is only one of several data estates to govern |
For an AWS-centric team whose sensitive data problem is specifically “what’s sitting in our S3 buckets,” Macie’s tight integration with Security Hub and EventBridge, positioned by AWS as a managed, continually updated service with automated discovery, makes it the lower-effort starting point. Organizations already committed to Purview for governance across Azure, on-prem file shares, and SaaS apps may still want Macie as the AWS-native detection layer feeding into that broader catalog rather than choosing one exclusively.
Frequently Asked Questions
Does Macie scan anything besides S3?
No. As of September 2026, Macie’s sensitive data discovery is scoped specifically to Amazon S3. It does not scan RDS databases, DynamoDB tables, EBS volumes, or EFS file systems natively. If those data stores also hold sensitive data, you’ll need separate tooling or an export-to-S3 workflow to bring that data within Macie’s scope.
How much does a typical Macie deployment cost per month?
It depends almost entirely on how much data you scan, not how many buckets you have. Bucket monitoring runs about $0.10 per bucket per month after the 30-day trial, and object monitoring is roughly $0.01 per 100,000 objects per month, but the dominant cost is data inspection at approximately $1 per GB (with 1 GB free every month). A team scanning 200 GB monthly across 50 buckets should expect a bill in the low hundreds of dollars; always confirm current rates in the AWS pricing calculator for your region before committing to a large scan.
What happens after the 30-day free trial ends?
Bucket inventory and monitoring charges begin automatically at the standard per-bucket rate, billed daily and prorated. The trial only covers the bucket-monitoring dimension — if you ran classification jobs or enabled automated discovery during the trial, data-inspection charges (beyond the 1 GB free tier) applied from day one, not after the trial ends.
Can Macie automatically remediate findings, like removing public access?
Macie itself only detects and reports; it does not take remediation actions on your buckets or objects. Automated remediation, like the Lambda function in Step 8, is something you build yourself using EventBridge to trigger a response. AWS deliberately keeps detection and remediation separate so a false positive can’t automatically break a production workload.
Is Macie available in every AWS region?
Macie is available in most, but not all, AWS commercial regions, and AWS periodically adds coverage. In July 2025, AWS also added VPC interface endpoint support across all regions where Macie is available, letting you reach the Macie API privately without traversing the public internet. Check the current regional availability table in the AWS console before assuming coverage in a newer region.
Does Macie replace the need for encryption and IAM access controls?
No. Macie is a detection and visibility tool, not a preventive control. It tells you where sensitive data lives and where bucket configurations are risky, but the actual protections — bucket policies, KMS encryption, IAM least privilege, block public access settings — still have to be implemented and maintained separately. Think of Macie as the tool that tells you where those controls are missing, not the tool that applies them.
How does Macie compare to enabling GuardDuty and Inspector as well?
They cover different layers and are meant to run together, not as alternatives. GuardDuty watches for threat activity (unusual API calls, compromised credentials, malicious network traffic), Inspector scans compute resources for known vulnerabilities, and Macie focuses specifically on sensitive-data content in S3. All three publish to Security Hub, so a well-configured account runs all three side by side and correlates findings there rather than treating them as competing tools.
What compliance frameworks does Macie help support?
Macie’s automated discovery of PII, financial data, and credentials in S3 supports the data-mapping and risk-assessment requirements common to frameworks like GDPR and PCI DSS, since both require organizations to know where regulated data actually resides before they can apply appropriate controls. Macie itself is not a certification or a compliance guarantee — it’s evidence-gathering infrastructure that a compliance program can build on top of, alongside separate controls for encryption, retention, and access management.
Should a small team bother with Macie, or is it overkill?
Even a small team with a handful of S3 buckets benefits from at least enabling bucket-level monitoring during the 30-day free trial, since that alone surfaces public-access and encryption risks at zero cost. Whether to go further and enable ongoing automated discovery is a cost-versus-risk decision: a team storing only application logs with no customer PII has less to gain than a team storing customer uploads, support exports, or payment-adjacent data. Start with the free trial, review what bucket-level findings alone surface, and decide on content scanning from there rather than assuming it’s unnecessary.
Can I test Macie safely without risking real customer data?
Yes, and you should. Create a dedicated test bucket, populate it with clearly synthetic data (fake names, obviously invalid credit card numbers like repeating test sequences, placeholder SSNs), and run your first classification jobs and custom identifiers against that bucket before pointing anything at production. This also gives you a safe target for the suppression-rule pattern shown in Step 10, since you’ll want a permanent findings filter for that test bucket once you move to production monitoring.
Related Coverage
- How to Set Up Argo Rollouts: 12 Steps, 90 Min [2026]
- PlayFab Multiplayer Servers Setup: 12 Steps, 90 Min [2026]
- Sunshine and Moonlight on AWS G7: 12 Steps, 90 Min [2026]
- Migrate to AWS Graviton5: 12 Steps, 90 Min [2026]
- Deploy Agones on Kubernetes: 12 Steps, 90 Min [2026]
