Migrate from Amazon SES to managed deliverability, without losing the cost discipline that brought you to AWS in the first place

Yes, SES is cheaper at every volume tier on a bytes basis. At 100K emails per month, SES base is $10 versus our €399; at 1M it is around $107 versus €859; at 10M with managed IPs and VDM it is around $400-700 versus our €2,799 floor. We are not within 2-3x of SES on raw cost at any volume below the very-high-volume tier, and we never will be — pay-as-you-go infrastructure at hyperscaler scale wins that argument.

What changes the picture is what is bundled. SES does not bundle managed warmup, complaint-rate triage, blocklist remediation, named operator review of Postmaster Tools compliance status, or weekly deliverability reporting. To get those at the same level on SES, you either build them in-house (one senior deliverability engineer at €90-130K plus tooling and time) or you pair SES with a deliverability consultancy (typically €2,000-5,000/month retainers). Once you add that to the SES line item, the comparison narrows substantially, and at sub-10M volumes it usually flips. We work through the math with prospects honestly — there are real shapes of email program where SES wins on total cost, and we say so on the calls.

The European Sovereign Cloud went GA on January 15, 2026 in Brandenburg, Germany with about 70-90 services in scope. SES was not on that list. AWS may add SES to the ESC roadmap at some point — they have not announced a date — but as of May 2026, every SES email continues to route through the standard AWS regions, which means the CLOUD Act applies to your customer data regardless of whether you have your account in eu-west-1 (Ireland) or eu-central-1 (Frankfurt). For most teams, this is not a deal-breaker. For teams in regulated industries (financial services, healthcare, public sector) or for teams whose DPO has flagged the issue post-Schrems II, it is becoming one.

The underlying issue is structural rather than technical. Multiple independent analyses through 2025-2026 have argued that even the ESC itself remains exposed to CLOUD Act compellation because the controlling ownership is still American — Microsoft's French subsidiary admitted exactly that under oath at the French Senate in June 2025. For teams whose sovereignty story needs to survive a procurement-level audit (BSI C5 registration deadline was March 6, 2026, with penalties up to €10M or 2% of global revenue), we are a clean answer because we are EU-incorporated in Sweden with no US parent.

Domain reputation transfers. IP reputation does not. Your sender reputation at Gmail, Yahoo, and Microsoft is tied to the combination of sending IP and From: domain — when your traffic starts flowing through our IPs but the same From: domain, receivers see "this domain has historical engagement, but the IP is new." That is exactly the warmup signal Gmail's Postmaster Tools v2 expects, and the 14-day warmup curve we run is calibrated to it.

What does not transfer is any IP reputation you may have built on SES dedicated IPs. If you were on SES dedicated IPs and you decide to keep those IPs via BYOIP into our infrastructure, that is technically possible but rarely the right answer (the 256-IP BYOIP minimum makes the math difficult, and dedicated-IP reputation does not move cleanly between providers in any case). Most teams accept the 14-day warmup and emerge with better placement than they had on SES dedicated, mostly because the new IPs are warmed against engagement-first traffic rather than mixed pool history.

SES customers typically use SNS topics to fan out bounce, complaint, and delivery events to Lambda functions, SQS queues, or downstream applications. Our webhook model replaces SNS with direct HTTPS POSTs to the endpoint of your choice, with retry and exponential backoff handled on our side. The payload format is close to but not identical to the SES SNS message structure — we publish the schema mapping during week 1 of the migration so your Lambda functions can be updated alongside the parallel-run phase.

For teams who want to keep the SNS-based event flow even after migration (some have downstream consumers that are tightly coupled to that pattern), the workaround is to point our webhooks at an API Gateway endpoint that fans out to SNS internally. This works but adds latency and an extra cost line. Most teams use the migration as an opportunity to simplify by going webhook-direct.

Mail Manager is one of the SES features that is genuinely strong, and we are not going to pretend our inbound parsing matches it. Ingress endpoints, the rule engine, archive add-ons, and virus scanning via Trend Micro are a deeper stack than we ship. If inbound is core to your application, three paths work: keep SES for inbound only (it has no monthly minimum, so the running cost stays small), pair us with a dedicated inbound service (CloudMailin and Postmark Inbound both work cleanly alongside our outbound), or build directly on Postfix at the application layer.

We typically recommend option one for the first 6-12 months post-migration. Outbound traffic moves to us, inbound continues to run on SES while the team observes outbound performance. After steady state, the team decides whether to keep the split or consolidate. There is no operational reason to force inbound migration on the same timeline as outbound.

No, if the SES-specific glue is unwound carefully. Most teams that ran SES also run S3, Lambda, RDS, or other AWS services from IAM policies that may or may not include SES-scoped permissions. We have seen migrations where a junior engineer "cleaned up the SES IAM policy" by deleting too much and broke an unrelated service for two days. Our week 5-8 cleanup phase is specifically about avoiding that pattern.

The migration itself only touches the application-level email integration, the DNS records, and the SES configuration sets on AWS. Nothing in your S3, EC2, RDS, Lambda, or VPC layer changes. The AWS account stays open, the SES service stays enabled (it costs nothing to leave it enabled when traffic is at zero), and the migration is fully reversible up to the point you delete configuration sets and revoke API keys. Most teams take 60-90 days after full cutover before doing the cleanup, which is conservative on purpose.

Month-to-month on standard plans with 30-day notice for cancellation. Annual contracts get a 10-15% discount for teams that want pricing certainty, but the annual is always optional and we never lead with it. The SES no-contract pay-as-you-go elasticity is something we cannot fully replicate — we have a monthly tier — but the practical difference is small for any team with steady volume.

During the migration project specifically, the first 60 days are structured so you can route back to SES at any time. We do not lock anyone in during the validation period. If the new infrastructure does not meet your standards, the application-level feature flag puts you back on SES in minutes and you owe us only the pro-rated month-to-month cost.