LASSIC Media らしくメディア
Azure Cosmos DBのコストを外注で最適化する進め方【RU削減】
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Cosmos DBのRU課金は「Autoscale・Serverless・パーティション設計・TTL」の4軸で削減できます。
- Autoscaleは平均使用率66%未満のワークロードで特に有効で、未使用時間のコストを自動で圧縮できます。
- パーティション設計やインデックスポリシーの最適化は高度な知識を要するため、外注で専門家に委ねることで失敗リスクを下げられます。
目次
Cosmos DBのRU課金とコスト増加の背景
Azure Cosmos DB（NoSQL用API）のコスト最適化（RU削減）とは、Microsoftが提供するフルマネージドNoSQLデータベースサービスにおいて、スループット課金単位であるRU/s（Request Unit per second）の消費量を適正化し、クラウドコストを抑制する取り組みを指します。
RU（Request Unit）とは何か
Azure Cosmos DBは、読み取り・書き込み・クエリなどすべてのデータベース操作を「RU（Request Unit）」という単位に統一して課金します。1秒あたりに消費できるRUの上限がRU/sであり、この値をプロビジョニングした量に基づいて費用が発生します。
Microsoft Learnの公式ドキュメントによれば*1、最小スループットの400 RU/sから始まり、毎秒数千万リクエスト以上までスケールアップできます。例として40 RUのコストがかかるクエリを処理する場合、400 RU/sでは1秒間に10個しか処理できず、それを超えるとレート制限（HTTP 429）が返ります。
担当者が直面する「気づいたら高くなっている」課金パターン
Cosmos DBのコスト増加でよく見られるのは、「初期リリース時に余裕を持ってプロビジョニングした値をそのまま据え置いている」というパターンです。夜間・休日もトラフィックが低い時間帯でも、手動プロビジョニングの場合はフルのRU/sが課金され続けます。
アクセスが集中するのは平日の業務時間帯だけにもかかわらず、1か月730時間分の固定コストが発生する仕組みになっています。利用状況の監視が行われていないと、このコスト構造が見えにくくなりがちです。
DynamoDBなど他NoSQLとの課金モデルの違い
AWSのAmazon DynamoDBはWCU（書き込みキャパシティユニット）とRCU（読み込みキャパシティユニット）に分離した課金体系であり、操作種別ごとに単価が異なります。一方、Cosmos DBはRUに統一されているため、クエリの複雑さやデータサイズがRU消費に直結します。
この違いは最適化アプローチにも影響します。Cosmos DBでは「1クエリあたりのRU消費量をいかに下げるか」という観点でパーティション設計やインデックスポリシーを調整することが、コスト削減の中心になります。
RU削減の4つの軸 — Autoscale・Serverless・パーティション・TTL
Cosmos DBのRUコストを削減するには、①Autoscale切替え、②Serverless活用、③パーティションキー設計・インデックスポリシー最適化、④TTLによるデータ削除、の4軸で対応します。それぞれのアプローチは互いに独立しており、ワークロードの特性に合わせて組み合わせられます。
①Autoscale切替え — 使用率66%未満なら自動スケールダウンでコスト削減
Autoscale（自動スケーリング）は、設定した上限RU/sの10%を最小値として、トラフィックに応じて自動的にスケールアップ・ダウンします。Microsoft Learnの公式ドキュメントによれば*2、平均使用率が66%未満のワークロードではAutoscaleがコスト削減に有効です。逆に平均使用率が66%を超えている場合は、手動プロビジョニングのほうが割安になります。
例えば上限4,000 RU/sのAutoscaleを設定した場合、低負荷時は400 RU/sまで自動縮退します。実際の課金は「その時間内にスケーリングされたピークRU/s」に対して時間単位で発生するため、トラフィックが少ない夜間・休日のコストを大幅に抑えられます。なお、マルチリージョン書き込み構成では手動とAutoscaleのRU/s単価が同等になるため*2、使用率にかかわらずAutoscaleが有効な選択肢です。
②Serverless — 小規模・開発環境向けの実消費課金
Serverlessモードは、プロビジョニングなしで実際に消費したRUにのみ課金される容量モードです。Microsoft Learnによれば*3、断続的または予測不可能なトラフィックを持つワークロードに適しています。開発・ステージング環境や低トラフィックのプロジェクトでは、手動プロビジョニングよりも費用を抑えられます。
ただし、Serverlessは1つのAzureリージョンのみで動作し、地理的分散には対応していません*3。高頻度・大量RU消費のワークロードでは割高になる場合があります。本番の大規模サービスではAutoscaleとの比較検討が必要です。
| モード | 課金の仕組み | 向いているワークロード | 注意点 |
|---|---|---|---|
| 手動プロビジョニング | 設定したRU/sを常時課金 | 平均使用率66%超の安定トラフィック | 低負荷時間でも固定コスト発生 |
| Autoscale | その時間のピークRU/sを課金（最低値は上限の10%） | 平均使用率66%未満の変動トラフィック | 単価は手動の約1.5倍 マルチリージョン書き込みは同単価 |
| Serverless | 消費したRUのみを従量課金 | 開発環境・低トラフィック・断続的アクセス | 単一リージョン限定。 大量消費時は割高になる場合あり |
③パーティションキー設計・インデックスポリシーでRU消費を減らす
Cosmos DBはデフォルトですべてのプロパティに自動インデックスを付与します。プロパティ数が多いドキュメントでは、このインデックスコストが無視できない割合を占めます。実際にクエリで使用するプロパティに絞ってインデックスポリシーを調整することで、書き込み時のRU消費を抑えられます*1。
パーティションキーの選択も同様に重要です。特定のパーティションへアクセスが集中する「ホットパーティション」が発生すると、そのパーティションに必要なRU/sが跳ね上がります。均等に分散できるパーティションキーを設計することで、全体のプロビジョニング量を抑えられます。
④TTLで不要データを自動削除しストレージ・RUを節約
TTL（Time to Live）は、設定した秒数後にアイテムを自動削除する機能です。ログデータ・セッション情報・一時キャッシュなど、一定期間後に不要になるデータに設定することで、ストレージコストとクエリ時のRU消費を削減できます*4。
手動削除の場合はアプリケーション側で削除ロジックを実装する必要がありますが、TTLを使えばCosmos DB側で自動処理します。プロビジョニング済みアカウントでは、ユーザーリクエストで消費されなかった残余RUを使って削除処理が行われるため、別途RUを追加する必要はありません*4。
内製で最適化するときの落とし穴と難易度
RU削減の4軸はドキュメントを読めば理解できますが、本番環境での実施には複数の落とし穴があります。特にパーティション設計はデータモデルと密接に関わるため、変更コストが高くなります。
パーティション設計ミスが招く「ホットパーティション」問題
パーティションキーを誤ると、一部の論理パーティションにアクセスが集中するホットパーティションが発生します。Cosmos DBではパーティションごとにスループットが分配されるため、ホットパーティションが生じると全体のRU/sを大幅に引き上げなければ処理が詰まります。
さらに、既存コンテナーのパーティションキーは変更できないため、設計ミスの修正にはデータの再移行が必要です。本番サービスでの再移行は、ダウンタイムの計画・データ整合性の確認・アプリケーション側の接続先変更など、複数工程を伴います。設計前にアクセスパターンを十分に分析することが求められます。
インデックスポリシー変更に必要なスキルと工数
インデックスポリシーの最適化には、Cosmos DBのクエリエンジンの動作・RU課金の計算方法・JSON形式のポリシー定義・変更後の検証の4つの知識が必要です。インデックスポリシーを変更すると既存データに対してバックグラウンドで再インデックスが走り、その間RU消費が増加します。本番環境では低負荷時間帯を選んで実施し、変更前後でRU消費量・クエリ性能の両方を計測する必要があります。
担当者1名が初めてこの作業を行う場合、調査・設計・実装・検証のサイクルで数週間から1か月規模の工数がかかることがあります。専任担当がいない環境では、既存業務と並行しての対応は難しくなります。
誤ったスループット設定が引き起こすリクエスト制限（429エラー）
Autoscaleへの切替えや手動でのRU/s引き下げを行う際、プロビジョニング値が実際のピーク需要を下回るとHTTP 429（RequestRateTooLarge）エラーが頻発します。Azure Cosmos DB SDK（.NET・Java・Node.js・Python）は自動リトライを行いますが*1、リトライ待機時間の間ユーザーへの応答が遅延します。サービス品質に影響するため、RU/sの引き下げは負荷テストと組み合わせることが重要です。
外注で任せられる範囲と進め方
Cosmos DBのコスト最適化を外注する場合、現状診断から最適化設計・実装・継続監視まで一貫して委託できます。フェーズごとに依頼できるため、予算や社内リソースの状況に合わせた形で開始できます。
フェーズ1：現状診断 — RU消費パターン・使用率の可視化
最初のフェーズでは、Azure PortalのメトリクスやAzure Monitorを使ってRU消費量・正規化使用率・レート制限エラーの傾向を可視化します。「1時間ごとの正規化使用率の平均が66%以上か否か」がAutoscale移行の判断基準になります*2。
外注先が担うのは、この使用率データの収集・分析・ボトルネックの特定です。社内に担当者が不在でも、アクセス権限を委任することで診断レポートを受け取れます。診断フェーズだけを単独で依頼し、結果を見てから次のフェーズを検討する進め方も可能です。
フェーズ2：最適化設計 — Autoscale移行判断・インデックス・TTL設計
診断結果をもとに、Autoscale移行の可否・上限RU/sの設定値・対象コンテナーへのServerless適用・インデックスポリシーの見直し箇所・TTL設定対象データの範囲を設計します。この段階では実際のデータアクセスパターンとコスト試算を組み合わせた判断が求められます。
インデックスポリシーの変更設計では、どのクエリでどのプロパティが使われているかをAzure Monitor Logsで分析し、不要なインデックスを特定します。パーティションキーの再設計が必要な場合は、データ移行計画も含めて設計書として整理します。
フェーズ3：実装・検証・継続監視
設計書に基づいて実装・設定変更を行い、変更前後のRU消費量・クエリ応答時間・429エラー発生率を比較検証します。検証後は継続的な監視体制を整え、トラフィックの変化に応じてAutoscaleの上限値を定期的に見直します。
外注先との契約形態として、単発のスポット対応（フェーズ1〜2のみ）と、継続的な運用監視を含む保守契約の2つがあります。コスト最適化は一度実施すれば完了ではなく、データ量・利用パターンの変化に合わせた継続的な調整が効果を持続させます。
外注先の選び方 — Cosmos DB実績のある委託先を見極めるポイント
Cosmos DBのコスト最適化を外注する場合、委託先の選定で確認すべき観点があります。Azure全般の知識だけでなく、Cosmos DB固有のRU課金・パーティション設計・インデックスポリシーに精通しているかどうかが重要です。
確認すべきポイントは次の4点です。
- Cosmos DBの構築・最適化実績があるか：Azure全般の実績にとどまらず、Cosmos DBを用いたシステムの設計・運用経験が確認できると判断の根拠になります。
- 診断フェーズを単独で提供しているか：いきなり大規模な改修を提案するのではなく、まず現状診断から始める提案ができる委託先は、課題を正確に把握してから動く姿勢があります。
- 変更時のリスク管理（429エラー対策・ロールバック計画）を説明できるか：設定変更によるサービス影響を最小化するための手順を持っているか確認します。
- 元請（プライムベンダー）として窓口を一本化できるか：Cosmos DBの最適化はインフラ・アプリケーション・データモデルをまたいで対応が必要になります。複数の下請けに分散せず、一社が責任を持って調整できる体制が望まれます。
なお、Cosmos DBのコスト最適化はAzureの他サービス（Azure SQL・Azure Monitor・Azureコスト管理）との連携も生じます。Cosmos DB固有の最適化と、Azure全般のコスト施策（リザーブドキャパシティ・予約容量など）を分けて検討することで、対応範囲を整理しやすくなります。
まとめ — Cosmos DBコスト最適化の3つの判断軸
本稿では、Azure Cosmos DBのRU課金が高くなる背景と、コスト削減のための4軸（Autoscale・Serverless・パーティション設計・TTL）を整理しました。要点を3つに集約します。
第一に、Autoscaleの適用可否は「平均使用率66%」で判断します。Microsoft Learnの公式ドキュメントに示された基準です*2。66%未満であればAutoscaleで未使用時間のコストを圧縮できます。66%超の安定トラフィックでは手動プロビジョニングが割安です。
第二に、パーティション設計とインデックスポリシーはデータモデルに直結するため、変更コストが高い領域です。設計段階で適切な選択を行うことが、後のコスト増加を防ぐ道です。既存システムで設計の見直しが必要な場合は、専門知識を持つ外注先に診断を依頼することでリスクを下げられます。
第三に、コスト最適化は一度で完結しません。データ量・トラフィックパターンの変化に応じた継続的な監視と調整が必要です。社内にCosmos DB専任担当がいない場合、保守契約として継続的に委託する形が現実的な選択肢になります。
よくある質問
Azure Cosmos DBのコスト最適化を外注するメリットはありますか？
外注の主なメリットは、Cosmos DB固有のRU課金・パーティション設計・インデックスポリシーに精通した専門家が対応できる点です。内製で対応する場合、担当者が不在だと調査・設計・実装の工数確保が難しくなります。外注先はAzure Monitorを使った使用率分析や最適化設計を短期間で提供できます。設計ミスによる429エラーやホットパーティション問題のリスクも事前に回避しやすくなります。
AutoscaleとServerlessはどう使い分けますか？
Microsoft Learn公式ドキュメントによれば*2,*3、Autoscaleはトラフィックが変動するワークロード向けで、設定した上限RU/sの10%を最低値として自動スケールします。Serverlessは消費したRUのみ課金するため、開発環境・断続的アクセスのワークロードで割安になります。ただしServerlessは単一リージョン限定です。本番サービスで複数リージョンを使う場合はAutoscaleが選択肢になります。
パーティションキーの設計を後から変更できますか？
既存コンテナーのパーティションキーは変更できません。変更が必要な場合は、新しいパーティションキーで別コンテナーを作成してデータを再移行する必要があります。再移行はデータ整合性の確認・アプリケーション接続先の変更・移行中のダウンタイム管理など複数の工程を伴います。外注先に依頼する場合は、移行計画の策定とリスク評価も含めて委託することをお勧めします。
外注する場合、どのくらいの期間でコスト削減効果が出ますか？
効果が出るタイミングはワークロードの特性によって異なります。Autoscale切替えは設定変更後すぐに課金に反映され、翌月の請求から削減効果を確認できます。インデックスポリシーの最適化はバックグラウンドの再インデックス完了後に効果が現れます。パーティション再設計が必要な場合はデータ移行工程が加わるため、準備期間を含めた計画が必要です。まず診断フェーズで優先度の高い施策を特定し、効果の大きい対応から着手することが現実的です。
Azure全般のコスト最適化（Hybrid BenefitやReserved Capacityなど）との関係はどうなりますか？
Cosmos DBのRU最適化は、Azure全般のコスト施策（Azure Hybrid BenefitやリザーブドキャパシティによるVM・SQL割引）とは独立した対応です。Microsoft Learn公式ドキュメントによれば*1、Cosmos DBも予約容量（Reserved Capacity）を利用して1時間単位のプロビジョニングコストを割り引く仕組みがあります。Azure全般の費用最適化と合わせて検討する場合は、それぞれの担当範囲を整理してから対応することをお勧めします。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Microsoft「スループット コストの最適化 – Azure Cosmos DB」（2026年6月24日更新）
- *2 出典：Microsoft「手動スケールと自動スケールを選択する方法 – Azure Cosmos DB」（2024年7月26日更新）
- *3 出典：Microsoft「プロビジョニング済みスループットとサーバーレスの比較 – Azure Cosmos DB」（2025年7月25日更新）
- *4 出典：Microsoft「TTLを用いてデータを有効期限切れにする – Azure Cosmos DB」（2025年12月5日更新）
