AWS 07-3 쉬지 않고 흐르는 데이터 — Kinesis Data Streams·Data Firehose·MSK
고친 사람 github-actions[bot]
서울 리전에서 초당 1,000건, 건당 1 KB 짜리 클릭 로그를 받아 두 소비자가 읽게 한다고 해 봅니다. AWS 의 스트림 서비스 Kinesis Data Streams 를 「알아서 늘어나는」 온디맨드 모드로 만들면 한 달 약 $530 이 나옵니다. 같은 스트림을 용량을 직접 정하는 모드로 바꾸고 샤드(스트림의 용량 단위) 두 개만 두면 약 $81 입니다. 같은 데이터, 같은 서비스인데 여섯 배 넘게 차이 납니다.
어디서 그 차이가 나는지는 4절에서 계산합니다. 그 전에 풀어 둘 것이 있습니다. 주문 이벤트를 07-1편의 SQS 에 넣으면, 소비자 하나가 메시지를 받아 처리하고 지우는 순간 그 메시지는 큐에서 사라집니다. 큐는 「일감을 한 번 나눠 주는」 장치라서입니다. 반면 스트림은 기록을 도착한 순서대로 쌓아 두는 장부입니다. 누가 읽어도 기록은 지워지지 않고 보관 기간이 끝날 때까지 남습니다. 소비자마다 「나는 어디까지 읽었다」는 위치를 따로 들고 있어서, 분석 앱은 방금 들어온 것을 읽고 적재 앱은 한 시간 전 것을 읽고, 버그를 고친 앱은 어제 아침부터 다시 읽을 수 있습니다. 07-1편의 SNS 로도 소비자 여럿에게 같은 메시지를 보낼 수 있지만, 스트림이 다른 점은 순서를 지켜 남겨 두고 소비자가 원하는 위치부터 다시 읽게 한다는 데 있습니다.
이 편은 스트림을 다루는 서비스 셋을 봅니다. 스트림 자체를 빌려주는 Kinesis Data Streams, 스트림을 읽는 코드 없이 S3 같은 저장소에 모아 넣어 주는 Data Firehose(스트림 없이 혼자 받기도 합니다), 오픈소스 Kafka 를 대신 운영해 주는 MSK 입니다. 요금은 전부 2026-09-27 서울(ap-northeast-2) 기준입니다.
지도
flowchart TD
START["끊임없이 들어오는 기록"] --> Q1{"누가 읽나"}
Q1 -- "읽는 프로그램 없이<br/>S3·검색 저장소에 쌓는다" --> FH["Data Firehose"]
Q1 -- "소비자 여럿이<br/>각자 읽는다" --> Q2{"이미 Kafka 를<br/>쓰고 있나"}
Q2 -- "아니다" --> KDS["Kinesis<br/>Data Streams"]
Q2 -- "그렇다" --> MSK["MSK"]
KDS --> FH
MSK --> FH
첫 갈래는 「누가 읽나」입니다. 저장소에 그대로 쌓기만 한다면 읽는 프로그램을 짤 필요가 없으니 Firehose 로 곧장 보냅니다. 소비자가 여럿이고 각자 가공한다면 스트림이 필요하고, 그때는 조직이 이미 Kafka 를 쓰느냐가 Kinesis 와 MSK 를 가릅니다. Firehose 는 두 스트림 뒤에 붙어 적재만 맡기도 합니다. 흐르는 데이터를 SQL·코드로 실시간 집계하는 Managed Service for Apache Flink 는 11편(데이터 분석)에서 봅니다.
1. Kinesis Data Streams — 샤드를 빌려 쓰는 스트림
Kinesis Data Streams(아래 KDS)에서 스트림 하나는 샤드(shard) 여러 개의 묶음입니다. 샤드는 기록이 들어온 순서대로 한 줄로 늘어선 기록 묶음이고, 샤드 하나가 받는 양이 정해져 있습니다. 쓰기는 초당 1,000건 또는 1 MB 까지(파티션 키 길이 포함), 읽기는 초당 2 MB·호출 5번까지입니다. 스트림 전체 용량은 샤드 용량의 합입니다(Amazon Kinesis Data Streams Terminology and concepts).
기록을 넣는 쪽(생산자)은 기록마다 파티션 키를 붙입니다. KDS 는 이 문자열을 MD5 해시 함수로 128비트 정수로 바꾸고, 그 값이 속한 범위를 맡은 샤드에 기록을 넣습니다. 그래서 파티션 키가 같은 기록은 늘 같은 샤드에 들어가고, 샤드 안에서 기록은 KDS 가 매긴 시퀀스 번호 순서로 읽힙니다. 순서가 지켜지는 범위는 스트림 전체가 아니라 샤드 하나입니다. 사용자 ID 를 파티션 키로 쓰면 한 사용자의 클릭은 순서대로 읽히지만, 서로 다른 사용자의 클릭 사이 순서는 약속되지 않습니다. 스트림 전체에 한 줄 순서가 필요하다면 샤드를 하나만 두는 수밖에 없고, 그러면 초당 1,000건이 상한입니다.
flowchart TD
P["생산자<br/>키: user-7"] --> H{"키의 MD5 해시"}
H --> S1["샤드 1"]
H --> S2["샤드 2"]
S1 --> C1["소비자 A<br/>실시간 분석"]
S1 --> C2["소비자 B<br/>적재"]
S2 --> C1
S2 --> C2
키 하나에 기록이 몰리면 그 키를 맡은 샤드만 한도에 걸립니다. 한 파티션 키가 샤드 하나의 초당 1 MB·1,000건을 넘으면 어느 모드에서도 쓰기가 거절되므로, 키는 값이 고르게 퍼지는 것으로 고릅니다(Choose the right mode to stream in).
보관 기간과 소비자
기록이 남아 있는 보관 기간은 기본 24시간이고 최대 8,760시간(365일)까지 늘릴 수 있습니다. 24시간을 넘기면 추가 요금이 붙습니다. 스트림은 정한 위치부터 차례로 읽는 구조라, 몇 달 치를 두고 조건으로 골라 조회할 기록은 다음 절의 Firehose 로 S3 에 쌓는 편이 맞습니다. 소비자는 보통 Lambda 나 KCL(Kinesis Client Library, 샤드마다 읽는 일꾼을 붙여 주는 AWS 의 소비자 라이브러리)로 만듭니다. KCL 은 「어디까지 읽었나」를 DynamoDB 테이블에 적어 두므로 그 테이블 요금도 나갑니다(Amazon Kinesis Data Streams Terminology and concepts).
기본 소비자는 샤드에 직접 요청해서 기록을 가져가고, 샤드 하나의 읽기 한도 초당 2 MB·호출 5번을 나눠 씁니다. 소비자가 다섯이면 각자 초당 한 번꼴로만 요청할 수 있어서 기록이 도착하는 데 평균 1초 가까이 걸립니다. 소비자마다 샤드당 초당 2 MB 를 따로 받게 하는 기능이 향상된 팬아웃(enhanced fan-out)입니다. 이때는 소비자가 요청하는 대신 스트림이 기록을 소비자에게 평균 70 ms 안팎에 전달하고, 스트림 하나에 소비자를 최대 20개 붙일 수 있으며, 요금은 별도입니다(Develop enhanced fan-out consumers with dedicated throughput).
용량 모드와 요금
샤드 수를 누가 정하느냐가 용량 모드입니다. 온디맨드(On-demand Standard)는 KDS 가 샤드를 알아서 늘리고 줄입니다. 새 스트림은 초당 쓰기 4 MB 로 시작하고, 지난 30일 최고치의 두 배까지는 바로 받습니다. 그 두 배를 15분 안에 넘기는 급증은 곧바로 받지 못해 잠시 쓰기가 거절되므로 생산자는 재시도해야 합니다. 서울에서는 스트림 하나가 기본 초당 쓰기 200 MB 까지 늘어납니다(Quotas and limits).
프로비저닝은 샤드 수를 내가 정하고 바꿉니다. 필요한 샤드 수는 쓰기 KB/초 ÷ 1,024, 쓰기 건수/초 ÷ 1,000, 읽기 KB/초 ÷ 2,048 가운데 큰 값을 올림한 것이고, 쓰기 KB 에는 파티션 키 길이도 들어갑니다. 두 모드는 스트림마다 24시간에 두 번까지 오갈 수 있습니다.
두 모드는 값을 매기는 단위부터 다릅니다. 온디맨드는 켜 둔 스트림 시간과 쓰고 읽은 GB 에, 프로비저닝은 샤드 시간과 PUT 단위(기록을 25 KB 씩 잘라 센 개수, 1 KB 기록 하나는 1단위)에 요금을 매깁니다.
KDS On-demand Standard · 서울 · 2026-09-27
스트림 시간당 $0.049 (730시간이면 $35.77)
쓰기 GB 당 $0.099 (기록마다 1 KB 단위 올림)
읽기 GB 당 $0.049 (향상된 팬아웃이면 $0.062)
KDS 프로비저닝 · 서울 · 2026-09-27
샤드 시간당 $0.0185 (730시간이면 $13.51)
PUT 단위 100만 단위당 $0.0204
- 기본 24시간 보관은 추가 요금이 없고, 그보다 길게 두면 두 모드 모두 보관 요금이 더해집니다. KDS 는 AWS 프리 티어에 들지 않습니다(Amazon Kinesis Data Streams pricing)
- 프로비저닝의 기본 소비자 읽기에는 GB 요금이 없습니다. 읽기 값이 샤드 시간에 들어 있는 셈입니다
셋째로 On-demand Advantage 라는 약정 모드가 있습니다. 계정의 리전 단위로 켜며, 쓰기·읽기 GB 단가가 내려가는 대신 그 리전의 온디맨드 스트림 전체가 쓰기·읽기 각각 초당 25 MiB 를 약속하고 못 채운 만큼도 청구됩니다. 이 최소 약정액만 서울에서 한 달 약 $3,800 이라, 초당 수십 MB 를 꾸준히 흘리는 경우가 아니면 맞지 않습니다(Choose the right mode to stream in).
소비자마다 따로 드는 읽기 위치, 샤드 하나 안에서만 지키는 순서, 늘릴 수 있는 보관 기간 — 이 셋이 KDS 를 쓸지 가르는 기준이고, 샤드 한도와 파티션 키는 그 기준마다 따라붙는 부담입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 맞다를 고른 대가 |
|---|---|---|
| 한 이벤트를 실시간 분석·적재·알림 등 소비자 여럿이 각자 읽는다 | 소비자가 하나뿐이고 처리하면 끝나는 일감이다(→ SQS, 07-1편) | 소비자마다 읽은 위치를 적는 코드와 테이블(KCL 이면 DynamoDB 요금) |
| 사용자·기기 단위로 순서가 지켜져야 한다 | 스트림 전체에 걸친 한 줄 순서가 필요하다(→ 샤드 하나, 초당 1,000건 상한) | 키를 고르게 골라야 하고, 한 키가 샤드 한도를 넘으면 그 샤드만 쓰기가 거절된다 |
| 장애 뒤에 몇 시간~며칠 전부터 다시 읽어야 한다 | 몇 달 치를 두고 조건으로 골라 조회한다(→ Firehose 로 S3 에 쌓는다) | 24시간을 넘는 보관에 붙는 추가 요금 |
소비자 코드를 짤 생각이 없고 저장소에 쌓는 것이 전부라면 다음 절의 Firehose 로 가고, 이미 Kafka 클라이언트로 짠 시스템이 있다면 3절의 MSK 로 갑니다. 두 용량 모드 가운데 어느 쪽이 싼지는 4절에서 셈합니다.
2. Data Firehose — 받아서 모아 넣는 배달 서비스
Data Firehose(옛 이름 Kinesis Data Firehose)는 받은 기록을 목적지에 배달하는 완전 관리형 서비스입니다. 목적지는 S3·Amazon Redshift(데이터 웨어하우스)·Amazon OpenSearch Service(검색·로그 분석 엔진)·Splunk·Apache Iceberg 테이블·임의의 HTTP 엔드포인트 등입니다. 들어오는 길은 생산자가 직접 넣는 것(Direct PUT)과 KDS·MSK 에서 읽어 오는 것이 있습니다. 가장 큰 차이는 소비자 애플리케이션을 짜거나 서버를 둘 필요가 없다는 점입니다. 기록 하나는 최대 1,000 KB 입니다(What is Amazon Data Firehose?).
Firehose 는 기록을 하나씩 보내지 않고 버퍼에 모았다가 한꺼번에 씁니다. S3 로 보낼 때 버퍼 크기는 1~128 MiB(기본 5 MiB), 버퍼 시간은 0~900초(기본 300초)이고, 둘 중 먼저 차는 쪽에서 파일 하나를 씁니다. 버퍼를 키우면 S3 파일 수가 줄고, 줄이면 데이터가 빨리 도착합니다(BufferingHints — Amazon Data Firehose API Reference). 다만 Firehose 가 하는 일은 저장소에 쓰는 데서 끝납니다. 기록 하나하나에 곧바로 반응하는 코드를 돌려야 한다면 KDS 에 Lambda 소비자를 붙입니다.
가는 길에 모양도 바꿀 수 있습니다. JSON 기록을 열 단위로 저장하는 Parquet·ORC 형식으로 바꿔 S3 에 쓰면 저장 공간이 줄고 조회가 빨라집니다. 변환에는 AWS Glue 데이터 카탈로그에 만든 스키마가 필요하고, CSV 처럼 JSON 이 아닌 입력은 Lambda 로 먼저 JSON 으로 바꿉니다(Convert input data format in Amazon Data Firehose). 여기까지는 기록 하나씩 모양을 바꾸는 일이고, 여러 기록을 엮는 조인·집계는 Flink(11편) 몫입니다.
요금은 받은 GB 에 붙는데, 기록 하나를 5 KB(5,120바이트) 단위로 올림해 셉니다. 3 KB 기록은 5 KB, 12 KB 기록은 15 KB 로 칩니다(Amazon Data Firehose pricing).
Data Firehose · 서울 · 2026-09-27
Direct PUT·KDS 에서 수집 GB 당 $0.036 (월 첫 500 TB), 기록마다 5 KB 단위 올림
MSK 에서 수집 GB 당 $0.068, 5 KB 올림 없음
형식 변환 GB 당 $0.022 (올림한 수집 GB 기준)
+ S3 저장·요청, Lambda 변환, 데이터 전송 요금은 별도
5 KB 올림은 작은 기록에서 크게 튑니다. 4절과 같은 흐름(초당 1,000건 × 1 KB, 한 달 약 2,506 GB)을 Firehose 로 S3 에 쌓으면 기록마다 5 KB 로 셈해 약 12,531 GB × $0.036 = $451.13 입니다. 생산자가 이벤트를 묶어 기록 하나로 보내면 내려가는데, 묶음이 5,120바이트를 넘으면 10 KB 로 올림되니 경계를 세어야 합니다. 1 KB(1,024바이트) 이벤트 다섯 개는 딱 5,120바이트라 S3 에서 줄을 가르는 구분자 한 바이트만 붙어도 넘습니다. 구분자까지 넣어 네 개씩 묶으면 기록 6억 5,700만 개 × 5 KB ≈ 3,133 GB × $0.036 = $112.78 입니다.
결국 Firehose 를 쓸지는 버퍼만큼의 지연과 기록 크기에 민감한 요금을 받아들일 수 있느냐에 달렸습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 맞다를 고른 대가 |
|---|---|---|
| 로그·이벤트를 S3 에 시간 단위 파일로 쌓아 나중에 조회한다 | 기록마다 곧바로 코드를 돌려 반응해야 한다(→ KDS + Lambda) | 버퍼가 차거나 버퍼 시간이 될 때까지 늦게 도착한다 |
| JSON 을 Parquet 로 바꿔 조회 비용을 줄이고 싶다 | 여러 기록을 엮는 조인·집계가 필요하다(→ Flink, 11편) | 형식 변환 GB 요금과 Glue 스키마 관리 |
| 생산자가 이벤트를 5 KB 안쪽으로 묶어 보낼 수 있다 | 1 KB 안팎 기록을 하나씩 보낼 수밖에 없다(→ KDS 에 소비자를 붙여 직접 쓴다) | 묶음이 5,120바이트를 넘지 않게 세는 생산자 코드 |
3. MSK — Kafka 를 대신 운영해 준다
Kafka 는 KDS 와 같은 일을 하는 오픈소스 스트리밍 플랫폼입니다. 기록을 토픽(topic, 기록의 이름 붙은 묶음으로 KDS 의 스트림에 해당)에 쓰고, 토픽은 KDS 의 샤드에 해당하는 파티션으로 나뉘며, 순서는 파티션 하나 안에서 지켜집니다. 소비자는 컨슈머 그룹(같은 일을 나눠 맡는 소비자 묶음) 단위로 붙고, 그룹마다 파티션별로 어디까지 읽었는지를 오프셋(파티션 안 기록의 순번)으로 기억합니다. 이 기록들을 저장하고 내주는 서버가 브로커입니다.
Amazon MSK(Managed Streaming for Apache Kafka)는 이 브로커를 대신 띄우고, 고장 난 브로커를 감지해 바꾸고, 클러스터 생성·삭제를 맡습니다. 돌아가는 것은 오픈소스 Kafka 그대로라서, 기존 Kafka 애플리케이션과 도구·플러그인을 코드 수정 없이 씁니다(Welcome to the Amazon MSK Developer Guide). MSK 를 고르는 가장 큰 이유가 이것입니다. 외부 시스템과 데이터를 주고받는 커넥터 모음 Kafka Connect, 애플리케이션 안에서 스트림을 가공하는 라이브러리 Kafka Streams, 언어별 Kafka 클라이언트를 이미 쓰는 조직은 그대로 옮겨 옵니다. Kafka Connect 는 MSK Connect 로 맡길 수도 있습니다.
MSK 클러스터는 세 가지로 만듭니다. 프로비저닝 Standard 브로커는 브로커 크기·개수와 브로커마다 붙는 저장 용량(EBS)을 내가 정합니다. 서울에서는 브로커를 가용 영역 두 곳이나 세 곳에 고르게 나눠 두므로 가장 작은 구성이 브로커 둘입니다(Create an MSK Provisioned cluster). 제일 작은 kafka.t3.small 은 CPU 크레딧으로 잠깐 성능을 끌어올리는 T3 계열이라, AWS 는 이를 저비용 개발·저처리량용으로 두고 운영에는 M5·M7g 를 권합니다(Amazon MSK broker sizes). 고가용성이 필요하면 가용 영역 세 곳에 복제 계수(파티션 하나를 브로커 몇 대에 복사해 두나) 3 이상으로 둡니다. 복제 계수 2 로는 데이터를 잃을 수 있습니다(Best practices for Standard brokers).
Express 브로커는 같은 프로비저닝 클러스터의 다른 브로커 종류입니다. 저장 용량을 정하지 않고 쓴 만큼 내며, 같은 크기 Standard 브로커보다 브로커당 처리량이 크기에 따라 최대 3배, 확장이 최대 20배 빠릅니다. 가용 영역 세 곳 구성만 되고 M7g 크기만 있으며, Kafka Streams API 는 아직 완전히 지원하지 않습니다(Amazon MSK Express brokers). 가장 작은 Express 브로커도 Standard m7g.large 의 두 배 값이라 큰 흐름을 받는 클러스터용입니다.
MSK Serverless 는 브로커를 아예 안 보이게 하고 용량과 파티션 배치를 알아서 맞춥니다. 클러스터당 쓰기 초당 200 MB·읽기 400 MB, 파티션 하나당 쓰기 초당 5 MB 가 상한이고, 인증은 IAM 만 됩니다(What is MSK Serverless? · Amazon MSK quota). 그래서 기존 클라이언트가 다른 인증 방식을 쓰고 있었다면 접속 설정을 IAM 용으로 바꿔야 합니다. 앞의 「코드 수정 없이」는 클라이언트 코드 얘기이고, 접속 설정까지 그대로 둔다는 뜻은 아닙니다.
요금은 브로커 종류마다 따로 매기고, 저장은 GB-월(1 GB 를 한 달 두는 값) 단위입니다.
MSK · 서울 · 2026-09-27
Standard kafka.t3.small 브로커 시간당 $0.0569 (730시간이면 $41.54)
Standard kafka.m7g.large 브로커 시간당 $0.2508
Standard 저장(EBS) GB-월 당 $0.114
Express express.m7g.large 브로커 시간당 $0.5016 + 쓰기 GB 당 $0.0123
+ 저장 GB-월 당 $0.114
Serverless 클러스터 시간당 $0.92 (730시간이면 $671.60)
+ 파티션 시간당 $0.0018
+ 쓰기 GB 당 $0.123, 읽기 GB 당 $0.061
+ 저장 GB-월 당 $0.114
- 브로커끼리의 복제 트래픽에는 요금이 없지만, 생산자·소비자가 다른 가용 영역의 브로커와 주고받는 트래픽에는 표준 데이터 전송 요금이 붙습니다. 액수는 4절에서 셈합니다(Amazon MSK pricing)
KDS 와 견주면 MSK 는 더 많은 것을 내 몫으로 남깁니다. 클러스터가 내 VPC 서브넷 안에 뜨고, Standard 브로커면 브로커 크기·개수·디스크 용량을 정하고 디스크가 차기 전에 늘려야 합니다. 토픽마다 파티션 수와 복제 계수를 정하고, 브로커를 늘리면 파티션을 옮겨 부하를 다시 나누며, Kafka 버전 올리기도 내가 시작합니다. KDS 는 HTTPS API 와 IAM 권한만 있으면 되고 서버·디스크라는 말이 나오지 않습니다. 이 짐을 지고도 MSK 를 고르는 것은 이미 Kafka 로 짠 것이 있을 때이고, 짐을 덜고 싶으면 Serverless 로, 흐름이 크면 Express 로 갑니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 맞다를 고른 대가 |
|---|---|---|
| Kafka 클라이언트·Connect·Streams 로 짠 시스템을 AWS 로 옮긴다(Standard) | 처음 만드는 작은 스트림이다(→ KDS) | 브로커·디스크·파티션 설계와 버전 올리기, 운영 구성이면 브로커 세 대가 늘 켜져 있다 |
| Kafka 는 필요하지만 브로커 크기·디스크는 맡기고 싶다(Serverless) | 흐름이 작고 값이 가장 중요하다(→ KDS) | 클러스터만으로 월 $671.60, 클라이언트 인증을 IAM 으로 바꾼다 |
| 브로커당 처리량이 크게 필요하고 가용 영역 세 곳을 쓴다(Express) | Kafka Streams 앱을 그대로 올린다(→ Standard) | 가장 작은 브로커도 시간당 $0.5016 |
4. 초당 1,000건을 받으면 한 달에 얼마인가
첫 문단의 $530 과 $81 을 이 절에서 계산합니다. 조건은 KDS·MSK 에 똑같이 둡니다. 초당 1,000건, 건당 1 KB(1,024바이트)를 한 달(730시간) 내내 받고, 소비자 둘이 전부 읽으며, 보관은 24시간입니다. 한 달이면 26억 2,800만 건, 약 2,506 GB 이고, 읽기는 그 두 배인 약 5,013 GB, 하루치 보관량은 약 82 GB 입니다. Firehose 는 소비자 둘을 두는 구성이 아니라 2절에서 따로 셈했습니다.
KDS 프로비저닝은 샤드 둘입니다. 쓰기 한도 1 MB 에 파티션 키도 들어가서, 1 KiB 기록 1,000건에 키를 붙이면 샤드 하나를 넘기 때문입니다. MSK 는 데이터를 잃을 수 있는 하한선인 t3.small 두 대(복제 계수 2)와, AWS 가 권하는 가용 영역 세 곳·복제 계수 3 구성을 함께 봅니다. 브로커마다 디스크 100 GB 를 두고, 토픽 보관(retention.ms)을 24시간으로 설정합니다. Kafka 기본 보관 7일로 두면 이틀도 안 돼 디스크가 찹니다.
서울 · 2026-09-27 · 한 달(730시간 = 2,628,000초)
데이터 1,000건 × 1 KiB × 2,628,000초 ≈ 2,506 GB 쓰기, 5,013 GB 읽기
KDS On-demand Standard
스트림 $0.049 × 730 = $35.77
쓰기 2,506 GB × $0.099 = $248.12
읽기 5,013 GB × $0.049 = $245.61
합계 ≈ $529.50
(소비자 둘을 향상된 팬아웃으로: 읽기 5,013 GB × $0.062 = $310.78, 합계 ≈ $594.67)
KDS 프로비저닝 · 샤드 2개
샤드 2 × $0.0185 × 730 = $27.01
PUT 2,628백만 단위 × $0.0204 = $53.61
합계 ≈ $80.62
MSK Standard · t3.small 3대 · 복제 3
브로커 3 × $0.0569 × 730 = $124.61
디스크 3 × 100 GB × $0.114 = $34.20
합계 ≈ $158.81 (+ 가용 영역 간 전송)
MSK Standard · t3.small 2대 · 복제 2 (하한선) ≈ $105.87
MSK Standard · m7g.large 3대 · 복제 3 ≈ $583.45
MSK Serverless · 파티션 2개
클러스터 $0.92 × 730 = $671.60
파티션 2 × $0.0018 × 730 = $2.63
쓰기 2,506 GB × $0.123 = $308.27
읽기 5,013 GB × $0.061 = $305.76
저장 82 GB × $0.114 = $9.39
합계 ≈ $1,297.65
- AWS 는 온디맨드 스트림에서 소비자가 둘 이상이면 향상된 팬아웃을 권합니다. 권장대로 하면 온디맨드는 약 $595 입니다(Choose the right mode to stream in)
- MSK 는 생산자·소비자와 브로커가 서로 다른 가용 영역에 있으면 오가는 GB 마다 서울 GB 당 $0.01 이 양방향으로 붙습니다. 절반이 가용 영역을 넘나든다고 보면 (1,253 + 2,506 GB) × $0.02 ≈ $75 로 하한선 구성의 브로커 요금에 맞먹습니다(Amazon MSK pricing)
- KDS 도 클라이언트가 사설 서브넷에 있으면 NAT 게이트웨이나 인터페이스 엔드포인트를 거치며 GB·시간 요금이 붙습니다. 인터페이스 엔드포인트로 받으면 이 흐름에서 약 $94 입니다
- KCL 이 쓰는 DynamoDB 요금은 KDS 합계에 넣지 않았습니다
흐름이 고르게 예측되면 KDS 프로비저닝 샤드 두 개(월 약 $81)가 가장 쌉니다. 온디맨드가 여섯 배 넘게 나오는 주된 이유는 소비자 수가 아니라 쓰기 GB 단가입니다. 소비자가 하나여도 온디맨드는 $35.77 + $248.12 + 2,506 GB × $0.049 ≈ $407 로 다섯 배입니다. 샤드 둘에 담기는 2,506 GB 를 프로비저닝은 샤드 시간 $27.01 과 PUT $53.61 로 받는데, 온디맨드는 쓰기만으로 $248.12 를 매깁니다. 꽉 찬 샤드의 시간 요금이 같은 양을 GB 로 매긴 값보다 훨씬 싼 셈입니다.
거꾸로 샤드가 대부분 비어 있으면 온디맨드가 이깁니다. 하루 23시간은 거의 조용하다가 한 시간만 초당 10,000건이 몰리는 스트림이면 한 달 쓰기는 위의 10/24 인 약 1,044 GB 이고, 온디맨드는 $35.77 + 1,044 GB × $0.099 + 2,089 GB × $0.049 ≈ $241, 최고치에 맞춘 샤드 20개를 늘 켜 둬야 하는 프로비저닝은 20 × $13.51 + 1,095백만 단위 × $0.0204 ≈ $292 입니다.
MSK 는 하한선 구성(월 약 $106)으로도 프로비저닝 KDS 보다 비싸고, 권장대로 가용 영역 세 곳·복제 3 으로 가면 약 $159, 운영용 m7g.large 면 약 $583 에 전송 요금이 더해집니다. MSK Serverless 는 클러스터 요금만으로 이 규모에서 가장 비쌉니다. MSK 를 고른다면 값이 아니라 Kafka 호환성 때문입니다.
이럴 땐 무엇
| 상황 | 서비스 | 이유 |
|---|---|---|
| 로그·이벤트를 코드 없이 S3 에 파일로 쌓는다 | Data Firehose | 버퍼와 형식 변환까지 맡습니다. 작은 기록은 5 KB 안쪽으로 묶어 보냅니다 |
| 한 이벤트를 소비자 여럿이 각자 읽고, 흐름이 고르다 | KDS 프로비저닝 | 꽉 찬 샤드의 시간 요금이 같은 양의 GB 요금보다 쌉니다 |
| 평소엔 한가하다가 가끔 몰린다 | KDS 온디맨드 | 최고치에 맞춘 샤드를 늘 켜 둘 필요가 없습니다 |
| 장애 뒤 며칠 전부터 다시 읽어야 한다 | KDS(보관 기간 연장) | 최대 365일까지 남겨 둡니다 |
| Kafka 클라이언트·Connect 로 짠 시스템을 옮긴다 | MSK 프로비저닝 | 코드 수정 없이 옮기고 브로커를 직접 고릅니다 |
| Kafka 가 필요하지만 브로커 관리는 싫다 | MSK Serverless | 용량을 알아서 맞춰 줍니다. 인증은 IAM 으로 바꿔야 합니다 |
| 처리하면 끝나는 일감을 하나씩 나눠 준다 | SQS(07-1편) | 스트림이 필요 없습니다 |
자주 붙는 서비스는 Lambda(스트림 소비자), S3(적재 목적지), Managed Service for Apache Flink(실시간 집계), AWS Glue(형식 변환 스키마), CloudWatch(지표·경보), IoT Core(기기 데이터 입구)입니다.
한 장 요약
큐는 읽으면 사라지고 스트림은 남아 소비자마다 제 위치에서 읽습니다. 이 편에서 값을 몇 배로 가르는 것은 Firehose 의 5 KB 올림과 KDS 온디맨드의 GB 단가 둘이고, 둘 다 기록 크기와 흐름의 모양(고른가, 가끔 몰리는가)을 먼저 재면 피할 수 있습니다. MSK 는 값이 아니라 Kafka 호환성으로 고릅니다.
관련 항목
스트림을 이루는 개념
스트림 · 이벤트 스트림 · 샤드 · 파티션 · 파티션 키 · 시퀀스 번호 · 오프셋 · 보관 기간 · MD5 · 해시 함수
스트림과 견주는 전달 방식
큐 · Amazon SQS · Amazon SNS · 발행-구독 · 메시지 브로커 · Amazon EventBridge
스트림을 읽는 소비자
AWS Lambda · Kinesis Client Library · 향상된 팬아웃 · 컨슈머 그룹 · Amazon DynamoDB · Managed Service for Apache Flink
Kafka 생태계
Apache Kafka · Amazon MSK · Kafka Connect · Kafka Streams · MSK Connect · KRaft · Apache ZooKeeper · 브로커 · 복제 계수
Firehose 가 넘겨주는 목적지와 형식
Amazon S3 · Amazon Redshift · Amazon OpenSearch Service · Apache Iceberg · Apache Parquet · Apache ORC · AWS Glue · 버퍼 · JSON
요금을 이루는 단위
샤드 시간 · PUT 페이로드 단위 · 데이터 전송 요금 · 가용 영역 · 프리 티어