iGaming Operator

Finding $90,000 a year in one Aurora setting

Your AWS bill keeps climbing, and nobody on your team can explain why. The engineers who built the infrastructure are gone, the documentation left with them, and every resource looks load-bearing. How do you cut cloud spend when you don't know which resources are actually doing work?

sales@itsyndicate.org

Where the money was actually going

Our client is an iGaming operator running 15 microservices on AWS. The platform grew fast, and it grew the way fast platforms usually do: get it working first, understand the bill later. Their previous engineering partner had left them with an environment nobody on the internal team could account for - unclear access control, unexplained line items, and no map of what depended on what. The client came to us disappointed by that experience and asking a simple question: "What are we paying for?"

We took over ongoing maintenance and started with the bill. Within the database layer, we found something worth writing down: a single default configuration value was holding a large block of Aurora capacity permanently online, at a cost of roughly $90,000 a year, to serve a workload that was mostly idle.

Quick facts

iGaming Operator

Online gaming platform

A licensed iGaming operator running a microservices architecture, with analytics and reporting on Amazon Redshift, Snowflake, and S3 that finance, audit, and player support all depend on.

$90,000

Cut from annual database costs

Correcting Aurora's failover priority lets serverless capacity scale with real demand instead of sitting at its ceiling. The high-availability design stayed intact.

AWS + Aurora Serverless

The infrastructure runs on ECS behind a peered VPC topology, with Amazon Aurora, RDS Proxy, and Infrastructure as Code for every change we make to it.

"No one could explain the bill. We suspected overpayment but had no way to confirm until ITsyndicate examined our bill line by line, identified the issue, and resolved it without any downtime."

Daniel Reeves

CEO, iGaming Operator

What we did for iGaming operator

Making an ownerless infrastructure consistent

You cannot optimize what nobody can describe. When we came in, a team that was no longer around had built the infrastructure at speed, so our first job wasn't cost-cutting; it was figuring out what existed, who could reach it, and which resources were genuinely serving traffic. So we started with:

A full audit of the running environment: We inventoried the AWS accounts, mapped the VPC peering between them, and traced how the ECS services actually reach the database layer - through the main production endpoint, the read-only endpoint, and RDS Proxy. That map became the reference the client's own developers had been missing.
Tightening access and codifying changes: We reviewed IAM roles and security group rules against least privilege, closed the gaps we found, and moved configuration into Terraform so that every subsequent change is version-controlled and reviewable. The point is that the next team to inherit this environment won't have to guess either.

Right-sizing Aurora without giving up high availability

A seemingly small Aurora setting was generating a surprisingly large bill. Here's how Aurora handles failover. The cluster had a provisioned writer on a db.r6g.4xlarge instance at roughly $1,300 a month, a provisioned reader of the same size, and a group of Aurora Serverless readers configured to scale between 0.5 and 16 ACUs. Aurora Capacity Units are the serverless billing unit, where one ACU is about 2 GiB of memory. So we worked through it in this order:

Diagnosing why serverless capacity never scaled down: Promotion tiers tell Aurora which instance to promote if the writer fails, and a lower tier number means higher priority. The serverless readers had been left at the default tier, giving them the same failover priority as the provisioned reader. Aurora then does something reasonable: it keeps a tier-0 or tier-1 serverless reader sized to take over from the writer. The writer's 128 GiB works out to a 64 ACU equivalent, but the serverless maximum was 16 ACUs - so Aurora pinned those readers to their ceiling and held them there, around the clock, whether or not there was any load. Across production and staging, that idle capacity accounted for roughly $7,500 a month.
Correcting failover priority and validating the result: We moved the serverless readers to a lower-priority promotion tier and left the equally sized provisioned reader as the designated failover candidate. Aurora immediately released the capacity it had been reserving, and the serverless readers dropped to around 0.5 ACU at idle while still scaling up under load. Failover behavior was unchanged, because the instance that gets promoted is now the one actually built to be promoted. We could have pushed the floor closer to zero, but after modeling the read patterns, we judged the current settings sufficient.

Aurora cost optimization: FAQ

Our cloud bill is growing and nobody can explain it. Where do you actually start?

With the bill itself, not with assumptions. Cost problems are usually visibility problems wearing a disguise.

We begin by attributing spend to workloads, which means tagging resources consistently, building spend dashboards, and setting budget alerts so the numbers stop being a monthly surprise.

Only then do we look for waste, and we look at the largest line items first. In this client's case the database layer was the single biggest opportunity, and the fix turned out to be one configuration value.

How can one configuration value cost $90,000 a year?

Because cloud platforms make sensible decisions on your behalf, and sensible decisions cost money when the inputs are wrong.

Aurora saw a serverless reader with a high failover priority and a writer holding 128 GiB of memory. To honour that priority it kept the reader as large as it was allowed to be. Nothing failed and no alarm went off - the capacity was simply never released.

Multiply that across several readers and two environments and you get $7,500 a month for compute that was doing almost nothing.

Doesn't scaling the database down put high availability at risk?

Not when the change is to failover priority rather than to failover capability. This is the distinction that matters.

The cluster still has a same-size provisioned reader ready to be promoted, and it is now first in line rather than competing with instances that were never sized for the job.

We validate this rather than assume it: we confirm the promotion order, check replica lag, and rehearse the failover path before we consider the work finished.

The previous team left us with infrastructure nobody understands. How do you handle that?

We treat documentation as a deliverable, not a courtesy. An environment that only one vendor can operate is a risk, whoever that vendor is.

We audit what is running, map the dependencies, and hand your engineers the diagrams and runbooks. Configuration goes into Terraform so the environment can be read as code instead of reverse-engineered from the console.

The goal is that your team can answer questions about your own infrastructure without calling us.

How do you stop costs from creeping back up?

By making cost a standing part of maintenance instead of a quarterly panic.

We keep tagging and budget alerts in place, review right-sizing and autoscaling rules against actual demand, and watch for configuration drift - which is how most of these problems appear in the first place.

Because we handle ongoing maintenance for this client, that review is continuous rather than a one-off engagement.

We’d love to hear from you

Ready to prepare your product for the next growth level?

Talk to our team about your needs.