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

DB インスタンスを、お客様が指定したコンピュートおよびストレージリソースを備えた、クラウド内のデータベース環境であると考えることができます。お客様は、DB インスタンスの作成と削除ができ、DB インスタンスのインフラストラクチャ属性を定義/改良でき、AWS Management Console、AmazonRDSAPI およびコマンド ライン ツールを通じてアクセスとセキュリティをコントロールできます。複数の MySQL データベースまたは Oracle データベースのスキーマは、特定の DB インスタンスで作成することができます。

Amazon RDS は、お客様が要求するインフラストラクチャ容量の準備からデータベース ソフトウェアのインストールまで、リレーショナル データベースのセットアップに関係する作業を管理します。一旦お客様のデータベースがそれ自身の DB インスタンス上で動作を始めると、Amazon RDS は、バックアップの実行やお客様の DB インスタンスを駆動するデータベース ソフトウェアのパッチなどの一般的な管理作業を自動化します。オプションの Multi-AZ 配備（現在は MySQL のみでサポートされている）として、Amazon RDS はまた、Availability Zone 全体での同期的データレプリケーションと自動フェイルオーバーを管理します。

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

Amazon Web Services は、開発者向けにいくつかのデータベースソリューションの選択肢を提供しています。Amazon RDS はデータベース管理の負荷を軽減しながら、完全な機能を持つリレーショナルデータベースを実行することができます。Amazon SimpleDB は、シンプルなインデックスとクエリ機能、そしてシームレスな拡張性を提供します。Amazon EC2 および Amazon EBS 上にある当社の数多くのリレーショナルデータベース AMI を使用することにより、お客様独自のリレーショナルデータベースをクラウド上で運用することが可能となります。お客様のユースケースに対して、どの選択肢を使うのが適切かを検討する上でのポイントは下記の通りです。どのソリューションがお客様にとってベストであるかに関する追加説明は、AWS でのデータベースの実行をご覧ください。

Amazon RDS にサインアップするには、Amazon RDS 詳細ページの「Amazon RDS にサインアップ」ボタンをクリックし、サインアップ プロセスを完了します。お客様は、Amazon Web Services アカウントを持っている必要があります。まだアカウントを持っていない場合、Amazon RDS サインアップ プロセスを始めた時に、アカウントを作成するよう要求されます。RDS に対してサインアップした後、Amazon RDS 資料をご覧ください。入門ガイドが含まれています。

一旦 Amazon RDS の使用に慣れれば、AWS Management Console または Amazon RDS API を使用して、数分以内に DB インスタンスを起動できます。

一旦お客様の DB インスタンスが利用可能になったら、AWS Management Console または DescribeDBInstance API の DB インスタンスの説明を使用して、そのエンドポイントを取得できます。このエンドポイントを使用して、使い慣れたデータベース ツールまたはプログラミング言語により、DB インスタンスに直接接続するために必要な接続ストリングを作成することができます。お客様の実行中の DB インスタンスに対するネットワーク リクエストを許可するため、アクセスを認可する必要があります。接続ストリングの作成方法および開始方法についての詳細は、当社の入門ガイドをご覧ください。

デフォルトでは、合計20までの Amazon RDS DB インスタンスを持つことができます。それらの20のうち、最大10までを「ライセンス込み」モデルで Oracle DB インスタンスにすることができます。20すべてを、「BYOL」モデルで MySQL または Oracle に使用することができます。アプリケーションに20以上の DB インスタンスを必要とする場合は、この申請フォームを使用して、追加の DB インスタンスをリクエストできます。

MySQL 用の mysqldump または mysqlimport ユーティリティ、および Oracle 用のインポート/エクスポートまたは SQL Loader など、データを Amazon RDS にインポートする簡単な方法がいくつかあります。データのインポートおよびエクスポートの詳細については、MySQL の Amazon RDS データインポートガイド または Oracle の Amazon RDS データインポートガイドをご参照ください。

Amazon RDS は現在、InnoDB 搭載の MySQL 5.1 および 5.5（コミュニティ版）をデフォルトのデータベース ストレージ エンジンとして、および Oracle Database 11gR2 をサポートしています。

MySQL を使用している場合は、DB Engine の MySQL マイナーバージョンへのオプションのコントロールとして、Amazon RDS MySQL DB Engine Version Management を使用することができます。

Oracle を使用している場合は、DB インスタンスのパッチレベルへのオプションのコントロールとして、Amazon RDS Oracle DB Engine Version Management を使用することができます。

MySQL の Amazon RDS における特定時点の復元およびスナップショット復元機能には、クラッシュからの回復可能なストレージエンジンが必要で、InnoDB ストレージエンジンのみがサポートされています。MySQL は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、MyISAM ストレージエンジンは、信頼性の高いクラッシュ回復をサポートしておらず、MySQL がクラッシュ後に再起動した時、特定時点の復元およびスナップショット復元が意図通りに機能せず、データが紛失または破損する可能性があります。それでも、Amazon RDS で MyISAM を使用する場合は、このステップに従ってください。スナップショット復元機能において特定のシナリオで役立つ可能性があります。

既存の MyISAM テーブルを InnoDB テーブルに変換したい場合は、alter table コマンド（例えば、alter table TABLE_NAME engine=innodb;）を使用することができます。MyISAM と InnoDB は異なる長所と短所を持っているので、これを行う前に、アプリケーションでこれを切り替えた際の影響を十分に査定する必要があることを念頭に置いてください。

加えて、フェデレーティッドストレージエンジンは、現在 MySQL の Amazon RDS ではサポートされていません。

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

お客様のDBインスタンスをオフラインにする Amazon RDS を必要とする唯一のメンテナンスイベントは、スケール計算オペレーション（これは通常開始から終了まで数分のみを要します）。または要求されたソフトウェアパッチです。 要求されたパッチに対しては、安全で堅牢かつ関連性のあるパッチのみが自動的にスケジューリングされます。このようなパッチは頻繁に発生するものではありません（通常数ヵ月ごとに一度です）。またお客様のメンテナンスウィンドウのごく一部以外を使用する必要があることは稀なはずです。DB インスタンスの作成時点で、希望する週間メンテナンスウィンドウが指定されていない場合は、30分のデフォルト値が割り当てられます。メンテナンスがお客様のために実行される際に修正を行いたい場合、AWS Management Console でDBインスタンスを修正する、または ModifyDBInstance API を使用することでそれを行うことができます。お客様の各 DB インスタンスは、個々に異なるメンテナンス ウィンドウを選択することができます。

DB インスタンスを Multi-AZ 配備として実行すると、メンテナンスイベントの影響をさらに抑えることができますが、これは Amazon RDS が以下の手順でメンテナンスを行うからです: 1）スタンバイでメンテナンスを実行する 2）スタンバイをプライマリに昇格させる 3）古いプライマリでメンテナンスを実行し、これが新しいスタンバイになる。

メンテナンスウィンドウを指定するための API またはコマンドラインインターフェイスの使用に関する詳細については、Amazon RDS 開発者ガイドをご覧ください。Multi-AZ モード配備についての詳細は、ここをクリックしてください。

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

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

使用したものに対してのみ支払い、最低料金やセットアップ料金はありません。以下に基づき請求が行われます。

• DB インスタンス時間 - 消費された DB インスタンスのクラス（例: スタンダードスモール、ラージ、エクストララージなど）に基づいています。1 時間に満たない DB インスタンスの利用は、1 時間として請求されます。
• ストレージ（/GB /月）- DB インスタンスに対して準備したストレージ容量。準備したストレージ容量を当月以内に拡張した場合、請求は比例配分されます。
• I/O リクエスト/月 - ストレージ I/O リクエストの合計。
• バックアップ ストレージ - バックアップ ストレージは、お客様の自動データベース バックアップおよびお客様が取得した アクティブなデータベース スナップショットに関連するストレージです。バックアップ保持期間を延長するか、追加のデータベース スナップショットを撮ると、データベースが消費するバックアップ ストレージが増加します。Amazon RDS は、お客様が準備したデータベース ストレージの100％まで追加料金なしでバックアップ ストレージを提供します。例えば、10GB・月のデータベース ストレージが準備されていると、当社は追加料金なしで最大 10GB・月のバックアップ ストレージを提供します。データベース管理者としての当社の経験に基づけば、大半のデータベースは一次データセットの場合よりもバックアップの場合には必要とする raw ストレージは少ないです。つまり、ほとんどのお客様はバックアップストレージに料金を支払いません。バックアップストレージは、アクティブな DB インスタンスの場合のみ無料です。
• データ転送 - DB インスタンスのインターネット経由のデータ受信および送信です。

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

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

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

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

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

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

特に記載のない限り、当社の価格は、VAT および該当する売上税を含め、該当する税金および関税は別となっています。例えば、アジアパシフィック（東京）リージョンの価格には、日本の消費税が含まれています。

リザーブド インスタンスを使うと、事前に予約金をお支払いいただくことで、1年または3年の予約を作成して、自分の DB インスタンスを特定のリージョンで実施し、時間課金制の請求に対して大量の割引を受けることができます。リザーブドインスタンスには3つのタイプ（軽度使用、中度使用、重度使用リザーブドインスタンス）があるため、これらの効果的な時間単位価格によって先払い料金とのバランスを取ることができます。

機能的には、リザーブド インスタンスもオンデマンドインスタンスも全く同一のものです。唯一異なる点は、お客様の インスタンスが構築される方法です。リザーブド DB インスタンスでは、1回限りの前払いで契約期間中は低価格の時間単位で課金されます（オンデマンド DB インスタンスではない）。

AWS Management Console の「リザーブド DB インスタンスの購入」オプションを使用することができます。あるいは、API ツールを使用することができます。DescribeReservedDBInstancesOfferings API メソッドで購入可能な予約を一覧表示し、PurchaseReservedDBInstancesOffering メソッドを呼び出して DB インスタンスの予約を購入することができます。

リザーブド インスタンスの作成方法は、オンデマンドインスタンスの起動方法と同じです。CreateDBInstance API の rds-create-db-instance コマンドを使う、または AWS Management Console の DB インスタンスの起動オプションを選択して、予約した DB インスタンスのクラスとリージョンを指定します。予約購入が完了すれば、Amazon RDS は割引価格をお客様の新しい DB インスタンスに適用します。

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

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

最初の DB インスタンスとストレージ容量を選択するため、アプリケーションのコンピュート、メモリ、およびストレージニーズを評価したいと考えます。正しい DB インスタンスクラスとストレージ容量の選択に関するガイドラインについては、Amazon RDS DB インスタンスサイズ設定ガイドをご覧ください。

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

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

Amazon RDS は、データベースとログの格納に EBS ボリュームを使用します。要求されるストレージのサイズによって、Amazon RDS は自動的に複数の EBS ボリューム全体をストライプして、IOPS パフォーマンスを向上させます。したがって、ストレージを拡張すると、既存の DB インスタンスにいくらかの I/O 機能の向上が見られる可能性があります。AWS Management Console または ModifyDBInstance API を使用して、DB インスタンスに割り当てられたストレージ容量を縮小・拡張することができます。

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

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

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

Amazon RDS の自動化バックアップ機能によって、お客様の DB インスタンスを特定時点から復旧することができます。DB インスタンスに対して自動化バックアップがオンになっている場合、Amazon RDS はお客様のデータを 1 日 1 回自動的に、（任意のバックアップウィンドウで）完全なスナップショットを作成し、（DB インスタンスに対する更新を作成中）トランザクションログを捕捉します。特定時点への復旧を開始する際、DBインスタンスをリクエストされた特定の時刻の状態に復元するため、トランザクションログが最も適切なデイリーバックアップに適用されます。Amazon RDS は、DB インスタンスを、限られた、ユーザーに指定された期間（保持期間と呼ぶ）保持します。これはデフォルトでは1日ですが、最大8日間に設定可能です。保持期間中、特定時点への復旧を開始して、最大で復元可能な最新時刻（Latest Restorable Time）まで、任意の秒数を指定することができます。DescribeDBInstances API を使用して、DB インスタンスの復元可能な最新時刻まで戻ることができます。これは通常過去５分以内です。 代わりに、AWS Management Console で DB インスタンスを選択し、コンソールの下にあるパネルの [説明] タブでこれを閲覧することによって、その DB インスタンスの「復元可能な最新時刻」を知ることもできます。

DB スナップショットはユーザーにより開始され、指定した頻度で既知の状態で DB インスタンスをバックアップすることができ、その後いつでもその特定の状態に復旧することができます。DB スナップショットは、AWSManagement Console または CreateDBSnapshot API で作成可能であり、コンソールまたは DeleteDBSnapshot API で明示的に削除するまで保持されます。

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

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

AWS Management Console または ModifyDBInstance API を使用して、RetentionPeriod パラメータを修正することにより、自動化バックアップが保持される期間を管理することができます。自動化バックアップをすべて無効にしたい場合、保持期間を 0 に設定します（お勧めしません）。AWS Management Console の DB スナップショット セクションを使用して、ユーザー作成 DB スナップショットを管理できます。代わりに、DescribeDBSnapshots API を使用して、指定 DB インスタンスのユーザー作成 DB スナップショット一覧を表示でき、DeleteDBSnapshot API を使用して、スナップショットを削除できます。

Amazon VPC を使用すると、Amazon Web Services（AWS）クラウドの非公開の隔離されたセクションに仮想ネットワーキング環境を作成できます。この環境では、プライベート IP アドレスの範囲、サブネット、ルーティングテーブル、ネットワークゲートウェイなど、さまざまな点を完全にコントロールして演習できます。Amazon VPC では、仮想ネットワークトポロジを定義し、従来の IP ネットワークと同じようにネットワーク設定をカスタマイズできるため、独自のデータセンターで運用できます。

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

Amazon RDS の基本機能は VPC を使用するかどうかにかかわらず同じです。Amazon RDS は、DB インスタンスを VPC 内に展開するかどうかにかかわらず、バックアップ、ソフトウェアのパッチ処理、自動エラー検出、および復元を管理します。ただし、現時点で VPC 内でサポートされるのは MySQL 用の Amazon RDS のみです。また、MySQL 用 Amazon RDS のリードレプリカ機能は、現時点で VPC 内ではサポートされていません。

VPC 以外に展開した Amazon RDS DB インスタンスには（エンドポイント/DNS 名を解決できる）外部 IP アドレスが割り当てられ、EC2 またはインターネットから接続できます。Amazon VPC では、Amazon RDS DB インスタンスには（定義したサブネット内の）プライベート IP アドレスのみが割り当てられます。

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 配備に変換する場合に備えてこのように定義する必要があります。

VPC 内に DB インスタンスを作成する手順については、Amazon RDS ユーザーガイドを参照してください。

以下に、VPC 内に DB インスタンスを作成するために必要な前提条件を示します。

• VPC で、DB インスタンスを展開する Region 内のすべての Availability Zone に、1 つ以上のサブネットを指定する必要があります。Amazon VPC およびサブネットを作成する方法については、Amazon VPC 入門ガイドを参照してください。
• VPC 用に DB サブネットグループを定義する必要があります。
• VPC 用に DB セキュリティグループを定義する必要があります（デフォルトで定義されているグループを使用することもできます）。
• また、各サブネットには適度な大きさの CIDR ブロックを割り当てて、コンピュータの拡張やフェイルオーバーなどの保守作業で使用できる Amazon RDS 用の予備の IP アドレスを確保するようにします。

Amazon RDS では、データベース セキュリティ グループ（DB セキュリティ グループ）を使用して、DB インスタンスへのアクセスをコントロールできます。DB セキュリティ グループは、DB インスタンスへのネットワーク アクセスをコントロールするファイアウォールのように動作します。デフォルトでは、DB インスタンスへのネットワーク アクセスは無効です。アプリケーションから DB インスタンスにアクセスできるようにするには、特定の EC2 セキュリティグループ/VPC セキュリティグループのメンバーシップまたは IP 範囲の EC2 インスタンスからのアクセスを許可するように DB セキュリティグループを設定します。このプロセスは、イングレスと呼ばれています。一旦 DB セキュリティ グループに対してイングレスが設定されると、同じルールがその DB セキュリティ グループに関連するすべての DB インスタンスに適用されます。DB セキュリティグループは、AWS Management Console の「DB セキュリティグループ」で設定できます。または Amazon RDS API を使用してください。

VPC を DB セキュリティグループに関連付ける場合、その DB セキュリティグループ内のすべてのアクセスルールを、VPC セキュリティグループまたは IP 範囲からのアクセスルールにする必要があります。EC2 セキュリティグループと VPC セキュリティグループの間に互換性はありません。

もう 1 つの注意事項は、VPC 内に特定の DB セキュリティグループのメンバーシップを持つ DB インスタンスを作成するたびに、管理の目的でその DB インスタンスに対応する VPC セキュリティグループが Amazon RDS によって作成される、という点です。このような VPC セキュリティグループは説明を見ると確認できます（「RDS DB インスタンス用のセキュリティグループ 」といった形式の説明になっています）。これらは、EC2/VPC コンソールまたは EC2/VPC API を使用して更新しないようにしてください。DB インスタンスへのアクセスを制御するために変更が必要な場合は、DB セキュリティグループを使用してください。

DB セキュリティグループを使用すると、Amazon VPC 内の DB インスタンスを保護できます。また、各サブネットに出入りするネットワークトラフィックは、ネットワークアクセスコントロールリスト（ACL）を使用して許可または拒否することができます。IPsec VPN 接続を介する VPC へのすべてのネットワークトラフィックの出入りは、ネットワークファイアウォール、侵入検知機、防止システムなど、社内のセキュリティインフラストラクチャによって監視することができます。

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

VPC 内に展開した DB インスタンスには、インターネットからアクセスできるだけでなく、VPN またはパブリックサブネットで起動できる拠点ホストを介して VPC 以外にある EC2 インスタンスからもアクセスできます。拠点ホストを使用するには、SSH 拠点として動作する EC2 インスタンスを使用してパブリックサブネットを設定する必要があります。このパブリックサブネットには、SSH ホストを介してトラフィックを制御できるインターネットゲートウェイまたはルーティングルールが必要です。また、その SSH ホストから RDS DB インスタンスのプライベート IP アドレスに要求を転送できる必要があります。

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

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

VPC 以外にある DB インスタンスのスナップショットを作成し、VPC に復元することができます。それには、使用する DB サブネットグループを指定します。または、「以前の状態に復元」操作も可能です。

現在、VPC 内から VPC 以外へ DB インスタンスを直接移行する操作はサポートされていません。セキュリティ上の理由から、VPC 内の DB インスタンスの DB スナップショットを VPC 以外の場所に復元することはできません。「以前の状態に復元」機能も同様です。DB インスタンスを VPC 内から VPC 以外へ移行する必要がある場合は、VPC 内のソース DB インスタンスのデータを、VPC 以外に展開したターゲット DB インスタンスにエクスポートする必要があります。

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

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

既存の DB サブネットグループを更新して、既存の Availability Zone 用、または DB インスタンスの作成後に作成した新しい Availability Zone 用にサブネットを追加できます。ただし、現時点では、展開した DB インスタンスの DB サブネットグループの変更は許可されていません。

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

いいえ、リレーショナル データベースを使用してお客様自身で管理する時と同じ熟知している方法ですべて機能します。

はい、しかし、このオプションは現在のところ MySQL エンジンのみでサポートされています。

Amazon RDS は、各 DB インスタンスに対して SSL 証明書を生成します。 Amazon RDS ユーザーガイドには、デフォルトの mysql クライアントを使用して、暗号化された接続を確立する手順についての説明が記載されています。暗号化された接続が確立されたら、DB インスタンスとお客様のアプリケーション間で転送されるデータは、転送中に暗号化されるようになります。データベースで「at rest」中にデータを暗号化する必要がある場合、お客様のアプリケーションがデータの暗号化と復号化を管理しなければなりません。また、Amazon RDS 内での SSL サポートは、お客様のアプリケーションと DB インスタンス間での接続暗号化のためにあることにご注意ください。これは DB インスタンスそのものの認証に使用されるべきではありません。

SSL がセキュリティ上の利点を提供する一方で、SSL 暗号化がかなりの計算処理を必要とするオペレーションであり、お客様のデータベース接続の待ち時間を増加させることにご注意ください。SSL と MySQL の連携方法の詳細については、ここにある MySQL の文書を直接ご参照ください。

GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL

Amazon RDS は、DB インスタンスのコンピュートリソースとストレージ容量を考慮して、デフォルト値として DB インスタンス用に最適の設定パラメータを選択します。しかし、それらを変更したい場合には、当社の設定管理 API を使用します。推奨値からの設定パラメータの変更は、性能の低下からシステムクラッシュまで、予期しない影響を生じる場合があり、これらのリスクを想定した高度なユーザーのみが行うべきであることにご注意ください。パラメータ変更に関する詳細については、Amazon RDS 文書をご覧ください。

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

Amazon Management Console、Amazon RDS API またはコマンドラインツールを使用して、DB パラメータグループおよび該当するパラメータ設定についての情報を知ることができます。

Amazon RDS は MySQL と Oracle データベースエンジンをサポートしています。お客様は、要件を最適に満たすデータベースエンジンを選ぶことができます。現在、レプリケーションは MySQL エンジンのみでサポートされています。将来的には、Oracle のレプリケーションオプションもサポートする予定です。

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

予期しない電源障害などが発生した時にデータベースの最新更新状態を保ちながらデータベースの可用性を高めたい場合は、DB インスタンスを Multi-AZ 配備として実行することを考慮します。DB インスタンスを作成または修正して Multi-AZ 配備として実行する場合、Amazon RDS は異なる Availability Zone で「スタンバイ」レプリカを自動的にプロビジョニングして管理します（個別のインフラストラクチャが物理的に分離した場所にある）。予定されたデータベースメンテナンスまたは予期せぬサービス障害時、Amazon RDS は自動的にスタンバイに対してフェイルオーバーを行い、データベース運用を手動の管理介入なく速やかに再開できます。Multi-AZ 配備は、同期レプリケーションを活用して、データベースへの書き込みをプライマリとセカンダリで同時に行い、フェイルオーバーが発生した場合にスタンバイが最新の状態を保つようにしています。Multi-AZ DB インスタンスに対する当社の技術革新により障害発生時のデータ耐久性を最大化したことで、スタンバイに直接アクセスしたり、読み込み操作に使用されなくなりました。Multi-AZ 配備が提供するフォールト・トレランスは、プロダクション環境に自然に適用されます。Multi-AZ 配備に関する詳細は、この FAQ セクションをご参照ください。

MySQL に内蔵されているレプリケーション機能を使って1つの DB インスタンスの容量制限を拡大してデータベースの付加を緩和させたい場合は、Amazon RDS でリードレプリカを使用すると簡単です。AWS Management Console または CreateDBInstanceReadReplica API を使うと、与えられた「ソース」DB インスタンスのリードレプリカが作成できます。リードレプリカを作成すると、データベースがソース DB インスタンスを更新して、リードレプリカにプロパゲートされます。与えられた1つのソース DB インスタンスに対して複数のリードレプリカを作成して、アプリケーションの読み込みトラフィックをレプリケーションできます。Multi-AZ 配備とは異なり、リードレプリカは、MySQL に内蔵されているレプリケーション機能を使います。これには、その長所と制限が適用されます。特に、ソース DB インスタンスに更新が発生した後にリードレプリカにも更新が適用されます（「非同期」レプリケーション）。つまり、レプリケーションに大幅な遅延が生じます。これは、標準（Multi-AZ でない）ソース DB インスタンスに最新のデータベース更新は、ソース DB インスタンスに予期しない障害が発生した場合にリードレプリカには適用されていない場合があることを意味します。そのような場合、リードレプリカは、Multi-AZ 配備が提供するものと同じデータ耐久性を提供できません。リードレプリカにはいくつかの可用性の面で利点がありますが、書込み精度を提供するものではありません。

Amazon RDS を使うと、Multi-AZ 配備とリードレプリカを使って、それぞれの利点を総合的に活用することができます。与えられた Multi-AZ 配備がお客様のリードレプリカのソース DB インスタンスであることを指定するだけです。この方法により、Multi-AZ 配備のデータ耐久性と可用性、およびリードレプリカの読込み能力の拡大という両面の利点を得ることができます。

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

DBインスタンスを Multi-AZ 配備として実行することの主な利点は、データベースの堅牢性と可用性を強化することです。Multi-AZ 配備によって提供される可用性とフォールト・トレランス（障害体制）の強化は、重要な運用環境に対して間違いなく適合するものです。

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

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

DB インスタンスを Multi-AZ配備として実行することの別の目立たない恩恵として、DB インスタンスのフェイルオーバーが自動であり、手動管理が必要ないことがあります。Amazon RDS のコンテキストでは、これは Availability Zone 障害または DB インスタンスの障害時に、（RestoreDBInstanceToPointInTime または RestoreDBInstanceFromSnapshot API を使用して）DB インスタンスのイベントを監視し、手動で DB インスタンスの復旧を開始する必要がないことを意味します。

• プライマリ Availability Zone の可用性損失
• プライマリに対するネットワーク接続の喪失
• プライマリ上でのコンピュートユニット障害
• プライマリへのストレージ不良
• DBインスタンスのコンピュートクラスの規模を拡大または縮小する
• ソフトウェアのパッチをする

単一の AZ で標準配備を実行していようと、Multi-AZ 配備を実行していようと、自動バックアップと DB スナップショット機能に対して、同様の方法でやりとりすることができます。Multi-AZ 配備を実行している場合、自動バックアップとDBスナップショットは、プライマリでのI/O中断を避けるために、単純にスタンバイから取得されます。バックアップ時は、I/O の遅延が長くなる可能性がありますのでご注意ください（通常は数分間です）。

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

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

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

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

リードレプリカにはトランザクションストレージエンジンが必要であり、InnoDB ストレージエンジンでのみサポートされています。

MyISAM などの非トランザクションエンジンでは、リードレプリカが意図したとおりに動作しない可能性があります。それでも MyISAM でリードレプリカを使用する場合は、Amazon CloudWatch の「レプリカラグ」の計測値（AWS Management Console または Amazon Cloud Watch API を介して取得できます）を注意して監視し、レプリケーションエラーが原因でリードレプリカが停止した場合は再作成することをお勧めします。一時テーブルや他の非トランザクションエンジンを使用する場合も、同様の注意事項が適用されます。

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

Amazon RDS リードレプリカでは、簡単に削除できます。Amazon RDS Management Console を使う、または DeleteDBInstance API（削除したいリードレプリカに対する DBInstanceIdentifier を指定）を呼び出します。

リードレプリカの作成をリクエストする場合は、以下の事柄に注意してください。

• MyISAM などの非処理エンジンを使う場合は、以下の手順に従ってリードレプリカを設定する必要があります。この手順は、リードレプリカがお客様のデータと一致するために必要です。ただし、すべてのテーブルが InnoDB などのトランザクションを管理するエンジンを使用している場合にはこの手順は必要ありません。1. 非トランザクション テーブルのすべての DML および DDL 操作を停止して、それらが完了するまで待ちます。SELECT 記述で実行を続けます。2. それらのテーブルをフラッシュしてからロックします。3. CreateDBInstanceReadReplica API を使ってリードレプリカを作成します。4. DescribeDBInstances API を使ってレプリカの作成状況を確認します。レプリカが利用可能となったら、テーブルをアンロックして、通常のデータベース操作を再開します。

• お客様のソース RDS インスタンスにトランザクションの実行が長い物がある場合は、そのトランザクションが完了するのを待ってから、そのソースを基にしたリードレプリカの作成をリクエストしてください。

Mulit-AZ フェイルオーバーが発生した後は、リードレプリカを受信できない、またはソース Mulit-AZ DB インスタンスから更新を適用できない場合があります。これは、いくつかの MySQL バイナリログ イベントがフェイルオーバーの時点でディスクにフラッシュされていないからです。フェイルオーバーの後、リードレプリカは、存在しないソースからバイナリログを要求している可能性があります。このクラッシュによる MySQL バイナリログの損失については、この MySQL 文書に記されています。

この問題に関する情報は、MySQL sync-binlog パラメータを説明している行の下に説明されています。このパラメータは、MySQL バイナリログをディスクにフラッシュする方法をコントロールし、InnoDB を使うタイミング、バイナリログと InnoDB ログを同期する方法をコントロールします。

現在の問題を解決するためには、リードレプリカを削除して、代わりとなる新しいリードレプリカを作成する必要があります。今後この問題を回避するためには、sync-binlog=1 に設定すると、クラッシュやフェイルオーバーが発生した際にリードレプリカが要求する MySQL バイナリログを損失する可能性が大幅に減ります。MySQL 文書が説明する通り、上述を行っても完全にこの問題を解決することはできません。さらにこの問題に遭遇する可能性を減らすには、innodb_support_xa=1 を設定します。これらの変数を設定すると、パフォーマンスに影響が出る場合があります。sync_binlog と innodb_support_xa は双方ともに動的変数であるため、パフォーマンスへの影響が大きすぎる場合は、停止しなくてもそれらをリセットできます。

これは、パフォーマンスまたはソース Multi-AZ のフェイルオーバーが発生した後のリードレプリカの自動再同期の改善のどちらを優先するかという究極の選択です。Amazon RDS Read Replicas を使う利点の1つは、削除による同期の問題が発生した時に迅速に再度インスタンスの作成を行うことができます。それ自体は、同期リードレプリカを手動で中断し、自分のニーズに合うリードレプリカを再作成する場合に、同期バイナリログおよび/または innodb_support_xa の設定がパフォーマンスに影響することはありません。　

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

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

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

標準の DescribeDBInstances API を使って、お客様が配備したすべての DB インスタンス（リードレプリカを含む）の一覧に戻る、または Amazon RDS Management Console の「DB インスタンス」タブをクリックします。

Amazon RDS を使うと、リードレプリカに対して 標準の「Show Slave Status」 MySQL コマンドを発行して、リードレプリカがどの程度そのソース DB インスタンスから遅れているかを見ることができます。「Show Slave Status」が返す「Seconds_Behind_Master」データは、AWS Management Console または Amazon Cloud Watch API 経由で利用可能な Amazon CloudWatch 測定基準（「レプリカラグ」）として公開されています。

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

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

Amazon RDS を使うと、お客様の DB インスタンス（MySQ など）を強化するリレーショナルデータベースソフトウェアを Amazon RDS でサポートする新しいバージョンにアップグレードすべきか、およびそのタイミングをコントロールします。 これにより、特定の SQL バージョンとの互換性を維持する、プロダクションに展開する前にアプリケーションで新しいバージョンをテストする、ユーザー独自の条件とタイムラインでバージョンのアップグレードを実行する柔軟性を提供します。

お客様が指定しない限り、お客様の DB インスタンスは、新しい MySQL マイナーバージョン（Amazon RDS がサポートするバージョン）に自動的にアップグレードされます。このパッチは、予定されたメンテナンスウィンドウで行われ、事前に Amazon RDS フォーラムで告知されます。自動バージョンアップグレードをオフにしたい場合は、AutoMinorVersionUpgrade パラメータを「false」に設定します。メジャーバージョンアップグレードには互換性のリスクが伴います。したがって、自動的には行われません。ご自分の責任で実施してください。

このデータベースソフトウェアのパッチは、管理面でのバージョンアップグレードが行われますが、Amazon RDS に対するアプリケーションのパッチを手動で行う必要もあります。バージョン管理について詳しく知るには、該当する FAQ をご覧ください。また、当社の開発者ガイドもご参照ください。

DB Engine バージョン管理機能では、パッチ発生を可能な限りお客様が管理できるようにしていますが、データベースソフトウェアにおいて重要なセキュリティ脆弱性が発生した場合は、お客様に代わって Amazon RDS が DB インスタンスをパッチする可能性があります。

ユーザーは、CreateDBInstance API を使って新しい DB インスタンスを作成する時に現在サポートされているバージョン（マイナー、またはメジャー）ならどれでも指定することができます。作成時に希望するバージョンを EngineVersion パラメータに渡します。バージョンを指定しない場合は、Amazon RDS がデフォルトのバージョン（通常は最新のバージョン）を指定します。マイナーバージョンではなく、メジャーバージョン（MySQL 5.1など）を指定した場合は、Amazon RDS は、お客様が指定したメジャーバージョンの最新リリースをデフォルトに設定します。サポートされているバージョンの一覧と新しく作成される DB インスタンスのデフォルトを見るには、DescribeDBEngineVersions API を使います。

AutoMinorVersionUpgrade パラメータを false に設定して自動アップグレードを行わないようにして、手動でサポートされているマイナーバージョンまたはメジャーバージョンへのアップグレードを実行したい場合は、ModifyDBInstance API を使います。EngineVersion パラメータにアップグレードしたいバージョンを指定します。これにより、アップグレードを即時に実行する（ApplyImmediately フラグが true に設定されている場合）、または DB インスタンスの次の予定メンテナンスウィンドウで実行されます。

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

MySQL においてバージョン番号は以下のように整理されています。

MySQL バージョン = X.Y.Z

X = メジャーバージョン、Y = リリースレベル、Z = リリースシリーズ内のバージョン番号Version number within release series.

Amazon RDS では、メジャーバージョンまたはリリースレベが変更されると、バージョン変更がメジャーであると判断します。例: 5.1.X -> 5.5.X. の場合。同じリリースでバージョン番号が変更されていれば、バージョン変更は、マイナーであると判断します。例: 5.1.45 -> 5.1.49。

現在、Amazon RDS は、MySQL メジャーバージョン MySQL 5.1 および MySQL 5.5 をサポートしています。今後もさらに多くの MySQL メジャーバージョンのサポートを予定しています。

今後、当社では、Amazon RDS に対してさらに多くの MySQL バージョン、マイナーとメジャーの両方のサポートを計画しています。毎年サポートされる新しいバージョンリリースの数は、MySQL バージョンリリースの頻度とコンテンツ、および当社のデータベース技術チームのリリース診断結果により異なります。ただし、一般的なガイダンスとして、当社では、一般公開リリースの3～5ヵ月以内に新しい MySQL バージョンをサポートできるよう取り組んでいます。

廃止のポリシーについて:

• 当社ではメジャー MySQL バージョンリリース（MySQL 5.1 を含む）に対して、Amazon RDS によるサポートが開始されてから 3年間のサポートを予定しています。
• マイナー MySQL バージョンリリース（MySQL 5.1.45 など）に対しては、Amazon RDS によるサポートが開始されてから、少なくとも1年間のサポートを予定しています。
• MySQL メジャー/マイナーバージョンが「廃止」となった後は、予定メンテナンスで自動アップグレードされる前に、ユーザーがサポート対象バージョンにアップグレードするための猶予期間を3ヵ月間設けます。

新しい MySQL 5.5 DB インスタンスの作成には、AWS Management Console の「DB インスタンスの起動ウィザード」を使い、MySQL 5.5 に対応するバージョンを選択する、または CreateDBInstance API の Engine Version パラメータに「5.5」を設定します。

現在、MySQL 5.1 から MySQL 5.5 への直接アップグレードはサポートされていません。ただし、将来的にはこの機能にも対応する予定です。現状、既存の MySQL 5.1 データベースを MySQL 5.5 にポートしたい場合は、mysqldump を使って既存の MySQL 5.1 DB インスタンスからエクスポートして、新しい MySQL 5.5 DB インスタンスにインポートします。

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 マネジメント機能が含まれています。

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

• BYOL: スタンダードエディション1（SE1）、スタンダードエディション（SE）、およびエンタープライズエディション（EE）
• ライセンス込み: スタンダードエディション1（SE1）

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

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

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

Oracle のコンテキストでは、Amazon RDS DB Engine バージョンは次のように構成されています:

Oracle 用 DB Engine バージョン= X.Y.Z

X=メジャーバージョン（例: 11.2）、Y=リリースレベル（例: 0.2）、Z=リリースシリーズのバージョン番号（例: V2）。例えば、Oracle 用 DB Engine バージョンは 11.2.0.2.v2 のようになります。

Oracle は、四半期ごとにサポートされているリリースレベルでデータベースパッチセット更新（PSU）をリリースします（例: 11.2.0.2.1）。PSU には、セキュリティの修正と Oracle が推奨する追加のセキュリティ関連以外の修正が含まれています。

Amazon RDS DB Engine バージョンは、ベースラインとして指定された PSU で構築されており、それ以外の追加の修正が含まれている場合があります。

Amazon RDS では、メジャーバージョンまたはリリースレベが変更されると、バージョン変更がメジャーであると判断します。例: 11.2.0.2.Z -> 11.2.0.4.Z の場合。同じリリースでバージョン番号が変更されていれば、バージョン変更は、マイナーであると判断します。例: 11.2.0.2.v2 -> 11.2.0.2.v3 の場合。

現時点では、Amazon RDS はメジャーバージョン11.2（11g リリース2）をサポートしています。将来的には、追加のメジャーバージョンをサポートする予定です。

Oracle の各 DB Engin バージョンのパッチセットの構成に関する詳細については、Amazon RDS ユーザーガイドをご参照ください。

Amazon RDS では、DB インスタンスを駆動しているリレーショナルデータベースソフトウェアを Amazon RDS でサポートされている新しいバージョンにアップグレードする時期をコントロールできます。これにより、特定の Oracle データベースバージョンとの互換性を維持する、プロダクションに展開する前にアプリケーションで新しいバージョンをお客様のアプリケーションでテストする、独自の条件とタイムラインでバージョンのアップグレードを実行する柔軟性が提供されます。

指定がない限り、お客様の DB インスタンスは、Amazon RDS がサポートする新しい DB Engine バージョンに自動的にアップグレードされます。このパッチは、予定されているメンテナンスウィンドウで行われ、事前に Amazon RDS フォーラムで告知されます。バージョンの自動アップグレードをオフにしたい場合は、[マイナーバージョンの自動アップグレード] フィールドを [いいえ] に設定してください。メジャーバージョンアップグレードには互換性のリスクが伴います。したがって、自動的には行われません。ご自分の責任で実施してください。

このデータベースソフトウェアのパッチは、管理面でのバージョンアップグレードが行われますが、Amazon RDS に対するアプリケーションのパッチを手動で行う必要もあります。バージョン管理について詳しく知るには、該当する FAQ をご覧ください。また、当社の開発者ガイドもご参照ください。

DB Engine バージョン管理機能では、パッチ発生を可能な限りお客様が管理できるようにしていますが、データベースソフトウェアにおいて重要なセキュリティ脆弱性が発生した場合は、お客様に代わって Amazon RDS が DB インスタンスをパッチする可能性があります。

AWS Management Console または CreateDBInstance API の「DB インスタンスの起動」オプションを介して新しい DB インスタンスを作成する際に、現在サポートされているすべてのバージョンを（マイナーおよび/またはメジャー）を指定することができます。

AutoMinorVersionUpgrade パラメータを false に設定して自動アップグレードを行わないようにして、手動でサポートされているマイナーバージョンまたはメジャーバージョンへのアップグレードを実行したい場合は、ModifyDBInstance API を使います。EngineVersion パラメータにアップグレードしたいバージョンを指定します。アップグレードはお客様の代わりに即時に実行される（「ApplyImmediately」フラグが設定されている場合）か、または DB インスタンスの次の予定されているメンテナンスウィンドウで実行されます。

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

今後、当社では Amazon RDS に対して、マイナーとメジャーの両方で、追加の Oracle データベースバージョンのサポートを計画しています。サポートされる新しいバージョンリリースのその年の数は、Oracle パッチセットアップグレード（PSU）の頻度とコンテンツ、および当社のデータベース技術チームのリリース診断結果により異なります。ただし、一般的なガイダンスとして、当社では、一般公開の3～5ヵ月以内に新しい Oracle データベースバージョンをサポートできるよう取り組んでいます。

廃止のポリシーについて:

• 当社ではメジャーバージョンリリースに対して、Amazon RDS によるサポートが開始されてから3年間のサポートを予定しています。
• マイナー Oracle データベースバージョン（例えば、11.2.0.2.v2 など）に対しては、Amazon RDS によるサポートが開始されてから、少なくとも1年間のサポートを予定しています。
• メジャー/マイナーバージョンが「廃止」となった後は、予定メンテナンスで自動アップグレードされる前に、ユーザーがサポート対象バージョンにアップグレードするための猶予期間を3ヵ月間設けます。

BYOL モデルでは、Oracle のライセンスの条件に従って、DB インスタンスを縮小・拡張することができます。

ライセンス込みモデルでは、Oracle を実行している DB インスタンスは、いつでも縮小・拡張することができ、各 DB インスタンスのクラスの存続している時間単位の料金の対象となります。

リザーブド DB インスタンスの縮小・拡張の影響の詳細については、当社のリザーブド DB インスタンス FAQ をご参照ください。

BYOL モデルでは、実行する予定の DB インスタンスのエディションおよびクラスに適切な未使用の Oracle ライセンスを保有している限り、1つの Oracle ソフトウェアのエディションから別のエディションに移行することができます。エディションを変更してデータを保持するには、実行中の DB インスタンスのスナップショットを取り、そのスナップショットから希望するエディションの新しい DB インスタンスを作成する必要があります。適切な Oracle データベースのライセンスを持っていて、それを実行し続けることを希望する場合を除き、その後、古い DB インスタンスは削除します。

ライセンス込みモデルの場合は、現在、Oracle のスタンダードエディション1のみがサポートされています。

MySQL 用 Amazon RDS は、Multi-AZ 配備とリードレプリカ両方をサポートしています。これらのオプションは Oracle 用 Amazon RDS では現在利用できません。しかし将来的には、Oracle のレプリケーションをサポートする予定です。

いいえ、RAC は現在サポートされていません。

以下のエンタープライズエディションのオプションが、現在 BYOL モデルでサポートされています。

• パーティション
• 管理パック（診断、調整）
• 高度な圧縮
• トータルリコール

Oracle データベースはいくつかの機能をサポートしていますが、それは実行する Oracle データベースのエディションによって異なります。Amazon RDS が現在サポートしている Oracle の機能については、Amazon RDS ユーザーガイドをご参照ください。

These are our most popular posts: