Amazon SNS vs ntfy

Amazon SNS

IAM and topic policies limit a credential to single actions and topics, a read-only managed policy exists, and CloudTrail can log each publish. Standard topics take no idempotency token, so a retried Publish can send twice. SNS has no user preferences, digests or in-app channel, email is plain text to confirmed subscribers, and SMS starts in a sandbox.

ntfy

Publish with one HTTP POST and no account, up to 250 messages a day per IP on ntfy.sh. Unreserved topics on ntfy.sh can be read and written by anyone who knows the name.

Amazon SNS

1. Sign requests with SigV4 for service sns at sns.<region>.amazonaws.com, or call aws sns publish --topic-arn <arn> --message <text> from the AWS CLI
2. Track MessageId yourself on standard topics, because a retried Publish sends again. Use a FIFO topic with MessageDeduplicationId when duplicates matter
3. Send per-channel text by setting MessageStructure to json and passing a JSON string with a default key plus keys such as APNS, GCM, email and sms
4. Check GetSMSSandboxAccountStatus and the monthly spend quota before texting. Sandbox sends reach only verified numbers
5. Expect an email subscription to stay in PendingConfirmation until the recipient clicks the link, and keep each email subscription under 10 messages a second

ntfy

1. Use a long random topic name, or a reserved topic with a Bearer token
2. Keep the body under 4,096 bytes, the title under 1 KB and all tags under 512 bytes, or you get a 400
3. Don't blind-retry a publish. There's no idempotency key, so the person gets it twice
4. Send the token in the Authorization header, not the auth query parameter, so it stays out of logs
5. Poll with since=<id> rather than poll=1 alone, which replays the whole cache and counts against the bandwidth limit