Amazon Keyspacesとは？Cassandra互換サーバーレスDBの仕組み・料金・採用判断を実装者目線で解説

Amazon Keyspaces（for Apache Cassandra）は、Apache CassandraのCQL（Cassandra Query Language）と互換のAPIを備えた、AWSのフルマネージド型でサーバーレスなデータベースサービスです。サーバーの用意やパッチ適用、ノードの増減といった運用をAWS側に委ね、既存のCassandraアプリケーションのコードやドライバーをほぼそのまま動かせる点が持ち味です。この記事では、ワイドカラムというKeyspacesのデータモデル、サーバー管理を伴わない自動スケールの仕組み、オンデマンドとプロビジョンドの容量モード、RRU/WRUとストレージで積み上がる料金、35日のポイントインタイムリカバリやTTL・KMS暗号化・マルチリージョンレプリケーションといった保護機能を一次情報で整理します。DynamoDBや自己管理のCassandra、RDS/Auroraとの違い、Keyspacesを採用すべき条件と見送るべき場面の判断基準まで、データ基盤の選定で迷う論点を実装者目線で示します。

まとめ：Amazon Keyspacesの仕組み・料金と採用判断の要点

Amazon Keyspacesは、CQL APIでApache Cassandraと互換のAWSマネージドデータベースで、既存のCassandraワークロードをドライバーやツールをほぼ変えずにサーバーレス環境へ載せ替えられる点が核になります。ノードの構築やコンパクション、リペア、パッチ適用といった自己管理Cassandra特有の運用が不要で、トラフィックに応じてテーブルが自動でスケールします。読み書きは単一桁ミリ秒のレイテンシで、ストレージは実質的に容量上限を意識せず伸ばせる構成です。Cassandraクラスターの運用負荷をAWSへ移したい、あるいはサーバーの台数計画から解放されたいワークロードに向きます。

料金は、起動インスタンスの時間課金ではなく、実際の読み書き量とストレージ量に対する従量制です。オンデマンドモードは容量計画なしで使え、波の大きい負荷で無駄が出にくく、負荷が読めるならプロビジョンドモードで単価を下げられます。既存Cassandraの移行やCQLでの開発が前提ならKeyspaces、AWSネイティブに新規のNoSQLを組むならDynamoDB、結合やトランザクション整合性が中心ならRDS/Aurora、という切り分けが基本の判断軸です。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめてください。

Amazon Keyspacesの仕組みとCassandra互換のデータモデル

Keyspacesを設計へ落とし込むには、まず「ワイドカラム型のCassandraがリレーショナルデータベースやキーバリューストアとどう違うのか」を押さえるのが出発点です。ここが曖昧なままだと、結合が前提の業務データを無理に一枚のテーブルへ押し込んだり、逆に単純なキー参照で足りる用途に分散データベースを持ち込んだりといった設計のずれを招きます。データベースの種類やRDBとNoSQLの選び方から確認したい場合は、データベースの種類・DBMS・RDBとNoSQLの選び方を実装目線で解説した記事が上位の入り口になります。

サーバーレスなApache Cassandra互換マネージドDBという位置づけ

Amazon Keyspacesは、大量データを分散して扱うために設計されたワイドカラム型のデータストア、Apache Cassandraと互換のAPIを提供するマネージドサービスです。利用者はサーバーをプロビジョニング・パッチ適用・運用する必要がなく、ソフトウェアのインストールや保守も伴いません。数クリックまたは数行のコードでキースペースとテーブルを作成でき、インフラを一切デプロイせずにCassandraワークロードをAWS上で動かし始められます。サーバーレスであるため、使ったリソースぶんだけを支払い、アプリケーションのトラフィックに応じてテーブルが自動でスケールする設計です。既存のCassandraで積み上げたアプリケーションコードや開発ツールを、そのままAWSクラウドへ持ち込める点が採用の起点になります。

CQL APIとワイドカラム型のデータモデルと主要言語の対応ドライバー

Keyspacesの操作は、CassandraのCQL（Cassandra Query Language）APIを通じて行います。SQLに似た構文でキースペース・テーブルの定義やデータの読み書きを記述でき、Apache Cassandra 2.0ライセンスのオープンソースドライバーと開発ツールをそのまま使える点が特徴です。ドライバーはJava・Python・Ruby・.NET・Node.js・PHP・C++・Perlなど主要言語向けが用意されています。データモデルはパーティションキーとクラスタリングキーでプライマリキーを構成するワイドカラム型で、パーティションキーの設計がアクセス性能と分散のばらつきを左右します。1行あたりのサイズには上限（2026年7月時点で1MB系。公式で時点確認）があるため、巨大な値を1行に詰め込む設計は避け、パーティション設計とあわせて見積もります。既存のCQLスキーマやクエリをそのまま持ち込めるかは、互換範囲に収まるかを検証環境で確認するのが安全です。

単一桁ミリ秒レイテンシとサーバー管理を伴わない自動スケールの仕組み

Keyspacesは、読み書きに対して単一桁ミリ秒のレイテンシを一貫して提供するとされ、テーブルはトラフィックに合わせて自動でスケールします。自己管理のCassandraで避けて通れないノードの追加・削除、コンパクションやリペア、バージョンアップといった運用作業が、マネージドサービスとしてAWS側に含まれる点が、自己管理との最大の差です。スループットとストレージは実質的に上限を意識せず伸ばせる構成で、秒間数千リクエストを処理するアプリケーションを、事前のキャパシティ確保なしに構築できます。可観測性はCloudWatchと連携し、読み書きのキャパシティ消費やスロットリングをメトリクスで追える設計です。運用の担い手をAWSへ寄せることで、クラスターのお守りではなくアプリケーション側の開発にリソースを振り向けられます。

Amazon Keyspacesの容量モード・料金モデルと保護機能の設計前提

Keyspacesで次に押さえるのが、容量モードの選択と料金の積み上がり方、そしてバックアップ・暗号化といった保護の前提です。読み書きの課金単位を理解しておくと、試算とチューニングの精度が上がります。

オンデマンドとプロビジョンドという2つの容量モードの選び分け基準

Keyspacesの容量モードは2つあります。オンデマンドモードは、想定外のピークに備えて事前にスループットを積んでおく必要がなく、実際のリクエスト量に対して支払う従量制で、容量計画そのものを省けます。プロビジョンドモードは、読み書きのキャパシティをあらかじめ指定し、オートスケーリングでトラフィックの変動に追随させる方式で、負荷が読める定常ワークロードで単価を下げやすい構成です。トラフィックの波が大きく予測しにくいならオンデマンド、安定して負荷が見通せるならプロビジョンド、という需要の読みやすさが選び分けの起点になります。モードはテーブル単位で切り替えられるため、立ち上げ期はオンデマンドで様子を見て、定常化したらプロビジョンドへ寄せる運用も取れます。

RRU/WRU・ストレージで積み上がる料金モデルと2024年の値下げ

料金は、読み書きのリクエスト量とストレージ量で積み上がります。オンデマンドでは、読み取りリクエスト単位（RRU）がLOCAL_QUORUM整合性で最大4KBの読み取りに相当し（LOCAL_ONEなら半分の消費）、書き込みリクエスト単位（WRU）が1行あたり最大1KBの書き込みに相当する単位です。プロビジョンドでは、これが毎秒あたりのRCU/WCUという指標に置き換わります。ここにストレージのGB/月課金が加わる構造です。2024年11月の改定で、オンデマンドは単一リージョンで最大56%・マルチリージョンで最大65%、プロビジョンドは単一で最大13%・マルチで最大20%引き下げられ、TTLによる削除の価格も75%下がりました。1年コミットのDatabase Savings Plans（$/時のコミット）で単価を抑える選択肢もあります。RRU/WRUの消費は1行のサイズと整合性レベルで変わるため、代表的な読み書きの1回あたりKB数を見積もって試算し、下表の要素ごとに打ち手を検討してください。

ポイントインタイムリカバリ・TTL・暗号化とマルチリージョンの保護前提

保護と可用性は、マネージドサービスとして標準的な仕組みがそろっています。ポイントインタイムリカバリ（PITR）を有効にすると、最大35日の連続バックアップから任意の秒単位の時点へ復元でき、誤操作やアプリ不具合からの巻き戻しに使えます。TTL（Time to Live）は行や属性に失効時刻を設定して自動削除する機能で、プロビジョンド容量や手動コンパクションを伴わずに古いデータを整理でき、削除は1行あたり1KBごとに1回分として計上される仕組みです。

保存データはデフォルトで暗号化され、AWS所有キーまたはKMSのカスタマー管理キーを選べます。転送中はTLSで保護し、IAMによる認可とAWS PrivateLinkによるVPC内接続も前提です。マルチリージョンレプリケーションは99.999%の可用性をうたい、非同期複製は通常1秒未満で伝播し、競合はセル単位のタイムスタンプによるlast-writer-winsで解決します。変更データを他システムへ流したい場合は、Keyspaces StreamsでCDC（変更データキャプチャ）をStreams APIまたはKinesis Client Library経由で受け取れます。

Amazon Keyspacesを採用すべき条件と各データベースとの使い分け

ここでは判断を言い切ります。KeyspacesはCassandra互換のサーバーレスDBとして強い反面、新規でAWSネイティブなNoSQLを組むだけの用途や、結合とトランザクション整合性が中心の業務データには過剰、あるいは用途違いになります。自社のデータをどこに置くかを、条件付きで見極めてください。

Amazon Keyspacesの採用が効くワークロードと要件の見極め

採用が効くのは、既存のApache CassandraワークロードをAWS上へ移したい、かつCQLやCassandraのドライバー・ツールをそのまま使い続けたい、という条件が重なるときです。具体例としては、オンプレミスや他クラウドで自己管理しているCassandraクラスターの移行、時系列データやIoTのイベントログ、ユーザーアクティビティのように書き込みが多く水平にスケールしたいワークロード、パーティションキーで引く単純な参照が中心のアプリケーションが当てはまります。ノードのお守り、コンパクションやリペア、パッチ適用といった運用をマネージドに委ね、サーバーの台数計画から解放されたい場面で効きます。こうしたAWS上のデータベース基盤や既存Cassandraワークロードの移行を自社で進めるなら、AWSを含むクラウドインフラ構築の相談窓口で、容量モードの選定やパーティション設計、RRU/WRUを含めたコストの妥当性を相談するとよいでしょう。

DynamoDBとの違いとサーバーレスNoSQLの選び分けの判断軸

同じAWSのサーバーレスNoSQLであるDynamoDBと比べると、判断軸がはっきりします。両者ともサーバーレスで単一桁ミリ秒のレイテンシを提供しますが、Keyspacesは既存Cassandra資産の互換（CQL・ドライバー）を主眼に据えるのに対し、DynamoDBはAWS独自のAPIを持つキーバリュー／ドキュメント寄りのデータベースです。新規にAWSでNoSQLを組むだけで、Cassandra互換が必須でないなら、エコシステムとの結び付きが強いDynamoDBが有力な候補になります。両者の特徴は、AWS DynamoDBの特徴・使い方・料金・RDSとの違いを実装目線で解説した記事と読み比べると切り分けやすくなります。既存のCassandraコードやCQLスキーマを流用できるか、あるいはAWSネイティブなAPIとサービス連携を優先するかが、選び分けの分かれ目です。

自己管理Cassandra・RDS/Auroraへ寄せる切り分けと過剰な場面

自前でCassandraを運用してきたチームにとって、Keyspacesはノード管理・リペア・パッチといった運用を手放せる一方、CQLや機能の一部で自己管理版と挙動が異なる場合があります。特定のCassandra機能やバージョン固有の挙動に強く依存しているなら、互換範囲に収まるかを事前に確認し、収まらないならEC2上での自己管理Cassandraを残す判断もあり得ます。逆に、複数テーブルの結合や、金額を扱うような厳密なトランザクション整合性が中心の業務データなら、ワイドカラムのKeyspacesは用途違いです。こうしたデータは、MySQLやPostgreSQLをマネージドで動かすRDSや、負荷に応じて自動でスケールするAuroraへ寄せます。とくに需要の増減が読みにくいワークロードでは、コンピュートを自動で伸縮させるAurora Serverless v2のスケーリングと料金を解説した記事が選択肢になります。分散前提でCQLの読み書きが中心ならKeyspaces、正規化された関係データと整合性が要るならRDS/Aurora、という軸で選定してください。

よくある質問

Amazon Keyspacesの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Amazon Keyspacesは自己管理のApache Cassandraとどう違うのですか？

KeyspacesはCassandra互換のAPI（CQL）を提供するAWSのサーバーレスなマネージドサービスで、Cassandra本体そのものではありません。ノードのプロビジョニングやコンパクション、リペア、パッチ適用といった運用が不要になり、テーブルはトラフィックに応じて自動でスケールします。一方で内部エンジンはAWSが独自に実装しているため、Cassandraの全機能・全バージョン固有の挙動がそのまま使えるわけではなく、必要な機能が互換範囲に収まるかを事前に確認します。

Amazon KeyspacesとDynamoDBはどちらを選べばよいですか？

既存のCassandraワークロードを移行したい、あるいはCQLやCassandraドライバーの互換が要るならKeyspaces、新規にAWSでNoSQLを組むだけならAWSネイティブなDynamoDBが起点になります。両者ともサーバーレスで単一桁ミリ秒のレイテンシを備えますが、KeyspacesはワイドカラムのCQL、DynamoDBはキーバリュー／ドキュメント寄りの独自APIという違いがあります。既存資産の互換か、AWSサービスとの連携かが判断の分かれ目です。

Amazon Keyspacesの料金はどう決まりますか？

起動インスタンスの時間課金ではなく、読み書きのリクエスト量とストレージ量に対する従量制です。オンデマンドは読み取りRRU（LOCAL_QUORUMで最大4KB）と書き込みWRU（1行あたり最大1KB）で計上し、プロビジョンドは毎秒あたりのRCU/WCUを指定します。ここにストレージのGB/月が加わります。2024年11月の値下げでオンデマンド・プロビジョンドとも単価が下がり、TTL削除の価格も引き下げられました。1年コミットのDatabase Savings Plansで単価を抑える選択肢もあります。

Amazon Keyspacesのバックアップと復元はどうなっていますか？

ポイントインタイムリカバリ（PITR）を有効にすると、最大35日の連続バックアップから任意の秒単位の時点へ復元できます。保存データはデフォルトで暗号化され、AWS所有キーまたはKMSのカスタマー管理キーを選べる仕組みです。マルチリージョンレプリケーションを使えば、複数リージョンへ非同期で複製して可用性とディザスタリカバリを高められ、競合はセル単位タイムスタンプのlast-writer-winsで解決します。

既存のCassandraアプリはそのままAmazon Keyspacesへ移行できますか？

CassandraのCQL APIと、Apache Cassandra 2.0ライセンスのオープンソースドライバー・ツールに互換のため、接続先の切り替えを中心とした変更で載せ替えられる場合が多いです。ただし互換範囲を外れる機能や、1行あたりのサイズ上限、パーティション設計の前提が自己管理版と異なることがあります。移行前に、使用しているCQLや機能が互換範囲に収まるかを検証環境で確認し、必要なら移行ツールやデータ移行の手順を併用すると安全です。

関連記事

• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説：Keyspacesの前提となるデータベースの分類とRDB・NoSQLの選び方を整理した上位概念の記事
• AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説：Keyspacesと選び分けるAWSのもう一方のサーバーレスNoSQLを整理した記事
• Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説：結合や整合性が要る場合に寄せるRDB側のマネージドDBを整理した記事