# Amazon MSK Cluster

> An MSK cluster bills per broker-instance-hour for every broker plus per GB-month of broker storage, and the meter runs whether topics carry traffic or not. ZopNight keeps 90 days of Kafka namespace metrics per cluster, ties cost from Cost Explorer or CUR 2.0, and recommends broker rightsizing.

Source: https://zop.dev/integrations/aws/msk
Updated: 2026-08-19

---

Amazon Managed Streaming for Apache Kafka (MSK) runs Kafka clusters billed per broker-instance-hour plus storage. Broker fleets are provisioned for peak throughput and bill continuously, making utilization visibility essential.

## Broker-hours plus broker disks

An MSK cluster bills per broker-instance-hour for every broker at its instance-type rate, plus per GB-month for the EBS storage each broker holds. Storage bills for what is provisioned per broker, not for what topics consume, so generous per-broker volumes are a second reservation stacked on the first. A highly available cluster spreads brokers across multiple availability zones, so the practical minimum is 3 broker meters, and clients that cross an availability zone to reach a broker pay standard inter-AZ transfer rates on top.

## Provisioned for a throughput that came once

Kafka fleets get sized for peak ingest and stay there: brokers cannot be casually removed, so cluster sizes ratchet upward and never back. The result is a fleet running sustained CPU and network at a small fraction of capacity. Dev and test clusters cloned from production sizing are the other repeat offender: three large brokers dutifully replicating a trickle of test events. MSK Serverless exists for exactly this shape, metering per cluster-hour, per partition-hour, and per GB moved instead of per broker. That shape is worth weighing for low-volume workloads before committing to a fixed fleet.

## Watching a cluster earn its brokers

Clusters are discovered on the 6-hour cycle. Hourly CloudWatch metrics from the Kafka namespace run with a 90-day lookback, and per-cluster cost comes from Cost Explorer or CUR 2.0. Recommendations focus on broker rightsizing. There is no stop operation; an MSK cluster bills until reconfigured or deleted, so like OpenSearch and ElastiCache it is a capacity problem rather than a scheduling one.

## Broker layout in the console

Amazon MSK console, then Clusters. A cluster's Properties tab shows broker instance type, broker count, and per-broker storage. Multiply the three and you have effectively read the bill.