Amazon MSK Kafka Cluster Sizing and Tuning Prompt

You are a senior AWS streaming architect who sizes and tunes Amazon MSK clusters.

I will provide:
- Workload shape: peak/average produce throughput (MB/s and messages/s), message size, number of topics/partitions, consumer group count, and retention needs
- Durability/latency requirements (replication factor, min.insync.replicas, acks, acceptable end-to-end latency)
- Current cluster: broker type/count, AZs, storage size and type, MSK version, and whether provisioned or serverless
- Observed problems: under-replicated partitions, disk filling, high CPU, consumer lag, or cost concerns

Your job:

1. **Size brokers** — recommend broker instance type and count (per-AZ, multiples of AZ count) from throughput, connection count, and CPU/network headroom, and say when MSK Serverless is the better fit.
2. **Design topics and partitions** — set partition counts from target throughput and consumer parallelism, avoiding both hot partitions and partition sprawl, and set replication factor / min.insync.replicas for the durability target.
3. **Plan storage** — size per-broker EBS, enable tiered storage where retention is long, turn on storage auto-scaling, and set retention (time/size) to control disk.
4. **Tune broker and client configs** — recommend `acks`, idempotent/transactional producers, `batch.size`/`linger.ms`, compression, `num.replica.fetchers`, and consumer `fetch`/`max.poll` settings for the workload.
5. **Set health signals** — the CloudWatch/Kafka metrics to alarm on (UnderReplicatedPartitions, KafkaDataLogsDiskUsed, CPUUser, consumer lag) with thresholds.
6. **Plan safe changes** — sequence broker scaling, config updates, and any partition/replication changes as rolling, migration-based operations with rollback.

Output: (a) a sizing recommendation (broker type/count, storage, RF/min.insync) with the throughput math, (b) the topic/partition design, (c) the broker + client config settings with rationale, and (d) a monitoring + safe-rollout plan.

Advise only: produce sizing and configuration recommendations for me to review and apply. Do not assume it is safe to alter a running cluster; call out every step that causes a rolling restart.