2026.07.22 インフラ

Amazon MSK（Managed Streaming for Apache Kafka）とは？仕組み・料金・使い方とKafka自前運用との違いを解説

Amazon MSK（Amazon Managed Streaming for Apache Kafka）は、Apache Kafka のクラスターをAWS上のマネージドサービスとして動かすためのサービスです。ブローカーの構築・パッチ適用・監視・スケーリングといった運用作業をAWSが引き受けるため、開発チームはストリーミングデータの処理そのものに集中できます。本記事では、実装者の視点で Amazon MSK の構成・仕組み・料金・使い方を整理し、Amazon Kinesis や自前運用の Apache Kafka との使い分けの判断まで解説します。

まとめ（先に結論）

  • Amazon MSK は Apache Kafka を「そのまま」動かせるマネージドサービスで、既存の Kafka クライアントやツールをコード変更なしで接続できる。
  • 提供形態は主に3つ。ブローカー台数とサイズを自分で決める MSK Standard（プロビジョンド）、容量を意識せず使う MSK Serverless、Kafka Connect のコネクターを動かす MSK Connect。
  • Kafka API 互換が要件で、パーティション単位の順序保証やイベントの再処理（リプレイ）が要る用途は MSK が向く。AWSネイティブなシンプルさを優先し、Kafka互換にこだわらないなら Amazon Kinesis が候補になる。
  • 料金はブローカーの稼働時間・ストレージ・データ転送で決まる（Serverless はパーティション時間とスループット、ストレージの従量課金）。低トラフィックの検証用途では小さめのブローカーか Serverless から始めると費用を抑えやすい。

Amazon MSK とは何か｜AWSにおける定義と立ち位置

Apache Kafka は、大量のイベントデータを順序を保ったまま蓄積・配信できる分散ストリーミング基盤のオープンソースソフトウェアです。ただし、ブローカーのクラスター構成、バージョン更新、障害時の復旧、スケール調整などの運用負荷が大きく、自前で安定運用するには専任の知見が要ります。Amazon MSK は、この Kafka の運用部分をAWSが受け持つマネージドサービスとして提供されました（一般提供は2019年5月・時点情報）。

MSK が扱う Kafka はフォークではなく、コミュニティ版の Apache Kafka そのものです。したがって、プロデューサー／コンシューマーのアプリケーション、Kafka Connect のコネクター、スキーマ管理などの既存資産をほぼそのまま持ち込めます。Apache Kafka 自体の特徴やメリットの全体像は、Apache Kafkaが選ばれる理由とは？特徴とメリットを徹底解説で整理していますので、OSS としての Kafka の理解を先に固めたい場合はそちらを参照してください。本記事はその「AWS上での実装形態」に位置づけられます。

MSK Standard（プロビジョンド）：台数とサイズを自分で決める

ブローカーのインスタンスタイプと台数、EBS ストレージ容量を自分で指定してクラスターを構成する形態です。スループットやパーティション数を見積もれる本番ワークロードで、性能とコストを細かく制御したい場合に向きます。マルチAZ配置で可用性を確保し、Kafka のバージョンも複数から選べます（3.x系が中心・時点：2026年7月）。

MSK Serverless：容量設計を意識せず使い始められる形態

ブローカー台数やストレージ容量の設計を意識せず、スループットに応じて自動でスケールする形態です（一般提供は2022年4月・時点情報）。トラフィックが読みにくい新規サービスや、スパイクのあるワークロード、検証環境で使い始めやすい構成です。容量計画の手間を減らせる一方、超大規模で定常的な高スループットではプロビジョンドの方が単価を抑えられる場面もあり、想定負荷で試算して選びます。

MSK Connect：Kafka Connect を管理された形で動かす機能

Kafka Connect を管理された形で動かすための機能です（一般提供は2021年9月・時点情報）。データベースの変更データ（CDC）取り込みや、S3 や各種データストアへの書き出しといったコネクターを、コネクターの実行基盤を自前で用意せずにデプロイできます。取り込んだストリームを後段の分析につなぐ際に、Amazon Athenaとは？使い方・クエリの書き方・料金・Redshiftとの違いを解説で扱う S3 上データのクエリと組み合わせる構成も取れます。

Amazon MSK の仕組み・アーキテクチャの全体像を理解する

MSK のクラスターは、複数のブローカーノードで構成されます。トピックはパーティションに分割され、各パーティションは順序を保った追記ログとして働く。プロデューサーがパーティションへイベントを書き込み、コンシューマーはオフセット（読み取り位置）を進めながら読み取ります。オフセットで位置を管理するため、過去のイベントを最初から読み直すリプレイができる点が、単純なキューとの違いです。

可用性は、パーティションのレプリカを複数のブローカー（複数AZ）に分散して確保します。あるブローカーが落ちても、別レプリカがリーダーを引き継ぎます。メタデータ管理は、従来の ZooKeeper 依存から Kafka 本体の KRaft 方式へ移行が進んでおり、新しい Kafka バージョンでは運用構成が簡素化される方向です（バージョン依存・時点：2026年7月）。

ストレージは各ブローカーの EBS ボリュームに保持され、長期保持向けには階層型ストレージ（Tiered Storage）で低コスト層へ退避する構成も選べます。認証・認可は、IAM によるアクセス制御、SASL/SCRAM、mTLS（クライアント証明書）から要件に合わせて選択でき、通信は TLS で暗号化できます。

Amazon MSK の料金体系の考え方とコスト見積もりのコツ

MSK Standard の費用は、主に次の3要素で決まります。第一にブローカーのインスタンス稼働時間（台数×時間）、第二にストレージ容量（プロビジョンドした EBS と階層型ストレージ）、第三にAZ間などのデータ転送量です。ブローカーは稼働している限り課金されるため、常時稼働の本番では台数とサイズの見積もりがコストを左右します。

MSK Serverless は、クラスター単位の時間課金に加えて、パーティション時間・取り込み／取り出しのスループット・ストレージの従量で積み上がります。台数設計が要らない代わりに、パーティション数や流量が増えると費用も比例して伸びるため、パーティション設計を絞ることが費用抑制につながります。いずれの形態も、まず小さく作って実測トラフィックで試算し、段階的に広げるのが無駄の少ない進め方です。

Amazon MSK の使い方｜クラスター作成から接続までの実装手順

実装は、おおむね次の順で進みます。

  1. クラスター作成：マネジメントコンソールまたは IaC（CloudFormation／Terraform）で、Standard か Serverless を選び、VPC・サブネット・セキュリティグループを指定する。
  2. ネットワーク設計：MSK は VPC 内のプライベートな仕組みとして動くため、アプリケーション側（EC2・EKS・Lambda 等）から到達できるサブネットとセキュリティグループを設計する。
  3. 認証設定：IAM アクセス制御や SASL/SCRAM を有効化し、プロデューサー／コンシューマーのクライアント設定にブートストラップサーバーと認証情報を渡す。
  4. トピック設計：パーティション数と保持期間を、想定スループットと並列コンシューマー数から見積もる。パーティション数は後から増やせても減らせない前提で決める。
  5. クライアント接続：既存の Kafka クライアントライブラリ（Java・Python 等）でそのまま接続する。コネクター連携は MSK Connect に載せる。
  6. 監視：CloudWatch のメトリクスや Open Monitoring（Prometheus 互換）で、ブローカー負荷・パーティションのラグ・ディスク使用率を継続監視する。

Amazon Kinesis・自前 Kafka との使い分け

ストリーミングの選択肢は MSK だけではありません。判断の軸を先に述べます。「Kafka API 互換」「既存 Kafka 資産の移行」「豊富なコネクターやエコシステム」が要件なら MSK、「AWSネイティブな最小構成」「運用要素をさらに減らしたい」「Kafka 互換は不要」なら Amazon Kinesisが第一候補になる。両者の機能とシャード／容量モードの詳細は、Amazon Kinesisとは｜Data Streams・Firehoseの仕組みと料金・実装・採用判断を解説で比較していますので、AWS内で迷う場合はあわせて読むと選定が進みます。

Kafka を EC2 上に自前構築する選択肢と比べると、MSK はブローカーの運用・パッチ・スケールの負荷を肩代わりする分、細部のカーネルやブローカー設定の自由度は下がります。逆に、特殊なチューニングや独自ビルドが要件でなければ、自前運用の人件費とリスクを MSK が吸収します。メッセージング全般でキュー型（RabbitMQ 等）とストリーム型（Kafka）のどちらを採るかから検討したい場合は、RabbitMQとKafkaの違いで選定軸を確認してください。

Amazon MSK 導入時の判断｜採用条件と見送りを勧める場面

ここは判断を言い切ります。MSK を採用すべき条件は、(1) 順序保証やリプレイが要るイベント駆動アーキテクチャを AWS 上で運用する、(2) すでに Apache Kafka を使っており運用負荷だけ下げたい、(3) 複数のプロデューサー／コンシューマーがブローカーを共有する中〜大規模構成、のいずれかに当てはまる場合です。この条件では、自前運用より総保有コストと障害リスクを下げやすくなります。

一方で見送りを勧める場面もはっきりしています。単発のバッチ連携や日次ファイル取り込みで、順序保証もリプレイも不要な用途では、キューや SQS、あるいは単純なファイル連携の方が安く単純です。また、ごく小規模かつ常時低トラフィックでコストを最小化したい場合は、常時稼働ブローカーの費用が重くなりやすいため、Serverless で試すか Kinesis を検討する方が費用対効果が見えやすくなります。「Kafka を使うこと」自体を目的化せず、順序保証・リプレイ・Kafka互換という要件があるかで採否を決めてください。

よくある質問

Amazon MSK と Apache Kafka の違いは何ですか？

Apache Kafka はソフトウェア本体で、MSK はその Kafka をAWSがマネージドで運用するサービスです。MSK が動かすのはコミュニティ版 Kafka そのものなので、機能や API は同じで、違いはブローカーの構築・保守・スケールを自分でやるか AWS に任せるかにあります。

MSK Standard と MSK Serverless はどう選べばよいですか？

トラフィックを見積もれて性能とコストを細かく制御したい本番は Standard、負荷が読みにくい新規サービスや検証は Serverless から始めるのが判断の目安です。定常的な超高スループットでは Standard の方が単価を抑えられる場面もあるため、想定負荷で試算して決めます。

既存の Kafka アプリケーションはそのまま動きますか？

基本的に動きます。MSK はコミュニティ版 Kafka を提供するため、プロデューサー／コンシューマーや Kafka Connect のコネクターを、接続先（ブートストラップサーバー）と認証設定を変えるだけで移せる場合がほとんどです。

Amazon Kinesis とどちらを使うべきですか？

Kafka API 互換や既存 Kafka 資産、豊富なコネクターが要るなら MSK、AWSネイティブな最小構成で運用要素をさらに減らしたいなら Kinesis が第一候補です。要件に「Kafka であること」が含まれるかどうかが分かれ目になります。

料金を抑えるコツはありますか？

まず小さいブローカーか Serverless で始め、実測トラフィックで試算してから広げるのが基本です。パーティション数を必要以上に増やさないこと、長期保持は階層型ストレージへ退避すること、AZ間のデータ転送を意識することが費用抑制につながります。

関連記事

ストリーミング基盤の設計・構築や、取り込んだデータの分析基盤づくりまで含めて相談したい場合は、データ分析基盤構築・MLOps構築支援で対応しています。要件整理から実装・運用設計までを、受託開発の実務として支援します。

資料請求

RELATED POSTS 関連記事

一覧へ戻る