Introducing SendOps: A Control Plane for AWS SES

If you send email through AWS SES, you already know the pitch: unmatched deliverability, a fraction of the cost of Sendgrid or Postmark, and the reliability of AWS infrastructure behind every message.

You also know what comes after: the weeks of wiring up EventBridge rules, SNS topics, and CloudWatch dashboards just to answer "did that email arrive?" The templating system that hasn't changed since 2015. The complete absence of team collaboration tools. The fact that your marketing team needs AWS console access to preview an email.

I've lived this for years. At Cloud 66, we send millions of transactional emails through SES — deployment notifications, alerts, onboarding sequences, billing receipts. SES handles the sending beautifully. Everything around it, we had to build ourselves.

SendOps is what we built, extracted, and turned into a product.

What SendOps actually is

SendOps is a control plane for AWS SES. It doesn't send email. It doesn't proxy email. It doesn't even touch your email content in transit. Your application calls SES directly, the same way it does today, and SES delivers your messages.

What SendOps does is everything else.

It connects to your AWS account — your SES resources, in your infrastructure — and layers on the management, observability, and workflow tools that SES doesn't ship with. Think of it as the dashboard, the template editor, the analytics engine, and the alerting system that AWS never built.

This distinction matters. Because we never sit in the sending path, there's no added latency, no additional point of failure, and no reason to change a single line of your sending code. Your SES costs stay exactly the same. Your compliance posture stays exactly the same. You just get visibility into what's happening.

The problem, specifically

Every team that reaches a certain scale with SES hits the same walls:

No visibility after the send. You call SendEmail, you get a 200 back, and you assume it worked. When it doesn't — a bounce spike, a complaint wave, a DKIM record that drifted after a DNS change — you find out because users tell you. Not because anything alerted you.

Templates are stuck in 2015. SES templates are stored as blobs in the SES API. No version control. No preview. No approval workflow. No way to let a non-engineer touch them safely. So templates either live in your codebase as string literals, or they live in an SES API call that nobody remembers writing.

No concept of channels. You're sending password resets, marketing campaigns, and billing receipts through the same configuration set — or worse, no configuration set at all. When your marketing send tanks your deliverability, your transactional email goes down with it.

Team access is all or nothing. Either someone has AWS console access, or they can't see anything about your email infrastructure. There's no role for a marketing lead who needs to manage templates, or a finance team member who needs to see costs.

What we ship

Analytics and reporting. Every SES event — send, delivery, bounce, complaint, open, click — flows through EventBridge into SendOps, where it's stored, aggregated, and made searchable. Dashboards break down deliverability by channel, template, and tag. You can trace an individual message or spot trends across millions of sends.

Git-synced templates. Connect a GitHub repository and manage your email templates in code — with version control, pull request reviews, and rendered preview comparisons. Your engineering team gets the workflow they expect. Teams that prefer a visual editor get that too. Both stay in sync.

Channels. SendOps maps directly to SES configuration sets, but wraps them in a concept that makes operational sense: separate your transactional, marketing, and notification traffic with distinct identities, tracking, and alerting thresholds. A bad marketing send stays contained.

Team roles and permissions. Invite your marketing team, your finance lead, your operations engineer — each with the access they need and nothing more. Nobody needs to touch the AWS console.

Deliverability alerting. Set thresholds per channel for bounce rates, complaint rates, and delivery drops. Get notified via email, Slack, or webhook before SES sends you a warning — or worse, suspends your account.

IP warm-up. When you add a new sending identity, SendOps manages the gradual volume ramp that ISPs expect, so you don't crater your reputation on day one.

Bring your own AWS account

This is the part I want to be explicit about, because it's the architectural decision everything else follows from.

SendOps doesn't have its own SES infrastructure. It doesn't pool your email with other customers' email. It doesn't have sending IPs that you share with strangers. Your AWS account, your SES resources, your sending reputation — all yours.

This means your cost structure is SES pricing. Not "SES pricing plus a per-message fee." Not "SES pricing but we mark it up." Just SES pricing. SendOps charges a flat subscription for the management layer — not for the messages you send.

It also means your data stays in your AWS account. SendOps processes SES events to build analytics, but the sending infrastructure is yours. If you ever stop using SendOps, your SES setup keeps working exactly as it did.

Already running at scale

SendOps isn't a prototype. It's extracted from production infrastructure that has been running at Cloud 66 for years, handling millions of emails across deployment notifications, transactional messages, and operational alerts. Cloud 66 is our first — and genuine — customer at scale.

We built this because we needed it. We're shipping it because every team we talk to that's on SES needs it too.

What's next

We're launching with a free tier that covers small teams, a Team plan for growing companies, and a Business plan for high-volume senders. Every feature is available on every tier — the only differences are seats, templates, and data retention.

If you're running SES and want to stop flying blind, sign up at sendops.dev.

We'd love to hear what you think.