How much does it cost to run?

About $2.40/month at typical small-business volume (around 200 photos a month). The fixed cost is essentially zero. The variable cost is dominated by the Bedrock vision call that reads each photo and drafts its details; everything else — Lambda, DynamoDB, S3, the resize step — is pennies. At 2,000 photos a month the bill lands around $15.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the approve and edit buttons, S3 (with versioning) for the photo drop folder and resized copies, DynamoDB on-demand for draft state and the audit trail, SQS with a dead-letter queue to smooth out batch uploads, SES outbound for the review email, Secrets Manager and Parameter Store for config, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 vision via Global cross-Region inference) to read each photo and draft its details. No API Gateway, no NAT Gateway, no always-on compute.

Where do the photos and drafts live?

Photos land in a Google Drive folder you control, or are dropped straight into an S3 bucket. A small drive-sync Lambda mirrors new files to S3 every few minutes. Each draft — title, alt text, tags, category, description — is stored as a row in DynamoDB and shown in a review email and a simple web card. Nothing is written to your store until you approve it.

Does the photo tagger use AI?

Yes, but only where it earns its place. A cheap deterministic step resizes each photo and runs basic quality checks (too dark, too blurry, too small) with no model at all. Bedrock Claude Haiku 4.5 with vision fires once per photo to read the image and draft the title, alt text, tags, category, and description. There is no model on the quality checks and none on the approve step — those are plain Python.

What stops a wrong or bad photo from going live?

Two layers. First, a deterministic quality gate rejects photos that are too dark, too blurry, too small, or oddly shaped before any model runs. Second, the model is asked to say when the photo doesn't look like a clean product shot — a screenshot, a receipt, a person, an empty box — and to mark its own confidence per field. Anything low-confidence or wrong-looking is flagged for a human instead of drafted as if it were fine. And nothing reaches your store without an explicit approval.

What happens when I review a draft?

Each draft arrives as a card with the photo and the drafted title, alt text, tags, category, and description. Three buttons: Approve writes the listing fields to your store (or to an export sheet) and archives the draft; Edit opens a form pre-filled with the draft so you can fix a word and then approve; Reject sends the photo to a flagged folder with a reason. Every action is recorded in an audit table with timestamp, photo, action, and who did it, so the trail is clear and reversible.

Series · 7 parts Published June 8, 2026

Photo tagger

A serverless tagger that saves an online shop hours of typing. When new product photos land, it looks at each one and drafts the boring-but-important details — a clear title, alt text for accessibility, suggested tags and category, and a short description — so listings stay consistent and searchable. The owner reviews and approves; it never publishes a listing on its own, and it flags low-quality or wrong-looking images for a human. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A product photo tagger on AWS for a few dollars a month

The whole system on one page — a photo intake, a reader that drafts details, and a review piece, plus the safety rails that keep a wrong photo from ever reaching your store.
02

How a product photo gets read

Two ways a photo gets in — a Drive folder and a direct S3 drop — then a resize-and-check step that shrinks the image and runs plain quality checks before any model looks at it.
03

How photo details get drafted

One Bedrock vision call reads the photo and drafts five fields — title, alt text, tags, category, description — each with a confidence score, against the rules and word list in your style doc. No invented details.
04

How a bad photo gets flagged

Two layers catch a wrong or low-quality image — a deterministic quality gate before any model, and a model self-check that spots screenshots, receipts, people, and empty boxes — so a human looks instead of a bad draft going out.
05

How a listing gets approved

Three actions on every draft card: approve (write the fields to your store or an export sheet), edit (fix a word, then approve), and reject (send to a flagged folder with a reason). Every action is logged.
06

What the photo tagger costs

A few dollars a month at SMB volume. The system runs only when a photo lands, and the only real cost is the one Bedrock vision call per photo that drafts the details.
07

Engineering reference: the photo tagger architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SQS and S3 event wiring, and the DynamoDB schemas.

What is a product photo tagger?: A small serverless system that watches a folder for new product photos. When one lands, it looks at the image and drafts the boring-but-important listing details — a clear title, alt text for accessibility, suggested tags and category, and a short description — so listings are consistent and searchable. The owner reviews and approves each draft. The system never publishes a listing on its own, and it flags low-quality or wrong-looking images for a human.
How much does it cost to run?: About $2.40/month at typical small-business volume (around 200 photos a month). The fixed cost is essentially zero. The variable cost is dominated by the Bedrock vision call that reads each photo and drafts its details; everything else — Lambda, DynamoDB, S3, the resize step — is pennies. At 2,000 photos a month the bill lands around $15.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the approve and edit buttons, S3 (with versioning) for the photo drop folder and resized copies, DynamoDB on-demand for draft state and the audit trail, SQS with a dead-letter queue to smooth out batch uploads, SES outbound for the review email, Secrets Manager and Parameter Store for config, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 vision via Global cross-Region inference) to read each photo and draft its details. No API Gateway, no NAT Gateway, no always-on compute.
Where do the photos and drafts live?: Photos land in a Google Drive folder you control, or are dropped straight into an S3 bucket. A small drive-sync Lambda mirrors new files to S3 every few minutes. Each draft — title, alt text, tags, category, description — is stored as a row in DynamoDB and shown in a review email and a simple web card. Nothing is written to your store until you approve it.
Does the photo tagger use AI?: Yes, but only where it earns its place. A cheap deterministic step resizes each photo and runs basic quality checks (too dark, too blurry, too small) with no model at all. Bedrock Claude Haiku 4.5 with vision fires once per photo to read the image and draft the title, alt text, tags, category, and description. There is no model on the quality checks and none on the approve step — those are plain Python.
What stops a wrong or bad photo from going live?: Two layers. First, a deterministic quality gate rejects photos that are too dark, too blurry, too small, or oddly shaped before any model runs. Second, the model is asked to say when the photo doesn’t look like a clean product shot — a screenshot, a receipt, a person, an empty box — and to mark its own confidence per field. Anything low-confidence or wrong-looking is flagged for a human instead of drafted as if it were fine. And nothing reaches your store without an explicit approval.
What happens when I review a draft?: Each draft arrives as a card with the photo and the drafted title, alt text, tags, category, and description. Three buttons: Approve writes the listing fields to your store (or to an export sheet) and archives the draft; Edit opens a form pre-filled with the draft so you can fix a word and then approve; Reject sends the photo to a flagged folder with a reason. Every action is recorded in the pt-audit DynamoDB table with timestamp, photo, action, and who did it, so the trail is clear and reversible.

All posts

Frequently asked questions

Other series