Amazon MSK(Amazon Managed Streaming for Apache Kafka)는 완전 관리형 Kafka 서비스로, 브로커와 스토리지를 직접 운영하지 않아도 손쉽게 대용량 실시간 데이터를 처리할 수 있는 것이 장점입니다. 그러나 이 편리함 뒤에는 예상치 못한 비용 증가가 따라붙기 쉽습니다.
Kafka 클러스터는 트래픽량, 파티션 수, 메시지 크기, 복제 계수(Replication Factor) 등에 따라 내부적으로 CPU, 메모리, 네트워크, 스토리지 사용량이 크게 달라집니다. 특히, 브로커 인스턴스 비용, EBS 스토리지 비용, 데이터 전송 비용, 커넥터(MSK Connect) MCU 비용 등이 복합적으로 발생하며, 이를 체계적으로 관리하지 않으면 매달 수백~수천 달러가 불필요하게 지출될 수 있습니다.
이 때문에 MSK 비용을 효율적으로 절감하기 위해서는 AWS Cost Explorer를 통한 정기적인 비용 분석이 필수입니다. Cost Explorer는 MSK 비용을 Usage Type, Resource ID, Linked Account, Region 등의 기준으로 구분해 보여주어, 어떤 서비스·클러스터·커넥터가 비용을 가장 많이 발생시키고 있는지를 빠르게 파악할 수 있게 해줍니다. 이를 통해 무의미하게 높은 Retention 설정, 파티션 과다 생성, 불필요한 커넥터 유지, Cross-AZ 트래픽 증가 등의 비용 누수를 찾아내어 개선할 수 있습니다.
이 글에서는 AWS Cost Explorer를 활용해 Kafka 클러스터 비용을 항목별로 분석·진단하는 방법을 알아보겠습니다.
Amazon MSK 클러스터의 비용을 정확하게 파악하려면 AWS Cost Explorer를 활용해 세부 항목을 필터링하고 분석하는 것이 중요합니다. 특히 MSK는 브로커 인스턴스, 스토리지, 데이터 처리, 그리고 모니터링(Log 및 CloudWatch) 항목별로 요금이 과금되므로, 이를 구분해 분석하는 과정이 필요합니다.
먼저 AWS Cost Explorer에 접속해 필터링 설정을 통해 MSK 관련 비용을 추적하는 방법은 아래와 같습니다.
Cost Explorer 접속 방법
AWS Console 상단 검색창에 Cost Explorer를 입력하고 선택합니다. Cost Explorer 열기를 클릭합니다.
Group By 설정
보다 구체적인 분석을 위해 Group By 항목을 추가 설정합니다. MSK 비용은 UsageType 필터를 통해 상세 항목별로 확인할 수 있습니다. UsageType의 상세 설명은 아래에 있습니다. Resource ID로 필터하게 되면 각 MSK 클러스터별로 비용을 분리해서 확인할 수 있습니다. 커넥터를 등록해서 사용할 경우 각 커넥터의 비용도 확인 가능합니다.
필터링 설정
필터링 설정은 Service: Amazon MSK 선택 후, UsageType에서 위 항목들을 개별 선택하거나, 전체 선택 후 후처리 방식으로 확인할 수 있습니다.
일별/월별 트렌드 분석 설정
상단의 기간 선택 메뉴에서 원하는 기간(예: 이번 달, 지난 6개월 등)을 선택해 비용 트렌드를 분석합니다. 이 과정을 통해 월별 MSK 클러스터별, 항목별 비용 변화를 한눈에 확인할 수 있습니다. 일별 분석은 급격한 변화 파악에 유용하고, 월별 분석은 장기 트렌드 확인에 유용합니다.
아래는 UsageType으로 Group By한 예시입니다.
대부분의 비용이 APN2-Kafka.mcu.general, APN2-Kafka.m5.large에서 나가고 있습니다. debezium을 활용한 커넥터 수를 다수 운용하기 때문입니다. 총비용의 90 % 이상이 MCU + 브로커 EC2 + EBS 세 항목이 차지하고 있습니다.
2025년 2월에 MCU -34 %로 비용이 급감한 것을 확인할 수 있습니다. 이는 일부 Kafka Connect 커넥터 축소 작업이 있었기 때문입니다.
아래는 resource ID로 group by한 결과입니다.
주요 특이점은 cdc-prod-item-detail-ep 커넥터가 2월 이후로 완전 제거되면서 비용이 크게 감축한 것이 있습니다.
이 과정을 통해 내 Kafka 클러스터의 현재 비용 구조를 명확히 파악할 수 있으며, 특히 브로커 인스턴스 비용, 스토리지 비용, 데이터 처리 비용 등 비용의 주범이 무엇인지 식별할 수 있습니다. 이 정보를 기반으로 이후의 비용 최적화 전략을 세울 때, 어느 항목에 집중해야 할지 우선순위를 정하는 데 도움이 됩니다.
MSK를 Usage Type으로 분류하면 아래와 같은 항목을 확인할 수 있습니다.
MSK Serverless 클러스터를 사용할 때 발생하는 비용 항목으로, 서버리스 Kafka의 데이터 처리량, 파티션 수, 클라이언트 수 등에 따라 동적으로 부과됩니다. Serverless 클러스터는 EC2 브로커 인스턴스를 직접 관리하지 않고 Kafka 클러스터를 운영할 때 사용하는 방식으로, 일반적인 프로비저닝 클러스터에서는 이 항목이 나타나지 않습니다.
Debezium 등을 활용한 커넥터를 EC2/EKS에 직접 띄운다면 그 서버 비용은 Kafka 클러스터 비용이 아닌, EC2 또는 EKS 클러스터의 일반적인 인프라 비용에 포함됩니다. 반면, MSK Connect를 사용해 Debezium 커넥터를 배포했다면 APN2-Kafka.mcu.general 비용 항목에서 처리량, 커넥터 수, 파티션 수에 따라 과금됩니다.
커넥터 생성 시 프로비저닝 크기(CPU, 메모리)를 지정하게 됩니다. 이때 선택하는 값은 커넥터 단위의 리소스 크기이며, AWS가 이를 기반으로 내부적으로 서버를 자동 할당해 관리합니다. 즉, 커넥터마다 독립된 컨테이너(혹은 내부 서버)가 생성됩니다. 이 때 MCU는 AWS MSK Connect에서 사용하는 리소스 단위를 의미합니다. 1 MCU는 1vCPU, 4GiB 메모리로 구성됩니다.
1 MCU는 서울 리전 기준 시간당 $0.135, 월 $97.2가 청구됩니다. 커넥터를 많이 생성한다면 그만큼 유지비용이 증가하게 됩니다.
MSK 클러스터의 브로커 인스턴스 중 kafka.m5.large 타입을 선택했을 때 발생하는 비용입니다. 이 항목은 프로비저닝된 Kafka 클러스터에서 인스턴스별로 시간 단위로 과금되며, 다른 인스턴스 타입을 사용할 경우에는 해당 타입의 항목이 표시됩니다. 예를 들어 Graviton 기반 kafka.m7g.large 인스턴스를 사용한다면, APN2-Kafka.m7g.large 항목이 표시됩니다.
서버의 유지비용은 아래 링크에서 참조 가능합니다.
https://aws.amazon.com/ko/msk/pricing/
예를 들어 kafka.m5.large 3대를 클러스터에서 운영한다면 아래 근거에 의해 월 $557가 지출됩니다.
$0.258 x 24 hours x 30 day x 3 ea = $557.28
Kafka 클러스터의 브로커 인스턴스에 연결된 EBS 스토리지(General Purpose SSD, GP2)의 사용량에 따라 발생하는 비용입니다. 이는 Kafka의 로그와 데이터를 저장하는 공간으로, 저장 용량(GB)과 저장 시간(시간 단위)에 따라 과금됩니다.
Kafka 클러스터 내외부에서 발생하는 데이터 전송량에 대한 비용입니다. 주로 가용영역(AZ) 간 트래픽이나 Kafka에서 다른 AWS 서비스로 데이터를 전송할 때 발생하며, 예를 들어 Kafka 클러스터가 있는 AZ와 클라이언트(Producer/Consumer)가 다른 AZ에 있거나, Kafka 데이터를 Lambda, OpenSearch, S3 등으로 전송할 때 이 항목에서 비용이 발생합니다. 데이터 전송량(GB)에 따라 과금되며, Kafka 클러스터의 구조와 사용 방식에 따라 상당한 비용 차이가 발생할 수 있습니다.
APN2-Kafka.mcu.general은 커넥터 생성 및 활용으로 비용이 발생하게 됩니다. 이 UsageType을 Resource ID로 분류하게 될 경우 커넥터별로 사용하게 된 비용을 확인할 수 있습니다. 다만 비용 확인 시에 같은 커넥터인데도 여러개로 쪼개져 있는 것을 볼 수 있는데요. 이로 인해 비용을 제대로 분석하기가 어렵습니다.
하나의 커넥터가 Cost Explorer에서 Resource ID별로 분리되어 표시될 수 있습니다. MSK Connect에서 커넥터를 삭제 후 재생성하거나, 새로운 이름이나 설정(예: 파라미터 변경, Task 수 변경 등)으로 커넥터를 다시 생성하면, AWS 내부에서는 새로운 리소스 ID로 인식하기 때문입니다. 같은 기능의 커넥터라도 생성 시점마다 다른 Resource ID로 기록되기 때문에, 비용 분석 시 동일한 커넥터의 비용이 여러 줄로 나뉘어 표시되는 현상이 나타납니다.
이러한 이유로, 커넥터별로 명확한 태그(Name, Env, Project 등)를 부여하고, Cost Explorer에서 Tag 기준으로 Group By를 설정해 분석하는 것이 가장 효과적입니다.
예를 들어, Project=order-cdc, Env=prod 태그를 넣어두면, 재생성되더라도 동일 프로젝트/환경에 속한 비용을 한눈에 파악할 수 있게 됩니다.
AWS MSK(Amazon Managed Streaming for Apache Kafka)는 CloudWatch를 통해 주요 성능 지표를 제공합니다. 아래의 경로로 CloudWatch 메트릭을 선택합니다.
AWS 콘솔 접속 → CloudWatch → Metrics → Kafka 선택
MSK 클러스터별로 다음과 같은 주요 지표 확인할 수 있습니다.
Broker CPUUtilization: 각 브로커 인스턴스의 CPU 사용률
BytesInPerSec / BytesOutPerSec: 초당 데이터 처리량 (네트워크 인바운드/아웃바운드)
DiskUsed: 브로커별 스토리지 사용량
Amazon MSK 클러스터의 비용은 크게 브로커 인스턴스 비용, EBS 스토리지 비용, 데이터 전송 비용(AZ 간, VPC 외부), CloudWatch 로그 및 지표 비용 등으로 구성됩니다. 이러한 비용은 CloudWatch에서 제공하는 리소스 사용량 지표와 직접 연결되며, 모니터링을 통해 비용 급증 원인을 파악할 수 있습니다.
예를 들어, CloudWatch의 CPUUtilization 지표를 보면 브로커 인스턴스의 CPU 사용률을 확인할 수 있는데, CPU 사용률이 높다는 것은 데이터 처리량이 많다는 것을 의미하며, 이로 인해 브로커 인스턴스 자체의 시간당 요금이 계속 발생합니다. 만약 브로커별 CPU 사용률이 70~80% 이상으로 지속된다면 과부하 신호입니다. 브로커 인스턴스 타입 또는 개수 조정이 필요할 수 있습니다.
또한, BytesInPerSec, BytesOutPerSec 지표는 네트워크 트래픽을 나타냅니다.
BytesInPerSec: 초당 수신 바이트 (프로듀서 → 브로커)
BytesOutPerSec: 초당 송신 바이트 (브로커 → 컨슈머)
데이터 처리량이 많을수록 Data Transfer 비용(예: AZ 간 트래픽)과 연계됩니다. 특히 다중 가용영역(AZ)에 브로커가 분산된 경우, 파티션 복제 과정에서 AZ 간 데이터 전송 비용이 발생하며, 이는 Cost Explorer의 APN2-DataTransfer-Regional-Bytes 항목으로 청구됩니다. 특정 브로커의 네트워크 트래픽이 다른 브로커보다 현저히 높다면 불균형 발생 가능성이 있습니다. 이 때는 파티션 분산 상태 확인 및 리밸런싱이 필요합니다.
DiskUsed 지표는 브로커별 EBS 스토리지 사용량을 나타내며, EBS 용량에 따라 APN2-Kafka.Storage.GP2 비용이 부과됩니다. 만약 DiskUsed가 계속 증가한다면, 주기적인 로그 청소(retention 정책 관리)나 데이터 파티션 재조정 등을 검토해야 합니다. 디스크 사용률 80% 이상이면 진단이 필요합니다. 로그 Retention 설정 미흡, 파티션 과다 생성, 과도한 메시지 저장이 원인일 수 있습니다. Kafka Retention.ms, Segment.bytes, Cleanup.policy 파라미터를 점검하고 불필요한 토픽/파티션은 삭제해야 합니다.
Kafka는 높은 성능과 유연성을 제공하는 만큼, 제대로 관리하지 않으면 불필요한 비용이 빠르게 누적됩니다. 이번 분석을 통해 확인했듯이 MSK 비용의 대부분은 브로커 인스턴스, EBS 스토리지, 데이터 전송, MSK Connect MCU 비용이 차지하고 있으며, 이들 항목을 면밀히 살펴보고 불필요한 사용을 줄이는 것이 핵심입니다.
AWS Cost Explorer와 CloudWatch 모니터링을 함께 사용하면, 어디서 비용이 발생하는지, 언제 증가했는지, 어떤 리소스가 주범인지 구체적으로 파악할 수 있습니다. 이를 기반으로 브로커/커넥터 스케일 조정, Retention 설정, 파티션 구조 개선, Cross-AZ 트래픽 최소화 등 구체적인 비용 절감 조치를 취해야 합니다.