A Resend alternative that skips the meteringSame developer-first sending, priced by AWS instead of a usage tier.

The free tier is the part of Resend most developers meet first, and it is a fair way to try the API. The part that matters for a growing app is what happens after: usage-based pricing that climbs as your send volume climbs, on Resend's own cloud rather than infrastructure you hold. For a side project that never leaves the free tier, this is a non-issue. For an app whose signups, receipts and notification volume are genuinely growing, the bill grows with it in a way that a flat, owned platform does not.

If your app sends a small, steady volume that comfortably sits inside the free or entry tier, and you only ever want a hosted send API with a React email preview workflow and nothing else, Resend already does that job well. There is no reason to add an AWS account for a problem that is not costing you anything.

• Stay if you will not open an AWS account under any circumstance.
• Stay if all you want is a hosted send API and a React preview tool, with no plan to ever add marketing campaigns.
• Move if send volume is climbing and the usage bill is climbing with it, or if you want your product's sending account to be one you administer rather than rent.

1. Inventory every place your codebase calls the Resend API and every domain it sends from.
2. Purchase a SendBunny license, then walk through the one-click install so the platform lands inside your own AWS account.
3. Verify the same sending domain in SES so DKIM and reputation carry over cleanly rather than starting cold.
4. Update your SDK or HTTP client calls to SendBunny's transactional API. If you can, ship the change behind a feature flag rather than a hard cutover.
5. Remove the Resend API keys once production traffic has run clean on the new path for a stretch, not just a single test send.

Templates and any client-side React email components you built do not migrate automatically; the API call changes, but the rendering logic in your codebase is yours to keep or rewrite either way.

What stays the same either way: your account is still subject to the sending rules of whichever infrastructure carries the mail. Moving off a vendor's cloud does not exempt you from anything; it removes a vendor's policy layer sitting on top of AWS's own rules, and AWS's rules still apply directly to your account.

It also means the operational surface shifts onto your team. On Resend, a delivery incident is partly Resend's problem to explain. On your own SES account, the bounce rate, the complaint rate and the sandbox status are numbers only your team is watching, which is more control and also more responsibility for noticing when something drifts.

SendBunny installs into your own AWS account with one click and is a single $199 purchase, with optional $99 yearly updates after the first year. It sends through your own Amazon SES at Amazon's rate, roughly a tenth of a cent per email, with unlimited contacts and no usage tier on top. Because it is a full platform rather than a send-only API, the same install also carries campaigns, automations, a shared inbox, analytics and a template editor, so product email and marketing email end up on one account instead of two. Your AWS credentials never pass through our hands at any point, which is what makes the install zero-access.

New AWS accounts start in the SES sandbox, which only sends to verified addresses. SendBunny's dashboard shows that status directly and links to AWS's production-access form, so you can wire and test the transactional path while approval is pending.