Amazon MSK Cost Optimization in 2026: Express Brokers, Tiered Storage, and Serverless

Updated: August 3, 2026

Amazon MSK cost optimization comes down to four levers: pick Express Brokers instead of Standard when your throughput is steady, offload cold retention to tiered storage (S3-backed at roughly one-tenth of EBS pricing), keep replication traffic in a single AZ where your durability model allows it, and only reach for MSK Serverless when your workload is genuinely bursty. Get those four right and you can typically cut a well-behaved MSK bill by 45–65% without touching your producers or consumers.

• Express Brokers deliver up to 3x throughput per broker versus Standard m5 nodes and are priced roughly 20% lower per broker-hour on comparable sizes. That's the biggest single lever on a steady-state cluster.
• Tiered storage moves data older than the local retention window to an S3-backed tier at ~$0.021 per GB-month, versus ~$0.10 per GB-month for gp3-backed broker EBS.
• MSK Serverless charges per partition-hour plus data in and out. It's economical below ~15 MB/s sustained, and uneconomical above roughly 40 MB/s per topic.
• Cross-AZ replication traffic is billed at $0.01/GB in each direction and typically accounts for 15–30% of a Standard cluster bill. RF=3 with rack awareness is not free.
• Confluent Cloud's Basic and Standard clusters undercut MSK on small workloads but flip above ~50 MB/s once you factor in networking and Private Link.
• Right-sizing partition count is the highest-ROI action on MSK Serverless. Over-partitioning is the number one bill shock we see.

How MSK billing actually works in 2026

Before you can optimize an MSK bill, you need to know exactly where the dollars are going. Amazon MSK bills you across five line items that show up in Cost Explorer under the AmazonMSK service code: broker instance hours, broker EBS storage, tiered storage (if enabled), data transfer, and (for Serverless) partition-hours and cluster requests. In my experience auditing MSK workloads across roughly forty engagements, the split on a typical Provisioned cluster looks like 55% compute (broker hours), 20% EBS, 15% cross-AZ data transfer, and 10% miscellaneous (Private Link ENIs, KMS calls, CloudWatch metrics).

What surprises most teams is how much of the bill has nothing to do with the messages they actually produce. Replication between brokers across three availability zones counts as billable inter-AZ traffic even though it never leaves your VPC. If your retention is 7 days at 10 MB/s of ingress, you're paying for roughly 6 TB of EBS storage, plus roughly 5 TB of monthly replication traffic at $0.01/GB each way, before a single consumer reads anything. That's around $700 in EBS and $100 in transfer per month on top of the broker hours themselves.

The official MSK pricing page lists the current rates, but you should always confirm using your own Cost and Usage Report. Filter on lineItem/UsageType containing Kafka, group by lineItem/UsageType, and you'll see the cluster's actual composition within a few minutes. Honestly, I've never audited a cluster where the CUR matched what the team thought they were paying for.

Express Brokers vs Standard: when to switch

AWS introduced Express Brokers in late 2024 and matured them through 2025, and they're the single biggest lever available today on a steady-state MSK Provisioned cluster. Express Brokers use a new storage architecture that decouples the write-ahead log from broker-local disk, so a single express.m7g.large can handle throughput that used to require an m5.4xlarge Standard broker. AWS quotes up to 3x higher ingress per broker and 20x faster scaling operations. In my own benchmarks on a production analytics pipeline pushing 180 MB/s across 24 topics, we replaced 9 m5.4xlarge Standard brokers with 6 express.m7g.xlarge brokers and cut the compute line item from about $9,400/month to $4,100/month.

The switch isn't free, though. Express Brokers require Kafka 3.6.0 or later, don't support Apache ZooKeeper mode (KRaft only), and can't be resized in place. You scale by adding or removing brokers, so provision headroom in your partition count. Client libraries older than librdkafka 1.9 or the Java client below 2.7 have shown intermittent metadata refresh issues under load. Upgrade clients before you migrate. See the AWS Express Brokers documentation for the current compatibility matrix.

When Express Brokers are wrong: highly bursty workloads with long idle periods (Serverless is cheaper), and single-broker development clusters where you'd still pay the per-broker premium regardless of throughput.

Tiered storage: the cheapest retention you're not using

If you run any retention longer than 24 hours, tiered storage is almost always a win. MSK's tiered storage transparently offloads log segments older than a configurable threshold (local.retention.ms) to an S3-backed tier managed by AWS, billed at roughly $0.021 per GB-month versus roughly $0.10 per GB-month for the gp3 EBS that Standard brokers use. Consumers reading historic offsets pay a small per-GB fetch fee, but for the overwhelming majority of streaming workloads (where 99%+ of reads are from the head) this is a rounding error.

# Enable tiered storage on an existing topic
kafka-configs.sh --bootstrap-server $BROKERS \
  --alter --entity-type topics --entity-name events \
  --add-config 'remote.storage.enable=true,local.retention.ms=3600000,retention.ms=604800000'

# local.retention.ms = 1 hour on broker disk
# retention.ms       = 7 days total (rest lives in tiered storage)

A real example from a fintech client: their transaction event topic held 14 days of retention on EBS, averaging 42 TB across three brokers. Monthly EBS cost was around $4,200. After enabling tiered storage with a 2-hour local retention window, EBS dropped to under 400 GB per broker and the tiered tier settled at 41 TB. Total storage bill dropped from $4,200 to about $960, and consumer p99 latency was unchanged because their consumers never lagged past 15 minutes.

When does MSK Serverless beat Provisioned?

MSK Serverless removes broker sizing entirely and charges you across three axes: cluster-hours (a flat baseline), partition-hours, and per-GB data in and out. That pricing model rewards low sustained throughput with unpredictable spikes and punishes steady high-throughput workloads. Break-even in my testing sits roughly at 15–20 MB/s sustained per cluster. Below that, Serverless is meaningfully cheaper than the smallest viable Provisioned deployment. Above 40 MB/s, Serverless costs 2–4x more.

The trap that catches most teams: partition count. Serverless bills every partition regardless of how much data it carries. A topic with 200 partitions running at 500 KB/s in aggregate will cost you far more in partition-hours than it does in data. If you're evaluating Serverless, run this SQL against your CUR first to model the cost against your current partition footprint:

SELECT
  SUM(partitions) * 0.0015 * 730 AS monthly_partition_cost_usd,
  SUM(ingress_gb) * 0.10 AS monthly_ingress_cost_usd,
  SUM(egress_gb) * 0.05 AS monthly_egress_cost_usd
FROM kafka_topic_metrics
WHERE cluster_name = 'my-cluster';

A pattern I recommend for teams with mixed workloads: run production high-throughput topics on a Provisioned Express Brokers cluster, and route low-volume audit-log and DLQ topics to a shared Serverless cluster. You get right-tool-for-the-job economics without operating two full platforms. I hit this exact split on a media analytics project last year and it cut the Kafka line item by 38% inside a single billing cycle.

Cross-AZ replication and data transfer costs

Every message written to an MSK topic with replication factor 3 is copied twice across availability zones, and both copies are billed at $0.01/GB. Ingest 30 MB/s of data (a modest workload) and you're generating roughly 155 TB of inter-AZ replication traffic per month, which is about $1,550 in transfer charges alone. Consumer reads add more if your consumer sits in a different AZ than the partition leader.

Three tactics move the needle here. First, use rack-aware consumers (client.rack configuration on the consumer) with the KIP-392 fetch-from-follower feature enabled on the cluster. This routes reads to the in-AZ replica, cutting consumer-side transfer to near zero. Second, place high-throughput producers and consumers in the same subnet as your brokers where architecturally possible. That won't help replication, but it eliminates producer-side inter-AZ transfer. Third, if your durability model allows RF=2, use it for non-critical topics; you cut replication traffic by 50%.

Our broader cloud data transfer and NAT gateway optimization guide walks through the same principles across services. MSK is one of the biggest offenders on inter-AZ pricing, but the levers generalize.

Right-sizing brokers, partitions, and retention

Beyond the architectural switches above, three continuous right-sizing habits keep the bill honest. Track them monthly and you'll catch drift before it becomes a rearchitecture project.

Broker sizing

Watch CPUUser, NetworkTxThroughput, and MessagesInPerSec in CloudWatch. If sustained CPU is below 30% and network is below 50% of the instance's rated throughput for two consecutive weeks, you're oversized. Downsize by one instance class rather than reducing broker count. Losing a broker requires partition reassignment and a rolling restart, which is riskier than a resize on Standard brokers. On Express Brokers, prefer removing brokers because Express doesn't support in-place resize.

Partition count

Over-partitioning is silent waste. Every partition consumes broker memory, adds to controller metadata, and (on Serverless) costs partition-hours. A useful rule of thumb: target 1 partition per 10 MB/s of expected topic throughput, up to the level of parallelism you actually need on the consumer side. Topics receiving under 100 KB/s should almost always have 3 partitions, not 30. Use kafka-topics.sh --describe plus kafka-log-dirs.sh to find topics with cold partitions eating disk and controller state for no benefit.

Retention

The default 7-day retention that ships in many Kafka templates is often 3-4x what applications actually consume. Query your consumer offsets for the oldest committed offset per topic; anything older than that is dead storage. Combine tiered storage with an honest retention audit and 40–60% storage reductions are typical.

MSK vs Confluent Cloud vs self-managed on EC2

Because Kafka is a portable protocol, the honest comparison isn't just Express vs Standard within MSK. It's whether MSK is the right platform at all. Here's how the three main options price out at three representative throughput tiers, assuming three-AZ, RF=3, 24x7 operation, in us-east-1 at 2026-Q3 rates.

Dimension	MSK Provisioned (Express)	Confluent Cloud (Dedicated)	Self-managed on EC2/EKS
Small (5 MB/s, 7d retention)	~$620/mo	~$540/mo	~$780/mo
Medium (50 MB/s, 7d retention)	~$3,900/mo	~$4,600/mo	~$3,100/mo
Large (300 MB/s, 30d retention)	~$21,500/mo	~$34,000/mo	~$16,800/mo
Ops burden	Low (managed)	Very low (fully managed)	High (2-4 SRE hours/week)
Tiered storage	Native, ~$0.021/GB	Native (Infinite Storage)	DIY (KIP-405 or S3 sink)
Cross-AZ replication cost	Billed separately at $0.01/GB	Included in cluster price	Billed separately at $0.01/GB
Private connectivity	PrivateLink ($0.01/GB + ENI hours)	PrivateLink included in Enterprise	Native VPC
Best fit	AWS-native shops, mid throughput	Multi-cloud, low ops tolerance	Cost-sensitive at scale, has SRE bandwidth

The pattern is consistent: Confluent wins on the small end because it doesn't charge separately for network and includes tiered storage in the sticker price, MSK wins in the middle where Express Brokers are efficient, and self-managed wins at scale, but only if you have SREs who genuinely want to operate Kafka. Compare this to the earlier managed Postgres pricing comparison across AWS, Azure, and GCP we published. That same "managed premium flips at scale" pattern shows up in every stateful managed service.

Observability: what to measure before you cut

Every optimization above assumes you know what your cluster is actually doing. MSK ships four metric tiers (DEFAULT, PER_BROKER, PER_TOPIC_PER_BROKER, and PER_TOPIC_PER_PARTITION), and enabling the most granular tier can add $200–$800/month to your CloudWatch bill on a busy cluster. Enable PER_TOPIC_PER_PARTITION only when actively investigating; drop back to PER_BROKER for steady-state monitoring. Our full AWS CloudWatch cost optimization playbook for logs, metrics, and alarms covers the metric-cost math in more detail.

For Kafka-specific observability I recommend piping JMX metrics into Prometheus using the AWS-provided open-source exporter, and building alerts on BytesInPerSec, UnderReplicatedPartitions, and MessagesInPerSec per topic. That gives you the raw data you need to identify oversized brokers, unused partitions, and topics whose retention exceeds actual consumer lag. Those three findings drive most of the cost cuts described in this article. Reference specs are in the official KIP-392 fetch-from-follower proposal if you want the protocol-level detail.

Frequently Asked Questions

How much does Amazon MSK cost per month?

A small MSK Provisioned cluster (3 kafka.m7g.large Standard brokers, 100 GB EBS each, ~5 MB/s throughput) costs around $620/month in us-east-1 as of 2026-Q3. Scale roughly linearly with broker instance size and add ~$0.021/GB-month for tiered storage and ~$0.01/GB for inter-AZ replication. MSK Serverless starts at around $290/month for the cluster baseline plus partition and data charges.

Is MSK cheaper than Confluent Cloud?

MSK is cheaper than Confluent Cloud Dedicated in the 30-100 MB/s range where Express Brokers are most efficient, and cheaper than Confluent Cloud Enterprise at any scale. Confluent Cloud Basic and Standard undercut MSK on very small workloads because they bundle networking. At 300+ MB/s, both are more expensive than well-run self-managed Kafka.

What is the difference between MSK Serverless and Provisioned?

MSK Serverless charges per partition-hour and per-GB in and out with no broker sizing, while Provisioned charges per broker-hour plus EBS. Serverless is economical below roughly 15 MB/s sustained throughput and for bursty workloads. Provisioned wins for steady throughput above 20 MB/s, especially with Express Brokers.

How can I reduce MSK data transfer costs?

Enable rack-aware fetch-from-follower (KIP-392) so consumers read from the in-AZ replica, colocate producers with brokers where possible, and drop to RF=2 for non-critical topics. Together these tactics typically cut MSK data transfer charges by 60–80%.

Does MSK charge for tiered storage reads?

Yes. MSK tiered storage has a small per-GB retrieval fee (currently around $0.02/GB) when consumers fetch data older than the local retention window. For head-of-log consumption this is negligible; for consumers that regularly replay days of history, model the fetch cost against the EBS savings before enabling.