All posts

Leveraging Macie suppression rules to eliminate noise

May 10, 2026 · 11 min read

What is Amazon Macie?

Amazon Macie is a fully managed data security and data privacy service that uses machine learning and pattern matching to discover, monitor, and protect sensitive data stored in Amazon S3. Where GuardDuty focuses on threats to your infrastructure, Macie focuses on the data itself: what sensitive information exists in your S3 estate, where it lives, and whether it is adequately protected.

When you enable Macie, it automatically builds and maintains an inventory of your S3 general purpose buckets in the current region, evaluating each one for security and access control issues. Beyond bucket-level monitoring, Macie can inspect the contents of objects inside those buckets to detect sensitive data through two mechanisms:

Macie can detect a broad range of sensitive data types out of the box, including personally identifiable information (PII), personal health information (PHI), financial data such as credit card and bank account numbers, and credentials such as AWS secret access keys. You can also define your own custom data identifiers using regex patterns and keyword lists to catch organisation-specific data formats.

When Macie detects a potential issue, it generates a finding: a detailed report describing the affected resource, the type of sensitive data or policy violation involved, and the severity.

Example Macie Finding Types

Macie generates two distinct categories of findings: policy findings and sensitive data findings. They serve different purposes and are generated by different parts of the service.

Policy Findings

Policy findings report potential security or privacy misconfigurations on your S3 buckets. Macie generates these continuously as part of its ongoing bucket monitoring, independent of any discovery jobs.

Sensitive Data Findings

Sensitive data findings report the detection of sensitive content inside S3 objects. These are generated when Macie inspects object contents, either through automated discovery or a discovery job.

Severity Scoring

Macie scores findings on a three-tier scale: Low, Medium, and High. The score is influenced by factors including the type of sensitive data detected, the number of occurrences, and the security posture of the bucket containing the object. A SensitiveData:S3Object/Credentials finding in a publicly accessible bucket will score higher than the same finding type in a private, encrypted bucket.

What are Suppression Rules?

A suppression rule in Macie is a saved set of filter criteria that automatically archives any new finding matching those criteria. Like GuardDuty, Macie continues to generate the finding and stores it for 90 days, but it is immediately moved to the archived state and does not appear in your active findings queue.

How they work

Suppression rules are built on Macie's finding filter system. You define one or more conditions using finding attributes, and Macie evaluates every new finding against all active suppression rules at generation time. If a finding matches, it is archived immediately.

Filter conditions can be built using fields across two categories:

Field category Examples
Common fields Finding type, severity, region, account ID, resource ARN
Classification fields Sensitive data category, sensitive data type, job ID, custom identifier name

You can combine multiple conditions with AND logic to build precise rules. For example, you could suppress all SensitiveData:S3Object/Personal findings only from a specific bucket used for anonymised test data, while keeping the finding active for all other buckets.

Why use them?

In environments with large S3 estates, Macie findings accumulate quickly. Common sources of recurring noise include:

Without suppression rules, your team spends time reviewing findings they have already triaged, which erodes confidence in the signal Macie produces.

Suppressed findings are not forwarded to AWS Security Hub or Amazon EventBridge, so your downstream alerting and ticketing systems stay clean.

Important consideration

Suppression rules archive findings after they are generated. If your automated sensitive data discovery or discovery jobs are generating high volumes of findings from known-good data, suppression rules reduce the noise in your queue but Macie still performs the inspection and counts the data. For data you know is safe and want Macie to ignore entirely at inspection time, allow lists are the more efficient tool.

Macie Allow Lists

An allow list in Macie defines specific text or text patterns that you want Macie to ignore when it inspects S3 objects for sensitive data. Where suppression rules operate after a finding is generated, allow lists operate before: if Macie finds text that matches an entry in an allow list, it does not report that occurrence in findings, statistics, or discovery results at all.

Macie supports two types of allow list:

Predefined Text Lists

A predefined text list contains exact strings that Macie should ignore. This is useful for known values that are not actually sensitive in your context but would otherwise match a managed data identifier: sample account numbers used in documentation, anonymised test identifiers, or internal reference codes that follow a format Macie recognises as financial data.

Each entry in the list must be an exact match. Macie performs a case-sensitive comparison against the text it finds in the object.

Regular Expression (Regex) Lists

A regex list defines a pattern that Macie should ignore across all inspected objects. This is the more flexible option and suits cases where the exempted data follows a consistent format:

You store the regex or text list as a file in S3, and Macie reads it from there when performing inspections.

Usage

After creating an allow list you attach it to one or more sensitive data discovery jobs or to your automated sensitive data discovery settings. Macie then applies the list during every inspection covered by those jobs or that discovery configuration.

Limits

The Difference Between Allow Lists and Suppression Rules

Both allow lists and suppression rules reduce noise in Macie, but they work at different points in the pipeline and have meaningfully different effects.

Allow Lists Suppression Rules
When it acts At inspection time, before a finding is created After finding generation, immediately archives it
Finding created? No — the occurrence is excluded from results entirely Yes — created and then archived, stored for 90 days
Scope Specific text or patterns within object content Any finding attribute (type, severity, bucket, account, job, etc.)
Applies to Sensitive data findings only Both policy findings and sensitive data findings
Forwarded downstream? N/A — no finding exists to forward Suppressed findings are not sent to Security Hub or EventBridge
Best used for Known-safe data patterns you never want reported Known false positives scoped by resource, finding type, or job

When to use each

Use an allow list when you have specific text or patterns that are genuinely not sensitive in your environment — test data, internal formats, or public contact details that happen to match a Macie managed identifier. Allow lists prevent Macie from ever flagging that content, which keeps your sensitive data statistics clean and avoids generating findings you will only suppress anyway.

Use a suppression rule when the finding itself is valid but irrelevant to your operations in a specific context: a known-good bucket that stores credentials as part of its design, a replication rule that intentionally sends data to an external account you own, or a policy finding type that your security posture accepts for a defined set of resources.

In practice, allow lists handle content-level exemptions and suppression rules handle context-level exemptions. Using both together gives you precise control over what Macie surfaces without losing the audit trail that archived findings provide.

Example Finding: Sensitive Credentials Detected in S3

The finding type SensitiveData:S3Object/Credentials fires when Macie detects content matching credentials patterns — such as AWS secret access keys, private keys, or authentication tokens — inside an S3 object. This is one of Macie's highest-priority finding types since exposed credentials in S3 are a common and high-impact misconfiguration.

{
  "schemaVersion": "1.0",
  "accountId": "123456789012",
  "region": "eu-west-1",
  "partition": "aws",
  "id": "b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5",
  "type": "SensitiveData:S3Object/Credentials",
  "title": "The S3 object contains AWS credentials",
  "description": "The S3 object contains text that matches detection criteria for AWS secret access keys.",
  "severity": {
    "score": 90,
    "description": "High"
  },
  "createdAt": "2026-05-10T11:22:10Z",
  "updatedAt": "2026-05-10T11:22:10Z",
  "resourcesAffected": {
    "s3Bucket": {
      "arn": "arn:aws:s3:::my-app-deployment-artifacts",
      "name": "my-app-deployment-artifacts",
      "publicAccess": {
        "effectivePermission": "NOT_PUBLIC"
      },
      "defaultServerSideEncryption": {
        "encryptionType": "AES256"
      }
    },
    "s3Object": {
      "bucketArn": "arn:aws:s3:::my-app-deployment-artifacts",
      "key": "configs/production/app-config.env",
      "size": 2048,
      "serverSideEncryption": {
        "encryptionType": "AES256"
      },
      "lastModified": "2026-05-09T08:14:00Z"
    }
  },
  "classificationDetails": {
    "jobArn": "arn:aws:macie2:eu-west-1:123456789012:classification-job/abc123def456",
    "result": {
      "status": {
        "code": "COMPLETE"
      },
      "sensitiveData": [
        {
          "category": "CREDENTIALS",
          "detections": [
            {
              "type": "AWS_CREDENTIALS",
              "count": 2,
              "occurrences": {
                "lineRanges": [
                  { "start": 14, "end": 14 },
                  { "start": 27, "end": 27 }
                ]
              }
            }
          ],
          "totalCount": 2
        }
      ],
      "sizeClassified": 2048
    }
  }
}

Key fields to note:

Summary

In this post we covered the core building blocks of Amazon Macie and how to use them to manage signal quality across your S3 data estate.

We started with an overview of what Macie is: a managed data security service that monitors S3 buckets for misconfigurations and inspects object contents for sensitive data, using both automated discovery and on-demand jobs to build a picture of where sensitive data lives in your environment.

We then looked at the two finding categories. Policy findings surface bucket-level misconfigurations such as public access or disabled encryption. Sensitive data findings report detected content inside objects, covering credentials, financial data, PII, PHI, and custom patterns you define yourself.

From there we explored suppression rules: saved filter criteria that automatically archive matching findings without deleting them. They keep your active queue clean while preserving a 90-day audit trail, and prevent suppressed findings from being forwarded to Security Hub or EventBridge.

We covered allow lists, explaining how they differ from suppression rules by operating at inspection time rather than after finding generation. Predefined text lists handle exact-match exemptions; regex lists handle pattern-based exemptions. Both prevent Macie from ever reporting the exempted content, keeping your sensitive data statistics accurate.

We then compared allow lists against suppression rules directly, highlighting that allow lists handle content-level exemptions while suppression rules handle context-level ones. Using both together gives you precise control without losing the audit trail.

Finally, we walked through a realistic example finding for SensitiveData:S3Object/Credentials to show what Macie's JSON output looks like in practice and which fields matter most when triaging or writing suppression logic.

Further Reading