*1. Simple Scaling (scheduled action) *
- How it works: Performs a single scaling action (like add/remove N instances) after a CloudWatch alarm is triggered.
- Cool-down period: Waits for a cooldown period before checking again.
- Example: If CPU > 70%, add 1 instance. Then wait 5 minutes before responding again.
- desired instances = 10
2. Step Scaling
- How it works: Performs different scaling actions based on thresholds ("steps").
- More flexible than simple scaling.
-
Example:
- CPU > 60% → add 1 instance
- CPU > 80% → add 2 instances
- CPU > 90% → add 3 instances
3. Target Tracking Scaling
- How it works: Automatically adjusts capacity to maintain a specific target metric (like keeping average CPU at 50%).
- Works like a thermostat: constantly adjusts to hit the set point.
- Most automatic and recommended for standard scenarios.
📊 Comparison Table
| Feature | Simple Scaling | Step Scaling | Target Tracking Scaling |
|---|---|---|---|
| Scaling logic | One action per alarm | Multiple actions based on ranges | Auto-adjusts to reach target metric |
| Control level | Basic | Medium (more rules) | Minimal (hands-off) |
| Use case | Simple apps, small workloads | Apps with predictable load steps | Most workloads needing consistent performance |
| Example metric | CPU > 70% → add 1 instance | CPU > 60% → +1, CPU > 90% → +3 | Keep CPU at 50% |
| Cooldown | Manual setting | Manual setting | Handled automatically |
| Ease of use | Easy | Moderate | Easiest (just set target) |
| Best for | Learning/demo | Custom rules | Production apps needing balanced performance and cost |
| Flexibility | Low | High | Medium |
✅ When to Use What?
| Scenario | Best Option |
|---|---|
| Just starting out, small app | Simple Scaling |
| You want different actions for different thresholds | Step Scaling |
| You want it to "just work" and maintain a metric like CPU % | Target Tracking |
Top comments (0)