AWS MSK と Confluent の比較：運用・機能・コストの違いを試験と実務目線で整理

Kafka をマネージドで使うとき、多くのチームが AWS MSK と Confluent のどちらを選ぶかで悩みます。両者は「Kafka を動かす」点では同じですが、運用責任の境界、セキュリティ機能、周辺サービス、そして課金モデルが大きく異なります。

本稿では、日々の運用で効く差分と、CCAAK 試験で問われやすいポイント（RBAC/ACL、接続方式、レプリケーション、監査・ガバナンス）に絞って、安定した公式仕様に基づき整理します。

全体像と選定軸

MSK は AWS 上の VPC 内で Kafka ブローカーをマネージド提供するサービスです。Kafka 自体の互換性が高く、既存の Kafka ツール群をそのまま使いやすいのが強みです。一方、Schema Registry や ksqlDB などの周辺スタックは原則別途用意が必要です（自前または他サービス）。

Confluent は Kafka に加えて Schema Registry、Kafka Connect、ksqlDB、RBAC、監査、クラスタ間レプリケーション（Cluster Linking など）を統合的に提供します。Cloud 版はマルチクラウドでフルマネージド、Platform 版は自己管理型です。

• 選定軸は大きく「運用責任の境界」「セキュリティ/ガバナンス要件」「周辺機能の内蔵度合い」「ネットワーク制約」「コストモデル」の5つ。
• CCAAK 観点では、RBAC と ACL の違い、Schema Registry と互換モード、レプリケーション手段（MM2 vs Cluster Linking）、プライベート接続の扱いが頻出です。

運用モデルの違い（スケーリングとアップグレード）

MSK（プロビジョンド）はブローカー台数とEBS容量を明示的に管理します。スケール時はリバランスやパーティション再割当の計画が必要です。Serverless では容量計画の一部が抽象化されますが、パーティション設計やスループット上限など Kafka 固有の制約は引き続き設計が必要です。

Confluent Cloud はクラスタサイズや使用量ベースで拡張し、Schema Registry や Connect、ksqlDB も同一プラットフォームで連動します。ローリングアップグレードやバージョン整合性は提供側が吸収しますが、クライアント互換性（プロデューサ/コンシューマAPI、線形化/圧縮設定）は利用者側の責任です。

• MSK ではブローカー追加＝ネットワーク/セキュリティグループ/サブネット計画も伴う。
• Confluent ではパーティション上限やクォータ、CKU 等のサービス制約を事前確認。
• どちらでもパーティション増加は再割当とデータ移動を伴い、ピークトラフィック期は避ける。

セキュリティとアイデンティティ（ACL と RBAC、認証方式）

MSK は TLS による暗号化、SASL/SCRAM、そして AWS 独自の IAM 認証（SASL/IAM）に対応します。認可は Kafka ACL で行い、プリンシパル（ユーザ/ロール）に対してトピックやグループ等のリソース権限を付与します。

Confluent は API キーや OAuth/OIDC、mTLS を提供し、認可は RBAC（リソース所有者/役割）で行います。監査ログや Stream Governance（スキーマ互換性/タグ付け）と合わせて、組織的なガバナンスを一体で設計できます。

• 試験対策: ACL はアクション（Read/Write/Create）× リソース（Topic/Group/Cluster）で評価。RBAC はロール（DeveloperRead/Operator など）で権限束ねを行う点が異なる。
• スキーマ進化の互換モード（BACKWARD/FORWARD/FULL）は Confluent Schema Registry で頻出。MSK では別途のレジストリ運用が前提。

Kafka クライアント設定例（MSK IAM と Confluent Cloud の比較）

# MSK（SASL/IAM）クライアントプロパティ例
bootstrap.servers=b-1.msk.example.amazonaws.com:9098,b-2.msk.example.amazonaws.com:9098
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler

# Confluent Cloud（SASL/PLAIN）クライアントプロパティ例
bootstrap.servers=pkc-xxxxx.us-central1.gcp.confluent.cloud:9092
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="<API_KEY>" password="<API_SECRET>";
client.dns.lookup=use_all_dns_ips

エコシステム機能（Schema Registry / Connect / ksqlDB）

MSK 単体には Schema Registry や ksqlDB は含まれません。必要な場合は Confluent Schema Registry を自己管理でデプロイする、または別サービスを併用します。Connect は MSK Connect としてマネージド実行環境が提供されますが、利用可能なコネクタ、ライセンス、運用機能は各ベンダの提供範囲を確認してください。

Confluent は Schema Registry、マネージド Connect、ksqlDB を一体で提供し、互換モード、スキーマの進化、コネクタのバージョン管理、ストリーム処理の運用までを統合UI/APIで扱えます。

• 試験対策: スキーマ互換モードの選択と破壊的変更の検出、コネクタのエラーハンドリング（DLQ/リトライ）、ksqlDB の永続クエリとリソース消費が問われやすい。
• 実務: 異種DB/SaaSへの連携が多い場合は、マネージド Connect とカタログの充実度が総所有コストに影響。

可観測性・DR・ネットワーク

MSK は CloudWatch メトリクス/ログへの統合が基本です。マルチAZ配置がデフォルトで、リージョン間DRは MirrorMaker 2 などで構成します。ネットワークは VPC 内接続が前提で、プライベートな到達性設計（ルーティング/DNS/証明書）を厳密に行います。

Confluent はメトリクスAPIやUI、監査ログ（Cloud/Platform）を備え、DR は Cluster Linking などの選択肢があります。ネットワークは標準でインターネット経由の公開エンドポイントを持ち、必要に応じて Private Link/Peering/TGW で閉域化します。

• 試験対策: 消費遅延（consumer lag）、スロットル（クォータ超過/帯域制限）、拒否（RecordTooLarge/RequestQueueFull）などの症状と原因の対応付け。
• DR 設計では、同一クラスター内のレプリカ数と、クラスター間レプリケーション（RPO/RTO）の目的を分けて説明できること。

MSK（VPC内）と Confluent Cloud（Private Link 連携）の概念図

コストモデルと見積もりの勘所

MSK（プロビジョンド）はブローカー（インスタンスタイプ×台数×時間）とストレージ（GB/月）、データ転送、MSK Connect（使う場合）などが主要コストです。Serverless は使用量（入出力やパーティション/保存量等）に連動した課金が中心です。正確な単価はリージョンや時期で変動するため、公式料金ページでの見積りを前提にします。

Confluent Cloud は使用量課金（GB入出力、保存、パーティション等）およびプラン/サイズ（Basic/Standard/Dedicated、CKU 等）で決まります。Schema Registry、ksqlDB、Private Link 等のアドオンも併せて算入します。

• 両者とも AZ 間/リージョン間/インターネット方向のデータ転送は別課金になり得るため、DR/外部連携の設計時に必ず試算する。
• パーティション数は性能だけでなくコストにも影響（メタデータ/管理オーバーヘッド）。必要最小限で始め、段階的に増やす。
• 保存コストはコンパクション/保持期間（retention.ms/bytes）と連動。要件に応じてトピック単位で調整する。

問題で確認

よくある質問