Amazon SNS Message Data Protection Availability Change: Migration Options Before April 30, 2026

Amazon SNS message data protection has a hard availability change on April 30, 2026. AWS says the feature will no longer be available to new customers after that date. Existing customers with SNS message data protection policies configured can keep using it in those accounts, but AWS also says it will not introduce enhancements to the feature.

That is the signal. If you already depend on SNS message data protection, do not panic. If you are building a new SNS security pattern in 2026, do not design around a feature that is closing to new customers.

AWS recommends a Lambda-based architecture using Amazon Bedrock Guardrails for customers who need an alternative. The pattern is simple: publish to an inbound SNS topic, inspect the message with Lambda, call Bedrock Guardrails and custom matching logic for sensitive data detection, then publish the allowed or redacted message to a destination SNS topic.

That sounds easy. The gotchas are in latency, cost, failure handling, redaction consistency, and who owns the policy.

What changes on April 30, 2026

The AWS documentation is direct: effective April 30, 2026, the Amazon SNS message data protection feature is no longer available to new customers. Existing customers with configured SNS message data protection policies can continue to use the feature in those accounts, with security updates but no new enhancements.

The official source is the Amazon SNS message data protection availability change documentation. AWS also links to a GitHub sample for protecting sensitive data in SNS messages with Amazon Bedrock Guardrails.

If you need a baseline refresher on SNS itself, start with What is AWS SNS? and the practical comparison of AWS SNS vs SQS. The migration pattern in this post assumes SNS fanout remains useful, but message inspection moves out of the built-in SNS feature.

The replacement architecture

The replacement is not “SNS data protection, but renamed.” It is an explicit message processing pipeline.

AWS describes the recommended flow this way:

1. Publishers send messages to an inbound SNS topic.
2. A Lambda function subscribed to the inbound topic inspects message content.
3. The Lambda function uses Amazon Bedrock Guardrails to detect sensitive data and apply policies.
4. The policy action is LOG, BLOCK, or REDACT.
5. Processed messages are published to a destination SNS topic for delivery to subscribers.

In architecture terms:

This is a good pattern because it makes policy enforcement visible. You can version the Lambda code, test the guardrail configuration, add metrics, send failures to a dead-letter path, and treat sensitive-data handling as an application control instead of a hidden topic setting.

It also means you now own more moving parts.

LOG, BLOCK, and REDACT are product decisions

AWS lists three policy outcomes in the recommended alternative: LOG, BLOCK, and REDACT. Do not let engineers pick these in isolation. Each outcome has product, compliance, and operational consequences.

For the first rollout, many teams should start in LOG mode in a non-production or shadow pipeline. Use it to understand how often sensitive data appears, which publishers generate it, and what false positives look like. Then move specific patterns to BLOCK or REDACT once the impact is understood.

If your downstream consumers use schemas, REDACT needs special care. Replacing "ssn": "123-45-6789" with "ssn": "[REDACTED]" may be fine for a string field. Replacing a numeric account number with a string token may break validation. Redaction must preserve the contract consumers expect, or you need a versioned destination topic.

Migration decision tree

Use this decision table before you start writing Lambda code:

The most important question is not technical. It is this: which subscribers are allowed to receive raw sensitive data?

If the answer is “none,” the Lambda processor should block or redact before fanout. If the answer is “some,” use separate destination topics with explicit IAM policies. Do not rely on every subscriber to handle sensitive data correctly after delivery.

A practical migration checklist

Start with inventory.

• Run aws sns get-data-protection-policy --resource-arn topic-arn against every important SNS topic.
• Record which accounts and Regions already have policies configured.
• Identify every publisher and subscriber for each protected topic.
• Classify message fields by sensitivity: PII, credentials, tokens, health data, payment data, internal identifiers, and safe operational metadata.
• Decide which policy mode each data type needs: LOG, BLOCK, or REDACT.
• Build an inbound topic and destination topic pair for one low-risk workflow.
• Subscribe a Lambda function to the inbound topic and publish processed output to the destination topic.
• Add a DLQ or quarantine topic before enabling BLOCK mode.
• Measure latency, error rate, throttling, and false positives under realistic load.
• Move publishers one at a time, not all at once.
• Keep the old protected topic stable until replay and rollback paths are tested.
• Document who approves changes to Bedrock Guardrails and custom pattern rules.

This is not a “change the ARN and ship it” migration. It is an event-contract migration.

Example control flow

The Lambda function does not need to be complicated, but it does need to be deterministic:

import os
import boto3

sns = boto3.client("sns")

DESTINATION_TOPIC_ARN = os.environ["DESTINATION_TOPIC_ARN"]
QUARANTINE_TOPIC_ARN = os.environ["QUARANTINE_TOPIC_ARN"]


def handler(event, context):
    for record in event["Records"]:
        message = record["Sns"]["Message"]
        decision = inspect_message(message)

        if decision["action"] == "BLOCK":
            sns.publish(TopicArn=QUARANTINE_TOPIC_ARN, Message=message)
            continue

        output = decision.get("redacted_message", message)

        sns.publish(
            TopicArn=DESTINATION_TOPIC_ARN,
            Message=output,
            MessageAttributes=record["Sns"].get("MessageAttributes", {}),
        )


def inspect_message(message):
    # Call Bedrock Guardrails here, then combine the result with custom patterns.
    # Return {"action": "LOG" | "BLOCK" | "REDACT", ...}
    return {"action": "LOG"}

The exact Bedrock Guardrails call depends on your guardrail configuration and sample project choice. The design point is more important: every message ends in one of three states: delivered, redacted and delivered, or quarantined.

If you build serverless pipelines often, the same failure-handling instincts from SQS plus Lambda event source mapping apply here. Poison messages need isolation. Retries need limits. Operators need a place to inspect failures.

Gotcha: SNS fanout semantics change

With built-in SNS message data protection, the protection lives on the topic. With the replacement architecture, protection lives between two topics.

That changes the fanout model:

• Publishers must send to the inbound topic, not directly to the destination topic.
• Subscribers must subscribe to the destination topic, not the raw inbound topic.
• IAM policies must prevent accidental bypass.
• Cross-account publishers and subscribers need updated resource policies.
• Monitoring needs to cover both topics and the Lambda function.

The common mistake is leaving the destination topic publishable by old publishers. That bypasses inspection completely.

Use IAM and topic policies to enforce the path:

That simple matrix prevents accidental data leaks during migration.

Gotcha: Lambda retries can duplicate notifications

SNS invokes Lambda asynchronously. If your Lambda publishes to the destination topic and then fails before the invocation completes, a retry can publish the same processed message again.

That matters for notifications, ticket creation, billing workflows, and anything that triggers human action.

Mitigations:

• Include an idempotency key in the message body or attributes.
• Store processed message IDs in DynamoDB with a TTL for high-risk workflows.
• Make subscribers idempotent whenever possible.
• Publish to SQS between stages if you need stronger replay behavior.

For deeper event orchestration patterns, EventBridge and Step Functions may be a better fit than raw SNS-to-Lambda if the workflow needs approval steps, retries, and state.

Gotcha: Bedrock Guardrails is not just a library call

Bedrock Guardrails introduces its own operational surface:

• IAM permissions for invoking guardrails.
• Regional availability and latency considerations.
• Policy versioning and approval.
• False positives and false negatives.

If your organization already centralizes guardrail governance, align this migration with that operating model. The Bedrock Guardrails cross-account guide is especially relevant when multiple AWS accounts need consistent sensitive-data controls.

Also remember that Bedrock Guardrails can detect sensitive data, but you may still need custom regex or deterministic checks for internal IDs, customer numbers, tenant IDs, proprietary tokens, or legacy formats. The AWS doc explicitly mentions using Guardrails and custom pattern matching. Treat both as part of the control, not competing options.

Existing customers: stay or migrate?

If you already have SNS message data protection policies configured, you can keep using the feature in those accounts. That may be the right short-term move.

Stay for now if:

• The feature is stable and covers a narrow set of topics.
• You have no immediate need for custom detection logic.
• Your compliance team accepts the current control.
• You can document that AWS is providing security updates but no enhancements.

Start migrating if:

• You need the same pattern in new accounts or future environments.
• You need custom sensitive-data patterns.
• You want version-controlled policy logic.
• You need richer logging, quarantine, and replay behavior.
• You are already standardizing AI safety controls through Bedrock Guardrails.

The strategic direction is clear. Existing support is not the same as future investment.

Observability you need before production

Do not ship the processor without dashboards.

Track these metrics:

Use CloudWatch alarms for Lambda errors, throttles, duration, and quarantine depth. If this is a critical notification path, add synthetic test messages that verify the end-to-end route.

The same CloudWatch fundamentals from AWS CloudWatch Deep Dive apply: metrics without alarms are just dashboards someone forgets to check.

Recommended migration path

For most teams, I would use a four-phase rollout.

Do not migrate the most sensitive or highest-volume topic first. Pick a workflow that has real message variety but manageable blast radius.

The bottom line

April 30, 2026 is the date to remember. After that, Amazon SNS message data protection is closed to new customers. Existing customers can keep using configured policies, but the lack of future enhancements should change how you design new systems.

The Lambda plus Amazon Bedrock Guardrails pattern is more flexible than the old built-in feature, especially when you need custom detection, quarantine, observability, and version-controlled policy logic. It is also more operationally demanding.

The safe migration is not just “replace a feature.” It is “insert an explicit data protection stage into the event path, then lock down every bypass.”

If you do that carefully, the availability change can become an improvement: better ownership, better testing, clearer policy behavior, and fewer sensitive messages reaching places they should never have gone.