Amazon SES Regions Explained: How to Pick the Right One in 2026

Amazon SES is available in 29 AWS regions worldwide. Outbound pricing is a flat $0.10 per 1,000 emails everywhere, per the AWS SES pricing page, so cost is not how you pick. What varies is feature parity, recipient latency, and the regional reputation pool you join when you start sending. The right answer for most senders: pick the region closest to your recipients first, your other AWS infrastructure second, and check feature parity third.

This is a reference post for AWS SES practitioners who need to make a region decision before turning on traffic. Disclosure: Mailblast is a hosted management layer on top of your own Amazon SES account, so we have a lot of customers asking exactly this question during setup.

Where Amazon SES is actually available

Amazon SES publishes sending endpoints in 29 AWS regions, including two GovCloud regions, per the SES endpoints and quotas reference. The footprint covers all major commercial regions in North America, Europe, Asia Pacific, South America, the Middle East, and Africa - but feature parity is uneven. Some newer regions ship without SMTP endpoints or inbound receiving, and SES has a small set of region-specific DKIM domains you need to know about before you publish DNS.

Region code	Location	Price / 1k	SMTP	Inbound	Notes
us-east-1	N. Virginia	$0.10	✓ Yes	✓ Yes	Largest pool, broadest feature set, FIPS endpoints
us-east-2	Ohio	$0.10	✓ Yes	✓ Yes	FIPS endpoints
us-west-2	Oregon	$0.10	✓ Yes	✓ Yes	FIPS endpoints, common AWS default
eu-west-1	Ireland	$0.10	✓ Yes	✓ Yes	Largest EU SES region
eu-central-1	Frankfurt	$0.10	✓ Yes	✓ Yes	EU data residency, mature feature set
eu-west-2	London	$0.10	✓ Yes	✓ Yes	UK data residency
eu-south-1	Milan	$0.10	✗ No	✓ Yes	Region-specific DKIM domain
eu-central-2	Zurich	$0.10	✗ No	✗ No	Region-specific DKIM domain
ap-southeast-1	Singapore	$0.10	✓ Yes	✓ Yes	APAC default for SE Asia
ap-southeast-2	Sydney	$0.10	✓ Yes	✓ Yes	ANZ default
ap-northeast-1	Tokyo	$0.10	✓ Yes	✓ Yes	Japan default
ap-south-1	Mumbai	$0.10	✓ Yes	✓ Yes	India default
sa-east-1	São Paulo	$0.10	✓ Yes	✓ Yes	South America default
ca-central-1	Canada Central	$0.10	✓ Yes	✓ Yes	FIPS endpoints
af-south-1	Cape Town	$0.10	✗ No	✓ Yes	Region-specific DKIM domain
me-central-1	UAE	$0.10	✗ No	✗ No	Region-specific DKIM domain
us-gov-west-1	GovCloud (US-West)	$0.10	✓ Yes	✗ No	FedRAMP workloads only

The full SES region count includes additional Asia Pacific regions (Hyderabad, Jakarta, Malaysia, Osaka, Seoul), Europe (Paris, Stockholm), Middle East (Bahrain), Israel (Tel Aviv), and US West (N. California), Canada West (Calgary), and the second GovCloud region.

How AWS region affects deliverability

Region selection shapes deliverability in one specific way: each AWS region maintains its own sending IP pool and its own reputation history with mailbox providers. AWS confirms in its SES service quotas documentation that sending limits are tracked "per Region" - which is the operational tell that reputation is also scoped per region. Open the same account in two regions and you have two independent senders from Gmail's perspective.

In practice this means three things. First, warmup is per region. If you have a clean year of sending from us-east-1 and you spin up eu-west-1 to reduce latency to European recipients, that European traffic starts from zero reputation and needs a fresh warmup ramp. Second, a single bad campaign in one region cannot poison another region's reputation directly, which is occasionally useful as a containment strategy. Third, the size of the regional IP pool matters: us-east-1 is the largest SES region by traffic, so its shared IPs are seen by mailbox providers more often, which is generally a small reputation advantage if your own sender behavior is clean.

If you are on shared IPs, this means region selection partially determines which neighborhood you live in. If you are on dedicated IPs - including the newer Managed Dedicated IPs product - reputation belongs entirely to your IPs, and the region effect collapses to latency and feature availability.

Region pricing

Amazon SES outbound pricing is $0.10 per 1,000 emails in every commercial region, with no per-region surcharge, per the SES pricing page. Inbound email receiving is also $0.10 per 1,000 emails. The one pricing line that touches geography is the multi-region Global Endpoint, which adds $0.03 per 1,000 emails on top of the base rate when you route sends through it - and that fee applies only when you opt in.

There are two pricing lines that look like they might vary regionally but do not: data transfer out and attachment overage. Both are uniform across SES regions. If you want a full breakdown of the SES bill, including dedicated IP costs and the free tier rules for EC2-originated traffic, see our Amazon SES pricing guide.

Feature parity

Outbound sending works in every SES region, but several features have a smaller footprint. SMTP endpoints are not available in 10 newer regions (Cape Town, Hyderabad, Jakarta, Malaysia, Milan, Zurich, Tel Aviv, Bahrain, UAE, Calgary), per the AWS SES endpoints reference - if your app sends via SMTP rather than the API, those regions are off the table. Email receiving is missing in six regions (Hyderabad, Malaysia, Zurich, UAE, and both GovCloud regions). FIPS endpoints exist in the four US regions, both Canadian regions, and both GovCloud regions. And eleven regions use a region-specific DKIM domain (dkim.<region>.amazonses.com) rather than the default dkim.amazonses.com, which affects your DNS publishing workflow.

Two features are worth checking the console for before you commit to a region: Managed Dedicated IPs and Virtual Deliverability Manager. AWS adds regions to both regularly, so the list moves. If either is part of your deliverability plan, verify it exists in your candidate region before you start verifying identities.

How to choose a region

The decision framework is short. Pick the region closest to your recipients, then the region closest to your other AWS infrastructure, then check feature parity. Cost is not in the list because it does not vary. Here is how to apply that in practice.

Recipients first, by majority share. SES sends from AWS-owned IPs in the region you pick. The TCP path from the SES region to the recipient mailbox provider's MX adds latency to every send. For a US-recipient list, us-east-1 or us-east-2 keeps SMTP handshakes short. For European recipients, eu-west-1 or eu-central-1. The latency cost of cross-region sending is small in absolute terms - tens of milliseconds - but it compounds over millions of sends and shows up in SMTP timeouts on slow links. If you have a balanced multi-region recipient base, the Global Endpoint exists for exactly this case, at the $0.03 per 1,000 surcharge.

Your other AWS infrastructure second. If your application stack runs in eu-west-1 and you call SES from EC2, Lambda, or ECS in the same region, you stay inside AWS's network for the API call and avoid public-internet egress. AWS also exempts EC2-originated traffic from a portion of the SES free tier under specific conditions. Putting SES in a region where your app does not already live means you are paying for cross-region data transfer to push the message payload to SES.

Feature parity third. If you need FIPS endpoints, you are in the US regions (us-east-1, us-east-2, us-west-1, us-west-2), the Canadian regions (ca-central-1, ca-west-1), or GovCloud. If you need SMTP, you have 19 regions to choose from, not 29. If your deliverability plan includes Virtual Deliverability Manager or Managed Dedicated IPs, check the console - those product footprints grow over time.

Data residency as a hard constraint. EU customer data needs to stay in EU regions. UK data residency suggests eu-west-2. Public-sector US workloads under FedRAMP belong in a GovCloud region. These constraints override the latency and infrastructure rules. If you are new to setting all of this up, our Amazon SES setup walkthrough covers identity verification and production access for whichever region you land on.

Moving between regions

There is no in-place migration for SES. Moving from one region to another means re-doing the entire setup: verify every sending domain in the new region, publish a new set of DKIM records (and check whether your new region uses the default dkim.amazonses.com or a region-suffixed domain), re-create configuration sets and event destinations, request production access from the new region's sandbox, and warm up sending volume from zero. AWS confirms in the production access documentation that production access is granted per region, which means you are starting the support-ticket clock over.

The warmup is the expensive part. If you send 5 million emails a month on a healthy reputation in us-east-1, you cannot turn on 5 million a month in eu-west-1 on day one. Mailbox providers throttle new IP-domain pairs aggressively for the first two to four weeks. A realistic warmup ramp moves through 50, 100, 500, 1,000, 5,000, 10,000, 50,000 per day before approaching your normal volume. Plan four to six weeks of dual-region sending if you are migrating production traffic, not cutting over.

The exception is if you stay on shared IPs and have low volume (under 50,000 emails per day). Shared-IP warmup is shorter because the pool already has reputation; you only need to establish your domain's sending pattern. But you still re-verify, re-publish DNS, and re-request production access.

When region selection actually matters operationally

For most senders, region selection is a one-time decision made during initial setup, and it stops mattering once you start sending. The exceptions are worth flagging because they are the cases where teams get burned.

The first case is the multi-region disaster recovery question. SES does not replicate identities, suppression lists, or configuration sets across regions. If your DR plan says "we fail over from us-east-1 to us-west-2 if there is an outage," you need to maintain a verified, production-access-granted, warmed-up secondary region all the time. That doubles your IP-warmup effort and means you should be sending a small percentage of traffic from the secondary region continuously to keep its reputation warm. The Global Endpoint is AWS's answer to this, but the $0.03 per 1,000 fee adds up at scale and you give up some control over which region a given send originates from.

The second case is regulated workloads. GDPR, HIPAA-aligned BAAs, FedRAMP - these are region-level decisions that the legal team makes, not the engineering team. Verify the legal requirement before you pick the region, because moving SES out of GovCloud or out of an EU region after the fact is a multi-week project.

The third case is bounce-rate isolation. Some teams deliberately run transactional mail in one region and marketing mail in another so that a marketing reputation hit cannot block password resets. This is overkill for most senders, but it is a legitimate use of SES's per-region reputation model. The trade-off is that you now manage two warmup ramps, two suppression lists, and two production-access tickets, which is a real ongoing operational cost.

FAQ

Does Amazon SES cost more in some regions?

No. AWS charges a uniform $0.10 per 1,000 outbound emails in every commercial SES region. The only region-related pricing line is the optional multi-region Global Endpoint, which adds $0.03 per 1,000 emails on top of the base rate when you route through it. Data transfer and attachment overage rates are also uniform across regions.

Can I share sending reputation between two SES regions?

No. Each AWS region operates its own pool of sending IPs and tracks reputation independently. A warmed, healthy account in us-east-1 has no reputation history in eu-west-1. If you start sending from a new region, you start a new warmup, even with the same verified domain and the same account.

Which SES region has the best deliverability?

Deliverability is driven by your sender behavior and the IP pool reputation, not the region label. That said, us-east-1 (N. Virginia) is the largest and oldest SES region, so its shared IP pools are more diverse and have the most established history with mailbox providers. For most senders, that makes it a sensible default unless data residency or latency dictate otherwise.

Is SES available in every AWS region?

Almost. As of 2026, SES sending endpoints exist in 29 regions including two GovCloud regions, per AWS documentation. A few feature gaps remain: SMTP endpoints are not yet available in 10 newer regions (Cape Town, Hyderabad, Jakarta, Malaysia, Milan, Zurich, Tel Aviv, Bahrain, UAE, Calgary), and email receiving is missing in six regions (Hyderabad, Malaysia, Zurich, UAE, and both GovCloud regions).

How do I move my SES setup to a different region?

You re-verify every domain identity, re-publish DKIM records (the DKIM domain differs in some regions - eu-south-1, eu-central-2, il-central-1, me-central-1, ap-south-2, ap-southeast-3, ap-southeast-5, ca-west-1, af-south-1, ap-northeast-3, us-gov-east-1 each use a region-suffixed DKIM domain), request production access again, and re-warm the new region's IP pool from scratch. There is no in-place migration.