Amazon Kinesisとは｜Firehoseとの違い・シャード・料金試算

この記事で実際に動かしたもの：パーティションキー → MD5 → シャードの割り当てを再現する Python、手元の 127.0.0.1 で動かした Kinesis のエミュレーター（moto）への PutRecord・ListShards・SplitShard、公式の単価を写した料金の計算。AWS には接続していません。

flowchart TB
    P[プロデューサー<br>アプリ・端末] -->|パーティションキー| DS
    subgraph DS[Kinesis Data Streams]
        direction LR
        S1[シャード1] ~~~ S2[シャード2]
    end
    DS --> C1[Lambda<br>KCLのアプリ]
    DS --> F[Data Firehose]
    F --> S3[(S3など)]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS・Python 3.13.18。サービスの説明・上限・料金は AWS の公式（aws.amazon.com の Kinesis Data Streams と Amazon Data Firehose の料金ページ・What's New の発表、docs.aws.amazon.com の Kinesis Data Streams 開発者ガイド・API リファレンス・Firehose 開発者ガイド・Lambda と EventBridge のユーザーガイド、Amazon SQS の FAQ）だけで確かめました。料金ページで読み取れた単価は米国東部のもので、東京リージョンの単価表は取得した文面に含まれていなかったため、試算は米国東部の単価で行っています。パーティションキーからシャードを決める計算は Python 標準の hashlib で再現し、AWS のエミュレーター moto 5.2.5（boto3 1.44.2）を 127.0.0.1 で動かして、PutRecord が返すシャードと一致するかを確かめました。本物の AWS には接続しておらず、アカウント・認証情報も使っていません（ダミーの鍵だけを渡しています）。エミュレーターの振る舞いは AWS と同じとは限らないため、本物の上限やエラーの文面は公式の記載で書いています。図は mermaid-cli で描画を確かめました（確認日 2026年11月13日）。

Amazon Kinesisとは（読み方・できること・名前の変更）

この節では、Amazon Kinesis が何を指す名前なのか、いまどのサービスがその仲間なのかが分かります。

Amazon Kinesis は、1つの製品ではなく、ストリーミングデータを扱う AWS のサービスの集まりの呼び名です。読み方は「キネシス」が一般的です。AWS の製品ページは Kinesis を「リアルタイムのビデオストリームとデータストリームの収集、処理、分析」と説明しています。

ストリーミングデータとは、終わりがなく流れ続けるデータのことです。Web サイトのクリック、アプリのログ、IoT 機器のセンサーの値、決済のイベントなどが当てはまります。1日分をまとめてから処理する（バッチ処理）のではなく、届いたそばから数秒以内に処理したいときに使います。Kinesis Data Streams の開発者ガイドは、レコードがストリームに入ってから取り出せるまでの遅延を「通常 1 秒未満」と書いています。

開発者ガイドでは、Kinesis Data Streams は「Firehose、Kinesis Video Streams、Managed Service for Apache Flink とともに、Kinesis ストリーミングデータプラットフォームの一部」とされています。このうち2つは名前が変わっています。

どちらの改名も、AWS の発表ではエンドポイント・API・CLI・IAM ポリシー・CloudWatch のメトリクスは変わらないとされています。そのため、API 名や SDK のクライアント名には以前の名前（firehose・kinesisanalytics など）が残っています。検索すると「Kinesis Data Firehose」と書かれた記事と「Amazon Data Firehose」と書かれた記事が混ざるのはこのためで、同じサービスです。

次の節では、仲間のサービスがそれぞれ何を受け持つのかを並べて比べます。

Kinesisの種類と違い：Data Streams・Data Firehose・Video Streams

この節では、Data Streams・Data Firehose・Video Streams の違いと、どれを選ぶかの目安が分かります。

いちばん迷うのは Data Streams と Data Firehose の違いです。Data Streams は「ためておく場所」、Firehose は「届ける配送係」と考えると整理できます。

2つは組み合わせて使うこともよくあります。Firehose は Data Streams をソース（入力）にできるので、「Data Streams に入れて、リアルタイムの処理は Lambda、保存は Firehose で S3 へ」という形がとれます。Firehose の開発者ガイドが挙げる送り先は、Amazon S3・Amazon Redshift・Amazon OpenSearch Service・OpenSearch Serverless・Splunk・Apache Iceberg Tables・任意の HTTP エンドポイントと、Datadog・New Relic などの対応したサービスの HTTP エンドポイントです。

次の節では、Data Streams の中身（ストリーム・シャード・レコード）を用語ごとに見ていきます。

Kinesis Data Streamsの仕組み：ストリーム・シャード・レコード

この節では、Kinesis Data Streams を設計するときに出てくる用語と、その関係が分かります。

データストリームはシャードの集まりで、各シャードにはレコードが届いた順に並びます。開発者ガイドの「用語と概念」をもとに、要点を表にしました。

ここで押さえておきたいのは次の3点です。

次の節では、シャード1本あたりの上限と、何本あれば足りるかの計算式を見ます。

シャードの上限（書き込み1MB/秒・読み取り2MB/秒）とシャード数の決め方

この節では、シャード1本で扱える量と、プロビジョンドモードでシャード数を決める公式の式、その計算例が分かります。

クォータのページに載っている主な上限をまとめます（2026年11月13日時点。調整できるものは Service Quotas から引き上げを申請できます）。

シャードの書き込みには「バイト数」と「レコード数」の2つの上限があるので、小さなレコードを大量に送る場合は 1,000レコード/秒 の方に先に当たります。開発者ガイドは、プロビジョンドモードのシャード数を次の式で求めるよう書いています。

number_of_shards = ceiling(max(incoming_write_bandwidth_in_KiB/1024,
                               outgoing_read_bandwidth_in_KiB/2048))
incoming_write_bandwidth  = 平均のレコードの大きさ(KB) × 1秒あたりのレコード数
outgoing_read_bandwidth   = incoming_write_bandwidth × コンシューマーの数

この式に、レコード数の上限（1,000レコード/秒）での切り上げも加えて Python で計算しました（コードは料金の節にまとめて載せます）。

レコード/秒  大きさ(KB)  コンシューマー   必要シャード  (バイトで, レコード数で)
 500         1           1              1            (1, 1)
1500         0.5         1              2            (1, 2)
 800         2           1              2            (2, 1)
 800         2           3              3            (3, 1)
2000         1           5              5            (5, 2)
 100         35          1              4            (4, 1)

1,500レコード/秒×0.5KB は、バイト数では1本で足りても、レコード数で2本になります。800レコード/秒×2KB は、コンシューマーが3つに増えると読み取り側（2MB/秒）で3本になります。最後の行は料金ページのプロビジョンドの例（35KB のレコードを100件/秒、約3.4MB/秒で4シャード）と同じ答えです。

この式は平均ではなくピークの値で計算します。開発者ガイドも、ピークを処理できるシャード数を設定しないと読み書きで例外が起きると書いています。

次の節では、レコードがどのシャードに入るのかを、MD5 の計算で再現します。

パーティションキーからシャードが決まる仕組み（MD5と128ビットのハッシュキー範囲）

この節では、パーティションキーがどうやってシャードに結びつくのかと、それを Python で再現した結果が分かります。

API リファレンスの PutRecord には、次のように書かれています。

an MD5 hash function is used to map partition keys to 128-bit integer values and to map associated data records to shards.（MD5 ハッシュ関数で、パーティションキーを128ビットの整数に写し、レコードをシャードに割り当てる）

各シャードには「ハッシュキー範囲」（StartingHashKey〜EndingHashKey の連続した整数）があり、パーティションキーの MD5 を整数にした値が入る範囲のシャードに、レコードが入ります。MD5 は16バイト（128ビット）なので、値は 0 〜 2の128乗−1 の範囲になります。

1. 1パーティションキーを決める例：user-1（Unicode 文字列・最大256文字）
2. 2MD5 を求めるd6d7705392bc7af633328bea8c4c6904（16バイト）
3. 3128ビットの整数として読む先頭のバイトを上位として読む（ビッグエンディアン）
4. 4その整数を含むハッシュキー範囲のシャードに入る範囲は ListShards の HashKeyRange で分かる

これを Python 標準の hashlib だけで書くと次のようになります。シャードの範囲は、ハッシュの空間を均等に分けた場合です。

import hashlib

MAX = 2**128 - 1

def hash_key(pk: str) -> int:
    # パーティションキーの MD5 を128ビットの整数にする
    return int.from_bytes(hashlib.md5(pk.encode("utf-8")).digest(), "big")

def even_ranges(n):
    # 0〜2^128-1 を n 本のシャードで均等に分けた範囲
    size = 2**128 // n
    return [(i * size, MAX if i == n - 1 else (i + 1) * size - 1) for i in range(n)]

def shard_of(pk, ranges):
    h = hash_key(pk)
    for i, (s, e) in enumerate(ranges):
        if s <= h <= e:
            return i

R = even_ranges(4)
for pk in ["user-1", "user-2", "user-3", "order-1001", "東京"]:
    print(pk, hashlib.md5(pk.encode()).hexdigest(), hash_key(pk), "-> shard", shard_of(pk, R))

実行結果です（数字の桁が多いので一部の列を分けて載せます）。

2^128-1 = 340282366920938463463374607431768211455
user-1       md5=d6d7705392bc7af633328bea8c4c6904 int=285573413173782752570879317399258818820
user-2       md5=3d58ce20fe802793e0b221905baa60b3 int=81544010656874607678696621737415172275
user-3       md5=134ad24e99806ca111197065657dbf5e int=25643827420764883787405505484921093982
order-1001   md5=929211f12c9f601477a81243838a056c int=194825726634704243656021158002940314988
東京         md5=707ba17c7ef8d9ef08b39ef314adf432 int=149515463373044655254931301471039124530
--- 4 shards even ranges
shard 0: 0 - 85070591730234615865843651857942052863
shard 1: 85070591730234615865843651857942052864 - 170141183460469231731687303715884105727
shard 2: 170141183460469231731687303715884105728 - 255211775190703847597530955573826158591
shard 3: 255211775190703847597530955573826158592 - 340282366920938463463374607431768211455
user-1 -> shard 3
user-2 -> shard 0
user-3 -> shard 0
order-1001 -> shard 2
東京 -> shard 1

シャードが4本なら、1本の範囲は 2の128乗÷4 ずつです。MD5 の先頭の16進1文字だけを見ても目安がつきます。user-1 は先頭が d（13）で 0〜f の後ろ4分の1に入るのでシャード3、user-2 と user-3 は先頭が 3 と 1 なのでシャード0です。user-2 と user-3 のように、別のキーが同じシャードに入ることは普通に起きます。同じキーは必ず同じシャードに入りますが、逆は成り立ちません。

日本語のキー（東京）も UTF-8 のバイト列として MD5 を取れば同じように扱えます。MD5 とハッシュ値の求め方そのものは、関連記事「Python hashlibの使い方｜SHA256・MD5とファイルのハッシュ値」で扱っています。ここでの MD5 は割り当てのためのもので、安全のための用途ではありません。

ExplicitHashKey でシャードを直接指定する

PutRecord には ExplicitHashKey という引数もあり、パーティションキーのハッシュの代わりに、10進の整数の文字列で割り当て先を決められます（パターンは ^(0|([1-9]\d{0,38}))$）。たとえば "0" を渡せば、範囲が0から始まるシャードに入ります。特定のシャードに寄せたい・均等に配りたいときの手段ですが、キーとシャードの対応を自分で管理することになります。

次の節では、この計算が実際の API の振る舞いと合うかを、手元のエミュレーターで確かめます。

エミュレーターで確かめたシャードの割り当て・順序・シャードの分割

この節では、Kinesis のエミュレーター（moto）を手元で動かし、Python の計算と PutRecord の返すシャードが一致するか、分割でハッシュキー範囲がどう変わるかが分かります。

moto は AWS の API を真似るオープンソースのライブラリで、テストのために手元でサーバーとして動かせます。本物の Kinesis ではないので、上限やエラーの文面は本物と違うことがあります。ここではハッシュキー範囲と割り当ての計算だけを確かめます。AWS の鍵が使われないよう、環境変数を空にして（env -i）ダミーの鍵だけを渡しました。

python3 -m venv venv
./venv/bin/pip install 'moto[server]' boto3
env -i PATH=/usr/bin:/bin ./venv/bin/moto_server -H 127.0.0.1 -p 5455 &

import boto3
k = boto3.client("kinesis", endpoint_url="http://127.0.0.1:5455",
                 region_name="ap-northeast-1",
                 aws_access_key_id="testing", aws_secret_access_key="testing")
k.create_stream(StreamName="t455-demo", ShardCount=4)
shards = k.list_shards(StreamName="t455-demo")["Shards"]
for pk in ["user-1", "user-2", "user-3", "order-1001", "東京"]:
    r = k.put_record(StreamName="t455-demo", Data=b'{"v":1}', PartitionKey=pk)
    print(pk, r["ShardId"], r["SequenceNumber"])

ListShards の範囲と、PutRecord が返した ShardId です。右の python= は前の節の関数で求めたシャードです。

== list_shards
shardId-000000000000 0 85070591730234615865843651857942052863
shardId-000000000001 85070591730234615865843651857942052864 170141183460469231731687303715884105727
shardId-000000000002 170141183460469231731687303715884105728 255211775190703847597530955573826158591
shardId-000000000003 255211775190703847597530955573826158592 340282366920938463463374607431768211455
same as even_ranges(4): True
== put_record
user-1     -> shardId-000000000003  python=shardId-000000000003  seq=1
user-2     -> shardId-000000000000  python=shardId-000000000000  seq=1
user-3     -> shardId-000000000000  python=shardId-000000000000  seq=2
order-1001 -> shardId-000000000002  python=shardId-000000000002  seq=1
東京       -> shardId-000000000001  python=shardId-000000000001  seq=1
2000 keys mismatch: 0
ExplicitHashKey=0 -> shardId-000000000000

device-0〜device-1999 の2,000個のキーでも、PutRecord の結果と Python の計算はすべて一致しました（不一致0件）。ExplicitHashKey に "0" を渡すと、パーティションキー user-1 のままでもシャード0に入りました。なお、moto のシーケンス番号は 1・2… の短い数ですが、本物はもっと長い数字の文字列です（API リファレンスのパターンは最大129桁）。

同じキーの順序

order-1001 で3件続けて書き込み、そのシャードを TRIM_HORIZON（保持されている先頭の位置）から読むと、届いた順に並んでいました。

records in shardId-000000000002 506
1 b'{"v":1}'
504 b'{"n": 0}'
505 b'{"n": 1}'
506 b'{"n": 2}'

同じシャードには device-xxx のレコードも500件ほど混ざっています。シャードは「1つのキー専用の列」ではなく、範囲に入ったキーのレコードが混ざって並ぶ列です。読む側はパーティションキーで振り分けます。

シャードを分割すると範囲が半分になる

プロビジョンドモードでは SplitShard でシャードを2つに分けられます。シャード0の範囲の真ん中（2の128乗÷8）で分けた結果です。

== after split
shardId-000000000000 0 85070591730234615865843651857942052863 parent=- closed
shardId-000000000001 85070591730234615865843651857942052864 170141183460469231731687303715884105727 parent=- open
shardId-000000000002 170141183460469231731687303715884105728 255211775190703847597530955573826158591 parent=- open
shardId-000000000003 255211775190703847597530955573826158592 340282366920938463463374607431768211455 parent=- open
shardId-000000000004 0 42535295865117307932921825928971026431 parent=shardId-000000000000 open
shardId-000000000005 42535295865117307932921825928971026432 85070591730234615865843651857942052863 parent=shardId-000000000000 open

親のシャード0は閉じられ（closed＝それ以上書き込まれない）、範囲を半分ずつ受け持つ子のシャード4と5ができました。キーの MD5 は変わらないので、分割のあとは同じキーが子のどちらかに入ります。親に残ったレコードは保持期間のあいだ読めるので、順序を守るには親を読み終えてから子を読みます（KCL などのライブラリはこの順番を扱います）。オンデマンドモードでは、開発者ガイドによると1シャードあたり500KB/秒を超える流量を検知すると15分以内に分割され、親のハッシュキーは子に均等に配られます。

エラーの出方

0 ParamValidationError Parameter validation failed:
Invalid length for parameter PartitionKey, value: 0, valid min length: 1
ResourceNotFoundException An error occurred (ResourceNotFoundException) when calling the PutRecord operation: Stream no-such-stream under account 123456789012 not found.

空のパーティションキーは、送る前に boto3 が止めました（API の最小長が1のため）。存在しないストリーム名では ResourceNotFoundException になります（文面は moto のもの）。本物の上限超えの例外 ProvisionedThroughputExceededException は moto では起きないので、文面は後のつまずきの節で公式の記載から載せます。

次の節では、この仕組みを踏まえて、パーティションキーをどう選ぶかを考えます。

パーティションキーの選び方：偏り（ホットシャード）を避ける

この節では、パーティションキーの選び方で処理量がどう偏るかを、計算した数字で確かめられます。

MD5 の値はほぼ均一に散らばるので、キーの種類が多く、量がキーごとに大きく違わなければ、シャードはほぼ均等に使われます。device-0〜device-9999 の1万個のキーを4シャードに割り当てた結果です。

== distribution of 10000 device ids over 4 shards
[(0, 2493), (1, 2478), (2, 2465), (3, 2564)]

一方、キーの種類が少ないと、シャードを増やしても使われないシャードが出ます。3種類のキーを8シャードに割り当てた結果です。

['tokyo', 'osaka', 'nagoya'] [7, 6, 2]
['ap-northeast-1', 'us-east-1', 'eu-west-1'] [6, 6, 6]
== 100 keys over 8 shards (max/min)
[(0, 16), (1, 12), (2, 4), (3, 9), (4, 9), (5, 16), (6, 14), (7, 20)]

リージョン名の3つは、偶然すべてシャード6に入りました。8シャード用意しても1本しか使われず、書き込みの上限は1シャード分（1MB/秒）のままです。キーが100種類でも、多いシャードは20個、少ないシャードは4個と5倍の差が出ます。

1つのキーに量が集まると上限を超える

合計2,000レコード/秒を4シャード（上限は合計4,000レコード/秒）で受けるとき、1つの利用者（tenant-A）が全体の40%を占める場合を計算しました。

== hot key: 2000 rec/s total on 4 shards, one key = 40%
tenant-A shard 2 [(0, 310), (1, 272), (2, 1137), (3, 281)]

合計では半分しか使っていないのに、シャード2だけが1,137レコード/秒となり、1シャードの上限1,000レコード/秒を超えます。これがホットシャードです。シャードを増やしても、1つのキーは1つのシャードにしか入らないので解決しません。

tenant-A に #0〜#7 を付けて計算すると、8個のキーが4本のシャードすべてに散りました。

[('tenant-A#0', 1), ('tenant-A#1', 1), ('tenant-A#2', 0), ('tenant-A#3', 3),
 ('tenant-A#4', 0), ('tenant-A#5', 2), ('tenant-A#6', 1), ('tenant-A#7', 2)]

ただし、番号を付けると tenant-A 全体の順序は保てなくなります（#0 と #3 は別のシャード）。順序を守りたい単位（注文1件・端末1台など）をパーティションキーにし、それより大きな単位をキーにしないのが基本です。

オンデマンドモードには、パーティションキーを無視して均等に配る設定もあります。API リファレンスの UpdateStreamRecordDistributionStrategy によると、オンデマンドのストリームで記録の配り方を AUTO にすると、パーティションキーと ExplicitHashKey は無視され、サービスが均等に配ります（順序の要らない処理向け）。既定は USER_PARTITION_KEY で、プロビジョンドのストリームでは AUTO を設定できません。

次の節では、オンデマンドとプロビジョンドの2つの容量モードを比べます。

オンデマンドとプロビジョンドの違い（容量モード）

この節では、容量モードの違いと、オンデマンドの中の「標準」と「アドバンテージ」の違いが分かります。

開発者ガイドの例では、書き込みが10〜40MB/秒で推移していたストリームは、オンデマンド標準なら80MB/秒まですぐに受けられます。読み取りの容量は書き込みに比例し、少なくとも書き込みの2倍です。

オンデマンド アドバンテージはアカウント単位の設定で、有効にするとそのリージョンのすべてのオンデマンドのストリームに効きます。取り込み・取得の単価は標準より少なくとも60%安く、拡張ファンアウトも追加料金なしで50コンシューマーまで使えますが、取り込み・取得それぞれ25MiB/秒の最低利用量を約束する形です。有効にしてから24時間は無効にできません。

切り替えは1つのストリームで24時間に2回までで、切り替え中も読み書きは続けられます。次の節では、実際の単価で月額を計算します。

Kinesisの料金を試算する（Data Streams・Data Firehose）

この節では、公式の単価で月額を計算する方法と、公式の料金例を再現した結果、量ごとの比較が分かります。

料金ページから読み取れた単価は米国東部（US-East）のものです（2026年11月13日時点）。東京リージョンの単価は、料金ページの「リージョン別料金」で選び直すと確かめられます。

オンデマンドの取り込みはレコードごとに1KB（1,024バイト）単位で切り上げて数えます（4.5KB なら5KB）。取得には切り上げはありません。プロビジョンドの PUT ペイロードユニットは25KB ごとに1つで、料金ページでは 5KB のレコードが1ユニット、45KB が2ユニット、1MB が40ユニットと説明されています。延長保持（7日まで）はプロビジョンドで0.020ドル/シャード時間です。

公式の料金例を再現する

単価と切り上げの決まりを Python に写し、料金ページの例を計算しました。

import math
STD = dict(stream_h=0.040, in_gb=0.08, out_gb=0.040)   # US-East
ADV = dict(in_gb=0.032, out_gb=0.016, min_mib_s=25)
PROV = dict(shard_h=0.015, put_unit_per_m=0.014)

def std_cost(rps, kb, consumers, days=30):
    sec = days * 86400
    gb_in = rps * math.ceil(kb) / 1048576 * sec          # 取り込みは1KB単位で切り上げ
    gb_out = rps * kb / 1048576 * consumers * sec
    return gb_in * STD["in_gb"] + gb_out * STD["out_gb"] + days * 24 * STD["stream_h"]

def adv_cost(rps, kb, consumers, apply_min=True, days=30):
    sec = days * 86400
    gb_in = rps * math.ceil(kb) / 1048576 * sec
    gb_out = rps * kb / 1048576 * consumers * sec
    if apply_min:                                          # 25MiB/秒の最低利用
        gmin = ADV["min_mib_s"] / 1024 * sec
        gb_in, gb_out = max(gb_in, gmin), max(gb_out, gmin)
    return gb_in * ADV["in_gb"] + gb_out * ADV["out_gb"]

def shards_needed(rps, kb, consumers):
    w = rps * kb
    return max(math.ceil(max(w / 1024, w * consumers / 2048)), math.ceil(rps / 1000), 1)

def prov_cost(rps, kb, consumers, days=30):
    n = shards_needed(rps, kb, consumers)
    units = rps * math.ceil(kb / 25) * days * 86400
    return n, n * days * 24 * PROV["shard_h"] + units / 1e6 * PROV["put_unit_per_m"]

== official examples reproduced
std 1000rps 3KB 1c rounded : (593.05, 296.52, 28.8, 918.37)
std 1000rps 3KB 1c exact   : (593.26, 296.63, 28.8, 918.69)
adv 3000rps 10KB 1c        : (2373.05, 1186.52, 3559.57)
adv 1000rps 10KB 1c min    : (2025.0, 1012.5, 3037.5)
prov 4sh 31d 100rps 35KB   : 44.64 7.5 52.14 ext 59.52

オンデマンド標準の例は、料金ページが1秒あたりの量を 0.00286GB/秒 と丸めてから掛けているため、丸めずに計算すると0.35ドル高くなります。ほかの3つは1セント単位まで一致しました。

量ごとに3つのモードを比べる

平均の流量が一定と仮定して、30日の月額を計算しました。アドバンテージは最低利用量を入れずに計算した「単価だけ」の値で、実際にはアカウント全体で最低3,037.50ドル/月（米国東部）がかかります。プロビジョンドのシャード数は平均の流量から出しているので、ピークが平均の3倍なら3倍のシャードが要ります。

== scenarios (30 days, US-East)
小さなIoT: 100rps x 1KB x 1c  write=0.10MiB/s  std=58.46  adv(no-min)=11.87  prov=1sh 14.43
Webクリック: 1000rps x 1KB x 2c  write=0.98MiB/s  std=424.31  adv(no-min)=158.2  prov=1sh 47.09
ログ集約: 1000rps x 3KB x 1c  write=2.93MiB/s  std=918.69  adv(no-min)=355.96  prov=3sh 68.69
アプリログ大: 3000rps x 2KB x 3c  write=5.86MiB/s  std=2995.11  adv(no-min)=1186.52  prov=9sh 206.06
大きめのレコード: 50rps x 40KB x 1c  write=1.95MiB/s  std=622.06  adv(no-min)=237.3  prov=2sh 25.23

流量が一定でピークが読めるなら、プロビジョンドの方が大幅に安くなります。オンデマンド標準の差額は、シャードの計算と増減の手間を AWS に任せる分の料金と考えられます。流量の山と谷が大きい、まだ量が読めない、という場面ではオンデマンドが向きます。

ストリーム1本・1コンシューマー・2KB のレコードで、オンデマンド標準とアドバンテージ（最低利用込み）を比べると、損益の分かれ目は毎秒約9.9MiBでした。

  1 MiB/s rps=512 std=   332.55 adv=   3037.5 prov=1sh 29.38
  5 MiB/s rps=2560 std=  1547.55 adv=   3037.5 prov=5sh 146.9
 10 MiB/s rps=5120 std=   3066.3 adv=   3037.5 prov=10sh 293.79
 25 MiB/s rps=12800 std=  7622.55 adv=   3037.5 prov=25sh 734.49
 50 MiB/s rps=25600 std=  15216.3 adv=   6075.0 prov=50sh 1468.97
break-even MiB/s ~ 9.91

Amazon Data Firehose の料金と5KB の切り上げ

Firehose の料金ページの例では、Direct PUT（または Data Streams がソース）の取り込みは最初の500TB/月まで0.029ドル/GB で、レコードごとに5KB 単位で切り上げて数えます。形式変換（JSON から Parquet・ORC）は0.018ドル/GB、動的パーティショニングは0.020ドル/GB などが加わります。

official 100rps 5KB      (1235.96 GB, 35.84 USD)
1000rps 0.5KB            (12359.62 GB, 358.43 USD)  actual GB 1235.96
100rps 5KB(10 joined)    (1235.96 GB, 35.84 USD)

100件/秒×5KB は料金ページの例どおり35.84ドルです。0.5KB の小さなレコードを1,000件/秒送ると、実際の量は同じ1,236GB でも5KB として数えられ、358.43ドルと10倍になります。送る側で10件をまとめて1レコード（5KB）にすれば35.84ドルに戻ります。小さなレコードが多いときは、まとめて送れるかを先に考えると料金が大きく変わります。

次の節では、データを読む側（コンシューマー）の種類を見ます。

コンシューマーの種類：共有スループット・拡張ファンアウト・Lambda

この節では、Data Streams からデータを読む方法の違いと、Lambda で読むときの決まりが分かります。

読むアプリが2つ、3つと増えると、共有スループットでは1人あたりの読み取りが減り、遅れも大きくなります。コンシューマーが3つ以上になる、または遅れを小さくしたいなら拡張ファンアウトを検討します。

Lambda のユーザーガイドによると、Lambda はシャードごとに1秒に1回を基本に読みに行き、1回の呼び出しには1つのシャードのレコードだけが入ります。並列化係数（ParallelizationFactor）は1〜10で、上げてもパーティションキー単位の順序は守られます。関数がエラーを返すと、そのシャードの処理はそこで止まります。配信は「少なくとも1回」なので、同じレコードが2回届いても結果が変わらない（冪等な）処理にしておきます。

• 1処理を冪等にするLambda も KCL も「少なくとも1回」。レコードの ID で重複を判定する
• 2エラーで止まり続けないようにする1件の不正なレコードでシャード全体が止まる。失敗の送り先や再試行の上限を設定する
• 3読む遅れをメトリクスで見るCloudWatch で読む側の遅れを表すメトリクスが増え続けたら、処理が追いついていない
• 4保持期間より長く遅れない既定の24時間を超えて遅れると、読む前にレコードが消える

次の節では、Kinesis とよく比べられる SQS・EventBridge・Kafka との違いを整理します。

Kinesis と SQS・EventBridge・Kafka（MSK）の違い

この節では、似た役割を持つ AWS のサービスとの違いと、使い分けの目安が分かります。

Amazon SQS の FAQ は、SQS を「信頼性が高く非常にスケーラブルなホスト型キュー」、Kinesis Streams を「ストリーミングの巨大なデータをリアルタイムに処理可能」と説明し、Kinesis では複数のアプリにレコードを読み込ませて再生できる、と違いを挙げています。

EventBridge とは組み合わせて使えます。EventBridge のユーザーガイドでは、イベントバスのターゲットに「Kinesis stream」と「Firehose delivery stream」が、EventBridge Pipes のソースに「Amazon Kinesis stream」が挙がっています。イベントを Kinesis に流し込む／Kinesis のレコードを Pipes で別のサービスへつなぐという使い方ができます。

SQS の送受信・削除・可視性タイムアウトは関連記事「Amazon SQSの使い方｜送受信・削除と可視性タイムアウト、FIFO」で、1つのメッセージを複数の SQS に配る形は関連記事「Amazon SNSの使い方 CLI・boto3とSQSファンアウト早見表」で扱っています。決まった時刻に処理を起動したいだけなら、関連記事「EventBridge Schedulerの使い方｜cron・rate・1回実行」の方法が向きます。

すでに Apache Kafka で作ったアプリや運用の手順があるなら、AWS には Amazon MSK（Kafka のマネージドサービス）もあります。Kafka のトピックとパーティションは、Kinesis のストリームとシャードに近い考え方です。Kafka の基本の操作は関連記事「Kafka入門｜KRaftでトピック作成から消費まで最短手順」で扱っています。

次の節では、Kinesis でよく出るエラーとつまずきをまとめます。

Kinesisでよくあるエラー・つまずき

この節では、よく出る例外の原文と、原因・直し方が分かります。

上限を超えたときの例外 ProvisionedThroughputExceededException は、API リファレンスに次の文面で載っています（HTTP 400）。

ProvisionedThroughputExceededException
The request rate for the stream is too high, or the requested data is too large for the
available throughput. Reduce the frequency or size of your requests.

PutRecords で一部のレコードだけ絞られたときは、例外ではなく応答の中の1件に、次のような ErrorMessage が入ります（API リファレンスの応答例）。どのシャードで絞られたかが分かるので、ホットシャードを探す手がかりになります。

{
    "ErrorCode": "ProvisionedThroughputExceededException",
    "ErrorMessage": "Rate exceeded for shard shardId-000000000001 in stream exampleStreamName under account 111111111111."
}

また、API リファレンスによると PutRecords は1件の失敗で止まらないため、レコードの順序を保証しません。書いた順に読みたい場合は、PutRecord で同じシャードに書きます。

再試行の間隔は、毎回同じ間隔ではなく指数バックオフ（待ち時間を倍々にし、ばらつきを加える）にします。決め方と実装は関連記事「指数バックオフとは？リトライ間隔の決め方とジッターの実装」で扱っています。

次の節では、ここまでの内容を判断表にまとめます。

判断表：Kinesisのどれを、どのモードで使うか

この節では、やりたいことから選ぶサービスと容量モードを一覧で確かめられます。

次の節では、よく出る質問に短く答えます。

よくある質問

この節では、Kinesis についてよく聞かれることへの短い答えが分かります。

Q. Amazon Kinesis の読み方は？
「キネシス」と読まれるのが一般的です。

Q. Kinesis Data Firehose と Amazon Data Firehose は別のサービスですか？
同じサービスです。2024年2月9日の AWS の発表で Amazon Data Firehose に改名され、API や CLI、IAM ポリシーは変わっていません。

Q. Kinesis Data Analytics はなくなりましたか？
2023年8月30日に Amazon Managed Service for Apache Flink に改名されました。エンドポイントや API は変わらないと発表されています。

Q. シャード1本で何件まで書き込めますか？
1秒あたり1,000レコードまたは1MB までです。どちらか先に当たった方で絞られます。

Q. パーティションキーには何を使えばよいですか？
順序を守りたい単位（端末 ID・注文番号など）で、種類が多く、キーごとの量が大きく偏らないものです。固定の文字列や少数の地域名は偏りの原因になります。

Q. どのシャードに入るかを自分で計算できますか？
できます。パーティションキーの MD5 を128ビットの整数にし、ListShards で得たハッシュキー範囲に照らします。この記事の Python の関数は、エミュレーターの2,000キーで結果が一致しました。

Q. データはどれくらい保存されますか？
既定は24時間で、最大365日まで延ばせます。24時間を超える分は追加料金です。

Q. 読んだデータは消えますか？
消えません。保持期間が切れるまで残り、別のコンシューマーも読めます。処理したら消したいなら SQS が向きます。

Q. オンデマンドとプロビジョンド、どちらが安いですか？
流量が一定でピークが読めるならプロビジョンドが安くなる場面が多く、手元の試算では1,000件/秒×3KB でオンデマンド標準918.69ドルに対しプロビジョンド68.69ドル（米国東部・30日）でした。量が読めないうちはオンデマンドが扱いやすいです。

Q. 東京リージョンの料金はいくらですか？
この記事の単価は料金ページで読み取れた米国東部のものです。東京リージョンは料金ページの「リージョン別料金」か AWS Pricing Calculator で確かめられます。

Q. Kinesis は無料で試せますか？
この記事で確かめた料金ページの範囲では、Kinesis Data Streams の無料の枠の記載は確認できませんでした。オンデマンド標準はストリームがあるだけで1時間0.040ドル（米国東部）がかかるので、試したあとはストリームを消します。

まとめ

この節では、記事の要点を5つにまとめます。

• Amazon Kinesis はストリーミングデータを扱うサービス群の名前で、Data Streams（ためて複数のアプリが読む）・Data Firehose（届ける、旧 Kinesis Data Firehose）・Video Streams（動画）が中心です。
• シャードは容量の1単位で、書き込み1MB/秒・1,000件/秒、読み取り2MB/秒。シャード数はピークの値から公式の式で求めます。
• パーティションキーの MD5（128ビットの整数）が入るハッシュキー範囲のシャードにレコードが入ります。Python で再現した計算は、エミュレーターの結果と2,000キーすべてで一致しました。
• キーの偏りはシャードを増やしても直りません。順序を守る単位でキーを選び、量の多いキーは細かくするか散らします。
• 料金は公式の単価で試算できます。流量が一定ならプロビジョンドが安く、Firehose は5KB の切り上げに注意します。

参考・出典

この節では、記事で確かめた公式の資料の一覧が分かります（確認日 2026年11月13日）。

• Amazon Kinesis Data Streams とは：https://docs.aws.amazon.com/ja_jp/streams/latest/dev/introduction.html
• Kinesis Data Streams の用語と概念：https://docs.aws.amazon.com/ja_jp/streams/latest/dev/key-concepts.html
• クォータと制限：https://docs.aws.amazon.com/ja_jp/streams/latest/dev/service-sizes-and-limits.html
• 容量モードの選択：https://docs.aws.amazon.com/ja_jp/streams/latest/dev/how-do-i-size-a-stream.html
• 拡張ファンアウト：https://docs.aws.amazon.com/ja_jp/streams/latest/dev/enhanced-consumers.html
• API リファレンス PutRecord：https://docs.aws.amazon.com/kinesis/latest/APIReference/API_PutRecord.html
• API リファレンス HashKeyRange：https://docs.aws.amazon.com/kinesis/latest/APIReference/API_HashKeyRange.html
• API リファレンス UpdateStreamRecordDistributionStrategy：https://docs.aws.amazon.com/kinesis/latest/APIReference/API_UpdateStreamRecordDistributionStrategy.html
• Amazon Kinesis Data Streams の料金：https://aws.amazon.com/jp/kinesis/data-streams/pricing/
• Amazon Data Firehose とは：https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html
• Amazon Data Firehose の料金：https://aws.amazon.com/jp/firehose/pricing/
• Introducing Amazon Data Firehose, formerly known as Amazon Kinesis Data Firehose：https://aws.amazon.com/about-aws/whats-new/2024/02/amazon-data-firehose-formerly-kinesis-data-firehose
• Introducing Amazon Managed Service for Apache Flink：https://aws.amazon.com/about-aws/whats-new/2023/08/amazon-managed-service-apache-flink
• Amazon Kinesis Video Streams とは：https://docs.aws.amazon.com/ja_jp/kinesisvideostreams/latest/dg/what-is-kinesis-video.html
• Using Lambda with Kinesis：https://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html
• EventBridge のターゲット：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html
• EventBridge Pipes のソース：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes-event-source.html
• Amazon SQS のよくある質問：https://aws.amazon.com/jp/sqs/faqs/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。