infra-kafka-cost-optimizer

Audit Kafka topic retention and partitions to estimate monthly savings with tiered storage adjustments.

14|1|Updated May 5, 2026
One-click install
npx skills add https://github.com/ivanshamaev/de-agent-skills --skill infra-kafka-cost-optimizer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: infra-kafka-cost-optimizer
Source: https://github.com/ivanshamaev/de-agent-skills/tree/main/group_skills/infra_dataops_group_skills/infra_kafka_cost_optimizer
Command: npx skills add https://github.com/ivanshamaev/de-agent-skills --skill infra-kafka-cost-optimizer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Kafka clusters often overpay for disk, bandwidth, and operational overhead due to oversized retention, unnecessary partitions, idle consumer metadata, and inefficient compression settings.

Core Features & Use Cases

  • Tiered storage for cold logs (local.retention.ms vs retention.ms): Offload older segments from broker disks to S3/GCS to reduce storage spend while keeping long total retention.
  • Topic retention right-sizing and audit: Identify over-retained topics and estimate cost impact by combining retention configuration with topic size signals.
  • Partition and consumer group hygiene: Detect over-partitioning, reduce partition waste (with safe migration notes), and remove idle consumer groups to lower metadata overhead.
  • Compression and cost modeling: Estimate savings from producer/broker compression (e.g., lz4) and compare self-managed vs managed Kafka economics (including cross-region considerations).
  • Broker sizing guidance: Use practical checks to tune broker instances based on observed workload characteristics and disk-vs-compute constraints.

Quick Start

Ask your AI to audit your Kafka cluster’s topic retention settings, detect over-retained topics and over-partitioned usage, and propose a tiered storage + retention adjustment plan with an estimated monthly savings using the compression calculator.

Frequently Asked Questions about infra-kafka-cost-optimizer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reduce Kafka storage costs without losing long-term data retention?

Enable Kafka tiered storage to offload cold log segments from broker disks to S3 or GCS. This reduces local disk spend by setting a shorter local.retention.ms while maintaining a longer overall retention.ms for long-term data availability.

How do I audit Kafka topic retention settings to find cost savings?

Audit Kafka topic retention by combining retention configuration with topic size signals to identify over-retained topics. This process calculates the cost impact of oversized retention and produces actionable retention override configurations to reduce infrastructure spend.

Does Kafka tiered storage work with self-managed clusters on Kubernetes and Strimzi?

Yes, tiered storage cost optimization applies to self-managed Kafka on Kubernetes/Strimzi and Kafka 3.6+ deployments. It provides per-topic retention audits and configuration steps for environments where teams manage their own broker infrastructure.

What is the best way to detect over-partitioning and idle consumer groups in Kafka?

Detect over-partitioning and idle consumer groups by analyzing topic configurations and consumer metadata overhead. This identifies unnecessary partitions and idle consumers, providing safe migration notes and cleanup steps to lower metadata overhead and reduce costs.

How do I estimate Kafka compression savings and compare self-managed vs managed costs?

Estimate Kafka compression savings by modeling producer and broker compression like lz4. Compare self-managed versus managed Kafka economics, including cross-region considerations, to calculate estimated monthly savings and determine the most cost-effective deployment.

When should I tune Kafka broker sizing based on disk versus compute constraints?

Tune Kafka broker sizing when observed workload characteristics indicate disk-versus-compute constraints. Use practical checks to adjust broker instances based on actual usage patterns, ensuring the infrastructure matches the workload without overpaying for unused capacity.