Managed Flink Parallelism and KPU Scaling for MCP Servers — Task Slots, Autoscaling, Capacity Planning

KPU, parallelism, and task slots — the relationship

Understanding the KPU-to-parallelism mapping is prerequisite to capacity planning. The default Managed Flink configuration allocates one task slot per KPU, so application parallelism equals KPU count in the default setup. But task slot allocation can be tuned:

For AliveMCP probe analytics pipelines, the workload is CPU-bound at the window aggregation step (JSON deserialization + UDF for uptime percentage calculation) and I/O-bound at the source step (reading from Kinesis). The default parallelism-per-kpu = 1 is correct — increasing it risks CPU contention on the aggregation tasks without proportional throughput gain.

// Application-level parallelism — set in Managed Flink application configuration
// This is the top-level parallelism that Flink distributes across available task slots
{
  "ParallelismConfiguration": {
    "ConfigurationType": "CUSTOM",
    "Parallelism": 4,          // Number of parallel task instances
    "ParallelismPerKPU": 1,   // Task slots per KPU (default)
    "AutoScalingEnabled": true // Allow Managed Flink to adjust Parallelism automatically
  }
}

When ConfigurationType is set to DEFAULT, Managed Flink ignores Parallelism and ParallelismPerKPU and uses defaults (1 KPU, parallelism = 1). Use CUSTOM to control the KPU count and task slot allocation explicitly.

Operator-level parallelism overrides

The application-level parallelism sets the default parallelism for all operators. Individual operators can override this with setParallelism(n). Common reasons to override:

// Pattern: Kinesis source parallelism = shard count
// The KDS source cannot benefit from parallelism higher than the shard count —
// each parallel KDS consumer reads one or more shards, but a shard can only be
// read by one consumer at a time. Extra parallel tasks sit idle.
DataStream<String> source = env
    .addSource(new FlinkKinesisConsumer<>(...))
    .uid("kinesis-source")
    .setParallelism(4);  // Set to match shard count (4 shards in this example)

// Pattern: Aggregation operator at full application parallelism
// Window aggregation benefits from the full parallelism setting for
// key-distributed aggregation (Flink hashes serverSlug to distribute
// keys evenly across parallel tasks)
DataStream<ServerUptimeWindow> windows = source
    .keyBy(ProbeResult::getServerSlug)
    .window(TumblingEventTimeWindows.of(Time.minutes(15)))
    .aggregate(new UptimeAggregator())
    .uid("uptime-aggregator");
    // No .setParallelism() — inherits application-level parallelism (4)

// Pattern: Sink at reduced parallelism to avoid Firehose throttling
// PutRecordBatch limit: 500 records/batch, 4 MB/batch, 5,000 records/s per stream
// For low-throughput output streams, reduce sink parallelism to avoid
// creating too many Firehose producers competing for the same stream throughput limit
DataStream<String> output = windows
    .map(new UptimeWindowSerializer())
    .addSink(new KinesisFirehoseSink<>(...))
    .uid("firehose-sink")
    .setParallelism(1);  // Single sink task for Firehose output (low throughput)

A common mistake is setting source parallelism higher than the Kinesis shard count. Flink assigns shards to parallel tasks round-robin — with 4 shards and 8 parallel source tasks, 4 tasks read one shard each and 4 tasks are idle. The idle tasks consume KPU-hours without contributing throughput. Match source parallelism to shard count, then scale shards (via Kinesis resharding) when throughput grows.

Autoscaling behavior and triggers

When AutoScalingEnabled: true, Managed Flink monitors application metrics and adjusts the KPU count (and parallelism) automatically. The scaling logic uses two primary signals:

Autoscaling triggers an application restart: Managed Flink takes a checkpoint (or uses the latest checkpoint), updates the KPU count and parallelism, then restarts the application from the checkpoint. The restart takes 60–180 seconds. During restart, records continue to accumulate on the Kinesis source stream (they are not lost — Kinesis retains data for the configured retention period). After restart, the application catches up by processing the buffered records.

For AliveMCP probe analytics, autoscaling scale-out events typically occur at the start of each hour (when registry re-scans produce a burst of probe results) and scale back in 15 minutes later. This is a predictable pattern that can be handled by setting the minimum KPU count high enough to handle the hourly burst without triggering autoscaling at all — trading KPU-hour cost for stability.

Scaling with state: savepoint vs in-place autoscaling

Flink's autoscaling in Managed Flink is not in-place. It restarts the application, which means state must be checkpointed before the scale event and restored after. For large-state applications (RocksDB with multi-GB state), this restart can take 5–20 minutes for state restoration, during which the source stream accumulates backlog.

Two approaches to manage scaling for stateful applications:

// Approach 1: Autoscaling (recommended for small-state applications)
// - Let Managed Flink autoscale automatically
// - Application restarts from last checkpoint on each scale event
// - Acceptable when checkpoint size is <500 MB and restore takes <2 minutes
{
  "ParallelismConfiguration": {
    "AutoScalingEnabled": true,
    "Parallelism": 2,      // Starting value; Managed Flink adjusts this
    "ParallelismPerKPU": 1
  },
  "MonitoringConfiguration": {
    "MetricsLevel": "TASK"  // Required to emit per-operator metrics for autoscaling decisions
  }
}

// Approach 2: Manual scaling via savepoint (for large-state or latency-sensitive applications)
// Step 1: Take a savepoint via Managed Flink API
aws kinesisanalyticsv2 create-application-snapshot \
  --application-name alivemcp-probe-analytics \
  --snapshot-name "pre-scale-$(date +%Y%m%d%H%M)"

// Step 2: Update application configuration with new KPU count
aws kinesisanalyticsv2 update-application \
  --application-name alivemcp-probe-analytics \
  --current-application-version-id $version \
  --application-configuration-update '{
    "FlinkApplicationConfigurationUpdate": {
      "ParallelismConfigurationUpdate": {
        "AutoScalingEnabledUpdate": false,
        "ParallelismUpdate": 8,
        "ParallelismPerKPUUpdate": 1
      }
    }
  }'

// Step 3: Start the application from the savepoint
aws kinesisanalyticsv2 start-application \
  --application-name alivemcp-probe-analytics \
  --run-configuration '{
    "ApplicationRestoreConfiguration": {
      "ApplicationRestoreType": "RESTORE_FROM_CUSTOM_SNAPSHOT",
      "SnapshotName": "pre-scale-20261030"
    }
  }'

Manual scaling via savepoints gives you control over the timing (scale during low-traffic windows), the ability to verify the savepoint before committing to the scale event, and a rollback path (the savepoint is preserved until explicitly deleted).

Capacity planning for MCP probe analytics workloads

AliveMCP probes MCP endpoints every 60 seconds. Each probe result is a JSON record of ~500 bytes (endpoint slug, status code, response time, error code, timestamp). At different scale points:

The throughput numbers above are for ingestion only. If the analytics pipeline includes enrichment (joining probe results with a reference dataset of server metadata from S3 or RDS), add 20–50% to the KPU count to cover the enrichment CPU cost. If the pipeline aggregates results and fans out to multiple sinks (Kinesis output + Firehose archive + OpenSearch), add one KPU per 2–3 additional sink operators.

The most common capacity mistake for MCP probe analytics is sizing for average throughput and ignoring the registry-scan spike. When AliveMCP re-scans the full MCP registry (every 6 hours), ~5,000 new endpoint records arrive in the Kinesis stream within 2–3 minutes. This is a 60× burst above average. Size the Kinesis stream for the burst rate, not the average, and configure Kinesis enhanced fan-out for the Flink consumer to ensure dedicated 2 MB/s throughput per shard during the burst.

Complete failure mode reference