DEV Community: Aaron Hunter

My Kids Couldn't Spell "Because," So I Built an App to Help

Aaron Hunter — Mon, 14 Sep 2026 21:31:33 +0000

I built a serverless handwriting-grading app for my own kids, and it turned into one of the most honest reliability projects I've worked on. This is the deep version... the event-driven internals, the throttling war story, and the reconciliation layer, straight out of the deployed code.

Every week my kids bring home a spelling list. And every week the same thing happened... they'd ace the open-book practice, then forget some words and write others incorrectly. Letters flipped. Words running together. "Because" spelled a different way every time they tried.

I'm an engineer, so I built a thing. It's called Bee Hunter, and I'll be straight with you... it taught me more about the sharp edges of event-driven systems than half the production services I've worked on. My son named it: "Bee" for spelling bee, "Hunter" because that's our last name. He was very proud, and I was too.

Here's the twist. My users are in elementary school. They don't file bug reports. When something's slow or broken, they do one thing... they quit and hand the phone back to go play Roblox. That one constraint changed how I thought about the whole system, and it's the thread running through everything below: the architecture, the stage-machine bug that became a Bedrock throttling storm, and the reconciliation layer that stitches two AI services together. Every snippet here is from the deployed functions.

What Bee Hunter does

A kid photographs a handwritten spelling test, and a few seconds later the app shows which words are spelled correctly, how legible each one is, and a cropped image of each word so you can see what they actually wrote. It runs serverless on AWS, scales to zero, and is cheap enough that a project for two kids doesn't turn into a bill I resent.

The architecture

A photo goes in, word-by-word feedback comes out:

Photo upload
   -> S3 (image storage)
   -> Textract         (OCR: finds WHERE the words are)
   -> Claude / Bedrock (reads WHAT the words say + scores them)
   -> Reconcile        (fuzzy-match the two together)
   -> Results          (crops + spelling + legibility scores)

The pieces: S3 + CloudFront for hosting and image storage, API Gateway + Lambda for the backend (14 small functions, one job each), Amazon Textract for bounding boxes, Amazon Bedrock (Claude Sonnet 4.5) to read and score the handwriting, and DynamoDB for submissions and results.

The flow: the browser uploads straight to S3 with a presigned URL. That fires an S3 event to beehunter-textract-processor, which runs Textract and writes a record to beehunter-textract-results stamped stage: 'textract_complete'. That write fires a DynamoDB stream to beehunter-claude-analyzer, the brain of the app: it reads the image, calls Bedrock, reconciles the two AI outputs, scores every word, and writes the final record to beehunter-results. The frontend polls GET /status/{id}, which checks results first and falls back to the textract stage for a progress message.

Two facts about that analyzer step set up the best bug in the project. First, it's a Lambda writing to DynamoDB tables that also have streams, and it emits its own claude_starting/claude_analyzing/complete write-backs so the poller can show progress. Every one of those is itself a stream event. Second, DynamoDB Streams deliver at-least-once, not exactly-once, so a record can hit your Lambda more than once and your function has to be idempotent. Hold both thoughts.

Two AI services that don't talk to each other

I'm using two AI services, and each is good at exactly half the job.

Textract nails where the words are. Pixel-perfect boxes, as fractions of the image. Here's a real spelling test one of my kids handed me:

One of my kids' actual spelling tests. "Ruler" gave everybody trouble.

And here's what Textract made of it:

Word	X	Y	W	H	Confidence
river	862	400	471	187	99.3%
meter	850	581	559	207	100%
paper	859	778	475	264	99.7%
tiger	859	1255	450	212	83.9%
number	890	1580	681	173	99.6%
ruler	1008	2057	475	179	34.4%
swerve	811	2840	613	181	84.1%
germ	873	3187	399	174	99.6%

Look at the coordinates. Dead-on, every time. Now look at "ruler": 34.4% confidence, because Textract actually read it as "Fuler." There's a particular kind of humbling in watching the app you built squint at your own kid's homework and guess wrong. It can't reliably read a kid's handwriting, and the messier the word, the worse it gets. The long ones a kid mangles a different way every time... "because" coming out becuase one week and becuse the next... are exactly where Textract's confidence craters.

Claude is the opposite. It reads the handwriting and understands intent. It knows the kid meant "ruler." But ask it for pixel coordinates and it tells on itself:

A couple notes: 
coordinates are eyeballed from the visual layout, not from an OCR bounding-box pass, so treat them as approximate anchor points. 
The two words I'd flag as less certain are "hermit" and "ruler" (the r is rough).

"Approximate anchor points" won't crop an image. So I need both. Claude's read for accurate feedback, Textract's boxes for the crop. The catch is they disagree about the same word:

Textract sees: "Fuler"  (34.4% confidence, but exact coordinates)
Claude sees:   "ruler"  (reads it right, no usable coordinates)
Target word:   "ruler"

"Fuler" == "ruler" is False. Naive exact-match drops the word, so you get no crop and no score. I need a reconciliation layer that connects Claude's read to Textract's coordinates even when the strings disagree.

Reconciliation is a three-tier cascade

For each word Claude reports, the analyzer tries three strategies in order and stops at the first hit.

Tier 1: exact match. Claude's word matches a Textract word case-insensitively, and that box isn't claimed yet. Cheap and unambiguous.

Tier 2: hardcoded special cases. Scars from watching real submissions. When one specific misread showed up often enough, I stopped being clever and just hardcoded it. Two are literally in the deployed code:

# "geam" should match "feam" (common g/f OCR error)
if written_word == "geam":
    feam_match = next((tw for tw in textract_words
                       if tw['text'].lower() == 'feam'
                       and tw['text'] not in used_textract_words), None)
    ...
# "him self" should match "him" + "self" and combine their boxes
elif written_word == "him self":
    ...
    min_left  = min(him_bbox['x'], self_bbox['x'])
    max_right = max(him_bbox['x'] + him_bbox['width'], self_bbox['x'] + self_bbox['width'])
    ...

The "him self" case is the interesting one. Claude reads two Textract tokens as one intended word, so I merge two boxes into one crop with min/max corners. Special-case tiers accumulate, and each one is a signal your general strategy has a blind spot. I keep these because they're cheap and they document real failures. A third or fourth would be pressure to go fix Tier 3 instead.

Tier 3: fuzzy match. Fall back to difflib.SequenceMatcher(...).ratio() between Claude's word and each unclaimed Textract word, keeping the best above a threshold:

FUZZY_MATCH_THRESHOLD = 0.5  # lowered from 0.6 for better word matching
similarity = difflib.SequenceMatcher(None, claude_word.lower(),
                                     tw['text'].lower()).ratio()
if similarity > best_similarity and similarity >= FUZZY_MATCH_THRESHOLD:
    best_match, best_similarity = tw, similarity

That 0.5, lowered from 0.6 comment is where the real work hides. SequenceMatcher.ratio() is brutally sensitive to length, so on the three- and four-letter words first graders get, a single bad character drops them under a 0.6 threshold and they vanish. Lowering to 0.5 buys them back; drop much lower and "the" starts matching "he" and stealing the wrong box. The used_words set threads through all three tiers so two of Claude's words can't claim the same box.

The subtle part: I grade Textract, not Claude

The most subtle decision in the app. When I compute the spelling score, I don't score Claude's corrected reading. I score Textract's raw detection:

# Use TEXTRACT detection (actual handwriting), not Claude's correction
actual_written_word = textract_match['text']
letter_accuracy, _ = calculate_letter_accuracy(
    actual_written_word,   # what the OCR literally saw
    match['target_word'],  # what it was supposed to be
)

Claude is helpful, and helpful is wrong here. A kid writes becuase and Claude wants to hand you back "because." But the whole point of a spelling app is to catch that the kid wrote it wrong. If I scored Claude's cleaned-up read, every kid gets 100%. So Claude finds and labels the word, and Textract's dumb, literal, character-for-character read grades it. And calculate_letter_accuracy is a real Levenshtein aligner, not a ratio: it classifies every character as a match, substitution, insertion, or deletion, which is what powers "you swapped the 'a' and 'u' in 'because'" instead of just "wrong."

The war story: a stage bug became a throttling storm

The pipeline is event-driven. Textract writes stage: 'textract_complete', the stream triggers the analyzer. Simple. Except the analyzer's guard checked for the wrong stage value:

# BROKEN: Textract writes stage='textract_complete', but the guard
# waits for 'storing_results', which never arrives on the trigger event.
if processing_status == 'textract_complete' and stage == 'storing_results':
    # run Claude analysis

The intended trigger never cleanly matched. Meanwhile the analyzer's own status write-backs (claude_starting, claude_analyzing) and user retries kept firing new stream events into the same function. Not one clean run, but a swarm of overlapping invocations all reaching for Bedrock at once.

That's when Bedrock started returning ServiceUnavailableException / "Too many connections." Users got 60-second timeouts, and it would have gotten exponentially worse with more traffic. A one-word string mismatch in an if statement was a latent denial-of-service against my own model endpoint.

The fix has two halves.

Fix the stage machine so there's exactly one trigger. Match the value Textract actually writes, and set the terminal stage to something that isn't a trigger:

# FIXED: match the stage Textract really writes
if processing_status == 'textract_complete' and stage == 'textract_complete':
    # run Claude analysis
else:
    # our own write-backs (claude_starting/analyzing/complete) land here
    return {'statusCode': 200, 'body': 'Event ignored - not ready'}

The final write sets stage: 'complete', which no longer matches the trigger. The self-loop is closed structurally, and my own progress writes fall through to the harmless else.

Make Bedrock calls survive a throttle. Even loop-free, a burst of real uploads can make Bedrock push back, so add exponential backoff with jitter:

max_retries = 4
base_delay = 1  # 1s -> 2s -> 4s -> 8s, plus 0-2s random jitter
for attempt in range(max_retries + 1):
    try:
        claude_response = bedrock_client.invoke_model(...)
        break
    except Exception as e:
        if "ServiceUnavailableException" in str(e) or "throttled" in str(e).lower():
            if attempt < max_retries:
                time.sleep(base_delay * (2 ** attempt) + random.uniform(0, 2))
                continue
        raise e

The jitter is the part people skip. Without it, ten throttled invocations back off for exactly 2**attempt seconds and retry in lockstep, restampeding the endpoint. random.uniform(0, 2) smears them across a window so they don't re-collide.

The lesson worth keeping: the stage typo didn't just cause wrong behavior, it manufactured concurrency, and the concurrency is what took Bedrock down.

There's a UX angle here too. Claude's analysis takes ~25 seconds, and a seven-year-old's patience budget is about 20, so latency is a reliability metric, not just a performance one. I learned that number the hard way, watching my kid take the photo, wait, sigh, and set the phone down to go do literally anything else before the score came back. If your feedback loop is slower than your user's attention span, the system has failed that user. I couldn't make Claude faster, so I made the wait survivable with those same update_processing_status() write-backs and a GET /status/{id} poll that turns them into live progress. That's the real SLO for this app: not "99.9% under 500ms," but "results appear before the kid walks away." The analyzer already logs a per-step timing breakdown, so the honest next move is to emit those as CloudWatch metrics and alarm on p90 end-to-end, not the average that hides the one kid who waited 40 seconds behind the nine who waited 10.

What I'd add before letting strangers in

The fix above is what's deployed, and it's right for two kids. But a 300-level reader will see what's missing:

A conditional write for real idempotency. The stage guard stops the loop, but at-least-once delivery means the same event can still arrive twice. A ConditionExpression (attribute_not_exists(id)) on the results write makes a duplicate a no-op at the database, so I never pay for a second Bedrock call on a dupe. Today I rely on the stage flag, which is code-level, not storage-level.
A dead-letter queue on the stream mapping. A poison record (corrupt image, unparseable response) makes a stream Lambda retry the whole batch until records expire, up to 24 hours, blocking the shard and re-billing Bedrock every spin. BisectBatchOnFunctionError, a MaximumRetryAttempts cap, and an OnFailure destination would isolate it.
Infrastructure-as-code for the stream mappings, retry config, and DLQ. Right now I redeploy with aws lambda update-function-code and a prayer. There's literally a .lambda.backup-* folder from the day I fixed the loop. Fine for a personal app, but those retry settings are exactly what you can't afford to configure by hand and forget.

What I took away

A logic bug and a capacity failure can be the same incident. A one-word stage mismatch manufactured concurrency, and the concurrency is what threw ServiceUnavailableException. Guard the trigger edge precisely, and assume every downstream call can be throttled.
Backoff without jitter just reschedules the stampede. random.uniform(0, 2) on top of exponential delay is what keeps retries from re-colliding.
Use the "wrong" service on purpose. Claude to read, Textract to grade, so the helpful model can't auto-correct away the mistakes the app exists to catch.

The best engineering I've done on this app didn't happen at a desk. It happened at the kitchen table, with my kids handing me the phone and quitting the second it got slow. The most honest QA team I've ever had can't spell "because"... but they'll tell you when your app is too slow.

Happy building.

Bee Hunter runs on AWS: S3, CloudFront, API Gateway, Lambda, DynamoDB, Amazon Textract, and Amazon Bedrock (Claude Sonnet 4.5).

Saying Goodbye to Amazon WorkMail: How I Migrated My Mailbox to Gmail

Aaron Hunter — Wed, 02 Sep 2026 15:53:33 +0000

I spent years supporting WorkMail and SES at AWS, and even became a Subject Matter Expert in both services. Here's how I moved my own mail off it, start to finish... and got sentimental doing it.

Level: 200 (intermediate). Assumes you're comfortable with the AWS CLI, IAM roles, S3, and KMS.

Amazon WorkMail is winding down... AWS has announced end of support for March 31, 2027. If you're running a mailbox or two on WorkMail, now is a good time to think about where that mail is going to live next. In my case, I'm moving my domain's mail over to Google Workspace, and I wanted to bring years of old email along for the ride.

I'll be straight with you up front, though... this one's personal, and writing a guide to leave WorkMail behind is genuinely bittersweet. I'll get into why at the end... but first, let's do the work.

Here's the important part... WorkMail gives you a clean, supported way to get your mail out: the StartMailboxExportJob API. It drops every message into an S3 bucket as a KMS-encrypted .zip of standard .eml files. From there, getting those messages into Gmail is just a matter of speaking IMAP.

In this post, we're going to walk through the whole path... exporting the mailbox, wiring up the IAM and KMS pieces the export needs, downloading and inspecting the archive, uploading everything into Gmail with a small Python script, bringing the calendar over, tearing WorkMail down when you're done, and finally locking the domain down with SPF, DKIM, and DMARC so your new Gmail-hosted mail actually lands. Along the way I'll call out the gotchas that cost me time, so they don't cost you any.

The shape of the solution

Before we touch a command, let's set the mental model. There are two halves to this migration:

Get the mail out of WorkMail. StartMailboxExportJob writes an encrypted .zip to S3. This needs a KMS key and an IAM role the WorkMail export service can assume.
Get the mail into Gmail. Gmail speaks IMAP, and IMAP has an APPEND command that uploads a raw message into a mailbox. We loop over the exported .eml files and append each one.

That's it. No third-party migration tool, no paid service. Just AWS APIs on one side and IMAP on the other.

Part 1: Exporting the mailbox

What the export actually contains

The export writes email messages and calendar items to a .zip, organized into folders that mirror your mailbox (Inbox, Sent Items, Deleted Items, Junk E-mail, Calendar). Messages come out as .eml (standard MIME), and calendar entries come out as .ics.

One thing that surprised me... contacts and tasks are not included. If you need those, export them separately from the WorkMail web app. Good to know before you assume the .zip is everything.

The prerequisites the export needs

The export job can't just write to S3 on its own. It needs three things in place, and all of them have to live in the same AWS Region as your WorkMail organization:

A symmetric KMS key to encrypt the output.
An IAM role that the export service (export.workmail.amazonaws.com) can assume.
An S3 bucket to receive the .zip.

Let's build them. First, the KMS key:

aws kms create-key \
  --description "WorkMail mailbox export encryption key" \
  --key-spec SYMMETRIC_DEFAULT \
  --key-usage ENCRYPT_DECRYPT

Grab the key ARN from the output... you'll need it in a couple of places.

Now the IAM role. This is the part people trip on, so let's be precise. The role needs a trust policy that lets the WorkMail export service assume it, scoped to your account and organization:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "export.workmail.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "111122223333" },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:workmail:us-east-1:111122223333:organization/m-EXAMPLEORGID"
        }
      }
    }
  ]
}

Those aws:SourceAccount and aws:SourceArn conditions matter... they're what stop a confused-deputy situation where some other org could trick your role into running. Keep them.

And the permissions policy that lets the role write to your bucket and use the KMS key:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:AbortMultipartUpload", "s3:PutObject", "s3:GetBucketPolicyStatus"],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket",
        "arn:aws:s3:::amzn-s3-demo-bucket/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": ["arn:aws:kms:us-east-1:111122223333:key/EXAMPLE-KEY-ID"],
      "Condition": {
        "StringEquals": { "kms:ViaService": "s3.us-east-1.amazonaws.com" },
        "StringLike": {
          "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::amzn-s3-demo-bucket/mail-export*"
        }
      }
    }
  ]
}

Create the role and attach the policy:

aws iam create-role \
  --role-name WorkmailMailboxExportRole \
  --assume-role-policy-document file://trust-policy.json

aws iam put-role-policy \
  --role-name WorkmailMailboxExportRole \
  --policy-name MailboxExport \
  --policy-document file://permissions-policy.json

Kicking off the export

You'll need your organization ID and the entity (user) ID for the mailbox. Both come from the WorkMail API:

aws workmail list-organizations
aws workmail list-users --organization-id m-EXAMPLEORGID

Now start the job:

aws workmail start-mailbox-export-job \
  --organization-id m-EXAMPLEORGID \
  --entity-id EXAMPLE-ENTITY-ID \
  --kms-key-arn arn:aws:kms:us-east-1:111122223333:key/EXAMPLE-KEY-ID \
  --role-arn arn:aws:iam::111122223333:role/WorkmailMailboxExportRole \
  --s3-bucket-name amzn-s3-demo-bucket \
  --s3-prefix mail-export \
  --description "Mailbox export for Gmail migration"

You'll get back a JobId. Poll it until the state flips to COMPLETED:

aws workmail describe-mailbox-export-job \
  --organization-id m-EXAMPLEORGID \
  --job-id EXAMPLE-JOB-ID

A mid-size mailbox (a few thousand messages) finishes in a handful of minutes. When it's done, you'll have one .zip sitting at s3://amzn-s3-demo-bucket/mail-export/....

Heads up if your bucket fronts a public website. The export .zip is KMS-encrypted, so even a public bucket doesn't expose readable mail... a random visitor just gets ciphertext. Still, download it over authenticated S3 rather than the public URL, and delete it once you're done. No reason to leave a copy of your entire mailbox lying around.

Part 2: Download and inspect

Pull the archive down (S3 decrypts on the fly because your identity has access to the KMS key) and unzip it:

aws s3 cp "s3://amzn-s3-demo-bucket/mail-export/EXAMPLE.zip" ./mailbox-export.zip
unzip -q mailbox-export.zip -d mailbox-export

Take a minute to look at what you got. Counting files per folder tells you where the value actually is:

cd mailbox-export
for d in */; do printf "%-16s %s files\n" "$d" "$(find "$d" -type f | wc -l)"; done

In my export, the Inbox and Sent Items were the mail I cared about... Deleted Items and Junk E-mail were thousands of messages of noise I had no interest in re-importing. Knowing that up front saved me from uploading ~4,800 junk messages into a fresh mailbox.

Part 3: Uploading into Gmail over IMAP

This is where it gets fun. Gmail exposes IMAP at imap.gmail.com:993, and Python's standard library ships imaplib, so we don't need any dependencies.

A few design decisions that make the difference between "it technically worked" and "it worked well":

Preserve the original date. If you don't set the IMAP internal date, every message shows up dated today, which wrecks sorting. We parse each message's Date: header and pass it through.
Mark messages as read. Uploading 3,900 emails as unread is a great way to make your new inbox unusable. We append with the \Seen flag.
Batch the work. Gmail throttles after a burst of appends, and huge operations are easier to reason about in chunks. Split the Inbox into folders of ~500 and upload one at a time.
Never hardcode credentials. The script reads your Gmail address and an app password from environment variables. It never stores or prints them.

Here's the core of the uploader:

import email, email.utils, imaplib, os, sys, time
from pathlib import Path

def internaldate_for(msg):
    date_hdr = msg.get("Date")
    if date_hdr:
        parsed = email.utils.parsedate_tz(date_hdr)
        if parsed:
            return imaplib.Time2Internaldate(email.utils.mktime_tz(parsed))
    return None  # server stamps "now" if the header is missing

def upload(directory, label):
    imap = imaplib.IMAP4_SSL("imap.gmail.com", 993)
    imap.login(os.environ["GMAIL_ADDRESS"], os.environ["GMAIL_APP_PASSWORD"])
    if not label.startswith("[Gmail]"):
        imap.create(f'"{label}"')  # harmless if it already exists

    for f in sorted(Path(directory).glob("*.eml")):
        raw = f.read_bytes()
        msg = email.message_from_bytes(raw)
        imap.append(f'"{label}"', r"(\Seen)", internaldate_for(msg), raw)
        time.sleep(0.05)  # be polite to Gmail's rate limits

    imap.logout()

A quick word on app passwords... Gmail won't let a script log in with your normal password once 2-Step Verification is on. Instead you generate a 16-character app password (Google Account → Security → App passwords), hand it to the script through an environment variable, and revoke it the moment you're done. That keeps the credential out of your code, out of your shell history if you're careful, and easy to kill.

Run it per batch, and point Sent mail at Gmail's real Sent folder:

export GMAIL_ADDRESS="you@yourdomain.com"
export GMAIL_APP_PASSWORD="xxxxxxxxxxxxxxxx"

for b in 01 02 03 04 05 06 07 08; do
  python3 import_to_gmail.py --dir "mailbox-export/Inbox-batches/batch-$b" --label "WorkMail Import"
done

python3 import_to_gmail.py --dir "mailbox-export/Sent Items" --label "[Gmail]/Sent Mail"

The gotchas that cost me time

A few things I learned the hard way, so you don't have to:

Gmail has a 25 MB per-message limit. IMAP APPEND rejects anything bigger with [TOOBIG] Message too large. In my migration exactly one email failed... a 39 MB message stuffed with photos. There's no IMAP workaround; you handle those few manually from the export. The fix is to log the failures with their subject and date as you go, so you have a short punch list at the end instead of a mystery.

A custom label is not the Inbox. This one's subtle. When you APPEND a message to a label like "WorkMail Import", Gmail applies that label... and only that label. The Inbox in Gmail is itself just a label (\Inbox), and your append never applied it. So all your mail imports perfectly and then appears to be "missing" from the Inbox. It's not missing... it just isn't tagged Inbox.

The fix is elegant once you know it. In Gmail, copying a message to INBOX adds the Inbox label without duplicating the message. So a one-shot IMAP COPY from your label into INBOX lights everything up:

imap.select('"WorkMail Import"')
_, data = imap.uid("SEARCH", None, "ALL")
uids = data[0].split()
for i in range(0, len(uids), 200):
    chunk = b",".join(uids[i:i+200]).decode()
    imap.uid("COPY", chunk, "INBOX")  # adds \Inbox label, no dupes

Everything must share a Region. WorkMail org, KMS key, and S3 bucket all have to be in the same AWS Region, or the export simply won't run. Check this first.

Watch the throttling. My first batch of 500 flew through in about six minutes. Later batches slowed as Gmail throttled the connection. It never failed... it just paced itself. Batching plus a small sleep between appends keeps you on the right side of Gmail's limits.

Part 4: Bringing the calendar over

Remember those .ics files in the Calendar/ folder? Google Calendar can import them, but its web UI takes one file at a time, and I had a lot to import. So first, merge them into a single file.

The naive move... cat *.ics > combined.ics... produces a file with separate BEGIN:VCALENDAR ... END:VCALENDAR blocks, and some importers choke on that. The correct shape is one VCALENDAR wrapper containing all the event components. Pull the components out of each file and drop them into a single calendar:

def extract_components(lines):
    """Keep only component blocks (VEVENT, VTIMEZONE, ...); drop the outer
    VCALENDAR wrapper and calendar-level scalar props so we can re-wrap once."""
    out, depth = [], 0
    for ln in lines:
        s = ln.strip()
        if s in ("BEGIN:VCALENDAR", "END:VCALENDAR"):
            continue
        if s.startswith("BEGIN:"): depth += 1; out.append(ln); continue
        if s.startswith("END:"):   out.append(ln); depth -= 1; continue
        if depth >= 1: out.append(ln)  # inside a component
    return out

Wrap the collected components with a single header (BEGIN:VCALENDAR / VERSION:2.0 / PRODID:... / CALSCALE:GREGORIAN) and footer, write it out with CRLF line endings per RFC 5545, and you've got one importable file.

The "you do not have sufficient access on the target calendar" trap

Here's the one that had me scratching my head. I imported the merged file into my own calendar and got:

Imported zero events. Could not upload your events because you do not have sufficient access on the target calendar.

On my own calendar. Cute.

It's a misleading error. It has nothing to do with permissions. These events were meeting invites... Calendly bookings, Google-generated invitations... and each one carried its original UID ending in @google.com, with an ORGANIZER that was someone else. Google recognizes that UID as an event owned by another account in its namespace, and refuses to let you import a copy... hence "insufficient access."

The fix is to give each event a fresh, unique UID so Google treats them as brand-new events you own:

import uuid
# for each line in the .ics:
if line.startswith("UID:") or line.startswith("UID;"):
    line = f"UID:{uuid.uuid4()}@yourdomain.com"

Rewrite the UIDs, re-import, and you'll get the satisfying "Imported 7 out of 7 events." Tip: import into a dedicated calendar (make a "WorkMail" one first) so if anything looks off, you just delete that calendar instead of untangling events from your main one.

And remember... the export never included contacts. Export those from the WorkMail web app as a vCard and import them into Google Contacts separately.

Part 5: Decommissioning WorkMail

Once you've confirmed everything is safely in Gmail, you can tear WorkMail down to stop the per-mailbox billing. Order matters here.

Repoint your MX records first. Before you delete anything, make sure your domain's MX points at Google, not WorkMail, so incoming mail flows to the right place. Verify it against your authoritative nameserver (more on why in Part 6):

dig +short MX yourdomain.com     # want: 1 smtp.google.com.

Only once that's confirmed should you delete the organization. This is irreversible... it permanently destroys the mailbox and its directory:

aws workmail delete-organization \
  --organization-id m-EXAMPLEORGID \
  --delete-directory \
  --force-delete        # needed if the org still has enabled users

Then clean up the export scaffolding you built in Part 1, plus the archive itself:

# Schedule the KMS key for deletion (7-30 day window, cancellable)
aws kms schedule-key-deletion --key-id EXAMPLE-KEY-ID --pending-window-in-days 7

# Remove the IAM role (delete its inline policy first)
aws iam delete-role-policy --role-name WorkmailMailboxExportRole --policy-name MailboxExport
aws iam delete-role --role-name WorkmailMailboxExportRole

One more thing on the S3 archive: if your bucket has versioning enabled, a plain aws s3 rm just drops a delete marker... the actual object version (your entire mailbox) sticks around and stays recoverable. To truly purge it, delete the versions:

aws s3api list-object-versions --bucket amzn-s3-demo-bucket --prefix mail-export
# then delete each returned VersionId with:
aws s3api delete-object --bucket amzn-s3-demo-bucket --key <key> --version-id <VersionId>

Don't forget SES receiving, if you set it up

Here's one that's easy to leave dangling. If at some point you configured SES to receive mail for your domain (a receipt rule set with an S3 action that drops inbound messages into a bucket), that's a completely separate pile of resources from WorkMail... and it keeps quietly storing mail as long as your MX points at SES. Once you've moved MX to Google, it's dead weight. In my case it had accumulated over 11,000 raw messages in an S3 prefix I'd forgotten about.

Find it by looking at your active rule set:

aws ses describe-active-receipt-rule-set    # shows the S3Action bucket + prefix

To tear it down, deactivate the rule set before deleting it (SES won't let you delete the active one), then purge the S3 prefix:

aws ses set-active-receipt-rule-set                                   # deactivate all
aws ses delete-receipt-rule-set --rule-set-name your-rule-set-name
aws s3 rm "s3://your-bucket/SES/" --recursive --only-show-errors      # scope to the prefix!

Two cautions here:

Scope the S3 delete to the prefix, not the bucket. That bucket may hold unrelated things... mine also had a website folder and a video file at the root. Delete s3://bucket/SES/, never s3://bucket.
Be careful with SES identities. A verified domain identity governs sending, not just receiving. If anything still sends transactional mail as your domain through SES, keep the domain identity. Only delete identities you're sure are unused (a stale per-address identity is usually safe):

  aws ses delete-identity --identity old-unused@yourdomain.com

Part 6: Locking down email authentication (SPF, DKIM, DMARC)

Migrating the mail is only half the job. If you don't set up email authentication for your domain on Google Workspace, your outbound mail is going to land in spam folders... or get rejected outright. You want all three: SPF, DKIM, and DMARC.

A debugging tip that will save you an hour: when you add a DNS record and it "isn't showing up," don't guess about propagation. Query your domain's authoritative nameserver directly. If the record is there, it's live; if it's not, your edit didn't land (wrong hosted zone, wrong record name, not saved). This cuts through all the caching noise:

NS=$(dig +short NS yourdomain.com | head -1)
dig @"$NS" +short TXT yourdomain.com          # SPF lives on the apex
dig @"$NS" +short TXT _dmarc.yourdomain.com   # DMARC lives here
dig @"$NS" +short TXT google._domainkey.yourdomain.com  # DKIM

SPF goes on the apex as a TXT record:

"v=spf1 include:_spf.google.com ~all"

Watch out here if you're on Route 53: you can't have two separate TXT record sets with the same name. If your apex already has, say, a google-site-verification TXT, the SPF string goes in as an additional quoted value in that same record set... not a new record.

DKIM is generated in the Google Admin console (Apps → Google Workspace → Gmail → Authenticate email). It hands you a TXT record with the host name google._domainkey and a v=DKIM1; k=rsa; p=... value. Add it as its own separate record, then... and this is the step people miss... go back to the Admin console and click Start authentication. The DNS record alone doesn't turn it on. (If you already see a "Stop authentication" button, it's active.)

DMARC is the one everybody gets wrong, so pay attention: it does not go on your apex. It goes on its own record named _dmarc.yourdomain.com. That's a different DNS name, so it's a separate record and won't conflict with anything... the "only one TXT per name" rule doesn't apply across different names. Mail servers only ever look up DMARC at _dmarc.<domain>, so a v=DMARC1 string sitting on your apex does absolutely nothing.

Also know this: DMARC is domain-wide, not per-address. One record covers every mailbox on the domain. The mailto: in it isn't a "protected" address... it's just where aggregate reports get sent. Start in monitor-only mode:

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Leave it at p=none for a week or two while you watch the reports, then tighten to p=quarantine and eventually p=reject once you're confident legit mail is passing. DMARC only enforces once SPF and/or DKIM are aligned, so get those two live and signing first.

Wrapping up

When the dust settled, I had ONE message that wasn't migrated. It ended up being that oversized photo email, which I grabbed by hand. Sent mail landed in Sent, old mail landed in the Inbox (labeled correctly), all calendar events came across, WorkMail was fully torn down, and the domain was authenticating with SPF, DKIM, and DMARC.

The core pattern generalizes well beyond WorkMail. Export to a portable format (.eml/MIME), then speak the destination's native protocol (IMAP). Any mailbox that can export standard messages and any provider that offers IMAP can be bridged with a script like this. The calendar half is the same idea in miniature... portable .ics, imported natively.

A few closing lessons worth internalizing:

Verify against the authoritative nameserver, not a public resolver, whenever DNS "isn't working." It turns a guessing game into a yes/no answer.
DMARC on _dmarc, DKIM on google._domainkey, SPF on the apex. Wrong record name is the number-one reason email auth silently does nothing.
Clean up what you created. Revoke the app password, delete the export .zip (including old versions if the bucket is versioned), schedule the KMS key for deletion, and remove the export IAM role. And repoint MX before you delete the WorkMail org, never after.
Hunt down orphaned receiving infrastructure. WorkMail wasn't necessarily the only thing catching your mail... an old SES receipt rule set quietly archiving to S3 will keep costing you storage long after you've moved on. Check describe-active-receipt-rule-set and clean it up too.

Happy migrating.

One last thing... a personal goodbye

I'm going to step out of tutorial mode for this part, because writing a guide for migrating off WorkMail is genuinely bittersweet for me.

Before I ever built things on AWS, I worked at AWS, as a Cloud Support Engineer. WorkMail became my thing. I went deep enough to become an SME on it... and on SES right alongside it. I spent years in the trenches with some of our largest enterprise customers, untangling mail flow, receipt rules, DKIM, deliverability... the exact stuff this post is about. None of this is abstract for me. It's muscle memory from a lot of customer cases and a lot of late nights.

In 2016, I got to fly out to The Hague, near Amsterdam, and spend a week working side by side with the WorkMail service team. Sitting in the same room as the people who actually built the service, learning how they thought about it... that's one of the highlights of my entire AWS career. I'll never forget that week.

So yeah... watching WorkMail sunset stings. This was never just another service to me. It was customers I got to help, hard problems I got to solve, and a team I got to learn from. It's a chapter of my career I'm genuinely proud of. If you found your way here because you're migrating off too, I hope this guide makes it painless... and I hope you'll forgive me for getting a little sentimental about the thing we're packing up.

Thank you, WorkMail. And thank you to the team behind it. It was an honor. 🧡

How I Built a Serverless CFP Agent on AWS

Aaron Hunter — Thu, 30 Jul 2026 18:52:16 +0000

If you speak at conferences, you know the Call for Papers (CFP) hunt is a grind. Deadlines are scattered across a dozen sites, half of them are already closed, and you can never remember which ones you've already seen or applied to. I was doing this by hand every week... and I was still missing good ones.

So I built an agent to do it for me. It runs entirely serverless on AWS, wakes up on a schedule, pulls CFPs from multiple sources, ranks them against my speaker profile with a model on Amazon Bedrock, and drops the good ones in Slack. This post walks through how it's put together and, more importantly, why I picked the AWS pieces I did.

WHAT I BUILT

The whole thing is a pipeline that runs on its own every morning:

Fetch open CFPs from a few conference aggregators
Normalize them into one consistent shape
Filter them against rules I define (topics, countries, delivery type, deadlines)
Rank the survivors against my speaker profile using a model on Bedrock
Store the results as JSON and notify me in Slack

There's no server to babysit. When it's not running, it costs me basically nothing. That's the part I want to focus on... because the AWS choices are what make an "agent that runs every day" something you can build on a personal budget.

THE PROBLEM UP CLOSE

Here's what the manual version looked like. Open five or six tabs, scroll through conference listings, cross-reference against a note somewhere of what I'd already applied to, do the math on whether the deadline had even passed, and then repeat the whole thing next week because new ones show up constantly.

The worst part was memory. A CFP I looked at last Tuesday looked brand new again the following Monday. I had no durable sense of "this is new since I last checked" or "I already said no to this one." That's exactly the kind of stateful, repetitive, run-it-on-a-schedule chore that a little bit of AWS glue is perfect for.

THE AWS ARCHITECTURE

Here's the shape of it. Every box is serverless or managed, so there's nothing running when the job isn't.

EventBridge Scheduler (cron)
        │
        ▼
   Lambda "cfp-agent"
        │
  ┌─────┼───────────────┐
  ▼     ▼               ▼
 feeds  DynamoDB     Bedrock
(fetch) (rules,      (rank +
        profile,      recommend)
        seen log)
        │
   ┌────┴────┐
   ▼         ▼
 S3 json    Slack
(dashboard) (digest)

Let me walk through the important pieces.

Lambda is the whole engine

The entire pipeline is one Lambda function. Fetch, normalize, filter, rank, write... it all happens inside a single handler. There's no always-on box, no container sitting idle overnight. It spins up, does the work in a minute or two, and goes back to sleep.

The handler is really just an orchestration of the steps:

def lambda_handler(event, context):
    cfps = fetch_all_sources()          # pull the feeds
    cfps = normalize(cfps)              # one consistent schema
    cfps = tag_against_rules(cfps)      # topics, countries, deadlines
    ranked = rank_with_bedrock(cfps)    # score vs my profile
    write_to_s3(ranked)                 # dashboard reads this
    notify_slack(ranked)                # ping me on the good ones
    return {"count": len(ranked)}

This is the thing I love about Lambda for a personal agent... the unit of deployment is just the function. I'm not paying for uptime, I'm paying for the ninety seconds a day it actually runs.

DynamoDB is the agent's memory

This was the fix for my biggest pain point. The model doesn't remember anything between runs, so I give it memory in DynamoDB. One small table holds three things: my filter rules, my speaker profile, and a "seen" log of every CFP id I've already surfaced.

import boto3

table = boto3.resource("dynamodb").Table("cfp-agent")

# the agent's "memory": rules, profile, and what it's already seen
rules   = table.get_item(Key={"id": "rules"})["Item"]
profile = table.get_item(Key={"id": "profile"})["Item"]
seen    = table.get_item(Key={"id": "seen"})["Item"]

# after the run, remember what we surfaced so tomorrow knows what's new
table.put_item(Item={"id": "seen", "discovered": updated_seen})

The seen log is what lets the agent tell me "here's what's new since yesterday" instead of showing me the same list forever. DynamoDB on pay-per-request pricing is a great fit here... a handful of tiny reads and writes a day rounds down to nothing, and I never think about capacity.

Bedrock does the ranking

Deterministic rules do the cheap first cut... drop anything closed, wrong country, wrong topic. But "is this conference actually a good fit for me?" is a judgment call, not a keyword match. That's where a model on Amazon Bedrock comes in.

I feed it my profile (bio, expertise, goals, past talks) and each surviving CFP, and it hands back a relevance score, a recommendation of apply / consider / skip, and a short reason. Because the model is stateless, that profile from DynamoDB is what makes the recommendations actually about me.

prompt = f"""You match conference CFPs to a speaker.

SPEAKER PROFILE:
{profile}

Score each CFP 0-100 for fit. Return apply / consider / skip
plus a one-line reason.

CFPS:
{cfp_batch}
"""

resp = bedrock.invoke_model(modelId=MODEL_ID, body=json.dumps(payload))

One thing I decided early: no silent fallback. If Bedrock can't be reached, the run fails loudly and writes an error the dashboard shows as a banner. I'd rather know the ranking is broken than get a quietly degraded list of keyword-matched guesses that looks fine but isn't.

EventBridge Scheduler makes it an agent, not a script

The thing that turns this from "a script I run when I remember" into "an agent that just handles it" is EventBridge Scheduler. A cron expression kicks the Lambda off every morning. It's timezone-aware, so it fires at 6am my time without me doing daylight-saving math.

cron(0 6 * * ? *)   # 6:00am, every day

That's it. That single line is the difference between a tool I have to remember to use and one that quietly does its job before I wake up.

S3 + CloudFront for the dashboard

The Lambda writes the results as a JSON file to S3, and a static HTML dashboard reads it through CloudFront. No API, no database query from the browser... just a JSON file on a CDN. The dashboard is where I actually browse, search, hide ones I'm not into, and star the ones I want to apply to. Cheap, fast, and nothing to run.

DOES IT WORK?

Yeah. It went from me manually combing sites every week to opening one dashboard where the good ones are already ranked and the new ones are flagged. On a recent run it pulled well over a thousand CFPs across sources, cut them down to a few hundred that passed my rules, and Bedrock flagged a few dozen worth actually applying to. That's the whole point... I look at the dozen, not the thousand.

And because it remembers what it's shown me, I finally have that "new since last time" signal I was missing. No more re-reading the same listings and wondering if I'd already seen them.

THINGS TO CONSIDER

Feed data can be wrong. Community-maintained feeds sometimes have stale or flat-out incorrect deadlines. I added a separate verify step that actually renders the CFP page to double-check the date, but it's a reminder that your agent is only as good as its inputs... build in a way to correct them.

Bedrock costs scale with volume. Ranking a few hundred CFPs a day is cheap, but it's not free. Batching the calls and doing the cheap rule-based filtering first keeps the model spend down. Don't send the model everything... send it what already survived the free checks.

Serverless state needs a home. The moment your agent needs to remember anything between runs, you need somewhere durable to put it. DynamoDB was the low-friction answer for me, but the lesson is to plan for state early rather than bolting it on later.

GET STARTED

If you've got a repetitive, run-it-on-a-schedule chore that also needs a little judgment, this shape is worth stealing. Lambda for the work, DynamoDB for the memory, Bedrock for the judgment calls, EventBridge to run it on its own, and S3 for the output. Every piece scales to zero when it's idle, so an agent that runs every single day can cost next to nothing.

I built this because I was tired of missing CFPs... now I just check a dashboard. If you speak at conferences, or want to, that alone is worth the few hours it takes to set this up.