Series · 7 parts Published June 24, 2026

Product image cleaner

A shop owner photographs a new product on the kitchen counter with their phone and drops the snapshot into a folder. This is the design of a small serverless system that turns that raw photo into a full set of catalogue-ready images — background removed, auto-cropped and resized into the exact variant each sales channel needs, a subtle watermark where it’s allowed, written back ready to use in seconds. The background removal runs on a container Lambda; the cropping and watermarking are plain image ops; and a low-confidence cutout is never published — it’s flagged for a human to check. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

  1. 01

    A product image cleaner on AWS for a few dollars a month

    The whole system on one page — a photo lands in a folder, an S3 upload event starts the pipeline, a container Lambda removes the background, plain image ops cut the channel variants, and the finished set is written back, with a review lane for doubtful cutouts.

  2. 02

    How a raw photo gets ingested

    How a raw phone photo becomes a job — the watched folder and email lane that land it in S3, the upload event that triggers the pipeline, and the normalisation that turns a 3,000-pixel HEIC into a clean, oriented working file.

  3. 03

    How a background gets removed

    How the background gets removed — why it runs in a container Lambda on arm64 with extra memory, what rembg and U^2-Net actually do, and the confidence check that sends a doubtful cutout to review instead of onward.

  4. 04

    How channel variants get made

    How the channel variants get made — auto-cropping to the product, padding to a safe area, resizing to each channel’s exact spec, compositing onto white, and the watermark rule that keeps marketplace images clean.

  5. 05

    How a cleaned image gets published

    How a cleaned image gets published — writing the finished set back to S3 under per-channel prefixes, the manifest that records what was made, the notification that says it’s ready, and why nothing overwrites the original.

  6. 06

    What the product image cleaner costs

    A line-by-line monthly cost at about $3.40 for roughly 400 images, why the background-removal container Lambda is the biggest variable line, and what the bill looks like at ten times the volume.

  7. 07

    Engineering reference: the product image cleaner architecture

    The same system drawn for engineers — the zip and container Lambda inventory with memory and runtime, the S3 buckets and event notifications, the DynamoDB job table and key schema, IAM scope, and the region.

What is a product image cleaner?
A small serverless system that turns a raw phone photo of a product into catalogue-ready images. You drop a snapshot into a folder; it ingests the file to S3, removes the background, auto-crops and resizes the product into the exact variants each sales channel needs (a web-store image, a square marketplace image, a social image), applies a subtle watermark where the channel allows it, and writes the finished set back to S3 with a notification. It changes the pixels — it doesn’t describe them — and it never publishes a cutout it isn’t confident about.
How much does it cost to run?
About $3.40/month at typical small-business volume — roughly 400 images a month. The fixed cost is almost entirely Secrets Manager; everything else is usage-priced and rounds toward zero when no photos are coming in. The largest variable line is the container Lambda that removes backgrounds, billed on memory × duration, because that step is the one heavy compute job in the pipeline. At ten times the volume the bill lands near $13.
Which AWS services does it use?
Lambda — one container-image function on arm64 with extra memory for background removal, and zip functions for ingest, variant building, and publishing (all Python 3.14). S3 (versioned, event-triggered on upload), EventBridge for the upload event and a daily sweep, DynamoDB on-demand for job status, SES and SNS for notifications, SQS with a dead-letter queue between stages, Secrets Manager, CloudWatch Logs at 7-day retention, and AWS Budgets. One region, eu-west-2. No API Gateway, no NAT Gateway, no always-on compute.
How does the background removal work?
It runs in a container-image Lambda on arm64 with more memory than the other functions, because the model and its weights are too large for a zip package. By default it runs rembg with a U^2-Net segmentation model that produces a per-pixel alpha mask, then composites the product onto transparency; a hosted vision-model API is supported as a drop-in alternative, with its key in Secrets Manager. The function also measures how much of the frame the cutout covers and how cleanly the edges resolved, so a doubtful result can be held back rather than shipped.
Does it use AI?
Only for the one step that needs it. Background removal is a learned segmentation model (U^2-Net via rembg, or a hosted vision model) that decides which pixels are product and which are background. Everything after that — cropping to the content, padding, resizing per channel, compositing onto white, and watermarking — is plain deterministic image arithmetic in Pillow. The model never picks the crop or the channel; it only produces the mask.
What if it produces a bad cutout?
It flags the image for review and never auto-publishes a low-confidence cutout. The container function scores each result on how much of the frame the product fills and how fragmented the alpha mask is; a clear vase that gets eaten away, or a busy photo where nothing was removed, falls outside the safe band. Those jobs stop at a ‘needs review’ status and the owner gets a notification with the original and the attempted cutout side by side, so a person decides — the channel variants are only built once a cutout passes.
All posts