Amazon Aurora のよくある質問

現在の料金情報については、Aurora 料金ページを参照してください。

現時点では、Aurora 向けの AWS 無料利用枠はありません。ただし、Auroraはデータを1つのリージョンの3つのアベイラビリティーゾーンに永続的に保存し、1つのデータコピーに対してのみ料金を請求します。データベースクラスターのサイズの最大 100% のバックアップには料金はかかりません。また、データベースクラスターに設定したバックアップ保持期間中のスナップショットにも課金されません。

いいえ。Aurora のレプリケーションは料金に含まれています。料金はデータベースがデータベースレイヤーで消費したストレージに応じて発生します。Aurora の仮想化ストレージレイヤーで消費したストレージではありません。

I/O オペレーションは、Aurora データベースエンジンによって SSD ベースの仮想ストレージレイヤーに対して実行されます。各データベースページの読み取りオペレーションは 1 I/O とカウントされます。
Aurora データベースエンジンは、ストレージレイヤーに対して読み取りを発行し、キャッシュ内のメモリに存在しないデータベースページを取得します。

• クエリトラフィックをメモリまたはキャッシュから完全に提供できる場合、メモリからデータページを取得するための料金は発生しません。
• クエリトラフィックをメモリから完全に提供できない場合は、ストレージから取得する必要のあるデータページについて課金されます。
  各データベースページについては、Amazon Aurora MySQL 互換エディションでは 16 KB、Aurora PostgreSQL 互換エディションでは 8 KB です。

Aurora はコストを削減し、リソースが読み取り/書き込みトラフィックを提供するために利用可能になるように不要な I/O オペレーションを削除するよう設計されていました。書き込み I/O オペレーションは、書き込みに耐久性を持たせる目的で、Aurora MySQL 互換エディションの redo ログレコードまたは Aurora PostgreSQL 互換エディションのログ先行書き込みレコードをストレージレイヤーに保持する場合にのみ消費されます。

書き込み I/O オペレーションは 4 KB 単位でカウントされます。例えば、ログレコードが 1,024 バイトの場合、1 書き込み I/O オペレーションとカウントされます。ただし、ログレコードが 4KB を超える場合は、ログレコードを保持するために複数の書き込み I/O オペレーションが必要になります。

同時書き込みオペレーションでログレコードが 4 KB 未満の場合、I/O 消費を最適化するため Aurora データベースエンジンによってまとめてバッチ処理されます。従来のデータベースエンジンとは異なり、Aurora はダーティデータページをストレージにフラッシュすることはありません。

AWS マネジメントコンソールで Aurora インスタンスがどれほど I/O リクエストを消費しているか確認できます。I/O 消費を確認するには、Amazon RDS セクションのコンソールでインスタンスのリストから Aurora インスタンスを選び、モニタリングセクションの「VolumeReadIOPs」と「VolumeWriteIOPs」メトリクスを確認します。

I/O オペレーションの料金の詳細については、「Aurora の料金ページ」をご覧ください。データベースクラスターを Aurora Standard 設定にすると、読み取りと書き込み I/O オペレーションに対して課金されます。データベースクラスターを Amazon Aurora I/O 最適化に設定すると、読み取りと書き込み I/O オペレーションの料金は発生しません。

Aurora では、料金パフォーマンスと料金予測可能性のニーズに基づいて 2 つの設定オプションから選択することで、データベース支出を柔軟に最適化できます。2 つの設定オプションには、Aurora Standard と Aurora I/O 最適化があります。どちらのオプションも、I/O やストレージのプロビジョニングを前もって行う必要はなく、I/O オペレーションをスケールして最も要求の厳しいアプリケーションをサポートすることが可能です。

Aurora Standard は、I/O 使用量が少ないか中程度のアプリケーションの大部分に対して費用対効果の高い料金設定を提供するデータベースクラスター設定です。Aurora Standard では、データベースインスタンス、ストレージ、リクエスト I/O ごとの料金を支払います。

Aurora I/O 最適化は、支払い処理システム、e コマースシステム、金融アプリケーションなどの I/O 集約型アプリケーションの料金パフォーマンスを向上させるデータベースクラスター設定です。I/O 支出が Aurora データベースの総支出の 25% を超える場合、Aurora I/O 最適化を使用すると、I/O 集約型のワークロードのコストを最大 40% 節約できます。Aurora I/O 最適化では、読み取りと書き込み I/O オペレーションに料金がかからないため、すべてのアプリケーションについて予測可能な料金設定ができ、I/O の変動制が大きいワークロードに最適です。

Aurora I/O 最適化は、あらゆるアプリケーションで予測可能なコストが必要な場合に最適な選択肢です。書き込み高スループットを必要とする場合や、大量のデータを処理する分析クエリを実行する I/O 集約型のアプリケーションでは、料金パフォーマンスが向上します。I/O 支出が Aurora 請求額の 25% を超えるお客様の場合、Aurora I/O 最適化を使用すると、I/O 集約型のワークロードのコストを最大 40% 節約できます。

AWS マネジメントコンソールで利用できるワンクリックエクスペリエンスを使用して、既存のデータベースクラスターのストレージタイプを Aurora I/O 最適化に変更できます。AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を呼び出してこの変更を行うこともできます。

30 日に 1 回、既存のデータベースクラスターを Aurora I/O 最適化に切り替えることができます。いつでも Aurora Standard に戻すことができます。

はい。Aurora I/O 最適化は既存の Aurora リザーブドインスタンスでも動作します。Aurora は Aurora Standard と Aurora I/O 最適化リザーブドインスタンスとの料金の差を自動的に計算します。Aurora I/O 最適化によるリザーブドインスタンスの割引を利用すると、I/O 支出をさらに節約できます。

Aurora I/O Optimized によるバックトラック、スナップショット、エクスポート、継続的バックアップの料金に変更はありません。

はい。リージョン間でデータをリプリケーションするために必要な I/O オペレーションの料金は引き続き適用されます。Aurora I/O 最適化は、データリプリケーションとは異なり、読み取りと書き込み I/O オペレーションには課金しません。

Amazon Aurora Optimized Reads for Aurora PostgreSQL では、インテルベースの R6id および Graviton ベースの R6gd インスタンスの料金以外に追加料金は発生しません。詳細については、Aurora の料金ページにアクセスしてください。

ストレージの下限は 10 GB です。データベースの使用量に応じて、Amazon Aurora ストレージは 10 GB 単位で最大 128 TiB まで、データベースのパフォーマンスに影響を与えずに拡張されます。ストレージを事前にプロビジョニングする必要はありません。

Amazon Aurora DB インスタンスに関連するコンピューティングリソースをスケールするには、Aurora Serverless を使用する方法と手動調整の 2 つの方法があります。

Amazon Aurora のオンデマンドの自動スケーリング構成である Aurora Serverless を使用して、アプリケーションのニーズに基づいてデータベースコンピューティングリソースをスケーリングできます。データベース容量の管理を心配することなく、クラウド内でデータベースを実行できます。必要なデータベース容量の範囲を指定でき、データベースはアプリケーションのニーズに基づいてスケールされます。詳細については、Aurora Serverless ユーザーガイドをお読みください。

また、AWS マネジメントコンソールで目的の DB インスタンスタイプを選択することにより、データベースに関連付けられているコンピューティングリソースを手動でスケールすることもできます。要求された変更は、指定されたメンテナンスウィンドウ中に適用されます。あるいは、[すぐに適用] フラグを使用すると、DB インスタンスタイプをすぐに変更できます。

これらのオプションはいずれも、スケーリング操作が実行されている数分間の可用性に影響を与えます。保留中の他のシステム変更も適用されることにご注意ください。

Amazon Aurora DB インスタンスでは常に自動継続バックアップが有効です。バックアップはデータベースのパフォーマンスに影響を与えません。

はい。また、スナップショットを作成する際にパフォーマンスに影響はありません。DB スナップショットからデータを復元する場合は新しく DB インスタンスを作成する必要があることに注意してください。

Amazon Auroraは、リージョンの3つのAvailability Zone (AZ) (アベイラビリティーゾーン (AZ))にわたってデータを自動的に永続化し、データが失われることのない正常なAZでデータベースの復元を自動的に試みます。Amazon Aurora ストレージでデータが利用不可になるという稀なケースでは、DB スナップショットから復元するか、新しいインスタンスに任意の時点を指定した復元を実行できます。ポイントインタイムの復元オペレーションを実行する場合、最新の復元可能時間は直近で 5 分前までです。

DB インスタンスを削除する際に、最後の DB スナップショットを作成することができます。DB スナップショットを作成した場合、後日そのスナップショットを使用して、削除した DB インスタンスを復元することができます。Amazon Aurora は、DB インスタンスが削除された後も、このユーザーが作成した最終的な DB スナップショットと手動で作成されたその他の DB スナップショットをすべて保持します。DB インスタンスが削除された後は DB スナップショットのみが保持されます (つまり、ポイントインタイムの復元のために作成された自動バックアップは保持されません)。

はい。Aurora では、データベースのスナップショットを作成できます。これを使用して、後でデータベースを復元できます。スナップショットは別の AWS アカウントと共有でき、受取人アカウントの所有者は、そのスナップショットを使用して、お客様のデータを含む DB を復元できます。スナップショットを公開して、誰でもお客様の公開データを含む DB を復元できるように選択することもできます。

この機能を使用して、異なる AWS アカウントを持つさまざまな環境 (本番、開発/テスト、ステージングなど) でデータを共有できます。また、メインの AWS アカウントが侵害された場合でも、すべてのデータのバックアップを別個のアカウントで安全に保持できます。

アカウント間のスナップショットの共有に対して課金されることはありません。しかし、スナップショット自体、および共有スナップショットから復元するデータベースに対して課金される場合があります。詳細については、Aurora の料金を参照してください。

DB スナップショットの自動共有はサポートされていません。スナップショットを共有するには、手動でスナップショットのコピーを作成してから、コピーを共有する必要があります。

手動のスナップショットを、最大 20 個の AWS アカウント ID と共有できます。20 個を超えるアカウントと共有したい場合は、スナップショットを公開するか、クォータを引き上げるためにサポートにご連絡ください。

Aurora スナップショットは、Aurora が利用可能な AWS リージョン内で共有できます。

いいえ。共有された Aurora スナップショットは、それを共有したアカウントと同じリージョン内のアカウントからのみアクセスできます。

はい。暗号化された Aurora スナップショットは共有可能です。

Amazon Aurora はデータベースボリュームを自動で 10 GB のセグメントに分割し、多数のディスクに分散します。10 GB 単位の各データベースボリュームが、3 つのアベイラビリティーゾーンにわたって 6 つの方法でレプリケートされます。Amazon Aurora は最大 2 つまでのデータのコピー損失をデータベースの書き込み能力に影響せずに透過的に処理し、最大 3 つまでのコピー損失を読み込み能力に影響せずに処理します。

また、Amazon Aurora ストレージは自己修復機能を備えています。データブロックおよびディスクはエラー検出のために継続的にスキャンされ、自動的に修復されます。

他のデータベースと違い、データベースクラッシュ後、Amazon Aurora はデータベースを利用できるようにする前に最後のデータベースチェックポイント (通常 5 分前) から REDO ログをリプレイし、すべての変更が適用されたか確認する必要はありません。これにより、多くの場合データベースの再起動時間を 60 秒以内に短縮します。

また Amazon Aurora はバッファキャッシュをデータベース処理から除外し、再起動時にすぐ利用できるようにします。そのため、ブラウンアウトを避けるためにキャッシュが再生成されるまでアクセスを調整する必要がなくなります。

Amazon Aurora MySQL 互換エディションと Amazon Aurora PostgreSQL 互換エディションは、同じAWS リージョン内のプライマリインスタンスと同じ基盤ボリュームを共有する Amazon Aurora レプリカをサポートしています。プライマリにより実行された更新は、すべての Amazon Aurora レプリカで確認できます。

Amazon Aurora MySQL 互換エディションを使用すると、MySQL の binlog ベースのレプリケーションエンジンに基づいてクロスリージョン MySQL リードレプリカを作成することもできます。MySQL リードレプリカでは、プライマリインスタンスのデータはトランザクションとしてレプリカでリプレイされます。読み込みのスケーリングおよび高可用性など、ほとんどの使用目的では Amazon Aurora レプリカを使用することをお勧めします。

アプリケーションのニーズに応じてこれら 2 つのレプリケーションタイプを柔軟に組み合わせることができます。

上記のものに加えて、さらに 2 つのレプリケーションオプションがあります。Amazon Global Database を使用すると、異なるリージョンの Aurora クラスター間での物理レプリケーションを大幅に高速化できます。さらに、Aurora と非 Aurora MySQL 互換エディションデータベース (AWS 外であっても) 間のレプリケーションでは、セルフマネージドの、独自の binlog レプリケーションを設定できます。

はい。物理または論理のいずれかのレプリケーションを使用して、クロスリージョンの Aurora レプリカを設定できます。物理レプリケーション (Amazon Aurora Global Database) は、アプリケーションにサービスを提供するためにお使いのデータベースを全面的に利用可能とする専用のインフラストラクチャであり、1 秒未満という一般的なレイテンシーを特徴とする最大 5 つのセカンダリリージョンにレプリケートできます。Aurora MySQL 互換エディションと Aurora PostgreSQL 互換エディションの両方で使用できます。

低レイテンシーのグローバルな読み取りと災害復旧を実現するために、Amazon Aurora Global Database の使用をお勧めします。
Aurora は、各データベースエンジン (MySQL の場合はバイナリログ、PostgreSQL の場合は PostgreSQL レプリケーションスロット) でネイティブの論理レプリケーションをサポートしているため、リージョン間でも Aurora データベースと非 Aurora データベースにレプリケートできます。

Aurora MySQL 互換エディションは、最大 5 つのセカンダリ AWS リージョンをサポートする、使いやすい論理クロスリージョンリードレプリカ機能も提供しています。シングルスレッドの MySQL binlog レプリケーションに基づいています。レプリケーションラグは変更率または適用率、および選択された特定のリージョン間のネットワーク通信の遅延による影響を受けます。

はい。最大 15 個の Aurora レプリカを各クロスリージョンクラスターに追加できます。これにより、クラスター間で、クロスリージョンレプリカと同じ基盤となるストレージが共有されます。クロスリージョンレプリカはクラスターでプライマリとして機能し、クラスターの Aurora レプリカではプライマリよりも通常は数十ミリ秒の遅延が発生します。

はい。Amazon RDS コンソールから、クロスリージョンレプリカを新しいプライマリに昇格させられます。論理 (binlog) レプリケーションの場合、ワークロードによって異なりますが、昇格プロセスには一般に数分かかります。昇格プロセスを開始すると、クロスリージョンレプリケーションは停止します。

Amazon Aurora Global Database を使用すれば、セカンダリリージョンを昇格させて 1 分以内にすべての読み取り/書き込みワークロードを取得できます。

はい。クラスターの各インスタンスに昇格優先階層を割り当てることができます。プライマリインスタンスが失敗した場合、Amazon RDS は最も高い優先度のレプリカをプライマリに昇格します。複数の Aurora レプリカで同じ優先度を共有する場合、Amazon RDS は最大サイズのレプリカを昇格します。複数の Aurora レプリカで同じ優先度とサイズを共有する場合、Amazon RDS は同じ昇格階層の任意のレプリカを昇格します。

フェイルオーバーロジックの詳細については、Amazon Aurora ユーザーガイドをお読みください。

はい。インスタンスへの優先階層はいつでも変更できます。優先階層を変更するだけでは、フェイルオーバーはトリガーされません。

プライマリインスタンスに昇格させたくないレプリカを低い優先階層に割り当てることができます。しかし、クラスターの高い優先度のレプリカが正常でない、または何らかの理由により利用できない場合、Amazon RDS は低い優先階層のレプリカを昇格します。

Amazon Aurora レプリカを追加できます。同じ AWS リージョン内の Aurora レプリカ間で、プライマリインスタンスと同じ基盤となるストレージを共有します。任意の Aurora レプリカをデータを損失することなくプライマリに昇格できるため、プライマリ DB インスタンスに障害が発生した際の耐障害性を向上するために使用できます。

データベースの可用性を高めるためには、3 つのアベイラビリティーゾーンに任意に 1 から 15 個のレプリカを作成するだけで、Amazon RDS が自動でデータベースの機能停止時のフェイルオーバープライマリ対象としてそれらのレプリカを認識します。Amazon Aurora Global Database は、お使いのデータベースを複数の AWS リージョンで利用する場合に使用できます。これにより、データベースのパフォーマンスに影響を及ぼさずにデータがレプリケートされ、リージョン全体の停止からのディザスタリカバリが可能になります。

フェイルオーバーは Amazon Aurora によって自動的に処理されるため、アプリケーションは管理上の手動介入なしで、可能な限り迅速にデータベースオペレーションを再開することができます。

• 同一、または異なるアベイラビリティーゾーンに Aurora レプリカを作成している場合、障害が発生すると、Aurora は DB インスタンスの Canonical Name Record (CNAME) を反転させ、正常なレプリカを指定します。指定されたレプリカは新しいプライマリに昇格します。フェイルオーバーは開始から終了まで通常 30 秒以内に完了します。回復性を高め、フェイルオーバーを高速化するには、アプリケーション接続を維持したままフェイルオーバー DB インスタンスに自動的に接続する Amazon RDS Proxy の使用を検討してください。プロキシはフェイルオーバーをアプリケーションに透過的に表示し、フェイルオーバー時間を最大 66% 短縮します。
• DB インスタンスまたは AZ が使用不能になった時でも、Aurora Serverless v1 を実行していれば、別の AZ 内に Aurora が DB インスタンスを自動的に再作成します。Aurora Serverless v2 は、フェイルオーバーや他の高可用性機能のためにプロビジョニングされたように機能します。詳細については、「Aurora Serverless v2 と高可用性」を参照してください。 
• Aurora レプリカを作成しておらず(つまり、インスタンスは 1 つ)、Aurora Serverless を使用していない場合、Aurora は元のインスタンスと同じアベイラビリティーゾーンに新しい DB インスタンスの作成を試みます。オリジナルのインスタンスの置換処理はベストエフォート型であり、アベイラビリティーゾーンで広範囲に影響を及ぼす問題がある時などは失敗する可能性があります。
  

接続が切断された場合、アプリケーションではデータベースへの接続を再試行する必要があります。リージョンをまたがるディザスタリカバリは手動プロセスであり、ここで、読み取り/書き込みワークロードを取得できるようにセカンダリリージョンを昇格させます。

プライマリインスタンスでの問題は Amazon Aurora により自動検出され、フェイルオーバーがトリガーされます。クラスターエンドポイントを使っていれば、読み取りもしくは書き込みのための接続は Amazon Aurora レプリカに自動でリダイレクトされ、レプリカはプライマリに昇格します。

さらに、Aurora レプリカが処理していた読み取りトラフィックは一時的に中断されます。クラスターリーダーエンドポイントを使って読み取りトラフィックを Aurora レプリカに送っている場合は、古いプライマリノードがレプリカとして復旧するまでの間、新たにプライマリに昇格した Aurora レプリカに対し読み取り専用接続が行われます。

Amazon Aurora レプリカは、同じ AWS リージョン内のプライマリインスタンスと同じデータボリュームを共有しているため、実質的にレプリケーションラグはありません。通常、ラグは数十ミリ秒です。

クロスリージョンレプリケーションの場合、binlog ベースの論理レプリケーションラグは変更率または適用率、およびネットワーク通信の遅延に応じて無制限に増大する可能性があります。ただし、通常の状況では 1 分未満のレプリケーションラグが一般的です。Amazon Aurora Global Database の物理レプリケーションを使用するクロスリージョンレプリカには、1 秒未満という標準的なラグが生じます。

はい。Aurora MySQL 互換エディションインスタンスと外部の MySQL データベースの間で binlog レプリケーションを設定できます。もう一方のデータベースは、Amazon RDS 上で、AWS 上でセルフマネージド型データベースとして、または完全に AWS の外部で実行できます。

Aurora MySQL 互換エディション 5.7 を実行している場合、GTID ベースの binlog レプリケーションをお勧めしています。これにより完全な一貫性が提供され、フェイルオーバーやダウンタイムの後でも、複製でトランザクションが失われたり、競合が発生することがありません。

Amazon Aurora Global Database は、単一の Amazon Aurora データベースを複数の AWS リージョンにまたがって運用可能にする機能です。データベースのパフォーマンスに影響を与えずにデータをレプリケートし、1 秒未満という標準的なレイテンシーで各リージョンでのローカル読み取りを高速化し、リージョン規模の停止からの災害復旧を実現します。万一、リージョンの規模縮小や障害が発生した場合でも、セカンダリリージョンを、完全な読み取り/書き込み機能に 1 分以内で昇格させることができます。この機能は、Aurora MySQL 互換エディションと Aurora PostgreSQL 互換エディションの両方で使用できます。

Amazon RDS コンソールでのわずか数回のクリックにより、Aurora Global Database を作成できます。または、AWS Software Development Kit (SDK) または AWS Command-Line Interface (CLI) を使用することもできます。Amazon Aurora Global Database 内のリージョンにつき、少なくとも 1 つのインスタンスをプロビジョニングする必要があります。

Amazon Aurora Global Database には、最大 5 つのセカンダリリージョンを作成できます。

はい。データベースのアクティビティを分析することが目的である場合は、データベースのパフォーマンスへの影響を避けるために、代わりに Aurora の高度な監査、全般ログ、スロークエリログの使用を検討してください。

いいえ。プライマリリージョンが利用不可になる場合は、Amazon Aurora Global Database からセカンダリリージョンを手動で取り除き、完全な読み取り/書き込みを取得できるように昇格させることができます。新たに昇格させたリージョンへのアプリケーションの指定も必要になります。

Aurora PostgreSQL で利用可能な Amazon Aurora Optimized Reads は、費用対効果の高い新しいオプションであり、これを備えていないインスタンスと比較して、クエリレイテンシーが最大 8 倍改善し、コストが最大 30% 削減されます。これは、データベースインスタンスのメモリ容量を超える大規模なデータセットを使用するアプリケーションに最適です。

Amazon Aurora Optimized Reads インスタンスは、NVMe ベースの SSD ブロックレベルのローカルストレージ (Graviton ベースの R6gd およびインテルベースの R6id インスタンスで利用可能) を使用して、データベースインスタンスのメモリ容量を超えるデータセットを使用するアプリケーションのクエリレイテンシーを改善します。Optimized Reads には、階層化されたキャッシュや一時オブジェクトなどのパフォーマンスの強化が含まれます。

階層化されたキャッシュにより、読み取りを多用し、I/O が大量に発生するアプリケーション (運用ダッシュボード、異常検出、ベクトルベースの類似検索など) では、クエリレイテンシーが最大 8 倍改善し、コストが最大 30% 削減されます。これらの利点は、インメモリデータベースのバッファキャッシュから削除されたデータをローカルストレージに自動的にキャッシュし、そのデータへの後続のアクセスを高速化することによって実現されます。階層化されたキャッシュは、Aurora I/O-Optimized 設定を備えた Amazon Aurora PostgreSQL エディションでのみ使用できます。

一時オブジェクトは、Aurora PostgreSQL によって生成された一時テーブルをローカルストレージに配置することでクエリ処理の高速化を実現し、ソート、ハッシュ集計、高負荷の結合、および他のデータを多用するオペレーションを伴うクエリのパフォーマンスを改善します。

Amazon Aurora Optimized Reads for Aurora PostgreSQL は、レイテンシーの影響を受けやすいアプリケーションや大規模なワーキングセットを使用するお客様に、ビジネス SLA を満たし、インスタンスでさらに多くのことを実行するための、費用対効果が魅力的な代替手段を提供します。

Amazon Aurora Optimized Reads は、インテルベースの R6id および Graviton ベースの R6gd インスタンスでご利用いただけます。Aurora が利用可能なリージョンについては、こちらを参照してください。

Amazon Aurora Optimized Reads は、R6id および R6gd インスタンス上の Aurora の PostgreSQL 互換エディションでご利用いただけます。サポートされているエンジンバージョンは 15.4 以降、Aurora PostgreSQL では 14.9 以降です。

Amazon Aurora Optimized Reads は、Aurora Serverless v2 (ASv2) ではご利用いただけません。

はい。Amazon Aurora Optimized Reads は両方の設定でご利用いただけます。どちらの設定でも、Optimized Reads 対応インスタンスは一時テーブルを NVMe ベースのローカルストレージに自動的にマッピングし、分析クエリとインデックスの再構築のパフォーマンスを改善します。

読み取りを多用し、大量の I/O が発生するワークロードについて、Aurora I/O-Optimized を使用するように設定された、Aurora PostgreSQL 上の Optimized Reads 対応インスタンスは、データベースインスタンスのメモリ容量を超える大規模なデータセットを使用するアプリケーションのために、NVMe ベースのローカルストレージ上のメモリから削除されるデータを自動的にキャッシュします。これにより、このインスタンスは、この構成を使用しないインスタンスと比較してクエリレイテンシーを最大 8 倍改善し、コストを 30% 削減します。

お客様は、AWS マネジメントコンソール、CLI、SDK を通じて Amazon Aurora Optimized Reads の使用を開始できます。Optimized Reads は、デフォルトですべての R6id および R6gd インスタンスでご利用いただけます。この機能を使用するために必要なのは、既存の Aurora データベースクラスターを変更して R6id および R6gd インスタンスを含めるか、またはこれらのインスタンスを使用して新しいデータベースクラスターを作成することだけです。使用を開始するには、Amazon Aurora Optimized Reads ドキュメントをご覧ください。

R6id および R6gd インスタンスで使用可能なローカルストレージの約 90% は Optimized Reads に使用でき、Aurora は SSD 書き込み増幅の影響を軽減するために NVMe ストレージの 10% が予約されます。使用可能なストレージの割り当ては、有効になっている Optimized Reads の機能によって異なります。

Optimized Reads で一時オブジェクトと階層化されたキャッシュの両方の機能を使用する場合、ローカルストレージ内の一時オブジェクトのために使用できる領域は、これらのデータベースインスタンスで使用できるメモリサイズの 2 倍に相当します。これは、Aurora PostgreSQL の一時オブジェクトストレージの現在のサイズと一致します。残りのローカルストレージのディスク領域は、データのキャッシュのために使用できます。

Optimized Reads で一時オブジェクト機能のみを使用する場合、使用可能なすべてのローカルストレージのディスク領域を一時オブジェクトのために使用できます。例えば、r6gd.8xlarge インスタンスで一時オブジェクトと階層化されたキャッシュの両方の機能を使用する場合、一時オブジェクトのために 534 GiB (メモリ容量の 2 倍) が予約され、階層化されたキャッシュのために 1,054 GiB が予約されます。

ローカルストレージに障害が発生した場合、Aurora は自動的にホストの置き換えを実行します。マルチノードデータベースクラスターでは、これによりリージョン内のフェイルオーバーがトリガーされます。

データベースのフェイルオーバーが発生した場合、フェイルオーバー後にクエリレイテンシーが一時的に増大します。このレイテンシーの増大は時間の経過とともに小さくなり、最終的にはフェイルオーバー前のクエリレイテンシーに追いつきます。この追いつきに要する期間は、クラスターキャッシュ管理 (CCM) を有効にすることで短縮できます。CCM を使用すると、お客様は、特定の Aurora PostgreSQL データベースインスタンスをフェイルオーバーターゲットとして指定できます。

CCM が有効になっている場合、指定されたフェイルオーバーターゲットのローカルストレージキャッシュはプライマリインスタンスのローカルストレージキャッシュを厳密にミラーリングするため、フェイルオーバー後の追いつきに要する時間が短くなります。ただし、指定されたフェイルオーバーターゲットが、ライターインスタンスのワークロードとは別の読み取りワークロードを処理するためにも使用されている場合、CCM を有効にすると、ローカルストレージキャッシュの長期的な有効性に影響が生じる可能性があります。

したがって、リーダーをスタンバイフェイルオーバーとして指定する必要があるワークロードを実行しているお客様は、フェイルオーバー後にクエリレイテンシーが迅速に元に戻る可能性を高めるために、CCM を有効にする必要があります。指定したフェイルオーバーターゲットで別個のワークロードを実行しているお客様には、CCM を有効にする前に、フェイルオーバー後のレイテンシーの即時回復のニーズと、キャッシュパフォーマンスの長期的な有効性のバランスを取ることをお勧めします。

トランザクションデータにほぼリアルタイムでアクセスする必要がある場合は、Amazon Redshift との Amazon Aurora ゼロ ETL 統合を使用してください。この統合により、簡単な SQL コマンドで Amazon Redshift ML を活用できるようになります。

Amazon Redshift との Amazon Aurora ゼロ ETL 統合は、Aurora MySQL 3.05 バージョン (MySQL 8.0.32 互換) 以降の Aurora MySQL 互換エディションで利用できます。利用できるリージョンは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、欧州 (アイルランド)、欧州 (フランクフルト)、欧州 (ストックホルム) です。Aurora ゼロ ETL 統合と Amazon Redshift の統合は、米国東部 (オハイオ) リージョンの Aurora PostgreSQL 15.4 用の Aurora PostgreSQL 互換エディションでご利用いただけます。

Aurora ゼロ ETL 統合と Amazon Redshift の統合により、複雑なデータパイプラインを構築して維持する必要がなくなります。1 つまたは複数の Aurora データベースクラスターからのデータを 1 つの Amazon Redshift データベースクラスターに統合し、Amazon Aurora からのペタバイト単位のトランザクションデータに対して、Amazon Redshift を使用してほぼリアルタイムの分析と ML を実行できます。 

Amazon Redshift との Amazon ゼロ ETL 統合は、Amazon Aurora Serverless v2 と互換性があります。Aurora Serverless v2 と Amazon Redshift Serverless の両方を使用すると、データパイプラインのインフラストラクチャを管理することなく、トランザクションデータの分析をほぼリアルタイムで生成できます。

まず、Amazon RDS コンソールを使用してゼロ ETL 統合を作成します。これには、Aurora ソースと Amazon Redshift デスティネーションを指定します。統合が作成されると、Aurora データベースが Amazon Redshift にレプリケートされ、最初のシードが完了したらデータのクエリを開始できます。詳細については、Amazon Redshift との Amazon Aurora ゼロ ETL 統合に関するスタートガイドをお読みください。

ゼロ ETL とデータ変更の継続的な処理に追加料金はかかりません。ゼロ ETL 統合の一環として作成された変更データの作成と処理に使用された既存の Amazon RDS および Amazon Redshift リソースには課金されます。これらのリソースには次のものが含まれます。

• 拡張バイナリログを有効にすることで追加の I/O とストレージが使用される
• Amazon Redshift データベースをシードするための初期データエクスポートのスナップショットエクスポートコスト
• レプリケートされたデータを保存するための追加の Amazon Redshift ストレージ
• ソースからターゲットへのデータ移動にかかる Cross-AZ データ転送コスト。

詳細については、Aurora の料金ページにアクセスしてください。

Amazon DevOps Guru for RDS は、データベースのパフォーマンスと運用上の問題を自動的に検出および診断するように設計されています。Amazon RDS (Amazon Aurora を含む) の新しい機械学習を利用した機能であり、数日もかかっていた問題を数分以内に解決できます。

Amazon DevOps Guru for RDS は、Amazon DevOps Guru の機能であり、すべての Amazon RDS エンジンと他の数十のリソースタイプの運用およびパフォーマンスに関する問題を検出するように設計されています。DevOps Guru for RDS は、DevOps Guru の機能を拡張して、リソースの過剰使用や特定の SQL クエリの誤動作など、Amazon RDS のさまざまなデータベース関連の問題を検出、診断、および修正します。

問題が発生すると、Amazon DevOps Guru for RDS はすぐにデベロッパーと DevOps エンジニアに通知するように設計されており、診断情報、問題の範囲の詳細、およびお客様がデータベースに関するパフォーマンスのボトルネックと運用上の問題を迅速に解決するのに役立つインテリジェントな修復についてレコメンデーションを提供します。

Amazon DevOps Guru for RDS は、手動作業を行わずに、時間 (数時間から数日かかっていたものを数分に) を短縮して、リレーショナルデータベースのワークロードで見つけにくいパフォーマンスのボトルネックを検出して解決するように設計されています。

すべての Amazon Aurora データベースで DevOps Guru for RDS を有効にすると、ワークロードのパフォーマンス問題が自動的に検出されます。その後、各問題についてアラートが送信され、結果が説明され、問題を解決するための措置が推奨されます。
DevOps Guru for RDS を使用すれば、専門家以外のユーザーがデータベースを管理しやすくなり、データベースの専門家がさらに多くのデータベースを管理できるように支援します。

Amazon DevOps Guru for RDS は、機械学習を使用して、Amazon RDS Performance Insights (PI) によって収集されたテレメトリデータを分析します。DevOps Guru for RDS がデータベースに保存されているデータを分析に使用することはありません。PI は、データベースの負荷を測定します。これは、アプリケーションがデータベースでどのように時間を費やしているかを特徴付けるメトリクスであり、MySQL のサーバーステータス変数や PostgreSQL の pg_stat テーブルなど、データベースによって生成される厳選されたメトリクスです。

DevOps Guru for RDS の使用を開始するには、RDS コンソールで Performance Insights が有効になっていることを確認してから、Amazon Aurora データベースに対して DevOps Guru を有効にします。DevOps Guru を使用すれば、分析カバレッジの境界を AWS アカウント全体として選択することも、DevOps Guru に分析させる特定の AWS CloudFormation スタックを指定することも、AWS タグを使用して DevOps Guru に分析させるリソースグループを作成することもできます。

Amazon DevOps Guru for RDS は、ロックパイルアップ、接続ストーム、SQL リグレッション、CPU と I/O の競合、メモリの問題など、アプリケーションサービスの品質に影響を与える可能性のあるさまざまなパフォーマンス問題を特定できます。

Amazon RDS Performance Insights は、Amazon RDS データベースパフォーマンスメトリクスを収集して視覚化するデータベースパフォーマンスのチューニングとモニタリングを行う機能で、データベースの負荷をすばやく評価し、いつどこに措置を講じたらよいかを判断するのに役立ちます。Amazon DevOps Guru for RDS は、これらのメトリクスをモニタリングし、データベースでパフォーマンスの問題が発生していることを検出します。さらに、メトリクスを分析して、何が問題で、何ができるかを通知するように設計されています。

新しい最新のアプリケーション、特にリクエスト/レスポンスモデルで Aurora にアクセスする必要がある AWS Lambda で構築されたアプリケーションには、Data API を使用する必要があります。既存のアプリケーションがデータベースドライバーと高度に連動している場合、実行時間が長い場合、または開発者が一時テーブルなどのデータベース機能を利用したり、セッション変数を使用したりする場合は、Data API の代わりにデータベースドライバーを使用して永続的なデータベース接続を管理する必要があります。

Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API AWS リージョンとデータベースバージョンの可用性は、当社のドキュメントに記載されています。現在 Aurora Serverless v1 用の Data API を使用しているお客様は、Aurora Serverless v2 に移行して、再設計された Data API と Aurora Serverless v2 のよりきめ細かなスケーリングを活用することをお勧めします。

Data APIを使用すると、モダンアプリケーション開発を簡素化および加速できます。Data API は使いやすく安全な HTTP ベースの API で、データベースドライバーをデプロイしたり、クライアント側の接続プールを管理したり、アプリケーションとデータベース間の複雑な VPC ネットワークを設定したりする必要がありません。また、Data API は、データベース接続を自動的にプールして共有することでスケーラビリティを向上させ、接続を頻繁に開いたり閉じたりするアプリケーションによる計算オーバーヘッドを軽減します。 

Aurora Serverless v1 の既存の Data API は、Aurora の PostgreSQL 互換エディションと MySQL 互換エディションの両方で Aurora Serverless v1 の機能として残ります。Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API は Aurora Serverless v1 をサポートしていません。Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API は、Aurora グローバルデータベースライターインスタンスをサポートします。

ユーザーは、権限がある場合にのみで API オペレーションを呼び出すことができます。管理者は、権限を定義する AWS ID およびアクセス管理 (IAM) ポリシーをアタッチすることで、Data API を使用する権限をユーザーに付与できます。IAM ロールを使用している場合は、ポリシーをロールにアタッチすることもできます。Data API を呼び出すと、AWS Secrets Manager のシークレットを使用して Aurora DB クラスターの認証情報を渡すことができます。 

Aurora Serverless v1 での Data API の使用は、追加料金なしで引き続き利用できます。Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API は、Aurora 料金ページに記載されている API リクエスト量に基づいて価格設定されます。Aurora Servless v2 および Aurora プロビジョニングインスタンスの Data API は、Aurora Serverless v1 の Data API の場合と同様に、管理イベントの代わりに AWS CloudTrail データプレーンイベントを使用してアクティビティをログに記録します。

このアクティビティを追跡したい場合は、CloudTrail コンソール、CLI、または SDK を使用してデータイベントのロギングを有効にできます。これには、CloudTrail の料金ページに記載されている料金が発生します。さらに、AWS Secrets Manager の使用には、AWS Secrets Manager 料金ページに記載されている料金が発生します。 

AWS CloudTrail は AWS API アクティビティを管理イベントまたはデータイベントとしてキャプチャします。CloudTrail 管理イベント (「コントロールプレーンオペレーション」とも呼ばれる) は、リソースの作成、更新、削除など AWS アカウント内のリソースに対して実行される管理オペレーションを表示します。CloudTrail データイベント (「データプレーンオペレーション」とも呼ばれる) は、AWS アカウントのリソースで、またはリソース内で実行されたリソースオペレーションを示します。

Data API は Aurora データベース内のデータに対してクエリを実行するため、データプレーンの操作を実行します。したがって、Data API アクティビティはイベントの正しい分類であるため、データイベントとしてログに記録します。データイベントのログを有効にした場合、CloudTrail データイベントに対してのみ料金が発生します。

はい。Data API の無料利用枠には、1 か月あたり 100 万件のリクエスト（すべての AWS リージョンの合計）、初年度の使用分が含まれます。 1 年後、お客様は Aurora 料金ページに記載されているように Data API の支払いを開始します。

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

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

Amazon RDS ブルー/グリーンデプロイを使用すると、より安全、簡単、高速にデータベースの更新ができます。ブルー/グリーンデプロイは、メジャーバージョンまたはマイナーバージョンのデータベースエンジンのアップグレード、オペレーティングシステムの更新、論理レプリケーションを中断しないグリーン環境でのスキーマの変更 (テーブルの最後に新しい列を追加するなど)、またはデータベースパラメーター設定の変更などのユースケースに最適です。

ブルー/グリーンデプロイを使用すると、1 回のスイッチオーバーで複数のデータベースを同時に更新できます。これにより、セキュリティパッチを最新の状態に保ち、データベースのパフォーマンスを向上させ、短期間で予測可能なダウンタイムで新しいデータベース機能にアクセスできます。Aurora のマイナーバージョンアップグレードのみを行う場合は、 Aurora ゼロダウンタイムパッチ (ZDP) の使用をお勧めします。

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

例: Aurora MySQL 互換エディション 5.7 クラスターが、us-east-1 AWS リージョンにおいて 2 つの r5.2xlarge db.instance、プライマリライターインスタンスとリーダーインスタンスで稼働しているとします。それぞれの r5.2xlarge db.instance は、40 GiB ストレージで構成され、月間 2,500 万 I/O があります。Amazon RDS ブルー/グリーンデプロイを使って　ブルーインスタンスのトポロジーのクローンを作成し、15 日間 (360 時間) それを実行すると、その間に各グリーンインスタンスは 300 万 I/O 読み取りを行います。そして、スイッチオーバーが成功した後、ブルーインスタンスを削除します。ブルーインスタンス (ライターとリーダー) のコストは、15 日間で 849.2 USD、オンデマンド料金は 1.179 USD/時間 (インスタンス + ストレージ + I/O) です。グリーンインスタンス (ライターとリーダー) のコストは、15 日間で 840.40 USD、オンデマンド料金は 1.167 USD/時間 (インスタンス + ストレージ + I/O) です。この 15 日間、ブルー/グリーンデプロイを使用した場合の合計コストは 1689.60 USD で、これはその期間にブルーインスタンスを実行した場合のコストのおよそ 2 倍です。

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

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

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

Amazon RDS ブルー/グリーンデプロイは、スイッチオーバー完了後にグリーン環境への書き込みを可能にするよう設計されており、スイッチオーバープロセス中のデータ損失はゼロになります。

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

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

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

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