Cut infrastructure costs 85% by re-engineering a legacy AML monitoring system重構舊有洗錢防制 (AML) 監控系統，大幅削減 85% 維運成本

Situation

At a financial services firm, the monthly cloud infrastructure cost of a legacy AML monitoring platform had reached approximately $200,000. Although the system remained operational, the client considered its cost base unsustainable.

The underlying issue was not a single expensive component, but a mismatch between the platform’s architecture and its actual operational requirements. The original statement of work had specified 99.99% availability without identifying which services were genuinely business-critical or validating the requirement against real usage patterns. As a result, environments were provisioned for maximum redundancy and remained continuously available by default.

The platform also relied on complex legacy SQL logic that was difficult to understand, modify, and optimise. This increased maintenance effort while making it harder to trace workloads and identify the drivers of infrastructure spend.

I was tasked with determining the root causes and reducing costs without compromising the system’s required operational performance.

Strategy

I approached the problem across three connected areas: establishing a transparent cost baseline, redesigning the most inefficient parts of the architecture, and aligning availability requirements with business criticality.

Identifying the underlying cost drivers.

I reviewed the platform’s architecture, infrastructure utilisation, storage patterns, and operating schedules. I also worked through the legacy SQL logic to understand how data moved between components and when each workload genuinely needed to run.

The assessment identified three primary cost drivers:

• Inefficient SQL-scheduled data pipelines
• Environments operating continuously despite intermittent usage
• Storage configurations that were significantly more expensive than their access patterns required

This shifted the discussion from a general concern about cloud costs to a defined set of architectural and operational decisions that could be addressed.

Redesigning the pipeline and infrastructure.

I refactored the legacy SQL code into maintainable Python pipelines and redesigned parts of the data-processing and storage architecture.

A key constraint was the frontend application’s dependency on the primary database, which prevented that database from being shut down even when analytical workloads were inactive. I designed a lightweight database specifically for frontend access, decoupling the user-facing application from the main processing environment.

This allowed the primary database and supporting infrastructure to operate on a schedule rather than continuously. Working with the wider technical team, I also right-sized the remaining resources, aligned storage choices with actual access patterns, and introduced clearer cost monitoring.

Aligning availability requirements with business criticality.

A substantial portion of the over-provisioning originated from the blanket 99.99% availability requirement. Rather than treating this as a purely technical constraint, I worked directly with business stakeholders to revisit the underlying operational need.

We identified which components were genuinely business-critical and established differentiated availability requirements based on their role and usage. This preserved resilience where it created business value while removing unnecessary redundancy from lower-criticality workloads.

Result

Monthly infrastructure expenditure fell from approximately $200,000 to $30,000—an 85% reduction—while the platform continued to meet the client’s operational and availability requirements.

The refactored pipelines were easier to maintain, and the new monitoring provided greater visibility into where infrastructure costs were being generated. The project turned an unsustainable recurring expense into a more efficient platform with a viable long-term operating model.