SES pricing: what to model (send volume + payload size)

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

Use this page when you need to decide what belongs inside the SES bill model before you argue about optimization.

This guide is about bill boundaries: send volume, payload-sensitive line items, dedicated IP or add-on charges, and the downstream workflow costs that should be tracked beside SES rather than confused with it.

Quick SES pricing inputs

• Emails sent: total send volume per month.
• Payload size: avg KB per email for transfer costs.
• Delivery path: internet egress vs in-region recipients.

What to include in your estimate

• Emails/month: transactional + marketing + notifications
• Peak/incident scenario: retries, duplicates, and alert storms
• Average email size (optional): templates, images, and attachments
• Dedicated IP / add-ons (if used): treat as fixed baseline line items

Tool: AWS SES cost calculator

Inside the SES bill vs outside the SES bill

• Inside the SES bill: email sends, payload-sensitive billing lines when they apply, and fixed SES add-ons such as dedicated IP or similar account-level charges.
• Usually outside the SES bill: application compute, queueing, storage, analytics, CRM workflow, or downstream support tooling that happens because an email workflow exists.
• Why that boundary matters: teams often blame SES for the whole messaging workflow cost when the real multiplier sits in campaign design, duplicate sends, or downstream systems.

Step 1: estimate email volume (separate by intent)

• Transactional: password reset, receipts, signup confirmation, security alerts
• Product notifications: digests, alerts, workflow messages
• Marketing: campaigns, newsletters, onboarding sequences

Workflow: estimate email volume per month

Step 2: price baseline sends

Baseline monthly send cost is typically:

• Baseline cost ≈ emails/month × $/1,000 emails
• Keep separate assumptions for transactional vs marketing if they have different variability (marketing can be bursty).

Step 3: add the incident multipliers (the common budget miss)

• Retry loops: timeouts and downstream failures can cause repeated sends.
• Duplicate notification logic: one user action triggers multiple sends accidentally.
• Alert storms: incidents trigger high-frequency alerts to large recipient sets.

A simple approach: add a “duplicates/retries factor” (for example +5% baseline, +50% in peak month) and validate after you deploy.

Step 4: include payload size only if it’s meaningful

Many teams can ignore payload size for budgeting. Include it when you send large templates or attachments, or when you route email content through a path with measurable data-transfer billing.

• Estimate average email size (kB) for transactional vs marketing templates.
• Prefer links to downloads instead of attachments when feasible.
• Use the same unit conventions (MB vs MiB) when you convert sizes.

Helper: units converter

When this is not the right page

• If your main problem is turning product events, campaigns, recipient counts, and resend behavior into a defendable volume model, go to Estimate email volume per month.
• If the send model is already believable and you now need production changes, go to SES cost optimization.
• If the real question is whether retries, duplicates, or downstream workflow design are creating the cost, use the estimate workflow before treating SES pricing as solved.

How to validate after the first month

• Compare actual sends/day to your baseline and identify campaign vs incident spikes.
• Track retry/duplicate rate (resends and idempotency failures).
• Validate deliverability (bounces/complaints) when you change templates or volume.

Related guides

Sources

• AWS SES pricing
• SES sending concepts (deliverability and sending patterns)

Related guides

Related calculators

FAQ