Five operational differences to check before adopting Amazon MSK Express brokers

Express brokers are a broker type for Amazon MSK Provisioned that provide fully managed storage and best-practice defaults out of the box. That "managed" nature, however, creates an operational model different from Standard brokers. Carrying over Standard-era habits can lead you to mistake normal behavior for an incident, or to see performance regressions after migration. Here are five differences that come up repeatedly in support cases.

1. There is no maintenance window — brokers update automatically

This is the most frequent question. Standard brokers give you advance notice of maintenance and let you adjust the schedule, but Express brokers have no maintenance window concept at all. Amazon MSK updates brokers automatically on an ongoing basis, one broker at a time, distributed across the month. If you see operations of type BROKER_UPDATE in your cluster operations list (ListClusterOperations), that is normal automatic patching (the Express counterpart of SECURITY_PATCHING on Standard).

Because updates are rolling, overall cluster availability is maintained, but from the client's perspective you may observe:

• Partitions led by the restarting broker go through leadership failover. Transient disconnect errors are within normal range.
• If the transaction coordinator lives on that broker, coordinator unavailability of around a minute can occur. A transactional producer that cannot tolerate this can end up with ProducerFencedException.

Important: Since there is no advance notification, client resilience is a prerequisite for adoption. Recommended: retries with exponential backoff, a generous delivery.timeout.ms (for example 300 seconds), transaction.timeout.ms of 120 seconds or more when using transactions, and the full bootstrap broker list. Express always enforces replication factor 3 and min.insync.replicas 2, so the Standard-era scenario of an RF 1-2 topic going completely offline does not exist — but that does not help if your clients cannot handle failover.

2. Intelligent rebalancing is not an even-distribution tool

Intelligent rebalancing is a feature exclusive to Express-based clusters. It automatically reassigns partitions when you add or remove brokers (scaling operations complete within 30 minutes) and continuously monitors the cluster at steady state.

Most questions about it stem from a misunderstanding of how it works. Rebalancing moves partitions only when resource thresholds are exceeded (CPU, throughput, or partition count relative to their limits). Even distribution of partitions or leaders is not the goal. After adding brokers, if resources are not constrained, an uneven distribution is normal behavior.

Additional characteristics worth knowing:

1. Internal topics rarely cross the thresholds. Topics such as __consumer_offsets use CPU but carry low throughput, so they can remain concentrated on specific brokers after scaling. This has led to consumer group rebalance delays in production; include an internal-topic distribution check in your post-scaling runbook.
2. It cannot coexist with third-party tools. While intelligent rebalancing is on, you cannot use partition reassignment APIs or Cruise Control. To reassign manually, first set Rebalancing Status to Paused.
3. It does not operate while the cluster is UnderProvisioned. If the cluster is judged resource-starved (UnderProvisioned metric), rebalancing cannot move partitions. Add brokers or scale up the instance size first.
4. Existing clusters start Paused. As of June 18, 2026, the feature is available to all Express clusters, including those created before its launch on November 20, 2025 — but for those clusters, Rebalancing Status starts as Paused. Switch it to Active in the console, CLI, or SDK to activate it.
5. Monitor progress with the CloudWatch metric RebalanceInProgress (1 while ongoing).

3. Throughput is governed by quotas — and partition design decides your performance

Standard brokers can push up to the hardware limits (EBS, network). Express brokers instead have explicit per-broker throughput quotas imposed by MSK, in two tiers: up to the sustained level there is no degradation, and at the maximum quota client traffic is throttled.

Instance size	Ingress sustained / max (MBps)	Egress sustained / max (MBps)
express.m7g.large	15.6 / 23.4	31.2 / 58.5
express.m7g.4xlarge	124.9 / 187.5	249.8 / 468.7
express.m7g.16xlarge	500 / 750	1000 / 1875

(See the quota documentation in Related information for the full table. Size your cluster by working backward from it.)

Two practical pitfalls:

First, the "up to 3x throughput per broker" figure is an aggregate across well-distributed partitions. Express also has a separate per-partition throughput quota (up to 15 MBps). On Standard, a single partition could sustain tens of MBps or more, so a workload concentrated on a few large partitions can actually get slower after moving to Express. Partition count design is the key to Express performance.

Second, protective throttling can kick in on CPU even when you are far below the throughput quota. When combined broker CPU (CpuUser + CpuSystem) exceeds 60%, client traffic may be throttled to protect background operations. There have been cases where consumer throttling occurred purely due to CPU, at traffic levels well below the quota. Watch FetchThrottleByteRate and ProduceThrottleByteRate for throttling, and set a 60% CPU alarm.

Tip: When benchmarking Express against Standard, keep the broker count, instance size, and partition count identical. Several support cases reporting "performance regression" turned out to be non-normalized comparisons; once normalized, results were comparable.

4. Partition limits are hard limits

Unlike Standard, where per-broker partition counts are recommendations, Express enforces a maximum number of partitions per broker (including leader and follower replicas) as a quota.

Instance size	Recommended	Maximum (enforced)
express.m7g.large	1,000	1,500
express.m7g.xlarge	1,000	2,000
express.m7g.2xlarge	2,500	4,000
express.m7g.4xlarge	6,000	8,000
express.m7g.8xlarge	12,000	16,000
express.m7g.12xlarge	16,000	24,000
express.m7g.16xlarge	20,000	32,000

Exceeding the limit rejects topic/partition creation. Near or beyond the limit, the following operations are also blocked:

• Updating the cluster configuration
• Updating the cluster to a smaller broker size (downsizing)
• Associating a Secrets Manager secret for SASL/SCRAM authentication

An overloaded cluster can also show missing Kafka metrics in CloudWatch and Prometheus scraping. The effect is compounded by a high number of consumer groups (each group x topic x partition combination creates a tracked offset entry). Even empty consumer groups contribute until offsets.retention.minutes expires, so include cleanup of unused consumer groups in your operational routine.

5. Kafka APIs and configurations are not identical — a pre-migration checklist

Because Express storage is fully managed, its Kafka APIs and configurations are not exactly the same as Standard. Check the following before migrating.

1. DeleteRecords API is not supported. Calls return an UNSUPPORTED_VERSION error, which is hard to interpret from the message alone. Handle data deletion with retention.ms, retention.bytes, or topic re-creation. If your operational workflows rely on record deletion, prepare an alternative in advance.
2. Segment configurations cannot be changed. segment.bytes, segment.ms, and other log segment settings are not customer-configurable due to the managed storage design. The list of changeable configurations is documented separately.
3. Kafka Streams (KStreams) API is not yet fully supported. Validate compatibility before migrating KStreams-based applications. KIP-932 (Queues for Kafka) is also not yet supported.
4. Platform constraints: 3-AZ configuration only, m7g family instances only, Apache Kafka 3.6/3.8/3.9/4.2 (KRaft from 3.9). Broker count limits are 30 per ZooKeeper-based cluster and 60 per KRaft-based cluster.
5. Open Monitoring (Prometheus) scraping limits. Scraping at short intervals (for example, 10 seconds) can cause 429 errors and metric gaps. The official recommendation is a scrape_interval of 60 seconds or higher.
6. IAM connection quotas. With IAM authentication, there is a limit of 3,000 TCP connections per broker and 100 new connections per second. Configure reconnect.backoff.ms to protect against reconnect storms.

Summary

Aspect	Standard	Express
Maintenance	Window + advance notice	None — ongoing automatic updates (BROKER_UPDATE)
Partition placement	Manual (Cruise Control, etc.)	Intelligent rebalancing (threshold-based, not even distribution)
Throughput	Up to hardware limits	Per-broker/per-partition quotas + protective throttling at 60% CPU
Partition limits	Recommendations	Hard limits (blocking creation, config updates, downsizing)
APIs/configs	Full	No DeleteRecords, no segment configs, KStreams not fully supported

The common thread: Express is a platform with fewer things to configure but more things to assume. Build client resilience, design partition counts against the quota tables, and check the API differences created by managed storage before migrating — then you get higher throughput than Standard without the storage and maintenance burden.

Related information

• Amazon MSK Express brokers — overview and constraints
• Express broker quotas (throughput, partitions)
• Best practices for Express brokers (sizing, CPU monitoring)
• Patching on MSK Provisioned clusters
• Intelligent rebalancing