AWS を無料でお試しください

まずは無料で始める »
またはコンソールにサインイン

AWS 無料利用枠には、Amazon Relational Database Service (RDS)について、1 年間毎月 750 時間の Micro DB Instance、20 GB のストレージ、バックアップ用に 20 GB のストレージが含まれます。

AWS アカウント作成の流れはこちら »

日本担当チームへお問い合わせ »

Q: Amazon RDS とは何ですか?

Amazon Relational Database Service (Amazon RDS) は、クラウドでのリレーショナルデータベースのセットアップ、運用、およびスケーリングを容易に行えるようにするマネージドサービスです。これにより、時間のかかるデータベース管理作業をお客様の代わりに実行して、お客様を管理業務から解放し、アプリケーションとビジネスに集中させることができます。このサービスはコスト効率もよく、データベース容量の変更にも柔軟に対応します。

Amazon RDS では、使いなれた MySQL、MariaDB、Oracle、SQL Server、または PostgreSQL データベースの機能を引き続き利用できます。つまり、既存のデータベースで既に使用しているコード、アプリケーション、およびツールは、Amazon RDS でシームレスに機能します。Amazon RDS では、データベースは自動的にバックアップされ、データベースソフトウェアは最新バージョンによって最新の状態に保たれます。リレーショナルデータベースインスタンスに関連するコンピューティングリソースやストレージ容量を簡単に拡張できる柔軟性が得られます。さらに、Amazon RDS は、簡単にレプリケーションを使って、データベースの可用性を強化、データの耐久性を改善、ひとつのデータベースインスタンスの容量制限を拡張して読み込み付加を軽減することができるようにします。アマゾン ウェブ サービス のすべてのサービスと同じく、初期投資は不要であり、使用したリソースにのみ課金されます。

Q: Amazon RDS ではどのリレーショナルデータベースエンジンがサポートされていますか?

Amazon RDS では Amazon Aurora、MySQL、MariaDB、Oracle、SQL Server、PostgreSQL データベースエンジンがサポートされています。

Q: Amazon RDS では何を管理できますか?

Amazon RDS は、お客様からリクエストされたインフラストラクチャ容量のプロビジョニングからデータベースソフトウェアのインストールまで、リレーショナルデータベースのセットアップに関係する作業を管理します。データベースが起動および実行されると、Amazon RDS では、バックアップの実行やデータベースを強化するソフトウェアのパッチ適用などの一般的な管理タスクが自動化されます。オプションの マルチ AZ 配置により、Amazon RDS では、アベイラビリティーゾーン全体への同期的データレプリケーションと、自動フェイルオーバーが管理されます。

Amazon RDS ではネイティブのデータベースアクセスが提供されるので、お客様は通常の場合と同様にリレーショナルデータベースソフトウェアを操作できます。つまり、お客様はお客様のアプリケーションに特有なデータベース設定の管理にまだ責任があります。お客様は、お客様のユースケースに最適なリレーショナルスキーマを構築する必要があり、アプリケーションのワークフローに対してデータベースを最適化するための、性能調整に責任があります。

Q: Amazon RDS と Amazon EC2 Relational Database AMI を使用するとよいのは、それぞれどのような場合ですか?

開発者は、アマゾン ウェブ サービスでデータベースに関するいくつかの選択肢を利用できます。Amazon RDS を利用すると、フル機能のリレーショナルデータベースを、データベース管理の負担なしで運用できます。Amazon EC2 で AWS のさまざまなリレーショナルデータベース AMI のいずれかを使用することにより、クラウド内でお客様自身のリレーショナルデータベースを管理できます。この選択肢の間には重要な違いがあるため、実際のユースケースに応じて最適なものを選ぶときは、この違いを考慮する必要があります。お客様にとって最適なソリューションを選択するガイダンスについては、AWS が提供するクラウドデータベースをご覧ください。

Q: Amazon RDS を開始する方法を教えてください。

Amazon RDS にサインアップするには、アマゾン ウェブ サービスアカウントを持っている必要があります。まだ持っていない場合は、アカウントを作成してください。サインアップした後、Amazon RDS 資料をご覧ください。入門ガイドが含まれています。

Amazon RDS は、AWS 無料利用枠の一部のため、新しい AWS のお客様は、クラウド内のマネージドデータベースサービスを無料で開始できます。


Q: データベースインスタンス (DB インスタンス) とは何ですか?

DB インスタンスを、お客様が指定したコンピューティングおよびストレージリソースを備えた、クラウド内のデータベース環境であると考えることができます。DB インスタンスの作成と削除、DB インスタンスのインフラストラクチャ属性の定義や改良を行うことができ、さらに AWS マネジメントコンソールAmazon RDS APIAWS コマンドラインインターフェイスを使用してアクセスとセキュリティを管理できます。1 つ以上の DB インスタンスを実行でき、各 DB インスタンスは、1 つ以上のデータベースまたはデータベーススキーマをサポートできます (エンジンタイプによる)。

Q: DB インスタンスを作成する方法を教えてください。

DB インスタンスは、AWS マネジメントコンソールAmazon RDS APIAWS コマンドラインインターフェイスを使用して、簡単に作成できます。AWS マネジメントコンソールを使用して DB インスタンスを起動するには、[インスタンス] タブにある [RDS] をクリックし、次に [DB インスタンスの起動] ボタンをクリックします。そこから、DB エンジンとバージョン、ライセンスモデル、インスタンスタイプ、ストレージタイプと量、およびマスターユーザーの認証情報を含む DB インスタンスに対して、パラメータを指定できます。

DB インスタンスのバックアップ保持ポリシー、任意のバックアップウィンドウ、予定メンテナンスウィンドウを変更することも可能です。代わりに、CreateDBInstance APIcreate-db-instance コマンドを使用して、DB インスタンスを作成することも可能です。

Q: 自分が実行中の DB インスタンスにはどのようにアクセスしますか?

いったん DB インスタンスが利用可能になったら、AWS マネジメントコンソールDescribeDBInstances APIdescribe-db-instances コマンドの DB インスタンスの説明を使用して、そのエンドポイントを取得できます。このエンドポイントを使用して、使い慣れたデータベースツールまたはプログラミング言語により、DB インスタンスに直接接続するために必要な接続ストリングを作成できます。実行中の DB インスタンスに対するネットワークリクエストを許可するため、アクセスを許可する必要があります。接続文字列の作成方法および開始方法についての詳細は、AWS の入門ガイドをご覧ください。

Q: Amazon RDS ではいくつの DB インスタンスを実行できますか?

デフォルトでは、Amazon RDS DB インスタンスを合計 40 個まで保有できます。この 40 個のインスタンスのうち 10 個までは、"ライセンス込み" モデルの Oracle または SQL Server DB インスタンスとすることができます。40 個のインスタンスすべては、"BYOL" モデルで Amazon Aurora、MySQL、MariaDB、PostgreSQL、Oracle、または SQL Server に使用できます。アプリケーションにこれ以上の DB インスタンスが必要である場合、こちらの申請フォームで追加の DB インスタンスをリクエストできます。

Q: 1 つの DB インスタンスで何個のデータベースまたはスキーマを実行できますか?

  • RDS for Amazon Aurora: ソフトウェアによる制限はありません
  • RDS for MySQL: ソフトウェアによる制限はありません
  • RDS for MariaDB: ソフトウェアによる制限はありません
  • RDS for Oracle: インスタンスあたり 1 個のデータベース。データベースあたりのスキーマの数については、ソフトウェアによる制限はありません
  • RDS for SQL Server: インスタンスあたり 30 個のデータベース
  • RDS for PostgreSQL: ソフトウェアによる制限はありません

Q: Amazon RDS DB インスタンスにデータをインポートする方法を教えてください。

データを簡単に Amazon RDS にインポートする方法は多数あります。例えば、mysqldump または mysqlimport ユーティリティ (MySQL の場合)、Data Pump、Import/Export または SQL Loader (Oracle の場合)、インポート/エクスポートウィザード、完全バックアップファイル (.bak ファイル) または一括コピープログラム (BCP) (SQL Server の場合)、pg_dump (PostgreSQL の場合) です。データのインポートとエクスポートの詳細については、MySQL のデータインポートガイドOracle のデータインポートガイドSQL Server のデータインポートガイド、または PostgreSQL のデータインポートガイドをご覧ください。

また、AWS Database Migration Service を使用すると、データベースを簡単かつ安全に AWS に移行できます。

Q: メンテナンスウィンドウとは何ですか?メンテナンスイベント中にも DB インスタンスを使用できますか?

リクエストされた、または必要なイベントにおいて、DB インスタンスの修正 (DB インスタンスクラスのスケーリングなど) やソフトウェアパッチの適用が発生する場合、コントロールを行う機会として、Amazon RDS メンテナンスウィンドウを利用できます。「メンテナンス」イベントが特定の週に予定されている場合、お客様が識別するメンテナンスウィンドウ中の一定の時点で、開始されて完了します。メンテナンスウィンドウは、30 分間です。

Amazon RDS によってお客様の DB インスタンスをオフラインにする必要があるメンテナンスイベントは、コンピューティングのスケーリングオペレーション (通常、開始から終了までの所要時間は数分) や必須のソフトウェアのパッチ適用のみです。安全性と堅牢性に関連するパッチに関してのみ、必須のパッチ適用が自動的にスケジューリングされます。このようなパッチは頻繁に発生するものではありません(通常数ヵ月ごとに一度です)。またお客様のメンテナンスウィンドウのごく一部以外を使用する必要があることは稀なはずです。DB インスタンスの作成時点で希望する毎週のメンテナンスウィンドウが指定されていない場合は、30 分のデフォルト値が割り当てられます。メンテナンスの実行時に修正する場合は、AWS マネジメントコンソールModifyDBInstance APImodify-db-instance コマンド で DB インスタンスを修正することで実行できます。各 DB インスタンスには、任意で異なるメンテナンスウィンドウを設定できます。

DB インスタンスをマルチ AZ 配置として実行すると、メンテナンスイベントの影響をさらに軽減できます。メンテナンスオペレーションの詳細については、Amazon RDS ユーザーガイドを参照してください。

Q: クエリが遅いと思われる場合、どうしたらよいですか?

本番用データベースでは拡張モニタリングを有効にするようお勧めします。拡張モニタリングでは、CPU、メモリ、ファイルシステム、ディスク I/O に関する 50 を超えるメトリクスを利用できます。このような機能はインスタンスごとに有効にでき、詳細度 (最短で 1 秒) も選択できます。CPU の高度な利用によりクエリ性能が低下する場合は、DB インスタンスクラスのスケーリングを検討することをお勧めします。DB インスタンスのモニタリングの詳細については、Amazon RDS ユーザーガイドを参照してください。

RDS for MySQL または RDS for MariaDB を使用している場合は、データベース用のスロークエリログを参照して、実行速度の遅い SQL クエリがあるかどうかを判断します。実行速度の遅いクエリがある場合は、各クエリのパフォーマンス特性を判断します。「slow_query_log」DB パラメータを設定し、mysql.slow_log テーブルをクエリして、実行速度の遅い SQL クエリを確認することができます。詳細については、『Amazon RDS User Guide』をご覧ください。

RDS for Oracle を使用している場合は、Oracle トレースファイルデータを使用して、実行速度の遅いクエリを特定できます。トレースファイルデータへのアクセスの詳細については、Amazon RDS ユーザーガイドを参照してください。

RDS for SQL Server を使用する場合は、クライアント側 SQL Server トレースを使用して、実行速度の遅いクエリを特定できます。サーバー側トレースファイルデータへのアクセスついては、Amazon RDS ユーザーガイドを参照してください。


Q: Amazon RDS ではどのリレーショナルデータベースエンジンのバージョンがサポートされていますか?

  • Amazon RDS for MySQL では、現在 MySQL Community Edition 5.5、5.6、および 5.7 がサポートされています。
  • Amazon RDS for MariaDB では、現在 MariaDB Server 10.0 および 10.1 がサポートされています。
  • Amazon RDS for PostgreSQL では、現在 PostgreSQL 9.3、9.4、9.5、および 9.6 がサポートされています。
  • Amazon RDS for Oracle では、現在 Oracle Database 11gR2 および 12c をサポートされています。
  • Amazon RDS for SQL Server では、現在 Microsoft SQL Server 2008 R2、2012、2014、および 2016 がサポートされています。

Amazon Aurora データベースのバージョンの詳細については、Amazon Aurora ユーザーガイドを参照してください。

Q: Amazon RDS では、どのように "メジャー" と "マイナー" の DB エンジンバージョンが区別されますか?

バージョン番号付けの詳細については、各 Amazon RDS データベースエンジンのよくある質問ページを参照してください。

Q: Amazon RDS では、新しいバージョンの DB エンジンのサポートガイドラインが提供されますか?

Amazon RDS では、データベースエンジンの新しいメジャーとマイナーのバージョンが徐々に追加されます。毎年サポートされる新しいバージョンリリースの数は、エンジンのベンダーや開発組織からのリリースやパッチの頻度とその内容、および AWS のデータベースエンジニアリングチームのリリースおよびパッチの診断結果により異なります。ただし、一般的なガイダンスとして、AWS では、一般公開から 5 か月以内に新しいバージョンのエンジンをサポートできるよう取り組んでいます。

Q: サポートされている DB エンジンバージョンのうちで、自分の DB インスタンスで実行するバージョンを指定するにはどうしたらよいですか?

AWS マネジメントコンソールまたは CreateDBInstance API の [DB インスタンスの起動] をクリックして新しい DB インスタンスを作成する際に、現在サポートされているバージョン (マイナーおよびメジャー) のいずれかを指定することができます。すべての AWS リージョンですべてのバージョンのデータベースエンジンを利用できるとは限りません。

Q: 使用中の DB インスタンスのエンジンバージョンが新しいサポートバージョンに更新されるかどうか、およびその時期をどのように制御できますか?

サポート対象の新しいバージョンのデータベースエンジンを提供することで、Amazon RDS ではお客様のデータベースインスタンスを最新に維持しようとします。ベンダーまたは開発組織によって新しいデータベースエンジンのバージョンがリリースされると、Amazon RDS で利用可能になる前に、データベースエンジニアリングチームによって徹底的にテストされます。

最新のマイナーバージョンには最新のセキュリティと機能上の修正が含まれているため、データベースインスタンスを最新のバージョンにアップグレードしておくことをお勧めします。メジャーバージョンのアップグレードと異なり、マイナーバージョンのアップグレードには、データベースエンジンの以前のマイナーバージョン (同じメジャーバージョンの) に下位互換性のあるデータベースの変更のみが含まれます。

新しいマイナーバージョンに RDS のお客様に役立つ修正が含まれていない場合は、RDS でこれを利用しないように選択できます。新しいマイナーバージョンが RDS で利用可能になるとすぐに、そのバージョンを新しい DB インスタンスで使用するマイナーバージョンとして設定することができます。

データベースインスタンスをサポート対象のエンジンバージョンに手動でアップグレードするには、AWS マネジメントコンソールまたは ModifyDBInstance API の [Modify DB Instance] コマンドを使用して、DB Engine Version パラメータをご希望のバージョンに設定できます。デフォルトではアップグレードが適用されます。それ以外の場合は、次のメンテナンスウィンドウで適用されます。[Apply Immediately] オプションをコンソール API で選択することで、すぐにアップグレードするよう選択することもできます。

エンジンの新しいマイナーバージョンに、以前にリリースされたマイナーバージョンと比べて重大なバグ修正が含まれている場合は、[Auto Minor Version Upgrade] が [Yes] に設定されている DB インスタンスの自動アップグレードをスケジュールします。これらのアップグレードは、お客様が指定したメンテナンスウィンドウ中に行われるようにスケジュールされます。

AWS では、スケジュールされたアップグレードについては Amazon RDS フォーラムで発表し、少なくとも 30 日前にはお客様に E メールでお知らせしています。マルチ AZ インスタンスであっても DB エンジンバージョンのアップグレードにあたってはダウンタイムが発生するため、お客様が対応を計画できるようにアップグレードをスケジュールしています。マイナーバージョンの自動アップグレードをオフにする場合は、[Auto Minor Version Upgrade] 設定を [No] に設定してください。

RDS for Oracle と RDS for SQL Server で、次のマイナーバージョンへのアップグレードで異なるエディションへの変更が必要となる場合は、[Auto Minor Version Upgrade] が有効になっている場合でも、自動アップグレードのスケジュールは行いません。このような状況で自動アップグレードをスケジュールするかどうかは、ケースバイケースで決められます。

メジャーバージョンのアップグレードには互換性のリスクがあるため、自動的には実行せず、お客様に開始していただく必要があります (メジャーバージョンが廃止される場合を除きます。下記を参照してください)。

DB インスタンスを新しいバージョンの DB エンジンにアップグレードする方法の詳細については、Amazon RDS ユーザーガイドを参照してください。

Q: アップグレード前に自分の DB インスタンスを新しいバージョンでテストできますか?

はい。テストを実施するには、既存の DB インスタンスの DB スナップショットを作成し、その DB スナップショットから復元して新しい DB インスタンスを作成した後、その新しい DB インスタンスのバージョンアップグレードを開始します。その後で、オリジナルの DB インスタンスをアップグレードするかどうかを決める前に、コピーした DB インスタンスで安全性を確かめることができます。

DB スナップショットの復元については、Amazon RDS ユーザーガイドを参照してください。

Q: Amazon RDS では、現在サポートされているバージョンのデータベースエンジンの廃止についてガイドラインが提供されていますか?

  • メジャーバージョンリリース (MySQL 5.6、PostgreSQL 9.6 など) に対しては、Amazon RDS によるサポートが開始されてから、少なくとも 3 年間のサポートを予定しています。
  • マイナーバージョンリリース (MySQL 5.6.21、PostgreSQL 9.6.1 など) に対しては、Amazon RDS によるサポートが開始されてから、少なくとも 1 年間のサポートを予定しています。

AWS では、定期的にメジャーまたはマイナーのエンジンバージョンの廃止を行います。メジャーバージョンについては、そのバージョンが延長サポートに移行された場合や、ソフトウェアの修正やセキュリティアップデートが行われなくなった場合に廃止します。マイナーバージョンについては、そのマイナーバージョンに、以降のバージョンで解決された重大なバグやセキュリティ上の問題が含まれている場合に廃止します。

これらのガイドラインを満たすための作業が行われていますが、特定のメジャーバージョンまたはマイナーバージョンにセキュリティの問題がある場合には、予定より早く廃止する可能性があります。そのような状況が発生する見込みがない場合は、Amazon RDS では、データベースエンジンの自動アップグレードを実施して、問題に対処します。特定の状況では、対処すべき問題によって別のスケジュールを決定する可能性があります。

Q: RDS DB のエンジンバージョンが廃止されるとどうなりますか?

マイナーバージョンのデータベースエンジンが Amazon RDS で廃止される場合は、[Auto Minor Version Upgrade] 設定を使用してインスタンスの自動アップグレードをスケジュールし、フォーラムで廃止が発表され、お客様に通知が送信されてから少なくとも 30 日間で廃止するようにします。また、このバージョンでの新しいインスタンスの作成を無効にします。発表されてから少なくとも 3 か月の猶予期間が過ぎると、廃止されたマイナーバージョンを実行しているすべてのインスタンスには自動アップグレードがスケジュールされ、指定されたメンテナンスウィンドウ中にサポート対象のマイナーバージョンにアップグレードされます。

Amazon RDS でデータベースエンジンのメジャーバージョンが廃止される場合は、廃止の通知から少なくとも 6 か月の猶予期間が提供されるため、この期間にサポート対象のメジャーバージョンへのアップグレードを開始できます。この猶予期間が終了すると、廃止されたバージョンを実行しているインスタンスには自動アップグレードが適用され、スケジュールされたメンテナンスウィンドウ中にアップグレードされます。

特定のメジャーまたはマイナーバージョンのデータベースエンジンが Amazon RDS でサポートされなくなった場合、サポートされていないバージョンで作成された DB スナップショットから復元された DB インスタンスは、自動的かつすみやかに現在サポートされているバージョンにアップグレードされます。


Q: Amazon RDS の使用に対してどのように課金、請求されますか?

使用料金は従量課金制となっており、最低料金やセットアップ料金はありません。以下の内容に基づき、請求が行われます。

  • DB インスタンス時間 – 消費された DB インスタンスのクラス (例: db.t2.micro、db.m4.large など) に基づいています。1 時間に満たない DB インスタンスの利用は、1 時間として請求されます。
  • ストレージ (/GB/月) – DB インスタンスに対してプロビジョニングしたストレージ容量。準備したストレージ容量を当月以内に拡張した場合、請求は比例配分されます。
  • I/O リクエスト/月 – ストレージ I/O リクエストの合計 (Amazon RDS Magnetic ストレージおよび Amazon Aurora のみ)
  • プロビジョンド IOPS/月 – 消費 IOPS とは無関係な、プロビジョンド IOPS レート (Amazon RDS プロビジョンド IOPS (SSD) ストレージのみ)
  • バックアップストレージ – バックアップストレージは、自動化されたデータベースバックアップや、お客様の作成したデータベーススナップショットに関連付けられたストレージです。 バックアップ保持期間を増やしたり、追加のデータベーススナップショットを取得したりすれば、お客様のデータベースが使用するバックアップストレージは増大します。
  • データ転送 – DB インスタンスのインターネット経由のデータ受信および送信です。

Amazon RDS の利用料金については、Amazon RDS 製品ページの料金表をご覧ください。

Q: Amazon RDS DB インスタンスへの請求はいつ始まり、いつ終わりますか?

DB インスタンスが利用可能になるとすぐに、DB インスタンスへの請求が始まります。削除またはインスタンス障害の際に発生する DB インスタンスの削除まで、請求が続きます。

Q: 請求可能な Amazon RDS インスタンス時間をどのように定義していますか?

利用可能な状態で DB インスタンスが動作している各時間に対して、DB インスタンス時間が請求されます。これ以上 DB インスタンスへの課金を望まない場合は、追加のインスタンス時間に対して請求されないよう、DB インスタンスを停止するか、終了する必要があります。1 時間に満たない DB インスタンスの利用は、1 時間として請求されます。

Q: 停止した DB インスタンスに対してどのように請求されますか?

データベースを停止している間でも、プロビジョニングされたストレージ (プロビジョンド IOPS を含む) やバックアップストレージ (指定した保持期間内の手動スナップショットや自動バックアップを含む) に対して課金されます。ただし、DB インスタンス時間に対して料金が発生することはありません。

Q: 追加バックアップストレージは割り当てられた DB インスタンスストレージよりもコストがかかるのはなぜですか?

お客様の一次データ用の DB インスタンスに対してプロビジョニングされたストレージは、単一のアベイラビリティーゾーン内に存在しています。データベースをバックアップすると、(トランザクション ログを含む)バックアップ データは、より優れたレベルのデータ耐久性を提供するため、複数の Availability Zone に対して地理的な冗長性をもってレプリケーションされます。無料割当量を超えたバックアップ ストレージの価格は、クリティカル バックアップの耐久性を最大化するために発生する、この特別なレプリケーションを反映しています。

Q: マルチ AZ DB インスタンスの配置に対してどのように請求が行われますか?

お客様の DB インスタンスがマルチ AZ 配置となるよう指定する場合、Amazon RDS 料金ページに記載されたマルチ AZ 料金設定に応じて料金が請求されます。マルチ AZ の料金は以下に基づきます。

  • マルチ AZ DB インスタンス時間 – 消費された DB インスタンスのクラス (例: db.t2.micro、db.m4.large など) に基づいています。単一のアベイラビリティーゾーンへの標準配置と同様に、消費される 1 時間未満の DB インスタンス時間は 1 時間分として請求されます。特定の 1 時間以内に、標準とマルチ AZ 間で DB インスタンスの配置を交換する場合、その時間に対して該当する両方の料金が課金されることになります。
  • プロビジョニングされたストレージ (マルチ AZ DB インスタンス用) – 特定の 1 時間以内に標準とマルチ AZ 間でお客様の配置を交換する場合、その時間に該当するストレージ料金のうち高い方の金額が課金されます。
  • I/O リクエスト/月 – ストレージ I/O リクエストの合計。マルチ AZ 配置は、お客様のデータベース書き込み/読み込み比率によっては、標準の DB インスタンス配置よりも大容量の I/O リクエストを消費します。データベース更新に伴う書き込み I/O 使用量は、Amazon RDS がお客様のデータをスタンバイの DB インスタンスに 同時にレプリケーションする場合の2倍になります。読み込み I/O 使用量は変わりません。
  • バックアップストレージ – お客様のバックアップストレージ使用量は、DB インスタンスが標準であろうと、マルチ AZ 配置であろうと変わりません。バックアップは、DB インスタンスプライマリ上の I/O 中断を避けるため、単純にお客様のスタンバイから取得されます。
  • データ転送 – お客様のプライマリおよびスタンバイ間でデータをレプリケートする際に発生するデータ転送に対しては課金されません。DB インスタンスの受信および送信におけるインターネットのデータ転送は、標準配置と同様に課金されます。

Q: 料金は税込み価格ですか?

別途記載がない限り、表示される料金には VAT、売上税その他取引に対して適用される一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS サービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細はこちらをご覧ください


Q: Amazon RDS での AWS 無料利用枠は何を提供していますか?

Amazon RDS の AWS 無料利用枠では、MySQL、MariaDB、PostgreSQL、Oracle (「自分のライセンス使用 (BYOL)」ライセンスモデル)、SQL Server Express Edition を実行する Single-AZ マイクロ DB インスタンスを無料でご利用いただけます。無料利用枠は、1 か月あたり 750 インスタンス時間までとなっています。さらに、お客様は、1 か月あたり 20 GB の汎用 (SSD) データベースストレージと 20 GB のバックアップストレージを無料でご利用いただけます。

Q: Amazon RDS での AWS 無料利用枠をどれくらいの期間、利用することができるのですか?

新しい AWS アカウントを取得すると、12 か月の AWS 無料利用枠をお使いいただけます。詳細については、AWS の無料利用枠のよくある質問ページを参照してください。

Q: Amazon RDS での AWS 無料利用枠において、複数の DB インスタンスを実行できますか?

はい。同時に複数の Single-AZ マイクロ DB インスタンスを実行でき、それらの使用量は Amazon RDS での AWS 無料利用枠内で計算されます。ただし、すべての Amazon RDS Single-AZ マイクロ DB インスタンスおよび、すべての対象データベースエンジンおよびリージョンについて 750 インスタンス時間を超えるご利用については、標準の Amazon RDS 料金が課金されます。

例: 1 か月で 2 つの Single-AZ マイクロ DB インスタンスをそれぞれ 400 時間実行した場合、累算で 800 インスタンス時間の使用量になり、そのうち 750 時間が無料になります。残りの 50 時間分については、標準の Amazon RDS 料金が課金されます。

Q: AWS 無料利用枠では、MySQL、MariaDB、PostgreSQL、Oracle、および SQL Server のマイクロ DB インスタンスについて、それぞれ 750 インスタンス時間アクセスできるのですか?

いいえ。AWS 無料利用枠へのアクセス権を持つお客様は、MySQL、PostgreSQL、Oracle、または SQL Server Express Edition のいずれかを実行するマイクロインスタンスを 750 インスタンス時間までご利用いただけます。すべての Amazon RDS Single-AZ マイクロ DB インスタンスおよび、すべての対象データベースエンジンおよびリージョンにおいて 750 インスタンス時間を超えるご利用については、標準の Amazon RDS 料金が課金されます。

Q: Amazon RDS の AWS 無料利用枠は、すべての AWS リージョンで利用可能ですか?

Amazon RDS の AWS 無料利用枠は、GovCloud(米国)を除き、すべての AWS リージョンで利用可能です。

Q: インスタンス時間の使用量が無料利用枠を超えると、どのように課金されますか?

無料利用枠が提供するインスタンス時間を超えた時間については、標準の Amazon RDS 料金が課金されます。詳細については、Amazon RDS 料金表のページを参照してください。


Q: リザーブドインスタンス (RI) とは何ですか?

Amazon RDS リザーブドインスタンスとは、1 年契約または 3 年契約で DB インスタンスを予約しておくもので、予約しておくと、DB インスタンスのオンデマンドインスタンス料金に比べて大幅な割引を受けられます。RI の料金お支払い方法には「前払いなし」、「一部前払い」、「全前払い」の 3 つがあり、前払いする金額と実効時間単価とのバランスを取ることができます。

Q: リザーブドインスタンスはオンデマンド DB インスタンスとどのように異なりますか?

機能的には、リザーブドインスタンスもオンデマンド DB インスタンスもまったく同一のものです。唯一異なる点は、お客様の DB インスタンスが課金される方法です。リザーブドインスタンスでは、1 年または 3 年の予約を購入して、その代わりに期間中は低料金の実効時間単価 (オンデマンド DB インスタンスと比較した場合) が適用されます。リージョンでリザーブドインスタンスを購入した場合を除き、すべての DB インスタンスはオンデマンド時間料金で課金されます。

Q: リザーブドインスタンスはどのように購入して作成できますか?

Amazon RDS の AWS マネジメントコンソールの [リザーブドインスタンス] セクションでリザーブドインスタンスを購入できます。または、Amazon RDS API や AWS コマンドラインインターフェイスを使用して、購入可能な予約を一覧表示し、DB インスタンス予約を購入することもできます。

予約購入が完了すると、リザーブド DB インスタンスはオンデマンド DB インスタンスと同じように使用できます。予約をしたものと同じインスタンスクラス、エンジン、リージョンを使って DB インスタンスを起動します。予約購入が有効である間、Amazon RDS ではお客様の新しい DB インスタンスに割引価格の時間料金を適用します。

Q: リザーブドインスタンスにキャパシティーの予約は含まれていますか?

Amazon RDS リザーブドインスタンスは、特定のアベイラビリティーゾーンではなくリージョンに対して購入します。RI はアベイラビリティーゾーンに固有ではないため、キャパシティーの予約ではありません。つまり、1 つのアベイラビリティーゾーンのキャパシティーに限界があったとしても、そのリージョンで予約を購入することができ、そのリージョン内のアベイラビリティーゾーンに対応する使用料に割引が適用されます。

Q: リザーブドインスタンスはいくつ購入できますか?

リザーブド DB インスタンスは 40 個まで購入できます。40 個を超える DB インスタンスを実行する場合は、Amazon RDS DB インスタンス申請フォームにご記入ください。

Q: 既に持っている既存の DB インスタンスをリザーブドインスタンスでカバーしたい場合はどうしますか?

現在実行している、または予約を考えている DB インスタンスと同じリージョン内の同じ DB インスタンスのクラス、DB エンジン、マルチ AZ オプション、およびライセンスモデルで、DB インスタンスの予約を購入します。予約購入が完了すると、Amazon RDS は既存の DB インスタンスに時間単位の新しい利用料金を自動的に適用します。

Q: リザーブドインスタンスにサインアップすると、期間はいつから始まりますか? DB インスタンスの使用期限が過ぎるとどうなりますか?

支払い認証の処理中にお客様からのリクエストがあれば、リザーブドインスタンスに関連する価格変更が有効になります。AWS アカウントアクティビティページで、または DescribeReservedDBInstances APIdescribe-reserved-db-instances コマンドを使って予約の状態を確認できます。次の請求期間に一括払いが承認されない場合は、割引料金が適用されません。

予約期限が過ぎると、リザーブドインスタンスは、お客様の DB インスタンスクラスとリージョンに該当するオンデマンド時間料金に変わります。

Q: どの DB インスタンスがリザーブドインスタンスの料金で請求されるかは、どのようにコントロールするのですか?

DB インスタンスの作成、修正、削除を実行する Amazon RDS オペレーションでは、オンデマンドとリザーブドインスタンスは区別されません。お客様への請求額を計算する際、AWS のシステムは、お客様の予約状態を自動的に適用して、該当するすべての DB インスタンスに低料金のリザーブド DB インスタンス料金を適用します。

Q: 保有する DB インスタンスのクラスをスケールアップまたはスケールダウンした場合、予約はどうなりますか?

それぞれの予約は、DB エンジン、DB インスタンスのクラス、マルチ AZ 配置オプション、ライセンスモデル、およびリージョンといった一連の属性に関連付けられています。

サイズの柔軟性を利用できる DB エンジンとライセンスモデル (MySQL、MariaDB、PostgreSQL、Amazon Aurora、Oracle の「自分のライセンス使用」) の予約は、同じデータベースエンジンとリージョンの同じインスタンスファミリー (M4、T2、R3 など) に含まれる、任意のサイズの実行中である DB インスタンスに、自動的に適用されます。また、予約はシングル AZ またはマルチ AZ 配置オプションのいずれかで実行されている DB インスタンスにも適用されます。

例えば、db.m4.2xlarge の MySQL 予約を購入したとします。実行中の DB インスタンスを db.m4.4xlarge にスケールアップすることにした場合、この RI の割引率は大きい方の DB インスタンス使用量の 1/2 をカバーすることになります。

サイズの柔軟性を利用できない DB エンジンやライセンスモデル (Microsoft SQL Server、Oracle の「ライセンス込み」) を実行している場合、それぞれの予約は契約期間中に同じ属性を持つ DB インスタンスにのみ適用できます。予約期間が終了する前に実行中の DB インスタンスの属性を変更する場合は、その DB インスタンスに対する時間料金は、オンデマンドの時間料金に切り替わります。

サイズの柔軟性の詳細については、Amazon RDS ユーザーガイドを参照してください。

Q: 1 つのリージョンまたはアベイラビリティーゾーンから、別のリージョンまたはアベイラビリティーゾーンへ、リザーブドインスタンスを移動できますか?

各リザーブドインスタンスは、特定のリージョンに関連付けられています。これはリザーブドインスタンスの存続期間中固定されており、変更できません。ただし、それぞれの予約は、関連リージョン内のアベイラビリティーゾーンのいずれにおいても使用できます。

Q: リザーブドインスタンスはマルチ AZ 配置で利用できますか?

はい。DescribeReservedDBInstancesOfferings API、または describe-reserved-db-instances-offerings コマンドを呼び出す場合、購入時に利用可能な DB インスタンス構成に一覧表示された Multi-AZ オプションを探します。複数のアベイラビリティーゾーンにわたって同期レプリケーションされる DB インスタンスの予約を購入したい場合は、PurchaseReservedDBInstancesOffering 呼び出しで提供されるものから 1 つを指定します。

Q: リザーブドインスタンスは、リードレプリカでも利用できますか?

DB インスタンスクラスとリージョンが同じであれば、DB インスタンス予約はリードレプリカにも適用可能です。お客様の請求書を計算する際、AWS のシステムは、お客様の予約状態を自動的に適用して、該当するすべての DB インスタンスに低料金のリザーブドインスタンス料金を適用します。

Q: 予約はキャンセルできますか?

いいえ。リザーブド DB インスタンスはキャンセルできず、一括払いは (該当する場合) 返金不可能です。使用したかどうかにかかわらず、リザーブド DB インスタンスの期間が終了するまで、毎時間の料金をお支払いいただきます。

Q: 支払い方法によって料金請求はどのように変わりますか?

RI の購入時に、お支払い方法として「全前払い」を選択した場合は、RI の期間全体の料金を一括で前払いしていただきます。いっさい前払いなしにすることもでき、その場合は「前払いなし」を選択します。「前払いなし」の RI の価額総額が期間内の各時間に分配され、お客様へのご請求は使用の有無にかかわらず、期間内の 1 時間ごとに発生することになります。「一部前払い」は、「全前払い」と「前払いなし」の間をとったお支払い方法です。最初に少額をお支払いいただき、使用の有無にかかわらず、期間内の 1 時間ごとに低い時間単価で計算した料金請求が発生します。


Q: どの初期 DB インスタンスクラスおよびストレージ容量が私のニーズに適しているかをどのように判断できますか?

最初の DB インスタンスのクラスとストレージ容量を選択するには、アプリケーションでのコンピューティング、メモリ、およびストレージのニーズを評価する必要があります。利用できる DB インスタンスクラスの詳細については、Amazon RDS ユーザーガイドを参照してください。

Q: Amazon RDS データベースインスタンスに関連するコンピューティングリソースやストレージ容量をスケールするにはどうしたらよいですか?

DB インスタンスに割り当てるコンピューティングリソースとストレージ容量は、AWS マネジメントコンソール (任意の DB インスタンスを選択して [変更] ボタンをクリックする)、RDS API、AWS コマンドラインインターフェイスを使用してスケールできます。メモリおよび CPU リソースは、DB インスタンスを変更することにより修正され、ストレージ割り当てを修正すると、利用可能なストレージが変更されます。DB インスタンスクラスまたは割り当て済みストレージを修正すると、指定したメンテナンスウィンドウ期間にリクエストされた変更が適用されることにご注意ください。あるいは、「apply-immediately」フラグを使用して、拡張リクエストをすぐに適用することができます。他の未処理のシステム変更も適用されることにご注意ください。

Amazon CloudWatch により、追加料金なしで DB インスタンスのコンピューティングおよびストレージリソースの利用をモニタリングします。AWS マネジメントコンソールで DB インスタンスの [モニタリング] タブをクリックするか、Amazon CloudWatch API を使用して、CPU 使用量、ストレージ使用量、ネットワークトラフィックなどのメトリクスにアクセスできます。アクティブな DB インスタンスのモニタリングに関する詳細については、Amazon RDS ユーザーガイドをご覧ください。

なお、SQL Server については、Windows Server 環境に接続されるストライプ化ストレージの伸張性の制約が理由で、Amazon RDS でのストレージの増量は現時点ではサポートされていません。この機能は今後サポート対象となる予定ですが、ストレージのプロビジョニングは将来のストレージ成長を見越して行うことをお勧めします。当面は、SQL Server DB インスタンスのストレージを増量する必要がある場合、データをエクスポートし、ストレージを増量した新しい DB インスタンスを作成して、そのインスタンスにデータをインポートする必要があります。詳細については、SQL Server のデータインポートガイドを参照してください。

Q: Amazon RDS ストレージのハードウェア構成はどのようなものですか?

Amazon RDS は、データベースとログの格納に EBS ボリュームを使用します。要求されるストレージのサイズによって、Amazon RDS は自動的に複数の EBS ボリューム全体をストライプして、IOPS パフォーマンスを向上させます。MySQL と Oracle については、ストレージをスケールアップすると、既存の DB インスタンスの I/O 容量がある程度向上することがあります。AWS マネジメントコンソールModifyDBInstance APImodify-db-instance コマンド を使用して、DB インスタンスに割り当てられたストレージ容量をスケールできます。

ただし、SQL Server については、Windows Server 環境に接続されるストライプ化ストレージの伸張性の制約が理由で、Amazon RDS でのストレージの増量は現時点ではサポートされていません。

詳細については、Amazon RDS のストレージを参照してください。

Q: スケーリング中に DB インスタンスを使用できますか?

DB インスタンスに割り当てたストレージ容量は、DB インスタンスの可用性を維持しながら増やすことが可能です。しかし、DB インスタンスに対して利用可能なコンピューティングリソースをスケールアップまたはスケールダウンすることを決めると、DB インスタンスクラスが修正されている間にデータベースは一時的に利用できなくなります。この利用できない期間は一般的に数分で終了しますが、修正をすぐに適用することを指定しない限り、DB インスタンス用のメンテナンスウィンドウ期間に発生します。

Q: 最大 DB インスタンスクラスおよび最大ストレージ容量を超えて DB インスタンスをスケールするには、どのようにしたらよいですか?

Amazon RDS では、さまざまなアプリケーションニーズを満たすため、さまざまな DB インスタンスクラスおよびストレージ割り当てをサポートしています。アプリケーションが最大 DB インスタンスクラスよりも多くのコンピューティングリソースを必要としているか、最大割当量よりも大きなストレージを必要としている場合、パーティション化の実施が可能であり、複数の DB インスタンスにデータを分散することができます。

Q: Amazon RDS 汎用 (SSD) ストレージとは何ですか?

Amazon RDS 汎用(SSD)ストレージは、I/O 要件が中程度の幅広いデータベースワークロードに適しています。このストレージの選択肢は基準が 3 IOPS/GB で、最大 3,000 IOPS までバーストでき、ほとんどのアプリケーションのニーズに対応する予測可能なパフォーマンスを提供します。

Q: Amazon RDS プロビジョンド IOPS (SSD) ストレージとは何ですか?

Amazon RDS プロビジョンド IOPS (SSD) ストレージとは、高速かつ予測可能な一貫した I/O パフォーマンスを提供するよう設計された SSD ベースのストレージオプションです。Amazon RDS プロビジョンド IOPS (SSD) ストレージを使用する場合は、お客様が DB インスタンスの作成時に IOPS レートを指定します。Amazon RDS では、DB インスタンスが終了させられるまでその IOPS レートをプロビジョニングします。Amazon RDS プロビジョンド IOPS(SSD)ストレージは、大量の I/O が発生する、トランザクション指向(OLTP)のデータベースワークロードに最適です。詳しくは、Amazon RDS User Guide をご覧ください。

Q: Amazon RDS マグネティックストレージとは何ですか?

Amazon RDS マグネティックストレージは、データへのアクセスがあまり頻繁ではない軽度のデータベースワークロードに適しています。マグネティックストレージはプロダクションデータベースインスタンスには推奨されていません。

Q: Amazon RDS ストレージタイプはどのように選択すればよいですか?

ワークロードに最も適したストレージタイプを選択してください。

  • 高パフォーマンスの OLTP ワークロード: Amazon RDS プロビジョンド IOPS(SSD)ストレージ
  • 中程度の I/O 要件のデータベースワークロード: Amazon RDS 汎用(SSD)ストレージ

Q: Amazon RDS でサポートされる IOPS の最小値と最大値はどれくらいですか?

Amazon RDS でサポートされる IOPS は、データベースエンジンによって異なります。詳しくは、Amazon RDS User Guide を参照してください。

Q: 自動化バックアップと DB スナップショットの違いは何ですか?

Amazon RDS は、DB インスタンスのバックアップと復元を行うための 2 つの方法を提供しています。自動バックアップとデータベーススナップショット (DB スナップショット) です。

Amazon RDS の自動バックアップ機能によって、DB インスタンスのポイントインタイムリカバリが可能になります。DB インスタンスに対して自動バックアップがオンになっている場合、Amazon RDS は毎日、お客様のデータの完全なスナップショットを自動的に作成し (任意のバックアップウィンドウ中に実施)、トランザクションログを取得します (DB インスタンスに対する更新が実施される)。ポイントインタイムリカバリを開始する際、DB インスタンスをリクエストされた特定の時刻の状態に復元するために、最も適切なデイリーバックアップにトランザクションログを適用します。Amazon RDS は、DB インスタンスのバックアップを、ユーザーが指定する限られた期間 (保持期間) 中、保持します。保持期間はデフォルトでは 7 日間ですが、最大 35 日間に設定可能です。 保持期間中、特定時点への復旧を開始して、最大で復元可能な最新時刻 (Latest Restorable Time) まで、任意の秒数を指定することができます。 DescribeDBInstances API を使用して、DB インスタンスの復元可能な最新時刻まで戻ることができます。これは通常過去 5 分以内です。代わりに、AWS マネジメントコンソールで DB インスタンスを選択し、コンソールの下部にあるパネルの [Description] タブでこれを閲覧することによって、その DB インスタンスの復元可能な最新時刻を知ることもできます。

DB スナップショットはユーザーにより開始され、指定した頻度で既知の状態で DB インスタンスをバックアップすることができ、その後いつでもその特定の状態に復元することができます。DB スナップショットは、AWS マネジメントコンソールCreateDBSnapshot APIcreate-db-snapshot コマンドで作成可能であり、ユーザーが明示的に削除するまで保存できます。

自動バックアップを有効にするため Amazon RDS により実行されるスナップショットは、コピー (AWS コンソールまたは copy-db-snapshot コマンドを使用)、またはスナップショットの復元機能用に使用できます。スナップショットは、「自動」のスナップショットタイプを使用して探すことができます。また、「スナップショット撮影時刻」フィールドを確認すると、スナップショットが撮影された時刻を特定できます。また、"自動" スナップショットの識別子にも、スナップショットが作成された時刻 (UTC) が含まれます。

注意: 期間内のある時点へ、または DB スナップショットから復旧動作を実行すると、新しいエンドポイントを持つ新しい DB インスタンスが作成されます (必要な場合には、古い DB インスタンスは削除できます)。これを実行することにより、特定の DB スナップショットまたはポイントインタイムから、複数の DB インスタンスを作成できるようになります。

Q: DB インスタンスのバックアップは手動で有効にする必要がありますか? それとも自動でしょうか?

デフォルトでは、Amazon RDS により、7 日の保持期間で DB インスタンスの自動化バックアップを行うことができます。 無料のバックアップストレージは準備したデータベースのサイズに限定されており、アクティブな DB インスタンスのみに適用されます。 例えば、月をまたいで 100 GB のデータベースストレージが準備されていると、当社は追加料金なしで最大 100 GB/月のバックアップストレージを提供します。 バックアップ保持期間を 1 日以上に延長したい場合、(新しい DB インスタンスの作成時には CreateDBInstance API または(既存 DB インスタンスに対しては)ModifyDBInstance API で延長することができます。 これらの API を使用して、1日から希望する日数まで RetentionPeriod パラメータを変更することができます。自動化バックアップの詳細については、Amazon RDS ユーザーガイドを参照してください。

Q: バックアップウィンドウとは何ですか? なぜそれが必要ですか?バックアップウィンドウ期間で私のデータベースは利用できますか?

任意のバックアップウィンドウは、DB インスタンスをバックアップする、ユーザーが定義した期間です。Amazon RDS が、トランザクションログと併せてこれらの定期データバックアップを使用することにより、 お客様は、最大で復元可能な最新時刻 (LatestRestorableTime) (一般的には最大数分前) まで、保持期間中の任意の瞬間で DB インスタンスを復元できます。バックアップウィンドウ中に、バックアッププロセスの初期化が行われている間にストレージ I/O が一時中断 (通常 2~3 秒未満) することがあり、レイテンシーが短期間増加する可能性があります。マルチ AZ DB 配置では I/O 中断はありません。なぜならバックアップがスタンバイから取得されるためです。

Q: 自動バックアップと DB スナップショットの保存場所と保存内容を管理する方法について教えてください。

Amazon RDS DB スナップショットと自動バックアップは S3 に保存されます。

AWS マネジメントコンソールModifyDBInstance APImodify-db-instance コマンドを使用して、RetentionPeriod パラメータを修正することにより、自動化バックアップが保持される期間を管理できます。自動バックアップをすべて無効にしたい場合、保持期間を 0 に設定します (非推奨)。AWS RDS コンソールの [スナップショット] セクションを使用して、ユーザー作成 DB スナップショットを管理できます。代わりに、DescribeDBSnapshots APIdescribe-db-snapshots コマンドを使用して、指定 DB インスタンスのユーザー作成 DB スナップショット一覧を表示でき、DeleteDBSnapshot APIdelete-db-snapshot コマンドを使用して、スナップショットを削除できます。

Q: DB インスタンスを削除した場合、バックアップと DB スナップショットはどうなりますか?

DB インスタンスを削除するときに、最終的な DB スナップショットを作成できます。その場合、この DB スナップショットを使用して、削除された DB インスタンスを後日復元できます。Amazon RDS は、DB インスタンスが削除された後に、このユーザーが作成した最終的な DB スナップショットと、手動で作成されたその他の DB スナップショットをすべて保持します。バックアップストレージコストの詳細については、料金ページをご覧ください。

自動化されたバックアップは、DB インスタンスが削除されるときに削除されます。DB インスタンスの削除後に保持されるのは、手動で作成された DB スナップショットのみです。


Q: Amazon Virtual Private Cloud (VPC) とは何ですか? どのように Amazon RDS と連携しますか。

Amazon VPC を使用すると、AWS クラウドの分離したプライベートセクションに仮想ネットワーキング環境を作成できます。その環境では、プライベート IP アドレスの範囲、サブネット、ルーティングテーブル、ネットワークゲートウェイなど、さまざまな要素について全面的な制御を実行できます。Amazon VPC では、独自のデータセンターで運用している従来の IP ネットワークによく似るように、仮想ネットワークトポロジを定義し、ネットワーク設定をカスタマイズできます。

VPC を利用できる方法の 1 つは、プライベートサブネット内のパブリックにアクセスできないバックエンドサーバーを保守しながら、パブリックに公開されているウェブアプリケーションを実行する場合です。インターネットにアクセスできるウェブサーバ用にパブリック側のサブネットを作成し、インターネットアクセスできないプライベート側のサブネットにバックエンド RDS DB インスタンスを配置することができます。Amazon VPC の詳細については、Amazon Virtual Private Cloud ユーザーガイドを参照してください。

Q: Amazon RDS を VPC 内で使用することは、それを EC2-Classic プラットフォーム(非 VPC)上で使用することとどのように違いますか?

2013 年 12 月 4 日以前に作成した AWS アカウントでは、Amazon Elastic Compute Cloud (EC2)-Classic 環境で Amazon RDS を実行できる場合があります。Amazon RDS の基本機能は EC2-Classic を使用するか、EC2-VPC を使用するかにかかわらず同じです。Amazon RDS は、DB インスタンスが VPC 内外どちらにデプロイされるかにかかわらず、バックアップ、ソフトウェアのパッチ適用、自動障害検出、リードレプリカ、および復元を管理します。EC2-Classic と EC2-VPC の相違点の詳細については、EC2 のドキュメントを参照してください。

Q: DB サブネットグループの概要とそれが必要な理由は何ですか?

DB サブネットグループとは、VPC 内で RDS DB インスタンス用に指定するサブネットのコレクションです。各 DB サブネットグループには、特定の Region 内の Availability Zone ごとに 1 つ以上のサブネットを指定する必要があります。VPC 内に DB インスタンスを作成するときに、DB サブネットグループを選択する必要があります。選択すると、Amazon RDS は、その DB サブネットグループと設定した Availability Zone を使用し、サブネットとそのサブネット内の IP アドレスを選択します。Amazon RDS によって Elastic Network Interface が作成され、その IP アドレスを持つ DB インスタンスに関連付けられます。

基になる IP アドレスは変わる可能性があるので(フェイルオーバーなどの理由で)、DB インスタンスに接続するときは DNS 名を使用することを強くお勧めします。

Multi-AZ 配備の場合、Region 内のすべての Availability Zone 用にサブネットを定義すると、必要に応じて Amazon RDS で別の Availability Zone に新しいスタンバイを作成できるようになります。Single-AZ 配備の場合も、どこかの時点で Multi-AZ 配備に変換する場合に備えてこのように定義する必要があります。

Q: VPC では Amazon RDS DB インスタンスをどのように作成しますか?

このプロセスの詳細な手順については、Amazon RDS ユーザーガイドの 「VPC に DB イスタンスを作成する」を参照してください。

Q: DB インスタンスへのネットワークアクセスをどのようにコントロールしますか?

DB インスタンスのアクセスを制御する別の方法について詳しくは、Amazon RDS ユーザーガイドの「セキュリティグループ」を参照してください。

Q: VPC 内の RDS DB インスタンスにはどのように接続しますか?

VPC 内に展開した DB インスタンスには、同じ VPC に展開した EC2 インスタンスからアクセスできます。Elastic IP が関連付けられたパブリックサブネット内にこのような EC2 インスタンスをデプロイしている場合は、インターネットから EC2 インスタンスにアクセスできます。

VPC 内に展開した DB インスタンスには、インターネットからアクセスできるだけでなく、VPN またはパブリックサブネットで起動できる踏み台ホストを介して VPC 以外にある EC2 インスタンスからアクセスすることができます。また、Amazon RDS の Publicly Accessible オプションを使用してアクセスすることもできます。

  • 踏み台ホストを使用するには、SSH の踏み台として動作する EC2 インスタンスを使用してパブリックサブネットを設定する必要があります。このパブリックサブネットには、SSH ホストを介してトラフィックを制御できるインターネットゲートウェイまたはルーティングルールが必要です。また、その SSH ホストから RDS DB インスタンスのプライベート IP アドレスに要求を転送できる必要があります。
  • パブリックな接続を使用するには、Publicly Accessible オプションを yes に設定して DB インスタンスを作成します。Publicly Accessible をアクティブにすると、デフォルトにより、VPC の外部から VPC 内の DB インスタンスでアクセス可能になります。つまり、DB インスタンスへのアクセスを許可するように VPN または踏み台ホストを構成する必要はありません。

社内ネットワークを VPC に拡張する VPN ゲートウェイを設定して、その VPC 内の RDS DB インスタンスにアクセスできるようにする方法もあります。詳細については、Amazon VPC ユーザーガイドをご参照ください。

基になる IP アドレスは変わる可能性があるので(フェイルオーバーなどの理由で)、DB インスタンスに接続するときは DNS 名を使用することを強くお勧めします。

Q: VPC 以外にある既存の DB インスタンスを自分の VPC に移動できますか?

DB インスタンスが VPC 内に存在しない場合には、AWS マネジメントコンソールを使用して、VPC 内に DB インスタンスを簡単に移行できます。詳細については、Amazon RDS ユーザーガイドを参照してください。VPC 以外にある DB インスタンスのスナップショットを作成して、VPC に復元できます。それには、使用する DB サブネットグループを指定します。または、「特定時点への復元」オペレーションを実行することもできます。

Q: VPC 内にある既存の DB インスタンスを VPC 以外に移動できますか?

VPC 内から VPC 以外への DB インスタンスの移行はサポートされていません。セキュリティ上の理由から、VPC 内の DB インスタンスの DB スナップショットを VPC 以外の場所に復元することはできません。「特定時点への復元」機能も同様です。 

Q: VPC 内にある DB インスタンスをアプリケーションからアクセスできるようにするには、どのような注意事項がありますか?

ルーティングテーブルと VPC 内のネットワーキング ACL を変更して、VPC 内のクライアントインスタンスから DB インスタンスに到達できるようにする必要があります。

Multi-AZ 配備の場合、フェイルオーバー後に、クライアントの EC2 インスタンスと RDS DB インスタンスは異なる Availability Zone に属する可能性があります。そのため、AZ 間の通信が可能になるようにネットワーキング ACL を設定する必要があります。

Q: DB インスタンスの DB サブネットグループを変更できますか?

既存の DB サブネットグループを更新して、既存のアベイラビリティーゾーン用、または DB インスタンスの作成後に追加した新しいアベイラビリティーゾーン用にサブネットを追加できます。既存の DB サブネットグループからサブネットを削除すると、サブネットグループから削除される特定の AZ で実行されているインスタンスが利用できなくなります。詳細については、Amazon RDS ユーザーガイドを参照してください。

Q: Amazon RDS マスターユーザーアカウントとは何であり、AWS アカウントとはどのように違っていますか?

Amazon RDS の使用を始めるには、AWS 開発者アカウントが必要です。Amazon RDS のサインアップの前にアカウントを持っていない場合、サインアップ プロセスの開始時にアカウントを作成するよう要求されます。マスターユーザー アカウントは、AWS 開発者アカウントとは異なっており、DB インスタンスへのアクセスをコントロールするため、Amazon RDS の範囲内でのみ使用します。マスターユーザー アカウントは、DB インターフェイスへの接続に使用できる固有のデータベース ユーザー アカウントです。DB インスタンスの作成時に、各 DB インスタンスと関連付けたいマスターユーザー名とパスワードを指定することができます。一旦 DB インスタンスを作成すると、マスターユーザー証明書を使用してデータベースへ接続することができます。後で、追加のユーザー アカウントを作成したい場合があるので、DB インスタンスへアクセスできる人を制限することができます。

Q: 私の DB インスタンスについてマスターユーザーにどのような特権が認められていますか?

MySQL の場合、マスターユーザーのデフォルトの特権は、create、drop、references、event、alter、delete、index、insert、select、update、create temporary tables、lock tables、trigger、create view、show view、alter routine、create routine、execute、trigger、create user、process、show databases、grant option です。

Oracle の場合、マスターユーザーには「dba」の役割が付与されます。マスターユーザーは、ほとんどの役割に関連付けられた特権を継承します。制限された特権のリスト、およびその特権を必要とする管理タスクを実行するための代替方法については、Amazon RDS User Guide をご覧ください。

SQL Server の場合は、データベースを作成したユーザーに db_owner ロールが付与されます。制限された特権のリスト、およびその特権を必要とする管理タスクを実行するための代替方法については、Amazon RDS ユーザーガイドを参照してください。

Q: Amazon RDS によるユーザー管理について何か違いがありますか?

いいえ、お客様がリレーショナルデータベースを管理するときと同じ方法ですべて機能します。

Q: 自分のデータセンターのサーバー上で動作しているプログラムは Amazon RDS データベースにアクセスできますか?

はい。インターネットを介してデータベースにアクセスする機能は、セキュリティグループを設定して手動で有効にする必要があります。特定の IP、IP 範囲、またはお客様自身のデータセンターにあるサーバーに該当するサブネットに対してのみアクセスを認可することができます。

Q: SSL を用いて、アプリケーションと DB インスタンスの間の接続を暗号化できますか?

はい。このオプションは現在 MySQL、MariaDB、SQL Server、PostgreSQL、および Oracle エンジンでサポートされています。

Amazon RDS は、各 DB インスタンスに対して SSL 証明書を生成します。暗号化された接続が確立されたら、DB インスタンスとお客様のアプリケーション間で転送されるデータは、転送中に暗号化されるようになります。

SSL がセキュリティ上の利点を提供する一方で、SSL 暗号化がかなりの計算処理を必要とするオペレーションであり、お客様のデータベース接続の待ち時間を増加させることにご注意ください。また、Amazon RDS 内での SSL サポートは、アプリケーションと DB インスタンス間での接続暗号化のためにあることにご注意ください。これは DB インスタンスそのものの認証には使用しないでください。

Amazon RDS との暗号化された接続の確立について詳しくは、Amazon RDS の MySQL ユーザーガイドMariaDB ユーザーガイドSQL Server ユーザーガイドPostgreSQL ユーザーガイド または Oracle ユーザーガイド を参照してください。これらのエンジンでの SSL の動作について詳しくは、MySQL のドキュメントMariaDB のドキュメントMSDN SQL Server のドキュメントPostgreSQL のドキュメント、または Oracle のドキュメントを直接参照してください。

Q: Amazon RDS データベースで保管中のデータを暗号化できますか?

Amazon RDS では、AWS Key Management Service (KMS) で管理されるキーを使って、すべてのデータベースエンジンで保管時の暗号化をサポートしています。Amazon RDS 暗号化を使用して実行するデータベースインスタンスでは、基盤となるストレージに保管されるデータが、自動バックアップ、リードレプリカ、スナップショットとして暗号化されます。暗号化と復号は透過的に処理されます。Amazon RDS での KMS の使用に関する詳細は、Amazon RDS User's Guide を参照してください。

また、以前に暗号化されていない DB インスタンスや DB クラスターに暗号化を追加するには、DB スナップショットを作成してからそのコピーを作成し、KMS 暗号化キーを指定します。こうすることで、この暗号化されたスナップショットから暗号化された DB インスタンスまたは DB クラスターを復元できます。

Oracle および SQL Server 用 Amazon RDS では、それぞれのエンジンの Transparent Data Encryption テクノロジーがサポートされます。Oracle の Transparent Data Encryption は、AWS CloudHSM と統合されています。これにより、AWS クラウド内のシングルテナントの Hardware Security Module (HSM) アプライアンスで安全に暗号化キーを生成、保管、管理できます。詳細については、Amazon RDS User's Guide の OracleSQL Server の各セクションを参照してください。

Q: 特定の RDS リソースに対してシステムとユーザーが実行できるアクションを制御するには、どうすればよいですか?

RDS リソースに対して AWS IAM ユーザーとグループが実行できるアクションを制御できます。制御するには、ユーザーとグループに適用している AWS IAM ポリシーの RDS リソースを参照します。AWS IAM ポリシーで参照できる RDS リソースには、DB インスタンス、DB スナップショット、リードレプリカ、DB セキュリティグループ、DB オプショングループ、DB パラメータグループ、イベントサブスクリプション、DB サブネットグループが含まれます。また、これらのリソースにタグを付けて、追加のメタデータをリソースに追加できます。タグを使用すると、リソースを分類し(「開発用」DB インスタンス、「本稼働用」DB インスタンス、「テスト用」DB インスタンスなど)、同じタグが設定されたリソースに対して適用する権限を登録した AWS IAM ポリシーを作成することができます。詳細については、Managing Access to Your Amazon RDS Resources and Databases および Tagging Amazon RDS Resources をご覧ください。

Q: RDS デプロイメントに関するセキュリティ分析またはオペレーションのトラブルシューティングを実行したいと考えています。自分のアカウントで実行したすべての RDS API 呼び出しの履歴を取得することはできますか?

はい。AWS CloudTrail はアカウントに対する AWS API 呼び出しを記録し、ログファイルを配信するウェブサービスです。CloudTrail で生成される AWS API の呼び出し履歴を利用して、セキュリティの分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。CloudTrail の詳細については、AWS CloudTrail の詳細ページを参照してください。CloudTrail を有効にするには、CloudTrail の AWS マネジメントコンソールのホームページにアクセスしてください。


Q: DB インスタンス用に適切な設定パラメータを選択するには、どうすればよいですか?

Amazon RDS では、デフォルトでインスタンスクラスとストレージ容量が考慮され、DB インスタンスに最適の設定パラメータが選択されます。ただし、変更する場合には AWS マネジメントコンソール、Amazon RDS API、AWS コマンドラインインターフェイスを使用します。推奨値からの設定パラメータの変更は、性能の低下からシステムクラッシュまで、予期しない影響を生じる場合があり、これらのリスクを想定できる上級ユーザーのみが行えることにご注意ください。

Q: DB パラメータグループとは何ですか?それらはどのように役立ちますか?

データベース パラメータグループ(DB パラメータグループ)は、1つ以上の DB インスタンスに適用可能なエンジン設定値の「容器」として動作します。DB パラメータのグループを指定せずに DB インスタンスを作成する場合、デフォルトの DB パラメータグループが使用されます。このデフォルト値のグループは、お客様が実行している DB インスタンス用に最適化されたエンジンデフォルト値と Amazon RDS システムデフォルト値を持っています。しかし、カスタム指定のエンジン設定値で DB インスタンスを実行したい場合、新しい DB パラメータグループを作成し、必要なパラメータを修正し、新しい DB パラメータグループを使用するため DB インスタンスを修正するだけで十分です。いったん関連付けが行われると、特定の DB パラメータグループを使用するすべての DB インスタンスは、その DB パラメータグループへのすべてのパラメータアップデートを取得します。

DB パラメータグループの設定の詳細については、Amazon RDS ユーザーガイドを参照してください。

Q: Amazon RDS リソースの設定をどのようにモニタリングできますか?

AWS Config を使用して、Amazon RDS DB インスタンス、DB サブネットグループ、DB スナップショット、DB セキュリティグループ、イベントサブスクリプションの設定変更を継続的に記録し、Amazon Simple Notification Service (SNS) によって変更通知を受け取ることが可能です。AWS Config Rules を作成して、これらの RDS リソースが理想的な設定になっているかどうかを評価できます。


Q: Amazon RDS がサポートしているのはどのタイプのレプリケーションですか? また、各タイプはどのような場合に使用すべきですか?

Amazon RDS では、使用目的が異なる 2 つのレプリケーションオプションが提供されています。

計画外の機能停止が発生した際にデータベースの最新の更新状態を保ちながら、レプリケーションを使用してデータベースの可用性を高める場合は、DB インスタンスをマルチ AZ 配置として実行することを考慮します。DB インスタンスを作成または修正してマルチ AZ 配置として実行する場合、Amazon RDS は異なるアベイラビリティーゾーンに "スタンバイ" レプリカを自動的にプロビジョニングして管理します (各インフラストラクチャは物理的に離れた場所に存在)。予定されたデータベースメンテナンスの場合や、DB インスタンスまたはアベイラビリティーゾーンに障害が発生した場合は、Amazon RDS は自動的にスタンバイに対してフェイルオーバーを行い、データベース運用を手動の管理介入なしですぐに再開できるようにします。Multi-AZ 配備は、同期レプリケーションを活用して、データベースへの書き込みをプライマリとセカンダリで同時に行い、フェイルオーバーが発生した場合にスタンバイが最新の状態を保つようにしています。Multi-AZ DB インスタンスに対する当社の技術革新により障害発生時のデータ耐久性を最大化したことで、スタンバイに直接アクセスしたり、読み込み操作に使用されなくなりました。Multi-AZ 配置によって実現する耐障害性は、本番環境に最適です。

読み込み負荷の高いデータベースワークロードに単一 DB インスタンスの能力が対応しきれない場合にキャパシティーの制約を超えてスケールするように、Amazon RDS にはリードレプリカが用意されています。AWS マネジメントコンソール、RDS API、AWS コマンドラインインターフェイスを使用すると、与えられたソース DB インスタンスのリードレプリカを作成できます。リードレプリカを作成すると、データベースがソース DB インスタンスを更新して、リードレプリカにプロパゲートされます。1 つのソース DB インスタンスに対して複数のリードレプリカを作成して、アプリケーションの読み込みトラフィックをこれらのレプリカに分散できます。

リードレプリカは、Amazon Aurora、Amazon RDS for MySQL、MariaDB、および PostgreSQL でサポートされています。 マルチ AZ 配置とは異なり、これらのエンジンのリードレプリカは、各エンジンに組み込まれているレプリケーションテクノロジーを使いますが、これには、その長所と制限が反映されます。特に、更新は、ソース DB インスタンスに更新した後にリードレプリカに反映されるため ("非同期" レプリケーション)、レプリケーションラグは大幅に異なる場合があります。つまり、標準 (マルチ AZ でない) ソース DB インスタンスに対して行われる最新のデータベース更新は、ソース DB インスタンスで計画外の機能停止が発生した場合に、対応するリードレプリカには存在しなくなる可能性があります。そのような場合、リードレプリカは、Multi-AZ 配備が提供するものと同じデータ耐久性を提供できません。リードレプリカによって読み取りの可用性は高まりますが、書き込みの可用性を提供するよう設計されたものではありません。

マルチ AZ 配置とリードレプリカを組み合わせると、それぞれの特長の相乗効果が得られます。マルチ AZ 配置をリードレプリカのソース DB インスタンスに指定すれば、これを実現できます。この方法により、Multi-AZ 配備のデータ耐久性と可用性、およびリードレプリカの読込み能力の拡大という両面の利点を得ることができます。

Q: DB インスタンスをマルチ AZ 配置として実行することにどのような意味がありますか?

マルチ AZ 配置として実行するように DB インスタンスを作成または修正すると、Amazon RDS では、同期 "スタンバイ" レプリカが別のアベイラビリティーゾーンで自動的にプロビジョニングされ、管理されます。DB インスタンスに対する更新は、別のアベイラビリティーゾーンにあるスタンバイに同時にレプリケートされるため、同期が維持されるとともに、最新のデータベース更新が DB インスタンスの障害から保護されます。特定の種類の計画的なメンテナンスの期間中や、DB インスタンスの障害もしくはアベイラビリティーゾーンの障害といった予期せぬイベントが発生した際には、Amazon RDS はスタンバイに対して自動的にフェイルオーバーし、スタンバイが昇格したら直ちにデータベースの読み込みと書き込みを再開できるようにします。DB インスタンスの名前レコードは変化しないため、アプリケーションによるデータベースオペレーションは、管理者による手動での介入なしで再開できます。Multi-AZ 配備を使うと、レプリケーションが透過的になります。スタンバイを直接操作しなくなり、読み込みトラフィックには使えなくなります。Multi-AZ 配置の詳細については、Amazon RDS ユーザーガイドをご覧ください。

Q: アベイラビリティーゾーンとは何ですか?

Availability Zones とは、別の Availability Zone で発生した障害から隔離するために作られたリージョン内の場所です。各 Availability Zone は、その独自の、物理的にはっきりと独立したインフラストラクチャ上で稼動しています。また高い信頼性を保つように設計されています。発電機や冷却装置などの障害対策用装置がアベイラビリティーゾーン間で共有されることはありません。さらに、これらは物理的にそれぞれ別々の場所にあるため、火災、竜巻、または洪水などの極めて稀な災害でも、影響を受けるのは1つの Availability Zone のみです。同一リージョンにある Availability Zone は、待ち時間が短いネットワーク接続を提供します。

Q: マルチ AZ 配置のコンテキストにおいて "プライマリ" と "スタンバイ" は何を意味しますか?

DB インスタンスをマルチ AZ 配置として実行する場合、"プライマリ" はデータベースに読み込みと書き込みの機能を提供します。さらに、Amazon RDS は、背後で「スタンバイ」を設定して管理します。これはプライマリの最新レプリカになります。スタンバイはフェイルオーバー時に(プライマリに)「昇格」します。フェイルオーバー後、スタンバイはプライマリとなり、お客様のデータベースオペレーションを受け付けるようになります。昇格前には、どの時点においても、スタンバイと直接やりとり(例: 読み込みオペレーション)することはありません。単一の DB インスタンスの容量制限を超えて読み込みトラフィックをスケーリングする方法に関心のあるお客様は、リードレプリカのよくある質問をご覧ください。

Q: マルチ AZ 配置の利点は何ですか?

DB インスタンスをマルチ AZ 配置として実行することの主な利点は、データベースの耐久性と可用性を向上することです。マルチ AZ 配置によって高められる可用性と耐障害性は、本番環境に最適です。

DB インスタンスをマルチ AZ 配置として実行すると、万一 DB インスタンスコンポーネントに障害が発生した場合や、特定のアベイラビリティーゾーンで可用性が失われた場合でも、データの安全が守られます。例えば、プライマリ上のストレージボリュームが障害を受ける場合、Amazon RDS はスタンバイに対して自動的にフェイルオーバーを開始し、お客様のデータベース更新はそのスタンバイですべて完全な状態に保たれます。 これは、単一のAZにおける標準配備と比較した場合、さらなるデータ堅牢性を提供するものです。単一の AZ における標準配備では、ユーザーによって開始される復元オペレーションが必要で、復元可能な最新時刻(一般的には過去5分以内)後に発生した更新は利用できません。

データベースの可用性を向上できることも、DB インスタンスをマルチ AZ 配置として運用する場合の利点の 1 つです。アベイラビリティーゾーンの障害または DB インスタンスの障害が発生した場合、可用性が影響を受けるのは、自動フェイルオーバーが完了するまでの間のみです。Multi-AZ の可用性に対する恩恵は、計画されたメンテナンスにも拡大されます。例えば、自動バックアップでは、バックアップがスタンバイから取得されるため、お好みのバックアップウィンドウで、プライマリ上での I/O アクティビティが中断されることはありません。パッチの適用や DB インスタンスクラスのスケーリングを行う場合、これらのオペレーションは、自動フェイルオーバーの前にスタンバイで最初に行われます。結果的に、可用性が影響を受けるのは、自動フェイルオーバーが完了するのに必要な時間に限定されます。

DB インスタンスをマルチ AZ 配置として実行することによる暗黙の利点は他にもあります。それは、DB インスタンスのフェイルオーバーが自動で行われ、手動管理が必要ないことです。Amazon RDS のコンテキストでは、これはアベイラビリティーゾーンや DB インスタンスの障害時に、(RestoreDBInstanceToPointInTime または RestoreDBInstanceFromSnapshot API を使用して) DB インスタンスのイベントをモニタリングし、手動で DB インスタンスの復旧を開始する必要がないことを意味します。

Q: DB インスタンスをマルチ AZ 配置として実行するとパフォーマンスに影響はありますか?

実行される同期的データレプリケーションの結果として、単一のアベイラビリティーゾーンにおける標準 DB インスタンスの配置と比較した場合、レイテンシーが増加する可能性があります。

Q: DB インスタンスをマルチ AZ 配置として実行する場合、読み込みまたは書き込みオペレーションのためにスタンバイを使用できますか?

いいえ。スタンバイのレプリカは読み込みリクエストに対応していません。Multi-AZ 配備は、読み込み機能の拡張による恩恵よりも、データベースの可用性と堅牢性の強化を提供するよう設計されています。そのため、この機能はプライマリとスタンバイの間で同期するレプリケーションを行います。当社の実装では、プライマリとスタンバイが常に同期するようにしてありますが、スタンバイを読み込みまたは書き込みオペレーションのために使用する機能は除外しています。読み込みのスケーリングソリューションに興味がある場合は、リードレプリカに関するよくある質問をご覧ください。

Q: マルチ AZ DB インスタンス配置のセットアップはどのように行うのですか?

マルチ AZ DB インスタンス配置を作成するには、AWS マネジメントコンソールで DB インスタンスを起動する際に、[マルチ AZ 配置] で [はい] のオプションをクリックするだけです。代わりに、Amazon RDS API を使用している場合は、CreateDBInstance API を呼び出して "マルチ AZ" のパラメータの値を "true" に設定することもできます。既存の標準 (単一 AZ) DB インターフェイスをマルチ AZ に変換するには、AWS マネジメントコンソールで DB インスタンスを修正するか、ModifyDBInstance API を使用してマルチ AZ のパラメータを true に設定します。

Q: RDS インスタンスをシングル AZ からマルチ AZ に変換すると何が発生しますか?

RDS MySQL、MariaDB、PostgreSQL、および Oracle のデータベースエンジンについては、RDS インスタンスを Single-AZ から Multi-AZ に変換すると、次のことが発生します。

  • プライマリインスタンスのスナップショットが取得されます。
  • そのスナップショットから新しいスタンバイインスタンスが別のアベイラビリティーゾーンに作成されます。
  • 同期レプリケーションがプライマリインスタンスとスタンバイインスタンスとの間に構成されます。

結果として、インスタンスが Single-AZ から Multi-AZ に変換される際には、ダウンタイムは発生しません。

Q: Amazon RDS によるスタンバイレプリカへのフェイルオーバーは、どのようなイベントのときに発生しますか?

Amazon RDS では、マルチ AZ 配置における一般的な障害シナリオの検出とリカバリが自動的に行われるので、管理者の介入は不要でデータベース操作を可能な限りすみやかに再開できます。Amazon RDS によって自動的にフェイルオーバーが実行されるのは、次のことが発生したときです。

  • プライマリ利用可能ゾーンの可用性損失
  • プライマリに対するネットワーク接続の喪失
  • プライマリ上でのコンピュートユニット障害
  • プライマリへのストレージ不良

注: DB インスタンスのスケーリングやシステムアップグレード (OS のパッチ適用など) がマルチ AZ 配置に対して行われるときは、可用性を高めるために、これらが最初にスタンバイに適用されて、その後で自動フェイルオーバーが実行されます。したがって、可用性への影響が現れるのは自動フェイルオーバーを完了するのに必要な時間までとなります。なお、Amazon RDS マルチ AZ 配置での自動フェイルオーバーは、データベース操作におけるエラー(長時間実行クエリ、デッドロック、データベース破損など)の発生に対しては行われません。

Q: 自動フェイルオーバーが発生するときに警告がありますか?

はい。Amazon RDS では DB インスタンスイベントが発行され、自動フェイルオーバーの発生が通知されます。Amazon RDS コンソールの [イベント] セクションをクリックするか、DescribeEvents API を使用して、DB インスタンスに関係のあるイベントについての情報を返すことも可能です。Amazon RDS Event Notifications を使って、特定の DB イベントが発生したときに、通知を受け取ることも可能です。

Q: マルチ AZ のフェイルオーバー中どのようなことが起き、どれくらいの間継続しますか?

フェイルオーバーは Amazon RDS によって自動的に処理されるため、管理上の手動介入なく、可能な限り迅速にデータベースオペレーションを再開することができます。フェイルオーバーの際には、Amazon RDS は単純に DB インスタンスの正規名レコード (CNAME) を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。ベストプラクティスに従い、アプリケーションレイヤーでデータベース接続のリトライを実施することを推奨いたします。

フェイルオーバーは、プライマリで障害が検出されてからスタンバイでトランザクションが再開されるまでの間隔として定義され、通常 1 ~ 2 分以内に完了します。コミットされていない大きなトランザクションを回復させる必要があるかどうかによっても、フェイルオーバー時間は異なります。最適の結果を得るには、マルチ AZ では十分に大きなインスタンスタイプを使用することをお勧めします。また、高速かつ予測可能で、安定したスループットパフォーマンスを得るには、マルチ AZ インスタンスとともにプロビジョニングされた IOPS を使用することをお勧めします。

Q: マルチ AZ DB インスタンス配置に対して "強制フェイルオーバー" を開始できますか?

Amazon RDS は、さまざまな障害状態のときにユーザー介入なしで自動的にフェイルオーバーを行います。さらに、Amazon RDS ではインスタンスが再起動されたときにフェイルオーバーを開始することもできます。この機能にアクセスするには、AWS マネジメントコンソールを使用するか、RebootDBInstance API 呼び出しを使用してください。

Q: マルチ AZ の同期的レプリケーションはどのようにコントロール/設定するのですか?

Multi-AZ 配備を使用する場合、[Multi-AZ] パラメータを真に設定するだけです。スタンバイ、同期的レプリケーションおよびフェイルオーバーの作成は、すべて自動的に処理されます。つまり、スタンバイが配置されているアベイラビリティーゾーンを選択したり、利用可能なスタンバイ数を変更したりすることはできません (Amazon RDS は、DB インスタンスプライマリごとに 1 つの専用スタンバイを設定します)。また、スタンバイは、データベースの読み取りアクティビティを許可するよう設定できません。マルチ AZ 配置の詳細についてはこちらをご覧ください。

Q: 私のスタンバイは私のプライマリと同一のリージョンになりますか?

はい。スタンバイは、同一リージョンの異なるアベイラビリティーゾーンにおいて、DB インスタンスプライマリとして自動的にプロビジョニングされます。

Q: 私のプライマリが現在どのアベイラビリティーゾーンなのかを確認できますか?

はい。AWS マネジメントコンソールまたは DescribeDBInstances API を使用することで、現在のプライマリロケーションを視認することができます。

Q: フェイルオーバー後、私のプライマリは、私の他の AWS リソース (例: EC2 インスタンス) とは異なるアベイラビリティーゾーンに所在しています。レイテンシーについて心配する必要がありますか?

Availability Zones は、同一リージョンの別の Availability Zones に対して、待ち時間が短いネットワーク接続を提供するよう設計されています。さらに、1つの Availability Zone でのサービス障害時にお客様のアプリケーションが回復力を持つように、複数の Availability Zone 全体で冗長性を持つアプリケーションや他AWリソースの設計を考慮したいかもしれません。Multi-AZ 配備は、お客様サイドでの管理作業なく、データベースに対するこのニーズを解決します。

Q: DB スナップショットと自動バックアップは、マルチ AZ 配置とどのように連携するのですか?

自動バックアップと DB スナップショットの機能の扱い方は、単一 AZ での標準的な配置とマルチ AZ 配置のどちらで実行するかにかかわらず同一です。マルチ AZ 配置で実行している場合は、自動バックアップと DB スナップショットはスタンバイから取得されます。これは、プライマリでの I/O 中断を避けるためです。なお、単一 AZ とマルチ AZ のどちらの配置の場合も、バックアップ取得中は I/O レイテンシーが増加する可能性があることにご注意ください(一般的には数分で元に戻ります)。

復元操作(特定時点への復元または DB スナップショットからの復元)についても、マルチ AZ 配置での機能は標準の単一 AZ 配置の場合と同じです。新しい DB インスタンスの配置は、RestoreDBInstanceFromSnapshot または RestoreDBInstanceToPointInTime API のどちらかで作成できます。これらの新しい DB インスタンスの配置は、ソースバックアップが標準配置で開始されていようと、マルチ AZ 配置で開始されていようと、それとは無関係に標準またはマルチ AZ のどちらかに設定できます。

Q: DB インスタンスをリードレプリカとして実行することに、どのような意味がありますか?

リードレプリカは、サポートされるエンジンに組み込まれているレプリケーション機能を使って、単一の DB インスタンスの容量制限を弾性的に拡大してデータベースの読み込み負荷を緩和させることができます。ユーザーは、AWS マネジメントコンソールで数回クリックするか、CreateDBInstanceReadReplica API を使って、リードレプリカを作成できます。リードレプリカを作成すると、データベースは、サポートされるエンジンのネイティブ非同期レプリケーション機能を使ってソース DB インスタンスを更新します。1 つのソース DB インスタンスに対して複数のリードレプリカを作成して、アプリケーションの読み込みトラフィックをこれらのレプリカに分散させます。リードレプリカは、サポートされるエンジンに組み込まれているレプリケーション機能を使用するため、その長所と制限が反映されます。特に、更新は、ソース DB インスタンスを更新した後にリードレプリカに反映されるため、レプリケーションが大幅に異なる場合があります。リードレプリカは、Multi-AZ 配備に関連付けて、Multi-AZ 配備が提供するデータの書込み可用性と耐用性に加え読込み性能を拡大することができます。

Q: Amazon RDS リードレプリカの使用を検討すべきなのはどのような場合ですか?

与えられた DB インスタンスで正しく機能するためにリードレプリカを配備する場所は様々です。リードレプリカを配備する一般的な理由:

  • 読込みが多いデータベースに対して1つの DB インスタンスの処理または入出力機能を拡張します。これにより過度の読込みトラフィックを1つまたは複数のリードレプリカに誘導することができます。
  • ソース DB インスタンスが利用可能でない場合に読込みトラフィックを誘導します。お客様のソース DB インスタンスが入出力リクエストを取ることができない(バックアップまたは定期メンテナンスによる入出力一時停止のため)、読込みトラフィックをリードレプリカに誘導することができます。このような使用の場合、リードレプリカのデータは、ソース DB インスタンスが利用可能でないために、「古い」場合があるため注意が必要です。
  • ビジネスレポーティング、またはデータウェアハウジングでは、プライマリプロダクション DB インスタンスではなく、ビジネスレポーティングクエリーをリードレプリカに対して実行します。

Q: リードレプリカを作成する前に、DB インスタンスで自動バックアップを有効にする必要がありますか?

はい。リードレプリカを追加する前に、バックアップ保持期間を 0 以外の値に設定して、DB インスタンスの自動バックアップを有効にします。リードレプリカを動作させるには、バックアップを有効にする必要があります。

Q: Amazon RDS リードレプリカをサポートするのはデータベースエンジンのどのバージョンですか?

Amazon Aurora (MySQL): すべての DB インスタンス。

Amazon RDS for MySQL: MySQL バージョン 5.5 以降の DB インスタンスで、リードレプリカの作成がサポートされます。リードレプリカの操作のためには、ソース DB インスタンスで自動バックアップを有効にしておく必要があります。自動バックアップは、MySQL 5.6 以降 (5.5 は対象外) を実行する Amazon RDS リードレプリカでのみサポートされます。

Amazon RDS for PostgreSQL: PostgreSQL バージョン 9.3.5 以降の DB インスタンスで、リードレプリカの作成がサポートされます。Amazon RDS リードレプリカを利用するには、バージョン 9.3.5 より前の既存の PostgreSQL インスタンスを PostgreSQL バージョン 9.3.5 にアップグレードする必要があります。

Amazon RDS for MariaDB: MariaDB 10.0 以降の DB インスタンスで、リードレプリカの作成がサポートされます。リードレプリカの操作のためには、ソース DB インスタンスで自動バックアップを有効にしておく必要があります。

Q: 指定された DB インスタンスにリードレプリカをどのようにデプロイしますか?

標準の CreateDBInstanceReadReplica API を使う、または Amazon マネジメントコンソールで数回クリックするだけで数分でリードレプリカを作成できます。リードレプリカを作成する時は、SourceDBInstanceIdentifier を指定してリードレプリカを特定することができます。SourceDBInstanceIdentifier は、レプリケーションしたい「ソース」DB インスタンスを特定する DB インスタンス識別子です。標準 DB インスタンスと同様に、Availability Zone、DB インスタンスのクラス、推奨するメンテナンスウィンドウも指定できます。エンジンのバージョン(PostgreSQL 9.3.5 など)とリードレプリカの記憶域割り当ては、ソース DB インスタンスから継承されます。リードレプリカの作成を開始すると、Amazon RDS は、お客様のソース DB インスタンスのスナップショットを撮り、レプリケーションを開始します。その結果、スナップショットを撮る間、ソース DB インスタンスに軽度の入出力停止が発生します。入出力の一時停止は、通常 1 分程度です。ソース DB インスタンスがマルチ AZ 配置の場合は、回避されます(マルチ AZ 配置の場合は、スタンバイのスナップショットがあります)。Amazon RDS では、現在も最適化の作業が行われています (近日中に公開予定)。複数のリードレプリカを 30 分の範囲内で作成した場合、すべてのリードレプリカのソーススナップショットは同じになり、入出力の影響は最小限になります。(それぞれのリードレプリカに対する「キャッチアップ」レプリケーションは作成後に開始されます)。

Q: 自分のリードレプリカにどのように接続しますか?

DescribeDBInstance API または AWS Management Console を使ってリードレプリカに対するエンドポイントを読み出して標準 DB インスタンスと接続するのと同じようにリードレプリカを接続します。リードレプリカが複数ある場合、読込みトランザクションがどのように誘導されるかはアプリケーションに依存します。

Q: 与えられたソース DB インスタンスに対して、いくつのリードレプリカが作成可能ですか?

現在、Amazon Aurora (MySQL) では、特定のソース DB インスタンスに対して、最大 15 個のリードレプリカを作成できます。

現在、Amazon RDS for MySQL、MariaDB、PostgreSQL では、特定のソース DB インスタンスに対して、最大 5 個のリードレプリカを作成できます。

Q: ソース DB インスタンスとは異なる AWS リージョンにリードレプリカを作成できますか?

はい、RDS ではリージョン間のリードレプリカがサポートされます。

Q: Amazon RDS リードレプリカは同期レプリケーションをサポートしますか?

いいえ。Amazon RDS for MySQL、MariaDB、PostgreSQL のリードレプリカは、これらのエンジンのネイティブの非同期レプリケーションを使用して実装されています。 Amazon Aurora では別の (ただし非同期) のレプリケーションメカニズムが使用されます。

Q: リードレプリカを使って、障害が発生した場合のデータベースを書き込んだり、自分のソース DB インスタンスの保護を強化することはできますか?

レプリケーションを使ってデータベースの書き込み性能を強化し、さまざまな障害条件に対してデータベースの最新状態を保護するためには、DB インスタンスをマルチ AZ 配置として実行することをお勧めします。サポートされるエンジンのネイティブな非同期レプリケーションを使用する Amazon RDS リードレプリカでは、データベースの書き込みがソース DB インスタンスで既に発生した後にリードレプリカで発生するため、このレプリケーションの「遅延」は状態に応じてかなり異なります。その反面、Multi-AZ 配備が使うレプリケーションは同期しています。つまり、すべてのデータベース書込みはプライマリとスタンバイで同時に行われます。こうしてデータベース更新の最新状態を保護し、障害が発生した場合にスタンバイが利用可能であるようにします。さらに、Multi-AZ 配備のレプリケーションは、完全に管理されています。Amazon RDS では DB インスタンスの障害条件や Availability Zone の障害が自動的に監視され、機能停止が発生すると、スタンバイ (Amazon Aurora の場合はリードレプリカ) への自動フェイルオーバーが開始されます。

Q: リードインスタンスのソースとしてマルチ AZ DB インスタンス配置を持つリードレプリカを作成できますか?

はい。Multi-AZ DB インスタンスはリードレプリカとは異なるニーズに対処するため、プロダクション展開で双方を使用して、リードレプリカを Multi-AZ DB インスタンスに関連付けることは理にかなっています。「ソース」 Multi AZ-DB インスタンスは、書込み可用性とデータの耐久性を強化し、関連するリードレプリカは、読込みトラフィックの拡張性を向上します。

Q: Amazon RDS リードレプリカ自体を Multi-AZ にできますか?

Amazon RDS for MySQL、MariaDB、PostgreSQL では、現在この機能はサポートされていません。

Q: 自分のリードレプリカがマルチ AZ DB インスタンス配置をソースとして使用する場合、マルチ AZ フェイルオーバーが発生した場合にどうなりますか?

マルチ AZ フェイルオーバーが発生した場合、関連するリードレプリカ、および利用可能なリードレプリカは、フェイルオーバーが完了すると、自動的にレプリケーションを再開します (新たに昇格したプライマリから更新を取得します)。

Q: 別のリードレプリカのリードレプリカを作成できますか?

Amazon Aurora、Amazon RDS for MySQL、MariaDB:: 既存の第 1 層リードレプリカから第 2 層リードレプリカを作成できます。第 2 層リードレプリカを作成すると、マスターデータベースインスタンスからのレプリケーション負荷の一部を第 1 層リードレプリカに移動することができます。ただし、トランザクションはマスターから第 1 層レプリカにレプリケートされてから、第 2 層レプリカにレプリケートされ、レプリケーションのレイテンシーが増えるため、第 2 層リードレプリカはマスターよりも遅延する可能性があります。

Amazon RDS for PostgreSQL: 現在、リードレプリカのリードレプリカはサポートされていません。

Q: リードレプリカでデータベースの読み取りオペレーションのみを受け付けるようにすることはできますか?

リードレプリカは、読込みトラフィックを誘導するためのものです。ただし、上級ユーザーがリードレプリカに対してデータ定義言語(DDL) SQL 記述を完了したい場合があります。例えば、同じインデックスに対応するソース DB インスタンスに追加せずに、ビジネスレポーティングに使用されるリードレプリカにデータベースインデックスを追加する場合などです。

Amazon RDS for MySQL は、リードレプリカに対する DDL SQL ステートメントを許可するように設定できます。与えられたリードレプリカに対して読み込み以外の操作を有効にする場合は、リードレプリカに対してアクティブ DB パラメータグループを変更し、「read_only」パラメータを「0」に設定します。

現在、Amazon RDS for PostgreSQL はリードレプリカに対する DDL SQL ステートメントの実行をサポートしていません。

Q: リードレプリカを "スタンドアロン" DB インスタンスに昇格できますか?

はい。詳細については、『Amazon RDS User Guide』をご覧ください。

Q: リードレプリカはソース DB インスタンス最新状態と同一に保たれますか?

ソース DB インスタンスの更新は、あらゆる関連したリードレプリカに対して自動的にレプリケーションされます。ただし、サポートされているエンジンの非同期レプリケーションテクノロジーを使うと、様々な理由によりリードレプリカがソース DB インスタンスより遅れることがあります。一般的な理由:

  • ソース DB インスタンスへの書込みの入出力量が設定した値を超えた場合の変更がリードレプリカに適応されることがあります。(この問題は、リードレプリカの処理能力がソース DB インスタンスより低い場合に発生する場合があります)
  • ソース DB インスタンスへの複雑または長期間のトランザクションがリードレプリカのレプリケーションを発生させる
  • ネットワーク パーティションまたはソース DB インスタンス間の待ち時間とリードレプリカ

リードレプリカには、サポートされるエンジンのネイティブなレプリケーションの長所と短所が反映されます。リードレプリカを使う場合は、リードレプリカとそのソース DB インスタンスの間に遅延または「矛盾」が発生する可能性があることを理解していなければなりません。リードレプリカとソース間の遅延が大きくなった場合にどうすべきかに関するガイダンスは、ここをクリックしてください。

Q: アクティブなリードレプリカのステータスはどのように表示されますか?

標準の DescribeDBInstances API を使用すると、デプロイ済みのすべての DB インスタンス (リードレプリカを含む) のリストが返されます。または Amazon RDS Console の「DB Instances」タブをクリックします。

Amazon RDS には、リードレプリカがそのソース DB インスタンスからどの程度遅れているかを知るための機能があります。リードレプリカがマスターより遅れている秒数は Amazon CloudWatch メトリクス(「レプリカラグ」)として公開され、AWS マネジメントコンソールまたは Amazon CloudWatch API から閲覧できます。Amazon RDS for MySQL の場合、この情報ソースは、リードレプリカに対して標準の「Show Slave Status」 MySQL コマンドを発行することで表示されるものと同じです。Amazon RDS for PostgreSQL の場合、ソース DB インスタンスで pg_stat_replication ビューを使用して、レプリケーションのメトリクスを調べることができます。

Amazon RDS がリードレプリカのレプリケーション状態をモニタリングします。AWS マネジメントコンソールの [Replication State] フィールドが [Error] に更新された場合は、レプリケーションが何らかの理由で停止していることを示します(例: レプリカに対して試みた DML クエリが、マスターデータベースインスタンスでの更新と競合する場合は、レプリケーションエラーとなることがあります)。MySQL エンジンによってスローされた、対応するエラーの詳細を確認するには、[Replication Error] フィールドを調べます。この情報に基づいて、回復のための適切な措置をとります。レプリケーションの問題のトラブルシューティングの詳細は、Amazon RDS for MySQL または PostgreSQL のユーザーガイド「リードレプリカの問題のトラブルシューティング」セクションを参照してください。

レプリケーションエラーが解決すると、[レプリケーションの状態] は [レプリケーション中] に変化します。

Q: リードレプリカがソース DB インスタンスから大幅に遅れています。どうすればよいですか?

前の質問で説明した通り、リードレプリカとそのソース DB インスタンス間の「矛盾」または遅延は、非同期レプリケーションでも同様です。既存のリードレプリカで、お客様の要求に対して大幅な遅延が発生した場合は、そのリードレプリカを削除してから、同じ DB インスタンス識別子およびソース DB インスタンス識別子を削除したリードレプリカとして使用して同じエンドポイントを持つ新しいリードレプリカを作成します。この時、この再生プロセスは、遅延が小さい場合(5分以下の遅延など)では非生産的であるため、注意して使用する必要があります。(例えば、リードレプリカがそのソース DB インスタンスから大幅に遅延した場合のみに使用する、など)また、レプリカの遅延は、ソース DB インスタンスの定常状態の使用パターンにより自然に成長し、時間と共に収縮することも留意してください。

リードレプリカの DB インスタンスクラスを拡張すると、同じ状態、特に、ソース DB インスタンスのクラスがリードレプリカ DB インスタンスのクラスより大きい場合のレプリケーションラグを減少します。ただし、リードレプリカは、すべての状況下で機能するとは限りません。また、リードレプリカを作成してから絶対にそのソースに追いつけない、またはお客様のユースケース要件を満たす状態から大幅に遅れてしまうシナリオおよび使用パターンがあります。

Q: 使用するソース DB インスタンスの処理およびストレージ容量を拡張しました。それに伴い、関連するリードレプリカのリソースも拡張すべきですか?

レプリケーションが正しく機能するためには、リードレプリカに可能な限り多くの対応するソース DB インスタンスのコンピュートとストレージリソースを持たせてください。そうしないと、レプリケーションラグが増加する可能性が増える、またはリードレプリカがレプリケーションした更新を格納するスペースが足りなくなります。

Q: DB スナップショットまたは自動化バックアップはリードレプリカに対して実行できますか?

いいえ。ソース DB インスタンスではなくリードレプリカのバックアップを取ることでデータベースの書込み能力を強化したい場合は、DB インスタンスを Multi-AZ 配備として実行することにより、同じ目的が達成できます。バックアップは、Multi-AZ スタンバイから起動され、可用性の影響を最小限にすることができます。

Q: リードレプリカはどのように削除しますか? ソース DB インスタンスを削除すると自動削除されますか?

AWS マネジメントコンソールで数回クリックするか、DB インスタンスの識別子を DeleteDBInstance API に渡すと、簡単にリードレプリカを削除できます。

Amazon Aurora (MySQL) のリードレプリカはアクティブ状態のままとなり、対応するソース DB インスタンスが削除された後も読み込みトラフィックを受け入れ続けます。 クラスター内にあるリードレプリカのうちいずれかが自動的に新しいマスターに昇格し、書き込みトラフィックの受け入れを開始します。

Amazon RDS for MySQL または Amazon RDS for MariaDB のリードレプリカは、アクティブ状態のままとなり、対応するソース DB インスタンスが削除された後も読み込みトラフィックを受け入れ続けます。ソース DB インスタンスと同時にリードレプリカも削除する場合は、DeleteDBInstance API または AWS マネジメントコンソールを使って明示的に行う必要があります。

リードレプリカがある Amazon RDS for PostgreSQL の DB インスタンスを削除すると、すべてのリードレプリカがスタンドアロン DB インスタンスに昇格されて、読み込みトラフィックと書き込みトラフィックの両方を受け付けることができるようになります。新しく昇格された DB インスタンスは、相互に独立して動作します。元のソース DB インスタンスに加えてこれらの DB インスタンスを削除する場合は、DeleteDBInstance API または AWS マネジメントコンソールを使って明示的に行う必要があります。

Q: 自分のデータベースインスタンスに直接アクセスして自分のレプリケーションを管理できますか?

Amazon RDS for MySQL または Amazon RDS for MariaDB を使用して、DB インスタンスからバイナリログのダウンロードやストリーミングが可能です。Amazon RDS for PostgreSQL では、現在 DB インスタンスの WAL ファイルへのアクセスは提供されていません。

Q: リードレプリカの価格はいくらですか? 請求はいつ開始され、いつ終了しますか?

リードレプリカは、標準 DB インスタンスと同じ料金で請求されます。DB インスタンスの請求に関する情報については、この FAQ をご参照ください。標準 DB インスタンスと同様、リードインスタンスに対する "DB インスタンス時間" ごとの料金は、リードレプリカの DB インスタンスクラスで決まります。最新の料金情報については、Amazon RDS 詳細ページを参照してください。ソース DB インスタンスとリードレプリカ間のデータレプリケーションに発生したデータ転送に対しては請求されません。

リードレプリカの請求は、リードレプリカを作成(一覧のステータスが「アクティブ」になるなど)してから開始します。リードレプリカは、削除するコマンドを発行するまで標準 Amazon RDS DB インスタンスの時間料金で請求されます。

Q: リードレプリカのサポートは、その機能をサポートする Amazon RDS エンジン間でどのように異なりますか?

Amazon RDS for PostgreSQL、MySQL、MariaDB のリードレプリカは、読み込み負荷の高いデータベースワークロードに単一 DB インスタンスの能力が対応しきれない場合、弾力的にスケールアウトできます。これらはエンジンのネイティブ機能を使用するので、実装には同じ部分と異なる部分があります。詳細については次の表を参照してください。

機能 PostgreSQL MySQL MariaDB
ソース DB インスタンスごとに許される最大リードレプリカ数
5 5 5
レプリケーション方法 非同期
物理
非同期
論理
非同期
論理
リードレプリカをサポートするために自動バックアップを有効にする必要があるか?
リードレプリカを使用できるエンジンのバージョン 9.3.5 以降 5.5 以降 10.0 以降
新しいスタンドアロン DB インスタンスへのリードレプリカの昇格 サポート対象 サポート対象 サポート対象
リードレプリカでのインデックスの作成 現在は非サポート サポート対象 サポート対象
リードレプリカのバックアップの作成 現在は非サポート サポート対象 サポート対象
リードレプリカのチェーン
(つまり、リードレプリカのリードレプリカ)
現在は非サポート サポート対象 サポート対象
リージョン間のリードレプリカ サポート対象 サポート対象 サポート対象

Q: RDS の拡張モニタリングとは何ですか?

RDS の拡張モニタリングによって、RDS インスタンスの状況をより詳細に可視化できます。RDS DB インスタンスの [拡張モニタリング] オプションを有効にし、詳細度を設定すれば、指定された間隔でオペレーティングシステムの重要なメトリクスとプロセス情報が拡張モニタリングによって収集されます。

Q: 拡張モニタリングではどのようなメトリクスとプロセスをモニタリングできますか?

拡張モニタリングでは、特に CPU、メモリ、ファイルシステム、ディスク I/O といった、RDS インスタンスのシステムレベルのメトリクスが収集されます。メトリクスのリストはここからご覧ください。

Q: 拡張モニタリングではどのようなエンジンがサポートされていますか?

拡張モニタリングでは、すべての RDS データベースエンジンがサポートされています。

Q: 拡張モニタリングではどのようなインスタンスタイプがサポートされていますか?

拡張モニタリングでは、t1.micro と m1.small を除くすべてのインスタンスタイプがサポートされています。このソフトウェアでは、少量の CPU、メモリ、I/O が消費されます。一般的な目的でのモニタリングでは、中規模または大規模のインスタンスに対して高い詳細度を有効にすることをお勧めします。本番以外の環境の DB インスタンスでは、拡張モニタリングはデフォルトで「オフ」に設定されています。そのまま無効にしておくことも、オンにして詳細度を変更することも可能です。

Q: RDS ダッシュボードにはどのような情報が表示されますか?

RDS DB インスタンスのすべてのシステムメトリクスとプロセス情報を、コンソールのグラフィック形式で表示できます。各インスタンスについてモニタリングするメトリクスを管理し、必要に応じてダッシュボードをカスタマイズすることができます。

Q: RDS アカウント内のすべてのインスタンスの詳細度が同じになるのですか?

いいえ。RDS アカウント内のそれぞれの DB インスタンスに、個別に詳細度を設定できます。どのインスタンスに対して拡張モニタリングを有効にするかも選択でき、必要なときにはいつでも各インスタンスに対する詳細度を変更できます。

Q: RDS コンソールではメトリクスの履歴をどれほど前までさかのぼれますか?

すべてのメトリクスのパフォーマンス値を最大 1 時間前まで参照できます。詳細度は設定に基づいて最大 1 秒間です。

Q: RDS 拡張モニタリングで生成されたメトリクスを CloudWatch でどのように可視化できますか?

RDS 拡張モニタリングからのメトリクスは、CloudWatch Logs アカウントに配信されます。CloudWatch 内で、CloudWatch Logs からメトリクスフィルターを作成し、CloudWatch ダッシュボードに表示できます。詳細については、Amazon CloudWatch のページにアクセスしてください。

Q: RDS コンソールダッシュボードではなく CloudWatch を使用するのはどのようなケースですか?

RDS コンソールダッシュボードで利用できる履歴データよりも前のデータが必要な場合、CloudWatch の使用が必要です。RDS インスタンスを CloudWatch でモニタリングすることで、AWS スタック全体の状況について 1 つの場所で診断できます。現在のところ、CloudWatch でサポートされている詳細度は最高 1 分間隔で、それよりも詳細度の短い場合は平均値になります。

Q: 特定のメトリクスに基づいてアラームと通知をセットアップすることはできますか?

はい。アラームの状態が変化したときに通知を送信するアラームを CloudWatch に作成できます。アラームは、指定期間にわたって単一のメトリクスを監視し、その値と複数期間に対するしきい値との比較結果に基づいて 1 つ以上のアクションを実行します。CloudWatch アラームの詳細については、Amazon CloudWatch 開発者用ガイドをご覧ください。

Q: 現在使用中のツールに拡張モニタリングを統合するにはどのようにすればよいですか?

RDS 拡張モニタリングでは、CloudWatch Logs アカウントに配信される JSON ペイロードとして形成されるメトリクス一式が提供されています。JSON ペイロードは、その RDS インスタンスに最後に設定された詳細度で配信されます。

サードパーティ製のダッシュボードやアプリケーションでそれらのメトリクスを利用するには、2 種類の方法があります。モニタリングツールでは、CloudWatch Logs Subscriptions を使用することで、メトリクスについてリアルタイムに近いフィードをセットアップできます。別の方法として、CloudWatch Logs のフィルターを使用してメトリクスを CloudWatch にブリッジし、アプリケーションを CloudWatch と統合することもできます。詳細については、Amazon CloudWatch のドキュメントを参照してください。

Q: 履歴データはどのようにしてし消去できますか?

拡張モニタリングでは JSON ペイロードが CloudWatch Logs アカウントのログに配信されます。このため、他の CloudWatch Logs ストリームと同じように保持期間を制御できます。CloudWatch Logs では、拡張モニタリングのデフォルト保持期間が 30 日間に設定されています。保持期間の変更方法の詳細については、Amazon CloudWatch 開発者ガイドをご覧ください。

Q: 拡張モニタリングを利用すると、毎月の料金にどのような変化が発生しますか?

メトリクスは CloudWatch Logs に取り込まれるため、CloudWatch Logs 無料利用枠を超過した部分の料金については、CloudWatch Logs のデータ転送レートおよびストレージレートに基づいて決まります。料金の詳細については、こちらをご覧ください。ある RDS インスタンスについて転送される情報の量は、拡張モニタリング機能に設定された詳細度に直接比例します。管理者はアカウント内の各インスタンスの詳細度を個別に設定して、コストを管理できます。

1 つのインスタンスに対する拡張モニタリングによって CloudWatch Logs に取り込まれるデータ量の概算を以下に示します。

詳細度

60 秒

30 秒

15 秒

10 秒

5 秒

1 秒

CloudWatch Logs に取り込まれるデータ* (GB/月)

0.27

0.53

1.07

1.61

3.21

16.07

Q: Oracle 用 Amazon RDS では、どのようなタイプのライセンスオプションを利用できますか?

Oracle 用 Amazon RDS を使用するために利用できるライセンスオプションには 2 つのタイプがあります。

  • 自分のライセンス使用(BYOL): このライセンスモデルでは、既存の Oracle データベースのライセンスを使用して Amazon RDS で Oracle を実行することができます。BYOL モデルの DB インスタンスを実行するには、DB インスタンスのクラスと実行する Oracle Database のエディションに適切な Oracle Database のライセンス(ソフトウェア更新のライセンスとサポート付き)を持っている必要があります。また、クラウドコンピューティング環境での Oracle Database ソフトウェアのライセンス化に関する Oracle のポリシーに従う必要があります。Amazon EC2 環境における DB インスタンスおよび Amazon EC2 用の Oracle のライセンスポリシーはここでご覧になれます。
  • ライセンス込み: 「ライセンス込み」サービスモデルでは、Oracle のライセンスを個別に購入する必要はありません。Oracle データベースのソフトウェアは、AWS によってライセンス化されています。"ライセンス込み" 料金には、ソフトウェア、ハードウェアリソース、および Amazon RDS 管理機能の使用料金が含まれています。

Q: Amazon RDS for Oracle では、Oracle データベースのどのエディションを利用できますか?

Amazon RDS は現在、下の各ライセンスモデルにおいて、以下の Oracle データベースのエディションをサポートしています。

  • BYOL: Standard Edition Two (SE2)、Standard Edition One (SE1)、Standard Edition (SE)、および Enterprise Edition (EE)
  • ライセンス込み: スタンダードエディション1(SE1)

Q: Amazon RDS for Oracle のライセンスポリシーはどのようなものですか?

  • BYOL: BYOL モデルの DB インスタンスを実行するには、DB インスタンスクラスおよび実行する Oracle データベースのエディション用の適切な Oracle データベースのライセンス(ソフトウェアアップデートのライセンスおよびサポート付き)を持っている必要があります。また、クラウドコンピューティング環境での Oracle データベースのソフトウェアのライセンス化に関する Oracle のポリシーに従う必要があります。Amazon EC2 環境における DB インスタンスおよび Amazon EC2 用の Oracle のライセンスポリシーはここでご覧になれます。
  • ライセンス込み: 「ライセンス込み」サービスモデルでは、Oracle のライセンスを個別に購入する必要はありません。Oracle データベースのソフトウェアは、AWS によってライセンス化されています。

Q: Amazon RDS for Oracle はどのようにサポートされていますか?

  • BYOL: このモデルでは、アクティブな Oracle サポートアカウントを継続してご使用いただけます。Oracle データベースの特定のサービスリクエストに関しては、直接 Oracle にご連絡ください。アクティブな AWS Premium Support のアカウントをお持ちの場合、Amazon RDS 固有の問題については、AWS Premium Support にご連絡ください。Amazon Web Services と Oracle には、両方の組織からの援助が必要な場合のために、マルチベンダーサポートプロセスがあります。
  • ライセンス込み: このモデルでは、アクティブな AWS Premium Supportのアカウントをお持ちの場合は、Amazon RDS と Oracle データベース両方の特定のサービスリクエストに関しては、AWS Premium Supportにお問い合わせください。

Q: DB インスタンスのライセンスオプションを変更 (例えば、「BYOL」から「ライセンス込み」に) できますか?

はい、ライセンスのオプションは変更することができます。ただし、最後のスナップショットで現在の DB インスタンスを削除し、必要な新しいライセンスオプションを指定して、そのスナップショットから新しい DB インスタンスを作成する必要があります。