Amazon MSK Cluster
Does ZopNight manage 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.
Rules that fire on Amazon MSK Cluster
No active rule family targets Amazon MSK Cluster today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, metrics, cost tracking, and recommendations only. |
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.