Skip to content

/ Compare — Amazon SES

An EU region is not EU jurisdiction. The CLOUD Act made sure of it.

Sending through Amazon SES in eu-west-1 keeps your data in Europe — and under US legal reach at the same time, because AWS is a US company and the CLOUD Act follows the company, not the server. AWS knows this: it launched a European Sovereign Cloud in January 2026 to answer it. But that cloud is a wholly-owned subsidiary of Amazon US, which jurists call disputed sovereignty. EDP is the EU-native answer — SES-level economics, genuine EU jurisdiction, no US parent.

/ Quick answer

Sending through Amazon SES in an EU region gives you data residency, not jurisdiction. AWS is a US company, and the CLOUD Act lets US authorities compel American companies to disclose data they control regardless of where it physically sits — so EU-region data is in Europe and within US legal reach at once. AWS launched a European Sovereign Cloud in January 2026 to address this, but it is a wholly-owned subsidiary of Amazon US, and jurists argue a US parent keeps it exposed to the CLOUD Act — disputed sovereignty, at a premium, with a limited catalogue. Email Delivery Platform is the EU-native alternative: SES-level sending economics on dedicated PowerMTA and KumoMTA, operated by an EU entity with no US parent — jurisdiction without an asterisk.

  • Region ≠ law

    An EU region keeps data in Europe but under US jurisdiction. The CLOUD Act follows the company, not the server.

  • Jan 2026

    AWS launched its European Sovereign Cloud — but as a 100% Amazon US subsidiary, its legal sovereignty is disputed.

  • No US parent

    EDP is an EU entity with no US owner — the structural fact the CLOUD Act actually turns on.

  • SES-level

    Sovereignty without the trade: SES-class economics on our own MTAs, managed, not marked up.

/ 01 — The distinction

Residency answers where. Sovereignty answers who.

EU region · Frankfurt your data residency ✓ Amazon · US jurisdiction the company jurisdiction ✗ CLOUD Act compels the company, not the server

The most consequential misconception in European enterprise email is that choosing an EU region resolves the data question. A German company storing records in the Frankfurt region could once reasonably assume those records fell under German law. The CLOUD Act of 2018 ended that assumption: it established that US authorities can compel American companies to disclose data they control, anywhere in the world, regardless of where the servers physically sit. Residency became a statement about geography; sovereignty became a separate statement about legal control, and the two stopped meaning the same thing.

The conflict is structural, not political, which is why it has not resolved itself with time. Schrems II struck down the Privacy Shield framework; its 2023 successor, the EU-US Data Privacy Framework, is already under legal challenge on substantially the same grounds and remains unsettled in 2026. GDPR Article 48 restricts foreign government access to personal data, sitting in direct tension with the CLOUD Act's extraterritorial reach. The European Commission's own Cloud Sovereignty Framework, published in October 2025, proceeds from the assumption that data held by US-controlled providers carries a residual transfer risk that contractual clauses alone cannot remove.

For an ordinary commercial workload, that residual risk is often acceptable, and pretending otherwise would be scaremongering. But for a regulated sender — a financial firm under DORA, a healthcare provider, a public body procuring under sovereignty rules — the acceptable level of residual risk to a foreign jurisdiction is not low. It is zero. A non-zero probability of compelled disclosure is itself a compliance failure, no matter how many times the provider has historically pushed back, and "we would challenge the request" is an argument about willingness, not capability. That is the line where an EU region of a US provider stops being enough.

/ 02 — Your sovereignty bar

Raise the bar and watch the options fall away.

Sovereignty is not one requirement; it is a ladder. Pick the rung your workload actually has to clear and see honestly which options pass it — standard SES in an EU region, the AWS European Sovereign Cloud, or an EU-native provider. The higher you go, the fewer clear it without an asterisk.

Sovereign Cloud assessment reflects the published structure as of 2026 and the legal critique of jurists including French MP Philippe Latombe; the structure is untested in court. Not legal advice — confirm your obligations with counsel.

/ 03 — Credit where due

The AWS European Sovereign Cloud is real engineering — and still has a US parent.

It would be dishonest to wave away what AWS built. The European Sovereign Cloud that went live in January 2026 is a German legal entity, run by EU residents, with data, metadata, billing, and identity management kept inside the EU, backed by a roughly eight-billion-euro investment and a published sovereignty framework. It clears bars a standard EU region never could: data stays in Europe, and global AWS staff cannot operate it. For organizations whose sovereignty requirement centres on residency and operational control, it may be exactly sufficient, and that is a genuine advance.

The unresolved part is the one that the CLOUD Act actually cares about. AWS European Sovereign Cloud GmbH is a wholly-owned subsidiary of Amazon US, and the Act reaches companies subject to US jurisdiction, not data in particular places. French MP Philippe Latombe has argued the cloud cannot be sovereign while subject to US law; Nextcloud's leadership calls the model false sovereignty; the structure has not been tested in court. For the strictest bar — a threat model that includes a US government access request — an independently audited subsidiary of a US corporation is not the same as a provider with no US parent at all. That is not anti-AWS. It is the difference between residency engineered to a high standard and jurisdiction as a structural fact.

/ 04 — The EU-native answer

Jurisdiction as a fact, economics that stay close to SES.

EDP resolves the question by structure rather than assurance. It is operated by an EU entity with no US parent anywhere in the ownership chain, which means the CLOUD Act's test — is this company subject to US jurisdiction — simply returns no. There is no subsidiary relationship to audit, no untested court question, no asterisk: data and control sit under EU law because the company does. That is the one thing a US-owned provider cannot offer at any price, sovereign-branded or not.

The second half is that you do not pay for it in performance or in budget. EDP runs its own dedicated PowerMTA and KumoMTA rather than reselling a hyperscaler, which is what lets it offer SES-level sending economics instead of a sovereignty premium — and the warming, bounce handling, reputation monitoring, and deliverability come operated, not assembled by your team. So the choice is not the usual one between cheap-but-exposed and sovereign-but-expensive. It is managed, EU-native sending at a cost profile built to stay close to raw SES, because owning the MTAs is cheaper than marking up someone else's.

/ 05 — Side by side

Amazon SES vs an EU-native alternative.

SES wins on raw price and on native fit if you already live in AWS, and the matrix says so. The EU-native case is about sovereignty as structure and deliverability as an operated service — the columns where a region, even a sovereign-branded one, leaves a question open.

Filter:
Dimension Amazon SES This platform Managed infrastructure
Raw sending price Their edge ~$0.10 / 1,000 — cheapest at scale SES-level economics, managed and operated
Data residency Yes, in an EU region Yes, EU-native infrastructure
Operational autonomy No on standard region; yes on Sovereign Cloud Yes — EU entity, EU staff
Legal jurisdiction (CLOUD Act) Exposed; disputed even on Sovereign Cloud EU jurisdiction, no US parent
Deliverability work You build warming, bounce, monitoring Operated for you, included
Infrastructure AWS shared cloud Own dedicated PowerMTA and KumoMTA
Engineering to run it Their edge Significant — SES is raw None — managed is the service
Sovereign option premium Sovereign Cloud runs ~20–30% above standard Sovereignty without a hyperscaler premium
Already deep in AWS Their edge Native integration if you live in AWS A move — worth it when sovereignty is required

/ 06 — When SES is right

When a US provider in an EU region is the right call.

Most senders do not have a sovereignty requirement, and for them standard SES in an EU region is an excellent, cheap, reliable choice. If your data is ordinary commercial email, your obligation is satisfied by residency plus a signed data-processing agreement, you already operate inside AWS, and you have the engineering to run deliverability yourself, the residual CLOUD Act risk is a reasonable thing to accept. Buying sovereignty you do not need is its own waste, and we are not going to manufacture a requirement that is not there.

The EU-native case begins precisely where the requirement hardens into something a procurement review or an auditor will test: a regulated sector under DORA or NIS2, a public-sector tender with sovereignty rules, a client contract that demands data be genuinely beyond foreign reach. At that line, residency and even a sovereign-branded US subsidiary stop passing, because they rest on a legal position European courts have already rejected once. If that is your world, an EU entity with no US parent is not a nicety; it is the requirement. If it is not, keep SES — and know which signal will tell you the bar has risen.

/ Common questions

What teams ask about SES and EU sovereignty.

Doesn't sending through Amazon SES in an EU region keep my data in Europe?

It keeps your data physically in Europe, which is data residency, but residency and jurisdiction are different things — and the difference is the whole point. When you send through SES in eu-west-1 or eu-central-1, the messages sit on servers in Ireland or Frankfurt, but the company controlling those servers is Amazon, a US corporation. The US CLOUD Act, signed in 2018, lets US authorities compel American companies to hand over data they control regardless of where it physically sits. So your data is in Europe and under US legal reach at the same time. For many workloads that is an acceptable risk; for regulated ones, it is the exact gap that residency does not close.

Does the AWS European Sovereign Cloud solve this?

It narrows the gap considerably and it is a serious piece of engineering, but it does not fully close the legal question, and honesty about that matters. Launched in January 2026 as a German legal entity with EU-resident staff, EU-only operations, and data, metadata, and billing kept inside the EU, the AWS European Sovereign Cloud clears the data-residency and operational-autonomy bars that a standard EU region fails. The unresolved part is ownership: it is a wholly-owned subsidiary of Amazon US, and jurists from French MP Philippe Latombe to Nextcloud's leadership argue that a US parent keeps it within reach of the CLOUD Act and FISA no matter how separate the operations are. It also carries a premium and a limited service catalogue. For the strictest sovereignty bar, an independent third-party audit and an untested-in-court structure are not the same as no US parent at all.

What makes EDP an EU-native alternative rather than another EU region?

EDP is operated by an EU entity with no US parent company in the ownership chain, which is the structural difference that the CLOUD Act actually turns on. The Act reaches companies subject to US jurisdiction; a provider incorporated and owned under EU law, governed by EU courts, is simply not one of them. On top of that, EDP runs its own dedicated PowerMTA and KumoMTA infrastructure rather than reselling a hyperscaler's, so the sending engine and the IPs are EU-operated end to end. The result is the thing residency and even a sovereign-branded subsidiary cannot give you without an asterisk: data and control under EU jurisdiction, period.

Will I lose SES's pricing if I move?

That is the trade most people assume they have to make, and the reason EDP exists is to not make it. SES is genuinely the cheapest raw sending at scale — around ten cents per thousand emails — and a sovereign alternative that cost many times more would only suit organizations with no budget sensitivity. EDP is built to deliver SES-level sending economics on its own infrastructure, with warming, bounce handling, and deliverability operated rather than assembled by your team, so the comparison is not sovereign-but-expensive against cheap-but-exposed. It is managed, sovereign sending at a cost profile that stays close to raw SES, which is the point of running our own MTAs instead of marking up someone else's.

When is standard Amazon SES actually the right choice?

When sovereignty is a preference rather than a requirement, standard SES is hard to beat and we will say so plainly. If you already operate inside AWS, have the engineering team to run deliverability yourself, and your workload is ordinary commercial email where data residency plus a signed DPA satisfies your GDPR obligations, SES in an EU region is cheap, reliable, and sufficient. The case for an EU-native alternative begins where the requirement hardens: a regulated sector under DORA or NIS2, a public-sector procurement with sovereignty rules, an auditor or client asking you to demonstrate that personal data is genuinely beyond foreign reach. If that is not your world, SES is a reasonable answer and this page is not trying to move you.

Which regulations turn EU jurisdiction from a preference into a requirement?

Several converging ones, which is why this climbed the priority list over the last two years. GDPR Article 48 restricts handing personal data to a foreign authority absent an international agreement, in direct tension with the CLOUD Act. The NIS2 Directive, in full application since October 2024, extends supply-chain and jurisdiction-analysis obligations to providers serving critical infrastructure. DORA, effective January 2025, holds financial entities accountable for the resilience and jurisdiction of their third-party providers. And the European Commission's Cloud Sovereignty Framework of October 2025 codifies the assumption that US-controlled providers carry residual transfer risk. None of these names a vendor, but together they shift the burden of proof onto you to show your data is genuinely beyond foreign reach — and an EU region of a US provider is increasingly hard to defend in that proof.

Is this just a theoretical legal risk, or does it matter in practice?

It has moved from theoretical to procurement-blocking over the last two years, which is why it is worth taking seriously now. Schrems II invalidated the Privacy Shield framework, its 2023 successor is already under legal challenge on the same grounds, and the European Commission's own Cloud Sovereignty Framework from October 2025 proceeds from the assumption that data held by US-controlled providers carries a residual transfer risk that contract clauses cannot eliminate. The practical consequence is concrete: in a serious 2026 procurement or audit, the answer 'an EU region of a US provider' increasingly does not pass, because it relies on a legal position European courts have already rejected once. The risk is not a hypothetical subpoena; it is failing the review before any subpoena exists.

Keep SES economics. Lose the US parent.

Tell us your volume and what is driving the sovereignty question — a regulator, an auditor, a client contract. We'll map an EU-native setup honestly, tell you plainly if standard SES already satisfies your obligation, and if it doesn't, show you sovereign sending that stays close to SES on cost.

Book infrastructure review