Aurora MySQL 3.14が一般提供：ポスト量子TLSのハイブリッド鍵交換はクライアント側の対応も必要、DELETEにRETURNING追加で予約語に、行サイズの挙動はコミュニティ8.0.46と異なり従来のまま
2026年11月2日、AWSはAurora MySQL 3.14（MySQL 8.0.46互換）の一般提供を発表し、ポスト量子TLS（PQ-TLS）鍵交換を目玉としました。リリースノートによれば、TLS 1.3向けにX25519MLKEM768とSecP256r1MLKEM768のハイブリッドグループが加わり、クライアントが対応する場合にだけネゴシエートされ、そうでなければ従来のグループに戻ります。Aurora_ssl_named_groupステータス変数で確認できます。ほかに3.08以降からのマイナーアップグレード高速化、単一テーブルDELETEのRETURNING（予約語となり同名の識別子はバッククォートが必要）、FTSCacheMemoryUsedメトリクス、ERROR 1118前の行サイズ動作の維持（コミュニティ版と異なる）があります。監査ログは定義者ではなく呼び出したクライアントを記録します。ノートの日付は10月26日で、アップグレード速度やTLSオーバーヘッドの数値はありません。
2026年11月2日、AWSはAmazon Aurora MySQL互換エディション3（MySQL 8.0系）が、Aurora MySQL 3.14としてMySQL 8.0.46に対応したと発表しました。発表によると、このリリースにはコミュニティ版MySQLの修正とAurora独自の改善が含まれ、目玉はポスト量子TLS（PQ-TLS）の鍵交換への対応です。Aurora MySQLが利用できるすべてのAWSリージョンで利用できます。日付には注意が必要で、Auroraのリリースノートは3.14.0を2026-10-26の日付で載せており、「本日から」という発表より約1週間前にエンジンは文書化されていました。
発表は短く、ポスト量子機能が何をするかはリリースノートが説明しています。Aurora MySQLは、TLS 1.3接続で従来の楕円曲線グループに加えて、X25519MLKEM768とSecP256r1MLKEM768という二つのハイブリッド鍵交換グループを追加します。ポスト量子鍵交換に対応するクライアントは自動的に耐量子の共有秘密をネゴシエートし、対応しないクライアントは従来のグループを使い続けます。つまり、サーバー側のスイッチを入れれば有効になるものではなく、クライアントのライブラリもこれらのグループに対応し、TLS 1.3を使う場合にだけ起こります。セッションが何をネゴシエートしたかは、SHOW STATUS LIKE 'Aurora_ssl_named_group'で確認できます。
リリースノートには、運用者にとってもっと重要かもしれない変更があります。バージョン3.08以上から3.14へのマイナーバージョンアップグレードが速く完了するようになり、ライターインスタンスが早くサービスに戻ります。設定変更もオプトインも不要です。単一テーブルのDELETE文にRETURNING句が加わり、別のSELECTなしに削除した行の値を返せます。RETURNINGは予約語になったため、returningという名前の識別子はバッククォートで囲む必要があり、囲まないとアップグレード後に構文解析に失敗します。新しいCloudWatchメトリクスFTSCacheMemoryUsedは、インスタンス上の全テーブルのInnoDB全文検索キャッシュが使うメモリを示します。
互換性についての選択は、よく読む価値があります。コミュニティ版MySQL 8.0.46は特定の種類の列が多いテーブルの扱いを変え、そのようなテーブルの作成が、以前の8.0では成功した同じ文でもERROR 1118「Row size too large」で失敗することがあります。リリースノートによれば、Aurora MySQL 3.14.0は従来の動作を維持するため、これらの文は3.13.0以前と同じように動き続けます。つまりこの点でAurora 3.14はコミュニティ版8.0.46と異なり、両者の間でテストや移行をする場合に重要です。
ノートにはセキュリティ修正も載っています。Advanced Auditログは、SQL SECURITY DEFINERのルーチン内で実行された文について、呼び出したクライアントではなく定義者のユーザーとホストを記録していましたが、今は呼び出したクライアントを記録します。プリペアドステートメントで監査エントリが重複することもなくなりました。書き込み転送を使うセッションでSET ROLE NONEが以前のロールの権限を消さず、拒否されるべき操作が許される可能性があった問題も修正されています。リリースには高重大度のCVE二件と、中重大度のより長いリストの修正も載っています。コンプライアンスのために監査ログを解析しているチームは、アップグレード後にユーザーとホストの値が変わると想定すべきです。
展開について、AWSは、自動マイナーバージョンアップグレードでメンテナンスウィンドウ中にアップグレードでき、AWS Organizationsのアップグレードロールアウトポリシーで複数クラスターに段階的に適用できると述べています。アップグレードはインプレースでも、スナップショットの復元でも行えます。チームにとっての実務的なチェックリストは短く、PQ-TLSが目的ならクライアントライブラリがハイブリッドグループをネゴシエートするか確認し、引用符なしのreturning識別子をコード内で探し、監査ログの利用者を見直し、まず下位環境でテストします。発表とノートには、速くなったアップグレードの速度やTLSのオーバーヘッドの数値はありません。
Sources
FAQ
Aurora MySQL 3.14にアップグレードすれば、接続は自動的に耐量子になりますか？
必ずしもそうではありません。リリースノートはTLS 1.3向けにX25519MLKEM768とSecP256r1MLKEM768のハイブリッドグループを追加しますが、クライアントもポスト量子鍵交換に対応する場合にだけネゴシエートされ、そうでなければ従来のグループが使われます。Aurora_ssl_named_groupで結果を確認できます。
アップグレード前に最も踏みやすい互換性の問題は何ですか？
単一テーブルのDELETEにRETURNING句が加わったため、RETURNINGが予約語になりました。returningという名前の識別子はバッククォートで囲まないと、アップグレード後に構文解析に失敗します。また監査ログは定義者のルーチンで呼び出したクライアントを記録するようになったため、従来のユーザーやホストの値を前提とする解析は見直しが必要です。
Aurora 3.14の行サイズの扱いはコミュニティ版MySQL 8.0.46と同じですか？
同じではありません。コミュニティ版8.0.46は列が多い一部のテーブル作成でERROR 1118「Row size too large」になりますが、リリースノートによればAurora MySQL 3.14.0は8.0.46より前の動作を維持し、3.13.0以前と同様に成功します。両者の間でテストや移行をするときはこの差に注意してください。