Database

カテゴリ概要

Azure のデータベースサービスは、リレーショナル DB からマルチモデル NoSQL、インメモリキャッシュ、時系列分析まで幅広いワークロードをカバーする。AWS との最大の違いは、Cosmos DB がマルチモデル DB として DynamoDB・DocumentDB・Neptune・Keyspaces 相当の機能を 1 つのサービスに統合している点と、Azure SQL Database が SQL Server ベースの独自 PaaS として RDS SQL Server とは異なるアーキテクチャを持つ点にある。

サービスマッピング一覧

主要サービス詳細

Azure SQL Database（AWS: RDS SQL Server / Aurora に近い）

SQL Server エンジンをベースにした Azure 独自のフルマネージド PaaS データベース。RDS SQL Server とは異なり、Azure のクラウドネイティブなアーキテクチャ上に構築されている。

AWS エンジニアが知っておくべき違い:

• RDS SQL Server は EC2 上に SQL Server をデプロイする形式だが、Azure SQL Database は SQL Server の機能をクラウド向けに再設計した独自 PaaS。そのため、一部の SQL Server 機能（SQL Agent、CLR、Service Broker の一部など）は使えない
• 購入モデルが 2 種類ある: DTU ベース（パフォーマンスをバンドルした簡易モデル）と vCore ベース（CPU・メモリを個別に選択するモデル）。RDS のインスタンスクラス選択に近いのは vCore モデル
• Hyperscale tier は Aurora に近い位置づけで、ストレージの自動スケーリング（最大 100 TB）と高速な読み取りレプリカを提供する。Aurora のストレージアーキテクチャに類似した設計
• Serverless compute tier は Aurora Serverless v2 に近く、使用していないときは自動的にスケールダウン（一時停止も可能）し、アクティブ時に自動スケールアップする
• 組み込みの高可用性が提供され、RDS の Multi-AZ に相当する機能がデフォルトで含まれている（追加設定不要）

Azure SQL Managed Instance（AWS: RDS Custom for SQL Server に近い）

SQL Server との高い互換性を維持しつつ、フルマネージドの PaaS として提供されるサービス。オンプレミス SQL Server からの移行に最適。

AWS エンジニアが知っておくべき違い:

• RDS Custom for SQL Server よりも高い SQL Server 互換性を持ち、SQL Agent ジョブ、クロスデータベースクエリ、CLR、Service Broker など、Azure SQL Database では使えない機能も利用可能
• VNet 内にデプロイされ、プライベート IP アドレスでアクセスする。RDS のようにパブリックアクセスを簡単に有効化する方式ではない
• オンプレミス SQL Server からの移行パスとして Azure Database Migration Service が用意されており、ダウンタイムを最小限に抑えたオンラインマイグレーションが可能
• フェールオーバーグループを使って、異なるリージョンへの自動フェールオーバーを構成できる（RDS のクロスリージョンリードレプリカ + 手動昇格に相当）

Azure Database for MySQL - Flexible Server（AWS: RDS MySQL / Aurora MySQL）

MySQL のフルマネージドサービス。旧 Single Server は非推奨となり、Flexible Server が標準。

AWS エンジニアが知っておくべき違い:

• Aurora MySQL のようなストレージ自動分散アーキテクチャはない。ストレージは IOPS を含むプロビジョニングモデルまたは自動スケールモデルを選択する
• ゾーン冗長 HA（同一リージョン内の別 AZ にスタンバイを配置）を選択できるが、Aurora のような複数 AZ にまたがる共有ストレージモデルではなく、同期レプリケーション方式
• 読み取りレプリカは最大 10 個まで作成可能（Aurora は最大 15 個）
• メンテナンスウィンドウを柔軟にスケジュールでき、パッチ適用タイミングを制御可能
• RDS のパラメータグループに相当する「サーバーパラメーター」で MySQL の設定を変更できる

Azure Database for PostgreSQL - Flexible Server（AWS: RDS PostgreSQL / Aurora PostgreSQL）

PostgreSQL のフルマネージドサービス。MySQL と同様に Flexible Server が標準。

AWS エンジニアが知っておくべき違い:

• Aurora PostgreSQL に相当する高可用性アーキテクチャはないが、ゾーン冗長 HA を提供する
• Citus 拡張を有効化することで、分散テーブル（シャーディング）を利用した水平スケーリングが可能。Aurora のような読み取りスケーリングだけでなく、書き込みのスケーリングにも対応できる
• PgBouncer が組み込みで利用可能（接続プーリング）。RDS Proxy に相当する機能がサービスに内包されている
• 論理レプリケーションを使って、他の PostgreSQL インスタンスへのデータ配信が可能
• RDS と同様に、メジャーバージョンのインプレースアップグレードをサポートしている

Azure Cosmos DB（AWS: DynamoDB + DocumentDB + Neptune + Keyspaces を統合）

グローバル分散型のマルチモデルデータベースサービス。1 つのサービスで複数のデータモデルと API をサポートする Azure の主力 NoSQL サービス。

AWS エンジニアが知っておくべき違い:

• DynamoDB は Key-Value / ドキュメントモデル専用だが、Cosmos DB は NoSQL（コア）、MongoDB、Cassandra、Gremlin（グラフ）、Table の 5 つの API を提供する。AWS では DynamoDB + DocumentDB + Neptune + Keyspaces に分かれる機能を 1 サービスでカバー
• DynamoDB のキャパシティユニット（RCU / WCU）に相当するのが RU（Request Unit）。すべての操作（読み取り、書き込み、クエリ）のコストが RU で統一的に表現される
• DynamoDB Global Tables に相当するマルチリージョン書き込みをサポートしており、Active-Active のグローバル分散構成が可能
• 一貫性レベルを 5 段階（Strong / Bounded Staleness / Session / Consistent Prefix / Eventual）から選択できる。DynamoDB の強い整合性読み込み / 結果整合性読み込みの 2 択より細かい制御が可能
• DynamoDB Streams に相当する Change Feed 機能があり、データ変更をリアルタイムにキャプチャして Azure Functions 等で処理できる
• DynamoDB のようなテーブル設計（パーティションキー + ソートキー）とは異なり、NoSQL API ではパーティションキー + JSON ドキュメントの形式。クエリは SQL ライクな構文で記述する

Azure Cache for Redis（AWS: ElastiCache for Redis）

フルマネージドの Redis キャッシュサービス。セッション管理、データキャッシュ、メッセージブローカー等のユースケースに使用する。

AWS エンジニアが知っておくべき違い:

• ElastiCache for Redis と概念はほぼ同一。Standard（レプリカなし）、Premium（レプリカ + シャーディング + VNet 対応）、Enterprise / Enterprise Flash（Redis Enterprise ベース）の tier がある
• ElastiCache の Redis クラスターモードに相当するシャーディング（クラスタリング）は Premium tier 以上で利用可能
• Premium tier 以上で VNet 統合が可能。ElastiCache も VPC 内にデプロイするため、ネットワーク構成の考え方は同じ
• Azure には Managed Memcached サービスがない。ElastiCache for Memcached を使っている場合、Azure では Redis で代替するか、VM 上に自前で構築する必要がある

Azure Database for MariaDB（非推奨 → MySQL に移行推奨）

MariaDB のマネージドサービスだが、既に非推奨となっている。

AWS エンジニアが知っておくべき違い:

• Azure Database for MariaDB は 2025 年 9 月にリタイアが予定されており、新規作成は推奨されない
• 既存ワークロードは Azure Database for MySQL - Flexible Server への移行が推奨されている
• AWS の RDS MariaDB は引き続きサポートされているため、MariaDB を必須とするワークロードでは AWS のほうが選択肢がある

Azure Data Explorer / ADX（AWS: Timestream に近いが高機能）

大規模なログ・テレメトリ・時系列データに対するリアルタイム分析に特化したサービス。

AWS エンジニアが知っておくべき違い:

• Timestream は時系列データに特化しているが、ADX はログ分析、テレメトリ、IoT データなどより幅広いユースケースに対応する
• KQL（Kusto Query Language） という独自のクエリ言語を使用する。SQL に似ているがパイプベースの構文で、集計・フィルタ・可視化を効率的に記述できる
• Azure Monitor のログ分析基盤（Log Analytics）は ADX と同じ KQL エンジンを使用しており、Azure の監視エコシステムと深く統合されている
• 数十億行規模のデータに対するインタラクティブなクエリを数秒で実行でき、Timestream よりもスケーラビリティが高い

AWS との主要な違い

Cosmos DB のマルチモデルアプローチ

AWS では Key-Value ストアは DynamoDB、MongoDB 互換は DocumentDB、グラフ DB は Neptune、Cassandra 互換は Keyspaces と、データモデルごとに独立したサービスを選択する。Azure では Cosmos DB が 1 つのサービスでこれらすべてのデータモデルをサポートする。これにより、同一アプリケーション内で複数のデータモデルを使い分ける場合に、運用対象のサービスを 1 つに集約できる利点がある。一方で、各 API は完全互換ではなく、ネイティブの MongoDB や Cassandra とは動作が異なる部分もあるため、移行時には互換性の検証が必要。

Aurora に直接対応するサービスがない

AWS の Aurora は独自のストレージアーキテクチャ（3 AZ に 6 コピー、最大 128 TB の自動拡張）を持ち、MySQL / PostgreSQL 互換の高性能 DB として広く使われている。Azure にはこのアーキテクチャに直接対応するサービスがない。Azure SQL Database の Hyperscale tier が最も近い位置づけだが、SQL Server ベースであり MySQL / PostgreSQL 互換ではない。MySQL / PostgreSQL のワークロードでは Flexible Server のゾーン冗長 HA が Aurora の代替となるが、ストレージ層のアーキテクチャは従来型のレプリケーション方式である。

SQL Server エコシステムの充実

Azure は Microsoft 製品であるため、SQL Server 関連のサービスが AWS より充実している。Azure SQL Database（クラウドネイティブ PaaS）、Azure SQL Managed Instance（高互換 PaaS）、SQL Server on Azure VMs（IaaS）の 3 段階で、移行要件に応じた最適なサービスを選択できる。AWS の RDS SQL Server / RDS Custom for SQL Server よりも細かい粒度でマネージド度合いを調整できる。

Managed Memcached の不在

AWS では ElastiCache for Memcached と ElastiCache for Redis の 2 つのインメモリキャッシュサービスが提供されるが、Azure には Managed Memcached サービスがない。Azure Cache for Redis のみが提供されるため、Memcached を使用している AWS ワークロードを Azure に移行する際は、Redis への移行が必要になる。ただし、多くのユースケースでは Redis が Memcached の機能を包含しているため、実質的な制約は少ない。

RU ベースの課金モデル

Cosmos DB の課金は RU（Request Unit）ベースであり、DynamoDB の RCU / WCU とは異なる概念。RU はすべての操作（読み取り、書き込み、クエリ）を統一的に表現する単位で、1 KB のポイントリードが 1 RU となる。DynamoDB では読み取りと書き込みで別々のキャパシティを設定するが、Cosmos DB では RU として一元管理する。プロビジョニングスループットモデル（DynamoDB のプロビジョニドモードに相当）とサーバーレスモデル（DynamoDB のオンデマンドモードに相当）の 2 つの課金モデルを選択できる。

サービス選定の指針