Serving every image size from one master file — at a fraction of the storage and compute

// the challenge

The client rendered the same photo at many sizes across web and mobile — thumbnails, list cards, full-bleed hero, retina (2x) versions, and a few crops. The old approach pre-generated every one of those variants and stored them all. A single 4000×3000 source photo (~5 MB) fanned out into 15–20 derivative files, so the real storage cost per image was closer to 30–40 MB, not 5 MB. Across a catalog of hundreds of thousands of images that multiplies into terabytes of duplicated data — most of it sizes that were rarely, if ever, requested. Worse, every one of those variants was generated up front at upload or build time, burning compute to produce crops no user might open, and any design change (a new card size, a new aspect ratio) meant reprocessing the entire library.

// our approach

• Deployed the AWS Serverless Image Handler: a Lambda function fronted by CloudFront that resizes, crops, and converts format on demand, driven entirely by URL parameters.
• Kept a single master image in S3; every size is derived from it at request time instead of being stored as a separate file.
• Cached each rendered variant at the CloudFront edge, so the Lambda runs once for a given size and every subsequent request is served from cache with zero compute.
• Codified the whole stack as infrastructure as code so it deploys identically across environments and needs no manual upkeep.

// the outcome

The client now stores one image instead of twenty and pays for a resize only the first time a given size is actually requested — after which CloudFront serves it from the edge, so repeat traffic costs nothing to compute and loads faster for users worldwide. Storage dropped from terabytes of duplicated variants to the master images alone, an entire class of build-time image-processing jobs disappeared, and introducing a new size is now a URL change rather than a library-wide reprocessing run.