Amazon RDS よくある質問

全般

すべて開く

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

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

開発者は、Amazon ウェブサービスでデータベースに関するいくつかの選択肢を利用できます。Amazon RDS は、データベース管理業務を外部委託しながら、完全に管理されたフル機能のリレーショナルデータベースを運用することを可能にします。当社が提供する多数のリレーショナルデータベース AMI のいずれかをAmazon EC2 で使用すると、クラウド上で独自のリレーショナルデータベースを管理することが可能です。これらの選択肢には重要な違いがあり、ユースケースによって適切な方が異なる場合があります。どのソリューションが最適かについてのガイダンスは、AWS によるクラウドデータベースを参照してください。

はい、Amazon RDS on Outposts を使用することで、Amazon RDS をオンプレミス環境で実行できます。詳細については、Amazon RDS on Outposts のよくある質問をご覧ください。

はい、Amazon RDS のスペシャリストが質問への回答やサポートを提供しています。お問い合わせください。1 営業日以内に弊社からご連絡し、AWS が貴社をどのように支援できるかについてご相談させていただきます。

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 データベースを数分以内に迅速かつシームレスに接続できます。

Amazon RDS コンソールから、AWS Lambda 関数と Amazon RDS または Amazon Aurora データベース間の接続を設定できます。RDS コンソールで、データベースリストページから RDS または Aurora データベースを選択し、[アクション] メニューから [Lambda 接続のセットアップ] を選択します。Amazon RDS では、関連するネットワーク設定が自動でセットアップされ、選択した Lambda 関数と RDS データベース間の安全な接続が実現します。

この接続セットアップ中は RDS プロキシの使用をお勧めします。この接続は、既存の RDS プロキシを使用するか、接続中に自動的に作成できる新しい RDS プロキシを使用してセットアップできます。この接続セットアップの自動化により、新規ユーザーやアプリケーションデベロッパーの生産性を向上させることができます。ユーザーは現在、サーバーレスアプリケーションまたは Lambda 関数と RDS または Aurora データベースを数分以内に迅速かつシームレスに接続できます。

データベースインスタンス

すべて開く

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 マネジメントコンソールの DB インスタンスの説明、DescribeDBInstances APIまたはdescribe-db-instances コマンドを通じてエンドポイントを取得できます。このエンドポイントを使用して、お好みのデータベースツールまたはプログラミング言語で DB インスタンスに直接接続するために必要な接続文字列を作成できます。実行中の DB インスタンスへのネットワークリクエストを許可するには、アクセスの承認が必要です。接続文字列の作成方法と初期設定の詳細な説明については、開始ガイドを参照してください。

デフォルトにより、お客様は合計 40 台までの Amazon RDS DB インスタンスを保有することができます。この 40 台のうち、「ライセンス込み」モデルでは、最大 10 個まで Oracle 用 RDS または SQL Server 用 RDS の DB インスタンスとすることができます。40台すべてが、Bring Your Own Licence（BYOL）モデルのもとで、Amazon Aurora、RDS for PostgreSQL、RDS for MySQL、RDS for MariaDB、およびRDS for Oracleに使用できます。SQL Server 用 RDS では、1 つの 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 ユーザーガイドをご参照ください。

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

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

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

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

データベースエンジンのバージョン

すべて開く

サポート対象のデータベースエンジンバージョンの一覧については、各エンジンのドキュメントを参照してください。

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

時間の経過とともに、Amazon RDS は新しいメジャーおよびマイナーなデータベースエンジンバージョンのサポートを追加しています。サポートされる新バージョンの数は、エンジンのベンダーまたは開発組織からのリリースやパッチの頻度・内容、および当社のデータベースエンジニアリングチームによるこれらリリース・パッチの徹底的な審査結果によって異なります。ただし、一般的なガイドラインとして、新しいエンジンバージョンが一般公開されてから 5 か月以内にサポートすることを目標としています。

AWS マネジメントコンソールの「DB インスタンスの起動」操作、または CreateDBInstance API を通じて新しい DB インスタンスを作成する際に、現在サポートされている任意のバージョン（メジャー・マイナーを含む）を指定できます。すべてのデータベースエンジンバージョンが、すべての AWS リージョンで利用可能とは限らないことに注意してください。

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

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

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

データベースインスタンスを手動でサポート対象のエンジンバージョンにアップグレードするには、AWS マネジメントコンソールの「DB インスタンスの変更」コマンド、または ModifyDBInstance API を使用し、「DB エンジンバージョン」パラメータを希望のバージョンに設定します。デフォルトではアップグレードが、次のメンテナンスウィンドウで適用されます。コンソール 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 ユーザーガイドを参照してください。

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

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

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

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

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

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

請求

すべて開く

はい、Amazon RDS の利用分に対して Database Savings Plans を購入することが可能です。1 年間で一定量の利用を約束することで、コストを最大 35% 削減できます。適格な利用内容に関する追加情報は、Database Savings Plans の価格ページで確認できます。

ご利用分のみお支払いいただき、最低利用料金や初期費用は一切かかりません。以下の内容に基づき、請求が行われます。

DB インスタンス時間 – 消費された DB インスタンスのクラス (例: db.t2.micro、db.m4.large など) に基づいています。 DB インスタンスの部分利用時間は 1 秒単位で課金されますが、DB インスタンスの作成、起動、クラス変更などの課金対象ステータス変更後は、最低 10 分間の料金が発生します。さらなる詳細は、新機能のお知らせをご覧ください。
ストレージ（月額 / GB 単位）：DB インスタンスにプロビジョニングしたストレージ容量。月内にプロビジョニングしたストレージ容量をスケーリングした場合、料金は日割り計算されます。
月額 I/O リクエスト– ストレージ I/O リクエストの総数 （Amazon RDS 磁気ストレージおよび Amazon Aurora のみ対象）
月額プロビジョニング IOPS：消費された IOPS に関わらず、プロビジョニングした IOPS レート （Amazon RDS プロビジョニング IOPS（SSD）ストレージのみ対象）
バックアップストレージ：自動データベースバックアップおよびユーザーが実行したデータベーススナップショットに関連するストレージです。バックアップ保持期間を延長したり、追加のデータベーススナップショットを取得したりすると、データベースのバックアップストレージ消費量が増加します。
データ転送 – DB インスタンスへのインターネット経由のデータ送受信量。

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

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

DB インスタンス時間は、DB インスタンスが利用可能な状態で実行されている 1 時間ごとに課金されます。DB インスタンスの課金を停止したい場合は、インスタンスを停止または削除する必要があり、そうすることで追加のインスタンス時間の課金を回避できます。 DB インスタンスの部分利用時間は 1 秒単位で課金されますが、DB インスタンスの作成、起動、クラス変更などの課金対象ステータス変更後は、最低 10 分間の料金が発生します。

DB インスタンスが停止している間は、プロビジョニングしたストレージ（プロビジョニング 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 コンソールおよびDescribeDBSnapshots API レスポンスには表示されませんのでご注意ください。

DB インスタンスにプロビジョニングされたプライマリデータ用のストレージは、単一のアベイラビリティーゾーン内に配置されています。データベースのバックアップ時には、バックアップデータ（トランザクションログを含む）が複数のアベイラビリティーゾーンにまたがって地理的冗長性を持つようにレプリケートされ、より高いレベルのデータ耐久性が実現されます。無料割り当て分を超えたバックアップストレージの価格は、重要なバックアップの耐久性を最大化するために行われるこの追加的なレプリケーションのコストを反映しています。

DB インスタンスを Multi-AZ デプロイメントとして指定した場合、Amazon RDS 料金ページに記載された Multi-AZ 料金設定に応じて料金が請求されます。Multi-AZ の料金は以下に基づきます。

Multi-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 のサービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細はこちら。

無料利用枠

すべて開く

Amazon RDS の AWS 無料利用枠では、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、または SQL Server Express Edition を実行する Micro インスタンスを最大 750 インスタンス時間まで利用できます。すべての Amazon RDS Single-AZ マイクロ DB インスタンス、対象のデータベースエンジン、リージョンを合わせて 750 インスタンス時間を超えて利用した場合、標準的な Amazon RDS の料金で課金されます。

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

リザーブドインスタンス

すべて開く

Amazon RDS リザーブドインスタンスでは、1 年または 3 年の期間で 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 つのアベイラビリティーゾーンでリソース容量に制限があったとしても、リージョン単位でリザーブドインスタンスを購入でき、その割引は当該リージョン内の任意のアベイラビリティーゾーンでの該当するインスタンス使用量に適用されることを意味します。

最大 40 個の予約済み DB インスタンスを購入できます。40 個を超える DB インスタンスを実行したい場合は、Amazon RDS DB インスタンスリクエストフォームを完了してください。

現在実行中で予約を希望する DB インスタンスと同じリージョン内で、同じ DB インスタンスクラス、DB エンジン、Multi-AZ オプション、ライセンスモデルを備えた DB インスタンス予約を購入するだけです。予約購入が成功した場合、Amazon RDS は既存の DB インスタンスに対して新しい時間単位の使用料を自動的に適用します。

予約インスタンスに関連する価格変更は、お支払い承認処理中にリクエストを受領した時点で有効になります。予約のステータスは、AWS アカウントアクティビティページから確認するか、DescribeReservedDBInstances API または describe-reserved-db-instances コマンドを使用して追跡できます。次回の請求期間までに一括支払いの承認が成功しなかった場合、割引は適用されません。

予約期間が満了すると、予約インスタンスは、該当する DB インスタンスクラスおよびリージョンにおけるオンデマンドの時間単位使用料率に戻ります。

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

各リザーブドインスタンスは特定のリージョンに関連付けられており、このリージョンは予約期間中は固定され、変更することはできません。ただし、各予約は、関連するリージョン内の利用可能な AZ のいずれでも使用できます。

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

DB インスタンスの予約は、DB インスタンスクラスとリージョンが同一である場合に限り、リードレプリカに適用できます。請求額の計算時、システムは自動的に予約を適用し、対象となるすべての DB インスタンスがより低い時間単位の予約インスタンス料金で課金されるようにします。

いいえ、予約済み DB インスタンスをキャンセルすることはできません。また、一括払い（該当する場合）は返金不可となります。予約済み DB インスタンスの契約期間中は、ご利用状況にかかわらず、すべての時間に対して引き続きお支払いいただきます。

オールアップフロント支払いオプションで RI を購入する場合、RI の全期間分の料金を一括前払いします。いっさい前払いなしにすることもでき、その場合は「前払いなし」を選択します。「前払いなし」の RI の価額総額が期間内の各時間に分配され、お客様へのご請求は使用の有無にかかわらず、期間内の 1 時間ごとに発生することになります。「一部前払い」は、「全前払い」と「前払いなし」の間をとったお支払い方法です。初期費用として少額の支払いをいただき、契約期間中はご利用状況に関わらず、1 時間ごとに低額の時間単価で請求されます。

ハードウェアとスケーリング

すべて開く

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

DB インスタンスに割り当てられたコンピューティングリソースとストレージ容量は、AWS マネジメントコンソール（目的の DB インスタンスを選択し「変更」ボタンをクリック）、Amazon RDS API、または AWS コマンドラインインターフェースを使用してスケーリングできます。DB インスタンスクラスを変更するとメモリと CPU リソースが変更され、ストレージ割り当てを変更すると利用可能なストレージが変更されます。

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 に設定します (推奨されません)。AWS 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 インスタンスが削除されるときに削除されます。DB インスタンスの削除後に保持されるのは、手動で作成された DB スナップショットのみです。

セキュリティ

すべて開く

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

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

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 名を使用することを強くお勧めします。

マルチ AZ 配置の場合、Region 内のすべての Availability Zone 用にサブネットを定義すると、必要に応じて Amazon RDS で別の Availability Zone に新しいスタンバイを作成できるようになります。Single-AZ 配置の場合も、どこかの時点でマルチ 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ドキュメント、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 配置

すべて開く

マルチ 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 に設定します。

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

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

結果として、インスタンスがシングル AZ からマルチ 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 リソースのアーキテクチャーを設計することも検討できます。マルチ 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 のユーザーガイド「リードレプリカの問題のトラブルシューティング」セクションを参照してください。

レプリケーションエラーが修正されると、レプリケーション状態はレプリケーション中に変わります。

レプリケーションが正しく機能するためには、リードレプリカに可能な限り多くの対応するソース 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 の主な利点には次が含まれます。

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

拡張モニタリングでは、特に 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 に取り込まれるデータ量の概算を以下に示します。

詳細度	60 秒	30 秒	15 秒	10 秒	5 秒	1 秒
CloudWatch Logs に取り込まれるデータ量* (GB/月)	0.27	0.53	1.07	1.61	3.21	16.07

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

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

Amazon RDS Proxy

すべて開く

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

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

Amazon RDS Proxy は、アプリケーションのスケーラビリティ、可用性、セキュリティに関連する次のような多くのユースケースに対応しています。

予測不可能なワークロードのあるアプリケーション: 極めて変動の激しいワークロードをサポートするアプリケーションでは、新しいデータベース接続のバーストを開こうとすることがあります。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 プロキシはクエリまたはトランザクションの応答時間に平均 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 for PostgreSQL

すべて開く

Trusted Language Extensions (TLE) for PostgreSQL により、開発者は高性能な PostgreSQL 拡張を構築し、Amazon Aurora および Amazon RDS 上で安全に実行することができます。これにより、TLE は市場投入までの時間を短縮し、データベース管理者が本番データベースワークロードで使用するためのカスタムコードやサードパーティーコードを認証する負担を軽減します。延長がニーズに合うと判断したら、すぐにでも進めることができます。TLE により、独立系ソフトウェアベンダー (ISV) では、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 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 ブルー/グリーンデプロイを使用して変更をロールバックすることはできません。

Amazon RDS Optimized Writes

すべて開く

MySQL は、メモリ内の 16KiB ページ単位でデータを 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 RDS for MySQL のすべてのユーザーは、書き込みトランザクションのスループットを最大 2 倍向上させる Amazon RDS Optimized Writes を実装すべきです。デジタル決済、金融取引、オンラインゲームアプリケーションなど、書き込みの多いワークロードを持つアプリケーションでは、この機能が特に有用です。

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

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

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

Amazon RDS Optimized Reads

すべて開く

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 Readss を使用する必要があります。これらのユースケースでは、一時テーブルが作成され、Optimized Reads によってワークロードのクエリ処理を高速化することが可能になります。

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

ゼロ ETL 統合

すべて開く

Amazon RDS のゼロ ETL 統合により、ペタバイト規模のトランザクションデータに対する分析および機械学習（ML）が可能となり、複雑なデータパイプラインの構築と管理が不要になります。データが Amazon RDS に書き込まれてから数秒以内に、Amazon Redshift または Amazon SageMaker のレイクハウスに複製できます。

Amazon RDS の複数のデータベースやテーブルからデータを統合し、Amazon Redshift または Amazon SageMaker のレイクハウスに集約できます。分析ニーズに基づき、特定のデータベースやテーブルのデータフィルタリングにより、対象データを選択的に抽出できます。

複雑なデータパイプラインの構築と管理の必要性を排除したい場合には、Amazon Redshift との Amazon RDS ゼロ ETL 統合を利用すべきです。データが Amazon SageMaker または Amazon Redshift のレイクハウスに格納されると、トランザクションデータに対して分析および機械学習（ML）機能を利用できるようになります。

Amazon RDS およびゼロ ETL 統合の一環として作成された変更データの作成と処理に使用されるゼロ ETL ターゲットリソースに対して料金が発生します。

これらのリソースには、Amazon Redshift データウェアハウスまたは Amazon SageMaker のレイクハウスへのシードおよび再同期にかかる Amazon RDS スナップショットエクスポート費用、ソースからターゲットへのデータ変更の継続的なレプリケーションにかかる変更データキャプチャ（CDC）データ転送費用、および変更データの処理に使用される通常の RDS I/O およびストレージが含まれます。

Amazon Redshift では、複製されたデータのストレージおよびコンピューティングコストも考慮する必要があります。SageMaker では、複製データの保存には AWS Glue ストレージを、ターゲット上での SageMaker コンピューティングを考慮する必要があります。詳細については、 Amazon RDS 料金表ページを参照してください。

はい、プライマリインスタンスのリソース消費を削減するには、Amazon RDS リードレプリカをゼロ ETL 統合のソース Amazon RDS インスタンスとして使用できます。

はい、Amazon RDS のゼロ ETL 統合に必要なリソースの設定とデプロイを管理および自動化するために、AWS CloudFormation を使用できます。詳細については、AWS CloudFormation ユーザーガイドにアクセスしてください。

Amazon RDS のゼロ ETL 統合は、トランザクションをアトミックに複製し、ソースとなるAmazon RDS データベースと、ターゲットとなる Amazon Redshift クラスターまたは Amazon SageMaker 内のレイクハウス間のデータ整合性を保証します。

この統合によるトランザクションのアトミック性に関する重要なポイントをいくつかご紹介します。

Amazon RDS でコミットされたトランザクションのみが Amazon Redshift または SageMaker のレイクハウスにレプリケートされ、コミットされていないトランザクションやロールバックされたトランザクションは適用されません。
この統合では、2 フェーズコミットプロセスを使用して、各トランザクションを Amazon Redshift または SageMaker のレイクハウスにアトミックに適用します。トランザクションのすべてのデータ変更が適用されるか、または何も適用されないか (エラーが発生した場合) のいずれかです。
ソースとターゲットの間でトランザクションの一貫性が維持されます。レプリケーション後、特定のトランザクションのデータは Amazon RDS とターゲットで一貫性が保たれます。
DDL または DML を通じたスキーマ変更も、完全性を維持するためにアトミックに適用されます。
トランザクションをアトミックに適用することで、データベース間で部分的なトランザクションが発生したり、一貫性のないデータ状態が発生したりすることがなくなります。

Amazon RDS のゼロ ETL 統合は、ソースとなる Amazon RDS データベースと、ターゲットとなる Amazon Redshift クラスターまたは Amazon SageMaker 内のレイクハウスとの間で完全なトランザクション整合性を維持します。

スキーマ変更の処理方法に関する重要なポイントをいくつかご紹介します。

CREATE TABLE、ALTER TABLE、DROP TABLE などの DDL ステートメントは、Amazon RDS から Amazon Redshift へ自動的にレプリケートされます。
統合により、レプリケートされたスキーマの変更について、Amazon Redshift テーブルで必要なチェックと調整が行われます。例えば、RDS for MySQL に列を追加すると、その列が Amazon Redshift にも追加されます。
レプリケーションとスキーマ同期は自動的に実行され、ソースデータベースとターゲットデータベース間の遅延は最小限に抑えられます。

DML の変更が DDL の変更と並行して発生しても、スキーマの一貫性は維持されます。

Amazon RDS よくある質問

ページトピック

全般

データベースインスタンス

データベースエンジンのバージョン

請求

無料利用枠

リザーブドインスタンス

ハードウェアとスケーリング

自動化バックアップとデータベーススナップショット

セキュリティ

データベース設定

マルチ AZ 配置

リードレプリカ

モニタリングとメトリクス

Amazon RDS Proxy

Trusted Language Extensions for PostgreSQL

Amazon RDS ブルー/グリーンデプロイ

Amazon RDS Optimized Writes

Amazon RDS Optimized Reads

ゼロ ETL 統合

学ぶ

リソース

デベロッパー

ヘルプ

Amazon RDS よくある質問

ページトピック

全般

Amazon RDS とは何ですか?

Amazon RDS とはどのような場合に使用すべきですかAmazon EC2 のリレーショナルデータベース AMI とはどのような場合に使い分けるべきですか？

Amazon RDS にハイブリッドまたはオンプレミスのデプロイオプションはありますか？

Amazon RDS の詳細を学び、導入するためのサポートは受けられますか？

Amazon EC2 コンピューティングインスタンス上で実行されているアプリケーションまたはSQLベースのクライアントと、Amazon RDS データベースインスタンス/クラスターとの接続を設定するにはどうすればよいですか？

サーバーレスの Lambda アプリケーションと Amazon RDS または Amazon Aurora データベースインスタンスおよび/またはクラスター間の接続を設定するにはどうすればよいですか？

データベースインスタンス

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

DB インスタンスをどのように作成しますか?

実行中の DB インスタンスにどのようにアクセスしますか?

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

1 つの DB インスタンス内で、いくつのデータベースまたはスキーマを実行できますか？

Amazon RDS DBインスタンスにデータをインポートするにはどうすればよいですか？

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

クエリの実行が遅いように感じられる場合、どうすればよいですか？

データベースエンジンのバージョン

Amazon RDS はどのリレーショナルデータベースエンジンのバージョンをサポートしていますか？

Amazon RDS は、DB エンジンの「メジャー」バージョンと「マイナー」バージョンをどのように区別していますか？

Amazon RDS は新しい DB エンジンバージョンのサポートに関するガイドラインを提供していますか？

DB インスタンスで実行したいサポート対象の DB エンジンバージョンを指定するにはどうすればよいですか？

DB インスタンスのエンジンバージョンが新しいサポート対象バージョンにアップグレードされるかどうか、およびそのタイミングを制御するにはどうすればよいですか？

アップグレード前に、新しいバージョンで DB インスタンスをテストすることはできますか？

Amazon RDS は、現在サポートされているデータベースエンジンバージョンの廃止に関するガイドラインを提供していますか？

Amazon RDS の DB エンジンバージョンが廃止（非推奨）になった場合はどうなりますか？

特定のバージョンを作成できないのはなぜですか?

請求

Amazon RDS は Database Savings Plans でサポートされていますか？

Amazon RDS の利用料金はどのように課金・請求されますか？

Amazon RDS DBインスタンスの請求はいつ開始され、いつ終了しますか？

Amazon RDS の課金対象となるインスタンス時間とは何を指しますか？

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

バックアップストレージはどのように請求されますか?

追加のバックアップストレージのコストが、割り当てられた DB インスタンスストレージより高いのはなぜですか？

Multi-AZ DB インスタンスのデプロイメントの課金はどのように請求されるのですか?

価格には税金が含まれていますか?

無料利用枠

Amazon RDS の AWS 無料利用枠では何が提供されますか？

Amazon RDS の AWS 無料利用枠はどの期間利用できますか？

Amazon RDS の AWS 無料利用枠で、複数の DB インスタンスを実行できますか？

AWS 無料利用枠では、MySQL、MariaDB、PostgreSQL、SQL Server Micro DB の各インスタンスについて、それぞれ 750 インスタンス時間を利用できますか？

インスタンス時間の使用量が無料利用枠を超過した場合、どのように課金されますか？

リザーブドインスタンス

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

予約インスタンスとオンデマンド DB インスタンスの違いは何ですか？

予約インスタンスを購入および作成するにはどうすればよいですか？

予約インスタンスにはキャパシティ予約が含まれますか？

予約インスタンスはいくつ購入できますか？

既存の DB インスタンスをリザーブドインスタンスでカバーしたい場合、どうすればよいですか？

予約インスタンスに申し込んだ場合、契約期間はいつから始まりますか？ DB インスタンスの使用期限が過ぎるとどうなりますか?

どの DB インスタンスが予約インスタンス料金で課金されるかを制御するにはどうすればよいですか？

DB インスタンスクラスをスケールアップまたはスケールダウンした場合、リザーブドインスタンスはどうなりますか？

予約インスタンスをあるリージョンまたはアベイラビリティゾーンから別のリージョンまたはアベイラビリティゾーンに移動できますか？

マルチ AZ 配置でリザーブドインスタンスは利用可能ですか？

リザーブド インスタンスは、リードレプリカでも利用可能ですか?

予約をキャンセルできますか？

お支払い方法が請求書にどのような影響を与えますか？

ハードウェアとスケーリング

初期の DB インスタンスクラスとストレージ容量を、自分のニーズに合ったものにするにはどう判断すればよいですか？

Amazon RDS データベースインスタンスに関連付けられているコンピューティングリソースおよび/またはストレージ容量をどのように拡張すればよいですか？

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

私の DB インスタンスは拡張中も利用可能ですか?

最大 DB インスタンス クラスおよび最大ストレージ容量を超えて、DB インスタンスをどのように拡張できますか?

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

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

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

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

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

自動化バックアップとデータベーススナップショット

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

私の DB インスタンスのバックアップを有効にする必要がありますか、またはそれは自動的に行われますか?

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

自動バックアップと DB スナップショットはどこに保存され、それらの保持期間をどのように管理しますか？

自動化された DB スナップショットの数が、DB インスタンスに対するリテンション期間の日数よりも多いのはなぜですか?

DB インスタンスを削除した場合、バックアップと DB スナップショットに何が起きますか?

セキュリティ

仮想プライベートクラウド (VPC) とは何ですか? どのように Amazon RDS と連携しますか?

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