The core pathology of enterprise cloud budgets is static compute sizing: provisioning virtual machine capacity to survive midday traffic peaks, leaving more than 60% of paid compute capacity running idle overnight. In Southeast Asian digital banking, logistics, and retail platforms, diurnal traffic curves are steep. System concurrency surges between 09:00 and 16:30 WIB, tapers through the evening, and plummets into an 8-hour nocturnal trough where load registers below 15% of peak volume.
When infrastructure teams provision static Amazon EC2 fleets sized for worst-case peak traffic, the organization pays continuous peak-tier hourly rates for machines that burn clock cycles doing nothing. Over-provisioning is often defended as insurance against traffic spikes, but paying for idle hypervisor allocations is a failure of architecture, not a badge of reliability.
Eliminating this structural waste without compromising Service Level Objectives (SLOs) requires transitioning from statically provisioned EC2 virtual machines to an elastic three-tier architecture: containerized AWS ECS Fargate tasks, responsive target-tracking autoscaling based on Application Load Balancer (ALB) request throughput, and a distributed Redis caching layer. In a production system handling 4,800 requests per second in AWS Jakarta (ap-southeast-3), this architecture delivered a verified 35% reduction in total monthly compute outlay while improving P99 latency.
+----------------------------------------------------------------------------------------------------+
| ELASTIC FINOPS CONTAINER TOPOLOGY ON AWS (ap-southeast-3 Jakarta) |
| |
| [ Public Internet Inbound Traffic ] |
| | |
| v |
| +-------------------------------+ |
| | Application Load Balancer | |
| | - HTTPS TLS 1.3 Termination | |
| | - Target Group Health Checks | |
| +-------------------------------+ |
| | |
| +-------------------------+-------------------------+ |
| | Request Metrics Tap | Metric Telemetry |
| v v |
| +-------------------------------+ +-------------------------------+ |
| | AWS Application Auto Scaling | | CloudWatch Metric Alarm | |
| | - ALBRequestCountPerTarget:1k | | - P95 Concurrency Monitoring | |
| +-------------------------------+ +-------------------------------+ |
| | |
| v Scale-Out / Scale-In (Min: 3 Tasks | Max: 18 Tasks) |
| +--------------------------------------------------------------------------------------------+ |
| | AWS ECS Fargate Elastic Cluster (Private Subnets across 3 AZs) | |
| | +-------------------+ +-------------------+ ... +-------------------+ | |
| | | Task 1 (1vCPU/2G) | | Task 2 (1vCPU/2G) | | Task N (1vCPU/2G) | | |
| | +-------------------+ +-------------------+ +-------------------+ | |
| +--------------------------------------------------------------------------------------------+ |
| | | |
| | Cache-Aside Lookup (<1.2ms) | Direct Mutation / Miss |
| v v |
| +-------------------------------+ +-------------------------------+ |
| | Amazon ElastiCache for Redis | | Amazon Aurora PostgreSQL | |
| | - 2-Node Multi-AZ Cluster | | - Serverless v2 Auto-scaling | |
| | - 72% Query Offload Ratio | | - Dedicated Read Replicas | |
| +-------------------------------+ +-------------------------------+ |
+----------------------------------------------------------------------------------------------------+1. The Over-Provisioning Pathology in Numbers
During an architectural audit of a Jakarta-based digital payments and logistics platform serving 4,800 requests per second at peak, the application tier ran across twelve static c6i.2xlarge EC2 instances (8 vCPU, 16 GB RAM each).
Telemetry collected over a 90-day evaluation window revealed clear operational waste:
- Peak Hours (11:00 - 14:00 WIB): Fleet-wide average CPU utilization hovered around 58%, operating comfortably within safe thresholds.
- Off-Peak Hours (22:00 - 06:00 WIB): Fleet-wide CPU utilization plummeted to 11.4%, with memory usage flatlining at 18%.
- Idle Capacity Surcharge: Across 720 operating hours per month, 62% of purchased compute delivered zero commercial throughput. Fixed EC2 instance costs alone totaled $3,283.20 per month, excluding EBS root volume attachments.
Engineering teams maintain static fleets out of defensive habit: EC2 cold-boot times take 3 to 5 minutes, AMI rot creates deployment friction, and standard CPU-utilization autoscaling rules react too sluggishly to prevent connection queuing during sudden surges. The solution is not to manually toggle servers on and off, but to decouple capacity scaling from static virtual machine primitives.
2. The Three-Tier Elastic Architecture
The modern FinOps architecture replaces static virtual machine allocations with three tightly coupled infrastructure tiers:
Tier 1: Granular Serverless Tasks (AWS ECS Fargate)
Migrating microservices into containerized tasks on AWS ECS Fargate removes the virtual machine abstraction entirely. Rather than paying for whole EC2 instances 24/7 regardless of task packing efficiency, Fargate bills by the exact second for vCPU and memory allocated to active containers. Granular task sizing (1 vCPU, 2 GB RAM per task) enables true linear elasticity: scaling out adds only the compute increment required by immediate demand.
Tier 2: ALB Request-Driven Target Tracking
Conventional autoscaling policies that trigger on CPU utilization are fundamentally reactive. By the time elevated CPU metrics register in CloudWatch and initiate a scale-out event, backend request queues are already degraded.
We configure Application Auto Scaling to track the predefined metric ALBRequestCountPerTarget. By benchmarking baseline container throughput (calibrated to 1,000 requests per container per minute), the autoscaler provisions tasks proportionally before container CPU saturates, and scales capacity down automatically within 300 seconds once traffic returns to baseline.
Tier 3: Query Offload via Redis (Amazon ElastiCache)
Scaling application containers linearly under traffic surges inevitably shifts concurrency bottlenecks downstream onto relational database connection pools.
Deploying a Redis cache-aside layer via Amazon ElastiCache (cache.m6g.large Multi-AZ) absorbs repetitive read queries—such as bearer token validation, product pricing lookups, and routing configurations—resolving hits in under 1.2 milliseconds. Offloading 72% of read operations from Amazon Aurora PostgreSQL stabilizes database connection pools and lowers the container task count required to satisfy traffic spikes.
3. Production Terraform Configuration
The following Terraform specification provisions an elastic ECS service target alongside a high-responsiveness target-tracking scaling policy bound to ALB request counts:
# ecs-autoscaling.tf
# 1. Define the Application Auto Scaling Target for the ECS Service
resource "aws_appautoscaling_target" "ecs_service_target" {
max_capacity = 18
min_capacity = 3
resource_id = "service/${aws_ecs_cluster.production.name}/${aws_ecs_service.api_gateway.name}"
scalable_dimension = "ecs:service:DesiredCount"
service_namespace = "ecs"
}
# 2. Target-Tracking Auto-Scaling Policy based on ALB Request Count Per Target
resource "aws_appautoscaling_policy" "ecs_target_tracking_alb" {
name = "alb-request-count-target-tracking"
policy_type = "TargetTrackingScaling"
resource_id = aws_appautoscaling_target.ecs_service_target.resource_id
scalable_dimension = aws_appautoscaling_target.ecs_service_target.scalable_dimension
service_namespace = aws_appautoscaling_target.ecs_service_target.service_namespace
target_tracking_scaling_policy_configuration {
target_value = 1000.0 # Target: 1,000 requests per container per minute
predefined_metric_specification {
predefined_metric_type = "ALBRequestCountPerTarget"
resource_label = "${aws_lb.internal_alb.arn_suffix}/${aws_lb_target_group.ecs_targets.arn_suffix}"
}
# Stabilize scale-in to prevent task flapping during intermittent dips
scale_in_cooldown = 300
# Aggressively scale-out to absorb inbound traffic surges
scale_out_cooldown = 60
}
}The 60-second scale-out cooldown provides rapid provisioning during traffic surges, while the 300-second scale-in cooldown prevents thrashing (continuous task teardown and relaunch) during short-term request dips.
4. Financial Balance Sheet & Unit Economics
Below is the audited monthly cost reconciliation before and after migration for the 4,800 req/sec production platform in the AWS ap-southeast-3 (Jakarta) region:
| Infrastructure Component | Legacy Static Architecture (12x EC2 c6i.2xlarge) | Modernized Elastic Architecture (ECS Fargate + Redis) | Monthly Variance |
|---|---|---|---|
| Compute Layer | $3,283.20 (12x instances @ $0.38/hr, 720h) | $1,584.18 (Dynamic avg 5.4 tasks @ 1vCPU/2GB) | -$1,699.02 (-51.7%) |
| Storage (EBS) | $192.00 (12x 100GB gp3 root disks) | $0.00 (Ephemeral container root storage included) | -$192.00 (-100.0%) |
| Load Balancing (ALB) | $44.20 (1x ALB + 12 LCUs) | $44.20 (1x ALB + 12 LCUs) | $0.00 (0.0%) |
| Database (Aurora PostgreSQL) | $728.80 (db.r6g.xlarge primary + replica) | $728.80 (Retained for transactional mutations) | $0.00 (0.0%) |
| Caching Layer (ElastiCache) | $0.00 (No caching layer in place) | $403.20 (cache.m6g.large Multi-AZ 2-node cluster) | +$403.20 (+100.0%) |
| Total Monthly Spend | $4,248.20 | $2,760.38 | -$1,487.82 (-35.0%) |
Beyond delivering a verified 35.0% reduction in net monthly infrastructure outlay ($1,487.82 net savings per month, or ~$17,850 annualized), the platform unlocked two vital operational gains:
- P99 Latency Reduction: By serving 72% of queries directly from Redis in-memory cache, P99 API response time dropped from 185ms to 108ms.
- Zero OS Maintenance Overhead: Fargate eliminated operating system patching, security vulnerability scans on base AMIs, and manual kernel upgrade rotations from the platform engineering backlog.
FinOps is not an exercise in code starvation or compromising system headroom. It is the disciplined alignment of cloud billing increments with active transactional volume.