クラウドデータベース 比較解説まとめ

最終更新 2019-09-11

クラウドのリレーショナル・データベースサービス Amazon RDS、Azure SQL Database、Google Cloud SQL について、機能・料金・管理面などの比較をしてみます。

• 2019/06/21、Amazon RDS にて Aurora 以外にも容量自動拡張機能が追加されました。詳細
• 019/04/26、Amazon RDS の 1時間単位の課金が秒単位 (ただし最低利用10分) になったことを追記。
• 2019/04/10、DBバージョン・CPU・メモリ等を最新化。Azure SQL Database の「読み取りスケールアウト」の説明を追記 (追加コストなし！)

リレーショナル・データベースとは

リレーショナル・データベース (RDBMS) とは、表形式でデータを保存でき、 SQL などの言語によってデータの取得・集計・加工が行えるものです。

クラウド以前より、下記のような RDBMS が存在していました。

• Oracle Database
• MySQL
• PostgreSQL
• Microsoft SQL Server
• IBM DB2
• SAP Sybase

クラウドでのリレーショナル・データベースエンジン

2000年台後半より、リレーショナル・データベースエンジンをクラウドサービスに乗せる動きが進んでいます。クラウドサービス上でリレーショナル・データベースエンジンを動かすメリットは下記です。

• インストール不要で簡単構築
• 管理画面操作ですぐに使える
• 使った分だけ課金
• スケールアップ・スケールダウンを行える
• バックアップの自動化
• 冗長構成を簡単に組める
• パッチ当て不要
• ライセンス購入不要
• ストレージ拡張が容易
• ハードウェア障害対応不要

構築やメンテナンスの手間を省けるというメリットが非常に大きいと考えます。法人・商用サービスだけではなく、小規模な個人利用であってもぜひ利用を検討してみてください。

クラウドサービスとしてリレーショナル・データベースを動かすことを DBaaS (データベース・アズ・ア・サービス) と呼びます。Amazon・Microsoft・Google 各社が提供する DBaaS のサービス名称は下記のとおりです。

• Amazon Relational Database Service (RDS)
• Azure SQL Database (このページでは Azure Database for MySQL、Azure Database for PostgreSQL、Azure Database for MariaDB も含めて説明します)
• Google Cloud SQL

各サービス比較表

Amazon RDS・Azure SQL Database・Google Cloud SQL についての DBaaS の機能比較表は以下のとおりです。細かな解説はのちほど。

比較表はここまでです。以下、詳細説明です。

管理画面からの操作

まずは当然の話ではあるのですが、 管理画面でポチポチと操作するだけでデータベースが構築できますよという点。ソースからビルドしたり、パッケージインストールしたり、 my.cnf いじったり、ということはやらなくてもいいんですよ、ということです。

レプリケーション (耐障害性) について

自前で DB レプリケーションを行うのはめんどくさい！ まさにこういうところで DBaaS を使って楽することにしましょう。レプリケーションの目的は耐障害性向上・負荷分散がありますが、 まずは耐障害性向上から。

レプリケーション について

Amazon RDS では、シングル構成にするか、Multi-AZ 構成にするかを選択できます。Multi-AZ にすると、「同じリージョンかつ異なるアベイラビリティゾーン」に、 スレーブのインスタンスが用意され、データが同期され続けます。もしマスタに異常が発生した場合、スレーブに切り替わります。Multi-AZ を有効にした場合、インスタンスの料金は 2倍となります。

Azure SQL Database の場合、SQL Database を作成すると、 自動的にそのリージョンにてデータの 3重化が行われます。これは自動的に行われ、機能を OFF にすることはできません。また、フェイルオーバーも内部で自動的に行われます。内部的にはマスター・スレーブがあるのでしょうが、 外部からそれぞれの状況を知ることはできません。スレーブに接続することもできません。3重化は Azure 内部で行われていることなので、 3重化だから料金は 3倍です、ということはありません。

Google Cloud SQL の場合、 フェイルオーバーレプリカというものを作成できます。Amazon RDS でいう Multi-AZ と同じようなものと考えてよいです。

Amazon・Azure・GCP いずれも、目指しているのは下記です。「マスタで障害が発生した場合、アプリケーション側で何もしなくても、 少し (1〜2分) 待てばデータベースが復旧する」

Amazon RDS では Multi-AZ を有効にしないと SLA 対象となりません。Google Cloud SQL もフェイルオーバーレプリカを有効にしないと SLA 対象になりません。金額が倍になるのは痛いですが、あきらめましょう。

レプリカの個数 について

Amazon RDS では Multi-AZ を有効にするかしないか、のみ選択可能ですので、 個数は 0個または1個です。「Multi-AZ をさらに追加」ということはできません。

Azure SQL Database は、内部的に3重化です。外部から確認や設定変更は一切できません。

Google Cloud SQL は Amazon RDS と同様に、フェイルオーバーレプリカを作るか作らないかですので、 0個または1個です。

レプリカのリージョン について

Amazon RDS・Google Cloud SQL いずれも、レプリカはマスタと同じリージョンかつ、 異なるゾーンに配置します。Azure SQL Database は、内部的に3重化しており、外部から設定や確認は一切できませんが、 よい感じに配置してあるはずです。

レプリカのインスタンスサイズ指定 について

これは「マスタは Standard だけど、レプリカは Small にして費用を節約することができるか」 という意味で書きましたが、残念ながらできないようです。

上記レプリケーションへの通常時アクセス について

「レプリケーションは障害発生に備えたものであることはわかるけど、 障害が発生していないときはもったいないから、負荷分散にも使えないの?」 という意味で書きました。

Amazon RDS・Azure SQL Database ではそのような使い方はできません (レプリカに別 IP アドレスが振られていないので、通常時は接続できない)。(★Azure 読み取りスケールアウトでできる旨要追記)

Google Cloud SQL は、少なくとも別 IP アドレスが振られているのでもしかしたらできるかも… (★できるっぽい。要追記)

手動フェイルオーバー について

Amazon RDS と Google Cloud SQL のみ、手動フェイルオーバーが可能です。そもそもレプリケーションもフェイルオーバーも DBaaS の責任範囲ですので、 動作確認という意味はあまりありません。しかしながら何分くらいでサービス正常性が戻るのか確認しておくのはよいことだと思います。

メモ: CloudSQLの自動フェイルオーバーはマスターインスタンス障害時には発火しない 要調査 → 最新版では問題ないように見える

マルチマスタ について

要追記。

レプリケーション (負荷分散) について

続いては、負荷分散のためのレプリケーションです。

リードレプリカ について

リードレプリカとは、「マスタ→レプリカのレプリケーション設定をした上で、レプリカを読み取り専用とする」 というやり方です。

Amazon RDS・Azure SQL Database・Google Cloud SQL いずれもリードレプリカに対応しています。

Amazon RDS では、1つのマスタについて最大 5個のリードレプリカを作成できます。

Azure SQL Database では、 Premium と Business Critical サービスレベルのみですが、「読み取りスケールアウト」という機能が 2019/3 より使用可能となりました。SQL Database では自動的にレプリケーションが行われ3重化されますが、通常は 1つのインスタンスのみに接続します。残り 2つのインスタンスにリードオンリーで接続することで負荷分散を実現するというのが「読み取りスケールアウト」です。メリットは無料であること。もともと3重化されているものに接続しにいくので、お金がかからないわけですね。

Google Cloud SQL ではリードレプリカの制限はなく、「インスタンス上限40個」内であればいくつでも作れるようです (とりあえず 12個までは確認済)。

なお、読み取りのみの場合はレプリカを参照、更新が必要な場合はマスタに更新します。

任意リージョンへのリードレプリカ作成 について

「任意リージョンへのリードレプリカ作成」は、例えば「マスタ DB が日本にあるときに、 リードレプリカを米国などに作成できるか」です。Amazon RDS ではどのリージョンでも選択可能でした。Google Cloud SQL では、リードレプリカのリージョンは、マスタと同じリージョン固定でした。どうしてなんでしょうね。

リードレプリカでの低インスタンスサイズ について

「リードレプリカでの低インスタンスサイズ」は、「マスタは Standard だけど、レプリカは Small にして費用を節約することができるか」という意味ですが、Amazon RDS は可能です。

Google Cloud SQL では、MySQL は可能ですが、PostgreSQL では元のDB以上の CPU・メモリが必要です。

外部をマスタとしたリードレプリカ について

オンプレミスや、他クラウドサービスにマスタ DB を置いて、 クラウドサービス上の DBaaS をレプリケーションできるか、について。これが実現できると、オンプレミスの準リアルタイムバックアップや、 オンプレミス → クラウド DBaaS の移行が簡単になります。

Google Cloud SQL では、2018/7 より外部 MySQL をマスタとし、 Google Cloud SQL の MySQL をスレーブとする設定が可能となりました。

対応DB・対応バージョン

対応DB

下記はそれぞれのクラウドサービスが対応している RDBMS の比較表です。Amazon RDS の歴史が長いだけあって、対応している種類が多いですね。

MySQL は有名なオープンソースの RDBMS です。AWS・Azure・GCP いずれも利用可能です。

MariaDB は MySQL から分岐したオープンソース RDBMS です。MySQL AB 社がサン・マイクロシステムズに買収され、 その後サン・マイクロシステムズがオラクル社に買収された際、「Oracle Database で稼いでいるオラクル社が MySQL をつぶすのではないか」 と懸念する声があがり、MySQL 創始者が自ら MariaDB を立ち上げたもの。AWS・Azure で利用可能です。

Amazon Aurora は、Amazon が開発した高性能 DB で、「オーロラ」と読みます。Amazon 曰く、MySQL の 5倍、PostgreSQL の 3倍速いとのこと (本当かどうかは知らない)。2018/8 にサーバレス版の Aurora Serverless がリリースされました。さらに Aurora Multi Master (2019/5 現在、プレビュー) が控えており、まだまだ進化しそうです。Aurora が使えるのは AWS のみです。

PostgreSQL も MySQL に並び立つオープンソース RDBMS です。AWS・Azure・GCP いずれも利用可能です。

SQL Server は、マイクロソフト製の DB で、クラウド以前の 1990年代から存在します。Azure では DBaaS サービスとして「SQL Database」が利用可能です。これは SQL Server をベースとして開発された、Azure 上で動作する SQL Server 互換のサービスです (SQL Database と SQL Server は完全に機能が同じなわけではない)。また、Amazon RDS でも SQL Server が選択可能です。GCP においては 2019/4 に「Cloud SQL for Microsoft SQL Server」が発表されましたが、2019年中にサービス開始予定とのことです。

Oracle は、いわずと知れた Oracle Database です。一時期は AWS や Azure で比較的安価に利用できたのですが、近年は Oracle 社が自ら立ち上げた Oracle Cloud にシフトを進めています。

対応バージョン

Amazon RDS のみ、マイナーバージョンまで指定できます。2019/4 現在、MySQL の場合は下記を選択可能です。

• MySQL 8.0.11
• MySQL 5.7.23～5.7.16
• MySQL 5.6.41～5.6.34
• MySQL 5.5.61～5.5.46

Azure や GCP では、5.5、5.6、5.7 といったメジャーバージョンまでの指定となります。

特徴ふたつめ。Amazon RDS では、マイナーバージョンの自動バージョンアップを有効にするか否かを設定することができます。Azure や GCP では、強制的に自動バージョンアップがなされます。

メジャーバージョンアップ

マイナーバージョンアップ

複数 DB 統合管理

Azure SQL Database には Elastic Pool (エラスティックプール) という機能があります。これは、データベースそれぞれでインスタンスを立てるのではなく、 全体としてある程度のリソースを購入し、その中で複数のデータベースを動かすイメージです。

例えば、

• フロント用 DB … 日中帯に負荷が高まるが、夜間・早朝は負荷が低い
• バックエンド用 DB … 夜間・早朝のバッチ動作時に負荷が高まるが、日中帯は負荷が低い

などのように、異なる負荷特性を持つデータベースが複数ある場合や、

• 10個のデータベースがあり、それぞれ突発的に負荷が高まることがあるが、それ以外のほとんどは負荷が低い場合

というケースにて役立つでしょう。

料金・課金・コスト

料金 について

すごく比較が難しいのですが、

• Amazon RDS は、Multi-AZ だと 2倍
• Google Cloud SQL は、フェイルオーバーレプリカだと 2倍
• Azure SQL Database はデフォルト 3重化なので Multi-AZ・フェイルオーバーレプリカ相当の料金は「込み」といえる。
• Amazon RDS は、リザーブドインスタンスにすれば安くなる
• Google Cloud SQL は、継続利用割引があるので 1ヶ月使い続ければ 30% OFF

という前提で、 「MySQL や PostgreSQL で、1ヶ月間使い続ける、リザーブドインスタンスはやらない」 という条件とすると、GCP は Amazon RDS の約半額になるのではと思います。

なお、ストレージ料金について比較をしようとしてまとめたメモを下記に貼っておく (東京リージョン前提)。

[AWS]
 　Aurora
 　　ストレージ料金    0.12USD GB あたり/月
 　　I/O 料金    0.24USD/100 万件のリクエスト
 　MySQL・MariaDB・PostgeSQL・SQL Server・Oracle
 　　汎用(SSD)
 　　　シングルAZ: 0.138USD GB あたり/月
 　　　Multi-AZ: 0.276USD GB あたり/月
 　　プロビジョンド IOPS（SSD）ストレージ
 　　　シングルAZ
 　　　　・ストレージ料金    0.15USD GB あたり/月
 　　　　・プロビジョンド IOPS レート    0.12USD IOPS あたり/月
 　　　Multi-AZ
 　　　　・マルチ AZ ストレージ料金    0.30USD GB あたり/月
 　　　　・マルチ AZ プロビジョンド IOPS レート    0.24USD IOPS あたり/月
 　　Magnetic ストレージ
 　　　シングルAZ
 　　　　・ストレージ料金    0.24USD GB あたり/月
 　　　　・I/O 料金    0.12USD/100 万件のリクエスト
 　　　マルチAZ
 　　　　・ストレージ料金    0.12USD GB あたり/月
 　　　　・I/O 料金    0.12USD/100 万件のリクエスト
 [Azure]
 　付属ストレージ分はいくらなのか計算できない
 　超過ストレージ (プレビュー。プレビュー期間なので半額かもしれない)
 　　Standard: \0.0119/時間 (≒8.568円 GB あたり/月)
 　　Premium および Premium RS: \0.0237/時間 (≒17.064円 GB あたり/月)
 [GCP]
 　$0.22 per GB/month for SSD storage capacity
 　$0.12 per GB/month for HDD storage capacity
 　$0.10 per GB/month for backups (used)

なお、この他にネットワーク料金やバックアップストレージ料金の考慮も必要。

課金単位時間 について

Amazon RDS は 1秒単位の課金ですが、最低利用として 10分の課金がありますので、5分使ったら 10分、15分使ったら 15分の課金です。

Azure SQL Database は 1時間です。5分間だけ触ったとしても請求は 1時間分です。

GCP の Cloud SQL は 1分単位です。

インスタンス停止時の課金 について

開発環境や検証環境など、「たまにしかデータベースを使わない」「夜間土日は一切使わない」 というケースもあると思います。そのような場合、コスト削減のためにデータベースを停止したくなるでしょう。停止が可能な場合と、停止できない場合がありますので以下説明します。

Amazon RDS は停止が可能ではあるものの、 「SQL Server かつ Multi-AZ の場合は停止できない」 「リードレプリカが存在すると停止できない」 「SQL Server ミラーリングを使用している場合は停止できない」 という制限事項があります。また、停止できるのは最大7日で、7日を経過すると自動的に起動してしまいます。

ちなみに Amazon RDS の停止機能の変遷は以下のとおりです。

• 2009年のリリース時点では停止機能なし
• 2017/6 に停止機能が実装されたが、Multi-AZ は停止不可
• 2018/10 に Multi-AZ の停止機能を実装 (SQL Server 以外)

Azure SQL Database には、2017/12 現在も「停止」機能が実装されていません。大変よろしくないことと感じます。

GCP Cloud SQL は停止機能があります。ただし、「レプリカが存在する状況でマスタの停止はできない」 「リードレプリカやフェイルオーバーレプリカの停止はできない」ようです。中途半端な状態で停止するくらいなら削除しなさい、ということでしょうか。なお、停止したまま90日が経過すると自動削除されることに注意です。

なお、Amazon RDS・Cloud SQL とも「停止」するとインスタンス分の課金はされませんが、 「データ保持」のためのストレージ料金は必要ですのでご注意を。

課金単位 について

Amazon RDS・GCP Cloud SQL の課金単位は「インスタンス」です。例えば Amazon RDS では「db.m4.large」インスタンスを 1つだけ作り、 その中で “CREATE DATABASE” 的なことを行うことで、 1インスタンス内にデータベースを複数持つことができます。

一方、Azure SQL Database の課金単位は「データベース」です。”CREATE DATABSAE” 的なもので DB を 2個作ると、2個分の費用がかかります。(注: 2018/3 頃、SQL Database Managed Instance というサービスが始まり、 インスタンス単位での管理も選択可能となりました。要詳細追記)

無料枠について

Amazon RDS では、サービス利用開始から 12ヶ月間、

• db.t2.micro インスタンスでの MySQL, PostgreSQL, MariaDB, Oracle BYOL, SQL Server の Single-AZ 750時間/月
• SSD ストレージ 20GB

が無料となっています。31日×24時間＝744時間ですので、毎月 RDS を起動し続けておくことができます。なお、Aurora は無料枠対象ではありません。Oracle は BYOL (ライセンス持ち込み) のみです。

Azure Database では、サービス利用開始から 12ヶ月間、 S0 というインスタンスが無料で使えます。これは SSD 250GB を含みます。なお、S0 を複数個使ったらすべて無料になるかは明記されていませんが、誰か試してみてください。なお、対象は Azure Database のみであり、Azure Database for MySQL・Azure Database for PostgreSQL・Azure Database for MariaDB は対象外のようです。

GCP では Cloud SQL の無料枠というものはありませんが、12ヶ月有効な $300 のクレジットで実質無料使用ができます。

Amazon・Azure・GCP いずれのデータベースサービスも、12ヶ月を超えた場合の無料枠はないようです。

無料枠についてのさらなる情報は こちら

インスタンスサイズについて

Amazon・Azure・GCP とも、 自由にインスタンスサイズを選択することができ、後から変更することが可能です Amazon RDS・GCP はあらかじめ用意されているインスタンスサイズから選択する方式ですが、 なぜか Google Cloud SQL for PostgreSQL のみ、CPU とメモリの量を指定可能でした。Cloud SQL + MySQL でもそのうち指定可能になるんでしょうか。

Amazon RDS の vCPU 最大 128、メモリ最大 3,904GB は立派なものですが、対応 DB に注意が必要です。この vCPU・メモリに対応しているのは Oracle のみで、例えば MySQL・MariaDB・PostgreSQL は最大 96 vCPU、SQL Server は最大 64 vCPU のようです。

Azure SQL Database の場合、 価格表示 では、 CPU もメモリも記載がありません。代わりに下記のように「DTU」という表示があります。

Basic: DTU: 5 0.78円/時間
Standard S0: DTU: 10     2.33円/時間
Standard S1: DTU: 20     4.65円/時間
Standard S2: DTU: 50     11.65円/時間
 (略)
Premium P15: DTU: 4000  2,482.89円/時間

DTU とは “Database Transaction Unit” のことで、 CPU・メモリ・I/O を組み合わせた指標値と考えるとよいでしょう。Basic であれば DTU 5 ですが、Standard S2 であれば DTU 50 です。「Standard S2 は Basic の 10倍の処理能力を提供可能」と言ってよいです。

一方で、SQL を実行するたびに DTU を消費していきます。CPU もメモリもあまり使わない、I/O もほぼないような軽い SQL であればあまり DTU を消費しませんが、CPU もメモリも I/O もたくさんで 数分間かかるような SQL であればがっつり DTU を消費します。単位時間あたりの DTU を使い尽くしてしまった場合、待たされます。

Azure ポータル (管理画面) にて、DTU 使用率のグラフを簡単に見ることができるので、 DTU 不足と思った場合はインスタンスサイズをあげるなり、 SQL チューニングや Redis 等に逃がすなどの改善をしましょう。

バックアップ・リストアについて

バックアップ・リストアの基礎知識

まずはバックアップとリストアの基礎知識から。

すべての RDBMS では、データベースをフルバックアップすることができます。例えば MySQL なら mysqldump コマンドを使います。「1日1回や、週1回のフルバックアップがあればよい」 「フルバックアップ以降の更新分は失われてもよい」 ということであれば話は終了です。直近のフルバックアップを使ってリストアしてください、です。

とはいえ普通は「できるだけ最近のデータも救って」という話になるわけです。しかし、フルバックアップの頻度を1時間に1回、30分間に1回、10分に1回と頻度をあげていっても DB が重くなるだけです。そこで一般的には、フルバックアップ + ジャーナルファイル という組み合わせを使います。ジャーナルファイルは MySQL だとバイナリログ、Oracle だと REDO ログやアーカイブログと言いますが、 内容は「実行した SQL 文や、追加・更新したデータが実行時刻付きで時系列に並んでいるもの」と思ってください。

直近で取得したフルバックアップに対して、ジャーナルファイルをどんどん当て込んでいくことで、 最新のデータベースに近づいていくわけです。また、ある時刻でジャーナルファイルの適用を止めれば、「任意時刻時点のリカバリ」となります。以上、基礎知識おわり。

自動バックアップ

AWS・Azure・GCP いずれも、自動的にバックアップを取得して保存しておくことができます。取得タイミングは 1日1回や数時間に 1回などと決まっており、変更はできません。ただし、ジャーナルファイルがありますので、1日1回のバックアップだからといって、 最長24時間データが巻き戻ってしまうわけではありません (ただしバックアップ頻度が長すぎると、 リストア時に時間がかかってしまう)。

このときのバックアップがフルバックアップであるか、 フルバックアップ + ジャーナルファイルであるかは、気にする必要がありません。例えば管理画面上からは「2018/06/14 18:30:11 時点のバックアップ」として見えているものが、 フルバックアップかもしれないし、フルバックアップにジャーナルファイルを当て込んで生成されるものかもしれないが、気にしなくてよいということです。

自動バックアップ保存期間

自動バックアップしたデータは、上記の日数の間、保存されます。例えば保存期間が 7日である場合、7日前のデータに戻すことはできるが、8日前に戻すことはできません。ただし、手動でバックアップを取得する方法がありますので、 手動バックアップであれば 1ヵ月間でも 1年間でも保存しておくことができます (その分、コストはかかります)。

任意時点のデータ復元

いずれのサービスも、自動バックアップ保存期間内であれば、任意時点のデータを復元することが可能です。

「バックアップウィンドウ」について

Amazon RDS・Google Cloud SQL では、日次バックアップを行う時間帯 (ウィンドウ) を指定することができます。Amazon は 30分幅、GCP は 4時間幅です。一般的には朝方など、利用者の少ない時間帯を指定しておくとよいでしょう。ただし Amazon RDS で Multi-AZ を有効にしている場合、待機系であるスレーブからバックアップを取得するため、 マスタへの負荷の影響はほぼないと見てよいでしょう。

Azure SQL Database では、バックアップの時間帯は指定できないようです。

「任意タイミングでスナップショット生成」について

ストレージについて

どのサービスも最大数TB程度はいけるようです。

AWS の場合、通常の RDS のストレージに SSD や HDD を選択した場合、容量は最低 5GB、最大 数TB 程度ですが、「プロビジョンドIOPS (SSD)」を選択すると容量が最低 100GB、最大 32TB と一気に広がります (SQL Server は最低 20GB、最大 16TB)。

ストレージ容量の自動拡張について

Amazon RDS・Google Cloud SQL は「容量自動拡張」を持っています。データを保存するストレージが不足した場合、勝手に拡張してくれます。

ただし気づかない間にどんどん容量が増えてコストが増えてしまうのは困るというケースもあるでしょうから、 Amazon RDS・Google Cloud SQL いずれも自動拡張の ON/OFF や、自動拡張時の上限容量設定が可能です。

Azure SQL Database は、選択したサービスレベル (Basic・Standard S0, S1, S2 など) ごとに上限が決まっていて、その枠内ならば自由に使えます。それを超える場合は、上位サービスレベルの変更が必要になります。

その他管理

メンテナンスウィンドウ

Oracle Database

Oracle Database は、「Amazon RDS for Oracle」というサービス名称で、 Amazon RDS のみでサポートされています。対象バージョンは下記のとおりです。

• 11.2 (11g リリース 2)
• 12c

対応エディションは以下のとおりです。

• BYOL (持ち込み) の場合:
  • Standard Edition Two (SE2)
  • Standard Edition One (SE1)
  • Standard Edition (SE)
  • Enterprise Edition (EE)
• ライセンス込みの場合:
  • Standard Edition Two (SE2)
  • Standard Edition One (SE1)

Amazon RDS for Oracle では、RAC はサポートされていません。また、その他の Enterprise のオプション、

• Oracle Active Data Guard
• Oracle Advanced Analytics
• Oracle Advanced Compression
• Oracle Advanced Security
• Oracle Database Vault
• Oracle Label Security
• Oracle On-Line Analytical Processing (OLAP)
• Oracle Partitioning
• Oracle RAC One Node
• Oracle Real Application Clusters (Oracle RAC)
• Oracle Real Application Testing
• Oracle Spatial and Graph
• Oracle TimesTen Application-Tier Database Cache

について、Advanced Compression や Advanced Security などの一部オプションは BYOL (持ち込み) モデルではサポートされていると FAQ に書いてありますが、逆に言うと、ライセンス込みモデルでは サポートされていない? いずれにせよ全オプションが利用可ではないようなので、注意が必要です。

以前 Azure には Oracle Database ライセンス込みの VM があったのですが、 2016/05 に終了となったようです。Marketplace での提供はなされているので、使えなくなったわけではありません。

なお、RDS 等の DBaaS を使わず、仮想マシン (Amazon EC2、Azure VM、GCP Compute Engine) に、 自分で Oracle Database をインストールするという前提であれば、いずれも動作するはずです。

TODOメモ

• Azure: DTU だけではなく、vCore 単位での課金タイプもある。
• Azure: Premium で 4重化
• Azure: アクティブ geo レプリケーション は手動フェイルオーバー可能
• Azure: https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-planned-maintenance の「 再構成/フェールオーバーは、通常、30 秒以内に完了します (平均は 8 秒)」「平均すると、1 か月に 1.7 回の計画メンテナンス イベントが発生します。」 を追加
• Azure: バックアップ10年保存
• Azure: マネージドインスタンス
• GCP: MySQL はフェイルオーバーレプリカをリードレプリカとして使用可能ではないか。PostgreSQL ではできないように見える。