build.allanninal.dev

Part 6 of 7 · Churn predictor series ~3 min read

What the churn predictor costs

The predictor is one of the cheapest systems in this whole series. The weekly run reads a CSV from S3, does some plain arithmetic, writes a few rows to DynamoDB, and posts one short list per owner. It calls no model on the hot path. Bedrock fires only when a support ticket comes in, when the weekly list needs its plain reasons written, and once a month for the summary. At typical SMB volume, the bill is a couple of dollars a month, fixed cost essentially zero.

Key takeaways

  • Around $2/month at typical SMB volume (around 500 customers).
  • Fixed AWS cost is essentially zero. No always-on compute, no NAT Gateway, no API Gateway.
  • The weekly scoring run costs pennies — no model calls.
  • Bedrock fires only on support-ticket mood, the weekly reasons, and the monthly summary.
  • At 2,000 customers the bill is around $5. At 5,000 customers it’s around $9.

Cost at three volumes

Monthly cost at three customer volumes, broken out by component A vertical stacked-bar chart showing monthly cost in US dollars at three customer volumes. The leftmost bar represents 500 customers and shows a total around $2, dominated by the everything-else slice (Lambda, DynamoDB, S3, EventBridge Scheduler, CloudWatch) with a tiny sliver for Bedrock and a tiny sliver for the order-feed import. The middle bar represents 2,000 customers and shows a total around $5, with the same shape — the everything-else slice grows roughly linearly with customer count because the weekly run still scores every customer. The rightmost bar represents 5,000 customers and shows a total around $9, with everything-else still dominant; Bedrock stays small in absolute terms because it only fires on incoming support tickets, the weekly reason write-up, and the monthly summary. Below the chart is a legend explaining the four sections of each bar: Bedrock (support mood, weekly reasons, monthly summary), order-feed import (reading the daily order export), AWS Budgets and Secrets Manager (small fixed amounts), and an everything-else bucket for Lambda runtime, DynamoDB on-demand, S3, EventBridge Scheduler, SES (inbound and outbound), and CloudWatch. A note at the bottom: the weekly run is the dominant cost, and even that is fractions of a cent per customer per week. $0 $5 $10 $15 $20 500 ~$2 2,000 ~$5 5,000 ~$9 Bedrock (mood + weekly reasons + summary) Order-feed import (daily export) AWS Budgets + Secrets Manager (fixed) Everything else (Lambda, DDB, S3, Scheduler, SES, CloudWatch) The weekly run is the dominant cost — and even that is fractions of a cent per customer per week.
Fig 6. Monthly cost at three customer volumes. Bedrock and the order-feed import are small slivers because they only fire on incoming tickets, the weekly reasons, and the daily export. The dominant cost is the everything-else bucket: the weekly run scoring every customer.

Where the dollars actually go

Lambda runtime (the bulk). The scorer runs once a week. Each run reads the customer CSV from S3, iterates the rows, sums the signal points for each, and decides on a band. At 500 customers, that’s a few hundred milliseconds. At 5,000 it’s a couple of seconds. Either way it’s pennies a month. Add the hand-off Lambda building one list per owner, the Function URL Lambda for outcome buttons, the order-import Lambda running daily, the support-mood Lambda firing per ticket, and the drive-sync Lambda every fifteen minutes — the Lambda total still lands under a dollar at all three volumes.

DynamoDB on-demand. Two small tables: cp-state and cp-audit. Reads are dominant during the weekly run (one read per customer, plus recent state). Writes are list events and outcome rows. Pennies a month at any of these volumes.

S3 + Storage. The mirrored customer CSV, the daily order exports, and the archived support MIME. A few MB total at SMB volume. Effectively free.

EventBridge Scheduler. The weekly scoring rule, the daily import trigger, and the hourly housekeeping. A handful of invocations a day. Pennies.

SES. Inbound for the support lane: $0.10 per thousand received messages (a few cents a month for an SMB). Outbound for email-fallback lists: $0.10 per thousand sent. Both are negligible at this scale.

Bedrock (only when something fires it). The weekly scoring run uses no Bedrock. The support-mood lane fires Haiku 4.5 once per forwarded ticket: a few hundred input tokens and one word out, so a tiny fraction of a cent each. The hand-off fires Haiku 4.5 once per name on the weekly list to write the plain reason — at five names per owner, that’s a handful of small calls a week. The monthly summary is one larger call. At SMB ticket and list volume, Bedrock costs cents.

The order-feed import. Reading the daily export and updating rows is plain Lambda and Sheets-API work — no model, no special service. Counted on its own because it runs every day, but it’s still a sliver: a short run over one file, once a day.

What doesn’t cost money

  • API Gateway. Replaced by a Lambda Function URL for the outcome buttons.
  • NAT Gateway. Nothing is in a VPC. No NAT, no $32/month minimum.
  • Always-on compute. No EC2, no Fargate. The scorer wakes once a week and sleeps the rest.
  • A Knowledge Base. The list is structured rows and the score is plain arithmetic — deterministic math beats vector search here. No embeddings, no Knowledge Base, no S3 Vectors needed.
  • Models on the score. The weekly decision is plain Python. Bedrock fires only on mood, the weekly reasons, and the summary.

How the cost scales

Lambda runtime grows roughly linearly with customer count, because every customer is scored on every run. DynamoDB grows linearly too. Bedrock is uncorrelated with customer count — it only fires when a support ticket arrives, when a name needs its weekly reason, or when it’s the first of the month. So the bill at 10,000 customers is around $16; at 20,000 it’s around $30. Past those volumes the weekly-full-scan model probably stops being right (you’d switch to scoring only customers whose signals changed that week), but those are optimizations for very large lists — not redesigns.

Set an AWS Budgets alarm at $15/month so anything unusual pages you before the bill matters. The predictor’s normal-volume bill stays well under that ceiling — and one saved customer usually pays for a year of it.

Last post in the series: the engineering reference. Same system, drawn for engineers — service names, Lambda inventory, IAM scopes, DynamoDB schemas, SES rule set, and EventBridge Scheduler config.

All posts