AWS SNS subscription keeps deleting the subscription itself
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
If an AWS SNS subscription appears to delete itself repeatedly, the root cause is usually automation or endpoint lifecycle behavior, not SNS randomly removing resources. Common causes include IaC drift correction, endpoint auto-unsubscribe on repeated failures, permission errors with cross-account targets, or manual cleanup jobs.
A reliable diagnosis starts by checking CloudTrail and deployment pipelines to identify who initiated Unsubscribe or DeleteSubscription actions.
Core Sections
1. Audit subscription lifecycle events
Use CloudTrail to trace deletion source:
Look for IAM principal, automation role, and timestamp correlation.
2. Verify infrastructure-as-code ownership
CloudFormation/Terraform can delete and recreate subscriptions during reconciliation if configuration changes or resource identifiers drift.
Check deploy logs for subscription resource updates.
3. Inspect endpoint health behavior
For protocols like HTTP/S, repeated delivery failures can trigger disablement logic at endpoint side. Ensure endpoint returns proper response codes and confirms subscriptions correctly.
4. Confirm permissions and policies
Cross-account SNS/SQS subscriptions require correct topic and queue policies. Missing policy permissions can cause unstable subscription state.
5. Monitor retries and DLQ strategy
Configure delivery policies and dead-letter queues where supported so failures are observable instead of silently cycling.
Common Pitfalls
- Assuming SNS service bug without checking CloudTrail actor details.
- Ignoring Terraform/CloudFormation reconciliation effects on subscription resources.
- Not confirming subscription endpoint handshake for HTTP/S protocols.
- Missing cross-account policy permissions for topic-to-endpoint delivery.
- Lacking monitoring around subscription state transitions and failure rates.
Summary
SNS subscriptions rarely “self-delete” spontaneously. Most cases come from automation, policy misconfiguration, or endpoint lifecycle issues. Use CloudTrail to identify the deleting principal, validate IaC ownership, and verify endpoint and permission health. With proper observability and policy checks, subscription stability becomes predictable.
A practical way to keep this guidance valuable over time is to convert it into an executable runbook rather than treating it as static prose. The runbook should include exact prerequisites, supported tool versions, expected environment settings, and a concise verification sequence that can be run from a clean machine. For each step, include a brief expected output and one common failure signature so engineers can quickly determine whether they are on a known-good path or a known-bad path. This reduces guesswork during incidents and shortens time-to-resolution when teams rotate ownership frequently.
It also helps to maintain one minimal reproducible fixture in source control for the specific scenario covered by the article. The fixture can be a tiny script, focused test case, sample dataset, or minimal manifest depending on topic. The point is to have an artifact that demonstrates both successful behavior and a realistic failure condition in isolation. When dependency versions or infrastructure behavior change, teams can run the fixture quickly and identify whether the regression is caused by environment drift, configuration mismatch, or application logic changes. This dramatically improves debugging speed compared to investigating only full production workflows.
For long-term reliability, add one lightweight CI guardrail that targets the most failure-prone step in the flow. Good examples include schema checks, startup smoke tests, deterministic unit tests, API contract assertions, and compatibility probes. Keep guardrails fast and specific so they run on every change and produce actionable failures. If a class of issue appears repeatedly, promote the manual troubleshooting step into automation so regressions are caught before deployment. Over time, this shifts effort from reactive debugging to preventive quality control and keeps operational knowledge aligned with real-world delivery practices.
As an additional safeguard, schedule periodic verification in a clean ephemeral environment and store the results as part of release evidence. This keeps assumptions current as dependencies evolve and helps detect subtle regressions before they reach production.
