DEV Community: Ashish Sikka

How a photo marketplace cut its face search bill 56% by moving off AWS Rekognition

Ashish Sikka — Fri, 06 Nov 2026 10:31:44 +0000

This article was written with AI.

Disclosure: I work on SightRadar, the API this team moved to. The figures for sellphotos.online are the ones they reported, and the full case study is at sightradar.com/customers/sellphotos. The audit scripts below run against your own Rekognition account, whatever you decide afterwards.

sellphotos.online sells event photos. Photographers upload weddings, marathons and corporate events, a guest uploads a selfie, and face search finds every photo that guest is in. They ran it on AWS Rekognition until the bill reached about $3,500 a month. After moving to SightRadar they pay about $1,550, for the same photos and the same number of searches. By their figures that is 56% less. They also found more faces in crowd shots, which had been their bigger complaint.

This post breaks a Rekognition face search bill into its three lines, shows how to measure each one from your own account, and then covers what changed for them.

The three lines on a face search bill

Indexing. Every IndexFaces call is billed per image. In us-east-1 the first million Group 1 images a month cost $0.0010 each.
Searching. SearchFacesByImage (search with a selfie) and SearchFaces (search with a stored face id) are Group 1 calls at the same per-image rate.
Storage. Every face you keep in a collection is a stored face vector, billed at $0.00001 per vector per month, which is $10 per million faces. AWS applies the charge monthly and pro-rates partial months (pricing page). User vectors are billed the same way.

The first two lines follow traffic. The third follows what you keep, so it is charged every month whether anyone searches the collection or not. It is also per face, not per photo: a group shot with 40 people in it adds up to 40 vectors.

For a young platform, storage is small. For an event platform that keeps years of past events searchable, it becomes a fixed monthly cost that keeps growing unless you delete old collections.

The chart is list-price arithmetic, not sellphotos.online's data. Their case study does not attribute any of their saving to storage.

Measure your storage line

DescribeCollection returns FaceCount and UserCount for each collection. Multiply by the list price and you have the storage line before the invoice arrives. Collections are regional, so run it for every region you use, and change the price if yours differs from us-east-1:

import boto3

REGION = "us-east-1"
PER_VECTOR_MONTH = 0.00001  # us-east-1 list price for face and user vectors

rek = boto3.client("rekognition", region_name=REGION)

total = 0
for page in rek.get_paginator("list_collections").paginate():
    for cid in page["CollectionIds"]:
        c = rek.describe_collection(CollectionId=cid)
        vectors = c["FaceCount"] + c.get("UserCount", 0)
        total += vectors
        print(f"{cid:40} {vectors:>13,}  ${vectors * PER_VECTOR_MONTH:>9,.2f}/month")

print(f"{'total':40} {total:>13,}  ${total * PER_VECTOR_MONTH:>9,.2f}/month")

Sort the output and look at the biggest collections. If some belong to events nobody has searched in a year, the cheapest fix needs no migration at all: set a retention window and delete collections once they pass it.

Count the faces you are not indexing

Cost was half of their problem. The other half was guests who searched and came up empty because their face in the back row of a group shot was never indexed.

Rekognition tells you about some of those faces. IndexFaces returns UnindexedFaces, each with a list of Reasons such as SMALL_BOUNDING_BOX, LOW_FACE_QUALITY or EXCEEDS_MAX_FACES. By default, IndexFaces chooses the quality bar that filters detected faces. It also indexes at most 100 faces per image. When it has more faces than MaxFaces, it drops the lowest quality ones first, then the smallest (API reference).

Run a sample of your hardest photos into a scratch collection and tally the reasons:

import re
from collections import Counter

import boto3

REGION = "us-east-1"
rek = boto3.client("rekognition", region_name=REGION)
BUCKET = "your-photo-bucket"  # must be in the same region as the client
sample_keys = [...]  # a few hundred crowd shots from one event
SCRATCH = "audit-scratch"

rek.create_collection(CollectionId=SCRATCH)
indexed, reasons = 0, Counter()
try:
    for key in sample_keys:
        res = rek.index_faces(
            CollectionId=SCRATCH,
            Image={"S3Object": {"Bucket": BUCKET, "Name": key}},
            # ExternalImageId allows only [a-zA-Z0-9_.\-:], up to 255 characters
            ExternalImageId=re.sub(r"[^A-Za-z0-9_.\-:]", "_", key)[:255],
        )
        indexed += len(res["FaceRecords"])
        print(f"{key}: {len(res['FaceRecords'])} indexed, {len(res['UnindexedFaces'])} dropped")
        for face in res["UnindexedFaces"]:
            reasons.update(face["Reasons"])
finally:
    rek.delete_collection(CollectionId=SCRATCH)  # stored faces are billed until deleted

print("indexed:", indexed)
for reason, n in reasons.most_common():
    print(f"dropped ({reason}): {n}")

500 photos cost $0.50 to index at the first-tier rate. Two limits on what this tells you:

UnindexedFaces only lists faces the detector found and then dropped. A face it never detected does not appear anywhere in the response.
AWS documents a minimum detectable face of 40 by 40 pixels in a 1920 by 1080 image (limits). In a wide group shot, the back rows are often near that size.

So finish the audit by eye. Take 20 group photos, count the faces yourself, and compare against FaceRecords. The gap is faces in those photos that no search can match as they are indexed today.

What sellphotos.online found

They did not switch on the strength of a pricing page. They indexed about 5,000 photos from a recent wedding into a test collection and compared search results with Rekognition's on the same photos. Then, for a day, every live guest search went to both providers.

SightRadar found more faces in group shots. Its detector scans each photo at several scales, which catches smaller faces that a single-scale pass misses. Ranking order differed slightly in a few searches, but every face Rekognition found, SightRadar found too. Within the first month the support team noticed fewer "my photos didn't show up" complaints. They did not measure it formally.

One trade-off to plan for: finding more faces means storing more faces. Every extra face in the back row is another vector on the storage line. At these prices that is small, but put it in the estimate.

The move also had costs of its own. Re-indexing the back catalogue took longer than they hoped, and they paid both providers while it ran. They spent a day re-deriving their match threshold, because Rekognition scores similarity from 0 to 100 and SightRadar from 0 to 1, and a cut-off copied from one model is wrong on another. The threshold guide covers the method.

Their bill

The bill went from about $3,500 to about $1,550 a month. Those are the totals they reported, without a line-by-line breakdown. At list prices no single line is more than 40% cheaper, so the rate gap alone does not account for 56%. Treat it as their result, not a rate to plan on, and run your own numbers.

List prices, line by line

Line	AWS Rekognition (us-east-1, first tier)	SightRadar
Index a photo	$0.0010	$0.00062 batch, $0.00093 real-time
Search with a selfie	$0.0010	$0.00093 (billed as a real-time photo)
Search with a stored face id	$0.0010	$0.00062
Keep 1M faces for a month	$10.00	$6.00

Batch indexing is 38% under Rekognition's first tier, real-time calls are 7% under, and storage is 40% under. SightRadar charges storage daily for the faces held that day. Creating and deleting collections is free.

A worked example from the pricing page: 100,000 photos indexed in a month, 2,400 selfie searches and 300,000 stored faces.

Rekognition: $100.00 indexing + $2.40 search + $3.00 storage = $105.40
SightRadar: $62.00 batch indexing + $2.23 search + $1.80 storage = $66.03

At that size storage is a rounding error. At 50 million faces it is $500 a month on Rekognition and $300 on SightRadar, charged in a month when nobody searches at all.

Where the gap narrows

High volume. Rekognition's per-image rate falls in tiers: $0.0008 after the first million Group 1 images a month, $0.0006 after 5 million, $0.0004 after 35 million. Every image past the first million costs less on Rekognition than SightRadar's real-time rate. Averaged over the month, an all-real-time workload costs less on Rekognition from about 1.5 million images, and an all-batch workload from about 37 million.
You use more than faces. Labels, text detection, celebrity recognition, video and user vectors are Rekognition features SightRadar does not support. The shim raises NotImplementedError for them.
You are not on Python. The Rekognition shim, which let them keep their boto3 integration, is Python only. On Node or Java you map the calls to the REST API yourself.

Your saving depends on how much of your volume can go through batch, how many billed calls you make per photo, how many faces you keep, and how carefully you calibrate the threshold. Run the two scripts above against your own account before you decide anything.

Moving face search off AWS Rekognition in two days: a photo marketplace's playbook

Ashish Sikka — Fri, 06 Nov 2026 05:00:55 +0000

This article was written with AI.

Disclosure: I work on SightRadar, the API this team moved to. The figures below are the ones sellphotos.online reported. The full case study is at sightradar.com/customers/sellphotos.

sellphotos.online is a marketplace where event and sports photographers upload their shots and guests buy the ones they appear in. A guest uploads a selfie and the platform finds every photo that person is in. They process hundreds of thousands of photos a month across weddings, marathons and corporate events.

They ran this on AWS Rekognition and had two problems with it. The bill had grown to about $3,500 a month. And in crowd shots, the smaller faces in the back rows were often missed, so guests searched for themselves and came up empty. Those guests complained to the photographer, and the photographer complained to the platform.

They moved face search to SightRadar in about two days. This post is the playbook they followed, with code. Most of it applies whichever provider you move to.

What you are actually migrating

A selfie-search product on Rekognition is three things:

A collection of faces indexed from every uploaded photo (IndexFaces).
A search on every guest visit (SearchFacesByImage).
A threshold that decides what counts as a match.

The first two are API calls, and they port. The third is a number tuned to one vendor's model, and it does not. Most bad migrations go wrong at the threshold, not at the API.

Step 1: test on one real event

They set up a test collection, indexed about 5,000 photos from a recent wedding, and compared search results against what Rekognition returned for the same photos.

Pick an event with the hard cases in it: group shots, people far from the camera, bad light. Every provider handles a well-lit portrait, so clean photos tell you nothing.

Their backend is mostly Python, so they used the Rekognition shim. It keeps boto3's method names, arguments and response shapes, so the change is the import and the constructor:

from sightradar_rekognition_shim import client   # was: import boto3

rek = client(api_key="frs_...")                    # was: boto3.client("rekognition")

rek.create_collection(CollectionId="test-wedding")
rek.index_faces(
    CollectionId="test-wedding",
    Image={"URL": "https://cdn.example.com/wedding/0001.jpg"},
    ExternalImageId="0001",
)

Two things to know before you start:

The shim maps Image={"S3Object": ...} to a public S3 URL, which has to be fetchable. A private bucket needs a URL the API can fetch, such as a presigned one passed as {"URL": ...}.
The shim is Python only (PyPI). On Node or Java you map the calls to the REST API yourself, which is more work than swapping an import.

Step 2: batch re-index the back catalogue

This was the biggest chunk of work: hundreds of thousands of existing photos. Indexing them one synchronous call at a time is slow at that volume. Instead they used the batch endpoint, which takes up to 1,000 photo URLs per call and delivers one webhook per photo as results land. They scripted the submissions and let it run overnight.

import os
import requests

BASE = "https://api.sightradar.com"
HEADERS = {"Authorization": f"Bearer {os.environ['SIGHTRADAR_API_KEY']}"}

def submit(collection_id, photos, webhook_id):
    """photos: up to 1,000 dicts of {"url": ..., "external_id": ...}"""
    r = requests.post(f"{BASE}/v1/batches", headers=HEADERS, timeout=30, json={
        "collection_id": collection_id,
        "op": "index",
        "webhook_endpoint_id": webhook_id,
        "photos": photos,
    })
    r.raise_for_status()
    return r.json()["batch_id"]

# all_photos: your catalogue as {"url", "external_id"} dicts; WEBHOOK_ID from POST /v1/webhooks
for i in range(0, len(all_photos), 1000):
    print(submit("events", all_photos[i:i + 1000], WEBHOOK_ID))

Each webhook carries your external_id, a status, and on failure an error.code such as image_fetch_failed. Failed photos are not charged. Keep a list of them and resubmit once you have fixed the cause. The batch guide covers registering the endpoint and verifying signatures.

Plan for this step to take longer than you expect. It did for them. While it runs you are paying both providers, because live uploads still go to the old one. That double cost is short, but put it in the budget.

Step 3: run both providers side by side

For the next day, every guest search went to both providers and they compared the ranked results. The shim returns Rekognition-shaped responses, so the comparison is short:

import boto3
from sightradar_rekognition_shim import client

aws = boto3.client("rekognition", region_name="us-east-1")
sr = client()  # reads SIGHTRADAR_API_KEY

# Start loose on both sides: you are comparing what each provider finds,
# not deciding matches yet. That is step 4.
AWS_THRESHOLD = 70
SR_THRESHOLD = 50  # the shim divides by 100, so this is 0.5 cosine

def photo_ids(rek, threshold, selfie):
    res = rek.search_faces_by_image(
        CollectionId="events",
        Image={"Bytes": selfie},
        FaceMatchThreshold=threshold,
        MaxFaces=100,
    )
    return {m["Face"]["ExternalImageId"] for m in res["FaceMatches"]}

selfie = open("guest.jpg", "rb").read()
a = photo_ids(aws, AWS_THRESHOLD, selfie)
b = photo_ids(sr, SR_THRESHOLD, selfie)
print(f"both: {len(a & b)}  only AWS: {len(a - b)}  only SightRadar: {len(b - a)}")

Look at the "only" sets by eye. They tell you more than any aggregate number.

In their case, SightRadar found more faces in group shots. Its detector scans each photo at several scales, which catches smaller faces that a single-scale pass misses. The ranking order differed slightly in a few searches, but every face Rekognition found, SightRadar found too.

Step 4: re-derive the threshold

This is the step people skip, and then they blame the new provider when results look off.

Rekognition scores similarity from 0 to 100. SightRadar returns cosine similarity from 0 to 1. The shim converts the scale both ways, but converting the scale does not convert the decision. Two models put the same "same person" call at different scores, so a cut-off copied from Rekognition is wrong on the new model.

They spent a day on this with known match and non-match pairs from their test events. The method is short:

Collect a few hundred same-person pairs and a few hundred different-person pairs from your own photos: same cameras, same venues, same lighting.
Score every pair.
Pick your cut-offs from the scores: accept above nearly all of the different-person scores, and review the band below that where most real matches still sit.

def score(url_a, url_b):
    r = requests.post(f"{BASE}/v1/compare", headers=HEADERS, timeout=30,
                      json={"sourceUrl": url_a, "targetUrl": url_b})
    r.raise_for_status()
    body = r.json()
    return body["similarity"] if body["face_found"] else None

# same_person_pairs / different_person_pairs: lists of (url_a, url_b) you labelled by hand
same = sorted(s for a, b in same_person_pairs if (s := score(a, b)) is not None)
diff = sorted(s for a, b in different_person_pairs if (s := score(a, b)) is not None)

# Accept automatically above the score that lets through at most ~1% of
# different-person pairs. Below that, down to where 95% of real matches sit,
# ask the guest "Is this you?" instead of hiding the photo.
accept = diff[int(len(diff) * 0.99)]
review = same[int(len(same) * 0.05)]
print(f"accept >= {accept:.3f}; review band {min(review, accept):.3f} to {accept:.3f}")

Each compare is billed as two photos ($0.00186 a pair), so 600 pairs costs about $1.12. Two bands usually beat a single cut-off for photo discovery, because a wrong suggestion is cheap when the guest confirms it. The threshold guide goes further on picking bands.

Step 5: cut over

By now every existing photo was indexed in both systems, so the cutover was a config change: new index calls and searches went to SightRadar. If you can afford it, keep the old collection for a while so rolling back is also just a config change.

What they reported afterwards

The bill went from about $3,500 to about $1,550 a month, for the same photos and the same number of searches.
Fewer "my photos didn't show up" tickets within the first month. They didn't track it formally; the support team noticed fewer of those complaints.
Clearer visibility into costs: per-operation spend, search results and collection sizes in one console, instead of CloudWatch metrics and Cost Explorer tags.

For context on those numbers, here are the list prices. Rekognition's first US tier is $0.0010 per image. SightRadar's batch rate is $0.00062 per photo, 38% lower, and its real-time rate is $0.00093, 7% lower. Your saving depends mostly on how much of your volume can go through batch and on how many calls you make per photo. Run your own numbers with the pricing calculator before you decide anything.

When this is not a like-for-like swap

You use more than faces. Labels, text detection, celebrity recognition, video and user vectors are not supported. The shim raises NotImplementedError for them instead of silently doing nothing.
You are on very high volume. Rekognition's per-image rate drops to $0.0008 after the first million images a month and lower after that. At that scale the gap narrows, and for real-time calls it can flip.
You are not on Python. There is no shim for other AWS SDKs.
You rely on final deletes. Deleting a collection is a restorable soft delete by default. Pass Immediate=True through the shim if you need Rekognition's finality.