Comparison

European AWS SES alternative

Almost nobody picks SES for the developer experience. They pick it because it costs fractions of a cent and it’s already inside the account. Two things eventually push teams off it: the realisation that eu-central-1 answers where the data sits but not who the processor is — and the slow accumulation of plumbing you had to build because SES is a sending primitive rather than an email product.

A region is a location. It isn’t a jurisdiction.

Running SES in eu-central-1 or eu-west-1 is a sensible thing to do, and it genuinely settles the data-location half of the GDPR question: the bytes are in Frankfurt or Dublin.

What it doesn’t change is that the processor is Amazon Web Services, a US-incorporated company. Under the US CLOUD Act, a US provider can be compelled to produce data under its control wherever it is physically stored. That is why a transfer impact assessment for SES-in-Europe is still a document you write, revisit, and defend — the region narrows the exposure rather than removing the question. Choosing a processor established in the EEA is what removes it.

Sending infrastructureMail servers we operate ourselves, Falkenstein (Germany)
API hostingNuremberg (Germany)
Database & delivery eventsFrankfurt (Germany)
CompanyA Norwegian entity, inside the EEA and under the GDPR
Parent companyNone — no US parent in the ownership chain
The honest caveatThe marketing site and dashboard front-end are served from a US CDN, and DNS and bot checks run through Cloudflare. Neither handles message content or recipients. The full list is on our sub-processors page.

The plumbing you stop operating

This is usually the bigger practical win, and it is the thing SES pricing doesn’t show you. A production SES setup is never just SES — it is SES plus a small distributed system you wrote and now maintain.

SNS topics + subscriptionsSigned webhooks — email.delivered, email.bounced, email.complained, plus opens and clicks. HMAC-SHA256 signed, no subscription confirmation handshake to handle.
Your own suppression tableHard bounces and complaints are suppressed automatically, account-wide, from the first send.
Configuration sets + event destinationstrackOpens and trackClicks flags on the send, switchable org-wide, with the analytics dashboard already built.
Firehose/Lambda into your own event storeA searchable delivery log with the full event history per message, retained for 30 days and 90 on the larger plans.
CloudWatch alarms on bounce ratePlatform-level thresholds that throttle or suspend before a reputation problem becomes an account problem.
A production access requestA daily ceiling that ramps automatically as you send cleanly — no sandbox ticket.

The code change is a flattening

SESv2’s nested Destination / Content / Simple structure collapses into plain fields, and IAM credentials become an API key:

the diff, roughly
- import { SESv2Client, SendEmailCommand } from '@aws-sdk/client-sesv2'
- const ses = new SESv2Client({ region: 'eu-central-1' })
+ import { Eusend } from '@eusend_dev/sdk'
+ const eusend = new Eusend(process.env.EUSEND_API_KEY)

- await ses.send(new SendEmailCommand({
-   FromEmailAddress: 'Acme <hello@acme.com>',
-   Destination: { ToAddresses: ['user@example.com'] },
-   Content: { Simple: {
-     Subject: { Data: 'Your receipt' },
-     Body: { Html: { Data: html } },
-   } },
-   ConfigurationSetName: 'tracking-and-events',
- }))
+ await eusend.emails.send({
+   from: 'Acme <hello@acme.com>',
+   to: 'user@example.com',
+   subject: 'Your receipt',
+   html,
+ })
  • If you go through nodemailer, there’s no code change at all. Plenty of SES setups point nodemailer at the SES SMTP endpoint. Swap the transport to smtp.eusend.dev on port 465 with implicit TLS and delete the IAM SMTP credential derivation.
  • No more hand-built MIME for attachments. If you reached for SendRawEmailCommand only to attach a PDF invoice, that becomes an attachments array with base64 content — up to 20 files, 10 MB combined.
  • Errors are values. Calls return { data, error } with stable machine-readable codes instead of throwing AWS SDK exception types you match on by name.

The full field mapping, including templates and the SNS-to-webhook translation, is in the SES migration guide.

Where SES is genuinely the better answer

Worth saying plainly, because the alternative is you finding out after migrating. SES wins on raw price and it is not close. If you send very high volume of low-sensitivity mail, you already have the bounce and suppression plumbing working, and nobody is asking you questions about the processor’s jurisdiction, then SES is doing its job and this page is not for you.

The trade is worth it when the plumbing is costing engineering time, when you want delivery problems to be someone’s actual job rather than your on-call rotation, or when “who is the processor” has started appearing in security questionnaires. The pricing page has the numbers to run that comparison honestly.

Common questions

What is the best European alternative to Amazon SES?

eusend is a transactional email API operated by a Norwegian company on infrastructure it runs itself inside the EU. Compared to SES it trades a lower per-email price for a complete product — suppression, delivery webhooks, open and click tracking, and a delivery log are built in rather than assembled from SNS topics, configuration sets and your own database.

Is SES in eu-central-1 already GDPR compliant?

Sending from an EU region is a reasonable and common choice, and it satisfies the data-location half of the question. It does not change who the processor is: AWS is a US-incorporated company, reachable under the US CLOUD Act for data it controls regardless of the region storing it. Using an EEA-established processor removes that analysis instead of documenting it.

Is eusend cheaper than Amazon SES?

No. SES is the cheapest raw sending pipe available and eusend does not try to beat it on per-email price — the free tier is 3,000 emails a month and paid plans start at €9 for 10,000. The fair comparison is SES plus the engineering time that the SNS plumbing, suppression handling, event storage and CloudWatch alarms cost you to build and keep running.

What do I stop maintaining if I move off SES?

The usual list is SNS topics and subscriptions for bounces and complaints, your own suppression table and the code that writes to it, configuration sets and event destinations for open and click tracking, somewhere to store and query delivery events, and CloudWatch alarms on bounce rate to stop AWS suspending the account. All of those are platform behaviour on eusend.

Does eusend require a production access request like the SES sandbox?

No. New accounts start with a conservative daily ceiling that lifts automatically as you demonstrate clean sending, rather than a support ticket to leave a sandbox. If you need high steady volume from day one, talk to us first so we can plan the ramp.

Run it beside SES before you cut over.

Test keys exercise the full pipeline — accepted, logged, complete webhook lifecycle — without delivering. Point a staging environment at eusend, confirm the events match what your SNS handlers expected, then move production when it looks boring.

Create a free account