How a leading Indian insurer kept processing SLAs under five minutes while cutting container costs by up to 70%
A leading Indian general insurance company runs a documentation platform on Amazon ECS, where unpredictable traffic spikes made it difficult to balance processing SLAs against infrastructure cost. After four new microservices increased workload variability, fixed scaling patterns led to either under-provisioning or unnecessary container capacity. Flentas designed a custom, queue-based autoscaling framework that scales ECS services according to actual workload demand and now operates it as a managed service, sustaining sub-five-minute processing SLAs, zero downtime, and up to 70% lower container runtime costs.
- A leading Indian insurer
- General insurance / BFSI
- Documentation platform on Amazon ECS
- 4 new microservices added
- Reduction in container runtime costs
- Up to 70%
- Processing SLA sustained under variable load
- <5 minutes
- Downtime during production rollout
- Zero
The platform was scaling on the wrong signal
As new microservices were introduced, workload patterns became harder to predict. The existing scaling approach couldn't respond directly to the metric that mattered most: the number of messages waiting to be processed.
No native queue-depth autoscaling
ECS did not natively scale services based on Amazon SQS queue depth, creating a trade-off between SLA risk and over-provisioning.
Cost from excess capacity
Keeping additional tasks running to handle potential spikes meant paying for compute that wasn't always being used.
SLA risk during spikes
Scaling too conservatively could leave insufficient tasks available when queue volumes increased.
Ongoing tuning required
Scaling thresholds and operational parameters needed continuous adjustment as workload patterns evolved.
Custom, event-driven autoscaling operated as a managed service
Flentas built a queue-depth-based autoscaling framework that connects workload demand to ECS scaling actions, then took on its ongoing monitoring and optimization.
Ran the documentation platform on Amazon ECS with Fargate Spot, using Amazon SQS to buffer incoming workloads and support cost-efficient container processing.
Monitored queue depth using Amazon CloudWatch Alarms, with Amazon SNS acting as the event layer between queue conditions and scaling actions.
Used AWS Lambda to execute idempotent scaling operations on ECS services, dynamically adjusting task capacity based on messages waiting to be processed.
Continues to manage and tune the framework, monitoring application health, adjusting scaling thresholds, and responding to incidents as workload patterns change.
Lower container costs without compromising processing SLAs
Up to 70% reduction in container runtime costs
Enabled by Fargate Spot and workload-driven scaling.
Sub-five-minute processing SLAs sustained
Even as workload volumes fluctuated.
60% reduction in ECS over-provisioning
By scaling capacity according to actual queue demand.
40% fewer on-call alerts
With manual scaling interventions eliminated.
Zero-downtime production rollout
With the autoscaling framework deployed within six hours.
Continuous optimization
With scaling thresholds and infrastructure performance managed as part of ongoing AWS operations.
Built on an event-driven AWS serverless stack
- Amazon ECS (Fargate Spot)
- Amazon SQS
- Amazon CloudWatch Alarms
- Amazon SNS
- AWS Lambda
What insurers and high-throughput platforms usually ask about managed autoscaling
Ready for autoscaling that responds to the workload that actually matters?
Talk to an AWS-certified architect about your own scaling framework.