AWS SES Global Endpoints (MREP): The Enterprise Decision Guide

On December 11, 2024, AWS shipped SES Global Endpoints — multi-region sending resilience for SES API v2 workloads (API changelog, Messaging blog). In 2026, the picture is richer: Tenant Management for per-tenant reputation isolation, tenant-level suppression lists (June 2026), and VDM global deliverability (May 2026) all interact with how you design multi-region email.

This guide is for CTOs, platform engineers, and email infrastructure owners deciding whether to pay the $0.03/1,000-email MREP surcharge (SES pricing), how to replicate regional resources correctly, and when Tenants add value beyond configuration sets. It is not a SendGrid migration tutorial — see How to Migrate from SendGrid to Amazon SES for that path.

Artifacts: MREP readiness checklist, resource replication matrix, TCO worksheet, failover test runbook, tenant vs config set matrix.

Benchmark pattern (not a cited client) — API v2 transactional sender, 2M emails/month, us-east-1 + us-west-2 MREP, mixed OTP and receipts. Failover drill per failover-test-runbook.md: secondary absorbed 100% traffic in 47s after simulated primary impairment; +$60/mo MREP surcharge vs regional-only at 2M volume (worksheet).

Executive Summary

SES Global Endpoints distribute outbound API v2 traffic across two AWS Regions in an active-active configuration. AWS creates a Multi-Region Endpoint (MREP) with an Endpoint ID you pass to SendEmail / SendBulkEmail. If either region degrades, SES shifts weight to the healthy region without customer-run failover scripts.

What you gain: regional resilience, simplified DR for email sending, unified cross-region metrics.

What you pay: $0.03/1k MREP surcharge, duplicated operational overhead (identities, config sets, quotas, IPs), API v2 requirement, and honest complexity in event aggregation.

What we recommend: Enable MREP for Tier-1 transactional paths (OTP, receipts, password reset) when you already send via API v2 and can keep both regions warm. Skip MREP for low-volume or SMTP-only stacks. Add Tenant Management when you send on behalf of many customers or business units — not for single-brand enterprises.

Reference architectures: draw.io files in repo docs/aws-ses-mrep-active-active-architecture.drawio and docs/aws-ses-mrep-tenants-combined.drawio.

Why SES Needed Multi-Region Sending

Before December 2024, SES sending was single-region per workload. If us-east-1 impaired, you waited for AWS recovery or ran bespoke DR: pre-warmed IPs in a second region, DNS flips, cron jobs rewriting endpoints, and hope your deliverability survived the asymmetry.

Enterprise requirements that broke the old model:

• OTP and auth email tied to login SLAs — a regional outage blocks revenue
• Banking and healthcare notification windows with regulatory delivery expectations
• SaaS platforms where email downtime becomes a P1 across all tenants
• Black Friday / exam-day spikes where you cannot afford a multi-hour send freeze

AWS’s answer is not “run two independent SES stacks yourself.” Global Endpoints centralize routing, health detection, and traffic weighting behind one MREP ID, while console tooling duplicates configuration sets, identities (with DEED), and quota alignment workflows.

What broke — Teams that built manual dual-region SES before MREP often kept cold standby secondary IPs. On failover, sudden volume on unwarmed IPs triggered ISP throttling worse than the original outage. MREP forces both regions active under normal load — the right default for reputation, but it means you pay for warm IPs in two places.

What Are AWS SES Global Endpoints (MREP)?

Terminology

Architecture components

1. MREP resource — entry point for API v2 sends (endpoint-id parameter)
2. Primary SES region — hosts management APIs for the MREP
3. Secondary SES region — peer region with mirrored send configuration
4. Health monitoring — AWS detects regional impairment and adjusts routing weights
5. Cross-region metrics — unified send volume view in SES console

Supported access patterns

MREP states

CREATING → READY | FAILED | DELETING (CreateMultiRegionEndpoint API)

Region availability

Global Endpoints are available in commercial regions where SES outbound sending is offered. You choose primary (console login region) and secondary at creation time.

How MREP Works Internally

Request flow

sequenceDiagram
    participant App
    participant MREP as MREP_DNS
    participant Primary as SES_Primary
    participant Secondary as SES_Secondary
    participant ISP as MailboxProvider
    App->>MREP: SendEmail with endpoint-id
    MREP->>Primary: ~50% traffic
    MREP->>Secondary: ~50% traffic
    Primary->>ISP: Deliver
    Secondary->>ISP: Deliver
    Note over MREP,Secondary: On impairment weight shifts to healthy region

1. Application calls SES API v2 with endpoint-id set to MREP ID
2. MREP layer routes to primary or secondary SES send path
3. Under normal conditions, traffic splits approximately 50/50
4. SES in each region uses that region’s identities, IPs, and config sets
5. Delivery proceeds to mailbox providers through standard SES egress

Active-active behavior

MREP is not active-passive cold standby. AWS expects both regions to send regularly to preserve IP reputation and deliverability. You may still choose hybrid routing at the application layer: OTP via MREP, newsletters via regional endpoint only (AWS re:Invent session guidance).

Failure detection and failover

When SES detects degradation in either region, it weights traffic away from the impaired region toward the healthy one until recovery. This is automatic — no customer DNS flip for the MREP itself.

Customer responsibilities that still matter:

• DNS caching on your clients — MREP publishes routing weights through DNS; set JVM networkaddress.cache.ttl=60 and HTTP connection TTL ~60s (AWS best practices)
• Secondary quota sized for 100% volume
• Identical identities and configuration sets in both regions

DNS and endpoint lifecycle

Long-lived HTTP connections pin to resolved IPs. Without connection rotation, your app may keep sending to a degraded path after AWS has shifted MREP weights. Treat connection pooling as part of the HA design, not an afterthought.

Regional Resource Replication Requirements

Console duplication follows a fixed order (AWS docs):

1. Configuration sets
2. Verified domain identities
3. Production limits (Service Quotas)

Summary matrix

Full matrix: resource-replication-matrix.md.

Expert tip — Run Check differences in the console after every duplication batch. Drift between regions is the top cause of “failover succeeded but events disappeared.”

When Should You Use MREP?

Opinionated take: We recommend MREP for Tier-1 API v2 sends and regional endpoints for everything else in the same account. AWS explicitly supports mixing — you are not forced to pay the surcharge on every email.

Pricing and TCO Analysis

Published rates (verify on SES pricing)

MREP surcharge is 30% of base send price — AWS frames it as reliability premium (re:Invent session).

TCO scenarios (from worksheet)

Hidden costs

• Duplicated dedicated IPs in two regions
• NAT gateway egress if apps in one region send through MREP to distant region
• Dual event pipelines (SNS/Lambda/Firehose per region) unless you aggregate
• Engineering time for duplication, drift detection, failover drills

Reproduce this — Open mrep-tco-worksheet.csv, plug your volume and IP count, compare combined_send_monthly_usd vs regional_only row.

Advantages

• High availability without custom failover Lambdas
• Automatic regional failover on impairment
• Active-active keeps IPs warm in both regions
• Simplified app integration — one endpoint-id parameter
• Cross-region metrics in one console view
• Coexists with regional sends for non-critical mail
• DEED reduces DNS toil for Easy DKIM domains

Downsides (Honest)

• API v2 only — SMTP shops must migrate first
• Resource duplication — identities, config sets, tenants, IPs
• Operational complexity — drift, quotas, event aggregation
• Cost surcharge on every MREP-routed message
• Testing complexity — failover drills, DNS TTL tuning
• Not three regions — exactly two regions per MREP
• Manual gaps after console duplication (event destinations, BYODKIM, MAIL FROM)

Things to Consider Before Enabling MREP

Use mrep-readiness-checklist.md:

• Sending quotas aligned for full failover
• Easy DKIM parent domains for DEED
• Configuration set event destinations replicated
• Dedicated IP warm-up in both regions
• IAM CreateServiceLinkedRole for ses.amazonaws.com
• CloudWatch alarms on ses:multi-region-endpoint-id
• Compliance review if secondary region crosses residency boundaries
• Application HTTP client DNS and connection TTL configured

Step-by-Step Enterprise Implementation Guide

Phase 1 — Planning

1. Inventory all send paths (API v2 vs SMTP)
2. Pick primary + secondary regions (latency-balanced vs app)
3. Classify email tiers (Tier-1 → MREP candidate)
4. Document current quotas, IPs, identities, config sets

Phase 2 — Primary region hardening

1. Exit sandbox; verify all domains (Easy DKIM preferred)
2. Create configuration sets with event destinations
3. Provision and warm dedicated IPs if used
4. Enable VDM if you rely on inbox placement metrics

Phase 3 — Create MREP

# AWS CLI — primary region session
aws sesv2 create-multi-region-endpoint \
  --endpoint-name txn-global-prod \
  --details RoutesDetails='[{Region=us-west-2}]' \
  --region us-east-1

Retrieve Endpoint ID:

aws sesv2 get-multi-region-endpoint \
  --endpoint-name txn-global-prod \
  --region us-east-1

Phase 4 — Duplicate to secondary (console order)

1. Duplicate configuration sets → fix event destinations manually
2. Duplicate identities → verify DEED auto-verification
3. Align production limits in Service Quotas

Phase 5 — Application integration

aws sesv2 send-email \
  --region us-east-1 \
  --from-email-address "noreply@example.com" \
  --destination "ToAddresses=user@example.com" \
  --endpoint-id "abcdef12.g3h" \
  --configuration-set-name "txn-prod" \
  --content "Simple={Subject={Data=Receipt,Charset=UTF-8},Body={Text={Data=Thanks,Charset=UTF-8}}}"

SDK example (conceptual): set EndpointId on SendEmailRequest in boto3 / AWS SDK v2.

Phase 6 — Monitoring and testing

• Cross-region metrics tab in SES console
• CloudWatch dimension ses:multi-region-endpoint-id
• Execute failover-test-runbook.md

Phase 7 — Production rollout

1. Canary 1% traffic with endpoint-id
2. Ramp over 48–72 hours; watch bounce/complaint parity across regions
3. Document rollback: remove endpoint-id → regional sends resume

IaC and deployment pipelines

Treat secondary region resources as first-class in your pipeline, not a one-time console action.

CloudFormation — AWS::SES::MultiRegionEndpoint creates the MREP; AWS::SES::ConfigurationSet and AWS::SES::EmailIdentity should be deployed to both regions via stack sets or separate regional stacks. Parameterize region so the same template deploys to primary and secondary with identical names.

AWS CDK — Use ses.CfnMultiRegionEndpoint in the primary stack; instantiate ses.CfnConfigurationSet and ses.CfnEmailIdentity in two RegionAwareStack constructs. Wire CI to fail if DescribeConfigurationSet output differs between regions.

Terraform — aws_sesv2_multi_region_endpoint plus duplicated aws_sesv2_configuration_set and aws_sesv2_email_identity resources. Run terraform plan in both region workspaces before MREP cutover.

CI/CD gates:

1. sesv2 get-multi-region-endpoint status = READY
2. Identity count parity primary vs secondary
3. Configuration set names match
4. Service Quotas sending limit secondary ≥ primary
5. Synthetic send with endpoint-id in staging

Monitoring deep dive

SES console — Global Endpoints → your endpoint → Cross-region metrics tab (up to 31 days).

CloudWatch metrics — Dimension ses:multi-region-endpoint-id on namespace AWS/SES. Metrics include send counts aggregated across the MREP. Pair with regional Reputation.BounceRate and Reputation.ComplaintRate in each region.

Alarms we set on engagements:

Event aggregation pattern — SNS topics are regional. Options:

1. Duplicate subscribers in both regions feeding one Lambda/SQS in a hub region
2. Firehose per region → S3 → Athena for analytics
3. EventBridge cross-region buses (event patterns)

Include tenantName in event payloads when using Tenants so aggregated dashboards can filter.

Disaster recovery narrative

MREP addresses regional SES impairment, not:

• Account-level sending pause for policy violations
• Domain blacklisting at major ISPs
• Application bugs generating bad sends
• DNS failures on your public DKIM/SPF records (DEED helps cross-region DKIM tokens, not your DNS hosting outage)

Your DR runbook should list MREP as one layer alongside suppression list hygiene, Gmail Postmaster monitoring, and customer-facing SLO design for email delivery.

Deliverability implications

Keeping both regions active is a feature, not overhead — ISPs see consistent volume from both IP pools. Failing to send through secondary during normal operations means failover looks like a sudden IP cold start.

Dedicated IP strategy:

• Provision IPs in both regions before MREP production cutover
• Run parallel warm-up schedules (AWS automatic warm-up or custom ramp)
• Map configuration sets to region-local IP pools
• Do not share marketing IPs with transactional pools

VDM integration — With global deliverability (May 2026), enable VDM in both regions to compare inbox placement and blocklist status per region. Divergence often precedes failover issues.

SES Tenant Management (2026)

AWS Tenant Management (Messaging blog) isolates reputation and enforcement per tenant (customer, brand, or business unit) inside one SES account — up to 10,000 tenants default, 300,000 on request.

Tenants vs configuration sets

Configuration sets route and measure. Tenants isolate and enforce. You typically use both: one config set per tenant (or tier), tenant wrapper for reputation policy.

When to use Tenants

• SaaS ESP sending for downstream customers
• Agency managing multiple brands
• Enterprise with LOBs that must not poison each other’s reputation
• June 2026 tenant-level suppression — complaints on tenant A should not suppress tenant B (docs)

When to avoid Tenants

• Single-brand company with one marketing + one transactional stream
• Low volume internal mail — configuration sets + IAM suffice
• Teams without automation to onboard/offboard tenant resources

Internal enterprise vs SaaS

Tenant lifecycle (CLI reference)

AWS CLI 2.28.0+ required for tenant APIs (tenant blog).

# Create tenant (us-east-1 example)
aws sesv2 create-tenant --tenant-name acme-corp --region us-east-1

# Associate identity
aws sesv2 create-tenant-resource-association \
  --tenant-name acme-corp \
  --resource-arn arn:aws:ses:us-east-1:111122223333:identity/acme.com

# Associate configuration set (with IP pool already linked)
aws sesv2 create-tenant-resource-association \
  --tenant-name acme-corp \
  --resource-arn arn:aws:ses:us-east-1:111122223333:configuration-set/acme-txn

# Send with tenant
aws sesv2 send-email \
  --from-email-address "billing@acme.com" \
  --destination "ToAddresses=user@example.com" \
  --tenant-name acme-corp \
  --configuration-set-name acme-txn \
  --content "Simple={Subject={Data=Invoice,Charset=UTF-8},Body={Text={Data=Attached,Charset=UTF-8}}}"

Reputation policies — standard (pause on high-severity findings) vs strict (pause on low-severity). Update via update-reputation-entity-policy.

Enforcement signals — Complaint rates, bounce rates, Spamhaus listings, volume anomalies. EventBridge delivers findings with tenant ID for automation (blog).

Reporting and governance

• Per-tenant dashboards — CloudWatch metrics scoped via configuration set per tenant
• Account governance — Parent account remains accountable to AWS for all tenants; monitor rogue tenants or risk account-level action
• IAM isolation — Condition ses:TenantName on send policies for application credentials
• Audit — CloudTrail sesv2:SendEmail with tenant context in request parameters

From a real engagement shape (anonymized) — Marketing automation platform at 200M+ emails/month (case study) used configuration-set separation and dedicated IPs before tenant APIs existed. Today’s tenant-level suppression (June 2026) would have reduced blast radius when one merchant’s list purchase polluted complaints — we now spec Tenants for comparable multi-merchant platforms at onboarding.

MREP + Tenants: Combined Architecture

Compatible. Recommended pattern for large ESP:

1. Create MREP once per environment
2. Create tenant per customer with dedicated config set + IP pool
3. Send with endpoint-id + tenant-name + configuration-set-name
4. Replicate tenants and associations in secondary region
5. Aggregate events with tenantName dimension into central analytics

Common mistakes:

• Tenants created only in primary — failover breaks tenant-scoped sends
• Shared IP pool across toxic and premium tenants — defeats isolation purpose
• Missing EventBridge rules for tenant reputation findings

See tenant-vs-configset-decision-matrix.md.

Security Best Practices

• Least privilege IAM — scope to identity ARNs + config sets + ses:TenantName
• Cross-region policies — duplicate or use condition keys carefully
• CloudTrail in both regions for sesv2:*
• Secrets Manager for API credentials; rotate on schedule
• KMS for BYODKIM signing keys with cross-region policy if shared
• No secrets in templates — use application-side rendering

Operational Best Practices

• Infrastructure as Code — CloudFormation/CDK/Terraform for config sets (MREP creation APIs exist; duplicate resources via IaC to prevent drift)
• Drift detection — weekly console “Check differences” or automated describe calls
• Quota dashboards — CloudWatch + Service Quotas alarms per region
• Unified event bus — Kinesis Firehose or EventBridge aggregation across regions
• Runbook — link failover drill to incident response (incident patterns)

Common Mistakes

1. Assuming MREP replaces regional resources — it does not
2. 50% quota in secondary — must handle 100% on failover
3. BYODKIM without secondary setup — DEED won’t help
4. Ignoring connection TTL — stale DNS breaks failover perception
5. Cold secondary IPs — reputation collapse on shift
6. Event destinations not replicated — blind during failover
7. SMTP assumption — MREP silently not an option
8. Tenants only in primary — partial HA illusion

Real Enterprise Architectures

Small SaaS (~500k/mo)

Regional SES in one region; config sets split marketing vs transactional. Skip MREP until OTP becomes SLA-bound.

Large SaaS / ESP (2M–50M/mo)

MREP for transactional + Tenants per customer + dedicated IP tiers. Marketing bulk via regional endpoint. Reference: TargetBay case study for scale patterns (regional; MREP is additive).

Healthcare

MREP for appointment and results notification; BAA-covered accounts; VDM for inbox placement. Pair with HIPAA Bedrock patterns discipline for PHI in templates — email body content is your compliance boundary.

Banking

MREP on fraud alert and OTP lanes; strict IAM; EventBridge tenant findings to SOC queue. Consider FinTech reference architecture for event-driven ops maturity.

Government

MREP only if multi-region authorized; watch data residency. May require GovCloud SES availability check per region pair.

Retail / e-commerce

MREP for order/shipping email; regional for campaigns. See e-commerce SES marketing.

Global enterprise

Multiple MREPs per environment (prod/stage) or per brand OU; centralized observability. Cross-link multi-region without doubling cost.

Internal platform team

Platform exposes email API to internal product teams. Use Tenants per product line if teams bring their own domains and reputation risk. Use shared tenant + config sets per app if central governance. MREP on shared transactional API gateway.

Customer communication platform

ISV white-labeling email for clients: Tenants mandatory; MREP on platform-wide send API; per-tenant onboarding automation (create-tenant, identity association, IP pool tier). Store tenant ARN in your product database for IAM policy generation.

Architecture diagram descriptions

Diagram 1 — Active-active MREP (docs/aws-ses-mrep-active-active-architecture.drawio):

• Application tier (Lambda/ECS) invokes SES API v2 with endpoint-id
• MREP fans out ~50/50 to us-east-1 and us-west-2 SES endpoints
• Each regional SES uses local dedicated IP pools and configuration sets
• SNS event destinations per region; CloudWatch cross-region metrics on MREP dimension
• Failover path: MREP shifts weight to healthy region → single regional SES absorbs 100%

Diagram 2 — MREP + Tenants (docs/aws-ses-mrep-tenants-combined.drawio):

• SaaS platform sends on behalf of Tenant A and Tenant B
• Each tenant owns config set, IP pool, and verified identity
• Shared MREP entry point for regional resilience
• EventBridge captures tenant reputation findings independently per tenant
• IAM policies scope credentials per ses:TenantName

Sequence — failover

sequenceDiagram
    participant App
    participant MREP
    participant Primary as PrimaryRegion
    participant Secondary as SecondaryRegion
    App->>MREP: SendEmail endpoint-id
    MREP->>Primary: 50% weight
    MREP->>Secondary: 50% weight
    Note over Primary: Regional impairment detected
    MREP->>Primary: 0% weight
    MREP->>Secondary: 100% weight
    App->>MREP: Subsequent sends
    MREP->>Secondary: All traffic until recovery

Decision Matrix

FactualMinds Expert Recommendations

1. MREP is essential when email downtime equals revenue or auth outage — and you already use API v2.
2. MREP is over-engineering below ~500k/mo unless compliance mandates it.
3. Tenants are valuable for SaaS and multi-brand; avoid for single-domain enterprises.
4. Hybrid routing — best cost/HA balance: MREP for OTP, regional for newsletters.
5. Migrate SMTP to API v2 before any MREP project — see SES Migration service.
6. Budget +$60/mo per 2M MREP-routed emails before executive approval (worksheet math).

Need hands-on help? Book a deliverability assessment or explore Amazon SES consulting.

Comparison: MREP vs Manual Multi-Region SES

Before December 2024, resilient SES architectures looked like this:

We recommend MREP over custom active-active when you are already on API v2 and can accept the surcharge. We recommend regional SES over DIY dual-region if you lack platform engineering capacity to keep two regions byte-identical.

MREP vs Global Accelerator / Route 53 health checks

Route 53 and Global Accelerator solve network path failover to application endpoints. They do not verify SES identity parity, IP warm-up, or sending quotas in a second region. MREP is SES-aware — it understands regional send impairment, not just TCP reachability to an API hostname.

Use Route 53 for your application API HA; use MREP for SES send HA. They complement each other when your mailer service runs in multiple regions but sends through one SES integration point.

Enterprise adoption phases

Regulated industries add 4–6 weeks for security review of secondary region and cross-region event data flows.

Compliance considerations

Latency and client placement

AWS notes fractional API latency increase when MREP routes to a distant region relative to your client. Mitigations:

• Place senders in a region equidistant to both SES regions when possible
• Use hybrid routing so latency-sensitive bulk does not traverse MREP unnecessarily
• Tune HTTP client timeouts — SES send is async from user perspective but batch workers care

Quota management during failover

When traffic consolidates to one region:

• Sending rate (messages/sec) may throttle before daily quota
• Request headroom in Service Quotas for both regions at max expected burst
• Monitor Throttling errors in CloudWatch during drills
• Pre-scale worker concurrency only after quota confirmation — app scale without quota is useless

Event collection architecture

Problem: Bounce and complaint events during failover must still reach suppression logic.

Pattern A — Dual SNS → single SQS

us-east-1 SNS (bounce) ──┐
                         ├──► SQS (hub) ──► Lambda suppress
us-west-2 SNS (bounce) ──┘

Pattern B — Firehose aggregation

Each region Firehose → S3 ses-events/ prefix → nightly suppression merge job.

Pattern C — EventBridge bus forwarding

Regional buses forward to central bus with detail.region attribute.

For Tenants, ensure handlers read tenantName from event JSON (June 2026 tenant suppression APIs accept TenantName on suppression CRUD).

Testing complexity

Minimum test matrix before production:

Migration from regional-only to MREP

1. Freeze identity and config set changes during cutover window
2. Deploy secondary region resources via IaC
3. Create MREP in staging; run parallel sends (shadow mode) comparing MessageIds
4. Enable endpoint-id on canary fleet (1%)
5. Increase to 100% over 72h if metrics stable
6. Keep regional endpoint code path for rollback 30 days

Extended FAQ

Architecture and behavior

Does MREP support more than two regions? No. One MREP pairs exactly one primary and one secondary region.

Is primary region preferred for traffic? No. AWS states primary vs secondary is a management distinction; traffic splits ~50/50.

Can I have multiple MREPs? Yes — e.g., per environment or per brand, each with its own endpoint ID.

Does MREP change my FROM address? No. You still send from verified identities in each region.

What API parameter activates MREP? endpoint-id on SendEmail and SendBulkEmail (API v2).

Does MREP work with SendRawEmail? Use API v2 raw content structures via SendEmail / SendBulkEmail with appropriate content blocks; classic SMTP-style SendRawEmail paths are not the MREP integration surface.

What happens to dedicated IPs during failover? Traffic shifts to the healthy region’s IP pools. Both regions must maintain warmed IPs.

How fast is failover? AWS automates weight shifts; your app must refresh DNS and connections. Benchmark drill: 47s to full secondary absorption — your mileage varies.

Does MREP protect against account-level suspension? No. Bounce/complaint account pauses are per-region but policy is account-scoped. Tenants help isolate tenant-level issues.

Can I use MREP in GovCloud? Check current SES region availability; MREP requires SES sending in both selected regions.

Configuration and replication

Does console duplication copy SNS topics? No. Event destinations referencing regional SNS need manual secondary setup.

Are email templates duplicated automatically? No. Duplicate templates if sends reference them.

What about contact lists? Manual. Not part of MREP duplication workflow.

Does DEED work for subdomains? Parent domain must use Easy DKIM; follow AWS identity hierarchy guidance.

Can I use different MAIL FROM per region? Yes, but configure manually in secondary after duplication.

What if configuration sets differ between regions? Risk delivery failures and missing metrics. Use Check differences.

Do suppression lists sync? Account suppression is per-region. Tenant suppression (2026) is per-tenant per-region — design accordingly.

Is VDM required? No, but recommended for inbox placement visibility (VDM global deliverability).

Tenants

How many tenants can I create? 10,000 default; 300,000 with AWS request.

Can one tenant share an IP pool with another? Possible but weakens isolation — prefer dedicated pools for premium tiers.

How do I pause one tenant? update-reputation-entity-customer-managed-status with DISABLED or automated policy on findings.

SMTP with tenants? Set X-SES-TENANT header (tenant blog).

Do tenants replicate with MREP duplication? No. Manual tenant setup in secondary.

Tenant vs configuration set for marketing/transactional split? Config set split suffices for single brand; Tenants when reputation must not cross customers.

Pricing and operations

If I remove endpoint-id, do I still pay MREP surcharge? No. Surcharge applies only to sends through MREP ID.

Is there a fee to create MREP? No separate creation fee — per-message surcharge only.

Do I pay double dedicated IP fees? Yes — IPs are per region.

NAT egress on cross-region MREP routing? Possible. Model in worksheet nat_egress_estimate_usd.

How do I monitor MREP traffic split? SES console Cross-region metrics; CloudWatch ses:multi-region-endpoint-id.

Can CloudFormation create MREP? AWS::SES::MultiRegionEndpoint — use IaC for repeatability.

Terraform resource? aws_sesv2_multi_region_endpoint (provider version dependent — pin and validate).

Rollback strategy? Remove endpoint-id from app config; regional endpoints continue working.

Compliance: does email leave the secondary region? Sending executes from both regions; ensure secondary region meets residency rules.

What to Do This Week

Implementation checklist

• Confirm API v2 send path (no SMTP dependency for MREP candidates)
• Run mrep-readiness-checklist.md
• Model cost in mrep-tco-worksheet.csv
• Create MREP in staging; duplicate config sets → identities → quotas
• Configure DNS/connection TTL on senders
• Execute failover drill runbook
• Decide Tenants vs config-sets-only via decision matrix

Decision checklist

• Is email Tier-1 for SLA? If no → defer MREP
• Is volume >500k/mo or regulatory pressure? If no → defer
• Can secondary region hold 100% quota? If no → fix quotas first
• Are you multi-tenant? If yes → evaluate Tenants
• Will you keep both regions actively sending? If no → fix IP strategy first

Migration checklist (regional → MREP)

• Inventory SMTP dependencies → plan API v2 migration
• Align Easy DKIM on all domains
• Export configuration set definitions to IaC
• Create secondary region resources before cutover
• Canary endpoint-id on staging
• Production ramp with rollback tested

Operational readiness checklist

• CloudWatch dashboards per region + MREP dimension
• Event aggregation pipeline tested from both regions
• Drift detection scheduled weekly
• Incident runbook links failover steps
• Executive sign-off on +$0.03/1k surcharge

What This Post Doesn’t Cover

• Inbound email / Mail Manager receiving paths — MREP is outbound API v2 only
• Pinpoint vs SES product selection
• Third-party ESP comparison beyond SES economics — see SendGrid to SES
• Full SMTP → API v2 migration — covered in migration guide
• Exact tenant feature pricing lines — verify SES pricing at deploy time
• GovCloud-specific MREP region pairs — validate against your AWS account partition

Official AWS references: Global endpoints guide · CreateMultiRegionEndpoint · SES pricing · Global Endpoints blog · Tenant Management blog