Aurora Serverless v1 の仕組み - Amazon Aurora

Aurora Serverless v1 の仕組み

Amazon Aurora では、2 つの異なる DB エンジンモードが用意されており、それぞれが大きく異なる使用モデルに対応しています。

プロビジョニングされた DB エンジンモードは、予測可能なワークロード向けに設計されたモードです。Aurora のプロビジョニングされた DB クラスターを使用する場合は、DB インスタンスクラスのサイズ、およびその他のいくつかの設定オプションについての選択が必要です。例えば、1 つまたは複数の Aurora レプリカを作成して、読み出しのスループットを向上させることができます。ワークロードが変動した場合は、DB インスタンスクラスのサイズを変更して、Aurora レプリカの数を変更できます。プロビジョニングされたモデルは、消費パターンが予想される場合に、前もってキャパシティーを調整できる場合に有効です。

サーバーレス DB エンジンモードは、これとは完全に異なる使用パターン用に設計されたモードです。用途の例としては、データベースの使用負荷が短時間の間だけ増大し、その後に軽いアクティビティが長時間続くか、またはアクティビティがまったく発生しなくなるケースが挙げられます。例えば、散発的にセールスキャンペーンを行う小売ウェブサイト、必要な時点にだけレポートを生成するレポートデータベース、開発やテスト環境、要件が確定していない新規アプリケーションなどが該当します。他にも多くが考えられますが、このようなケースに対してプロビジョニングされたモデルを使用しても、事前にキャパシティーを正しく指定できるとは限りません。また、過剰なプロビジョニングを行い、使用しない容量が生じた場合には、コストが高くなる可能性もあります。

Aurora Serverless v1 を使用すれば、DB インスタンスクラスのサイズを指定せずにデータベースエンドポイントを作成できます。お客様は、Aurora Serverless v1 DB クラスターのキャパシティーに、最小値と最大の範囲を指定するだけです。Aurora Serverless v1 データベースエンドポイントでは、継続的な接続をサポートしリソース間でワークロードを分散するために、ルーターフリートが構成されます。Aurora Serverless v1 では、指定された最小および最大キャパシティーの仕様に基づいた、リソースの自動的なスケーリングが行われます。

ルーターフリートを使用するために、データベースクライアントアプリケーションのコードを変更する必要はありません。Aurora Serverless v1 が自動的に接続を管理します。常にリクエストに対応できる "warm" なリソースプールにより、スケーリングが高速化されています。ストレージと処理は分離されているため、処理ワークロードが終了すると、Aurora Serverless v1 DB クラスターは 0 にスケールダウンできます。Aurora Serverless v1 DB クラスターが 0 にスケーリングされると、ストレージに対してのみ課金されるようになります。

Aurora Serverless v1 アーキテクチャ

次の図は、Aurora Serverless v1 アーキテクチャの概要を示しています。


                  Aurora Serverless v1 アーキテクチャ

データベースサーバーをプロビジョニングして管理する代わりに、Aurora キャパシティーユニット (ACU) を指定します。各 ACU では、約 2 GB (GB) のメモリ、対応する CPU、およびネットワーキングが組み合わせられています。データベースストレージは、自動的に 10 ギビバイト (GiB) から 128 tebibytes (TiB) にスケールします (標準 Aurora DB クラスターのストレージと同じです)。

最小と最大の ACU を指定できます。Aurora の最小キャパシティーユニットは、DB クラスターをスケールダウンできる最小の ACU です。Aurora の最大キャパシティーユニットは、DB クラスターをスケールアップできる最大の ACU です。設定に応じて、CPU 使用率、接続、および使用可能メモリの各しきい値に関するスケーリングルールが、Aurora Serverless v1 により自動的に作成されます。

Aurora Serverless v1 は、AWS リージョンのリソースのウォームプールを管理し、スケーリング時間を最小限に短縮します。Aurora Serverless v1 は、Aurora DB クラスターに新しいリソースを追加する際、ルーターフリートを使用してアクティブなクライアント接続を新しいリソースに切り替えます。いつの時点においても、Aurora DB クラスターで実際に使用している ACU 分のみ課金されます。

Aurora Serverless v1 の自動スケーリング

Aurora Serverless v1 DB クラスターに割り当てられるキャパシティーは、クライアントアプリケーションによって生成された負荷に対応して、シームレスに拡大および縮小されます。ここでは、負荷は CPU 使用率と接続数です。これらのいずれかによって容量が制約されると、Aurora Serverless v1 がスケールアップします。 また、スケールアップすることで解決できるパフォーマンスの問題を検出すると、Aurora Serverless もスケールアップします。

Aurora Serverless で AWS Management Console クラスターのスケーリングイベントを表示できます。自動スケーリングの実行中に、Aurora Serverless v1 により、EngineUptime メトリクスがリセットされます。リセットメトリクス値の値は、シームレススケーリングに問題があったことを意味するものでも、Aurora Serverless が接続を切断したことを意味するものでもありません。これは、新しい容量での稼働時間の開始点に過ぎません。詳細については、「Amazon Aurora を使用した Amazon CloudWatch メトリクスのモニタリング」を参照してください。

Aurora Serverless v1 DB クラスターにアクティブな接続がない場合、容量ゼロ (0 ACU) にスケールダウンできます。詳細については、「Aurora Serverless v1 の一時停止と再開」を参照してください。

スケーリング操作を実行する必要がある場合は、Aurora Serverless v1 は最初にスケーリングポイントを特定しようとします。これは、クエリが処理されていない瞬間です。Aurora Serverless は、 次の理由により、スケーリングポイントを見つけることができない場合があります。

  • クエリの実行時間が長い

  • トランザクションが進行中である

  • 一時テーブルまたはテーブルがロックされている

スケーリングポイントを見つけるときに Aurora Serverless DB クラスターの成功率を上げるには、長時間実行されるクエリや長時間実行されるトランザクションを回避することをお勧めします。スケールブロッキング操作とそれらを回避する方法の詳細については、「Amazon Aurora Serverless を使用するためのベストプラクティス」を参照してください。

デフォルトでは、Aurora Serverless v1 は、スケーリングポイントを 5 分 (300 秒) で見つけようとします。クラスターの作成時または変更時に、別のタイムアウト期間を指定できます。タイムアウト期間は、60 秒~10 分 (600 秒) の間で指定できます。Aurora Serverless が、指定した期間以内にスケーリングポイントが見つからない場合、自動スケーリング操作がタイムアウトします。

デフォルトでは、自動スケーリングがタイムアウトする前にスケーリングポイントを見つけられない場合、Aurora Serverless v1 はクラスターを現在の容量で維持します。[Force the capacity change] (容量の変更を強制する) オプションを選択して Aurora Serverless DB クラスターを作成または変更するときに、このデフォルトの動作を変更できます。詳細については、「キャパシティーの変更のタイムアウトアクション」を参照してください。

キャパシティーの変更のタイムアウトアクション

スケーリングポイントが見つからずに自動スケーリングがタイムアウトした場合、デフォルトでは Aurora は現在の容量を維持します。[容量の変更を強制する] オプションを有効にすることで、Aurora で変更を強制することを選択できます。このオプションは、クラスターを作成するときに、[Create database] (データベースの作成) ページの [Autoscaling timeout and action] セクションで使用できます。

  • [ ] 容量を強制的に変更する – デフォルトでは、このオプションは選択解除されています。スケーリングポイントが見つからずにスケーリング操作がタイムアウトした場合に Aurora Serverless DB クラスターの容量を変更しないようにするには、このオプションをオフのままにします。

  • [X] 容量を強制的に変更する – このオプションを選択すると、Aurora ServerlessDB クラスターを使用して、スケーリングポイントがない場合でも、容量変更を強制します。このオプションを有効にする前に、これを選択することでどのような結果になるかに注意してください。

    • 処理中のトランザクションはすべて中断され、次のエラーメッセージが表示されます。

      Aurora MySQL 5.6ERROR 1105 (HY000): The last transaction was aborted due to an unknown error. Please retry.

      Aurora MySQL 5.7ERROR 1105 (HY000): The last transaction was aborted due to Seamless Scaling. Please retry.

      このトランザクションは、Aurora Serverless v1 DB クラスターが利用できるようになり次第、再送信できます。

    • 一時テーブルとロックへの接続は削除されます。

注記

アプリケーションが切断された接続または不完全なトランザクションから回復できる場合にのみ、[強制] オプションを選択することをお勧めします。

Aurora Serverless DB クラスターを作成するときに AWS Management Console で行った選択は、SecondsBeforeTimeout および TimeoutActionプロパティの ScalingConfigurationInfo オブジェクトに格納されます。クラスターを作成すると、TimeoutAction プロパティの値は次のいずれかの値に設定されます。

  • RollbackCapacityChange - この値は、[Roll back the capacity change] (容量の変更をロールバックする) オプションを選択したときに設定されます。これがデフォルトの動作です。

  • ForceApplyCapacityChange - この値は、[Force the capacity change] (容量の変更を強制する) オプションを選択したときに設定されます。

次に示すように、describe-db-clusters Aurora Serverless コマンドを使用して、既存の AWS CLI DB クラスターでこのプロパティの値を取得できます。

Linux、macOS、Unix の場合:

aws rds describe-db-clusters --region region \ --db-cluster-identifier your-cluster-name \ --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Windows の場合:

aws rds describe-db-clusters --region region ^ --db-cluster-identifier your-cluster-name ^ --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

例として、米国西部 (北カリフォルニア) リージョンにある、west-coast-sles という名前の Aurora Serverless v1 DB クラスターに対するクエリとその応答を次に示します。

$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}' [ { "ScalingConfigurationInfo": { "MinCapacity": 1, "MaxCapacity": 64, "AutoPause": false, "SecondsBeforeTimeout": 300, "SecondsUntilAutoPause": 300, "TimeoutAction": "RollbackCapacityChange" } } ]

応答が示すように、この Aurora Serverless v1 DB クラスターはデフォルト設定を使用しています。

詳細については、「Aurora Serverless v1 DB クラスターの作成」を参照してください。Aurora Serverless v1 を作成した後、タイムアウトアクションやその他のキャパシティー設定はいつでも変更できます。この方法については、「Aurora Serverless v1 DB クラスターの変更」を参照してください。

Aurora Serverless v1 の一時停止と再開

Aurora Serverless v1 DB クラスターでは、アクティビティなしの状態が一定時間継続した場合に、一時停止させるような設定が可能です。DB クラスターを一時停止するまでのアクティビティなしの時間を指定します。このオプションを選択すると、デフォルトの非アクティブ時間は 5 分ですが、この値は変更できます。これは任意の設定です。

DB クラスターを一時停止すると、コンピューティングまたはメモリのアクティビティが完全に停止し、ストレージに対してのみ課金されます。Aurora Serverless DB クラスターの一時停止中にデータベース接続がリクエストされると、DB クラスターは自動的に再開して接続リクエストに対応します。

DB クラスターがアクティビティを再開すると、Aurora がクラスターを一時停止したときと同じ容量になります。ACU の数は、クラスターを一時停止する前に Aurora がスケールアップまたはスケールダウンした程度によって異なります。

注記

DB クラスターを一時停止してから 7 日間を超えると、DB クラスターはスナップショットからバックアップされる場合があります。この場合、接続要求がある場合、Aurora は DB クラスターをスナップショットから復元します。

パラメータグループと Aurora Serverless v1

Aurora Serverless v1 DB クラスターの作成時に、特定の Aurora DB エンジンと、それに関連する DB クラスターパラメータグループを選択します。プロビジョニングされた Aurora DB クラスターとは異なり、Aurora Serverless DB クラスターには単一の読み取り/書き込み DB インスタンスがあり、DB クラスターパラメータグループで構成されているだけで、— 個別の DB パラメータグループはありません。自動スケーリング中、Aurora Serverless は、容量の増減に対してクラスターが最適に機能するように、パラメータを変更できる必要があります。したがって、Aurora Serverless DBクラスターでは、特定のDBエンジンタイプのパラメータに加える可能性のある変更の一部が適用されないことがあります。

例えば、Aurora PostgreSQL–ベースAurora Serverlessの DB クラスターは、クエリプラン管理のためにプロビジョンド Aurora PostgreSQL DB クラスターで使用される可能性のある apg_plan_mgmt.capture_plan_baselines とその他のパラメータを使用できません。

CLI コマンドの describe-engine-default-cluster-parameters を使用し AWS リージョンに対しクエリすることで、さまざまな Aurora DB エンジンのデフォルトパラメータグループのデフォルト値のリストを取得できます。--db-parameter-group-family オプションに使用できる値は次のとおりです。

Aurora MySQL 5.6

aurora5.6

Aurora MySQL 5.7

aurora-mysql5.7

Aurora PostgreSQL 10.12 (以降)

aurora-postgresql10

AWS CLI アクセスキー ID と AWS シークレットアクセスキーを使用して AWS を設定し、AWS コマンドを使用する前に AWS CLI リージョンを設定することをお勧めします。CLI 設定にリージョンを指定すると、コマンドの実行時に --region パラメーターを入力する手間が省けます。AWS CLI の設定の詳細については、AWS Command Line Interface ユーザーガイド の「設定の基本」を参照してください。

次の例では、Aurora MySQL 5.6 のデフォルトの DB クラスターグループからパラメータのリストを取得します。

Linux、macOS、Unix の場合:

aws rds describe-engine-default-cluster-parameters \ --db-parameter-group-family aurora5.6 --query \ 'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \ --output text

Windows の場合:

aws rds describe-engine-default-cluster-parameters ^ --db-parameter-group-family aurora5.6 --query ^ "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^ --output text

Aurora Serverless v1 のパラメータ値の変更

DB パラメータグループおよび DB クラスターパラメータグループを使用する で説明したように、デフォルトのパラメータグループの値は、そのタイプ(DBクラスタパラメータグループ、DBパラメータグループ)に関係なく、直接変更することはできません。代わりに、Aurora DB エンジンのデフォルトの DB クラスターパラメータグループに基づいてカスタムパラメータグループを作成し、そのパラメータグループの設定を必要に応じて変更します。例えば、Aurora Serverless DB クラスターの設定の一部を変更して、クエリをログに記録したり、DB エンジン固有のログを Amazon CloudWatch にアップロードしたりできます。

カスタム DB クラスターパラメータグループを作成するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [パラメータグループ] を選択します。

  3. [パラメータグループの作成] をクリックして、パラメータグループの詳細ペインを開きます。

  4. Aurora Serverless v1 DB クラスターに使用する DB エンジンに適切なデフォルト DB クラスターグループを選択します。必ず次のオプションを選択してください。

    1. [パラメータグループファミリ] で、選択した DB エンジンに適したファミリを選択します。選択内容の名前には、aurora- プレフィックスが含まれていることを確認してください。

    2. [Type] で、[DB Cluster Parameter Group] を選択します。

    3. [グループ名] と [説明] に、ご自身や、Aurora Serverless v1 DB クラスターとそのパラメータを操作する必要がある他のユーザーにとって、わかりやすい名前を入力します。

    4. [Create] を選択します。

カスタム DB クラスターパラメータグループが、お使いの AWS リージョンで使用できる、パラメータグループのリストに追加されます。新しい Aurora Serverless DB クラスターを作成するときにカスタム DB クラスターパラメータグループを使用できます。また、カスタム DB クラスターパラメータグループを使用するように既存の Aurora Serverless DB クラスターを変更できます。ご使用の Aurora Serverless DB クラスターがカスタム DB クラスターパラメータグループの使用を開始したら、AWS Management Console または AWS CLI を使用して動的パラメータの値を変更できます。コンソールを使用して、次のスクリーンショットに示すように、カスタム DB クラスターパラメータグループの値をデフォルトの DB クラスターパラメータグループと比較した値を並べて表示することもできます。


          Aurora MySQL 用の CloudWatch Logs、および Aurora PostgreSQL の Aurora Serverless v1 DB クラスターに公開されたログ

アクティブな DB クラスターのパラメータ値を変更すると、Aurora Serverless は、パラメータの変更を適用するために、シームレスなスケーリングを開始します。Aurora Serverless DB クラスターは「一時停止」状態にあり、変更を行うことができるように再開してスケーリングを開始します。パラメータグループ変更のスケーリング操作は常に容量の変更を強制するため、スケーリング期間中にスケーリングポイントが見つからない場合、パラメータを変更すると接続が切断される可能性があることに注意してください。

Aurora Serverless v1 のログ記録

デフォルトでは、Aurora Serverless のエラーログが有効になっており、Amazon CloudWatch に自動的にアップロードされます。カスタム DB クラスターパラメータグループで設定パラメータを有効にすることにより、Aurora Serverless DB クラスターに Aurora データベースエンジン固有のログを CloudWatch にアップロードさせることもできます。次に、Aurora Serverless DB クラスターは使用可能なすべてのログを Amazon CloudWatch にアップロードします。CloudWatch を使用して、ログデータの分析、アラームの作成、およびメトリクスの表示を行うことができます。

Aurora MySQL については、次のログを有効にして、Aurora Serverless DB クラスターから Amazon CloudWatch に自動的にアップロードすることができます。

Aurora MySQL 説明

general_log

一般ログを作成します。オンにするには、1 に設定します。デフォルトはオフ (0) です。

log_queries_not_using_indexes

インデックスを使用しないスロークエリログにクエリを記録します。デフォルトはオフ (0) です。このログを有効にするには、1 に設定します。

long_query_time

高速実行クエリがスロークエリログに記録されないようにします。0 から 31536000 までの浮動小数点数に設定できます。デフォルトは 0 (アクティブではない) です。

server_audit_events

ログにキャプチャするイベントのリスト。サポートされている値は CONNECTQUERYQUERY_DCLQUERY_DDLQUERY_DMLTABLE です。

server_audit_logging

この値を 1 に設定すると、サーバー監査ログ記録がオンになります。これをオンにしている場合は、CloudWatch に送信する監査イベントを、server_audit_events パラメータにリストアップすることで指定できます。

slow_query_log

スロークエリログを作成します。スロークエリログをオンにするには、1 に設定します。デフォルトはオフ (0) です。

詳細については、「Amazon Aurora MySQL DB クラスターでの高度な監査の使用」を参照してください。

Aurora PostgreSQL については、Aurora Serverless DB クラスターで次のログを有効にして、Amazon CloudWatch に通常のエラーログとともに自動的にアップロードすることができます。

Aurora PostgreSQL 説明

log_connections

デフォルトで有効になっており、変更できません。これは、すべての新しいクライアント接続の詳細をログに記録します。

log_disconnections

デフォルトで有効になっており、変更できません。クライアントの切断をすべてログに記録します。

log_lock_waits

デフォルトは 0 (オフ) です。ロック待機をログに記録するには、1 に設定します。

log_min_duration_statement

ステートメントがログに記録されるまでに実行される最小時間 (ミリ秒単位)。

log_min_messages

ログに記録するメッセージレベルを設定します。サポートされている値は debug5debug4debug3debug2debug1infonoticewarningerrorlogfatalpanic です。パフォーマンスデータを postgres ログに記録するには、値を debug1 に設定します。

log_temp_files

指定されたキロバイト (KB) を超える一時ファイルの使用を記録します。

log_statement

ログに記録される特定の SQL ステートメントを制御します。サポートされている値は noneddlmodall です。デフォルトは none です。

Aurora Serverless DB クラスターの Aurora MySQL 5.6、Aurora MySQL 5.7、または Aurora PostgreSQL のログを有効にすると、CloudWatch でログを表示できます。

Amazon CloudWatch を使用して Aurora Serverless v1 ログを表示する

Aurora Serverless v1 は DB クラスターのカスタムパラメータグループで有効になっているすべてのログを Amazon CloudWatch に自動的にアップロード (公開) します。ログの種類を選択または指定する必要はありません。ログのアップロードは、ログ設定パラメータを有効にするとすぐに開始されます。後でログパラメータを無効にすると、それ以降のアップロードが停止します。ただし、既に CloudWatch に公開されているすべてのログは、削除するまで残ります。

CloudWatch と Aurora MySQL ログの使用の詳細については、「Amazon CloudWatch でログイベントをモニタリングする」を参照してください。

CloudWatch と Aurora PostgreSQL の詳細については、「Amazon CloudWatch Logs への Aurora PostgreSQL ログの発行」を参照してください。

Aurora Serverless DB クラスターのログを表示するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ご利用の AWS リージョンを選択します。

  3. [ロググループ] を選択します。

  4. リストから Aurora Serverless DB クラスターのログを選択します。エラーログの命名パターンは、次に従います。

    /aws/rds/cluster/cluster-name/error

例えば、次のスクリーンショットでは、「western-sles」という名前の Aurora PostgreSQL Aurora Serverless DB クラスターに対して公開されたログのリストを見つけることができます。また、Aurora MySQL Aurora Serverless DB クラスター「west-coast-sles」のリストもいくつか見つけることができます。目的のログを選択して、そのコンテンツの探索を開始します。


                    Aurora MySQL 用の CloudWatch Logs、および Aurora PostgreSQL の Aurora Serverless v1 DB クラスターに公開されたログ

Aurora Serverless v1 とメンテナンス

最新の機能、修正、セキュリティ更新の適用など、Aurora Serverless v1 DB クラスターのメンテナンスは自動的に実行されます。プロビジョニングされた Aurora DB クラスターとは異なり、Aurora Serverless にはユーザーが設定可能なメンテナンスウィンドウはありません。ただし、AWS Management Console DB クラスターの [ メンテナンスと バックアップ ] で、メンテナンスウィンドウを Aurora Serverless に表示することができます。次に示すように、メンテナンスが実行される予定日時と、Aurora Serverless DB クラスターで保留されているメンテナンスがあるかどうかが確認できます。


              Aurora Serverless DB クラスターでのメンテナンスウィンドウの例、ユーザー設定不可、保留中のメンテナンスなし

Aurora Serverless は、可能な限り、中断することなくメンテナンスを実行します。メンテナンスが実施される場合、Aurora Serverless DB クラスターは必要な操作を処理するためにキャパシティーをスケールアップします。スケーリングする前に、必要に応じて最大 7 日間、Aurora Serverless はスケーリングポイントを検索します。

Aurora Serverless によりスケーリングポイントが見つけられない場合は、その 1 日の終わりにクラスターイベントが作成されます。このイベントは、保留中のメンテナンスについてと、メンテナンスを実行するためのスケーリングの必要性についてを通知します。通知には、 Aurora Serverless が DB クラスターを強制的にスケーリングを実行できる日付が含まれています。

そのタイミングまで、Aurora Serverless DB クラスターではスケーリングポイントの検索が継続され、TimeoutAction 設定に従った動作が実行されます。つまり、タイムアウト前にスケーリングポイントが見つからない場合、RollbackCapacityChange に設定されているクラスターでは、キャパシティーの変更は放棄されます。また、ForceApplyCapacityChange に設定されている場合は、変更が強制的に実行されます。適切なスケーリングポイント以外で強制される変更と同様に、この変更でもワークロードが中断されることがあります。

詳細については、「キャパシティーの変更のタイムアウトアクション」を参照してください。

Aurora Serverless v1 とフェイルオーバー

Aurora Serverless v1 DB クラスターの DB インスタンスが使用不能になるか、その クラスターがあるアベイラビリティーゾーン (AZ) で障害が発生した場合、Aurora は別の AZ に DB インスタンスを再作成します。この機能は、自動マルチ AZ フェイルオーバーとも呼ばれます。

このフェイルオーバーメカニズムは、Aurora のプロビジョニングされたクラスターでのフェイルオーバーよりも時間がかかります。Aurora Serverless v1 のフェイルオーバー時間は、対象の AWS リージョン内での、他の AZ の需要や利用可能な容量によって変動するため、現在定義されていません。

Aurora では、コンピューティングキャパシティーとストレージは分離されるため、クラスターのストレージボリュームは複数の AZ に分散されます。停止が DB インスタンスまたは関連する AZ に影響する場合でも、データは引き続き利用することができます。

Aurora Serverless v1 とスナップショット

Aurora Serverless v1 クラスターでは、クラスターボリュームは常に暗号化されます。暗号化キーは選択できますが、暗号化を無効にすることはできません。Aurora Serverless v1 クラスターのスナップショットをコピーまたは共有するには、独自の AWS KMS key を使用してスナップショットを暗号化します。詳細については、「DB クラスターのスナップショットのコピー」を参照してください。暗号化と Amazon Aurora の詳細については、「Amazon Aurora リソースの暗号化」を参照してください。