AWS SES Marketing Automation with EventBridge and Step Functions (2026)

Migrating off Elastic Email, Resend Audiences, or a mid-market ESP often stalls on one question: who builds the journeys after the send API moves to Amazon SES? SES does not ship a drag-and-drop automation builder. As of July 21, 2026, SES pricing plans (Essentials / Pro / Enterprise) change how you buy dedicated IPs and Virtual Deliverability Manager — they do not add a marketer UI.

This guide is for platform engineers choosing among build (EventBridge + Step Functions + SES), buy (Customer.io / Loops / Klaviyo / Braze), and hybrid. Companion reading: SES for eCommerce, Elastic Email → SES, Resend → SES.

SES marketing automation on AWS means product events on EventBridge, journey orchestration in Step Functions, contact state in DynamoDB/RDS, and sends through SES configuration sets — with RFC 8058 unsubscribe and mailbox-provider bulk-sender rules treated as production requirements, not backlog polish.

Build vs Buy vs Hybrid (Opinionated)

We recommend hybrid for most product-led companies: marketer journeys on a purpose-built automation tool, SES for transactional and any promo volume where ESP unit economics break. Pure build wins when engineering already owns the contact model and marketers accept YAML/JSON journey changes (or you invest in an internal admin). Pure buy wins when weekly journey edits matter more than per-1k send cost.

Reproduce this — Use the journey architecture checklist to force an explicit build/buy/hybrid decision before writing the first state machine.

Reference Architecture

Product app / warehouse
        │  events (UserSignedUp, CartAbandoned, OrderPlaced)
        ▼
   EventBridge bus ──► rules ──► Step Functions (per journey family)
                                      │
                                      ├─ Wait / Choice / Parallel
                                      ├─ DynamoDB get/put (suppression, step state)
                                      ▼
                              SES SendEmail (config set: lifecycle|promo)
                                      │
                    bounce/complaint/open/click events
                                      ▼
                         SNS / EventBridge ──► suppression + journey flags

Quantified design constraint we use on checklists: treat one state machine per journey family (welcome, abandoned cart, win-back) — not one machine with 40 branches. Operational blast radius stays reviewable; a failed welcome definition does not block cart recovery deploys.

Why EventBridge + Step Functions (not cron + Lambda only)

• EventBridge gives durable, filterable ingestion and partner integrations without custom queue glue for every producer.
• Step Functions makes waits, retries, and human-readable execution history first-class — critical when a cart wait is 1–72 hours, not “sleep in Lambda.”
• SES stays a dumb, cheap, observable send primitive with configuration-set isolation.

Deliverability Requirements the Builder Must Own

Mailbox providers do not care that your journey is “serverless.”

1. SPF + DKIM + DMARC with alignment (Google/Yahoo Feb 2024; Microsoft May 5, 2025 for Outlook consumer bulk).
2. RFC 8058 List-Unsubscribe + List-Unsubscribe-Post on marketing/lifecycle mail.
3. Stream isolation — transactional vs lifecycle vs promo configuration sets; dedicated/managed DIPs when promo volume can poison txn reputation.
4. Suppression before send inside the state machine — never “send then clean.”
5. Plan-aware IP economics — a-la-carte DIPs ~$24.95/IP or managed DIP fees; Pro may undercut a packed a-la-carte stack (pricing plans).

Label complaint ceilings correctly: SES ~0.1% complaint risk vs Gmail Postmaster spam <0.10% vs published bulk-sender <0.3% guidance.

What broke (common DIY failure) — Teams port ESP automations into a single Step Functions definition, forget idempotency keys on EventBridge retries, and double-send abandoned-cart mail. Complaint rate spikes; SES still “works.” Fix: idempotency on event IDs + suppression check as a required state before SendEmail.

First-Party Artifact: Journey Checklist

The checklist encodes decision, identity/streams, event ingestion, orchestration, send path, feedback loop, and go-live — including a shadow-run gate that blocks SES until QA signs off. That is the reproducible outcome: a binary readiness gate you can attach to a PR, not a synthetic open-rate claim.

Monday Morning Path

1. Complete the journey architecture checklist.
2. If build: scaffold one abandoned-cart state machine with Wait + suppression + SES; shadow-run without send.
3. If hybrid: move only transactional to SES this sprint; leave marketer journeys on the ESP until auth domains are aligned.
4. If promo volume needs DIPs/VDM: run the plan vs a-la-carte worksheet.
5. For retail promo vs txn isolation patterns, see SES for eCommerce.

What This Post Doesn’t Cover

• Pixel-perfect parity with Klaviyo/Braze visual builders
• Full CDK/Terraform modules for every journey (checklist first; IaC follows your account standards)
• Consent / GDPR legal determinations
• Cold outbound compliance (see SES B2B cold outreach)

Services: Amazon SES · SES migration.

Discuss your SES automation architecture →