AWS Resource Tagging

After a successful masking run against an AWS target, DataMasque tags the masked resource with a standard set of protection tags. These provide a machine-readable "Protected by DataMasque" governance signal: proof that a resource holds masked data.

This page covers the tags applied, the IAM permissions required, how to preserve the tags through RDS snapshot and restore, and how to find masked resources with AWS Config.

• The protection tag set
• The tag_aws_resources global setting
• Required IAM permissions
• Preserving tags through RDS snapshot and restore
  • Do not pass explicit --tags on snapshot or restore
  • CloudFormation restore snippet
  • Terraform restore snippet
• Finding masked resources with AWS Config

The protection tag set

When tagging is enabled and DataMasque is running on AWS, a successful masking run applies the following tags to the masked resource:

Tag	Example value	Purpose
datamasque:masked	true	Customer-facing governance signal: this resource holds masked data.
datamasque:masked-date	2026-05-25T10:30:00+00:00	The ISO 8601 timestamp the masking run completed.
datamasque:run-id	42	The DataMasque run ID that produced the masked data.
aws-apn-id	pc:<product-code>	The product ID of the DataMasque product that performed the masking, used for auditing with AWS.

A discovery run (which profiles data without masking it) applies a parallel marker set instead:

Tag	Example value	Purpose
datamasque:discovered	true	Governance signal: this resource has been profiled by a DataMasque discovery run.
datamasque:discovered-date	2026-05-25T10:30:00+00:00	The ISO 8601 timestamp the discovery run completed.
datamasque:run-id	42	The DataMasque run ID that profiled the resource.

A discovery run never applies datamasque:masked or aws-apn-id, since it reads but does not mask data.

The resource tagged depends on the target type:

• RDS instances (matched by an *.rds.amazonaws.com endpoint) are tagged on the instance, and CopyTagsToSnapshot is enabled so the tags propagate to snapshots automatically.
• Redshift clusters are tagged on the cluster.
• DynamoDB tables are tagged on each masked table.
• S3 objects are tagged inline as they are written.

Tagging is best-effort. If a tagging API call fails (for example, because of a missing IAM permission), the masking run still completes successfully and a WARNING is logged with the underlying error and a remediation message. Tagging never blocks or fails a masking run.

Unlike the other resource types, which are tagged once on completion, S3 objects are tagged inline as each object is written. If a run fails partway through, objects already written carry the datamasque:masked tag even though the run did not complete, and the datamasque:masked-date value reflects the run start rather than its completion.

The tag_aws_resources global setting

Tagging is controlled by the Tag AWS resources as masked after a successful run checkbox on the global settings page. It defaults to on. The setting is only visible when DataMasque is running on AWS; on non-AWS installs no tagging UI or behaviour is present. To opt out, an administrator can clear the checkbox and save.

Required IAM permissions

Grant the DataMasque instance role the following permissions for the resource types you mask. The policy below avoids Resource: "*"; narrow the Resource ARNs further to the specific regions, accounts, tables, clusters, instances, and buckets you mask where possible.

Note that s3:PutObjectTagging is required even though S3 tags are supplied inline via the PutObject Tagging parameter, because IAM evaluates the tagging action independently of s3:PutObject.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DataMasqueDynamoDbTagging",
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeTable",
        "dynamodb:TagResource"
      ],
      "Resource": "arn:aws:dynamodb:*:<account-id>:table/*"
    },
    {
      "Sid": "DataMasqueRdsTagging",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:AddTagsToResource",
        "rds:ModifyDBInstance"
      ],
      "Resource": "arn:aws:rds:*:<account-id>:db:*"
    },
    {
      "Sid": "DataMasqueRedshiftTagging",
      "Effect": "Allow",
      "Action": [
        "redshift:DescribeClusters",
        "redshift:CreateTags"
      ],
      "Resource": "arn:aws:redshift:*:<account-id>:cluster:*"
    },
    {
      "Sid": "DataMasqueS3Tagging",
      "Effect": "Allow",
      "Action": [
        "s3:PutObjectTagging"
      ],
      "Resource": "arn:aws:s3:::<bucket-name>/*"
    }
  ]
}

rds:ModifyDBInstance is used only to enable CopyTagsToSnapshot on the masked instance, so that the protection tags propagate to snapshots automatically (see below).

Preserving tags through RDS snapshot and restore

DataMasque tags the RDS instance (not the snapshot) and sets CopyTagsToSnapshot=true. With this in place, tags copy automatically from the instance to its snapshots, and from a snapshot to an instance restored from it, as long as no explicit tags are supplied on the snapshot or restore operation.

Note: Amazon Aurora manages snapshot tag copying at the cluster level, so CopyTagsToSnapshot set on an Aurora DB instance has no effect, and Aurora cluster snapshots copy cluster tags rather than the instance tags DataMasque applies. Automatic propagation therefore applies to non-Aurora RDS instances only; for Aurora, include the protection tags in your snapshot or restore tooling explicitly, as shown in the snippets below.

Do not pass explicit --tags on snapshot or restore

Supplying explicit --tags on create-db-snapshot or restore-db-instance-from-db-snapshot overrides AWS tag inheritance and drops the inherited protection tags. When using the AWS CLI, omit --tags so the tags inherit:

# Inherits the instance tags (including the DataMasque protection tags).
aws rds create-db-snapshot \
  --db-instance-identifier my-masked-instance \
  --db-snapshot-identifier my-masked-snapshot

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-restored-instance \
  --db-snapshot-identifier my-masked-snapshot

CloudFormation and Terraform always send an explicit tag set on the restored resource, so tag inheritance does not apply to IaC restores. To keep the masked-data signal on resources restored via IaC, include the protection tags in the restore template, as shown below. If your organisation manages snapshot and restore pipelines entirely through its own templates, see Tagging AWS resources with your own CloudFormation or Terraform for a fuller guide. The snippets carry only datamasque:masked and aws-apn-id; datamasque:masked-date and datamasque:run-id describe the original masking run and are intentionally omitted, so they will not be present on resources restored this way.

CloudFormation restore snippet

Resources:
  RestoredInstance:
    Type: AWS::RDS::DBInstance
    Properties:
      DBSnapshotIdentifier: my-masked-snapshot
      DBInstanceClass: db.t3.medium
      Tags:
        - Key: "datamasque:masked"
          Value: "true"
        - Key: "aws-apn-id"
          # Replace with the value from the masked instance's `aws-apn-id` tag.
          Value: "pc:<product-code>"

Terraform restore snippet

resource "aws_db_instance" "restored" {
  snapshot_identifier = "my-masked-snapshot"
  instance_class      = "db.t3.medium"

  tags = {
    "datamasque:masked" = "true"
    # Replace with the value from the masked instance's `aws-apn-id` tag.
    "aws-apn-id" = "pc:<product-code>"
  }
}

Finding masked resources with AWS Config

If AWS Config is recording resource configurations, you can query for all resources DataMasque has marked as masked using an advanced query:

SELECT
  resourceId,
  resourceType,
  accountId,
  awsRegion
WHERE
  tags.key = 'datamasque:masked'
  AND tags.value = 'true'

Run it from the AWS Config console under Advanced queries, or with the CLI:

aws configservice select-resource-config \
  --expression "SELECT resourceId, resourceType, accountId, awsRegion WHERE tags.key = 'datamasque:masked' AND tags.value = 'true'"