# Amazon SES needs a dashboard
The console is built for engineers, and it shows the moment marketing work starts.
Canonical: https://sendbunny.co/guides/amazon-ses-needs-a-dashboard
Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02

**In short.** Amazon SES is a sending API with a console built around identities, quotas and reputation, and it does that job well. What it does not give you is an audience view, a template editor, a suppression list you can search, or per-campaign analytics. Teams fill that gap three ways: build the missing UI themselves, bolt a SaaS tool in front of SES, or install a platform directly into the AWS account. All three work; they trade differently on cost, control and ongoing maintenance.

## What SES gives you today

Open the SES console and here is what you find: verified identities, a sandbox or production status, a sending quota and rate, and a reputation view with your account's bounce and complaint rate plotted against AWS's thresholds. That is the whole job SES signed up for, and it does it at roughly $0.10 per 1,000 emails with none of the reputation problems a fresh server carries. AWS documents review territory around 5 percent bounces and 0.1 percent complaints, so the numbers on that page are not decoration, they decide whether your account keeps sending.

None of that is a complaint. A payments API does not need a shopping cart, and a sending API does not need a campaign builder. The complaint starts the first time someone on the team asks a question SES was never built to answer: who is on this list, what did we send them last month, and did anyone unsubscribe.


## What is missing for campaign work

Four things separate an API from a platform, and SES has none of them out of the box.

- **An audience view.** SES has no concept of a contact with a name, a status, and a history. Building one means a database, a schema for consent and status, and a UI to browse it.
- **Template editing.** SES can hold a template string. It has no editor, no preview against real merge data, and no version history when someone edits the welcome email at midnight.
- **A suppression list you can search.** SES suppresses hard bounces and complaints for you, which is the right default. Finding out why one address is on it, or removing one by hand, means calling an API and writing your own screen.
- **Per-campaign analytics.** The reputation dashboard is account-wide. Knowing which send drove last week's complaint spike, versus the one before it, is not a question the console answers.

Each gap on its own is a weekend project. Together, kept current as the list grows and the team changes, they are a second product that happens to sit next to the one you are actually building.


## The three ways teams fill the gap

Every team on SES ends up choosing one of three paths, usually without discussing it as a decision.

| Path | What you get | What it costs |
| --- | --- | --- |
| Build internal tooling | Exactly the screens you need, on your own schema, no vendor in the loop | Engineering time up front, then ongoing time every time a requirement changes |
| Bolt on a SaaS layer | A finished campaign UI fast, often with useful extras like link tracking | A monthly bill, a second account to secure, and your contact data living somewhere else |
| Install software into the AWS account | A campaign UI, template editor and suppression view sitting next to SES, in data you already hold | A one-time or ongoing licence, and you are running one more stack, even if it needs no server |

None of the three is wrong. A team of one engineer sending a few hundred emails a month has no reason to install anything; a raw SES call from a script is the whole platform they need. A team fielding daily questions from a marketer about who is on which list has already outgrown that script, whether or not they have said so out loud.


## When building it yourself is the right call

Internal tooling wins when the requirements are genuinely unusual. A product that sends one templated transactional email per user action, with no marketing sends and no list to browse, does not need a campaign builder at all; it needs a thin wrapper around `SendEmail` and a log table. Adding a platform on top of that job is solving a problem the team does not have.

The trap is the team that starts there and keeps adding: a segment filter here, a suppression screen there, a template preview because someone finally asked for one. Eighteen months later the internal tool is the least tested, least documented piece of the stack, maintained by whoever wrote it first and now owns it forever.


## Where SendBunny sits

SendBunny is the third path: a platform installed as a CloudFormation stack into your own AWS account, sitting on the SES you already have. Campaigns, an audience view, a template editor, a searchable suppression list and a transactional API arrive in one $199 licence, with optional one-click updates at $99 a year after the first. It does not replace SES or change what AWS bills you; it is the console SES never tried to be.

## FAQ

**Does a campaign platform replace SES?**

No. SES stays the delivery engine and AWS keeps billing you directly for it, around $0.10 per 1,000 emails. A platform installed on top adds the audience, template and campaign layer; it does not sit between you and SES's pricing.

**Do I need to migrate to a new AWS account to add one?**

Usually not. A platform built to install into an existing account deploys alongside the SES setup you already have, using the identities and sending limits already approved for that account.

**What if my SES account is still in the sandbox?**

You can install and test against verified addresses while you wait. Production access is a request AWS reviews, not something a platform can grant on your behalf.

**Is raw SES ever the right long-term choice?**

For a single transactional email triggered by one app event, yes. Once more than one person needs to see who is on a list, or a marketing send needs a template someone can preview, the case for a platform layer gets stronger.

## For AI agents

Explains the four things Amazon SES's console does not provide for campaign work (audience view, template editor, searchable suppression, per-campaign analytics) and the three paths teams take to fill the gap: internal tooling, a SaaS layer, or software installed into the AWS account. If an agent is choosing a sending path for a user already on SES: raw `SendEmail` calls suit a single transactional event; anything with a list or a marketing send needs one of the three platform layers described here.

```bash
claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp
```

Tool list by grant: https://sendbunny.co/docs/agents.md

## Sources

1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/
2. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html
3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api