How much does it cost to run?

About $2.80/month at typical small-business volume (one issue a week, drawing on a dozen or so items). The fixed cost is essentially zero. The variable cost is dominated by the weekly Bedrock draft and the email send; the gathering and the daily checks are pennies. At one issue a day to a larger list the bill lands around $14.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the approve and edit endpoints, EventBridge Scheduler for the weekly gather and the deferred-send one-offs, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 for classifying and tidying items, Claude Sonnet 4.6 for the issue draft) via Global cross-Region inference. No API Gateway, no NAT Gateway, no always-on compute.

Where do the items come from?

Three lanes feed one item pool. A Google Sheet in a Drive folder you control, where anyone can drop a win or a product note; a feed lane that watches your blog's RSS feed for new posts; and an inbox-forwarding lane where the team forwards an update to a dedicated address. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes; the composer reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.

Does it use AI, and can it make things up?

It uses AI to write, but only from the items you gathered. Bedrock Haiku 4.5 tidies and classifies each item; Bedrock Sonnet 4.6 writes the issue, grounded strictly in those items and your voice doc. The draft links every claim back to a source item, and the review message flags anything the model could not ground so the owner sees it before sending. The owner is always the last step; nothing leaves without a human approving it.

What if there is nothing worth sending this week?

The composer counts the fresh items first. If there are too few to make a worthwhile issue (default fewer than three), it skips the week and tells the owner why instead of padding a thin issue. The owner can also skip any week by hand from the review message. A skipped week is logged like any other action, so the trail shows why an issue did or did not go out.

What happens when the owner reviews a draft?

Three buttons on every review message: Approve (queue the issue to send at the configured time, after a short cooling-off window), Edit (open the draft in a doc, make changes, and re-submit), and Skip (don't send this week). Every action is recorded in the nc-audit DynamoDB table with timestamp, issue, action, by-user, and a before-and-after snapshot of the draft, so the trail is auditable for years.

Series · 7 parts Published May 16, 2026

Newsletter composer

A serverless composer that gathers the week’s new blog posts, product notes, and wins from the sources you point it at; drafts a clear, friendly email issue in your voice grounded in those items; and hands it to the owner to approve, edit, or skip before it sends. A human stays in control — nothing goes out without sign-off. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A newsletter composer on AWS for a few dollars a month

The whole system on one page — an item intake, a composer, and a sending piece, plus the four moves they share for every weekly run.
02

How a newsletter gathers the week’s updates

Three lanes feed one item pool — the Drive sheet where anyone drops a win, a feed lane that watches your blog’s RSS for new posts, and an inbox-forwarding lane that turns a forwarded update into a proposed item for one-tap approval.
03

How a newsletter issue gets drafted

A weekly run counts the fresh items, decides whether there is enough to send, then drafts the issue grounded only in those items and your voice doc. Five steps pick one of four moves: skip, draft, redraft, ready.
04

How a newsletter draft reaches the owner

Reviewer resolution, quiet hours, the grounding check that flags anything unsourced, the full draft in context, and the four guardrails between the finished draft and the review message landing.
05

How a newsletter issue gets approved and sent

Three actions on the review message: approve (queue to send after a cooling-off window), edit (open the draft, change it, re-submit), and skip (don’t send this week). Every action is logged.
06

What the newsletter composer costs

A couple of dollars a month at SMB volume. The composer runs once a week, drafts with one Bedrock call, and sends one email per subscriber through SES.
07

Engineering reference: the newsletter composer architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SES inbound rule set, EventBridge Scheduler config, and the DynamoDB schemas.

What is a newsletter composer?: A small serverless system that gathers the week’s new blog posts, product notes, and wins from the sources you point it at; drafts a clear, friendly email issue in your voice grounded in those items; and hands it to the owner to approve, edit, or skip before it sends. It never sends without sign-off. The owner can approve, edit a draft in place, or skip the week entirely directly from the review message.
How much does it cost to run?: About $2.80/month at typical small-business volume (one issue a week, drawing on a dozen or so items). The fixed cost is essentially zero. The variable cost is dominated by the weekly Bedrock draft and the email send; the gathering and the daily checks are pennies. At one issue a day to a larger list the bill lands around $14.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the approve and edit endpoints, EventBridge Scheduler for the weekly gather and deferred-send one-offs, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Haiku 4.5 to classify and tidy items, Sonnet 4.6 to draft the issue) via Global cross-Region inference. No API Gateway, no NAT Gateway, no always-on compute.
Where do the items come from?: Three lanes feed one item pool. A Google Sheet in a Drive folder where anyone can drop a win or a product note; a feed lane that watches your blog’s RSS feed for new posts; and an inbox-forwarding lane where the team forwards an update to a dedicated address. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes; the composer reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.
Does it use AI, and can it make things up?: It uses AI to write, but only from the items you gathered. Bedrock Haiku 4.5 tidies and classifies each item; Bedrock Sonnet 4.6 writes the issue, grounded strictly in those items and your voice doc. The draft links every claim back to a source item, and the review message flags anything the model could not ground so the owner sees it before sending. The owner is always the last step; nothing leaves without a human approving it.
What if there is nothing worth sending this week?: The composer counts the fresh items first. If there are too few to make a worthwhile issue (default fewer than three), it skips the week and tells the owner why instead of padding a thin issue. The owner can also skip any week by hand from the review message. A skipped week is logged like any other action, so the trail shows why an issue did or did not go out.
What happens when the owner reviews a draft?: Three buttons on every review message: Approve queues the issue to send at the configured time, after a short cooling-off window. Edit opens the draft in a doc to change and re-submit. Skip doesn’t send this week. Every action is recorded in the nc-audit DynamoDB table with timestamp, issue, action, by-user, and a before-and-after snapshot of the draft, so the trail is auditable for years.

All posts

Frequently asked questions

Other series