Amazon RDS よくある質問

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

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

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

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

デフォルトにより、お客様は合計 40 個までの Amazon RDS DB インスタンスを保有することができます。この 40 個のうち、最大 10 個を「ライセンス込み」モデルの RDS for Oracle または RDS for SQL Server DB インスタンスにすることができます。40 台すべてを Amazon Aurora、PostgreSQL 用 RDS、MySQL 用 RDS、MariaDB 用の RDS、および RDS for Oracle 用を Bring Your Own License (BYOL) モデルで使用できます。RDS for SQL Server では、単一の DB インスタンス上でのデータベース数は 100 に限定されています。詳細については、Amazon RDS for SQL Server ユーザーガイドを参照してください。

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

Amazon RDS にデータをインポートする方法はいくつかあります。

• MySQL: mysqldump または mysqlimport ユーティリティー
• Oracle: データポンプ、インポート/エクスポート、または SQL ローダー
• SQL Server: インポート/エクスポートウィザード、フルバックアップファイル (.bak)、または一括コピープログラム (BCP)
• PostgreSQL: pg_dump

データのインポートとエクスポートの詳細については MySQL のデータインポートガイド、Oracle のデータインポートガイド、SQL Server のデータインポートガイド、PostgreSQL のデータインポートガイド、または Db2 のデータインポートガイドをご覧ください。

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

DB インスタンスの修正、データベースエンジンバージョンのアップグレード、ソフトウェアパッチの適用が発生する場合、コントロールを行う機会として、Amazon RDS メンテナンスウィンドウを利用できます。メンテナンスイベントが特定の週に予定されている場合、お客様が特定する保守管理時間枠の間に開始されます。

Amazon RDS によってお客様の DB インスタンスをオフラインにする必要があるメンテナンスイベントは、コンピューティングのスケーリングオペレーション (通常、開始から終了までの所要時間は数分)、データベースエンジンバージョンのアップグレード、必須のソフトウェアのパッチ適用です。安全性と堅牢性に関連するパッチに関してのみ、必須のソフトウェアパッチ適用が自動的にスケジューリングされます。このようなパッチは頻繁に発生するものではありません（通常数ヵ月ごとに一度です）。またお客様のメンテナンスウィンドウのごく一部以外を使用する必要があることは稀なはずです。

DB インスタンスの作成時点で希望する毎週のメンテナンスウィンドウが指定されていない場合は、30 分のデフォルト値が割り当てられます。メンテナンスの実行時に修正する場合は、AWS マネジメントコンソール、ModifyDBInstance API、modify-db-instance コマンドで DB インスタンスを修正することで実行できます。各 DB インスタンスには、任意で異なるメンテナンスウィンドウを設定できます。

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

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

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

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

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

サポートされるデータベースエンジンのバージョンのリストは、各エンジンのドキュメントを参照してください。

• Amazon Aurora
• Amazon RDS for PostgreSQL
• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS for SQL Server
• Amazon RDS for Oracle
• Amazon RDS for Db2

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

• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon RDS for Oracle
• Amazon RDS for SQL Server
• Amazon Aurora
• Amazon RDS for Db2

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

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

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

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

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

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

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

マルチ AZ インスタンスであっても DB エンジンバージョンのアップグレードにあたってはダウンタイムが発生するため、お客様が対応を計画できるようにアップグレードをスケジュールしています。マイナーバージョンの自動アップグレードをオフにする場合は、[Auto Minor Version Upgrade] 設定を [No] に設定してください。

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

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

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

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

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

AWS では、定期的にメジャーまたはマイナーのエンジンバージョンの廃止を行います。メジャーバージョンは、少なくとも対応するコミュニティバージョンが終了するか、ソフトウェアの修正またはセキュリティアップデートが行われなくなるまで利用できるようにします。マイナーバージョンについては、そのマイナーバージョンに、以降のバージョンで解決された重大なバグやセキュリティ上の問題が含まれている場合に廃止します。

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

Amazon RDS でデータベースエンジンのマイナーバージョンが廃止される場合、発表から自動アップグレード開始まで 3 か月の期間が設定されます。この期間が終了すると、廃止されるマイナーバージョンを実行しているすべてのインスタンスには、スケジュールされたメンテナンスウィンドウ内に、サポート対象となっている最新のマイナーバージョンへの自動アップグレードスケジュールが設定されます。

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

場合によっては、特定のメジャーバージョンまたはマイナーバージョンが、当社の高い品質、パフォーマンス、またはセキュリティの水準を満たさないことが判明した場合など、事前の通知なしに廃止とされることがあります。万一このようなケースが発生した場合には、Amazon RDS はこれらのバージョンによる新しいデータベースインスタンスおよびクラスターの作成を中止します。既存のお客様は、引き続きデータベースの運用が可能です。特定の状況では、対処すべき問題によって別のスケジュールを決定する可能性があります。

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

• DB インスタンス時間 – 消費された DB インスタンスのクラス (例: db.t2.micro、db.m4.large など) に基づいています。 DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の消費された DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。さらなる詳細は、新機能のお知らせをご覧ください。
• ストレージ (/GB/月) – DB インスタンスに対してプロビジョニングしたストレージ容量。プロビジョニングしたストレージ容量を当月にスケールした場合、請求は日割り料金となります。
• I/O リクエスト/月 – ストレージ I/O リクエストの合計 (Amazon RDS Magnetic ストレージおよび Amazon Aurora のみ)
• プロビジョンド IOPS/月 – 消費 IOPS とは無関係な、プロビジョンド IOPS レート (Amazon RDS プロビジョンド IOPS (SSD) ストレージのみ)
• バックアップストレージ – バックアップストレージは、自動化されたデータベースバックアップや、お客様の作成したデータベーススナップショットに関連付けられたストレージです。バックアップ保持期間を増やしたり、追加のデータベーススナップショットを取得したりすれば、お客様のデータベースが使用するバックアップストレージは増大します。
• データ転送 – DB インスタンスのインターネット経由のデータ受信および送信です。

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

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

利用可能な状態で DB インスタンスが動作している各時間に対して、DB インスタンス時間が請求されます。これ以上 DB インスタンスへの課金を望まない場合は、追加のインスタンス時間に対して請求されないよう、DB インスタンスを停止するか、終了する必要があります。 DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の消費された DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。

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

無料のバックアップストレージは、リージョン全体にわたって、アカウントのプロビジョニングされたデータベースストレージの合計まで提供されます。例えば、同じリージョン、同じアカウントで、MySQL DB インスタンスのプロビジョニングされたストレージが月間 100 GB、PostgreSQL DB インスタンスのプロビジョニングされたストレージが月間 150 GB ある場合、このアカウントとリージョンのバックアップストレージ 250 GB を追加料金無しで提供します。この量を超えるバックアップストレージに対してのみ課金されます。

毎日、お客様のアカウントのリージョン内のプロビジョニングされたデータベースストレージの合計と、リージョン内のバックアップストレージの合計が比較され、超過分のバックアップストレージのみが課金されます。例えば、毎日ちょうど 10 GB のバックアップストレージが余っている場合、その月のバックアップストレージは 10 GB 月分として課金されます。あるいは、毎日 300 GB のプロビジョニングされたストレージがあり、毎日 500 GB のバックアップストレージがあるが、月の半分しかない場合、課金は毎日計算され (日割り計算)、バックアップは 1 か月間にわたり存在しなかったので、100 GB 月分のバックアップストレージのみが課金されます (200 GB 月ではありません)。無料のバックアップストレージは、アカウント固有、リージョン固有であることにご注意ください。

バックアップのサイズは、お客様のインスタンス上のデータ量に正比例します。例えば、100 GB のプロビジョニングされたストレージを持つ DB インスタンスを持っているが、その上に 5 GB のデータしか保存していない場合、最初のバックアップは約 5 GB にしかなりません (100 GB ではありません)。それ以降のバックアップは増分であり、DB インスタンスに変更されたデータのみを保存します。バックアップのストレージサイズは RDS Console にも DescribeDBSnapshots API のレスポンスにも表示されないことに注意してください。

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

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

• マルチ AZ DB インスタンス時間 – 消費された DB インスタンスのクラス (例: db.t2.micro、db.m4.large など) に基づいています。単一のアベイラビリティーゾーンにおける標準的なデプロイと同様に、DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の消費された DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。特定の 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 インスタンスの受信および送信におけるインターネットのデータ転送は、標準配置と同様に課金されます。

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

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

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

はい。同時に複数の 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 料金が課金されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

はい。リザーブドインスタンスを購入すると、購入可能な DB インスタンス設定でのマルチ AZ オプションを選択できます。さらに、リザーブドインスタンスのサイズ柔軟性をサポートする DB エンジンとライセンスモデルを使用している場合、マルチ AZ リザーブドインスタンスにはシングル AZ DB インスタンス２つが含まれます。

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

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

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

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

DB インスタンスに割り当てるコンピューティングリソースとストレージ容量は、AWS マネジメントコンソール (任意の DB インスタンスを選択して [変更] ボタンをクリックする)、Amazon RDS API、AWS コマンドラインインターフェイスを使用してスケールできます。メモリおよび CPU リソースは、DB インスタンスを変更することにより修正され、ストレージ割り当てを修正すると、利用可能なストレージが変更されます。 

DB インスタンスクラスまたは割り当て済みストレージを修正すると、指定したメンテナンスウィンドウ期間にリクエストされた変更が適用されることにご注意ください。あるいは、「apply-immediately」フラグを使用して、拡張リクエストをすぐに適用することができます。他の未処理のシステム変更も適用されることにご注意ください。

一部の古い RDS for SQL Server インスタンスは、拡張ストレージに対応していない可能性があります。詳細については、「RDS for SQL Server のよくある質問」を参照してください。

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

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

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

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

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

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 ユーザーガイドを参照してください。

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

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

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

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

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 API、create-db-snapshot コマンドで作成可能であり、ユーザーが明示的に削除するまで保存できます。

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

また、"自動" スナップショットの識別子にも、スナップショットが作成された時刻 (UTC) が含まれます。

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

デフォルトでは、Amazon RDS により、7 日の保持期間で DB インスタンスの自動化バックアップを行うことができます。バックアップ保持期間を変更したい場合、(新しい DB インスタンスの作成時には) RDS コンソール、CreateDBInstance API を使用して、(既存のインスタンスに対しては) ModifyDBInstance API を使用して、変更することができます。これらのメソッドを使用して、RetentionPeriod パラメータを 0 (自動バックアップを無効にする) から任意の日数までの数 (最大 35 日) に変更できます。DB インスタンスがリードレプリカのソースである場合は、値を 0 に設定することはできません。自動化バックアップの詳細については、Amazon RDS ユーザーガイドを参照してください。

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

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

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

リテンション期間の日数よりも 1 日か 2 日自動化 DB のスナップショットの日数が多いのは正常です。自動化スナップショットは 1 日余計にとられていて、リテンション期間中のいつにでも復帰できる時点を設けています。

例えば、バックアップウィンドウが 1 日に設定されている場合、自動化スナップショットは 2 つ必要で、これで過去 24 時間中の任意の時点への復帰をサポートしています。また、さらに多くの自動化スナップショットがある場合もありますが、これは新たな自動化スナップショットが、最も古い自動化スナップショットを削除する前に常に生成されるためです。。

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

DB インスタンスを削除すると、バックアップ保持期間の満了まで自動バックアップを保持できます。詳細については、「Retaining automated backups」をご覧ください。

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

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

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 のドキュメントを参照してください。

DB サブネットグループとは、VPC 内で Amazon RDS DB インスタンス用に指定するサブネットのコレクションです。各 DB サブネットグループには、特定の Region 内のアベイラビリティゾーンごとに 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 配備に変換する場合に備えてこのように定義する必要があります。

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

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

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

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

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

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

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

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

ルーティングテーブルと VPC 内のネットワーキング ACL を変更して、VPC 内のクライアントインスタンスから DB インスタンスに到達できるようにする必要があります。 マルチ AZ 配置の場合は、フェイルオーバー後に、クライアントの EC2 インスタンスと Amazon RDS DB インスタンスは異なるアベイラビリティゾーンに属する可能性があります。そのため、AZ 間の通信が可能になるようにネットワーキング ACL を設定する必要があります。

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

Amazon RDS の使用を始めるには、AWS デベロッパーアカウントが必要です。Amazon RDS のサインアップの前にアカウントを持っていない場合、サインアップ プロセスの開始時にアカウントを作成するよう要求されます。プライマリユーザー アカウントは、AWS 開発者アカウントとは異なっており、DB インスタンスへのアクセスをコントロールするため、Amazon RDS の範囲内でのみ使用します。プライマリユーザー アカウントは、DB インターフェイスへの接続に使用できる固有のデータベース ユーザー アカウントです。 

DB インスタンスの作成時に、各 DB インスタンスと関連付けたいプライマリユーザー名とパスワードを指定することができます。一旦 DB インスタンスを作成すると、プライマリユーザー証明書を使用してデータベースへ接続することができます。後で、追加のユーザー アカウントを作成したい場合があるので、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 ユーザーガイドをご覧ください。

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

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

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

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

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

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

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

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

Amazon RDS for Oracle および Amazon RDS for SQL Server では、それぞれのエンジンの Transparent Data Encryption (TDE) テクノロジーがサポートされます。詳細については、Amazon RDS ユーザーガイドの Oracle と SQL Server を参照してください。

Amazon RDS リソースに対して AWS IAM ユーザーとグループが実行できるアクションを制御できます。制御するには、ユーザーとグループに適用している AWS IAM ポリシーの Amazon RDS リソースを参照します。AWS IAM ポリシーで参照できる Amazon RDS リソースには、DB インスタンス、DB スナップショット、リードレプリカ、DB セキュリティグループ、DB オプショングループ、DB パラメータグループ、イベントサブスクリプション、DB サブネットグループが含まれます。 

また、これらのリソースにタグを付けて、追加のメタデータをリソースに追加できます。タグを使用すると、リソースを分類し (「開発用」 DB インスタンス、「本稼働用」 DB インスタンス、「テスト用」 DB インスタンスなど)、同じタグが設定されたリソースに対して適用するアクセス許可を登録した AWS IAM ポリシーを作成することができます。詳細については、Amazon RDS リソースのタグ付けを参照してください。

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

はい、Amazon RDS データベースは HIPAA に適格ですので、これらを使って HIPAA 準拠のアプリケーションを作り、ヘルスケア関連情報を格納できます。こうした情報には AWS の Business Associate Agreement (BAA) で保護された医療情報 (PHI) も含みます。

既に BAA を締結している場合は、BAA の適用を受けているアカウントでこのサービスの使用を開始するために何も行う必要はありません。AWS と BAA を締結していない場合や、AWS の HIPAA 準拠アプリケーションについてご不明な点がある場合は、お客様のアカウントマネージャーにお問い合わせください。

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

データベース パラメータグループ（DB パラメータグループ）は、1つ以上の DB インスタンスに適用可能なエンジン設定値の「容器」として動作します。DB パラメータのグループを指定せずに DB インスタンスを作成する場合、デフォルトの DB パラメータグループが使用されます。このデフォルト値のグループは、お客様が実行している DB インスタンス用に最適化されたエンジンデフォルト値と Amazon RDS システムデフォルト値を持っています。

しかし、カスタム指定のエンジン設定値で DB インスタンスを実行したい場合、新しい DB パラメータグループを作成し、必要なパラメータを修正し、新しい DB パラメータグループを使用するため DB インスタンスを修正するだけで十分です。いったん関連付けが行われると、特定の DB パラメータグループを使用するすべての DB インスタンスは、その DB パラメータグループへのすべてのパラメータアップデートを取得します。

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

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

マルチ AZ 配置として実行するように DB インスタンスを作成または修正すると、Amazon RDS では、同期 "スタンバイ" レプリカが別のアベイラビリティゾーンで自動的にプロビジョニングされ、管理されます。DB インスタンスに対する更新は、別のアベイラビリティゾーンにあるスタンバイに同時にレプリケートされるため、同期が維持されるとともに、最新のデータベース更新が DB インスタンスの障害から保護されます。 

特定の種類の計画的なメンテナンスの期間中や、DB インスタンスの障害もしくはアベイラビリティーゾーンの障害といった予期せぬイベントが発生した際には、Amazon RDS はスタンバイに対して自動的にフェイルオーバーし、スタンバイが昇格したら直ちにデータベースの読み込みと書き込みを再開できるようにします。DB インスタンスの名前レコードは変化しないため、アプリケーションによるデータベースオペレーションは、管理者による手動での介入なしで再開できます。マルチ AZ 配置のレプリケーションは透過的です。スタンバイと直接やり取りすることはできません。また、スタンバイを読み取りトラフィックの処理に使用することはできません。マルチ AZ 配置の詳細については、Amazon RDS ユーザーガイドをご覧ください。

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

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

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

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

データベースの可用性を向上できることも、DB インスタンスをマルチ AZ 配置として運用する場合の利点の 1 つです。アベイラビリティーゾーンの障害または DB インスタンスの障害が発生した場合、可用性が影響を受けるのは、自動フェイルオーバーが完了するまでの間のみです。Multi-AZ の可用性に対する恩恵は、計画されたメンテナンスにも拡大されます。

例えば、自動バックアップでは、バックアップがスタンバイから取得されるため、お好みのバックアップウィンドウで、プライマリ上での I/O アクティビティが中断されることはありません。パッチの適用や DB インスタンスクラスのスケーリングを行う場合、これらのオペレーションは、自動フェイルオーバーの前にスタンバイで最初に行われます。結果的に、可用性が影響を受けるのは、自動フェイルオーバーが完了するのに必要な時間に限定されます。

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

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

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

マルチ AZ DB インスタンス配置を作成するには、AWS マネジメントコンソールで DB インスタンスを起動する際に、[マルチ AZ 配置] で [はい] のオプションをクリックするだけです。

代わりに、Amazon RDS API を使用している場合は、CreateDBInstance API を呼び出して "マルチ AZ" パラメータの値を "true" に設定することもできます。 既存の標準 (シングル AZ) DB インスタンスをマルチ AZ に変換するには、AWS マネジメントコンソールで DB インスタンスを変更するか、ModifyDBInstance API を使用してマルチ AZ パラメータを true に設定します。

PostgreSQL 用 RDS、MySQL 用 RDS、MariaDB 用 RDS、SQL Server 用 RDS、Oracle 用 RDS、および Db2 データベースエンジン用の RDS では、Amazon RDS インスタンスをシングル AZ からマルチ AZ に変換することを選択すると、次のようになります。

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

結果として、インスタンスが Single-AZ から Multi-AZ に変換される際には、ダウンタイムは発生しません。ただし、スタンバイのデータがプライマリと一致するように処理されている間は、レイテンシーが増加することがあります。

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

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

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

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

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

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

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

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

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

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

アベイラビリティーゾーンは、同一リージョンの別のアベイラビリティーゾーンに対して低レイテンシーでネットワーク接続できるように設計されています。さらに、1 つのアベイラビリティーゾーンでのサービス障害時にお客様のアプリケーションが回復力を持つように、複数のアベイラビリティーゾーン全体で冗長性を持つアプリケーションや他の AWS リソースの設計も検討できます。Multi-AZ 配備は、お客様サイドでの管理作業なく、データベースに対するこのニーズを解決します。

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

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

リードレプリカは、サポートされるエンジンに組み込まれているレプリケーション機能を使って、単一の DB インスタンスの容量制限を弾性的に拡大してデータベースワークロードの読み込み負荷を緩和することを容易にします。

ユーザーは、AWS マネジメントコンソールで数回クリックするか、CreateDBInstanceReadReplica API を使って、リードレプリカを作成できます。リードレプリカを作成すると、データベースは、サポートされるエンジンのネイティブ非同期レプリケーション機能を使ってソース DB インスタンスを更新します。1 つのソース DB インスタンスに対して複数のリードレプリカを作成して、アプリケーションの読み込みトラフィックをこれらのレプリカに分散させることができます。

リードレプリカは、サポートされるエンジンに組み込まれているレプリケーション機能を使用するため、その長所と制限が反映されます。特に、更新は、ソース DB インスタンスを更新した後にリードレプリカに反映されるため、レプリケーションが大幅に異なる場合があります。リードレプリカをマルチ AZ 配置に関連付けることにより、マルチ AZ 配置が提供するデータベースの書き込み可用性と耐久性に加えて、読み込み性能をスケーリングすることができます。

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

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

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

Amazon Aurora: すべての DB クラスター。

Amazon RDS for MySQL: すべての 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: すべての DB インスタンスで、リードレプリカの作成がサポートされます。リードレプリカオペレーションでは、ソース DB インスタンスで自動バックアップを有効にしておく必要があります。

Amazon RDS for Oracle: Oracle バージョン12.1.0.2.v12 以上、および Oracle Database Enterprise Edition で自分のライセンスを使用する (BYOL) モデルを使用しており、Active Data Guard Option のライセンスを取得しているすべての 12.2 バージョンでサポートされています。

Amazon RDS for SQL Server: リードレプリカは、基盤となるレプリケーションテクノロジーで SQL Server バージョン 2016 および 2017 の Always On 可用性グループが使用されている場合、Enterprise Edition のマルチ AZ 設定でサポートされます。

標準の CreateDBInstanceReadReplica API を使用するか、AWS マネジメントコンソールでいくつかのステップにより数分でリードレプリカを作成できます。リードレプリカを作成する時は、SourceDBInstanceIdentifier を指定してリードレプリカを特定することができます。SourceDBInstanceIdentifier は、レプリケーションしたい「ソース」DB インスタンスを特定する DB インスタンス識別子です。標準 DB インスタンスと同様に、アベイラビリティーゾーン、DB インスタンスのクラス、推奨するメンテナンスウィンドウも指定できます。エンジンのバージョン (PostgreSQL 9.3.5 など) とリードレプリカのストレージ割り当ては、ソース DB インスタンスから継承されます。 

リードレプリカの作成を開始すると、Amazon RDS は、お客様のソース DB インスタンスのスナップショットを取り、レプリケーションを開始します。その結果、スナップショットを取る間、ソース DB インスタンスに軽度の入出力停止が発生します。入出力の一時停止は、通常 1 分程度です。ソース DB インスタンスがマルチ AZ 配置の場合は、回避されます (マルチ AZ 配置の場合は、スタンバイのスナップショットがあります)。

Amazon RDS では、現在も最適化の作業が行われています (近日中に公開予定)。複数のリードレプリカを 30 分の範囲内で作成した場合、すべてのリードレプリカのソーススナップショットは同じになり、入出力の影響は最小限になります。(それぞれのリードレプリカに対する「キャッチアップ」レプリケーションは作成後に開始されます)。

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

Amazon RDS for MySQL、MariaDB、PostgreSQL では、特定のソース DB インスタンスのために、最大 15 個のリードレプリカを作成できます。Amazon RDS for Oracle および SQL Server では、特定のソース DB インスタンスのために、最大 5 個のリードレプリカを作成できます。

はい。Amazon RDS (RDS for SQL Server 以外) はリージョンが異なるリードレプリカをサポートします。データがソース DB インスタンスに書き込まれてから、リードレプリカで使用可能になるまでの時間は、2 つのリージョン間のネットワークレイテンシーによって異なります。

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

レプリケーションを使ってデータベースの書き込み性能を強化し、さまざまな障害条件に対してデータベースの最新状態を保護するためには、DB インスタンスをマルチ AZ 配置として実行することをお勧めします。サポートされるエンジンのネイティブな非同期レプリケーションを使用する Amazon RDS リードレプリカでは、データベースの書き込みがソース DB インスタンスで既に発生した後にリードレプリカで発生するため、このレプリケーションの「遅延」は状態に応じてかなり異なります。 

その反面、Multi-AZ 配備が使うレプリケーションは同期しています。つまり、すべてのデータベース書込みはプライマリとスタンバイで同時に行われます。このように最新のデータベース更新を保護することで、イベントのフェイルオーバー発生時にスタンバイ状態にすることができます。 

さらに、Multi-AZ 配備のレプリケーションは、完全に管理されています。Amazon RDS では DB インスタンスの障害条件やアベイラビリティーゾーンの障害が自動的に監視され、機能停止が発生すると、スタンバイ (Amazon Aurora の場合はリードレプリカ) への自動フェイルオーバーが開始されます。

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

はい。Amazon RDS for MySQL、MariaDB、PostgreSQL および Oracle では、リードレプリカのマルチ AZ 設定を有効化することで、災害対策のサポートとエンジンアップグレードによるダウンタイム最小化を実現できます。

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

Amazon Aurora、Amazon RDS for MySQL、MariaDB: 3 層のリードレプリカを作成できます。既存の第 1 層のリードレプリカから第 2 層のリードレプリカを作成し、第 2 層のリードレプリカから第 3 層のレプリカを作成します。第 2 層と第 3 層のリードレプリカを作成することで、アプリケーションのニーズに基づいて、レプリケーションの負荷の一部をプライマリデータベースインスタンスからリードレプリカの別の層に移動できる場合があります。

ただし、トランザクションはプライマリから第 1 層レプリカにレプリケートされてから、第 2 層レプリカにレプリケートされ、レプリケーションのレイテンシーが高くなるため、第 2 層リードレプリカはプライマリよりも遅延する可能性があります。同様に、第 3 層のレプリカは、第 2 層のリードレプリカよりも遅れる場合があります。

Amazon RDS for Oracle および Amazon RDS for SQL Server: 現在、リードレプリカのリードレプリカはサポートされていません。

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

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

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

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

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

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

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

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

Amazon RDS には、リードレプリカがそのソース DB インスタンスからどの程度遅れているかを知るための機能があります。リードレプリカがプライマリより遅れている秒数は Amazon CloudWatch メトリクス (「レプリカラグ」) として公開され、AWS マネジメントコンソールまたは Amazon CloudWatch API から閲覧できます。

Amazon RDS for MySQL の場合、この情報ソースは、リードレプリカに対して標準の「Show Replica 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 のユーザーガイド「リードレプリカの問題のトラブルシューティング」セクションを参照してください。 

レプリケーションエラーが解決すると、[Replication State] は [Replicating] に変化します。

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

AWS マネジメントコンソールのいくつかのステップにより、または DB インスタンス識別子を DeleteDBInstance API に渡すことで、リードレプリカを削除できます。 

Amazon Aurora リードレプリカはアクティブ状態のままとなり、対応するソース 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 マネジメントコンソールを使って明示的に行う必要があります。

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

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

CloudWatch Database Insights は、データベースのトラブルシューティングを簡素化および強化する、モニタリングおよびメトリクスのソリューションです。メトリクス、ログ、トレースなどのテレメトリ収集を自動化します。これにより、手動でのセットアップや設定が不要になります。このテレメトリを Amazon CloudWatch に統合することで、CloudWatch Database Insights はデータベースのパフォーマンスと状態の統合ビューを提供します。

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

データベースの負荷をさらに詳細に診断および視覚化し、データ保持期間を長くするには、「Performance Insights」をお試しください。

CloudWatch Database Insights の主な利点には次が含まれます:

1. 簡単なテレメトリ収集: データベースのメトリクス、ログ、トレースを自動的に収集し、セットアップ時間を最小限に抑えます
2. 厳選されたインサイト: データベースパフォーマンスをモニタリングおよび最適化するための事前構築済みのダッシュボード、アラーム、およびインサイトを提供します。最小限の設定で使用を開始できます
3. 統合された CloudWatch ビュー: 複数のデータベースのテレメトリを 1 つのビューにまとめて、モニタリングを簡素化します
4. AI/ML 機能: AI/ML を使用して異常を検出し、人間の担当者によるトラブルシューティングの労力を軽減します
5. アプリケーションのコンテキストモニタリング: ユーザーはデータベースのパフォーマンスとアプリケーションのパフォーマンスを関連付けることができます
6. フリートとインスタンスレベルのビュー: 高レベルのフリートモニタリングと根本原因分析のための詳細なインスタンスビューの両方を提供します
7. シームレスな AWS 統合: Amazon CloudWatch Application Signals と AWS X-Ray を統合することで、包括的なオブザーバビリティエクスペリエンスを実現できます

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

データベースの負荷をさらに詳細に診断および視覚化し、データ保持期間を長くするには、Performance Insights をお試しください。

拡張モニタリングでは、特に CPU、メモリ、ファイルシステム、ディスク I/O といった、Amazon RDS インスタンスのシステムレベルのメトリクスが収集されます。メトリクスの詳細なリストは、「ドキュメント」で確認できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

CloudWatch Database Insights は Amazon RDS と Amazon Aurora のリソースとアプリケーションをリアルタイムでモニタリングし、カスタマイズ可能なダッシュボードを通じてデータを表示します。対照的に、Amazon DevOps Guru は CloudWatch メトリクスを分析して、時間の経過に伴うアプリケーションの動作を理解し、異常を検出するとともに、問題解決のためのインサイトとレコメンデーションを提供する機械学習 (ML) サービスです。

さらに、DevOps Guru は、AWS Config、AWS CloudFormation、AWS X-Ray など、複数のソースからのデータを分析します。CloudWatch ダッシュボードを使用すると、AWS/DevOps-Guru 名前空間に公開されているメトリクスを介して、DevOps Guru の分析情報を監視できます。これにより、すべての分析情報と異常を CloudWatch コンソールの 1 つの画面で確認できます。

Amazon RDS Performance Insights は、データベースパフォーマンスのチューニングおよびモニタリング機能です。これを利用することで、お客様は、データベースの負荷を評価し、いつ、どの部分で措置を講じたらよいのかを判断できます。

CloudWatch Database Insights は、Performance Insights のすべての機能を継承するデータベースオブザーバビリティ機能であり、フリートレベルのモニタリング、アプリケーションパフォーマンスのモニタリングとの統合、データベースメトリクスとログやイベントの相関付けなどを備えています。

Amazon RDS Proxy は、Amazon RDS 向けの完全マネージド型で可用性の高いデータベースプロキシ機能です。RDS プロキシで、アプリケーションの拡張性、データベース障害に対する耐障害性、安全性が向上します。

Amazon RDS プロキシは、フルマネージド型で可用性が高く、使いやすい Amazon RDS 用データベースプロキシ機能です。この機能で、1) データベース接続をプールおよび共有することにより、アプリケーションのスケーラビリティが改善、2) データベースのフェイルオーバー時間が最大 66％ 短縮し、フェイルオーバー中のアプリケーション接続を維持することにより、アプリケーションの可用性が向上、3) オプションでデータベースへの AWS IAM 認証を実施し、AWS Secrets Manager に認証情報を安全に保存することにより、アプリケーションのセキュリティが強化します。

ワークロードに応じて、Amazon RDS プロキシはクエリまたはトランザクションの応答時間に平均 5 ミリ秒のネットワークレイテンシーを追加できます。アプリケーションが 5 ミリ秒のレイテンシーを許容できない場合、またはRDS プロキシによって有効になっている接続管理やその他の機能が必要ない場合、アプリケーションをデータベースエンドポイントに直接接続することが可能です。

Amazon RDS Proxy で、お客様のアプローチは全く新しくなり、リレーショナルデータベースのパワーとシンプルさを活用できる最新のサーバーレスアプリケーションを構築できるようになります。第 1 に、RDS プロキシでサーバーレスアプリケーションを効率的に拡張し、データベース接続をプールし再利用できるようになります。第 2 に、RDSプロキシを使用すると、Lambda コードでデータベースの認証情報を処理する必要がなくなります。Lambda 関数に関連付けられた IAM 実行ロールを使用して、RDS プロキシとデータベースで認証できます。第 3 に、新しいインフラストラクチャやコードを管理する必要なく、リレーショナルデータベースに支えられたサーバーレスアプリケーションの可能性を最大限に活用できます。RDS プロキシは完全マネージド型で、アプリケーションの要求に基づいて容量を自動的にスケーリングします。

RDS Proxy は、MySQL 互換の Amazon Aurora、PostgreSQL 互換の Amazon Aurora、Amazon RDS for MariaDB、Amazon RDS for MySQL、Amazon RDS for PostgreSQL、Amazon RDS for SQL Server で使用可能です。サポートされるエンジンのバージョンのリストについては、Amazon Aurora ユーザーガイドまたは Amazon RDS ユーザーガイドを参照してください。

Amazon RDS コンソールで数回クリックするだけで、Amazon RDS データベースの Amazon RDS プロキシを有効にできます。RDS プロキシを有効にして、RDS プロキシにアクセスする VPC とサブネットを指定します。Lambda ユーザーの場合、Amazon RDS データベースの Amazon RDS Proxy を有効にすれば、Lambda コンソールで数回クリックするだけで RDS Proxy にアクセスできるように Lambda 関数を設定できます。

はい。Amazon RDS プロキシ API を使ってプロキシを作成し、ターゲットグループを定義して、プロキシを特定のデータベースインスタンスまたはクラスターに関連付けることができます。以下に例を示します。

aws rds create-db-proxy 
        --db-proxy-name '…' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

Trusted Language Extensions (TLE) for PostgreSQL により、開発者は高性能な PostgreSQL 拡張を構築し、Amazon Aurora および Amazon RDS 上で安全に実行することができます。これにより、TLE は市場投入までの時間を短縮し、データベース管理者が本番データベースワークロードで使用するためのカスタムコードやサードパーティーコードを認証する負担を軽減します。延長がニーズに合うと判断したら、すぐにでも進めることができます。TLE により、独立系ソフトウェアベンダー では、Aurora や Amazon RDS 上で動作する顧客に新しい PostgreSQL 拡張を提供することができます。

PostgreSQL の拡張機能では、同じプロセス空間で実行されるため、高いパフォーマンスを発揮します。しかし、拡張機能には、データベースをクラッシュさせるようなソフトウェアの欠陥があるかもしれません。

TLE for PostgreSQL は、このリスクを軽減するために複数のレイヤーを提供します。TLE は、システムリソースへのアクセスを制限するように設計されています。rds_superuser ロールは、特定の拡張機能のインストールを許可するユーザーを決定することができます。ただし、これらの変更は、TLE API を通じてのみ可能です。TLE は、拡張機能の欠陥の影響を単一のデータベース接続に限定するように設計されています。これらの安全対策に加えて、TLE は、rds_superuser ロールを持つ DBA が、拡張機能をインストールできるユーザーをきめ細かくオンラインで制御できるように設計されており、拡張機能を実行するための権限モデルを作成することが可能です。

十分な権限を持つユーザーのみが、TLE 拡張機能の「CREATE EXTENSION」コマンドを使用して実行および作成することができるようになります。DBA は、データベースの内部動作を変更し、通常、昇格した特権を必要とする、より高度な拡張機能に必要な「PostgreSQL フック」を許可リスト化することもできます。

TLE for PostgreSQL は、Amazon Aurora PostgreSQL 互換エディション および Amazon RDS on PostgreSQL のバージョン 14.5 以降で利用可能です。TLE は PostgreSQL の拡張機能そのものとして実装されており、Aurora や Amazon RDS でサポートされている他の拡張機能と同様に、rds_superuser ロールから有効化することが可能です。

TLE for PostgreSQL は、Amazon Aurora および Amazon RDS の PostgreSQL 14.5 以降で実行できます。 

TLE for PostgreSQL は現在、すべての AWS リージョン (AWS 中国リージョンを除く) および AWS GovCloud リージョンでご利用いただけます。

TLE for PostgreSQL は、Aurora と Amazon RDS のお客様には追加費用なしでご利用いただけます。

Aurora と Amazon RDS は、85 以上の PostgreSQL 拡張機能のキュレートされたセットをサポートしています。AWS は、AWS 責任共有モデルに基づいて、これらの拡張機能それぞれのセキュリティリスクを管理しています。TLE for PostgreSQL を実装する拡張機能は、このセットに含まれています。お客様が書いた、またはサードパーティーのソースから入手して TLE にインストールした拡張機能は、お客様のアプリケーションコードの一部とみなされます。TLE 拡張機能を使用するアプリケーションのセキュリティは、お客様の責任で行ってください。

ビットマップ圧縮や差分プライバシーなど (個人のプライバシーを保護する、一般にアクセス可能な統計クエリなど) のデベロッパー機能を構築することができます。

TLE for PostgreSQL は現在、JavaScript、PL/pgSQL、Perl、および SQL をサポートしています。

rds_superuser ロールによって TLE for PostgreSQL が有効になると、psql などの任意の PostgreSQL クライアントから SQL CREATE EXTENSION コマンドを使用して TLE 拡張機能をデプロイできます。これは、PL/pgSQL や PL/Perl などの手続き言語で記述されたユーザー定義関数を作成する方法と似ています。TLE 拡張機能をデプロイする権限と特定の拡張機能を使用する権限を持つユーザーを制御できます。

TLE for PostgreSQL は、TLE API を介してのみ PostgreSQL データベースにアクセスします。TLE がサポートする信頼できる言語には、PostgreSQL サーバープログラミングインターフェイス (SPI) の全機能と、チェックパスワードフックを含む PostgreSQL フックのサポートが含まれます。

TLE for PostgreSQL プロジェクトの詳細については、公式の TLE GitHub ページで確認できます。

Amazon RDS ブルー/グリーンデプロイメントは、Amazon Aurora MySQL 互換エディション、Amazon Aurora PostgreSQL 互換エディション、Amazon RDS for MySQL、Amazon RDS for MariaDB、Amazon RDS for PostgreSQL でご利用いただけます。 

Amazon RDS ブルー/グリーンデプロイは、Amazon Aurora MySQL 互換エディションバージョン 5.6 以降、RDS for MySQL バージョン 5.7 以降、および RDS for MariaDB バージョン 10.2 以降で利用可能です。ブルー/グリーンデプロイメントは、バージョン 11.21 以上、12.16 以上、13.12 以上、14.9 以上、15.4 以上の Amazon Aurora PostgreSQL 互換エディションと Amazon RDS for PostgreSQL でもサポートされています。利用可能なバージョンの詳細については、Amazon Aurora および Amazon RDS のドキュメントを参照してください。 

Amazon RDS ブルー/グリーンデプロイは、すべての AWS リージョンおよび AWS GovCloud リージョンで利用可能です。

Amazon RDS ブルー/グリーンデプロイを使用すると、より安全、簡単、高速にデータベースの更新ができます。ブルー/グリーンデプロイは、メジャーバージョンまたはマイナーバージョンのデータベースエンジンのアップグレード、オペレーティングシステムの更新、論理レプリケーションを中断しないグリーン環境でのスキーマの変更 (テーブルの最後に新しい列を追加するなど)、またはデータベースパラメーター設定の変更などのユースケースに最適です。ブルー/グリーンデプロイを使用すると、1 回のスイッチオーバーで複数のデータベースを同時に更新できます。これにより、セキュリティパッチを最新の状態に保ち、データベースのパフォーマンスを向上させ、短期間で予測可能なダウンタイムで新しいデータベース機能にアクセスできます。

グリーンインスタンスでワークロードを実行する場合、ブルーインスタンスと同じ料金が発生します。ブルーおよびグリーンインスタンスで実行するコストは、db.instance の現在の標準料金、ストレージのコスト、読み取り/書き込み I/O のコスト、およびバックアップや Amazon RDS Performance Insights のコストなど、有効な機能を含みます。事実上、ブルーグリーンデプロイの有効期間中は、db.instance でワークロードを実行するコストの約 2 倍を支払うことになります。

例: RDS for MySQL 5.7 データベースが、マルチ AZ (MAZ) 設定で us-east-1 AWS リージョンの 2 つの r5.2xlarge db.instance (プライマリデータベースインスタンスとリードレプリカ) で実行しているとします。各 r5.2xlarge db.instance は、20 GiB の汎用 Amazon Elastic Block Storge (EBS) で設定されています。Amazon RDS ブルー/グリーンデプロイを使用してブルーインスタンスのトポロジーのクローンを作成し、15 日間 (360 時間) 実行し、スイッチオーバーに成功した後にブルーインスタンスを削除します。ブルーインスタンスのコストは、オンデマンド料金 1.926 USD/時 (インスタンス + EBS コスト) で 15 日間 1,387 USD です。この 15 日間、ブルー/グリーンデプロイを使用した場合の合計コストは 2,774 USD で、これはその期間のブルーインスタンスの運用コストの 2 倍となります。

Amazon RDS ブルー/グリーンデプロイでは、メジャー/マイナーバージョンアップグレード、スキーマの変更、インスタンスのスケーリング、エンジンパラメータの変更、メンテナンスアップデートなど、より安全でシンプル、かつ迅速なデータベース変更を行うことが可能です。

Amazon RDS ブルー/グリーンデプロイでは、ブルー環境が現在の本番環境です。グリーン環境は、スイッチオーバー後に新しい本番環境となるステージング環境です。

Amazon RDS ブルー/グリーンデプロイがスイッチオーバーを開始すると、スイッチオーバーが完了するまで、ブルーとグリーンの両方の環境への書き込みがブロックされます。スイッチオーバーの間、ステージング環境 (グリーン環境) は本番システムに追いつき、ステージング環境と本番環境の間でデータの一貫性を確保します。本番環境とステージング環境が完全に同期されると、ブルー/グリーンデプロイは、新しく昇格させられる本番環境にトラフィックをリダイレクトすることで、ステージング環境を本番環境として昇格させます。ブルー/グリーンデプロイは、スイッチオーバー完了後にグリーン環境への書き込みを可能にするよう設計されており、スイッチオーバープロセス中のデータ損失はゼロになります。

ブルー環境がセルフマネージド論理レプリカまたはサブスクライバーの場合、スイッチオーバーはブロックされます。最初にブルー環境へのレプリケーションを停止し、スイッチオーバーを続行してからレプリケーションを再開することをお勧めします。対照的に、ブルー環境がセルフマネージド論理レプリカまたはパブリッシャーのソースである場合は、スイッチオーバーを続けることができます。ただし、スイッチオーバー後にグリーン環境からレプリケートするには、セルフマネージドレプリカを更新する必要があります。

Amazon RDS ブルー/グリーンデプロイでは、古い本番環境は削除されません。必要に応じて、追加の検証やパフォーマンス/リグレッションのテストのためにアクセスすることができます。古い本番環境が不要になった場合は、削除することができます。古い本番インスタンスでは、それを削除するまで標準料金が発生します。

Amazon RDS ブルー/グリーンデプロイのスイッチオーバーガードレールは、スイッチオーバー前にグリーン環境が追いつくまで、ブルー環境とグリーン環境での書き込みをブロックします。ブルー/グリーンデプロイは、ブルーとグリーンの環境におけるプライマリとレプリカのヘルスチェックも行います。レプリケーションのヘルスチェックも行います。例えば、レプリケーションが停止していないか、エラーが発生していないか、などを確認します。ブルー環境とグリーン環境の間で長時間実行されているトランザクションを検出します。最大許容ダウンタイムは最短で 30 秒から指定でき、進行中のトランザクションがこれを超えると、スイッチオーバーがタイムアウトします。

いいえ。Amazon RDS ブルー/グリーンデプロイは、グローバルデータベース、Amazon RDS Proxy、クロスリージョンリードレプリカ、またはカスケードリードレプリカをサポートしていません。

いいえ。現時点では、Amazon RDS ブルー/グリーンデプロイを使用して変更をロールバックすることはできません。

MySQL は、メモリ内の 16 KiB ページのデータを、耐久性のあるストレージに 2 回書き込むことで (まず「ダブルライトバッファ」に書き込み、その後にテーブルストレージに書き込みます)、データ損失からユーザーを保護します。Amazon RDS Optimized Writes は、AWS Nitro System の Torn Write Prevention 機能を使用して、高い信頼性および耐久性をもって、1 ステップで 16 KiB のデータページをデータファイルに直接書き込みます。

Amazon RDS Optimized Writes は、MySQL のメジャーバージョン 8.0.30 以降でご利用いただけます。

Amazon RDS Optimized Writes は、db.r6i および db.r5b インスタンスで利用可能です。これらのインスタンスが利用可能なすべてのリージョン (AWS 中国リージョンを除く) でご利用いただけます。

いいえ。Amazon Aurora MySQL 互換エディションは、既に「ダブルライトバッファ」の使用を回避しています。 その代わりに、Amazon Aurora は 3 つの アベイラビリティーゾーン (AZ) で 6 つの方法でデータをレプリケートし、クォーラムベースのアプローチでデータを耐久性をもって書き込み、その後正しく読み取ることができます。

現時点では、インスタンスクラスが Optimized Writes をサポートしていても、この初期リリースでは、既存のデータベースインスタンスのために Amazon RDS Optimized Writes を有効にすることはサポートされていません。

RDS for MySQL をご利用のお客様は、Amazon RDS Optimized Writes を追加費用なしでご利用いただけます。

MySQL および MariaDB の一時オブジェクトをクエリ処理に使用するワークロードは、Amazon RDS Optimized Reads の恩恵を受けることができます。 Optimized Reads は、Amazon Elastic Block Store ボリュームではなく、データベースインスタンスの NVMe ベースのインスタンスストレージに一時オブジェクトを配置します。これにより、複雑なクエリ処理を最大 2 倍高速化することができます。

Amazon RDS Optimized Reads は、RDS for MySQL では MySQL バージョン 8.0.28 以降、RDS for MariaDB では MariaDB バージョン 10.4.25、10.5.16、10.6.7 以降で利用可能です。

Amazon RDS Optimized Reads は、db.r5d, db.m5d, db.r6gd, および db.m6gd, X2idn, および X2iedn インスタンスが利用可能なすべてのリージョンで利用可能です。詳細については、Amazon RDS DB インスタンスクラスのドキュメントをご覧ください。

お客様は、複雑なクエリ、汎用分析、または複雑なグループ、ソート、ハッシュ集約、高負荷の結合、および共通テーブル式 (CTE) を必要とするワークロードがある場合、Amazon RDS Optimized Reads を使用する必要があります。これらのユースケースでは、一時テーブルが作成され、Optimized Reads によってワークロードのクエリ処理を高速化することが可能になります。

はい。お客様は、Optimized Read が有効になっているインスタンスにワークロードを移動することにより、既存の Amazon RDS データベースを変換して Amazon RDS Optimized Reads を使用することができます。また、Optimized Reads は、サポートされているすべてのインスタンスクラスでデフォルトで利用可能です。db.r5d、db.m5d、db.r6gd、db.m6gd、X2idn、および X2iedn インスタンスでワークロードを実行している場合、すでに Optimized Reads の恩恵を受けていることに なります。