Amazon Aurora のよくある質問

Amazon Aurora は、大規模なパフォーマンスと高可用性を提供する最新のリレーショナルデータベースサービスで、完全にオープンソースの MySQL と PostgreSQL 互換エディション、およびサーバーレスや機械学習 (ML) 駆動のアプリケーションを構築するためのさまざまなデベロッパーツールを提供します。

Aurora のストレージシステムは、分散型で耐障害性と自己修復機能を備えており、コンピューティングリソースから切り離され、データベースインスタンスごとに最大 256 TiB まで自動的にスケールアップされます。Amazon Aurora は、最大 15 個の低レイテンシーリードレプリカ、ポイントインタイムリカバリ、Amazon Simple Storage Service (Amazon S3) への継続的なバックアップ、3 つのアベイラビリティーゾーン (AZ) 間でのレプリケーションにより、優れたパフォーマンスと可用性を発揮します。

Aurora は、ハードウェアプロビジョニング、データベース設定、パッチ適用、バックアップなど、時間のかかる管理タスクを自動化すると同時に、1/10 のコストで商用データベースのセキュリティ、可用性、信頼性を提供するフルマネージドサービスでもあります。

Amazon Aurora は、既存の MySQL オープンソースデータベースとドロップイン互換性があり、新しいリリースのサポートも定期的に追加されています。このため、標準的なインポート/エクスポートツールやスナップショットを使用して、MySQL データベースを簡単に Aurora との間で移行できます。また、現在お客様が MySQL データベースで使用しているコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。これにより、2 つのエンジン間で簡単にアプリケーションを移動できます。

現在の Amazon Aurora MySQL のリリース互換性情報については、ドキュメントで確認することができます。

Amazon では Aurora PostgreSQL と Aurora で利用可能なすべての拡張機能を完全にサポートしています。Aurora PostgreSQL のサポートが必要な場合は、AWS サポートにご連絡ください。アクティブな AWS プレミアムサポートのアカウントをお持ちの場合、Aurora 固有の問題については、AWS プレミアムサポートにご連絡ください。

Amazon Aurora は、既存の PostgreSQL オープンソースデータベースとドロップイン互換性があり、新しいリリースのサポートも定期的に追加されています。このため、標準的なインポート/エクスポートツールやスナップショットを使用して、PostgreSQL データベースを簡単に Aurora との間で移行できます。また、現在お客様が PostgreSQL データベースで使用しているコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。

現在の Amazon Aurora PostgreSQL のリリース互換性情報については、ドキュメントで確認することができます。

Aurora を試用するには、AWS マネジメントコンソールにサインインし、[Database] (データベース) カテゴリの [RDS] を選択して、データベースエンジンとして Amazon Aurora を選択します。詳細なガイダンスとリソースについては、「Aurora の開始方法」のページをご覧ください。

Aurora が利用可能なリージョンについては、こちらを参照してください。

PostgreSQL から Aurora に移行したり、その逆を行いたい場合は、いくつかの選択肢があります。

• 標準の pg_dump ユーティリティを使用して PostgreSQL からデータをエクスポートし、pg_restore ユーティリティを使用して Aurora にデータをインポートします。その逆の方法も可能です。
• また、RDS の DB スナップショットの移行機能を利用して、AWS マネジメントコンソールで Amazon RDS for PostgreSQL DB スナップショットを Aurora に移行します。

ほとんどの場合、Aurora への移行は 1 時間以内に完了しますが、データの形式およびデータセットのサイズによって時間が異なります。

Babelfish for Aurora PostgreSQL を使用して、SQL Server データベースを Amazon Aurora PostgreSQL 互換エディションに移行できます。お客様のアプリケーションはそのままお使いいただけます。詳細については、こちらの Babelfish ドキュメントをご参照ください。

MySQL から Aurora へ、あるいはその逆に移行したい場合、いくつかの選択肢があります。

• 標準の mysqldump ユーティリティを使用して MySQL からデータをエクスポートし、mysqlimport ユーティリティを使用して Aurora にデータをインポートします。その逆の方法も可能です。
• また、Amazon RDS の DB スナップショットの移行機能を利用して、AWS マネジメントコンソールで Amazon RDS for MySQL DB スナップショットを Aurora に移行します。

ほとんどの場合、Aurora への移行は 1 時間以内に完了しますが、データの形式およびデータセットのサイズによって時間が異なります。詳細については、MySQL データベースを Amazon Aurora に移行するためのベストプラクティスを参照してください。

いいえ。Aurora は標準の PostgreSQL データベースドライバーで動作します。

Amazon Aurora は、データベースワークロード用の SSD ベースの仮想化ストレージレイヤーとデータベースエンジンを緊密に統合し、ストレージシステムに対する書き込みを削減し、ロックの競合を最小化し、データベースのプロセススレッドによる遅延を排除することで、MySQL と比較して大幅に高いパフォーマンスを提供します。

SysBench による r3.8xlarge インスタンスのテストの結果、Amazon Aurora は 500,000 SELECT/秒および 100,000 UPDATE/秒のパフォーマンスを示しました。これは同じハードウェアで実行する MySQL の 5 倍のパフォーマンスです。このベンチマークとその再現方法の詳細な手順は、Amazon Aurora MySQL 互換エディションのパフォーマンスベンチマークに関するガイドに記載されています。

Amazon Aurora では、データベースワークロード用の SSD ベースの仮想化ストレージレイヤーとデータベースエンジンを緊密に統合し、ストレージシステムに対する書き込みを削減し、ロックの競合を最小化し、データベースのプロセススレッドによる遅延を排除することで、PostgreSQL と比較して大幅に高いパフォーマンスが実現されています。

SysBench による r4.16xlarge インスタンスのテストの結果、Amazon Aurora は SELECT/秒および UPDATE/秒で、同じハードウェアで実行する PostgreSQL の 3 倍のパフォーマンスを示しました。このベンチマークとその再現方法の詳細な手順は、Amazon Aurora PostgreSQL 互換エディションのパフォーマンスベンチマークに関するガイドに記載されています。

Amazon Aurora は MySQL と互換性を持つように設計されているため、既存の MySQL アプリケーションおよびツールを修正することなく実行できます。一方で、Amazon Aurora が MySQL よりも優れている領域の 1 つが、ワークロードの同時実行数が非常に多い場合です。Amazon Aurora でワークロードのスループットを最大化するには、多数のクエリやトランザクションを同時実行するようにアプリケーションを作成することをお勧めします。

Amazon Aurora は PostgreSQL と互換性を持つように設計されているため、既存の PostgreSQL アプリケーションおよびツールを修正することなく実行できます。一方で、Amazon Aurora が PostgreSQL よりも優れている領域の 1 つが、ワークロードの同時実行数が非常に多い場合です。Amazon Aurora でワークロードのスループットを最大化するには、多数のクエリやトランザクションを同時実行するようにアプリケーションを作成することをお勧めします。

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

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

はい。Amazon Aurora の使用量に応じて Database Savings Plans を購入し、1 年間にわたって一定量の使用量を約束すれば、コストを最大 35% 削減できます。 対象となる使用量に関する追加情報は、Database Savings Plans の料金ページに記載されています。

いいえ。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 GiB です。データベースの使用量に応じて、Aurora ストレージは 10 GB 単位で最大 256 TiB まで、データベースのパフォーマンスに影響を与えずに拡張されます。 ストレージを事前にプロビジョニングする必要はありません。 Aurora は、ストレージを 256 TiB 以上にスケールする Amazon Aurora PostgreSQL Limitless Database を使用して自動水平スケーリングを行っています。詳細については、「Aurora PostgreSQL Limitless Database の使用」を参照してください。

Amazon Aurora DB に関連するコンピューティングリソースをスケーリングするには、Amazon Aurora Serverless、Aurora PostgreSQL Limitless Database、手動スケーリングの 3 つの方法があります。どのオプションを選択しても、使用した分のみお支払いいただきます。

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

Aurora PostgreSQL Limitless Database を使用すると、ワークロード要件に基づいてコンピューティングリソースを自動的に水平方向にスケールし、大規模なアプリケーションをサポートできます。これにより、単一のデータベース内での操作のシンプルさを維持しながら、単一のデータベースインスタンスの書き込みスループットとストレージの制限を超えてアプリケーションをスケールできます。 

また、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% 短縮します。 
• Aurora Serverless v2 は、フェイルオーバーや他の高可用性機能のためにプロビジョニングされたように機能します。詳細については、「Aurora Serverless v2 と高可用性」を参照してください。
  
• Aurora レプリカを作成しておらず(つまり、インスタンスは 1 つ)、Aurora Serverless を使用していない場合、Aurora は元のインスタンスと同じアベイラビリティーゾーンに新しい DB インスタンスの作成を試みます。オリジナルのインスタンスの置換処理はベストエフォート型であり、アベイラビリティーゾーンで広範囲に影響を及ぼす問題がある時などは失敗する可能性があります。

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

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

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

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

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

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

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

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) を使用することもできます。プライマリリージョンとセカンダリリージョンの間で、プロビジョンドインスタンスクラスタイプまたはサーバーレスインスタンスクラスタイプの混合設定を使用できます。また、プライマリリージョンを Aurora I/O 最適化クラスター設定として、セカンダリリージョンを Aurora スタンダードとして (またはその逆に) それぞれ構成できます。詳細については、Amazon Aurora Global Database の作成にアクセスしてください。

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

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

いいえ。プライマリリージョンが使用できなくなった場合は、マネージドクロスリージョン Aurora Global Database フェイルオーバーオペレーションを使用して、セカンダリリージョンを昇格させて、完全な読み取りおよび書き込み機能を持たせることができます。また、Aurora Global Database ライターエンドポイントを使用して、新しく昇格したリージョンに接続するためにアプリケーションコードを変更する必要性を回避できます。詳細については、「Amazon Aurora Global Database への接続」にアクセスしてください。

はい。すべての Amazon Aurora DB インスタンスは VPC で作成します。Amazon VPC では、お客様のデータセンターで運用されている従来型のネットワークを正確に模倣して、仮想ネットワークのトポロジーを定義できます。これにより、どのユーザーが Amazon Aurora データベースにアクセスできるかを完全に管理できます。

はい。Amazon Aurora では、SSL (AES-256) を使用してデータベースインスタンスとアプリケーションの間の通信が保護されています。Amazon Aurora では、AWS Key Management Service (AWS KMS) で管理されるキーを使って、データベースを暗号化できます。

Amazon Aurora 暗号化を使って実行するデータベースインスタンスでは、基盤となるストレージに保存される保管中のデータが、同じクラスター内の自動バックアップ、スナップショット、レプリカと同様に暗号化されます。暗号化と復号はシームレスに処理されます。Amazon Aurora での AWS KMS の使用に関する詳細は、Amazon RDS ユーザーガイドを参照してください。

現在のところ、暗号化されていない既存の Aurora インスタンスの暗号化はサポートされていません。暗号化されていない既存のデータベースで Amazon Aurora 暗号化を使用するには、暗号化を有効にした新規 DB インスタンスを作成し、データを移行してください。

Aurora データベースには、必ずデータベース作成時に入力したデータベースポートを使用してアクセスします。これにより、データに対するセキュリティが一層強化されます。Amazon Aurora データベースに接続する際の詳細な手順は、Amazon Aurora の接続に関するガイドに記載されています。

はい、Aurora の MySQL 互換エディションと PostgreSQL 互換エディションは、HIPAA に対応しています。それらを使用して HIPAA 準拠のアプリケーションを構築し、AWS との履行済み事業提携契約 (BAA) に基づく保護された医療情報 (PHI) を含む医療関連情報を保存できます。既に AWS で BAA を締結している場合、BAA の適用を受けているアカウントでこのサービスの使用を開始するためにこれ以上何も行う必要はありません。AWS を使用してコンプライアンスに準拠したアプリケーションを構築するための詳細については、「ヘルスケアプロバイダー」を参照してください。

CVE の一覧は現在、Amazon Aurora Security Updates でご覧いただけます。

Aurora は Amazon GuardDuty と統合されており、Aurora データベースに保存されているデータへの潜在的な脅威を特定するのに役立ちます。GuardDuty RDS Protection は、アカウント内の既存および新規のデータベースへのログインアクティビティをプロファイリングおよびモニタリングし、カスタマイズされた機械学習モデルを使用して Aurora データベースへの疑わしいログインを検出します。詳細については、「GuardDuty RDS Protection を使用した脅威のモニタリング」およびGuardDuty RDS Protection ユーザーガイドを参照してください。

Aurora Serverless は、Amazon Aurora のオンデマンドの Auto Scaling 設定です。 Aurora Serverless を使用すると、データベース容量を管理せずにデータベースをクラウドで実行できます。データベース容量を手動で管理すると時間がかかり、データベースリソースの非効率的な使用につながります。Aurora Serverless では、データベースを作成し、必要に応じてデータベースの容量範囲を指定し、アプリケーションを接続します。Aurora は、アプリケーションのニーズに基づいて、指定された範囲内で容量を自動的に調整します。

データベースがアクティブなときに使用したデータベース容量に対して、秒単位でお支払いいただきます。Aurora Serverless の詳細を確認し、Amazon RDS マネジメントコンソールでいくつかのステップだけで使い始めることができます。

Aurora Serverless v2 の互換性については、こちらをご覧ください。

はい。クラスターがプロビジョンされている既存の Aurora のスナップショットを、Aurora Serverless DB クラスターに復元することができます。その逆も可能です。

同一の VPC で実行しているクライアントアプリケーション内から Aurora Serverless DB クラスターにアクセスします。Aurora Serverless DB にパブリック IP アドレスを指定することはできません。

Aurora Serverless は、動作中のデータベースワークロードに応じて自動的にスケールしますが、大量の新しいトランザクションの発生といったワークロードの急激な変化に対して、キャパシティーを迅速にスケールして十分に対応することができない場合があります。このような場合、AWS マネジメントコンソール、AWS CLI、Amazon RDS API を使って、特定の値のキャパシティーを明示的に設定できます。

Aurora Serverless では、スケーリングオペレーションが開始されると、データベースのスケーリングを安全に行える時点となるスケーリングポイントを見つけようとします。Aurora Serverless では、進行中の長期のクエリやトランザクションがある場合や、一時的なテーブルやテーブルロックを使用している場合、スケーリングポイントを特定できないことがあります。

はい、Aurora Serverless v2 の使用を開始して、既存の Aurora DB クラスターのデータベースコンピューティング容量を管理できます。プロビジョンされたインスタンスと Aurora Serverless v2 の両方を含むクラスターは、混合構成クラスターと呼ばれます。クラスター内にプロビジョンされたインスタンスと Aurora Serverless v2 の任意の組み合わせを選択できます。

Aurora Serverless v2 をテストするには、Aurora DB クラスターにリーダーを追加し、インスタンスタイプとして Serverless v2 を選択します。リーダーが作成されて使用可能になると、読み取り専用ワークロードでの使用を開始できます。リーダーが期待どおりに機能していることを確認したら、フェイルオーバーを開始して、読み取りと書き込みの両方で Aurora Serverless v2 の使用を開始できます。このオプションは、Aurora Serverless v2 の使用を開始するためのダウンタイムを最小限に留めます。

Aurora Serverless v2 は、リードレプリカ、マルチ AZ 設定、Aurora Global Database、RDS Proxy、および Performance Insights など、プロビジョンされた Aurora のすべての機能をサポートします。

Aurora Serverless では、データベース容量は Aurora Capacity Unit (ACU) で測定されます。ACU 使用量について 1 秒あたりの定額料金をお支払いいただきます。Aurora Serverless でワークロードを実行するためのコンピューティングコストは、選択したデータベースクラスター設定、つまり Aurora Standard または Aurora I/O 最適化によって異なります。料金と利用可能なリージョンについては、Aurora の料金ページをご覧ください。

Aurora PostgreSQL 無制限のデータベースは、水平スケーリングを自動化して毎秒数百万件の書き込みトランザクションを処理し、単一データベース内での操作のシンプルさを維持しながらペタバイト単位のデータを管理します。ワークロードをサポートするために複数のデータベースインスタンスにわたってデータをスケールするための複雑なソリューションを構築および保守しなくても、大規模なアプリケーションの構築に集中できます。Aurora PostgreSQL Limitless Database はアプリケーションのワークロードに応じてスケールされ、支払いはアプリケーションが使用した分だけです。詳細については、Aurora PostgreSQL Limitless Database ユーザーガイドをご覧ください。

水平方向にスケールする必要があり、1 つの Aurora データベースインスタンスがサポートするよりも多くの書き込みスループットまたはデータストレージ容量を必要とするアプリケーションには、Aurora PostgreSQL Limitless Database を使用する必要があります。例えば、各ユーザーの会計データは他のユーザーから独立しているため、会計アプリケーションをユーザーごとに水平に分割できます。Aurora PostgreSQL Limitless Database は、最も規模が大きく急成長しているアプリケーションをサポートするように自動的にスケールします。 

スケーリングには既存の機能が 2 つあります。Aurora レプリカを使用した Amazon Aurora Auto Scaling と Aurora Serverless v2 です。

Aurora レプリカを使用すると、1 つのデータベースインスタンスが提供できる制限を超えて Aurora クラスターの読み取り容量を増やすことができます。読み取りワークロードと書き込みワークロードを分離できるアプリケーションでは、最大 15 個のリードレプリカの利点を享受し、全体的な読み取りスループットを向上させることができます。Aurora レプリカでは、アプリケーションでデータを水平に分割する必要はありません。すべてのデータがすべてのレプリカで利用可能です。Aurora レプリカは Aurora クラスターのストレージ容量や書き込みスループットを増加させません。

Aurora Serverless v2 は、Aurora 向けのオンデマンドの垂直スケーリング設定であり、単一のコンピューティングインスタンスの容量制約の範囲内で、アプリケーションのニーズに基づいてデータベースコンピューティングとメモリを自動スケーリングします。Aurora Serverless v2 は、ライターインスタンスとリーダーインスタンスの両方でサポートされています。ただし、Aurora クラスターのストレージ容量は増えません。アプリケーションが水平方向にスケールするように設計されている場合、Aurora PostgreSQL Limitless Database を使用すると、単一の Aurora ライターインスタンスの制限を超えて、データベースの書き込みスループットとストレージ容量をスケールできます

Aurora PostgreSQL Limitless Database は、テーブル列の顧客指定値 (シャードキーとも呼ばれます) を使用して、データベースインスタンス間でデータを分割します。例えば、ユーザー情報を保存するテーブルは、User-ID 列をシャードキーとして使用して分割することが可能です。内部的には、Aurora PostgreSQL Limitless Database はサーバーレスノードの分散デプロイです。ノードはルーターまたはシャードです。ルーターはデータベースの分散性を管理します。各シャードにはデータのサブセットが保存されるため、並列処理によって高い書き込みスループットを実現できます。

コンピューティングまたはストレージの要件が高まると、Aurora はまず各インスタンスとそれに関連するストレージを自動的にスケールアップし、次にさまざまなシャードキー値のデータベースワークロードに対応するようにスケールアウトします。どの時点でも、シャードキー値は単一のサーバーレスインスタンスによって所有され、処理されます。アプリケーションが Aurora PostgreSQL Limitless Database に接続してリクエストを発行すると、最初にそのリクエストの分析を行います。次に、リクエストで指定されたシャードキー値を所有するコンピューティングインスタンスに送信するか、複数のインスタンスにわたるクエリをオーケストレーションします。

それぞれ異なるシャードキー値を処理する複数のコンピューティングインスタンスが、同じ Aurora PostgreSQL Limitless Database に対するアプリケーションリクエストを同時に処理できます。Aurora PostgreSQL Limitless Database は、シングルライターの Aurora PostgreSQL システムと同じトランザクションセマンティクスを提供し、アプリケーション内のさまざまなトランザクションドメインを管理する複雑さを解消します。

Aurora PostgreSQL Limitless Database は、データを保存するテーブルとして、シャード、リファレンス、標準という 3 種類のテーブルをサポートしています。

シャードテーブル: これらのテーブルは複数のシャードに分散されています。データは、シャードキーと呼ばれるテーブル内の指定された列の値に基づいてシャード間で分割されます。アプリケーション中の最も大きく、最も入出力量の多いテーブルをスケーリングするのに便利です。

リファレンステーブル: これらのテーブルはすべてのシャードのデータを完全にコピーするため、不要なデータ移動がなくなり、結合クエリをより高速に実行できます。これらは通常、製品カタログや郵便番号など、あまり変更されないリファレンスデータに使用されます。

標準テーブル: これらのテーブルは通常の Aurora PostgreSQL テーブルに似ています。標準テーブルはすべて 1 つのシャードにまとめられるため、不要なデータ移動がなくなり、結合クエリをより高速に実行できます。標準テーブルからシャードテーブルとリファレンステーブルを作成できます。

PostgreSQL の互換性に関する考慮事項の詳細については、「Aurora PostgreSQL Limitless Database の要件と考慮事項」を参照してください。

Amazon RDS コンソールまたは Amazon API で Aurora PostgreSQL Limitless Database を使い始めると、サポートされているエンジンバージョンで新しい Aurora PostgreSQL クラスターを作成できます。使い始める方法の詳細については、Aurora PostgreSQL Limitless Database ユーザーガイドをご覧ください。

アプリケーションは、標準の Aurora PostgreSQL クラスターに接続するのと同じ方法で Aurora PostgreSQL Limitless Database に接続します。クラスターエンドポイントに接続するだけで済みます。詳細については、「Aurora PostgreSQL Limitless Database の使用」を参照してください。

はい。Aurora PostgreSQL Limitless Database を使用するにはデータベーススキーマを調整する必要があるかもしれません。シャーディングされたテーブルにはすべてシャードキーが含まれている必要があるため、このデータをバックフィルする必要がある場合があります。例えば、会計アプリケーションでは、各ユーザーが他のユーザーから独立しているため、User-ID 列を使用してデータをユーザーごとに分割する場合があります。ユーザーテーブル自体には当然この列が含まれていますが、
請求書の明細項目を含むテーブルなど、他のテーブルには含まれていない場合があります。クエリのパフォーマンスを最適化するには、これらのテーブルをユーザーごとに分割してテーブルをコロケーションする必要があるため、ユーザー ID 列をテーブルに追加する必要があります。

データを分割するために使用される列には命名上の制約はありませんが、列定義は一致している必要があります。アプリケーションクエリにシャードキーを追加する必要があります。また、最適なパフォーマンスが得られるようにクエリとトランザクションを調整する必要がある場合もあります。例えば、テーブルがユーザー ID だけで分割されている場合に Invoice-ID を使用して請求書を検索すると、クエリはすべてのデータベースインスタンスで実行する必要があるため、処理が遅くなります。ただし、クエリでユーザー ID も指定されている場合、クエリはそのユーザー ID のすべての注文を含む 1 つのデータベースインスタンスにルーティングされるため、クエリのレイテンシーが短縮されます。

はい。Aurora PostgreSQL Limitless Database のコンピューティング冗長性を 0 より大きく設定すると、高可用性オプションを選択できます。これにより、99.99% の可用性を実現できます。Aurora PostgreSQL Limitless Database のデータを保存してアクセスする各コンピューティングインスタンスには、プライマリが使用できない場合にリクエストを引き継ぐことができるスタンバイが 1 つか 2 つあります。ルーターは、アプリケーションへの影響を最小限に抑えるためにトラフィックを自動的にリダイレクトします。

Aurora PostgreSQL Limitless Database は、PostgreSQL 16.4 と互換性がある Aurora I/O 最適化クラスター設定で使用できます。Aurora PostgreSQL Limitless Database の AWS リージョン別の使用可否に関する追加情報は、Aurora の料金ページに記載されています。

Aurora PostgreSQL Limitless Database では、データベース容量は ACU 単位で測定されます。ACU 使用量について 1 秒あたりの定額料金をお支払いいただきます。Aurora I/O 最適化設定のストレージ料金が適用されます。詳細については、Aurora の料金ページをご覧ください。

Amazon Aurora Parallel Query とは、単一のクエリを Aurora のストレージレイヤーにある数千規模の CPU にわたってプッシュダウンしてコンピューティングの負荷を分散できることを言います。Parallel Query なしでは、Amazon Aurora データベースに対して出されたクエリはデータベースクラスターのひとつのインスタンス中のみで実行されます。多くのデータベースはほぼこのように動作します。

Parallel Query は大きな表でもフレッシュなデータと良好なクエリパフォーマンスを要する分析ワークロードに適しています。この種のワークロードの多くはオペレーションに関するものです。

Parallel Query を使用すると、パフォーマンスが向上し、分析クエリが最大 2 桁向上します。また、Aurora クラスター内の現在のトランザクションデータに対して直接クエリを発行できるため、シンプルなオペレーションとフレッシュなデータを得られます。また、Parallel Query では同じデータベースでトランザクションワークロードと分析ワークロードが可能であるため、Aurora が分析クエリと同時に高いトランザクションスループットを維持できます。

バッファープールにまだない大型のデータセットへの多くのクエリに改善が見込めます。Parallel Query の最初のバージョンは 200 を越す SQL 関数、等価結合、プロジェクションの処理をプッシュダウンおよびスケーリングできます。

具体的なクエリのパフォーマンスへの改善は Aurora ストレージレイヤーにどれだけのクエリプランがプッシュダウンできるかによります。クエリレイテンシーに 1 桁以上の改善が見られたというお客様もおられます。

はい。しかしそのようなケースは希です。

クエリシンタックスには変更を加える必要はありません。具体的なクエリに対してはクエリオプティマイザーが自動的に Parallel Query を使うべきかどうかを決定します。クエリが Parallel Query を使うかどうかを確認するには、EXPLAIN コマンドを用いてクエリ実行計画を見ることができます。ヒューリスティックスをバイパスして Parallel Query をテスト目的に強制的に使いたい場合、セッション変数に aurora_pq_force を使ってください。

Parallel Query は aurora_pq パラメータを用いてグローバルでもセッションレベルでも動的に有効化、無効化可能です。

いいえ。すでにインスタンス、I/O、ストレージに対してお支払いいただいている以上の料金はいただきません。

いいえ。クエリに対する Parallel Query IO コストはストレージレイヤーで計量されており、Parallel Query をオンにすると同じか、それ以上になります。改善されるのはクエリのパフォーマンスです。

Parallel Query で I/O コストが上がるには 2 つの理由があり得ます。まず、表中のデータのうちいくつかがバッファープールにあっても、Parallel Query はすべてのデータのスキャンはストレージレイヤーでされなければならないので、I/O が発生します。また、バッファープールで競合を避けることには、Parallel Query クエリの実行がバッファープールをウォームアップしないという副作用があります。その結果、同じ Parallel Query クエリの連続した実行には I/O コストがフルにかかります。

詳細については、ドキュメントの Parallel Query を参照してください。

いいえ。現時点では、Parallel Query は R* インスタンスファミリーのインスタンスで使用できます。

Parallel Query は、MySQL 5.7 および MySQL 8.0 互換バージョンの Amazon Aurora で利用可能です。

Parallel Query は Aurora Serverless v2 および Backtrack と互換性があります。

いいえ。Parallel Query は多くのケースでクエリレイテンシーの改善を見込んでいるものの、I/O コストは高くなります。ワークロードで機能をオン、オフにして徹底的にテストされることをお勧めします。Parallel Query が正しい選択肢であると確信されたら、クエリオプティマイザーを用いて Parallel Query を使用するクエリを自動的に決定できます。万一オプティマイザーが最適な決定をしてくれない場合は、設定をオーバーライドできます。

Aurora Parallel Query はデータウェアハウスではなく、このような製品に通常備わった機能はありません。リレーショナルデータベースのクエリパフォーマンスを向上させるために作られており、データベース中の最新データに高速で分析クエリを行う必要のあるオペレーション分析などのユースケースに最適です。

エクサバイト規模のクラウドデータウェアハウスについては、Amazon Redshift をご検討ください。

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 を有効にする前に、フェイルオーバー後のレイテンシーの即時回復のニーズと、キャッシュパフォーマンスの長期的な有効性のバランスを取ることをお勧めします。

pgvector は、Amazon Aurora PostgreSQL 互換エディションでサポートされている PostgreSQL のオープンソース拡張機能です。

pgvector を使用すると、Amazon Bedrock や Amazon SageMaker からの埋め込みなど、データベース内の機械学習 (ML) モデルや人工知能 (AI) モデルから生成された何十億もの埋め込みを保存、検索、インデックス付け、クエリできます。ベクトル埋め込みとは、テキスト、画像、動画などのコンテンツのセマンティックな意味を表す数値表現です。

pgvector を使用すると、Aurora PostgreSQL データベース内の埋め込みにクエリを実行して、ベクトルとして表されるこれらのデータ型を Aurora の他の表形式データと組み合わせて、効率的なセマンティック類似性検索を実行できます。これにより、類似するテキストや画像に基づくパーソナライズされた推奨事項、面接のメモに基づいた候補者のマッチング、チャットボット、成功した議事録やチャット記録の対話に基づくカスタマーサービスの次善アクションの推奨事項など、生成 AI やその他の AI/ML システムを新しいタイプのアプリケーションに使用できるようになります。 

ベクトルデータベースの機能に関するブログを読み、pgvector エクステンションを使用して Aurora PostgreSQL データベースに埋め込みを保存する方法、インタラクティブな質問応答チャットボットを作成する方法、pgvector と Aurora 機械学習のネイティブ統合を使用して感情分析を行う方法を学びましょう。

はい。 Aurora 機械学習 (ML) は ML モデルを SQL 関数として公開するため、標準 SQL を使用して ML モデルを呼び出し、データを渡し、予測をクエリ結果として返すことができます。pgvector では、データベースにベクトル埋め込みを保存する必要があります。そのため、ソーステキストまたは画像データで ML モデルを実行して埋め込みを生成し、埋め込みをバッチで Aurora PostgreSQL に移動する必要があります。

Aurora ML は、これをリアルタイム処理にして、モデルから最新の埋め込みを返す Amazon Bedrock や Amazon SageMaker を定期的に呼び出すことで、Aurora PostgreSQL への埋め込みを最新の状態に保つことができます。

はい。Amazon Aurora データベースを Amazon Bedrock と統合して、生成 AI アプリケーションを強化するための方法が 2 つあります。まず、Amazon Aurora ML では、Aurora MySQL と Aurora PostgreSQL の両方で、SQL から Amazon Bedrock で利用できる基盤モデルに直接アクセスできます。次に、1 回クリックするだけで Aurora を Amazon Bedrock のナレッジベース内のベクトルストアとして設定して、Bedrock から生成された埋め込みを Aurora に保存できます。Amazon Bedrock のナレッジベースは、Aurora PostgreSQL を検索拡張生成 (RAG) などのユースケース向けのベクトルストアとしてサポートしています。こちらのブログと、Amazon Bedrock のナレッジベースとしての Aurora PostgreSQL の使用に関するドキュメントをお読みください。

pgvector を使用した Amazon Aurora PostgreSQL Optimized Reads では、使用可能なインスタンスメモリを超えるワークロードにおいて、ベクトル検索の 1 秒あたりのクエリ数が最大 9 倍に増加します。これは、Optimized Reads で使用可能な、階層化されたキャッシュ機能によって可能になります。この機能は、インメモリデータベースのバッファキャッシュから削除されたデータをローカルストレージに自動的にキャッシュして、そのデータに対する以降のアクセスを高速化します。

Aurora 最適化された読み取り機能で Aurora PostgreSQL のクエリパフォーマンスを向上させる方法については、当社のブログとドキュメントをご覧ください。

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

Amazon Aurora と Amazon SageMaker のゼロ ETL 統合により、運用データベースとアプリケーションからレイクハウスにデータをほぼリアルタイムで取り込むことができます。SageMaker のレイクハウスアーキテクチャを使用すると、データアーキテクチャを変更することなく既存のデータ投資に基づいてオープンレイクハウスを構築し、SQL、Apache Spark、BI、AI/ML ツールなどのお好みの分析ツールやクエリエンジンを使用できます。

Amazon Redshift との Aurora ゼロ ETL 統合は、Aurora MySQL 3.05.2 バージョン (MySQL 8.0.32 と互換) 以上の Aurora MySQL 互換エディションで利用できます。Amazon Redshift との Aurora ゼロ ETL 統合は、Aurora PostgreSQL 16.4 以降用の Aurora PostgreSQL 互換エディションでご利用いただけます。

Amazon SageMaker との Aurora ゼロ ETL 統合は、Aurora MySQL 3.05.0 バージョン (MySQL 8.0.32 と互換) 以上の Aurora MySQL 互換エディションで利用できます。Amazon SageMaker との Aurora ゼロ ETL 統合は、Aurora PostgreSQL 16.4 バージョン以上と Aurora PostgreSQL 17.4 バージョン以上の Aurora PostgreSQL 互換エディションで利用できます。

Aurora ゼロ ETL 統合に対する AWS リージョンの可用性について詳しくは、AWS リージョンおよび Aurora DB エンジン別の Aurora でサポートされる機能をご覧ください。

Amazon Redshift と Amazon SageMaker との Aurora ゼロ ETL 統合により、複雑なデータパイプラインを構築して維持する必要がなくなります。さまざまな Aurora データベースクラスターの複数のテーブルのデータを単一の Amazon Redshift データベースクラスターまたは SageMaker のレイクハウスアーキテクチャに統合し、Aurora の運用データに対してほぼリアルタイムの分析と ML を実行できます。

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

Amazon SageMaker との Amazon ゼロ ETL 統合は、Amazon Aurora Serverless v2 と互換性があります。

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

ゼロ ETL 統合によるデータ変更の継続的な処理は、追加料金なしで利用いただけます。ゼロ ETL 統合の一環として作成された変更データの生成と処理に使用された既存のリソースについての料金はお支払いいただきます。これらのリソースには次のものが含まれます。

• 拡張バイナリログを有効にすることで追加の I/O とストレージが使用される
• データベースをシードするための初期データエクスポートのスナップショットエクスポートコスト
• 複製されたデータを保存するための追加ストレージ
• データ複製処理用の追加コンピューティング
• ソースからターゲットへのデータ移動にかかる AZ 間のデータ転送コスト

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

はい。AWS CloudFormation を使用して、Aurora ゼロ ETL 統合に必要なリソースの設定とデプロイを管理および自動化できます。詳細については、ゼロ ETL 統合を使用した CloudFormation テンプレートをご覧ください。

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

CloudWatch Database Insights の主な利点は次のとおりです。

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

Amazon 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 は、ML を使用して、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 は、これらのメトリクスをモニタリングし、データベースでパフォーマンスの問題が発生していることを検出します。さらに、メトリクスを分析して、何が問題で、何ができるかを通知するように設計されています。

CloudWatch Database Insights は Aurora のリソースとアプリケーションをリアルタイムでモニタリングし、カスタマイズ可能なダッシュボードを通じてデータを表示します。これとは対照的に、Amazon DevOps Guru は CloudWatch メトリクスを分析して、時間の経過に伴うアプリケーションの動作を理解し、異常を検出し、問題解決のための分析情報と推奨事項を提供する機械学習 (ML) サービスです。さらに、DevOps Guru は、AWS Config、AWS CloudFormation、AWS X-Ray など、複数のソースからのデータを分析します。CloudWatch ダッシュボードを使用すると、AWS/DevOps-Guru 名前空間に公開されているメトリクスを介して、DevOps Guru の分析情報を監視できます。これにより、すべての分析情報と異常を CloudWatch コンソールの 1 つの画面で確認できます。

Amazon RDS Performance Insights は、データベースパフォーマンスのチューニングとモニタリングを行う機能であり、データベースの負荷をすばやく評価し、いつどこに措置を講じたらよいかを判断するのに役立ちます。CloudWatch Database Insights は、Performance Insights のすべての機能を継承する新しいデータベースオブザーバビリティ機能であり、フリートレベルのモニタリング、アプリケーションパフォーマンスのモニタリングとの統合、データベースメトリクスとログやイベントの相関付けなどを備えています。

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

Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API AWS リージョンとデータベースバージョンの可用性は、当社のドキュメントに記載されています。

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

Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API は、Aurora グローバルデータベースライターインスタンスをサポートします。

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

Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API は、Aurora 料金ページに記載されている API リクエスト量に基づいて価格設定されます。管理イベントの代わりにアクティビティをログに記録するために AWS CloudTrail データプレーンイベントを使用する、Aurora Serverless v2 および Aurora プロビジョニングされたインスタンス用のデータ API。

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

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

はい、Amazon RDS ブルー/グリーンデプロイは Amazon Aurora Global Database をサポートしていますか? 詳細については、Blue/Green Deployments for Amazon Aurora Global Database ユーザーガイドをご覧ください。

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

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

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

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

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

TLE for PostgreSQL は、バージョン 14.5 以降の Amazon Aurora PostgreSQL 互換エディションでご利用いただけます。TLE は PostgreSQL 拡張機能自体として実装されており、Aurora でサポートされている他の拡張機能と同様に、rds_superuser ロールからアクティブ化できます。

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

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

Aurora をご利用のお客様は、TLE for PostgreSQL を追加料金なしで利用できます。

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 ページで確認できます。