Mozrest connects restaurants with reservation platforms across Europe. Their technology acts as a bridge between restaurant management systems and major online reservation platforms, synchronizing availability, bookings, and customer data in real time.
When the volume of processed reservations started growing steadily, the AWS infrastructure they had built during their early stages began showing its limits. It was not a conceptual problem. It was a scaling problem.
This case study describes how we redesigned their cloud architecture to support growth without sending costs through the roof.
The Challenge
Mozrest’s platform had grown organically. What started as a monolithic application on EC2 worked fine with a few dozen restaurants. But with hundreds of active restaurants across multiple European countries and thousands of daily reservations, problems were compounding.
Fragile Infrastructure
The core application ran on manually managed EC2 instances. There was no multi-AZ redundancy, meaning a failure in a single availability zone could take down the entire service. For a reservation platform, every minute of downtime means lost bookings and frustrated restaurant owners.
Uptime hovered around 99.5%. That sounds like a high number, but it translates to over 43 hours of downtime per year. In hospitality, where peak reservation times are concentrated in very specific windows, a failure at the wrong moment has a disproportionate impact.
Costs Growing Faster Than Revenue
The AWS bill was growing faster than the business. Oversized instances running 24/7 without adjusting to actual demand, orphaned EBS volumes, unoptimized data transfer, and no Reserved Instances or Savings Plans whatsoever. There was zero visibility into where each euro was going.
Manual and Risky Deployments
Every deployment was a high-risk event. The manual process took 2 to 3 hours, required direct intervention on the servers, and had no automated rollback. This limited deployment frequency and slowed down the product team’s ability to iterate.
Database as a Bottleneck
The PostgreSQL database ran on a manually managed RDS instance with no auto-scaling and only basic backup configuration. As data volume grew, queries slowed down. The absence of a caching layer meant every request hit the database directly.
The Solution
We conducted a full infrastructure audit before changing anything. This is a principle we always follow: before migrating, you need to understand exactly what exists, what it costs, and what hurts. The audit revealed that 40% of the monthly spend could be eliminated without changing the architecture. But optimizing costs on a fragile architecture makes no long-term sense. We decided to redesign.
From EC2 Monolith to ECS Fargate Microservices
We migrated the monolithic application to Docker containers orchestrated with ECS Fargate. The decision to use Fargate instead of ECS on EC2 was deliberate: it eliminates the need to manage underlying instances, reduces operational overhead, and allows each service to scale independently.
The migration was not a big bang. We extracted services one by one, starting with the most independent and lowest-risk ones. The monolith and the new microservices coexisted for weeks until the transition was complete. This incremental approach reduced risk and allowed the Mozrest team to keep shipping features during the migration.
Aurora PostgreSQL Serverless v2
We replaced the self-managed RDS instance with Aurora PostgreSQL Serverless v2. The benefits were immediate:
- Auto-scaling: Aurora adjusts compute capacity based on demand. During peak reservation hours, it scales up. During off-peak hours, it scales down. No manual intervention needed.
- Native high availability: Automatic multi-AZ replicas with failover in under 30 seconds.
- Continuous backups: Point-in-time recovery with 35-day retention, with zero performance impact.
Caching Layer with ElastiCache (Redis)
We implemented ElastiCache with Redis for two primary functions: session management and frequently accessed data caching. Restaurant availability queries, which previously hit the database on every request, are now served from cache with TTLs tuned to the actual update frequency.
The result was a 70% reduction in direct database queries and significantly lower API response times.
CDN and Static Assets
We configured CloudFront as a CDN in front of S3 to serve all static assets. This reduced latency for end users across Europe and offloaded traffic from the application servers.
CI/CD with GitHub Actions and CodeDeploy
We designed a complete CI/CD pipeline:
- GitHub Actions for running tests, building Docker images, and validating infrastructure.
- Amazon ECR as the container image registry.
- CodeDeploy with blue/green deployments for zero-downtime updates.
- Automatic rollback if health checks fail after deployment.
The Mozrest team went from deploying with fear to deploying multiple times a day with confidence.
Infrastructure as Code with Terraform
All infrastructure was codified in Terraform. Every AWS resource, from ECS clusters to IAM policies, was version-controlled in Git. This enabled:
- Reproducing the complete environment in minutes.
- Reviewing infrastructure changes through the same code review process used for application code.
- Maintaining consistency between staging and production environments.
Cost Optimization
Beyond the architectural redesign, we applied targeted cost optimizations:
- Savings Plans for Fargate compute with a 1-year commitment, reducing the compute cost per hour by 30%.
- S3 Lifecycle Policies to automatically move old data to S3 Glacier.
- VPC Endpoints to eliminate data transfer costs between AWS services that were previously routed through the public internet.
- Continuous right-sizing with AWS Compute Optimizer to match each Fargate task’s resources to actual consumption.
Results
The numbers speak for themselves:
- 99.99% uptime, up from approximately 99.5%. Less than 53 minutes of downtime per year, with automatic multi-AZ failover.
- 40% reduction in monthly AWS costs, combining the migration to Fargate, Aurora Serverless, Savings Plans, and the elimination of underutilized resources.
- 3x throughput capacity without additional infrastructure. The platform can process three times more reservations per second than before the migration.
- Deployments in under 10 minutes, down from 2-3 hours. With zero-downtime and automatic rollback.
- Complete disaster recovery plan, with RPO under 5 minutes and RTO under 30 minutes.
Lessons Learned
Start with the Cost Audit, Not the Migration
The initial audit allowed us to identify immediate savings that partially funded the migration. More importantly, it gave us a precise map of the existing infrastructure, its dependencies, and its real pain points. Without that map, architecture decisions would have been speculative.
Container Migration Does Not Have to Be All-or-Nothing
The incremental approach, service by service, reduced risk and allowed the Mozrest team to maintain their development velocity throughout the process. There was no “D-Day” migration. There was a gradual, controlled transition.
Invest in Infrastructure as Code Before Scaling
Terraform allowed us to iterate on the architecture with the same discipline we apply to application code. Every infrastructure change went through a pull request, review, and approval. This prevented manual configurations that get lost, forgotten, or contradict each other across environments.
Cost Optimization Is an Ongoing Process
Reducing the bill by 40% was the initial result. But the real value lies in having established the processes and tools for the Mozrest team to maintain that discipline autonomously. AWS Budgets, Cost Explorer, Compute Optimizer, and Savings Plans are not one-time configurations: they are practices that require periodic review.
If your AWS infrastructure is growing faster than your business, or if you need to scale without multiplying costs, we can help. Request a free audit to analyze your current situation and define a concrete action plan.
For more context on AWS architecture, see our guide on AWS architecture for startups.