Cutting Craft My Book's AWS Bill 3× by Going Full Serverless

Craft My Book is not your typical photo book service. With it, you don't waste hours painstakingly selecting photos from your last vacation and designing each page. Customers upload their photos and describe the occasion: a wedding, a trip to Europe, a new baby. A trained designer then creates the layout from scratch within 24 hours. The result is a professionally crafted photo book rather than an algorithmic one.

It's a great product powering some of the world's largest online photo product shops. But running it at scale is a different kind of engineering challenge.

Seasonal demand, at scale

During the holiday season in the US market alone, Craft My Book processes over 5,000 photo books and 80,000 photos per day in partnership with some of the world's largest online photography stores. Then January arrives and that demand drops sharply. Then summer holidays kick in. Then it peaks again.

This kind of workload — variable, seasonal, bursty — is one of the hardest patterns to run cost-efficiently in the cloud. And it's even harder when the system handling it is over a decade old.

The problem with the old architecture

Craft My Book started as a monolithic Django application running in containers on AWS ECS, backed by PostgreSQL on RDS. But the architecture was more sophisticated than a simple monolith.

Image analysis happened in parallel from the moment the order was submitted. A set of AWS Lambda functions ran computer vision pipelines across every image in an order simultaneously. That includes face detection, region-of-interest detection, aesthetic scoring, and zoom detection. This gave the system a rich understanding of each photo before any human or algorithm touched the layout.

Automated book design ran on Django and Celery, with background workers on ECS picking up orders once image analysis completed. A custom-built algorithmic pipeline used all that image intelligence to generate a first draft of the book automatically. It chose layouts, placed photos, and applied styling before the human designer ever opened the project. This dramatically cut turnaround times and allowed the team to handle far more orders without scaling the designer headcount proportionally.

Human designers then took that algorithmically-generated draft and applied the finishing touches. Cropping, rearranging, and adding the creative judgment that makes the product genuinely premium.

This setup worked, scaled, and kept orders flowing. But it was permanently over-provisioned.

To survive daily and holiday peaks, the team had to size the infrastructure for maximum load. Most of the time, they were paying for headroom they weren't using. The database had grown continuously for 10+ years. Every order, every photo, every design revision sitting in a single Postgres instance. Queries got slower, costs crept up. Finally, operations got more complex.

The system was not broken. It was simply not efficient, and it not built for the next decade.

Enter the AWS Migration Acceleration Program

ACP Engineering has been designing and operating Magiclabs' cloud infrastructure for several years. When the opportunity arose to modernise Craft My Book as part of the AWS Migration Acceleration Program (MAP), we took a clear-eyed look at where the real costs and friction were coming from.

Three changes would deliver the most impact:

1. Break the monolith into purpose-built microservices, each in its own AWS account
2. Replace ECS-based workloads with fully serverless compute across those services
3. Separate operational data from historical data

None of these required a full rewrite, but they all required careful engineering.

From a monolith to microservices

The old architecture was a tightly coupled system. Image analysis, book design, styling, and order management all living together. The modernisation separated these into independent microservices, each with its own AWS account, its own scaling profile, and its own deployment lifecycle.

Automated book design

The Celery background tasks and algorithmic pipeline that generated first drafts moved into a dedicated microservice, rebuilt as a fully serverless system using AWS Lambda and EventBridge. Orders trigger events. Then events trigger functions. And finally, functions compose the pipeline. No ECS workers idling between orders meaning no Celery broker to babysit.

Image analysis

The existing Lambda-based computer vision pipeline was preserved and extended. Amazon Bedrock was introduced to generate image embeddings, enabling image similarity detection across an order's photo set. This opens up smarter layout decisions such as grouping similar photos, avoiding near-duplicate placements, and better understanding the visual narrative a customer is trying to tell.

Style management

A new style library microservice now manages all the decorations, templates, and design assets associated with each partner brand's style catalogue. When a partner offers their customers a new visual theme, it lives and evolves in one place rather than staying buried inside a shared monolith.

From containers to Lambda

ECS containers are excellent for steady, predictable workloads. For Craft My Book's bursty, event-driven processing — photo ingestion, order routing, design job dispatch — they were the wrong tool.

Every step in the pipeline has a clear trigger. An order arrives, photos are uploaded, a first version of the book is designed algorithmically, a designer makes their changes and submits a completed book, a customer requests changes. These are not continuous processes, but events that trigger other ones. Lambda is exactly what they were designed for.

By migrating the core processing pipeline to AWS Lambda, the platform gained:

• Automatic scaling: Lambda scales to match demand instantly, with no manual intervention and no idle containers
• Pay-per-invocation pricing: during quiet periods, costs drop proportionally rather than staying flat
• Simplified operations: no ECS cluster management, no task definition tuning, no capacity planning for containers

The event-driven architecture also made the system's logic easier to reason about. Each function does one job, and pipelines are explicit. Any failures are thus isolated.

Right-sizing the database

The other major change was a data lifecycle strategy for PostgreSQL.

A production database that accumulates 10+ years of data without a retention policy doesn't just cost money. It slows down every query that touches it, makes backups heavier, and adds overhead to routine operations like vacuuming and index maintenance.

The solution was straightforward. To keep only the last three months of operational data in RDS PostgreSQL, and archive everything older than that to Amazon S3.

This created a proper data lake for Magiclabs including historical order data, design assets, and analytics all stored durably in S3. All of it queryable via Athena when needed. The production database instance became lean, fast, and cheap to run. The data was preserved, and simply moved somewhere more appropriate.

The outcome

The combination of serverless compute, microservice decomposition, and a disciplined data lifecycle strategy delivered a meaningful reduction in AWS spend. In December 2024 — peak holiday season — the AWS bill came in at $28,000. In December 2025, the same peak month on the new architecture, that figure dropped to $9,000. A 3× reduction, realised exactly when the platform was under maximum load.

Beyond the cost savings:

• Holiday peaks are handled automatically: no capacity planning conversations, no pre-scaling, no war rooms
• Database performance improved: smaller working set, faster queries, less operational overhead
• Services evolve independently: the style library, image analysis, and book design pipelines can each be updated and scaled without touching each other
• The engineering team spends less time on infrastructure and more time on the product itself

What other teams can take away

Craft My Book's modernisation isn't a unique story. Plenty of mature cloud applications are running on architectures that made sense five years ago but are now too expensive and too rigid.

A few patterns worth taking from this project:

Containers aren't always the right default. ECS and Kubernetes are powerful, but they carry overhead. If your workload is event-driven and bursty, serverless deserves serious consideration.

Microservice boundaries should follow ownership, not just scale. Splitting image analysis, book design, and style management into separate AWS accounts is a decision that affects both your organisation as well as your infrastructure. Each service has a clear owner, a clear purpose, and a clear blast radius if something goes wrong.

Data lifecycle is infrastructure. Letting a production database grow unbounded is a slow-moving cost and performance problem. Separating operational data from historical data — and storing the latter in S3 — is a straightforward strategy with significant returns.

Modernisation doesn't have to mean rewrite. The Craft My Book migration preserved the core product logic and business processes. The changes were targeted: decompose the monolith, swap the compute model, apply a data retention policy, build a proper archival layer.

Sometimes the biggest wins come from changing how a system runs, not what it does.