Key Takeaways

  • Amazon SES looks cheap at a base price like $5,000, but handling production email requires adding Amazon SNS, SQS, and CloudWatch just to track events.
  • Event tracking generates massive traffic: bounces, complaints, opens, and clicks require a dedicated queue architecture to prevent webhook failures.
  • Resend moved away from AWS abstractions down to bare metal servers and purchased dedicated IP blocks to take direct control over deliverability.
  • Rocha rewrote Resend's core sending pipeline from JavaScript to Go to increase throughput and gather lower-level telemetry directly from mail providers.

The Real Architecture Behind a Cheap SES Bill

Every engineer thinks sending email is a solved problem. You create an AWS account, verify a domain in Amazon Simple Email Service, and call an API endpoint. On paper, it looks like one of the cheapest services Amazon offers. In practice, SES is only the tip of an expensive iceberg.

“The hidden cost if you're going with SES is that okay you might be paying only 5K for example but now you need SNS for the events,” (play from 33:17) Zeno Rocha says. “So you need like all the feedback from bounces, complaints, open clicks, all that.” (play from 33:28)

A raw mail server that fires messages into a void is useless for production apps. You need to know if an inbox bounced, if a user marked your message as spam, or if a link failed. SES does not give you a clean dashboard for those events out of the box. You have to route event streams into Amazon Simple Notification Service.

Once you pipe millions of events into SNS, the problems multiply. “And now, so you get the events. Great. Now you need CloudWatch for the logs. Now you need a queue because it's going to be a lot of events. So now you add SQS,” (play from 33:34) Rocha explains.

Suddenly your five-thousand-dollar email line item demands four separate AWS products, custom lambda workers, and retry logic. You are no longer running an email integration; you are maintaining a distributed message queue just to find out if an authentication code was delivered.

Dropping the Abstraction to Own the Pipe

Resend launched on top of SES. It allowed the team to ship fast and serve developers who did not want to wire up AWS plumbing themselves. But as send volumes grew, wrapping third-party APIs hit a wall.

When you route messages through another provider, you share their reputation rules, their throttling bottlenecks, and their blind spots. If a major inbox provider delays your mail, an API wrapper cannot tell you why. You only see that the downstream endpoint returned a 200 or an error.

Resend decided to leave SES behind. The team bought their own IP blocks and moved directly onto bare metal servers. Along with the infrastructure shift, they gutted the application layer: “In the sending path we no longer use JavaScript, we have Go there, and we're changing other parts to be more performant in other ways,” (play from 37:13) says Rocha.

Going to bare metal changes the economics and the telemetry of the product. “The more we're close to the metal, the more we have in terms of data that we can surface for users,” (play from 35:52) Rocha points out. By controlling the SMTP connection directly, Resend can see the exact socket states, handshake delays, and queue lengths that mailbox providers enforce.

Managing your own mail servers used to be considered a bad idea for software startups. Rocha's decision shows the opposite rule: once your core product relies on third-party reliability, their black box becomes your operational ceiling.

What to Do With This

Audit your AWS bill for SES dependencies this week. Calculate the total cost of SNS topics, SQS queues, and CloudWatch logs tied to email delivery, plus the engineering hours spent keeping them in sync. If that hidden overhead exceeds the cost of a managed developer platform, turn off the custom glue code and switch providers.