DEV Community

SendFleet
SendFleet

Posted on

Amazon SES without the AWS homework: how SendFleet runs your email in your own account

#aws #email #serverless #devops

One Click Account Setup

Amazon SES is cheap, fast and reliable, and your sending reputation is your own. Most teams that choose it then spend days on everything around sending. This post walks through that work, and how SendFleet automates it inside the customer's own AWS account.

1. Getting access without holding keys

SendFleet never stores AWS keys. The customer launches a CloudFormation template that creates one IAM role, SendFleet-BYOC-Role. Its trust policy allows exactly two SendFleet roles, and only with an ExternalId generated for that customer:

"Condition": {
  "StringEquals": { "sts:ExternalId": "<your ExternalId>" },
  "ArnEquals": { "aws:PrincipalArn": [
    "arn:aws:iam::<sendfleet>:role/SendFleetByocRelay",
    "arn:aws:iam::<sendfleet>:role/SendFleetByocControl"
  ]}
}
Enter fullscreen mode Exit fullscreen mode

The ExternalId prevents the confused-deputy problem. The PrincipalArn condition means even SendFleet's own web servers cannot assume the role. All management calls go through one control
Lambda in an isolated AWS account.

2. The region problem

SES production access is granted per region. An account can be live in Ireland and sandboxed in Singapore. SendFleet reads SES in every supported region with one role session, in parallel, and picks the region with production access and the biggest quota. If there is none, it prefers a region where AWS is already reviewing a request. Choosing a region by hand stays available, for data residency.

3. Tracking that heals itself, but never fights you

SendFleet creates a configuration set (sendfleet-tracking) and an SNS topic (sendfleet-events) in the customer's account, and subscribes its own queue to the topic. Fixed names make every step idempotent: a repair re-creates the same set, so messages already queued with that name still work.

A daily sweep checks the set, topic and subscription. If something drifted, it repairs it, unless:

  • the customer turned automatic repair off: it only reports the drift;
  • the same resources were removed again within 24 hours of a repair: it assumes the customer meant it, stops, and asks.

Every write to the configuration row is fenced on a generation counter, so a stale worker can never overwrite a newer decision.

4. Paying only for the events you need

SNS bills the customer per published event. Bounces, complaints and rejections are always published: protection depends on them, and they are rare. Deliveries, which are about one event per recipient, are optional.

"Sent" is never published at all. The relay already knows when SES accepted a message, so it reports that itself, signed with a secret only SendFleet holds.

5. Protection before AWS steps in

AWS reviews accounts at a 5% bounce rate or 0.1% complaint rate. SendFleet evaluates the customer's own traffic over 24 hours and 7 days against a profile they choose. It warns first, then pauses sending with a clear API error until the customer reviews and resumes. Addresses skipped by SES Auto Validation are counted as suppressed, not bounced, matching how AWS measures it.

6. Logs without content

With email logs on, each send appears in the log as "Queued" the moment the API accepts it, moves to sent, delivered or bounced as events arrive, and turns "Failed" with a plain reason if it never reaches SES. Bodies are never stored, and subjects can be switched off.

Try it

SendFleet is free for 3,000 emails a month and $5 a month after that, with 20,000 emails included emails included, then $0.10 per 1,000.
You pay AWS for SES directly.

https://sendfleet.net · Docs: https://docs.sendfleet.net/byoc

I would love feedback, especially from anyone running SES at scale.

Top comments (0)