aws_appautoscaling_target cost estimation
An Application Auto Scaling target is free. It registers a resource (ECS service, DynamoDB table, and others) as scalable, and the cost is the capacity that resource runs at.
An aws_appautoscaling_target registers a scalable dimension of another resource with Application Auto Scaling: the desired count of an ECS service, the read or write capacity units of a DynamoDB table, an Aurora replica count, and similar. The target and the scaling policies attached to it are free. Application Auto Scaling itself has no charge, and neither do the CloudWatch alarms it creates for target tracking.
The cost is whatever the target scales. Registering an ECS service as a scalable target does nothing to your bill until the service scales out and runs more Fargate tasks or EC2 tasks. Registering a DynamoDB table's write capacity lets it scale between a min and max, and you pay for the provisioned capacity it settles at. So the target is the control surface, and the underlying resource is the meter.
The important knobs are min_capacity and max_capacity. The minimum sets your floor cost even at idle, and the maximum sets the ceiling a spike can drive you to. A max_capacity set far above real demand is a cost risk, because a bad metric or a traffic surge can scale the target to its ceiling and bill you for that capacity until it scales back in. c3x prices the underlying resource across its scaling range so you can see both the floor and the worst-case cost before you apply.
Terraform example
A minimal but realistic configuration that C3X can estimate.
resource "aws_appautoscaling_target" "ecs" {
service_namespace = "ecs"
resource_id = "service/prod/api"
scalable_dimension = "ecs:service:DesiredCount"
min_capacity = 2
max_capacity = 20
}
resource "aws_appautoscaling_policy" "cpu" {
name = "cpu-target-tracking"
policy_type = "TargetTrackingScaling"
resource_id = aws_appautoscaling_target.ecs.resource_id
scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension
service_namespace = aws_appautoscaling_target.ecs.service_namespace
target_tracking_scaling_policy_configuration {
predefined_metric_specification {
predefined_metric_type = "ECSServiceAverageCPUUtilization"
}
target_value = 60
}
}Pricing dimensions
What you actually pay for when you provision aws_appautoscaling_target.
| Dimension | Unit | What's being charged |
|---|---|---|
| Scaling target and policies | free | Registering the target and its scaling policies has no charge. $0 |
| Scaled capacity (floor) | varies by resource | min_capacity sets the baseline cost you pay even when idle: tasks, capacity units, or replicas. e.g. 2 Fargate tasks always on |
| Scaled capacity (ceiling) | varies by resource | max_capacity sets the worst-case cost a spike can reach before it scales back in. e.g. up to 20 Fargate tasks |
Optimization tips
Common ways to reduce aws_appautoscaling_target cost without changing the workload.
Set min_capacity to true idle demand
The minimum is your floor cost, paid around the clock. Do not pad it out of caution; a lower minimum with a fast scale-out policy costs less overall.
Cap max_capacity to a real ceiling
An unbounded or very high maximum lets a metric error or traffic surge scale the target to a bill you never intended. Set the ceiling to the most you would actually pay for.
Use scheduled scaling for known patterns
If load is predictable (business hours, batch windows), schedule the minimum down overnight so you do not pay the floor cost during hours with no traffic.
FAQ
Does Application Auto Scaling cost money?
No. Registering a scalable target and attaching scaling policies is free, and the CloudWatch alarms it creates for target tracking are free. You pay only for the capacity the underlying resource runs at.
What determines the cost of an autoscaling target?
The resource it scales. An ECS target bills for the Fargate or EC2 tasks it runs; a DynamoDB target bills for the read and write capacity it provisions. min_capacity is the floor and max_capacity is the ceiling.
Can autoscaling cause a surprise bill?
Yes, if max_capacity is set far above real demand. A bad metric or a spike can scale the target to its ceiling and charge for that capacity until it scales back in. Cap the maximum to limit the risk.
Related resources
Estimate this resource in your own Terraform
Free, open source, no API key. C3X parses your Terraform and shows line-item cost for every resource, including aws_appautoscaling_target.