AWS SNS & SES in Production — Why Emails Land in Spam and How to Fix Notification Costs

# SMS and Email Notifications Architecture — AWS SNS, SES, and Cost-Effective Messaging for Digital Transformation

Every modern application needs notifications. Whether it is a two-factor authentication OTP, an order confirmation, a shipping update, or an appointment reminder, transactional messaging is foundational infrastructure that touches every user interaction.

The challenge is not sending a single message — that is trivial. The challenge is building a notification system that scales to millions of messages per month without the cost spiraling out of control, handles multiple channels intelligently, maintains high deliverability, and respects regional regulations.

This guide covers the complete architecture for transactional notifications, with deep dives into SMS economics, email infrastructure, real-world case studies with actual cost breakdowns, and best practices for high-volume messaging.

---

1. The Notification Challenge in Digital Transformation

Why Notifications Matter More Than You Think

Notifications are not a feature — they are infrastructure. Every digital transformation initiative generates notification requirements:

• E-commerce platforms: Order confirmations, shipping updates, delivery notifications, payment receipts
• Banking and fintech: OTP for login, transaction alerts, statement notifications, fraud warnings
• Healthcare: Appointment reminders, lab results ready, prescription notifications, emergency alerts
• SaaS platforms: Welcome emails, password resets, usage alerts, billing notifications
• Logistics: Pickup scheduled, in-transit updates, delivery attempts, proof of delivery

The Cost Explosion Problem

Notification costs scale linearly with users, and SMS is where budgets break:

The difference between $0.05/msg (US rate) and $0.002/msg (India transactional rate) is dramatic. At scale, the country you operate in and the provider you choose can mean the difference between a $1,500/month notification budget and a $150,000/month one.

The Wrong Provider Problem

Choosing the wrong notification provider early creates painful migration later:

• Vendor lock-in through proprietary APIs and template systems
• Phone number ownership issues (you may not own your short codes or sender IDs)
• Deliverability reputation is tied to the provider — switching resets your reputation
• Integration depth across your codebase makes swapping providers a multi-sprint effort

The solution: Build an abstraction layer from day one. Your business logic should never call SMS or email APIs directly.

---

2. SMS Architecture — Complete Guide

AWS End User Messaging (formerly SNS SMS)

AWS End User Messaging is the rebranded SMS capability that was previously part of Amazon SNS. It provides direct SMS sending with per-message pricing that varies significantly by country.

Pricing by Country (key markets):

Source: AWS End User Messaging pricing page (aws.amazon.com/end-user-messaging/pricing/)

Key Observations:

• India is one of the cheapest markets for SMS globally
• European and APAC countries are 10-20x more expensive than India
• The cost difference between countries makes channel strategy critical — SMS everything in India is affordable; SMS everything in Germany will bankrupt you

Character Limits and Encoding (CRITICAL for Cost)

This is where most teams get surprised. SMS billing is per segment, not per message. Understanding character encoding is essential for cost control.

GSM-7 Encoding (Standard Characters):

Characters included: A-Z, a-z, 0-9, space, and common symbols (@, $, !, ?, -, +, etc.)

• Single message limit: 160 characters = 1 segment (1 charge)
• If message exceeds 160 characters: splits into segments of 153 characters each (7 characters are used for concatenation headers that tell the phone how to reassemble the message)
• Example: A 320-character GSM message = 3 segments (153 + 153 + 14) = 3x the cost

UCS-2 Encoding (Unicode Characters):

Triggered by: ANY character outside GSM-7 — emojis, Hindi, Chinese, Arabic, Japanese, Korean, accented characters beyond basic Latin

• Single message limit: 70 characters = 1 segment
• If message exceeds 70 characters: segments of 67 characters each
• ONE emoji or ONE Hindi character in your message = ENTIRE message uses UCS-2 encoding

The Cost Impact of Encoding:

The last row is the dangerous case. A 200-character message in pure GSM-7 costs 2 segments. Add a single emoji and it becomes UCS-2: now 200 characters ÷ 67 = 3 segments. That one emoji just increased your cost by 50%.

Cost Optimization Rules for SMS

Keep messages under 160 GSM characters — measure in GSM characters, not Unicode code points

Never use emojis in transactional SMS — they force UCS-2 encoding and can double/triple cost

Use URL shorteners — save 20-30 characters per link (bit.ly, your own branded shortener)

Template all messages — enforce character count validation before sending

Use regional language only when necessary — if your users can read English, send in English (GSM-7)

Pre-validate encoding — build a function that checks if a message will be GSM-7 or UCS-2 before sending

Example: Optimized OTP Message

Your OTP is 384721. Valid for 5 minutes.

Characters: 42 | Encoding: GSM-7 | Segments: 1 | Cost: $0.00223 (India)

Example: Unoptimized OTP Message

✅ Your verification code is 384721. Please enter this code within the next 5 minutes to complete your login. Do not share this code with anyone. - TeamApp

Characters: 149 | Encoding: UCS-2 (because of ✅) | Segments: 3 (149 ÷ 67 = 2.2, rounds up to 3) | Cost: $0.00669 (India)

The unoptimized version costs 3x more and delivers the same information.

Alternatives to AWS SMS

Twilio:

• Most feature-rich programmable SMS platform
• Excellent API, great documentation, SDKs for every language
• US: $0.0079/msg outbound + carrier fees
• Best for: Multi-channel (SMS + Voice + WhatsApp + Video), complex routing, US-focused
• Drawback: Premium pricing, can be 2-3x AWS for high volume

Vonage (formerly Nexmo):

• Strong international coverage, good for multi-country deployments
• Competitive pricing in European and APAC markets
• Good fallback routing — retries through alternate carriers
• Best for: International SMS with good deliverability

Plivo:

• Budget-friendly alternative to Twilio with similar API
• US: $0.005/msg (cheaper than Twilio)
• Good coverage in US, Canada, UK, India
• Best for: Cost-sensitive applications that need Twilio-like features

Country-Specific Local Carriers (cheapest for single-country high-volume):

For India:

• MSG91: DLT-compliant, excellent India coverage, competitive pricing, good for transactional
• Kaleyra: Enterprise-grade, good for banking and fintech, DLT registered
• Gupshup: WhatsApp Business API + SMS combo, good for conversational messaging

For India specifically, local carriers often provide better deliverability than international platforms because they have direct carrier relationships and handle DLT compliance natively.

India DLT Compliance (Critical for Indian Market)

Since 2021, India requires all commercial SMS to be registered on the Distributed Ledger Technology (DLT) platform:

• Register your business entity on DLT (Jio, Airtel, or Vodafone-Idea portal)
• Register all message templates with variable placeholders
• Register sender IDs (header like "BANKXX")
• Every SMS sent must match a registered template — unregistered messages are blocked
• This adds 2-3 weeks to SMS setup for the Indian market

---

3. Email Architecture — Complete Guide

AWS SES (Simple Email Service)

AWS SES is the most cost-effective email sending service for high-volume transactional and marketing email. It provides raw SMTP and API access with enterprise-grade deliverability features.

Pricing:

• $0.10 per 1,000 emails sent ($0.0001 per email)
• 62,000 free emails per month when sending from an application hosted on EC2
• Attachments: $0.12 per GB of attachments
• Dedicated IPs: $24.95/month per IP (recommended for >100K emails/month)
• Receiving email: $0.10 per 1,000 emails + $0.09 per 1,000 incoming email chunks

At Scale:

• 1M emails/month: $100 (effectively free compared to SMS costs)
• 10M emails/month: $1,000
• 100M emails/month: $10,000

Deliverability Features:

• DKIM (DomainKeys Identified Mail): Cryptographic signing that proves you own the sending domain
• SPF (Sender Policy Framework): DNS record authorizing SES to send on your domain's behalf
• DMARC (Domain-based Message Authentication): Policy that tells receiving servers what to do with unauthenticated mail
• Dedicated IPs: Your sending reputation is isolated from other SES users
• IP warm-up: Gradual increase in sending volume to build IP reputation
• Suppression list management: Automatic removal of bounced/complained addresses
• Virtual Deliverability Manager: AI-powered insights and recommendations

Configuration Best Practices:

DNS Records Required:
SPF: v=spf1 include:amazonses.com ~all
DKIM: 3 CNAME records (provided by SES)
DMARC: _dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"
Custom MAIL FROM: For complete authentication alignment

SES Sandbox vs Production:

• New accounts start in sandbox mode (can only send to verified addresses)
• Request production access: Provide use case, expected volume, bounce/complaint handling plan
• Approval typically takes 24-48 hours
• Production access removes sending restrictions

Email Alternatives

SendGrid (Twilio):

• Best for: Combined marketing + transactional email with a visual template editor
• Free tier: 100 emails/day
• Paid: Starts at $19.95/month for 50K emails
• Strength: Visual campaign builder, A/B testing, advanced analytics
• When to choose over SES: When marketing team needs self-service email campaign tools

Mailgun:

• Best for: Developer-focused transactional email with excellent API
• Free tier: 5,000 emails/month for 3 months
• Paid: $0.80 per 1,000 emails (8x more expensive than SES)
• Strength: Email validation API, excellent logs and debugging, inbound email parsing
• When to choose over SES: When you need sophisticated email parsing or validation

Postmark:

• Best for: Highest deliverability for transactional email (they refuse to handle marketing email)
• Pricing: $1.25 per 1,000 emails
• Strength: Industry-leading deliverability rates for transactional mail, excellent time-to-inbox
• When to choose over SES: When every email MUST arrive (password resets, invoices, legal notices)

For High Volume (>1M/month):

AWS SES is unbeatable on cost. At $0.10/1,000 emails, you pay $100 for a million emails. Competitors charge $800-1,250 for the same volume. Unless you have specific deliverability requirements that SES cannot meet, SES is the default choice for high-volume senders.

---

4. Three Case Studies

Case Study 1: E-Commerce Platform (India)

Business Profile:

• 500K orders per month
• Each order generates: order confirmation (SMS + email), shipping update (SMS), delivery confirmation (SMS + email)
• Average 3 SMS and 2 emails per order
• Operating exclusively in India
• Price-sensitive customer base expects SMS updates

Architecture:

Order Service → SQS (notification queue)
                    ↓
              Lambda (notification router)
                    ↓
         ┌─────────┼─────────┐
         ↓         ↓         ↓
    AWS End User  AWS SES   Push
    Messaging    (email)   (Firebase)
      (SMS)

Why This Architecture:

• SQS decouples notification sending from order processing — if SMS provider is slow, orders are not affected
• Lambda processes queue messages and routes to appropriate channel
• Dead letter queue (DLQ) catches failed notifications for retry
• Each channel has independent retry logic and failure handling

Cost Breakdown:

• SMS: 500K orders × 3 messages × $0.00223 = $3,345/month
• Email: 500K orders × 2 emails × $0.0001 = $100/month (practically free)
• Lambda: ~1.5M invocations × $0.0000002 = ~$0.30/month (negligible)
• SQS: ~1.5M messages × $0.40/million = $0.60/month (negligible)
• Total: ~$3,500/month for complete notification stack

Optimization Applied:

• All SMS messages templated in English (GSM-7) to avoid UCS-2 encoding
• SMS kept under 160 characters (single segment)
• Shipping updates moved to push notifications for users with the app installed (free)
• WhatsApp Business API used for delivery confirmations (free after first 1,000 conversations/month on business-initiated template messages)

Savings from Optimization:

Without optimization (Hindi messages, 2+ segments, SMS for everything):

• 500K × 5 messages × 2.5 segments × $0.00223 = $13,937/month
• Savings: ~$10,400/month by optimizing templates and channel routing

Case Study 2: Banking App (Multi-Country: India, UAE, Singapore)

Business Profile:

• 200K daily active users across three countries
• Every login requires OTP (SMS)
• Transaction alerts for amounts above threshold
• Monthly statement notifications
• Regulatory requirement: certain alerts MUST go via SMS

Challenge: Different countries have vastly different SMS costs:

• India: $0.00223/msg (affordable for everything)
• UAE: $0.03379/msg (15x India — painful at volume)
• Singapore: $0.04140/msg (19x India — very expensive)

Architecture:

Authentication Service → Notification Service (abstraction layer)
                              ↓
                    Country-Based Router
                    ↓         ↓         ↓
                 India      UAE     Singapore
                   ↓         ↓         ↓
              AWS SMS    AWS SMS    AWS SMS
              (all)     (OTP only) (OTP only)
                         ↓         ↓
                    Push + Email  Push + Email
                    (alerts)     (alerts)

Channel Strategy by Country:

Cost Breakdown:

• India (150K users × 3 SMS/day): 450K × 30 × $0.00223 = $30,105/month (all SMS)
• Wait — that is too high. Let us optimize:

- India (150K users): OTP only via SMS (1/day avg) = 150K × 30 × $0.00223 = $10,035/month

- India alerts via Push: Free

• UAE (30K users): OTP only = 30K × 30 × $0.03379 = $30,411/month

- This is why we MUST minimize SMS in UAE

- Actual: 30K × 15 (not all login daily) × $0.03379 = $15,205/month

• Singapore (20K users): OTP only = 20K × 15 × $0.04140 = $12,420/month

Optimized Total: ~$37,660/month

Without Optimization (SMS for everything):

• India: 150K × 30 × 5 msgs × $0.00223 = $50,175/month
• UAE: 30K × 30 × 5 msgs × $0.03379 = $151,555/month
• Singapore: 20K × 30 × 5 msgs × $0.04140 = $124,200/month
• Total: $325,930/month

Savings: ~$288,000/month by using smart channel routing

The lesson: In expensive SMS markets, reserve SMS exclusively for OTP and critical fraud alerts. Use push notifications and email for everything else.

Case Study 3: Healthcare SaaS (US + EU)

Business Profile:

• Appointment reminders for 500 clinics
• Lab results notifications
• Prescription ready alerts
• 300K messages per month (US), 100K messages per month (EU)
• HIPAA compliance required (US), GDPR compliance required (EU)

Compliance Requirements:

• US (HIPAA): Must have BAA with SMS provider. Cannot include PHI in SMS (no diagnosis, no test results in message body). SMS can say "Your lab results are ready" but NOT "Your cholesterol is 240."
• EU (GDPR): Patient consent required for each notification channel. Right to opt-out must be easy.

Architecture:

EHR System → SQS (HIPAA-eligible) → Lambda → Channel Router
                                                    ↓
                                    ┌───────────────┼───────────────┐
                                    ↓               ↓               ↓
                              AWS SMS (US)     AWS SES (US+EU)   Push (app)
                              HIPAA config     HIPAA config      Encrypted

HIPAA-Specific Configuration:

• AWS account with BAA signed
• SMS messages contain no PHI: "You have a new message from Dr. Smith's office. Log in to view."
• Email with TLS enforcement (SES configuration set with TLS required)
• All notification logs encrypted at rest (CloudWatch Logs with KMS)
• Audit trail for every notification sent (who, when, what channel, delivery status)

Cost Breakdown:

• US SMS: 300K × $0.00645 = $1,935/month
• EU SMS (minimized — email preferred): 20K × $0.04010 (UK avg) = $802/month
• EU Email (primary channel): 80K × $0.0001 = $8/month
• US Email: 300K × $0.0001 = $30/month
• Total: ~$2,775/month

EU Strategy: Email is the primary notification channel. SMS only for appointment reminders (time-sensitive, proven to reduce no-shows by 30-40%). Lab results and prescription notifications via email only (cheaper and can include more detail in a GDPR-compliant manner with proper encryption).

---

5. Architecture Best Practices

Build a Notification Service Abstraction

Never call SMS or email APIs directly from business logic. Create a notification service that:

Business Logic → Notification Service → Channel Router → Provider Adapters
                                              ↓
                                    ┌─────────┼─────────┐
                                    ↓         ↓         ↓
                                SMS Adapter  Email     Push
                                    ↓       Adapter   Adapter
                              ┌─────┼─────┐
                              ↓     ↓     ↓
                            AWS   Twilio  MSG91

Benefits of this abstraction:

• Switch providers without changing business logic
• A/B test providers for deliverability
• Route by country (cheapest provider per region)
• Centralized rate limiting, cost tracking, and monitoring
• Single point for compliance checks (opt-out, DND lists)

Queue All Notifications Through SQS

Every notification should pass through a message queue:

Why:

• Reliability: If the SMS provider is down, messages are retained in the queue and retried automatically
• Rate limiting: Process messages at a controlled rate to avoid hitting provider limits
• Cost control: A bug that generates 1M SMS is caught at the queue level before it costs you $50K
• Retry logic: Failed messages retry with exponential backoff without blocking new messages
• Ordering: FIFO queues ensure OTPs are not delivered out of order

Configuration:

• Standard queue for general notifications (at-least-once delivery, higher throughput)
• FIFO queue for OTPs and time-sensitive alerts (exactly-once, ordered)
• Dead letter queue (DLQ) for messages that fail after max retries (alert on DLQ depth)
• Visibility timeout: 30 seconds (enough for SMS API call + response)
• Max retries: 3 for SMS, 5 for email

Implement Per-User Channel Preferences

Users should control how they receive notifications:

User Preferences:
OTP: SMS (required, cannot opt out)
Order updates: Push → Email (fallback)
Marketing: Email only
Account alerts: SMS + Email

Implementation:

• Store preferences in DynamoDB or PostgreSQL
• Notification service checks preferences before sending
• Fallback chain: if push fails (user uninstalled app), fall back to SMS
• Legal requirements override preferences (fraud alerts always go via SMS regardless of preference)

Rate Limit SMS to Prevent Cost Spikes

A single bug in your order processing pipeline could trigger millions of duplicate SMS, costing tens of thousands of dollars in minutes.

Safeguards:

• Per-user rate limit: Maximum 10 SMS per user per hour (prevents loops)
• Global rate limit: Maximum 10,000 SMS per minute (prevents cascade failures)
• AWS spending limit: Set monthly SMS spending limit in AWS account ($5,000 default, adjust based on expected volume)
• Anomaly detection: Alert if SMS volume exceeds 2x normal hourly average
• Circuit breaker: Automatically stop sending if error rate exceeds 20%

Monitor Delivery and Costs

CloudWatch Metrics to Track:

• SMS delivery rate (should be >95%)
• SMS spending (daily, weekly, monthly trends)
• Email bounce rate (should be <5%, ideally <2%)
• Email complaint rate (should be <0.1%)
• Queue depth (growing queue = processing bottleneck or provider outage)
• DLQ depth (messages in DLQ = systematic failures needing investigation)

Alerts to Configure:

• SMS daily spend exceeds budget by 20%: Warning
• SMS daily spend exceeds budget by 50%: Critical (possible bug or abuse)
• Email bounce rate exceeds 5%: Warning (possible list hygiene issue)
• Email complaint rate exceeds 0.1%: Critical (SES may suspend your account)
• DLQ has >100 messages: Investigate immediately

Template All Messages and Enforce Character Counts

Template: order_confirmation
Content: "Order {{order_id}} confirmed. Track: {{short_url}}. Delivery by {{date}}."
Max length: 85 characters (well within single segment)
Encoding: GSM-7 (enforce no Unicode in variable values)
Validation: Reject if rendered message > 160 chars

Every SMS template should:

• Have a pre-calculated maximum length accounting for variable substitution
• Specify allowed encoding (GSM-7 for cost, UCS-2 if regional language required)
• Include a validation step that checks rendered message length before sending
• Be versioned and reviewed for character count whenever modified

---

6. Decision Framework: Choosing the Right Channel

Channel Cost Comparison

The Optimal Strategy:

• Use SMS only where it is irreplaceable: OTP, time-critical alerts, users without app
• Use email for all content-rich, non-urgent notifications
• Use push for real-time updates to app users (free)
• Use WhatsApp in markets with high penetration (India, Brazil, Southeast Asia) for rich transactional messages

---

7. WhatsApp Business API — The Cost-Effective Alternative

In markets where WhatsApp has 90%+ penetration (India, Brazil, Mexico, Indonesia), WhatsApp Business API is increasingly replacing SMS for non-OTP notifications:

Pricing Model:

• Business-initiated messages (templates): Charged per conversation (24-hour window)
• User-initiated messages: Free for the first 1,000 conversations/month
• India pricing: ~$0.0042 per marketing conversation, ~$0.0025 per utility conversation
• Utility conversations (order updates, shipping): Cheaper than marketing

Advantages over SMS:

• Rich media: Images, PDFs, buttons, quick replies
• Read receipts: Know when the user has seen the message
• Two-way: Users can reply, ask questions, take actions
• Delivery confirmation: More reliable delivery status than SMS
• Cost: Comparable to SMS in India, significantly cheaper than SMS in EU/APAC

Limitations:

• Cannot use for OTP (WhatsApp does not allow OTP templates)
• Requires user opt-in (users must message your business first or opt-in via another channel)
• Template approval process (24-48 hours for new templates)
• Rate limits on business-initiated messages for new numbers

---

8. Implementation Checklist

Before You Send Your First Message

• [ ] Choose primary SMS provider (AWS End User Messaging, Twilio, or local carrier)
• [ ] Choose email provider (AWS SES for most cases)
• [ ] Build notification service abstraction layer
• [ ] Set up SQS queue with DLQ for all notifications
• [ ] Configure SMS spending limits in AWS
• [ ] Set up CloudWatch monitoring and alerts
• [ ] Register DLT templates (if sending to India)
• [ ] Configure SES (DKIM, SPF, DMARC, move out of sandbox)
• [ ] Implement per-user notification preferences
• [ ] Build template management system with character count validation
• [ ] Set up rate limiting (per-user and global)
• [ ] Create fallback chain (SMS → Push → Email for critical messages)
• [ ] Document compliance requirements (HIPAA BAA, GDPR consent, DLT registration)
• [ ] Load test notification pipeline (verify it handles peak without dropping messages)

Ongoing Operations

• [ ] Monitor SMS delivery rates daily (alert if <95%)
• [ ] Monitor email bounce/complaint rates (alert if bounce >5% or complaint >0.1%)
• [ ] Review SMS costs weekly (catch unexpected spikes early)
• [ ] Audit notification templates quarterly (optimize character counts, update short URLs)
• [ ] Review channel routing quarterly (move more notifications to cheaper channels)
• [ ] Update DLT templates as messaging changes (India)
• [ ] Warm new dedicated IPs gradually (SES)
• [ ] Clean email suppression lists monthly

---

Frequently Asked Questions

What is the best approach for sending notifications at scale?

Use a message queue (SQS, RabbitMQ) between your application and notification services to handle traffic spikes and ensure delivery. Implement provider abstraction so you can switch between Twilio, SNS, or SendGrid without code changes. Support user preferences for channel (SMS, email, push), frequency, and opt-out. Rate limit to avoid hitting provider thresholds.

How do I choose between SMS and email for notifications?

Use SMS for time-critical alerts (OTP codes, outage notifications, appointment reminders) where immediate attention is needed — SMS has 98% open rates within 3 minutes. Use email for detailed content, non-urgent updates, and marketing where recipients need time to read. Many systems use multi-channel with fallback: try push notification first, then SMS, then email.

How do I handle notification delivery failures?

Implement retry logic with exponential backoff for transient failures. Track delivery status through provider webhooks (delivered, bounced, failed) and maintain a dead-letter queue for undeliverable messages. Set up monitoring for delivery rates — a drop below 95% indicates a systemic issue. Handle hard bounces by disabling the contact method to protect sender reputation.

What compliance considerations apply to SMS and email notifications?

SMS requires explicit opt-in consent (TCPA in US, GDPR in EU) and must include opt-out instructions. Email requires CAN-SPAM compliance with unsubscribe links, physical address, and honest subject lines. Maintain consent records with timestamps. Different countries have specific regulations — carrier filtering, sender ID registration, and time-of-day restrictions for promotional messages.

---

Related Resources

• Cloud Region Selection Guide — Choose the right region for your notification infrastructure
• AWS vs Azure vs GCP Compute Services — Compute decisions that affect your notification architecture
• Monitoring and Alerting for Production Systems — Setting up alerts for notification delivery
• Architecture Patterns — System design patterns for scalable notification systems
• DevOps Toolkit — Tools for managing notification infrastructure