AWSのRDS・Aurora・DynamoDBの違いと選び方【クラウド入門第10回】

「RDS をマルチ AZ にしたので、待機しているスタンバイのほうに月末のレポートのクエリを流して、本番の負荷を減らしたいと思います。スタンバイの接続先はどこですか」
「RDS のフェイルオーバーを訓練してみたら、DB は1〜2分で切り替わったのに、アプリが10分以上つながらないままでした。何が悪いのでしょう」

第8回と第9回では、IAM と KMS・Secrets Manager・ACM などのセキュリティのサービスを見ました。オンプレの DB サーバーでは、インストール、パッチ、バックアップ、レプリケーション、フェイルオーバー、監視と、多くの作業を自分たちで行ってきました。AWS には、これらを AWS が引き受けるマネージドのデータベースがあり、RDB の RDS と Aurora、NoSQL の DynamoDB を中心に、用途ごとのサービスがそろっています。ただし、任せられることと任せられないことの境目を知らないと、冒頭のような思い違いが起きます。

第10回では、マネージド DB の考え方、RDS の概要、マルチ AZ による可用性、リードレプリカとスケーリング、Aurora、DynamoDB、そのほかのデータベース・分析サービス、RDB と NoSQL の使い分け、バックアップと災害対策（DR）、DB への接続とセキュリティ、そして Azure との対応を扱います。数値・料金は2026年9月時点のものです。

マネージド DB という考え方
RDS（Relational Database Service）の概要
RDS の可用性：マルチ AZ
リードレプリカとスケーリング
Amazon Aurora
Amazon DynamoDB
その他のデータベース・分析サービス
RDB と NoSQL の使い分け
バックアップと災害対策（DR）
DB への接続とセキュリティ
Azure との対応表：データベース
考えてみよう
まとめ
連載「クラウド入門」全14回

マネージド DB という考え方

RDB の運用には、インストール、パッチ適用、バックアップ、レプリケーション、フェイルオーバー、監視、容量管理と、多くの作業が伴います。EC2 に MySQL を入れて動かすこともできますが（IaaS）、それらはすべて自分で行うことになります（RDB の運用の作業は、このブログの連載「RDB・SQL入門」第12回「バックアップと移行」・第13回「レプリケーションと冗長化」・第14回「監視と日々の運用」で詳しく扱います）。

RDS のようなマネージド DB では、OS とエンジンのパッチ適用はメンテナンスウィンドウで AWS が行い、バックアップは自動で日次に取得され、待機系への同期レプリケーションと障害時の切り替えは設定ひとつで有効になります。代わりに OS へのログインはできず、エンジンのパラメータは「パラメータグループ」経由でしか変えられず、一部の拡張機能や OS レベルのチューニングは使えません。

判断の基準は「その DB の運用に自社の付加価値があるか」です。多くの業務システムでは付加価値が無いため、AWS の Well-Architected（第13回）でも「差別化に繋がらない重労働（undifferentiated heavy lifting）はマネージドに任せる」ことを原則に挙げています。ライセンスの面では、Oracle と SQL Server はライセンス込み（LI）と持ち込み（BYOL）を選べ、Windows 版 SQL Server の CAL の考え方は不要になります。

左の枠「EC2 に自前構築（IaaS）」は上から「アプリ・スキーマ・SQL」「バックアップ／PITR」「レプリケーション・フェイルオーバー」「DB エンジンのパッチ」「OS のパッチ・監視エージェント」「インストール・容量管理」が利用者の担当（青）、「HW・仮想化・DC」だけが AWS の担当（橙）、右の枠「RDS（マネージド）」は「アプリ・スキーマ・SQL」だけが利用者の担当で、「自動バックアップ／PITR」「マルチ AZ・自動フェイルオーバー」「メンテナンスウィンドウで適用」「OS は見えない（AWS）」「作成ウィザード・自動拡張」「HW・仮想化・DC」が AWS の担当、凡例「■ 利用者」「■ AWS」、下に太字で「判断基準：その DB 運用に自社の付加価値があるか。無ければ「差別化に繋がらない重労働」として任せる（Well-Architected）」、灰色で「代償：OS ログイン不可、パラメータグループ経由の設定、一部拡張機能の制限。Oracle／SQL Server は LI か BYOL」とあり、自前構築とマネージド DB の責任の分担を示す図

パッチ・バックアップ・フェイルオーバー・監視を AWS が担う
代わりに OS ログイン不可、パラメータグループ経由の設定
「自社に付加価値のない運用」は任せる。Oracle/SQL Server は LI／BYOL

RDS（Relational Database Service）の概要

RDS の主な項目です。オンプレの DB サーバーの設定項目が、どこに当たるかを見てください。

項目	内容
エンジン	MySQL、MariaDB、PostgreSQL、Oracle、SQL Server、Db2（2023 年追加）
インスタンス	`db.m7g.large` のように EC2 と同じ体系（db. 付き）。メモリ最適化（db.r）、バースト（db.t）
ストレージ	gp3／io1／io2（EBS と同じ）。ストレージ自動スケーリングで閾値到達時に自動拡張
ネットワーク	VPC のサブネットグループに配置。エンドポイントは DNS 名（`xxx.abcdef.ap-northeast-1.rds.amazonaws.com`）。IP は変わり得るので名前で接続
認証	エンジンのユーザー＋パスワード、IAM データベース認証（トークン、MariaDB/MySQL/PostgreSQL）、Kerberos（Managed AD 連携）
バックアップ	自動（保持 0〜35 日、PITR 可）＋手動スナップショット（無期限）
パッチ	メンテナンスウィンドウ（週 30 分）。マイナーバージョン自動適用は選択可、メジャーは手動
設定	パラメータグループ（`my.cnf`／`postgresql.conf` 相当）、オプショングループ（Oracle/SQL Server の追加機能）
監視	CloudWatch（CPU、接続数、IOPS、空き容量）、CloudWatch Database Insights（旧 Performance Insights。待機イベント・SQL 単位の負荷）、拡張モニタリング（OS レベル）
追加	RDS Proxy（接続プーリング。Lambda からの大量接続対策）、Blue/Green デプロイ（メジャーアップグレードを別環境で検証して切替）

RDS の可用性：マルチ AZ

RDS の可用性は、AZ をまたいだ構成で確保します。

マルチ AZ DB インスタンス：別の AZ に同期レプリケーションのスタンバイを持つ。スタンバイは読めない。障害・メンテナンスのときに DNS のエンドポイントが自動で切り替わる（60〜120秒）。アプリは同じ DNS 名に再接続するだけ
マルチ AZ DB クラスター（MySQL/PostgreSQL）：1ライター＋2リーダーを3つの AZ に置き、準同期レプリケーションを行う。フェイルオーバーは35秒程度で、リーダーは読み取りに使える。書き込みの遅延も従来のマルチ AZ より小さい
シングル AZ：検証用。AZ の障害・メンテナンスで止まる。本番では使わない
フェイルオーバーは強制実行（aws rds reboot-db-instance --force-failover）で訓練できる。アプリ側の再接続処理と DNS のキャッシュ（JVM の TTL など）が切り替えの時間を左右する
レプリケーションの同期／非同期の違いが、「マルチ AZ（同期＝可用性）」と「リードレプリカ（非同期＝性能）」の区別にそのまま効いてくる（同期・非同期のレプリケーションは連載「RDB・SQL入門」第13回で詳しく扱います）

冒頭の1つ目の相談の答えがここにあります。マルチ AZ DB インスタンスのスタンバイは読めないので、レポートを流す先にはなりません。読み取りを逃がしたいなら、次の節のリードレプリカか、リーダーを読めるマルチ AZ DB クラスターを使います。

冒頭の2つ目の相談もここです。DB が切り替わっても、アプリが古い IP アドレスをキャッシュしていれば、つながらないままです。Java では JVM が名前解決の結果を長く覚えていることがあり、networkaddress.cache.ttl を短く（例：数十秒）するのが定番です。接続プールの再接続の設定も合わせて確かめます（DNS のキャッシュと TTL の考え方は、このブログの連載「DNS入門」第3回の「キャッシュとTTL」で詳しく扱っています）。

$ aws rds reboot-db-instance --db-instance-identifier app-db --force-failover
$ dig +short app-db.abcdef.ap-northeast-1.rds.amazonaws.com    # 切り替えの前後で IP が変わる

枠「リージョン」の中に「AZ a」と「AZ c」、AZ a に「プライマリ（読み書き）」と、その下のアプリから「DNS 名で接続」の矢印、プライマリから AZ c の「スタンバイ（読めない）」へ「同期レプリケーション」の矢印、AZ c に「障害・保守時：エンドポイントの DNS が自動でスタンバイへ（60〜120 秒）。アプリは再接続するだけ」、下の枠「マルチ AZ DB クラスター（MySQL／PostgreSQL）」に「1 ライター」「リーダー 1」「リーダー 2」と「準同期・3 AZ」「フェイルオーバー約 35 秒」「リーダーは読める」、その下に太字で「マルチ AZ ＝可用性（同期・読めない）／リードレプリカ＝性能（非同期・読める）を混同しない」、最下段に「訓練：reboot-db-instance --force-failover。切替時間はアプリの再接続処理と DNS キャッシュ（JVM の TTL 等）で決まる」とあり、RDS のマルチ AZ の構成を示す図

リードレプリカとスケーリング

リードレプリカは、非同期レプリケーションで作る読み取り専用の複製で、参照系のクエリ（レポート、検索）を分散して、書き込み側の負荷を下げるのが目的です。マルチ AZ のスタンバイが「可用性のため・読めない」のに対し、リードレプリカは「性能のため・読める・遅延がある」という違いを混同しやすいので注意しましょう。

MySQL/PostgreSQL で最大15台、別のリージョンにも作れるため、リージョンの障害のときにレプリカを昇格させて DR にも使えます（ただし非同期なので直前のデータは失われ得ます。RPO は秒〜分です）。スケールアップ（インスタンスクラスの変更）はオンラインではなく、短時間の停止を伴います（マルチ AZ ならスタンバイ側から順に変えて、停止時間を短くできます）。

垂直方向の上限に当たる前に、読み取りはレプリカへ、接続数は RDS Proxy で、キャッシュは ElastiCache（この回の「その他のデータベース・分析サービス」）で逃がすのが定石です。書き込みそのものの水平分割（シャーディング）は、Aurora Limitless や DynamoDB の領域になります。

上段で「プライマリ（読み書き）」から「非同期」の矢印が「リードレプリカ 1」へ、もう1本の「非同期」の矢印が下の「リードレプリカ 2（別リージョン可）」へ伸び、右の「レポート・検索」から「参照を分散」の矢印がリードレプリカ 1 へ、下の「書き込み」から矢印がプライマリへ向かう。その下に「別リージョンのレプリカを昇格すれば DR に（非同期なので RPO は秒〜分）」、枠「混同しやすい 2 つ」に青の「マルチ AZ スタンバイ同期・読めない・可用性のため」と橙の「リードレプリカ非同期・読める・性能のため」、枠「書き込みの限界に当たったら」に「RDS Proxy 接続プーリング」「ElastiCache キャッシュ」「Aurora ストレージ分散」「DynamoDB 水平分割」の4つが並ぶ、リードレプリカと書き込みの拡張の方法を示す図

非同期の読み取り専用の複製。性能の分散が目的（マルチ AZ は可用性）
最大15台、クロスリージョン可。昇格で DR にも使える（RPO あり）
書き込みの限界は RDS Proxy・キャッシュ・Aurora・NoSQL で対処

Amazon Aurora

Aurora は、AWS が設計した RDB です。

AWS が設計した MySQL 互換／PostgreSQL 互換の RDB。エンジンの SQL 層は互換で、ストレージ層を分散システムに置き換えたのが本質
ストレージは 3 AZ に6コピーを自動で持ち、書き込みは 4/6 のクォーラムで確定。最大 256 TiB（2025年7月に 128 → 256 TiB に拡張。対応するバージョンへの更新が必要）まで自動で拡張し、使った分だけ課金
インスタンスはストレージを共有するため、リードレプリカ（最大15台）の遅延は通常 100 ms 以下、フェイルオーバーは30秒以内。ライターエンドポイントとリーダーエンドポイント（負荷分散）を使い分ける
Aurora Serverless v2：ACU（0.5〜256）単位で秒単位に自動スケール。2024年11月からゼロまで縮退（アイドルのときは停止）できる。開発環境・変動する負荷に
Global Database：別のリージョンに1秒未満の遅延で複製し、リージョンの障害のときは1分以内に昇格
Aurora DSQL（2025年 GA）：PostgreSQL 互換の分散サーバーレス DB。マルチリージョンでアクティブ／アクティブ。従来の Aurora とは別物
費用は同じスペックの RDS より2割程度高いが、I/O 課金なしの「I/O 最適化」構成もある。可用性・性能の要件が高ければ Aurora、コスト最優先や Oracle/SQL Server なら RDS を選ぶ

枠「リージョン（3 AZ）」の中に「ライター」「リーダー 1」「リーダー 2〜15」が並び、ライターから「書き込み」の矢印、3つとも下の紫の枠「共有ストレージ：6 コピー／3 AZ、4/6 クォーラムで確定、最大 256 TiB 自動拡張」（6つの丸）につながり、その下に「ライター／リーダー（負荷分散）の 2 エンドポイント。レプリカ遅延は通常 100 ms 以下、フェイルオーバー 30 秒以内。費用は同スペック RDS より 2 割程度高い（I/O 最適化構成あり）」、左下の緑の枠「Aurora Serverless v2」に「ACU 0.5〜256 を秒単位で自動増減。2024-11〜ゼロまで縮退可」、右下の枠「Global Database」に「別リージョンへ 1 秒未満で複製、リージョン障害時 1 分以内に昇格」、最下段の枠「Aurora DSQL（2025 GA）」に「PostgreSQL 互換の分散サーバーレス DB。マルチリージョンアクティブ／アクティブ。従来の Aurora とは別物」とあり、Aurora の共有ストレージと派生のサービスを示す図

Amazon DynamoDB

DynamoDB はフルマネージドの NoSQL（キーバリュー／ドキュメント型）のデータベースで、サーバー・容量の管理が無く、テーブルを作れば即使えます。データは「パーティションキー」（＋任意の「ソートキー」）で格納され、キーによる読み書きはデータ量に関係なく1桁ミリ秒で応答します。

RDB が得意な JOIN・トランザクション・アドホックな集計は不得手で、アクセスパターンを先に決めてからテーブルを設計します（RDB とは逆の順序です。RDB の結合とトランザクションは連載「RDB・SQL入門」第3回・第6回、NoSQL の分類は第15回で扱います）。1項目は最大 400 KB で、キー以外の検索には GSI（グローバルセカンダリインデックス）を作ります。課金はオンデマンド（リクエスト数）かプロビジョンド（RCU/WCU を確保）で、常時の無料枠 25 GB があります（2026年9月時点）。

付随する機能として、TTL（期限切れの項目の自動削除）、Streams（変更を Lambda へ流す）、Global Tables（マルチリージョンのアクティブ／アクティブの複製）、PITR、DAX（インメモリキャッシュ）があります。Amazon.com の買い物かごを支える技術として2012年に登場し、セッション管理、IoT のテレメトリ、ゲームのランキング、Lambda のバックエンドといった「大量・単純・低遅延」の用途で標準的に使われています。

左上の「テーブル」の箱の右に表「パーティションキー｜ソートキー｜属性（スキーマ柔軟）」があり、行は「userId=u1 ｜ 2026-09-16T10:00 ｜ {cart:[…], total: 3200}」「userId=u1 ｜ 2026-09-16T11:30 ｜ {cart:[…]}」「userId=u2 ｜ 2026-09-15T09:00 ｜ {…}（1 項目最大 400 KB）」、その下に太字で「キー指定の読み書き → データ量に関係なく 1 桁 ms。アクセスパターンを先に決めてから設計（RDB と逆順）」、中段の左の緑の枠「向く」に「セッション、買い物かご、IoT テレメトリ」「大量・単純・低遅延」「Lambda のバックエンド」「水平スケール（上限なし）」、右の赤い枠「不得手」に「JOIN、集計、アドホック検索」「複雑なトランザクション」「既存の SQL アプリの移行」、下段に「Streams → Lambda」「GSI（別キー検索）」「DAX（キャッシュ）」「Global Tables（多リージョン）」、最下行に「課金：オンデマンド（リクエスト数）／プロビジョンド（RCU・WCU 確保）。常時無料枠 25 GB。TTL・PITR・暗号化は標準機能」とあり、DynamoDB のデータの形と向き不向きを示す図

キーバリュー型。キー検索は量に関係なく1桁 ms
アクセスパターン先行の設計。JOIN・集計は不得手
オンデマンド／プロビジョンド課金。Global Tables で多リージョン

その他のデータベース・分析サービス

RDS・Aurora・DynamoDB 以外にも、用途ごとのサービスがあります。

サービス	種別	互換／用途
ElastiCache	インメモリキャッシュ	Valkey（Redis 互換、2024 年〜。Redis のライセンス変更を受けた OSS フォーク）／Redis OSS／Memcached。セッション、ランキング、DB の前段キャッシュ
MemoryDB	永続化付きインメモリ	Valkey/Redis 互換で耐久性あり。プライマリ DB として使える
Redshift	データウェアハウス（列指向）	PostgreSQL 系 SQL。大量データの集計・BI。Serverless あり
Athena	S3 上のデータへの SQL	サーバーレス。スキャン量課金。ログ分析の第一選択
OpenSearch Service	全文検索・ログ分析	Elasticsearch 互換（フォーク）。syslog などのログ基盤の受け皿
DocumentDB	ドキュメント DB	MongoDB 互換
Neptune	グラフ DB	Gremlin／SPARQL／openCypher
Keyspaces	ワイドカラム	Apache Cassandra 互換
Timestream	時系列 DB	IoT・メトリクス
DMS（Database Migration Service）	移行ツール	オンプレ → RDS/Aurora の継続的レプリケーション、異種 DB 変換（SCT）

「S3 に置いて Athena で SQL」は、ログ調査の最も安い基盤として覚えておきましょう。ログを集約して検索する流れが、CloudWatch Logs → S3 → Athena で実現できます（ログの検索基盤は、このブログの連載「syslog入門」第8回の「検索基盤とは」と、第9回の「S3への保管とAthenaでの検索」で詳しく扱います）。

なお、Timestream のうち Timestream for LiveAnalytics は、2025年6月から新しい顧客は使えなくなりました（AWS の発表による）。新しく時系列 DB を選ぶときは、Timestream for InfluxDB を確かめてください。

RDB と NoSQL の使い分け

RDS／Aurora と DynamoDB を、観点ごとに比べます。

観点	RDS／Aurora	DynamoDB
データモデル	正規化されたテーブル、スキーマ固定	キーと属性、スキーマ柔軟
クエリ	SQL、JOIN、集計、アドホック検索	キー指定、インデックス経由の限定的な検索
整合性・トランザクション	ACID、複雑なトランザクション	単項目は強整合可、トランザクションは限定的
スケール	垂直＋読み取りの水平（レプリカ）	水平（自動パーティション）。上限は実質なし
遅延	ms〜（クエリ次第）	1 桁 ms（一定）
運用	パラメータ・インデックス・接続数の管理	キャパシティ設計（オンデマンドなら不要）
費用の性質	インスタンス時間（常時）	リクエスト数＋容量（アイドル時は安い）
向く例	会計、在庫、ERP、既存の SQL アプリ	セッション、カート、IoT、Lambda のバックエンド

「新しいから NoSQL」「慣れているから RDB」ではなく、アクセスパターンとデータ間の関係の複雑さで決めましょう。1つのシステムで、注文は Aurora、セッションは DynamoDB、検索は OpenSearch のように併用する（ポリグロット・パーシステンス）のが普通です。

バックアップと災害対策（DR）

DB のバックアップと、リージョンの障害への備えです。

自動バックアップ：日次のスナップショット＋5分ごとのトランザクションログで、保持期間（最大35日）内の任意の秒にポイントインタイムリカバリ（PITR）。復元は「新しいインスタンスを作る」形（既存を上書きしない）
手動スナップショット：保持は無期限。別のリージョン・別のアカウントへコピーできる。KMS で暗号化したスナップショットをクロスアカウントで共有するには、鍵の共有も必要
AWS Backup（第5回）で RDS/Aurora/DynamoDB もポリシーで管理し、Vault Lock で削除から守る
DR の段階（RPO/RTO で整理）：
- バックアップ＆リストア（RPO 時間、RTO 時間〜）：スナップショットを別のリージョンへコピー
- パイロットライト（RPO 分、RTO 数十分）：クロスリージョンのリードレプリカを最小構成で待機
- ウォームスタンバイ（RPO 秒〜分、RTO 分）：Aurora Global Database＋縮小した AP 層
- マルチサイト・アクティブ／アクティブ（RPO ほぼ0）：DynamoDB Global Tables、Aurora DSQL
復元テストを定期的に行う。「バックアップは取れていたが、復元の手順が無かった」が最も多い失敗

RPO・RTO の決め方は、このブログの連載「バックアップ入門」第2回の「RPO・RTO と SLA の決め方」で、RDS のポイントインタイムの復元と AWS Backup は第9回の「RDS をポイントインタイムで戻す」「別アカウント・別リージョンへのコピー」で詳しく扱います。

上から4つの枠が並ぶ。「① バックアップ＆リストア RPO 時間／RTO 時間〜」に「スナップショット・AWS Backup を別リージョンへコピー。最安。復元に時間」、「② パイロットライト RPO 分／RTO 数十分」に「クロスリージョンリードレプリカ＋最小構成の AP。障害時に拡張して昇格」、「③ ウォームスタンバイ RPO 秒〜分／RTO 分」に「Aurora Global Database＋縮小した AP 層を常時稼働。Route 53 で切替」、橙の枠「④ マルチサイトアクティブ／アクティブ RPO ≒ 0」に「DynamoDB Global Tables／Aurora DSQL。両リージョンで同時稼働。最も高価で複雑」、最下行に太字で「下へ行くほどコストと複雑さが増す。RPO／RTO（連載「バックアップ入門」）を先に決めて段を選ぶ。復元テストは定期的に」とあり、DR の4つの段階を示す図

DB への接続とセキュリティ

DB をどこに置き、どう接続させるかです。

配置：プライベートサブネット、パブリックアクセスは「なし」。SG は AP 層の SG からだけエンジンのポート（3306/5432/1433/1521）を許可（第6回の SG のルール例）
認証情報：マスターパスワードは Secrets Manager での管理を選ぶ（自動ローテーション）。アプリは起動時に Secrets Manager から取得する。IAM DB 認証なら15分有効のトークンでパスワードが要らない（MariaDB/MySQL/PostgreSQL。接続数の多い用途には不向き）
Kerberos 認証：Managed AD と連携し、Windows 統合認証で SQL Server／PostgreSQL に接続（このブログの連載「Kerberos入門」第12回の「クラウドの Kerberos」で詳しく扱います。そこでは MySQL・Oracle・Db2 も挙げています。Managed AD は連載「Active Directory入門」第13回）
通信の暗号化：RDS は TLS に対応。require_secure_transport（MySQL）／rds.force_ssl（PostgreSQL）で強制する。証明書は RDS の CA バンドル（rds-ca-rsa2048-g1 など。2024年に旧 CA から更新）を信頼する（信頼ストアの考え方は、このブログの連載「証明書入門」第5回の「信頼ストア」で詳しく扱っています）
監査：エンジンの監査ログ（MySQL の MariaDB Audit Plugin、PostgreSQL の pgAudit、SQL Server の Audit）を CloudWatch Logs へ出力。API の操作は CloudTrail
削除保護と最終スナップショット：本番は削除保護を有効にする。削除のときに最終スナップショットを取る設定を既定にする
接続の確認：TLS を必須にして接続する

$ mysql -h xxx.rds.amazonaws.com -u admin -p --ssl-mode=REQUIRED
$ psql "host=xxx sslmode=require"

紫の枠「VPC」の中に上下に2つのサブネットがあり、上の「プライベート AP サブネット」で「Secrets Manager」から「パスワード取得」の矢印が「アプリ」へ、アプリから「TLS・3306 from sg-app」の矢印が下の「プライベート DB サブネット」の「RDS（パブリックアクセス：なし）」へ、同じサブネットの「Managed AD（Kerberos 認証）」から矢印が RDS へ向かう。下の枠「認証の選択肢」に「エンジンのユーザー＋パスワード（Secrets Manager で自動ローテーション）」「IAM DB 認証：15 分有効トークン（MySQL／PostgreSQL。接続数が多い用途には不向き）」「Kerberos：Windows 統合認証（SQL Server／PostgreSQL → 連載「Kerberos入門」）」、最下段の枠「運用」に「CA バンドル rds-ca-rsa2048-g1 等を信頼（2024 年に旧 CA から更新 → 連載「証明書入門」）」「監査ログ（pgAudit 等）→ CloudWatch Logs。API 操作は CloudTrail」「削除保護＋最終スナップショット取得を既定に」とあり、DB の配置と接続・認証を示す図

Azure との対応表：データベース

Azure のデータベースとの対応です。

AWS	Azure	補足
RDS for MySQL／PostgreSQL	Azure Database for MySQL／PostgreSQL（Flexible Server）	Azure も「ゾーン冗長 HA」でマルチ AZ 相当
RDS for SQL Server	Azure SQL Database（PaaS）／SQL Managed Instance（互換性重視）／SQL Server on VM	Azure は SQL Server の選択肢が 3 段階
RDS for Oracle	（相当なし。Oracle Database@Azure は Oracle が OCI を Azure DC 内で提供）
Aurora	Azure SQL Database Hyperscale／Cosmos DB for PostgreSQL	明確な 1:1 は無い
DynamoDB	Azure Cosmos DB（NoSQL API、Table API）	Cosmos DB は複数 API（MongoDB、Cassandra、Gremlin も）
ElastiCache	Azure Managed Redis	Azure Cache for Redis は廃止予定（Basic・Standard・Premium は2028年9月30日、Enterprise は2027年3月31日）
Redshift	Azure Synapse Analytics／Microsoft Fabric
Athena	Synapse Serverless SQL／Fabric
OpenSearch	Azure AI Search（用途は一部）
DMS	Azure Database Migration Service
Secrets Manager（RDS 連携）	Key Vault

なお、Azure Cosmos DB for PostgreSQL は廃止に向かっており、新しいプロジェクトには勧められていません。Microsoft は、PostgreSQL の分散には Azure Database for PostgreSQL の Elastic Clusters を案内しています。

考えてみよう

手元の RDS は、マルチ AZ DB インスタンス・マルチ AZ DB クラスター・シングル AZ のどれですか。レポートのクエリをどこへ流すのがよいか、冒頭の1つ目の相談に沿って考えてください
アプリが Java なら、JVM の DNS キャッシュの設定（networkaddress.cache.ttl）と接続プールの再接続の設定を確かめ、--force-failover の訓練で切り替わるまでの時間を測ってください
次のデータは RDS／Aurora と DynamoDB のどちらに置きますか。①受注と在庫、②ログイン中のセッション、③月次の売上の集計。DR の段階は、それぞれ RPO・RTO から選んでください

ヒント：1は「RDS の可用性：マルチ AZ」と「リードレプリカとスケーリング」、2は「RDS の可用性：マルチ AZ」、3は「RDB と NoSQL の使い分け」と「バックアップと災害対策（DR）」の節を見直してください。