Developing Applications On Managed Service For Apache Flink

Scaling Decision Framework

Overview

Decision matrix for choosing the right scaling action based on observed bottleneck. For initial KPU sizing methodology and CloudWatch trend signals, see resource-optimization.md. This guide is for in-flight scaling decisions on running applications.

Decision Matrix

What is the bottleneck?
│
├─► CPU > 70% sustained or backpressure > 500ms/s
│   → INCREASE Parallelism (adds KPUs, restart required)
│
├─► OOM errors or heapMemoryUtilization > 85%
│   → DECREASE ParallelismPerKPU (more memory per subtask)
│   → Same total parallelism, more KPUs, lower throughput-per-dollar
│
├─► Variable/spiky load + can tolerate restart-on-scale
│   → ENABLE AutoScalingEnabled=true
│   → MSF reacts on CPU only; 5-15 min reaction; restart per event
│
└─► CPU < 30% sustained, idle > 500ms/s, no backpressure
    → DECREASE Parallelism (over-provisioned)
    → Validate with 60+ minute trend before reducing

Scaling Impact Table

KPU formula: KPU = Parallelism / ParallelismPerKPU. Add 1 orchestration KPU for total billed.

Pre-Scaling Validation

Always validate the bottleneck against trends, not point-in-time values, before scaling. Pull the last 6 hours of:

• containerCPUUtilization — Maximum (hottest container)

• backPressuredTimeMsPerSecond — Average and Maximum

• idleTimeMsPerSecond — Average and Minimum

• heapMemoryUtilization — Maximum

• lastCheckpointDuration — trend (rising = pressure)

If signals conflict (high CPU but also high idle, or backpressure with low CPU), the bottleneck is downstream — investigate the operator graph via Flink Dashboard before scaling. Adding KPUs to a sink-bound or skew-bound job wastes money. See first-fault-isolation.md for live diagnosis via the Dashboard.

AutoScalingEnabled Behavior

MSF built-in autoscaling is CPU-only with fixed thresholds:

• Scale up: containerCPUUtilization > 75% for 15 consecutive 1-min datapoints → doubles CurrentParallelism

• Scale down: containerCPUUtilization < 10% for 360 consecutive 1-min datapoints (6h) → halves CurrentParallelism, never below configured Parallelism

• Each event triggers a full restart (10–30s downtime). Backpressure, lag, and memory pressure do not trigger autoscaling.

• During scaling: status is AUTOSCALING. Only stop-application --force is valid.

For backpressure-driven, lag-driven, or memory-driven autoscaling: disable AutoScalingEnabled and implement custom scaling via CloudWatch alarms → Lambda → update-application.

Stateful vs Stateless ParallelismPerKPU

Scaling Guardrails

• ❌ Cannot scale during a transitional state (STARTING, UPDATING, STOPPING, AUTOSCALING)

• ❌ Cannot scale during another in-flight update — sequence operations

• ⚠️ Every scaling change triggers a restart with 10–30s downtime (varies with state size and snapshot recency)

• ⚠️ Take a snapshot before scaling for rollback safety

• ⚠️ Scaling beyond 64 KPU requires a Service Quotas increase (default limit)

• ⚠️ Setting Parallelism > source partition/shard count creates idle subtasks — wasted KPUs

Anti-Patterns

References

• MSF Auto-Scaling Behavior

• resource-optimization.md — KPU sizing methodology and trend-based signals

• first-fault-isolation.md — diagnose before scaling