Banksalad Consolidates 50 RDS Clusters with AWS DMS, Cutting Costs by One-Third

Banksalad's Core Infra team adopted AWS DMS to address resource inefficiency caused by using individual RDS clusters per service while operating an MSA architecture. They established a strategy to consolidate numerous t3.small instances—many with actual utilization below 10%—into larger, domain-based clusters.

RDS Consolidation Strategy and Cost Savings

The existing 50+ RDS clusters were reduced to about 5-10 clusters organized by business domain (curation, health, assets, etc.). Through this process, RDS cluster maintenance costs were reduced to 1/3 of pre-migration levels, while maintaining the benefit of blocking failure propagation at the domain level.

AWS DMS Application and Problem Solving

DMS supports N:1 clustering and CDC (Change Data Capture) functionality, enabling migration with minimal service disruption. The major issues encountered during migration and their solutions are as follows.

• High Load: To resolve the issue of CPU reaching 100% due to DMS tasks, Source and Target instances were scaled up to more than twice peak usage.
• Binary Log Limitation: There was a risk of Full Load failure due to Aurora MySQL's 168-hour (7-day) retention period limit, but this was completed within 7 days through a spec upgrade to r5.8xlarge and applying Limited LOB Mode.
• Data Verification: During nighttime maintenance windows, traffic was blocked and data integrity was verified through Row Count comparison and Sampling.

DMS Usage Tips and Error Handling

When configuring DMS, adding initstmt=SET FOREIGN_KEY_CHECKS=0 to the Target endpoint prevented FK constraint violation errors. Additionally, when handling LOB data for JSON columns with NOT NULL constraints, errors were resolved by temporarily changing the Target column to Nullable. For Table mappings, specifying only the necessary tables instead of the entire schema improved manageability and speed.