全般Amazon RDS とは何ですか?Amazon Relational Database Service (Amazon RDS) は、クラウド内でリレーショナルデータベースのセットアップ、運用、およびスケーリングを簡単に行うことのできるマネージド型サービスです。これにより、時間のかかるデータベース管理作業をお客様の代わりに実行して、お客様を管理業務から解放し、アプリケーションとビジネスに集中させることができます。このサービスはコスト効率もよく、データベース容量の変更にも柔軟に対応します。 Show
Amazon RDS では、使いなれた
MySQL、MariaDB、Oracle、SQL Server、または PostgreSQL データベースの機能を引き続き利用できます。つまり、既存のデータベースで既に使用しているコード、アプリケーション、およびツールは、Amazon RDS でシームレスに機能します。Amazon RDS
では、データベースは自動的にバックアップされ、データベースソフトウェアは最新バージョンによって最新の状態に保たれます。リレーショナルデータベースインスタンスに関連するコンピューティングリソースやストレージ容量を簡単に拡張できる柔軟性が得られます。さらに、Amazon RDS は、簡単にレプリケーションを使って、データベースの可用性を強化、データの耐久性を改善、ひとつのデータベースインスタンスの容量制限を拡張して読み込み付加を軽減することができるようにします。Amazon Web Services のすべてのサービスと同様に、初期費用は不要です。使用したリソースに対してのみ支払いが発生します。 Amazon RDS とAmazon EC2 Relational Database AMI はどのように使い分けますか?開発者は、Amazon ウェブ
サービスでデータベースに関するいくつかの選択肢を利用できます。Amazon RDS を利用すると、フルマネージドでフル機能のリレーショナルデータベースを、データベース管理の負担なしで運用できます。Amazon EC2 で AWS のさまざまなリレーショナルデータベース AMI のいずれかを使用することにより、クラウド内でお客様自身のリレーショナルデータベースを管理できます。これらの選択肢の間には大きな違いがあるため、実際のユースケースに応じて最適なものを選ぶときは、この違いを考慮する必要があります。お客様にとって最適なソリューションを選択するガイダンスについては、AWS が提供するクラウドデータベースをご覧ください。 Amazon RDS 用のハイブリッドまたはオンプレミスのデプロイオプションはありますか?はい。Amazon RDS と Amazon RDS on Outposts を使用して、オンプレミスで RDS を実行できます。詳細については、Amazon RDS on Outposts のよくある質問をご覧ください。 Amazon RDS の詳細を知り、オンボードするためのサポートを受けることはできますか?はい、Amazon RDS
スペシャリストが質問に答え、サポートをご提供します。お問い合わせいただければ、1 営業日以内に私たちからご連絡し、AWS がお客様の組織にどのように役立つかをご説明します。 Amazon EC2 コンピューティングインスタンス上で動作するアプリケーションまたは SQL ベースのクライアントと、Amazon RDS データベースインスタンス/クラスター間の接続をセットアップするにはどうすればよいですか?Amazon RDS
コンソールを使用して、EC2 コンピューティングインスタンスと新しい Amazon RDS データベース間の接続をセットアップすることができます。[Create database] (データベースの作成) ページで、[Connectivity] (接続) セクションにある [Connect to an EC2 compute resource] (EC2 コンピューティングリソースに接続) オプションを選択します。このオプションを選択すると、Amazon RDS は、VPC、セキュリティグループ、サブネット、および Ingress/Egress ルールの作成などの手動ネットワークセットアップタスクを自動化し、アプリケーションとデータベース間の接続を確立します。 さらに、既存の Amazon RDS データベースと EC2 コンピューティングインスタンスの間の接続をセットアップすることができます。これを行うには、RDS コンソールを開き、データベースリストページから RDS データベースを選択し、[Action] (アクション) メニュードロップダウンリストから
[Set up EC2 connection] (EC2 接続をセットアップ) を選択します。Amazon RDS では、関連するネットワーク設定が自動でセットアップされ、選択した EC2 インスタンスと RDS データベース間の安全な接続が実現されます。 この接続の自動化は、新規ユーザーやアプリケーションデベロッパーの生産性を向上させます。ユーザーは、EC2 コンピューティングインスタンス上で SQL を使用するアプリケーションやクライアントを、数分以内に迅速かつシームレスに RDS データベースに接続できるようになりました。 データベースインスタンスデータベース インスタンス (DB インスタンス) とは何ですか?DB インスタンスを、お客様が指定したコンピューティングおよびストレージリソースを備えた、クラウド内のデータベース環境であると考えることができます。DB インスタンスの作成と削除、DB インスタンスのインフラストラクチャ属性の定義や改良を行うことができ、さらに AWS マネジメントコンソール、Amazon RDS
API、AWS コマンドラインインターフェイスを使用してアクセスとセキュリティを管理できます。1 つ以上の DB インスタンスを実行でき、各 DB インスタンスは、1 つ以上のデータベースまたはデータベーススキーマをサポートできます (エンジンタイプによる)。 DB インスタンスをどのように作成しますか?DB インスタンスは、AWS マネジメントコンソール、Amazon RDS API、AWS コマンドラインインターフェイスを使用して、簡単に作成できます。AWS マネジメントコンソールを使用して DB インスタンスを起動するには、[RDS] をクリックし、次に [インスタンス] タブにある [DB インスタンスの起動] ボタンをクリックします。そこから、DB エンジンとバージョン、ライセンスモデル、インスタンスタイプ、ストレージタイプと量、およびプライマリユーザーの認証情報を含む DB インスタンスに対して、パラメータを指定できます。 DB インスタンスのバックアップ保持ポリシー、任意のバックアップウィンドウ、予定メンテナンスウィンドウを変更することも可能です。代わりに、CreateDBInstance API や create-db-instance コマンドを使用して、DB インスタンスを作成することも可能です。 私の実行中の DB インスタンスにどのようにアクセスしますか?いったん DB インスタンスが利用可能になったらAWS マネジメントコンソール、DescribeDBInstances API、describe-db-instances コマンドの DB インスタンスの説明を使用して、そのエンドポイントを取得できます。このエンドポイントを使用して、使い慣れたデータベースツールまたはプログラミング言語により、DB
インスタンスに直接接続するために必要な接続ストリングを作成できます。実行中の DB インスタンスに対するネットワークリクエストを許可するため、アクセスを許可する必要があります。接続文字列の作成方法および開始方法についての詳細は、AWS の入門ガイドをご覧ください。 Amazon RDS でいくつの DB インスタンスを実行できますか?デフォルトにより、お客様は合計 40 個までの Amazon RDS DB インスタンスを保有することができます。この 40 個のインスタンスのうち 10 個までは、"ライセンス込み" モデルの Oracle または SQL Server DB インスタンスとすることができます。40 個のインスタンスはすべて、"BYOL" モデルで Amazon Aurora、MySQL、MariaDB、PostgreSQL、Oracle に使用できます。RDS for SQL Server は 1 つの DB インスタンスで最大 100 個のデータベースに制限されています。詳細については、Amazon RDS for SQL Server ユーザーガイドを参照してください。 アプリケーションにこの制限を超える DB
インスタンスが必要である場合、こちらの申請フォームで追加の DB インスタンスをリクエストできます。 1 つの DB インスタンスで何個のデータベースまたはスキーマを実行できますか?
Amazon RDS DB インスタンスにデータをインポートする方法を教えてください。メンテナンスウィンドウとは何ですか? メンテナンスイベント中にも DB インスタンスを使用できますか?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 RDS ではどのリレーショナルデータベースエンジンのバージョンがサポートされていますか?Amazon RDS では、どのように "メジャー" と "マイナー" の DB エンジンバージョンが区別されますか?Amazon RDS では、新しいバージョンの DB エンジンのサポートガイドラインが提供されますか?Amazon RDS
では、メジャーとマイナーのデータベースエンジンの新しいバージョンが徐々に追加されます。サポートされる新しいバージョンの数は、エンジンのベンダーや開発組織からのリリースやパッチの頻度とその内容、および AWS のデータベースエンジニアリングチームのリリースおよびパッチの診断結果により異なります。ただし、一般的なガイダンスとして、AWS では、一般公開から 5 か月以内に新しいバージョンのエンジンをサポートできるよう取り組んでいます。 自分の DB インスタンスで実行する、サポートされている DB Engine バージョンはどのように指定しますか?AWS マネジメントコンソールまたは CreateDBInstance API の [DB インスタンスの起動] をクリックして新しい DB インスタンスを作成する際に、現在サポートされているバージョン (マイナーおよびメジャー) のいずれかを指定することができます。すべての AWS リージョンですべてのバージョンのデータベースエンジンを利用できるとは限りません。 使用中の DB インスタンスのエンジンバージョンが新しいサポートバージョンに更新されるかどうか、およびその時期をどのように制御できますか?サポート対象の新しいバージョンのデータベースエンジンを提供することで、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 インスタンスで安全性を確かめることができます。 DB スナップショットの復元については、Amazon RDS ユーザーガイドを参照してください。 Amazon RDS では、現在サポートされているバージョンのデータベースエンジンの廃止についてガイドラインが提供されていますか?
AWS では、定期的にメジャーまたはマイナーのエンジンバージョンの廃止を行います。メジャーバージョンは、少なくとも対応するコミュニティバージョンが終了するか、ソフトウェアの修正またはセキュリティアップデートが行われなくなるまで利用できるようにします。マイナーバージョンについては、そのマイナーバージョンに、以降のバージョンで解決された重大なバグやセキュリティ上の問題が含まれている場合に廃止します。 これらのガイドラインを満たすための作業が行われていますが、特定のメジャーバージョンまたはマイナーバージョンにセキュリティの問題がある場合には、予定より早く廃止する可能性があります。そのような状況が発生する見込みがない場合は、Amazon
RDS では、データベースエンジンの自動アップグレードを実施して、問題に対処します。特定の状況では、対処すべき問題によって別のスケジュールを決定する可能性があります。 Amazon RDS DB のエンジンバージョンが廃止されるとどうなりますか?Amazon RDS でデータベースエンジンのマイナーバージョンが廃止される場合、発表から自動アップグレード開始まで 3 か月の期間が設定されます。この期間が終了すると、廃止されるマイナーバージョンを実行しているすべてのインスタンスには、スケジュールされたメンテナンスウィンドウ内に、サポート対象となっている最新のマイナーバージョンへの自動アップグレードスケジュールが設定されます。 Amazon RDS
でデータベースエンジンのメジャーバージョンが廃止される場合、廃止の発表から少なくとも 6 か月の期間が設定されるため、この期間にサポート対象となっているメジャーバージョンへのアップグレードを開始できます。この期間が終了すると、廃止されるバージョンを実行しているインスタンスには、次のメジャーバージョンへの自動アップグレードが適用され、スケジュールされたメンテナンスウィンドウ中にアップグレードされます。 特定のメジャーまたはマイナーバージョンのデータベースエンジンが Amazon RDS で廃止される場合、サポートされていないバージョンで作成された DB スナップショットから復元された DB インスタンスは、自動的かつすみやかに現在サポートされているバージョンにアップグレードされます。 特定のバージョンを作成できないのはなぜですか?場合によっては、特定のメジャーバージョンまたはマイナーバージョンが、当社の高い品質、パフォーマンス、またはセキュリティの水準を満たさないことが判明した場合など、事前の通知なしに廃止とされることがあります。万一このようなケースが発生した場合には、Amazon
RDS はこれらのバージョンによる新しいデータベースインスタンスおよびクラスターの作成を中止します。既存のお客様は、引き続きデータベースの運用が可能です。特定の状況では、対処すべき問題によって別のスケジュールを決定する可能性があります。 請求Amazon RDS の使用に対してどのように課金・請求されますか?使用料金は従量課金制となっており、最低料金やセットアップ料金はありません。以下の内容に基づき、請求が行われます。
Amazon RDS の利用料金については、Amazon RDS 製品ページの料金表をご覧ください。 Amazon RDS DB インスタンスへの請求はいつ始まり、いつ終わりますか?DB インスタンスが利用可能になるとすぐに、DB インスタンスへの請求が始まります。削除またはインスタンス障害の際に発生する DB
インスタンスの削除まで、請求が続きます。 請求可能な Amazon RDS インスタンス時間をどのように定義していますか?利用可能な状態で DB インスタンスが動作している各時間に対して、DB インスタンス時間が請求されます。これ以上 DB インスタンスへの課金を望まない場合は、追加のインスタンス時間に対して請求されないよう、DB インスタンスを停止するか、終了する必要があります。 DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の消費された DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。 停止した DB インスタンスに対してどのように請求されますか?データベースを停止している間でも、プロビジョニングされたストレージ (プロビジョンド IOPS を含む) やバックアップストレージ (指定した保持期間内の手動スナップショットや自動バックアップを含む) に対して課金されます。ただし、DB インスタンス時間に対して料金が発生することはありません。 追加バックアップストレージは割り当てられた DB インスタンスストレージよりもコストがかかるのはなぜですか?お客様の一次データ用の DB
インスタンスに対してプロビジョニングされたストレージは、単一のアベイラビリティゾーン内に存在しています。データベースをバックアップすると、 (トランザクション ログを含む) バックアップ データは、より優れたレベルのデータ耐久性を提供するため、複数のアベイラビリティゾーンに対して地理的な冗長性をもってレプリケーションされます。無料割当量を超えたバックアップ ストレージの価格は、クリティカル バックアップの耐久性を最大化するために発生する、この特別なレプリケーションを反映しています。 マルチ AZ DB インスタンス配置に対してどのように請求されるのですか?お客様の DB インスタンスがマルチ AZ 配置となるよう指定する場合、Amazon RDS 料金ページに記載されたマルチ AZ 料金設定に応じて料金が請求されます。マルチ AZ の料金は に基づきます。
価格には税金が含まれていますか?別途記載がない限り、表示される料金には VAT、売上税その他取引に対して適用される一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS のサービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細はこちら。 無料利用枠Amazon RDS での AWS 無料利用枠は何を提供していますか?さらに、Amazon RDS の AWS 無料利用枠では、MySQL、MariaDB、PostgreSQL、Oracle (「Bring-Your-Own-License (BYOL)」ライセンスモデル)、および SQL Server Express Edition を実行するシングル AZ マイクロ DB インスタンスの使用が無料です。無料利用枠は、1 か月あたり 750 インスタンス時間までとなっています。さらに、お客様は、1 か月あたり 20 GB の汎用 (SSD) データベースストレージと 20 GB のバックアップストレージを無料でご利用いただけます。 Amazon RDS での AWS 無料利用枠をどれくらいの期間、利用することができるのですか?新しい AWS アカウントを取得すると、12 か月の AWS 無料利用枠をお使いいただけます。詳細については、「AWS 無料利用枠のよくある質問ページ」を参照してください。 Amazon RDS での AWS 無料利用枠において、複数の DB インスタンスを実行できますか?はい。同時に複数のシングル AZ マイクロ DB インスタンスを実行でき、それらの使用量は Amazon RDS での AWS 無料利用枠内で計算されます。ただし、すべての Amazon RDS シングル AZ マイクロ DB インスタンス、およびすべての対象データベースエンジンおよびリージョンについて 750 インスタンス時間を超えるご利用については、標準の Amazon RDS 料金が課金されます。 例: 1 か月で 2 つのシングル AZ マイクロ DB インスタンスをそれぞれ 400 時間実行した場合、累算で 800 インスタンス時間の使用量になり、そのうち 750 時間が無料になります。残りの 50 時間分については、標準の Amazon RDS 料金が課金されます。 AWS 無料利用枠では、MySQL、MariaDB、PostgreSQL、Oracle、および SQL Server のマイクロ DB インスタンスについて、それぞれ 750 インスタンス時間アクセスできるのですか?いいえ、AWS 無料利用枠へのアクセス権を持つお客様は、MySQL、PostgreSQL、Oracle、または SQL Server Express Edition のいずれかを実行するマイクロインスタンスを 750 インスタンス時間までご利用いただけます。すべての Amazon RDS シングル AZ マイクロ DB インスタンスおよび、すべての対象データベースエンジンおよびリージョンについて 750
インスタンス時間を超えるご利用については、標準の Amazon RDS 料金が請求されます。 インスタンス時間の使用量が無料利用枠を超えると、どのように課金されますか?無料利用枠が提供するインスタンス時間を超えた時間については、標準の Amazon RDS 料金が課金されます。詳細については、「Amazon RDS 料金表のページ」を参照してください。 リザーブドインスタンスリザーブドインスタンス (RI) とは何ですか?Amazon RDS リザーブドインスタンスでは、1 年契約または 3 年契約で DB インスタンスを予約でき、DB インスタンスのオンデマンドインスタンス料金に比べて、大幅な割引を受けられます。RI の料金お支払い方法には「前払いなし」、「一部前払い」、「全額前払い」の 3 つがあり、前払いする金額と実際の時間あたりの料金とのバランスを取ることができます。 リザーブド インスタンスはオンデマンド DB インスタンスとどのように異なりますか?機能的には、リザーブドインスタンスもオンデマンド
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 インスタンスをリザーブドインスタンスでカバーしたい場合はどうしますか?現在実行している、または予約を考えている DB インスタンスと同じリージョン内の同じ DB インスタンスのクラス、DB エンジン、マルチ AZ オプション、およびライセンスモデルで、DB インスタンスの予約を購入します。予約購入が完了すると、Amazon RDS は既存の DB インスタンスに時間単位の新しい利用料金を自動的に適用します。 リザーブドインスタンスに登録すると、いつから期間が始まりますか? DB インスタンスの使用期限が過ぎるとどうなりますか?支払い認証の処理中にお客様からのリクエストがあれば、リザーブドインスタンスに関連する価格変更が有効になります。AWS Account Activity ページや DescribeReservedDBInstances API、describe-reserved-db-instances コマンドを使用して予約状況を確認できます。次の請求期間までに一括払いが正常に承認されない場合、割引料金は適用されません。 予約期限が過ぎると、リザーブドインスタンスは、お客様の DB インスタンスクラスとリージョンに該当するオンデマンド時間料金に変わります。 リザーブド インスタンスの料金で請求されるインスタンスはどれにするのか、どのようにコントロールするのですか?DB インスタンスの作成、修正、削除を実行する Amazon RDS オペレーションでは、オンデマンドとリザーブドインスタンスは区別されません。お客様への請求額を計算する際、AWS のシステムは、お客様の予約状態を自動的に適用して、該当するすべての DB インスタンスに低料金のリザーブド 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 ユーザーガイドを参照してください。 1 つのリージョン/アベイラビリティゾーンから別のリージョン/アベイラビリティゾーンへ、リザーブドインスタンスを移動できますか?リザーブドインスタンスは、それぞれ特定のリージョンに関連付けられています。予約の存続期間中これは固定であり、変更できません。ただし、それぞれの予約は、そのリージョン内のどのアベイラビリティゾーンでも使用できます。 リザーブド インスタンスはマルチ AZ 配置で利用可能ですか?はい。リザーブドインスタンスを購入すると、購入可能な DB インスタンス設定でのマルチ AZ
オプションを選択できます。さらに、リザーブドインスタンスのサイズ柔軟性をサポートする DB エンジンとライセンスモデルを使用している場合、マルチ AZ リザーブドインスタンスにはシングル AZ DB インスタンス２つが含まれます。 リザーブド インスタンスは、リードレプリカでも利用可能ですか?DB インスタンスクラスとリージョンが同じであれば、DB
インスタンス予約はリードレプリカにも適用できます。お客様の請求書を計算する際、AWS のシステムは、お客様の予約状態を自動的に適用して、該当するすべての DB インスタンスに低料金のリザーブドインスタンス料金を適用します。 予約はキャンセルできますか?いいえ。リザーブド DB インスタンスはキャンセルできず、一括払いは (該当する場合) 返金不可能です。使用したかどうかにかかわらず、リザーブド DB インスタンスの期間が終了するまで、毎時間の料金をお支払いいただきます。 支払い方法によって料金請求はどのように変わりますか?RI
の購入時に、お支払い方法として「全前払い」を選択した場合は、RI の期間全体の料金を一括で前払いしていただきます。いっさい前払いなしにすることもでき、その場合は「前払いなし」を選択します。「前払いなし」の RI の価額総額が期間内の各時間に分配され、お客様へのご請求は使用の有無にかかわらず、期間内の 1 時間ごとに発生することになります。「一部前払い」は、「全前払い」と「前払いなし」の間をとったお支払い方法です。最初に少額をお支払いいただき、使用の有無にかかわらず、期間内の 1 時間ごとに低い時間単価で計算した料金請求が発生します。 ハードウェアとスケーリングどの初期 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 ストレージのハードウェア構成はどのようなものですか?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
インスタンスクラスが修正されている間にデータベースは一時的に利用できなくなります。この利用できない期間は一般的に数分で終了しますが、修正をすぐに適用することを指定しない限り、DB インスタンス用のメンテナンスウィンドウ期間に発生します。 最大 DB インスタンス クラスおよび最大ストレージ容量を超えて、DB インスタンスをどのように拡張できますか?Amazon RDS では、さまざまなアプリケーションニーズを満たすため、さまざまな DB インスタンスクラスおよびストレージ割り当てをサポートしています。アプリケーションが最大 DB インスタンスクラスよりも多くのコンピューティングリソースを必要としているか、最大割当量よりも大きなストレージを必要としている場合、パーティション化の実施が可能であり、複数の DB
インスタンスにデータを分散することができます。 Amazon RDS 汎用 (SSD) ストレージとは何ですか?Amazon RDS 汎用 (SSD) ストレージは、I/O 要件が中程度の幅広いデータベースワークロードに適しています。このストレージの選択肢は基準が 3 IOPS/GB で、最大 3,000 IOPS までバーストでき、ほとんどのアプリケーションのニーズに対応する予測可能なパフォーマンスを提供します。 Amazon RDS プロビジョンド IOPS (SSD) ストレージとは何ですか?Amazon RDS プロビジョンド IOPS (SSD) ストレージとは、高速かつ予測可能な一貫した I/O パフォーマンスを提供するよう設計された SSD ベースのストレージオプションです。Amazon RDS プロビジョンド IOPS (SSD) ストレージを使用する場合は、お客様が DB インスタンスの作成時に IOPS レートを指定します。Amazon RDS では、DB インスタンスが終了させられるまでその IOPS レートをプロビジョニングします。Amazon RDS プロビジョンド IOPS (SSD) ストレージは、大量の I/O が発生する、トランザクション指向 (OLTP)
のデータベースワークロードに最適です。詳しくは、Amazon RDS ユーザーガイドを参照してください。 Amazon RDS マグネティックストレージとは何ですか?Amazon RDS
マグネティックストレージは、データへのアクセスがあまり頻繁ではない軽度のデータベースワークロードに適しています。マグネティックストレージはプロダクションデータベースインスタンスには推奨されていません。 Amazon RDS ストレージタイプはどのように選択すればよいですか?ワークロードに最も適したストレージタイプを選択してください。
Amazon RDS でサポートされる IOPS の最小値と最大値はどれくらいですか?Amazon RDS でサポートされる IOPS は、データベースエンジンによって異なります。詳しくは、Amazon RDS ユーザーガイドを参照してください。 自動化バックアップとデータベーススナップショット自動化バックアップと DB スナップショットの違いは何ですか?Amazon RDS は、DB インスタンスのバックアップと復元を行うための 2 つの方法を提供しています。自動バックアップとデータベーススナップショット (DB スナップショット) です。 Amazon RDS の自動バックアップ機能によって、DB インスタンスのポイントインタイムリカバリが可能になります。DB インスタンスに対して自動バックアップがオンになっている場合、Amazon RDS は毎日、お客様のデータの完全なスナップショットを自動的に作成し (任意のバックアップウィンドウ中に実施)、トランザクションログを取得します (DB インスタンスに対する更新が実施される)。ポイントインタイムリカバリを開始する際、DB インスタンスをリクエストされた特定の時刻の状態に復元するために、最も適切なデイリーバックアップにトランザクションログを適用します。 Amazon RDS は、DB インスタンスのバックアップを、ユーザーが指定する限られた期間 (保持期間) 中、保持します。保持期間はデフォルトでは 7 日間ですが、最大 35 日間に設定可能です。保持期間中、特定時点への復旧を開始して、最大で復元可能な最新時刻 (Latest Restorable Time) まで、任意の秒数を指定することができます。DescribeDBInstances API を使用して、DB インスタンスの復元可能な最新時刻を返すことができます。これは通常過去 5 分以内です。 代わりに、AWS マネジメントコンソールで DB インスタンスを選択し、コンソールの下部にあるパネルの [Description] タブでこれを閲覧することによって、その DB インスタンスの復元可能な最新時刻を知ることもできます。 DB スナップショットはユーザーにより開始され、指定した頻度で既知の状態で DB
インスタンスをバックアップすることができ、その後いつでもその特定の状態に復元することができます。DB スナップショットは、AWS マネジメントコンソール、CreateDBSnapshot API、create-db-snapshot コマンドで作成可能であり、ユーザーが明示的に削除するまで保存できます。 自動バックアップを有効にするため Amazon RDS により実行されるスナップショットは、コピー (AWS コンソールまたは copy-db-snapshot コマンドを使用)、またはスナップショットの復元機能用に使用できます。スナップショットは、「自動」のスナップショットタイプを使用して探すことができます。また、「スナップショットの作成時刻」フィールドを確認すると、スナップショットが取得された時刻を特定できます。 また、"自動" スナップショットの識別子にも、スナップショットが作成された時刻 (UTC) が含まれます。 注意: 期間内のある時点へ、または DB スナップショットから復旧動作を実行すると、新しいエンドポイントを持つ新しい DB インスタンスが作成されます (必要な場合には、古い DB インスタンスは削除できます)。これを実行することにより、特定の DB スナップショットまたはポイントインタイムから、複数の DB インスタンスを作成できるようになります。 私の DB インスタンスのバックアップを有効にする必要がありますか、またはそれは自動的に行われますか?デフォルトでは、Amazon RDS により、7 日の保持期間で DB
インスタンスの自動化バックアップを行うことができます。無料のバックアップストレージは準備したデータベースのサイズに限定されており、アクティブな DB インスタンスのみに適用されます。例えば、月をまたいで 100 GB のデータベースストレージが準備されていると、当社は追加料金なしで最大 100 GB/月のバックアップストレージを提供します。 バックアップ保持期間を変更したい場合、(新しい DB インスタンスの作成時には) コンソールまたは CreateDBInstance API を使用して、(既存のインスタンスに対しては) ModifyDBInstance API を使用して変更することができます。これらの API
を使用して、RetentionPeriod パラメータを 0 (自動バックアップを無効にする) から任意の日数までの数に変更できます。DB インスタンスがリードレプリカのソースである場合は、値を 0 に設定することはできません。自動化バックアップの詳細については、Amazon RDS ユーザーガイドを参照してください。 バックアップウィンドウとは何であり、なぜそれが必要ですか? バックアップウィンドウ期間で私のデータベースは利用できますか?任意のバックアップウィンドウは、DB インスタンスをバックアップする、ユーザーが定義した期間です。Amazon RDS が、トランザクションログと併せてこれらの定期データバックアップを使用することにより、 お客様は、最大で復元可能な最新時刻 (LatestRestorableTime) (一般的には最大数分前) まで、保持期間中の任意の瞬間で DB インスタンスを復元できます。バックアップウィンドウ中に、バックアッププロセスの初期化が行われている間にストレージ I/O が一時中断 (通常 2～3 秒未満) することがあり、レイテンシーが短期間増加する可能性があります。マルチ AZ DB 配置では I/O
中断はありません。なぜならバックアップがスタンバイから取得されるためです。 自動バックアップと DB スナップショットの保存場所と保持内容を管理する方法について教えてください。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 コマンドを使用して、スナップショットを削除できます。 自動化された DB スナップショットの数が、DB インスタンスに対するリテンション期間の日数よりも多いのはなぜですか?リテンション期間の日数よりも 1 日か 2 日自動化 DB のスナップショットの日数が多いのは正常です。自動化スナップショットは 1 日余計にとられていて、リテンション期間中のいつにでも復帰できる時点を設けています。 例えば、バックアップウィンドウが 1 日に設定されている場合、自動化スナップショットは 2 つ必要で、これで過去 24 時間中の任意の時点への復帰をサポートしています。また、さらに多くの自動化スナップショットがある場合もありますが、これは新たな自動化スナップショットが、最も古い自動化スナップショットを削除する前に常に生成されるためです。。 DB インスタンスを削除した場合、バックアップと DB スナップショットに何が起きますか?DB インスタンスを削除するときに、最終的な DB スナップショットを作成できます。その場合、この DB スナップショットを使用して、削除された DB インスタンスを後日復元できます。Amazon RDS は、DB インスタンスが削除された後に、このユーザーが作成した最終的な DB スナップショットと、手動で作成されたその他の DB スナップショットをすべて保持します。バックアップストレージコストの詳細については、料金ページをご覧ください。 自動化されたバックアップは、DB インスタンスが削除されるときに削除されます。DB インスタンスの削除後に保持されるのは、手動で作成された DB スナップショットのみです。 セキュリティ仮想プライベートクラウド (VPC) とは何ですか? どのように Amazon RDS と連携しますか?Amazon VPC を使用すると、AWS クラウドの分離したプライベートセクションに仮想ネットワーキング環境を作成できます。その環境では、プライベート IP
アドレスの範囲、サブネット、ルーティングテーブル、ネットワークゲートウェイなど、さまざまな要素について全面的な制御を実行できます。Amazon VPC では、仮想ネットワークトポロジを定義し、従来の IP ネットワークと同じようにネットワーク設定をカスタマイズできるため、独自のデータセンターで運用できます。 VPC を利用できる方法の 1 つは、プライベートサブネット内のパブリックにアクセスできないバックエンドサーバーを保守しながら、パブリックに公開されているウェブアプリケーションを実行する場合です。インターネットにアクセスできるウェブサーバ用にパブリック側のサブネットを作成し、インターネットアクセスできないプライベート側のサブネットにバックエンド Amazon RDS DB インスタンスを配置することができます。Amazon VPC の詳細については、Amazon Virtual Private Cloud ユーザーガイドをご覧ください。 Amazon RDS を VPC 内で使用することは、それを EC2-Classic プラットフォーム (非 VPC) 上で使用することとどのように違いますか?2013 年 12 月 4 日以前に作成した AWS アカウントでは、Amazon Elastic Compute Cloud (EC2)-Classic 環境で Amazon RDS を実行できる場合があります。Amazon RDS の基本機能は EC2-Classic を使用するか、EC2-VPC を使用するかにかかわらず同じです。Amazon RDS は、DB インスタンスが VPC
内外どちらにデプロイされるかにかかわらず、バックアップ、ソフトウェアのパッチ適用、自動障害検出、リードレプリカ、および復元を管理します。EC2-Classic と EC2-VPC の相違点の詳細については、EC2 のドキュメントを参照してください。 DB サブネットグループの概要とそれが必要な理由は何ですか?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 デプロイの場合も、どこかの時点でマルチ AZ 配置に変換する場合に備えてこのように定義する必要があります。 VPC では Amazon RDS DB インスタンスをどのように作成しますか?DB インスタンスへのネットワークアクセスはどのようにコントロールしますか?DB インスタンスのアクセスを制御する別の方法について詳しくは、Amazon RDS ユーザーガイドのセキュリティグループを参照してください。 VPC 内の Amazon RDS DB インスタンスにはどのように接続しますか?VPC 内に展開した DB インスタンスには、同じ VPC に展開した EC2 インスタンスからアクセスできます。Elastic IP が関連付けられたパブリックサブネット内にこのような EC2 インスタンスをデプロイしている場合は、インターネットを介して EC2 インスタンスにアクセスできます。VPC 内に展開した DB インスタンスには、インターネットからアクセスできるだけでなく、VPN またはパブリックサブネットで起動できる踏み台ホストを介して VPC 以外にある EC2 インスタンスからアクセスすることができます。また、Amazon RDS の Publicly Accessible オプションを使用してアクセスすることもできます。
社内ネットワークを VPC に拡張する VPN ゲートウェイを設定して、その VPC 内の Amazon RDS DB インスタンスにアクセスできるようにする方法もあります。詳細については、「Amazon VPC ユーザーガイド」をご参照ください。 基になる IP アドレスは変わる可能性があるので (フェイルオーバーなどの理由で) 、DB インスタンスに接続するときは DNS 名を使用することを強くお勧めします。 VPC 以外にある既存の DB インスタンスを自分の VPC に移動できますか?DB インスタンスが VPC 内に存在しない場合には、AWS マネジメントコンソールを使用して、VPC 内に DB インスタンスを簡単に移行できます。詳細については、Amazon RDS ユーザーガイドをご覧ください。VPC 以外にある DB インスタンスのスナップショットを作成して、VPC に復元できます。それには、使用する DB サブネットグループを指定します。または、「特定時点への復元」オペレーションを実行することもできます。 VPC 内にある既存の DB インスタンスを VPC 以外に移動できますか?VPC 内から VPC 以外への DB インスタンスの移行はサポートされていません。セキュリティ上の理由から、VPC 内の DB インスタンスの DB スナップショットを VPC 以外の場所に復元することはできません。「特定時点への復元」機能も同様です。 VPC 内にある DB インスタンスをアプリケーションからアクセスできるようにするには、どのような注意事項がありますか?ルーティングテーブルと VPC 内のネットワーキング ACL を変更して、VPC 内のクライアントインスタンスから DB インスタンスに到達できるようにする必要があります。 マルチ AZ 配置の場合は、フェイルオーバー後に、クライアントの EC2 インスタンスと Amazon RDS DB インスタンスは異なるアベイラビリティゾーンに属する可能性があります。そのため、AZ 間の通信が可能になるようにネットワーキング ACL を設定する必要があります。 DB インスタンスの DB サブネットグループを変更できますか?既存の DB サブネットグループを更新して、既存のアベイラビリティゾーン用、または DB インスタンスの作成後に追加した新しいアベイラビリティゾーン用にサブネットを追加できます。既存の DB
サブネットグループからサブネットを削除すると、サブネットグループから削除される特定の AZ で実行されているインスタンスが利用できなくなります。詳細については、Amazon RDS ユーザーガイドを参照してください。 Amazon RDS プライマリユーザーアカウントとは何ですか? AWS アカウントとどのように違うのですか?Amazon RDS の使用を始めるには、AWS デベロッパーアカウントが必要です。Amazon RDS のサインアップの前にアカウントを持っていない場合、サインアップ プロセスの開始時にアカウントを作成するよう要求されます。プライマリユーザー アカウントは、AWS 開発者アカウントとは異なっており、DB インスタンスへのアクセスをコントロールするため、Amazon RDS の範囲内でのみ使用します。プライマリユーザー アカウントは、DB インターフェイスへの接続に使用できる固有のデータベース ユーザー アカウントです。 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
ユーザーガイドをご覧ください。 Amazon RDS によるユーザー管理では何か違いがありますか?いいえ、お客様がリレーショナルデータベースを管理するときと同じ方法ですべて機能します。 私自身のデータセンターのサーバー上で動作しているプログラムは Amazon RDS データベースにアクセスできますか?はい。インターネットを介してデータベースにアクセスする機能は、セキュリティグループを設定して手動で有効にする必要があります。特定の IP アドレス、IP アドレス範囲、またはお客様自身のデータセンターにあるサーバーに該当するサブネットに対してのみアクセスを認可することができます。 SSL/TLS を用いて、アプリケーションと DB インスタンスの間の接続を暗号化できますか?Amazon RDS データベースで保管中のデータを暗号化できますか?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 リソースに対してシステムとユーザーが実行できるアクションを制御するには、どうすればよいですか?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 リソースのタグ付けを参照してください。 Amazon RDS デプロイメントに関するセキュリティ分析またはオペレーションのトラブルシューティングを実行したいと考えています。自分のアカウントで実行したすべての Amazon RDS API 呼び出しの履歴を取得することはできますか?はい。AWS CloudTrail は、アカウントに対する AWS API 呼び出しを記録し、ログファイルを配信するウェブサービスです。CloudTrail で生成される AWS API
の呼び出し履歴を利用して、セキュリティ分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。詳細は CloudTrail の AWS マネジメントコンソールのホームページでご確認ください。 Amazon RDS は HIPAA 準拠性を要するアプリケーションと使えますか?はい、Amazon RDS データベースは HIPAA に適格ですので、これらを使って HIPAA 準拠のアプリケーションを作り、ヘルスケア関連情報を格納できます。こうした情報には AWS の Business Associate Agreement (BAA) で保護された医療情報 (PHI) も含みます。 既に BAA を締結している場合は、BAA の適用を受けているアカウントでこのサービスの使用を開始するために何も行う必要はありません。AWS と BAA を締結していない場合や、AWS の
HIPAA 準拠アプリケーションについてご不明な点がある場合は、お客様のアカウントマネージャーにお問い合わせください。 データベース設定私の DB インスタンス用にどのように正しい設定パラメータを選択しますか?Amazon RDS では、デフォルトでインスタンスクラスとストレージ容量が考慮され、DB インスタンスに最適の設定パラメータが選択されます。ただし、変更する場合には AWS マネジメントコンソール、Amazon RDS API、AWS
コマンドラインインターフェイスを使用します。推奨値からの設定パラメータの変更は、性能の低下からシステムクラッシュまで、予期しない影響を生じる場合があり、これらのリスクを想定できる上級ユーザーのみが行えることにご注意ください。 DB パラメータグループとは何ですか? どのように役立ちますか?データベース パラメータグループ (DB パラメータグループ) は、1つ以上の DB インスタンスに適用可能なエンジン設定値の「容器」として動作します。DB パラメータのグループを指定せずに DB インスタンスを作成する場合、デフォルトの DB パラメータグループが使用されます。このデフォルト値のグループは、お客様が実行している DB インスタンス用に最適化されたエンジンデフォルト値と Amazon RDS システムデフォルト値を持っています。 しかし、カスタム指定のエンジン設定値で DB インスタンスを実行したい場合、新しい DB パラメータグループを作成し、必要なパラメータを修正し、新しい DB パラメータグループを使用するため DB インスタンスを修正するだけで十分です。いったん関連付けが行われると、特定の DB パラメータグループを使用するすべての DB インスタンスは、その DB パラメータグループへのすべてのパラメータアップデートを取得します。 DB パラメータグループの設定の詳細については、Amazon RDS
ユーザーガイドを参照してください。 Amazon RDS リソースの設定をどのようにモニタリングできますか?マルチ AZ 配置DB インスタンスをマルチ AZ 配置として実行することにはどのような意味がありますか?マルチ AZ 配置として実行するように DB インスタンスを作成または修正すると、Amazon RDS では、同期 "スタンバイ" レプリカが別のアベイラビリティゾーンで自動的にプロビジョニングされ、管理されます。DB インスタンスに対する更新は、別のアベイラビリティゾーンにあるスタンバイに同時にレプリケートされるため、同期が維持されるとともに、最新のデータベース更新が DB インスタンスの障害から保護されます。 特定の種類の計画的なメンテナンスの期間中や、DB インスタンスの障害もしくはアベイラビリティーゾーンの障害といった予期せぬイベントが発生した際には、Amazon RDS はスタンバイに対して自動的にフェイルオーバーし、スタンバイが昇格したら直ちにデータベースの読み込みと書き込みを再開できるようにします。DB インスタンスの名前レコードは変化しないため、アプリケーションによるデータベースオペレーションは、管理者による手動での介入なしで再開できます。マルチ AZ 配置のレプリケーションは透過的です。スタンバイと直接やり取りすることはできません。また、スタンバイを読み取りトラフィックの処理に使用することはできません。マルチ AZ 配置の詳細については、Amazon RDS ユーザーガイドをご覧ください。 アベイラビリティゾーンとは何ですか?アベイラビリティゾーンとは、別のアベイラビリティゾーンで発生した障害から隔離するために作られたリージョン内の場所です。各アベイラビリティゾーンは、その独自の、物理的にはっきりと独立したインフラストラクチャ上で稼動しています。また高い信頼性を保つように設計されています。発電機や冷却装置などの障害対策用装置がアベイラビリティーゾーン間で共有されることはありません。さらに、これらは物理的にそれぞれ別々の場所にあるため、火災、竜巻、または洪水などの極めてまれな災害が発生しても、影響を受けるのは単一のアベイラビリティゾーンのみです。同一リージョンにあるアベイラビリティゾーンは、待ち時間が短いネットワーク接続を提供します。 マルチ AZ 配置のコンテキストにおいて「プライマリ」と「スタンバイ」は何を意味しますか?DB インスタンスをマルチ AZ 配置として実行する場合、"プライマリ" はデータベースに読み込みと書き込みの機能を提供します。さらに、Amazon RDS は、背後で「スタンバイ」を設定して管理します。これはプライマリの最新レプリカになります。スタンバイはフェイルオーバー時に（プライマリに）「昇格」します。フェイルオーバー後、スタンバイはプライマリとなり、お客様のデータベースオペレーションを受け付けるようになります。昇格前には、どの時点においても、スタンバイと直接やりとり (例: 読み込みオペレーション) することはありません。単一の DB
インスタンスの容量制限を超えて読み込みトラフィックをスケーリングする方法に関心のあるお客様は、リードレプリカのよくある質問をご覧ください。 マルチ AZ 配置の利点は何ですか?DB インスタンスをマルチ AZ 配置として実行することの主な利点は、データベースの耐久性と可用性を向上することです。マルチ AZ 配置によって高められる可用性と耐障害性は、本番環境に最適です。 DB インスタンスをマルチ AZ 配置として実行すると、万一 DB
インスタンスコンポーネントに障害が発生した場合や、特定のアベイラビリティゾーンで可用性が失われた場合でも、データの安全が守られます。例えば、プライマリ上のストレージボリュームが障害を受ける場合、Amazon RDS はスタンバイに対して自動的にフェイルオーバーを開始し、お客様のデータベース更新はそのスタンバイですべて完全な状態に保たれます。これは、単一のAZにおける標準配備と比較した場合、さらなるデータ堅牢性を提供するものです。単一の AZ における標準配備では、ユーザーによって開始される復元オペレーションが必要で、復元可能な最新時刻（一般的には過去５分以内）後に発生した更新は利用できません。 データベースの可用性を向上できることも、DB インスタンスをマルチ AZ 配置として運用する場合の利点の 1 つです。アベイラビリティーゾーンの障害または DB インスタンスの障害が発生した場合、可用性が影響を受けるのは、自動フェイルオーバーが完了するまでの間のみです。Multi-AZ の可用性に対する恩恵は、計画されたメンテナンスにも拡大されます。 DB インスタンスをマルチ AZ 配置として実行することによる暗黙の利点は他にもあります。それは、DB インスタンスのフェイルオーバーが自動で行われ、手動管理が必要ないことです。Amazon RDS のコンテキストでは、これはアベイラビリティゾーンや DB インスタンスの障害時に、(RestoreDBInstanceToPointInTime または RestoreDBInstanceFromSnapshot API を使用して) DB インスタンスのイベントをモニタリングし、手動で DB
インスタンスの復旧を開始する必要がないことを意味します。 DB インスタンスをマルチ AZ 配置として実行することにパフォーマンス上の意味がありますか?実行される同期的データレプリケーションの結果として、単一のアベイラビリティゾーンにおける標準 DB インスタンス配置と比較した場合、レイテンシーが増加する可能性があります。 DB インスタンスをマルチ AZ 配置として実行する場合、読み込みまたは書き込みオペレーションのためにスタンバイを使用できますか?いいえ。マルチ
AZ のスタンバイは、読み込みリクエストに対応していません。マルチ AZ 配置は、読み込み機能の拡張による恩恵よりも、データベースの可用性と堅牢性の強化を提供するよう設計されています。そのため、この機能はプライマリとスタンバイの間で同期するレプリケーションを行います。当社の実装では、プライマリとスタンバイが常に同期するようにしてありますが、スタンバイを読み込みまたは書き込みオペレーションのために使用する機能は除外しています。読み込みのスケーリングソリューションに関心のあるお客様は、リードレプリカのよくある質問をご覧ください。 マルチ AZ DB インスタンス配置のセットアップはどのように行うのですか?マルチ AZ DB インスタンス配置を作成するには、AWS マネジメントコンソールで DB インスタンスを起動する際に、[マルチ AZ 配置] で [はい] のオプションをクリックするだけです。 代わりに、Amazon RDS API を使用している場合は、CreateDBInstance API を呼び出して "マルチ AZ" のパラメータの値を "true" に設定することもできます。 既存の標準 (シングル AZ) DB インターフェイスをマルチ AZ に変換するには、AWS マネジメントコンソールで DB インスタンスを修正するか、ModifyDBInstance API を使用してマルチ AZ のパラメータを true に設定します。 Amazon RDS インスタンスをシングル AZ からマルチ AZ に変換するとどうなりますか?RDS for MySQL、MariaDB、PostgreSQL、および Oracle のデータベースエンジンについては、Amazon RDS インスタンスをシングル AZ からマルチ AZ に変換すると、次のようになります。
結果として、インスタンスが Single-AZ から Multi-AZ に変換される際には、ダウンタイムは発生しません。ただし、スタンバイのデータがプライマリと一致するように処理されている間は、レイテンシーが増加することがあります。 Amazon RDS によるスタンバイレプリカへのフェイルオーバーは、どのようなイベントのときに発生しますか?Amazon RDS では、マルチ AZ 配置における一般的な障害シナリオの検出とリカバリが自動的に行われるので、管理者の介入は不要でデータベース操作を可能な限りすみやかに再開できます。Amazon RDS
によって自動的にフェイルオーバーが実行されるのは、次のことが発生したときです。
注: DB インスタンスのスケーリングやシステムアップグレード (OS のパッチ適用など) のオペレーションがマルチ AZ 配置に対して行われるときは、可用性を高めるために、これらが最初にスタンバイに適用されて、その後で自動フェイルオーバーが実行されます。したがって、可用性への影響が現れるのは自動フェイルオーバーを完了するのに必要な時間までとなります。なお、Amazon RDS マルチ AZ 配置での自動フェイルオーバーは、データベース操作におけるエラー (長時間実行クエリ、デッドロック、データベース破損など) の発生に対しては行われません。 自動フェイルオーバーが発生する際警告は受けられますか?はい。Amazon RDS では DB インスタンスイベントが発行され、自動フェイルオーバーの発生が通知されます。Amazon RDS コンソールの [イベント] セクションをクリックするか、DescribeEvents API を使用して、DB インスタンスに関係のあるイベントについての情報を返すことも可能です。Amazon RDS Event Notifications を使って、特定の DB イベントが発生したときに、通知を受け取ることも可能です。 マルチ AZ のフェイルオーバー中どのようなことが起こるのですか? またこれはどれくらいの間継続するのですか?フェイルオーバーは Amazon RDS によって自動的に処理されるため、管理上の手動介入なく、可能な限り迅速にデータベースオペレーションを再開することができます。フェイルオーバーの際には、Amazon RDS は単純に DB インスタンスの Canonical Name Record (CNAME) を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。ベストプラクティスに従い、アプリケーションレイヤーでデータベース接続のリトライを実施することを推奨いたします。 フェイルオーバーは、プライマリで障害が検出されてからスタンバイでトランザクションが再開されるまでの間隔として定義され、通常 1 ～ 2 分以内に完了します。コミットされていない大きなトランザクションを回復させる必要があるかどうかによっても、フェイルオーバー時間は異なります。最適の結果を得るには、マルチ AZ では十分に大きなインスタンスタイプを使用することをお勧めします。また、高速かつ予測可能で、安定したスループットパフォーマンスを得るには、マルチ AZ インスタンスとともにプロビジョンド IOPS を使用することをお勧めします。 マルチ AZ DB インスタンス配備に対して「強制フェイルオーバー」を開始できますか?Amazon RDS は、さまざまな障害状態のときにユーザーが介入しなくても、自動的にフェイルオーバーを行います。さらに、Amazon RDS
ではインスタンスが再起動されたときにフェイルオーバーを開始することもできます。この機能にアクセスするには、AWS マネジメントコンソールを使用するか、RebootDBInstance API 呼び出しを使用してください。 マルチ AZ の同期レプリケーションはどのようにコントロール/設定するのですか?マルチ AZ 配置を使用する場合、[マルチ AZ] パラメータを真に設定するだけです。スタンバイ、同期的レプリケーションおよびフェイルオーバーの作成は、すべて自動的に処理されます。つまり、スタンバイが配置されているアベイラビリティーゾーンを選択したり、利用可能なスタンバイ数を変更したりすることはできません (Amazon RDS は、DB インスタンスプライマリごとに 1
つの専用スタンバイを設定します)。また、スタンバイは、データベースの読み取りアクティビティを許可するよう設定できません。マルチ AZ 配置の詳細についてはこちらをご覧ください。 私のスタンバイは私のプライマリと同一のリージョンになりますか?はい。スタンバイは、同一リージョンの異なるアベイラビリティゾーンにおいて、DB インスタンスプライマリとして自動的にプロビジョニングされます。 私のプライマリが現在所在する Availbility Zone を確認できますか?はい。AWS マネジメントコンソールまたは DescribeDBInstances API を使用することで、現在のプライマリロケーションを視認することができます。 フェイルオーバー後、プライマリは他の AWS リソース (例: EC2 インスタンス) と異なるアベイラビリティゾーンに所在するようになります。レイテンシーについて懸念すべきですか?アベイラビリティゾーンは、同一リージョンの別のアベイラビリティゾーンに対して短いレイテンシーでネットワーク接続できるように設計されています。さらに、1 つのアベイラビリティゾーンでサービスに障害が発生してもお客様のアプリケーションが柔軟性を保てるよう、複数のアベイラビリティゾーン全体で冗長性を持つようにアプリケーションや他の AWS リソースのアーキテクチャーを設計することも検討できます。マルチ AZ 配置は、お客様サイドでの管理作業なく、データベースに対するこのニーズを解決します。 DBスナップショットと自動バックアップは、私のマルチ AZ 配置とどのように連携するのですか?自動バックアップと DB
スナップショットの機能の扱い方は、シングル AZ での標準的なデプロイとマルチ AZ 配置のどちらで実行するかにかかわらず同一です。マルチ AZ 配置で実行している場合は、自動バックアップと DB スナップショットはスタンバイから取得されます。これは、プライマリでの I/O 中断を避けるためです。なお、シングル AZ とマルチ AZ のどちらの配置の場合も、バックアップ取得中は I/O レイテンシーが増加する可能性があることにご注意ください (一般的には数分で元に戻ります) 。 復元操作 (特定時点への復元または DB スナップショットからの復元) についても、シングル AZ 配置での機能は標準のマルチ AZ 配置の場合と同じです。新しい DB インスタンスの配置は、RestoreDBInstanceFromSnapshot または RestoreDBInstanceToPointInTime API のどちらかで作成できます。これらの新しい DB インスタンスの配置は、ソースバックアップが標準配置で開始されていようと、マルチ AZ
配置で開始されていようと、それとは無関係に標準またはマルチ AZ のどちらかに設定できます。 リードレプリカDB インスタンスをリードレプリカとして実行することにはどのような意味がありますか?リードレプリカは、サポートされるエンジンに組み込まれているレプリケーション機能を使って、単一の DB インスタンスの容量制限を弾性的に拡大してデータベースワークロードの読み込み負荷を緩和させることができます。 ユーザーは、AWS
マネジメントコンソールで数回クリックするか、CreateDBInstanceReadReplica API を使って、リードレプリカを作成できます。リードレプリカを作成すると、データベースは、サポートされるエンジンのネイティブ非同期レプリケーション機能を使ってソース DB インスタンスを更新します。1 つのソース DB インスタンスに対して複数のリードレプリカを作成して、アプリケーションの読み込みトラフィックをこれらのレプリカに分散させることができます。 リードレプリカは、サポートされるエンジンに組み込まれているレプリケーション機能を使用するため、その長所と制限が反映されます。特に、更新は、ソース DB インスタンスを更新した後にリードレプリカに反映されるため、レプリケーションが大幅に異なる場合があります。リードレプリカをマルチ
AZ 配置に関連付けることにより、マルチ AZ 配置が提供するデータベースの書き込み可用性と耐久性に加えて、読み込み性能をスケーリングすることができます。 Amazon RDS リードレプリカの使用はいつ考えるのが最適ですか?与えられた DB インスタンスで正しく機能するためにリードレプリカを配備する場所はさまざまです。リードレプリカをデプロイする一般的な理由は以下のとおりです。
リードレプリカを作成する前に、DB インスタンスで自動バックアップを有効にする必要がありますか?はい。リードレプリカを追加する前に、バックアップ保持期間を 0 以外の値に設定して、ソース DB インスタンスの自動バックアップを有効にします。リードレプリカを動作させるには、バックアップを有効にする必要があります。 Amazon RDS リードレプリカをサポートするのはデータベースエンジンのどのバージョンですか?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 設定でサポートされます。 どのように与えられた DB インスタンスにリードレプリカをデプロイしますか?標準の 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 インスタンスと接続するのと同じようにリードレプリカを接続します。リードレプリカが複数ある場合、読み込みトラフィックがどのように分配されるかはアプリケーションに依存します。 与えられたソース DB インスタンスに対していくつのリードレプリカが作成可能ですか?Amazon RDS for MySQL、MariaDB、PostgreSQL、Oracle、SQL Server では、特定のソース DB インスタンスに対して、最大 5 個のリードレプリカを作成できます。 ソース DB インスタンスとは異なる AWS リージョンにリードレプリカを作成できますか?はい。Amazon RDS (RDS for SQL Server 以外) はリージョンが異なるリードレプリカをサポートします。データがソース DB インスタンスに書き込まれてから、リードレプリカで使用可能になるまでの時間は、2 つのリージョン間のネットワークレイテンシーによって異なります。 Amazon RDS リードレプリカは同期レプリケーションをサポートしますか?いいえ。Amazon RDS for MySQL、MariaDB、PostgreSQL、Oracle、SQL Server のリードレプリカは、これらのエンジンのネイティブの非同期レプリケーションを使用して実装されています。Amazon Aurora は、別の (ただし非同期) のレプリケーションメカニズムを使用しています。 リードレプリカを使って障害が発生した場合のデータベースの書込み、または自分のソース DB インスタンスの保護を強化できますか?レプリケーションを使ってデータベースの書き込み性能を強化し、さまざまな障害条件に対してデータベースの最新状態を保護するためには、DB インスタンスをマルチ AZ 配置として実行することをお勧めします。サポートされるエンジンのネイティブな非同期レプリケーションを使用する Amazon RDS リードレプリカでは、データベースの書き込みがソース DB インスタンスで既に発生した後にリードレプリカで発生するため、このレプリケーションの「遅延」は状態に応じてかなり異なります。 その反面、Multi-AZ 配備が使うレプリケーションは同期しています。つまり、すべてのデータベース書込みはプライマリとスタンバイで同時に行われます。このように最新のデータベース更新を保護することで、イベントのフェイルオーバー発生時にスタンバイ状態にすることができます。 さらに、マルチ AZ 配置のレプリケーションは、完全に管理されています。Amazon RDS では DB
インスタンスの障害条件やアベイラビリティゾーンの障害が自動的に監視され、機能停止が発生すると、スタンバイ (Amazon Aurora の場合はリードレプリカ) への自動フェイルオーバーが開始されます。 リードインスタンスのソースとしてマルチ AZ DB インスタンス配備を持つリードレプリカを作成できますか?はい。マルチ AZ DB インスタンスはリードレプリカとは異なるニーズに対処するため、本番デプロイで双方を使用して、リードレプリカをマルチ AZ DB インスタンス配置に関連付けることは理にかなっています。「ソース」 Multi AZ-DB インスタンスは、書き込み可用性とデータの耐久性を強化し、関連するリードレプリカは、読み込みトラフィックのスケーラビリティを向上します。 Amazon RDS リードレプリカ自体をマルチ AZ にできますか?はい。Amazon RDS for MySQL、MariaDB、PostgreSQL および Oracle では、リードレプリカのマルチ AZ 設定を有効化することで、ディザスタリカバリのサポートとエンジンアップグレードによるダウンタイム最小化を実現できます。 自分のリードレプリカがマルチ AZ DB インスタンス配備をソースとして使用する際、マルチ AZ フェイルオーバーが発生した場合にどうなりますか?マルチ AZ
フェイルオーバーが発生した場合、関連するリードレプリカ、および利用可能なリードレプリカは、フェイルオーバーが完了すると、自動的にレプリケーションを再開します (新たに昇格したプライマリから更新を取得します)。 別のリードレプリカのリードレプリカを作成できますか?Amazon Aurora、Amazon RDS for MySQL、MariaDB: 既存の第 1 層リードレプリカから第 2 層リードレプリカを作成できます。第 2 層リードレプリカを作成すると、プライマリデータベースインスタンスからのレプリケーション負荷の一部を第 1 層リードレプリカに移動することができます。 ただし、トランザクションはプライマリから第 1 層レプリカにレプリケートされてから、第 2 層レプリカにレプリケートされ、レプリケーションのレイテンシーが増えるため、第 2 層リードレプリカはプライマリよりも遅延する可能性があります。 Amazon RDS for PostgreSQL、Oracle、SQL Server: 現在、リードレプリカのリードレプリカはサポートされていません。 リードレプリカはデータベースの読み込み操作のみを受け付けることができますか?リードレプリカは、読み込みトラフィックを誘導するためのものです。ただし、上級ユーザーがリードレプリカに対してデータ定義言語 (DDL) SQL 記述を完了する場合があります。例えば、同じインデックスに対応するソース DB インスタンスに追加せずに、ビジネスレポーティングに使用されるリードレプリカにデータベースインデックスを追加する場合などです。 Amazon RDS for MySQL は、リードレプリカに対する DDL SQL
ステートメントを許可するように設定できます。指定されたリードレプリカに対して読み込み以外のオペレーションを有効にする場合は、リードレプリカに対してアクティブ DB パラメータグループを変更し、「read_only」パラメータを「0」に設定します。 現在、Amazon RDS for PostgreSQL はリードレプリカに対する DDL SQL ステートメントの実行をサポートしていません。 リードレプリカを "スタンドアロン" 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 インスタンスのコンピューティングやストレージ容量をスケーリングしました。関連するリードレプリカのリソースもスケーリングする必要がありますか?レプリケーションが正しく機能するためには、リードレプリカに可能な限り多くの対応するソース DB インスタンスのコンピューティングとストレージリソースを確保してください。そうしないと、レプリケーションラグが増加する可能性が増える、またはリードレプリカがレプリケーションした更新を格納するスペースが足りなくなります。 リードレプリカはどのように削除しますか? ソース 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 インスタンスの時間料金で請求されます。 拡張モニタリングAmazon RDS の拡張モニタリングとは何ですか?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 ダッシュボードにはどのような情報が表示されますか?Amazon RDS
DB インスタンスのすべてのシステムメトリクスとプロセス情報を、コンソールのグラフィック形式で表示できます。各インスタンスについてモニタリングするメトリクスを管理し、必要に応じてダッシュボードをカスタマイズすることができます。 Amazon RDS アカウント内のすべてのインスタンスの詳細度が同じになるのですか?Amazon RDS アカウント内のそれぞれの DB インスタンスに、個別に詳細度を設定できます。どのインスタンスに対して拡張モニタリングを有効にするかも選択でき、必要なときにはいつでも各インスタンスに対する詳細度を変更できます。 Amazon RDS コンソールではメトリクスの履歴をどれほど前までさかのぼれますか?すべてのメトリクスのパフォーマンス値を最大 1 時間前まで参照できます。詳細度は設定に基づいて最大 1 秒間です。 Amazon RDS 拡張モニタリングで生成されたメトリクスを CloudWatch でどのように可視化できますか?Amazon RDS 拡張モニタリングからのメトリクスは、CloudWatch Logs アカウントに配信されます。CloudWatch 内で、CloudWatch Logs からメトリクスフィルターを作成し、CloudWatch
ダッシュボードに表示できます。詳細については、「Amazon CloudWatch」のページを参照してください。 Amazon RDS コンソールダッシュボードではなく CloudWatch を使用するのはどのようなケースですか?Amazon RDS コンソールダッシュボードで利用できる履歴データよりも前のデータが必要な場合、CloudWatch の使用が必要です。Amazon RDS インスタンスを CloudWatch でモニタリングすることで、AWS スタック全体の状況について 1 つの場所で診断できます。現在のところ、CloudWatch でサポートされている詳細度は最高 1
分間隔で、それよりも詳細度の短い場合は平均値になります。 特定のメトリクスに基づいてアラームと通知をセットアップすることはできますか?はい。アラームの状態が変化したときに通知を送信するアラームを CloudWatch に作成できます。アラームは、指定期間にわたって単一のメトリクスを監視し、その値と複数期間に対するしきい値との比較結果に基づいて 1 つ以上のアクションを実行します。CloudWatch アラームの詳細については、Amazon CloudWatch デベロッパーガイドをご覧ください。 現在使用中のツールに拡張モニタリングを統合するにはどのようにすればよいですか?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 に取り込まれるデータ量の概算を以下に示します。 Amazon RDS プロキシとは何ですか?Amazon RDS プロキシは、Amazon RDS 向けの完全マネージド型で可用性の高いデータベースプロキシ機能です。RDS プロキシで、アプリケーションの拡張性、データベース障害に対する耐障害性、安全性が向上します。 Amazon RDS プロキシを使用する理由は何ですか?Amazon RDS プロキシは、フルマネージド型で可用性が高く、使いやすい Amazon RDS 用データベースプロキシ機能です。この機能で、1) データベース接続をプールおよび共有することにより、アプリケーションのスケーラビリティが改善、2) データベースのフェイルオーバー時間が最大 66％ 短縮し、フェイルオーバー中のアプリケーション接続を維持することにより、アプリケーションの可用性が向上、3) オプションでデータベースへの AWS IAM 認証を実施し、AWS Secrets Manager に認証情報を安全に保存することにより、アプリケーションのセキュリティが強化します。 Amazon RDS プロキシはどのようなユースケースに対応していますか?Amazon RDS プロキシは、アプリケーションのスケーラビリティ、可用性、セキュリティに関連する次のような多くのユースケースに対応しています。 予測不可能なワークロードのあるアプリケーション: 極めて変動の激しいワークロードをサポートするアプリケーションでは、新しいデータベース接続のバーストを開こうとすることがあります。Amazon RDS
プロキシの接続ガバナンスにより、データベース接続を効率的に再利用して、予測不可能なワークロードを処理するアプリケーションを適切にスケーリングできます。第 1 に、RDS プロキシを使用すると、複数のアプリケーション接続がデータベース接続を共有でき、データベースリソースを効率的に使用できるようになります。第 2 に、RDS Proxy で、開くデータベース接続の数を調整して、予測可能なデータベースパフォーマンスを維持できるようになります。第 3 に、RDS Proxy は提供できない要求を削除し、アプリケーションの全体的なパフォーマンスと可用性を維持します。 データベース接続を頻繁に開閉するアプリケーション: サーバーレス、PHP、Ruby on Rails などのテクノロジーに基づいて構築したアプリケーションはデータベース接続を頻繁に開閉して、アプリケーションリクエストを処理する場合があります。Amazon RDS プロキシはデータベース接続のプールを維持し、データベースのコンピューティングとメモリに不要なストレスをかけず、新しい接続を確立します。 接続を開いたままでアイドル状態のアプリケーション: SaaS や e コマースなどの業界のアプリケーションは、データベース接続をアイドル状態に維持して、顧客が再エンゲージするときの応答時間を最小限に抑えます。データベースをオーバープロビジョニングしてほとんどのアイドル接続をサポートするのではなく、Amazon RDS プロキシを使用してアイドル接続を保持し、アクティブなリクエストを最適に処理するために必要なデータベース接続のみを確立します。 一時的な障害のために可用性を必要とするアプリケーション: Amazon RDS プロキシを使用すると、複雑な障害処理コードを記述することなく、データベース障害を透過的に許容できるアプリケーションを構築できます。RDS プロキシはアプリケーション接続を維持しながら、トラフィックを新しいデータベースインスタンスに自動的にルーティングします。Amazon RDS プロキシはドメインネームシステム (DNS) のキャッシュもバイパスして、RDS と Aurora のマルチ AZ データベースのフェールオーバー時間を最大 66％ 削減します。データベースのフェイルオーバー中には、アプリケーションのレイテンシーが増加し、進行中のトランザクションを再試行する必要がある場合があります。 セキュリティの向上と認証情報の集中管理: Amazon RDS プロキシは、リレーショナルデータベースで IAM ベースの認証を強制するという選択肢を提供しているため、より安全なアプリケーションを構築できます。RDS プロキシを使用すれば、AWS Secrets Manager を介してデータベースの認証情報を一元管理できます。 データベースには、Amazon RDS プロキシの使用ではなく直接接続をいつする必要がありますか?ワークロードに応じて、Amazon RDS プロキシはクエリまたはトランザクションの応答時間に平均 5 ミリ秒のネットワークレイテンシーを追加できます。アプリケーションが 5 ミリ秒のレイテンシーを許容できない場合、またはRDS プロキシによって有効になっている接続管理やその他の機能が必要ない場合、アプリケーションをデータベースエンドポイントに直接接続することが可能です。 サーバーレスアプリケーションが Amazon RDS プロキシから得られる利点は何ですか?Amazon RDS プロキシで、お客様のアプローチは全く新しくなり、リレーショナルデータベースのパワーとシンプルさを活用できる最新のサーバーレスアプリケーションを構築できるようになります。第 1 に、RDS プロキシでサーバーレスアプリケーションを効率的に拡張し、データベース接続をプールし再利用できるようになります。第 2 に、RDSプロキシを使用すると、Lambda コードでデータベースの認証情報を処理する必要がなくなります。Lambda 関数に関連付けられた IAM 実行ロールを使用して、RDS プロキシとデータベースで認証できます。第 3 に、新しいインフラストラクチャやコードを管理する必要なく、リレーショナルデータベースに支えられたサーバーレスアプリケーションの可能性を最大限に活用できます。RDS プロキシは完全マネージド型で、アプリケーションの要求に基づいて容量を自動的にスケーリングします。 Amazon RDS プロキシは、どのデータベースエンジンをサポートしていますか?Amazon RDS プロキシは、MySQL 互換の Amazon Aurora と Amazon RDS for MySQL でご利用いただけます。追加のデータベースエンジンのサポートは、まもなく開始されます。 Amazon RDS プロキシを有効にする方法を教えて下さい。Amazon RDS コンソールで数回クリックするだけで、Amazon RDS データベースの Amazon RDS プロキシを有効にできます。RDS プロキシを有効にして、RDS プロキシにアクセスする VPC とサブネットを指定します。Lambda ユーザーの場合、Amazon RDS データベースの Amazon RDS Proxy を有効にすれば、Lambda コンソールで数回クリックするだけで RDS Proxy にアクセスできるように Lambda 関数を設定できます。 API を使用して Amazon RDS Proxy にアクセスできますか?はい。Amazon RDS プロキシ API を使ってプロキシを作成し、ターゲットグループを定義して、プロキシを特定のデータベースインスタンスまたはクラスターに関連付けることができます。例: AWS support for Internet Explorer は 07/31/2022 に終了します。サポートされているブラウザは、Chrome、Firefox、Edge、Safari です。 詳細はこちら » Access Database Engineのサポート期限は？Accessのサポート終了期限一覧. Microsoft Access 2013のサポート期限は？Office 2013 のサポートは 2023 年 4 月 11 日に終了し、延長や拡張セキュリティ更新プログラムは提供されません。 すべての Office 2013 アプリは引き続き機能します。
Access Database Engine 2010のサポート期限は？Office2010に関係するデータファイルのダウンロード提供はサポート終了と共に終了しています。 2020 年 10 月 13 日以降のサポート終了に関して、以下をご確認ください。 今後 Microsoft は、Office 2010 のテクニカルサポート、バグ修正、セキュリティの修正プログラムを提供しません。
Access2000のサポート期限は？Access2000 のサポートは下記のサイトにありますように 2009 年 7 月 14 日終了しました。
|
Access DatabaseEngineのサポート期限は？
著作権 © 2024 wiewird Inc.
