助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 38383
問題を開く
ある企業は、ALBの背後でEC2インスタンスを使用してアプリケーションを開発しており、データはMySQLデータベースに保存する必要がある。データベースは高い可用性を確保し、読み取りのパフォーマンスを向上させることが求められている。さらに、障害が発生した場合でも、高速なフェイルオーバーでアプリケーションのダウンタイムを最小限に抑えたい。これらの要件を最も効率的に満たすソリューションはどれか。
正解
マルチAZ DBクラスター構成されたRDS for MySQLデータベースを作成する
解説
Amazon RDSのマルチAZ DBクラスターは、マルチAZ構成の新しい高可用性オプションです。従来のマルチAZ構成とは異なり、3つのアベイラビリティゾーンにまたがって配置されるため、可用性がさらに強化されています。また、従来のマルチAZ構成ではスタンバイインスタンスにアクセスできませんが、マルチAZ DBクラスターでは2つのスタンバイインスタンスがリードレプリカとしても機能し、読み取りアクセスが可能です。プライマリーインスタンスへの書き込みは、残り2台のリードレプリカに準同期レプリケーションされます。さらに、フェイルオーバー時には通常35秒未満で切り替わるため、アプリケーションのダウンタイムを最小限に抑えることができます。
[マルチAZ DBクラスターのイメージ図]

したがって、正解は
・マルチAZ DBクラスター構成されたRDS for MySQLデータベースを作成する
です。
それ以外の選択肢は、以下の通りです。
・マルチAZ構成されたRDS for MySQLデータベースを作成する
マルチAZ構成されたRDSは高可用性に優れていますが、リードレプリカが設置されておらず、読み取りパフォーマンスに限界がありますので、誤りです。
・EC2インスタンスにMySQLをセットアップする。EBSのスナップショットを使用してバックアップとリストアを自動化し、データの整合性を保つ
EBSのスナップショットはバックアップには適していますが、フェイルオーバーや高可用性に対応していませんので、誤りです。
・Aurora MySQLをシングルAZ構成でデプロイし、Auroraのリードレプリカを使用して読み取りパフォーマンスを向上させる
AuroraはシングルAZ構成でもリードレプリカを使ってフェイルオーバーが可能です。しかし、AZ全体が障害を起こした場合、フェイルオーバー先がなくなるため、マルチAZ構成ほど高い可用性は確保できません。よって、誤りです。
[マルチAZ DBクラスターのイメージ図]

したがって、正解は
・マルチAZ DBクラスター構成されたRDS for MySQLデータベースを作成する
です。
それ以外の選択肢は、以下の通りです。
・マルチAZ構成されたRDS for MySQLデータベースを作成する
マルチAZ構成されたRDSは高可用性に優れていますが、リードレプリカが設置されておらず、読み取りパフォーマンスに限界がありますので、誤りです。
・EC2インスタンスにMySQLをセットアップする。EBSのスナップショットを使用してバックアップとリストアを自動化し、データの整合性を保つ
EBSのスナップショットはバックアップには適していますが、フェイルオーバーや高可用性に対応していませんので、誤りです。
・Aurora MySQLをシングルAZ構成でデプロイし、Auroraのリードレプリカを使用して読み取りパフォーマンスを向上させる
AuroraはシングルAZ構成でもリードレプリカを使ってフェイルオーバーが可能です。しかし、AZ全体が障害を起こした場合、フェイルオーバー先がなくなるため、マルチAZ構成ほど高い可用性は確保できません。よって、誤りです。
参考
【AWSのデータベースサービス】
AWSには複数のデータベースサービスがあり、それぞれ異なる特徴や用途を持っています。

ユーザーは各サービスの特性を理解したうえで最適なものを選択する必要があります。
本項ではAmazon RDSについて解説します。
【Amazon RDS(Relational Database Service)】
RDSは、フルマネージド型のリレーショナルデータベース(関係データベース)サービスです。SQLを用いたデータベースの操作が可能であり、トランザクション処理にも適しています。リレーショナルデータベースでは、事前定義されたスキーマ(データの構造や制約の定義)に基づいてデータを管理します。そのため、ACID特性(原子性、一貫性、独立性、耐久性)を満たし、データの一貫性や整合性を保ちながら、複雑なトランザクションの実行が求められるシステムにおいても安心して利用できます。
RDSはフルマネージドサービスであり、AWSがデータベースの運用管理を担い、ストレージの拡張、高可用性の確保、バックアップ、パッチ適用、メンテナンスなど自動化しています。その代わりに、利用できるデータベースエンジンやバージョンが限定されており、データベースエンジンごとに使用が制限されている機能もあります。
RDSの以下の項目について説明します。
(1) RDSの主な機能
(2) 高可用性
(3) パフォーマンス
(4) セキュリティ
(5) ACID特性
(1) RDSの主な機能
RDSでは以下のデータベースエンジンを利用できます。
・Aurora
・MySQL
・MariaDB
・PostgreSQL
・Oracle
・Microsoft SQL Server
・IBM DB2
RDSは、バックアップ、スナップショット取得、パッチ適用、レプリケーションの設定などはAWS側で自動化または簡易化されています。また、ストレージの自動スケーリングをサポートしており、ストレージ容量が枯渇した場合に自動的に拡張されます。ただし増えたストレージ容量を減らす(ストレージを縮小する)ことはできません。
○データベースの移行
現在利用しているデータベースをRDSへ移行する際も、できるだけ手間が少ないように考慮されています。例えばMySQLを利用している場合、自社環境に保存されたバックアップデータを利用して移行が行える等の機能が提供されています。また、スナップショットを用いてデータベースの復元や、データベースの移行(異なるDBエンジンへ移行する)を行う機能も提供されています。

以下はRDS for MySQLのスナップショットからAmazon Auroraへ移行する場合の画面例です。

○スナップショットの共有
RDSでは、データベースを所有しているAWSアカウントとは別のAWSアカウントと、データベースのスナップショットを共有できます。例えば、AWSアカウントを別に持つ部署でデータベースのコピーが必要だったり、新たに作成するAWSアカウントへデータベースを移行したいような場合は、スナップショットを共有し、共有したAWSアカウントでスナップショットからデータベースの復元が可能です。
スナップショットが暗号化されている場合は、KMSキーのキーポリシーの設定で共有先のアカウントへKMS暗号化キーの使用を許可する必要があります。詳細は分野「KMS/CloudHSM」の「鍵の使用と鍵の共有」を参照してください。
○データベースのパラメータ変更
タイムゾーンや最大接続数、監査ログの有効化など、データベースの設定を変更したい場合、RDSでは「DBパラメータグループ(DBクラスターパラメータグループ)」または「オプショングループ」で定義します。DBパラメータグループ、オプショングループはDBエンジンごとに作成するパラメータまたはオプションの定義グループで、作成後は複数のデータベース(またはデータベースクラスター)へアタッチできます。
(2) 高可用性
○マルチAZ
マルチAZ構成では、複数のAZをまたぐ配置によって同期レプリケーションとフェイルオーバーを実現できます。

マルチAZでは、プライマリDBインスタンスとスタンバイDBインスタンスを2つの異なるAZに1つずつ配置することによって可用性を向上させることができます(リージョンは同一)。スタンバイ側のデータベースは常に同期レプリケーションされているため、フェイルオーバーが発生してもデータの損失が発生しません。また、フェイルオーバーは自動的に行われ、運用は継続して行えます。データベースを利用しているアプリケーション側からはスタンバイ側へアクセスを切り替える必要もありません。
マルチAZはデータベースのメンテナンス(OSの更新やパッチの適用など)の時にも役立ちます。RDSはフルマネージド型のサービスのため、メンテナンスはAWSが行います。再起動を伴うメンテナンス時にはマルチAZ構成を取ることで、以下のように運用停止なしにメンテナンスを完了できます。
1. スタンバイDBインスタンスに対するメンテナンス
2. スタンバイDBインスタンスをプライマリDBインスタンスへ昇格
3. 新スタンバイDBインスタンス(旧プライマリDBインスタンス)に対するメンテナンス
マルチAZは、DBインスタンスの作成時に設定できます。また、既にシングルAZで稼働中のDBインスタンスに対しても、最小限のダウンタイムのみで設定変更ができます。
○マルチAZ DBクラスター
Amazon RDSのマルチAZ DBクラスターは、マルチAZ構成の新しい高可用性オプションです。従来のマルチAZ構成とは異なり、3つのアベイラビリティゾーンにまたがって配置されるため、可用性がさらに強化されています。また、従来のマルチAZ構成ではスタンバイインスタンスにアクセスできませんが、マルチAZ DBクラスターでは2つのスタンバイインスタンスがリードレプリカとしても機能し、読み取りアクセスが可能です。プライマリーインスタンスへの書き込みは、残り2台のリードレプリカに準同期レプリケーションされます。さらに、フェイルオーバー時には通常35秒未満で切り替わるため、アプリケーションのダウンタイムを最小限に抑えることができます。
[マルチAZ DBクラスターのイメージ図]

(3) パフォーマンス
○インスタンスタイプ
RDSのパフォーマンスは、使用するインスタンスクラス(EC2のインスタンスタイプと同様)によって左右されます。インスタンスタイプは、アプリケーションの要件や負荷に応じて、計算能力(CPU)、メモリ、ネットワーク帯域の異なる複数のオプションから選択できます。一般的には、汎用(バランス型)、コンピューティング最適化、メモリ最適化などのクラスがあり、各クラス内でさらに小規模から大規模までのサイズが用意されています。
適切なインスタンスタイプを選択することで、データベースのパフォーマンスとコスト効率をバランス良く最適化できます。
○ストレージタイプ
RDSのストレージは、基本的には汎用SSDとプロビジョンド(予約済み)IOPSから選択します。IOPSとはInput Output per Second、つまり1秒間にどれだけI/O(Input/Output:読み取り/書き込み)が行えるかを意味するデータベースの性能指標です。
プロビジョンドIOPSを選択すると、予約したI/O性能が保証されるため、アクセスが集中する場面でも安定した性能を確保できます。なお、両者の性能値は以下のように示されています。
・汎用SSD: 100~10,000 IOPS
・プロビジョンドIOPS:1,000~30,000 IOPS
○リードレプリカ
RDSでは、リードレプリカ(RR)は参照専用のデータベースレプリカとして機能し、スケールアウトによって参照アクセスの負荷を分散するために使用されます。データベースの参照時にかかる負荷が高い場合、RRを最大15台までスケールアウトし、参照アクセスの負荷を分散できます。
リードレプリカは異なるAZや異なるリージョンにも配置でき、高可用性や災害復旧にも利用されます。

リードレプリカは、データベースのインスタンスクラスを変更することにより、スケールアップ(拡張)、スケールダウン(縮小)も柔軟に行うことができます。利用者の多いタイミングでデータベースを一時的に拡張し、利用者が少ないタイミングでは縮小するように運用することにより、リソース(CPU、メモリ、ディスクI/Oやネットワークなど)を無用に消費せずに済みます。
※リードレプリカのスケールアップ/ダウンはデータベースインスタンスが対象です。データベースのストレージ容量の拡張はできますが、縮小はできません。
(4) セキュリティ
○ネットワークアクセス制御
基本的にRDSはVPC内からの接続のみ許可します。EC2インスタンスからアクセスを行うパターンでは、RDSのデータベースインスタンス用のセキュリティグループを作成し、EC2インスタンスからのアクセスを許可するルールを作成して接続します。この設定により、ネットワークレベルでのアクセス制御が実現されます。
○データ通信の暗号化
アプリケーションサーバーとDBインスタンス間の通信をSSL/TLSを使用して暗号化することで、両者間のデータ転送が保護され、盗聴や改ざんのリスクが軽減されます。AWSが提供するルート証明書をダウンロードし、アプリケーションサーバー側でSSL/TLSを有効にしてDBインスタンスへ接続することで、安全な通信を確保できます。

○データ暗号化設定
データベースインスタンスは、AWS Key Management Service(KMS)と連携して暗号化できます。データベースインスタンスの暗号化を行うと、バックアップやスナップショット、ログ、RR(リードレプリカ)へも暗号化が行われます。暗号化を行う場合はデータベースの作成時に指定します。
※KMSの詳細は、分野「KMS/CloudHSM」を参照してください。

データベースの作成後に暗号化を有効にできません。暗号化されていないデータベースインスタンスを暗号化したい場合は、対象のインスタンスのスナップショットを作成し、スナップショットをコピーする際に暗号化を有効にします。暗号化されたスナップショットを基にデータベースインスタンスを復元すると、暗号化されたデータベースインスタンスが新規に構築されます。
(5) ACID特性
リレーショナルデータベースにはACID特性というものがあります。ACIDとは、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)、耐久性(Durability)を意味する言葉で、更新処理中に中途半端なデータが書き込まれないことや、並行処理がそれぞれ独立して動作する(互いに干渉しない)ことなど、処理の信頼性を保証する性質をいいます。RDSもリレーショナルデータベースサービスですので、ACID特性を持っています。
○データベースの削除保護
DBインスタンスに対して「削除保護」機能を有効にすると、設定されたデータベースは削除ができなくなるので、ユーザの操作ミスによる意図しない削除操作からデータベースを保護できます。

【Amazon RDS Proxy】
Amazon RDS Proxyは、RDSデータベースへの接続を効率的に管理するフルマネージドのプロキシサービスです。RDS Proxyをアプリケーションとデータベースの間に配置することで、データベース接続の管理を効率化し、アプリケーションのパフォーマンス、スケーラビリティ、および可用性を向上させることができます。特に、サーバーレスアーキテクチャやマイクロサービスアーキテクチャで使用されることが多く、頻繁なデータベース接続の確立や切断がパフォーマンスに影響を与えるケースに適しています。
[Amazon RDS Proxyの利用例]

主な特徴は以下です:
○接続プーリング
RDS Proxyは接続プールを使用して、複数のデータベース接続を効率的に管理します。アプリケーションがデータベースに新しい接続を頻繁に確立および切断する必要がなくなり、データベースサーバーの負荷が軽減されます。また、一度確立したデータベース接続をプール内で保持し、必要に応じて再利用するため、接続の確立にかかる時間とリソースを節約できます。
○フェイルオーバーサポート
RDS Proxyはデータベースのフェイルオーバー時に接続を管理し、新しいデータベースインスタンスに自動的にルーティングします。データベースやAZ障害時に、フェイルオーバー時間を短縮できるので、アプリケーションのダウンタイムを最小限に抑えられます。
○セキュリティ
RDS ProxyはIAMやSecrets Managerと統合して、データベースの認証情報を安全に管理します。データベース認証情報のセキュリティが強化され、アクセス制御も容易になります。
AWSには複数のデータベースサービスがあり、それぞれ異なる特徴や用途を持っています。

ユーザーは各サービスの特性を理解したうえで最適なものを選択する必要があります。
本項ではAmazon RDSについて解説します。
【Amazon RDS(Relational Database Service)】
RDSは、フルマネージド型のリレーショナルデータベース(関係データベース)サービスです。SQLを用いたデータベースの操作が可能であり、トランザクション処理にも適しています。リレーショナルデータベースでは、事前定義されたスキーマ(データの構造や制約の定義)に基づいてデータを管理します。そのため、ACID特性(原子性、一貫性、独立性、耐久性)を満たし、データの一貫性や整合性を保ちながら、複雑なトランザクションの実行が求められるシステムにおいても安心して利用できます。
RDSはフルマネージドサービスであり、AWSがデータベースの運用管理を担い、ストレージの拡張、高可用性の確保、バックアップ、パッチ適用、メンテナンスなど自動化しています。その代わりに、利用できるデータベースエンジンやバージョンが限定されており、データベースエンジンごとに使用が制限されている機能もあります。
RDSの以下の項目について説明します。
(1) RDSの主な機能
(2) 高可用性
(3) パフォーマンス
(4) セキュリティ
(5) ACID特性
(1) RDSの主な機能
RDSでは以下のデータベースエンジンを利用できます。
・Aurora
・MySQL
・MariaDB
・PostgreSQL
・Oracle
・Microsoft SQL Server
・IBM DB2
RDSは、バックアップ、スナップショット取得、パッチ適用、レプリケーションの設定などはAWS側で自動化または簡易化されています。また、ストレージの自動スケーリングをサポートしており、ストレージ容量が枯渇した場合に自動的に拡張されます。ただし増えたストレージ容量を減らす(ストレージを縮小する)ことはできません。
○データベースの移行
現在利用しているデータベースをRDSへ移行する際も、できるだけ手間が少ないように考慮されています。例えばMySQLを利用している場合、自社環境に保存されたバックアップデータを利用して移行が行える等の機能が提供されています。また、スナップショットを用いてデータベースの復元や、データベースの移行(異なるDBエンジンへ移行する)を行う機能も提供されています。

以下はRDS for MySQLのスナップショットからAmazon Auroraへ移行する場合の画面例です。

○スナップショットの共有
RDSでは、データベースを所有しているAWSアカウントとは別のAWSアカウントと、データベースのスナップショットを共有できます。例えば、AWSアカウントを別に持つ部署でデータベースのコピーが必要だったり、新たに作成するAWSアカウントへデータベースを移行したいような場合は、スナップショットを共有し、共有したAWSアカウントでスナップショットからデータベースの復元が可能です。
スナップショットが暗号化されている場合は、KMSキーのキーポリシーの設定で共有先のアカウントへKMS暗号化キーの使用を許可する必要があります。詳細は分野「KMS/CloudHSM」の「鍵の使用と鍵の共有」を参照してください。
○データベースのパラメータ変更
タイムゾーンや最大接続数、監査ログの有効化など、データベースの設定を変更したい場合、RDSでは「DBパラメータグループ(DBクラスターパラメータグループ)」または「オプショングループ」で定義します。DBパラメータグループ、オプショングループはDBエンジンごとに作成するパラメータまたはオプションの定義グループで、作成後は複数のデータベース(またはデータベースクラスター)へアタッチできます。
(2) 高可用性
○マルチAZ
マルチAZ構成では、複数のAZをまたぐ配置によって同期レプリケーションとフェイルオーバーを実現できます。

マルチAZでは、プライマリDBインスタンスとスタンバイDBインスタンスを2つの異なるAZに1つずつ配置することによって可用性を向上させることができます(リージョンは同一)。スタンバイ側のデータベースは常に同期レプリケーションされているため、フェイルオーバーが発生してもデータの損失が発生しません。また、フェイルオーバーは自動的に行われ、運用は継続して行えます。データベースを利用しているアプリケーション側からはスタンバイ側へアクセスを切り替える必要もありません。
マルチAZはデータベースのメンテナンス(OSの更新やパッチの適用など)の時にも役立ちます。RDSはフルマネージド型のサービスのため、メンテナンスはAWSが行います。再起動を伴うメンテナンス時にはマルチAZ構成を取ることで、以下のように運用停止なしにメンテナンスを完了できます。
1. スタンバイDBインスタンスに対するメンテナンス
2. スタンバイDBインスタンスをプライマリDBインスタンスへ昇格
3. 新スタンバイDBインスタンス(旧プライマリDBインスタンス)に対するメンテナンス
マルチAZは、DBインスタンスの作成時に設定できます。また、既にシングルAZで稼働中のDBインスタンスに対しても、最小限のダウンタイムのみで設定変更ができます。
○マルチAZ DBクラスター
Amazon RDSのマルチAZ DBクラスターは、マルチAZ構成の新しい高可用性オプションです。従来のマルチAZ構成とは異なり、3つのアベイラビリティゾーンにまたがって配置されるため、可用性がさらに強化されています。また、従来のマルチAZ構成ではスタンバイインスタンスにアクセスできませんが、マルチAZ DBクラスターでは2つのスタンバイインスタンスがリードレプリカとしても機能し、読み取りアクセスが可能です。プライマリーインスタンスへの書き込みは、残り2台のリードレプリカに準同期レプリケーションされます。さらに、フェイルオーバー時には通常35秒未満で切り替わるため、アプリケーションのダウンタイムを最小限に抑えることができます。
[マルチAZ DBクラスターのイメージ図]

(3) パフォーマンス
○インスタンスタイプ
RDSのパフォーマンスは、使用するインスタンスクラス(EC2のインスタンスタイプと同様)によって左右されます。インスタンスタイプは、アプリケーションの要件や負荷に応じて、計算能力(CPU)、メモリ、ネットワーク帯域の異なる複数のオプションから選択できます。一般的には、汎用(バランス型)、コンピューティング最適化、メモリ最適化などのクラスがあり、各クラス内でさらに小規模から大規模までのサイズが用意されています。
適切なインスタンスタイプを選択することで、データベースのパフォーマンスとコスト効率をバランス良く最適化できます。
○ストレージタイプ
RDSのストレージは、基本的には汎用SSDとプロビジョンド(予約済み)IOPSから選択します。IOPSとはInput Output per Second、つまり1秒間にどれだけI/O(Input/Output:読み取り/書き込み)が行えるかを意味するデータベースの性能指標です。
プロビジョンドIOPSを選択すると、予約したI/O性能が保証されるため、アクセスが集中する場面でも安定した性能を確保できます。なお、両者の性能値は以下のように示されています。
・汎用SSD: 100~10,000 IOPS
・プロビジョンドIOPS:1,000~30,000 IOPS
○リードレプリカ
RDSでは、リードレプリカ(RR)は参照専用のデータベースレプリカとして機能し、スケールアウトによって参照アクセスの負荷を分散するために使用されます。データベースの参照時にかかる負荷が高い場合、RRを最大15台までスケールアウトし、参照アクセスの負荷を分散できます。
リードレプリカは異なるAZや異なるリージョンにも配置でき、高可用性や災害復旧にも利用されます。

リードレプリカは、データベースのインスタンスクラスを変更することにより、スケールアップ(拡張)、スケールダウン(縮小)も柔軟に行うことができます。利用者の多いタイミングでデータベースを一時的に拡張し、利用者が少ないタイミングでは縮小するように運用することにより、リソース(CPU、メモリ、ディスクI/Oやネットワークなど)を無用に消費せずに済みます。
※リードレプリカのスケールアップ/ダウンはデータベースインスタンスが対象です。データベースのストレージ容量の拡張はできますが、縮小はできません。
(4) セキュリティ
○ネットワークアクセス制御
基本的にRDSはVPC内からの接続のみ許可します。EC2インスタンスからアクセスを行うパターンでは、RDSのデータベースインスタンス用のセキュリティグループを作成し、EC2インスタンスからのアクセスを許可するルールを作成して接続します。この設定により、ネットワークレベルでのアクセス制御が実現されます。
○データ通信の暗号化
アプリケーションサーバーとDBインスタンス間の通信をSSL/TLSを使用して暗号化することで、両者間のデータ転送が保護され、盗聴や改ざんのリスクが軽減されます。AWSが提供するルート証明書をダウンロードし、アプリケーションサーバー側でSSL/TLSを有効にしてDBインスタンスへ接続することで、安全な通信を確保できます。

○データ暗号化設定
データベースインスタンスは、AWS Key Management Service(KMS)と連携して暗号化できます。データベースインスタンスの暗号化を行うと、バックアップやスナップショット、ログ、RR(リードレプリカ)へも暗号化が行われます。暗号化を行う場合はデータベースの作成時に指定します。
※KMSの詳細は、分野「KMS/CloudHSM」を参照してください。

データベースの作成後に暗号化を有効にできません。暗号化されていないデータベースインスタンスを暗号化したい場合は、対象のインスタンスのスナップショットを作成し、スナップショットをコピーする際に暗号化を有効にします。暗号化されたスナップショットを基にデータベースインスタンスを復元すると、暗号化されたデータベースインスタンスが新規に構築されます。
(5) ACID特性
リレーショナルデータベースにはACID特性というものがあります。ACIDとは、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)、耐久性(Durability)を意味する言葉で、更新処理中に中途半端なデータが書き込まれないことや、並行処理がそれぞれ独立して動作する(互いに干渉しない)ことなど、処理の信頼性を保証する性質をいいます。RDSもリレーショナルデータベースサービスですので、ACID特性を持っています。
○データベースの削除保護
DBインスタンスに対して「削除保護」機能を有効にすると、設定されたデータベースは削除ができなくなるので、ユーザの操作ミスによる意図しない削除操作からデータベースを保護できます。

【Amazon RDS Proxy】
Amazon RDS Proxyは、RDSデータベースへの接続を効率的に管理するフルマネージドのプロキシサービスです。RDS Proxyをアプリケーションとデータベースの間に配置することで、データベース接続の管理を効率化し、アプリケーションのパフォーマンス、スケーラビリティ、および可用性を向上させることができます。特に、サーバーレスアーキテクチャやマイクロサービスアーキテクチャで使用されることが多く、頻繁なデータベース接続の確立や切断がパフォーマンスに影響を与えるケースに適しています。
[Amazon RDS Proxyの利用例]

主な特徴は以下です:
○接続プーリング
RDS Proxyは接続プールを使用して、複数のデータベース接続を効率的に管理します。アプリケーションがデータベースに新しい接続を頻繁に確立および切断する必要がなくなり、データベースサーバーの負荷が軽減されます。また、一度確立したデータベース接続をプール内で保持し、必要に応じて再利用するため、接続の確立にかかる時間とリソースを節約できます。
○フェイルオーバーサポート
RDS Proxyはデータベースのフェイルオーバー時に接続を管理し、新しいデータベースインスタンスに自動的にルーティングします。データベースやAZ障害時に、フェイルオーバー時間を短縮できるので、アプリケーションのダウンタイムを最小限に抑えられます。
○セキュリティ
RDS ProxyはIAMやSecrets Managerと統合して、データベースの認証情報を安全に管理します。データベース認証情報のセキュリティが強化され、アクセス制御も容易になります。
マルチAZ配置ではないAuroraでリードレプリカを使用
投稿日 2024/09/14
解説に対する疑問があります。マルチAZ配置ではないAuroraでリードレプリカを使用している場合もプライマリが障害でダウンするとリードレプリカがプライマリに昇格するので、フェイルオーバーを実現できていると思うのですが、いかがでしょうか?
2024/09/14 23:51
誤答解説のこの部分ですか?
シングルAZ構成では高可用性やフェイルオーバーを実現できませんので、誤りです。
確かに「フェイルオーバー」はシングルAZ構成でもできますが、当該AZ障害の場合はフェイルオーバーする先ごとなくなるので「高い可用性を確保」しているとは言えないから、ということなのかなぁと思います。そういう意味では記述が明確ではないかなぁって気がしますね (^^;
コメント
スタッフからの返信
この投稿に対して返信しませんか?
s staff_higashimoto
2024/09/18 11:07
pontamkii様 arashi1977様 ご指摘の点を修正いたしました。 ご報告いただきまして、誠にありがとうございます。