AWS MSK pricing is easy to look up and surprisingly easy to misread. The pricing page gives you the unit rates, but a real Kafka workload is not a single unit. It is brokers running all month, storage retained across replicas or tiers, producers writing, consumers reading, private connectivity processing bytes, connectors running workers, replication tools moving data, and sometimes a second cluster running during migration.
That is why the useful question is not "what does MSK cost?" It is "which MSK pricing model matches the way this workload creates traffic, retention, partitions, and operational change?" A small steady workload, a spiky event stream, and a high-throughput low-latency platform can all be valid MSK candidates, yet they land on different cost drivers.
The prices below should be treated as a pricing model, not a quote. AWS pricing changes by region and date; the exact examples cited here are from the official Amazon MSK pricing page as checked on May 20, 2026. Use the formulas with your own region, retention, replication, read fanout, and migration timeline before making a platform decision.
Quick Pricing Model Overview
Amazon MSK has three main deployment shapes that matter for pricing: Provisioned clusters with Standard brokers, Provisioned clusters with Express brokers, and MSK Serverless. They do not merely charge the same workload through different labels. Each one moves the bill toward a different axis.
| MSK option | Main pricing dimensions | Cost model bias | Good fit when |
|---|---|---|---|
| Provisioned Standard brokers | Broker instance hours, provisioned storage, optional provisioned storage throughput, data transfer, private connectivity | Capacity-first | You want Kafka control, predictable broker sizing, and can operate around provisioned capacity |
| Provisioned Express brokers | Express broker instance hours, stored data, data ingested, data transfer, private connectivity | Throughput and managed operations | You want higher per-broker throughput and faster operational actions than Standard brokers |
| MSK Serverless | Cluster hours, partition hours, GB written, GB read, storage, eligible data transfer | Usage-first | You prefer less capacity planning and the workload fits Serverless quotas and cost shape |
The choice becomes clearer when you separate fixed platform floor from workload-variable cost. Provisioned clusters have a broker-hour floor even when traffic is quiet. Serverless shifts more of the bill to partitions and read/write bytes, but it still has hourly cluster and partition charges. Express brokers remain provisioned, but AWS prices them around a different operational profile: broker instances plus storage plus per-GB data ingested.
That means a cost estimate should start with five workload numbers:
- Write throughput: average and peak producer ingress, preferably in MiB/s and GB/month.
- Read fanout: how many consumer groups read the same data, because read-heavy workloads can change Serverless economics.
- Retention: hot retention, tiered retention, and whether old data is replayed.
- Partition count: especially important for Serverless because partition-hours are a billable dimension.
- Network boundary: same VPC, multi-VPC PrivateLink, cross-Region replication, internet egress, or migration overlap.
If those numbers are missing, any MSK estimate is a dressed-up guess. Kafka is a log, and log economics are mostly a function of how many times each byte is written, copied, retained, read, and moved across a paid boundary.
Provisioned MSK Cost Drivers
Provisioned MSK with Standard brokers is the closest managed-service version of traditional Kafka capacity planning. You pick broker type and count, provision storage, choose optional features, and keep enough headroom for traffic, partitions, failures, and rebalancing. The bill starts with broker instance usage and storage; it grows when you add provisioned storage throughput, private connectivity, data transfer, Connect, Replicator, or longer migration windows.
AWS's official pricing example for Standard brokers in US East (N. Virginia), checked on May 20, 2026, uses three active kafka.m7g.large brokers for a 31-day month. The example lists \$0.204 per broker-hour, 2,232 broker-hours, and a broker instance subtotal of \$455.33. The same example calculates 1,516.13 GB-months of storage at \$0.10/GB-month, adding \$151.61, for a total of \$606.94 before applicable data transfer and optional features.
That example is useful because it exposes the base formula:
Provisioned MSK monthly cost =
broker instance hours
+ provisioned storage GB-months
+ optional provisioned storage throughput
+ data transfer and private connectivity
+ Connect, Replicator, monitoring, support, and migration overlap
Storage is where many teams undercount. In Provisioned Standard MSK, you pay for the amount of broker storage provisioned over time, not only the data producers write. If a cluster keeps extra disk for burst, retention safety, or operational headroom, that provisioned capacity is part of the bill. Tiered storage can reduce how much hot broker storage you keep, but it introduces its own low-cost tier storage and retrieval dimensions. AWS's MSK pricing page gives a Standard broker tiered storage example with primary storage, low-cost tier storage, and retrieval charges, which is exactly the mental model to use: old data may leave the hot tier, but it does not become free.
Provisioned storage throughput is another line item that tends to appear after the first sizing pass. AWS's example for US East (N. Virginia) shows 3 brokers each provisioned with 300 MB/s of storage throughput, producing 900 MB/s-months at \$0.08 per MB/s-month, or \$72 for the month. That number may be small next to broker hours in the example, but at larger broker counts or higher provisioned throughput it becomes part of the steady platform floor.
MSK Serverless Pricing Tradeoffs
MSK Serverless changes the conversation from "how many brokers should we run?" to "how many partitions and bytes will this workload use?" That is attractive for teams that do not want to manage broker sizing, but it does not remove the need for a cost model. It changes which variables matter.
AWS describes MSK Serverless pricing as cluster-hours, partition-hours, GB written by producers, GB read by consumers, and storage consumed. On the official pricing page, the Serverless example in US East (Ohio) uses one cluster for a 31-day month, 5 topics with 20 partitions each, 100 GB/day written, 200 GB/day read, and 24-hour retention. As checked on May 20, 2026, the example rates are \$0.75/cluster-hour, \$0.0015/partition-hour, \$0.10/GB-in, \$0.05/GB-out, and \$0.10/GB-month storage, producing a total of \$1,299.60 for that example workload.
The important part is not that one example total. It is the shape:
| Workload variable | Why it matters in MSK Serverless |
|---|---|
| Partitions | Every partition exists over time, so high partition counts create a persistent hourly cost even before traffic grows |
| Writes | Producer ingress is charged per GB, which makes compression and data shape visible in the bill |
| Reads | Read fanout matters because each consumer group that reads the same data can increase GB-out |
| Retention | Storage is usage-based, but long retention still accumulates GB-months |
| Traffic boundaries | Cross-Region transfer and internet egress can still apply depending on topology |
Serverless is often easier to start with than to forecast. A team may know today's write volume but not tomorrow's number of consumer groups. Kafka's value often grows through reuse: fraud, personalization, search indexing, observability, CDC, and ML features all read the same topics. That is good platform leverage, but in a usage-priced read model, reuse should be part of the estimate instead of an afterthought.
MSK Express Brokers Pricing Tradeoffs
Express brokers sit inside MSK Provisioned, but their pricing model is not identical to Standard brokers. AWS says Express brokers are built to make Apache Kafka easier to manage, provide up to 3x more throughput per broker, scale up to 20x faster, and reduce recovery time by 90% compared with Standard brokers. Pricing follows that product shape: broker instance usage, storage used, and a per-GB charge for data written to Express brokers, plus standard data transfer where applicable.
AWS's official Express example for US East (N. Virginia), checked on May 20, 2026, uses three express.m7g.large brokers active for 31 days and 1 TB ingested and stored. The example lists \$0.408 per broker-hour, \$0.01/GB of data ingested, and \$0.10/GB-month storage, yielding \$1,020.66 for that scenario.
That does not make Express "more expensive" or "less expensive" in isolation. It means the workload must justify the operational and throughput profile. If Express lets you use fewer brokers, recover faster, or handle a throughput pattern that Standard brokers would over-provision for, the higher broker-hour example may be offset elsewhere. If the workload is modest and steady, the extra per-GB ingest and broker profile may not be the lever you need.
The practical comparison is not a beauty contest between SKUs. It is a fit matrix: Standard for control and predictable provisioned capacity, Serverless for lower broker-management burden with usage-shaped pricing, Express for high-throughput managed Kafka operations where the broker profile matters.
Costs Teams Often Miss
The first MSK spreadsheet usually includes broker hours and storage. The second one includes the bill that actually arrives. The gap comes from Kafka's habit of multiplying bytes through availability, fanout, replication, and migration.
Private connectivity is one example. AWS's MSK pricing page describes multi-VPC private connectivity powered by AWS PrivateLink for clients in other VPCs or accounts, with hourly charges per cluster and authentication scheme plus per-GB processing. In the official pricing example, AWS adds a fixed private-connectivity charge and a variable data-processing charge on top of the MSK cluster charges. That may be exactly what the architecture needs, but it belongs in the first estimate.
MSK Connect and MSK Replicator follow the same pattern. MSK Connect charges for connector workers measured in MSK Connect Units, where AWS defines each MCU as 1 vCPU and 4 GB memory. The official Connect example uses workers that autoscale between 2 and 4 MCUs and totals \$218.24 for the month in that scenario. MSK Replicator charges for Replicator-hours and data processed, with cross-Region replication also paying standard AWS cross-Region data transfer; AWS's example for 50 MB/s continuous cross-Region replication totals \$13,647.
These are not hidden fees in the sense of being secret. They are hidden in the sense that they live outside the "three brokers plus storage" mental model:
- Cross-AZ and cross-boundary traffic: Amazon MSK says inter-broker replication traffic is not charged, but data transferred in and out of MSK clusters can still follow standard AWS data transfer rules. Cross-AZ, cross-Region, PrivateLink, and internet paths should be modeled separately.
- Read fanout: Serverless read charges, downstream connector reads, and replay jobs can make consumer traffic as important as producer traffic.
- Migration overlap: A safe migration often runs source and target platforms at the same time while replication catches up and clients move in waves.
- Monitoring and support: CloudWatch metrics, logs, alarms, and support plans can be small or material depending on the operating model.
- Over-provisioned headroom: Provisioned clusters reserve enough broker and storage capacity for peak, failure, and rebalancing conditions, not only the median day.
For AWS infrastructure inputs outside MSK, use the official service pages for the same region and date. For example, AWS EC2 pricing is the source for same-Region data transfer rules, Amazon EBS pricing is the source for gp3 storage and throughput rates, and Amazon S3 pricing is the source for object storage rates. Mixing regions or dates inside one estimate creates a spreadsheet that looks precise but is not decision-grade.
A Cost Model Template You Can Reuse
The cleanest MSK cost model is workload-first. Start with workload facts, translate them into pricing dimensions, then add platform services. The table below is intentionally a template; replace every placeholder with values from your AWS region and account assumptions.
| Input | Example unit | Why it matters |
|---|---|---|
| Average write throughput | MiB/s or GB/month | Drives data-in, broker sizing, storage accumulation, and replication load |
| Peak write throughput | MiB/s | Drives Provisioned broker count, Express fit, and headroom |
| Read fanout | Number of full-stream readers | Drives Serverless data-out, connector traffic, and replay cost |
| Hot retention | Hours or days | Drives broker storage or Serverless storage |
| Tiered retention | Days or months | Drives low-cost tier storage and retrieval if tiered storage is used |
| Partition count | Active partitions | Drives Serverless partition-hours and broker metadata/ops constraints |
| Network topology | Same VPC, multi-VPC, cross-Region | Drives data transfer, PrivateLink, and replication charges |
| Migration window | Days of dual-running | Drives temporary double-platform and Replicator costs |
Once those inputs are known, compare the options with formulas rather than adjectives:
Provisioned Standard =
broker-hours + provisioned storage + optional throughput
+ private connectivity + data transfer + surrounding services
MSK Serverless =
cluster-hours + partition-hours + GB-in + GB-out + storage
+ eligible data transfer + surrounding services
Provisioned Express =
express broker-hours + GB ingested + storage
+ private connectivity + data transfer + surrounding services
This is also the right place to model risk. A lower monthly estimate is not useful if the workload violates service quotas, cannot meet latency expectations, or requires an operational pattern the team cannot support. Cost models should include assumptions, not bury them.
When an MSK Alternative Changes the Equation
If the largest line item comes from a mismatch between workload and SKU, stay inside MSK and choose the better SKU. A spiky workload with manageable partitions may be better served by Serverless. A high-throughput workload may justify Express. A steady platform with strict Kafka controls may belong on Provisioned Standard. SKU selection is a real lever.
But some Kafka costs come from architecture rather than SKU. Traditional Kafka ties durable log storage to brokers, uses replication for availability, and often moves data during scaling, recovery, and reassignment. Managed Kafka can reduce operational burden, but it does not automatically remove every storage and data-movement multiplier. When retention is large, read fanout is high, or scaling events move too much local state, the bigger lever is the storage architecture.
That is where AutoMQ enters the evaluation. AutoMQ keeps Kafka API compatibility while redesigning the storage layer around shared object storage through S3Stream. Its documentation describes a storage-compute separated architecture in which broker nodes are stateless and Kafka data is offloaded to shared storage. In practical cost-model terms, the question changes from "which broker SKU should hold this data?" to "how much broker-local state should exist at all?"
This is not a claim that every MSK workload should move. MSK is a strong AWS-native managed Kafka service, and many teams should use it. AutoMQ is relevant when the cost problem is structural: too much retained data on broker-attached storage, too much operational friction around stateful brokers, or too much over-provisioned compute kept around because storage and compute cannot scale independently. In those cases, an AutoMQ pricing calculator comparison can sit next to the MSK formulas and test whether changing the architecture changes the bill.
The cost model should make that decision soberly. If your spreadsheet shows that MSK cost is dominated by a few connectors, Replicator traffic, or cross-Region topology, an alternative broker architecture may not fix the main issue. If it shows that the core Kafka log is paying repeatedly for storage, headroom, and state movement, architecture belongs in the conversation.
Sources
- Amazon MSK pricing
- AWS EC2 On-Demand pricing: data transfer within the same AWS Region
- Amazon EBS pricing
- Amazon S3 pricing
- MSK Replicator pricing documentation
- AutoMQ overview
- AutoMQ architecture overview
- AutoMQ stateless broker
- AutoMQ pricing calculator
FAQ
How much does AWS MSK cost?
AWS MSK cost depends on the MSK option, region, broker or cluster configuration, storage, throughput, partitions, read/write traffic, networking, and surrounding services such as MSK Connect or MSK Replicator. The safest estimate starts with your workload model, then applies current AWS rates for your target region.
Is MSK Serverless always lower cost than Provisioned MSK?
No. MSK Serverless can reduce broker capacity planning, but it charges for cluster-hours, partition-hours, GB written, GB read, and storage. Workloads with many partitions or heavy read fanout can become more expensive than expected, while small or spiky workloads may fit Serverless well.
What is the difference between MSK Standard and MSK Express pricing?
Standard brokers are priced around broker instance hours, provisioned storage, and optional provisioned storage throughput. Express brokers are also provisioned, but AWS prices them with Express broker instance hours, storage used, and a per-GB data-ingested charge, reflecting their higher-throughput and faster-operations profile.
Does Amazon MSK charge for inter-broker replication traffic?
AWS states on the MSK pricing page that you are not charged for data transfer used for replication between brokers or between metadata nodes and brokers. You still pay standard AWS data transfer charges for data transferred in and out of MSK clusters where applicable, so client topology and replication paths still matter.
When should I consider an MSK alternative?
Consider an alternative when the cost driver is architectural rather than a poor SKU choice. If retained data, stateful broker operations, over-provisioned capacity, or data movement dominate the model, a Kafka-compatible shared-storage architecture such as AutoMQ may be worth comparing. If the main issue is a specific MSK feature or connector topology, tune the MSK design first.