AWSは2025年後半から、ALB・NLB・KMS・ACM・CloudFront・Secrets Managerで、ML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism、NISTが標準化した耐量子暗号の鍵交換方式）をTLSのハイブリッド鍵交換に組み込む対応を進めている[1][2][3][4]。CloudFrontは既存のセキュリティポリシーに自動適用されるのに対し、ALBとNLBは新しいポリシーへの明示的な切替が必要になる。この「デフォルトかどうか」の違いが、インフラ運用チームの実務上の優先順位を左右する。RSA・ECCを2030年前後に廃止していく業界全体の方針はすでに広く知られているが、AWS環境で具体的に何をどの順番で動かすべきかは別の問題である。本稿はAWSが公開している移行計画の枠組みに沿って、ロードバランサー・鍵管理・証明書・VPNアプライアンスの見直し順序を整理する。
予備知識
- 耐量子暗号（PQC）: 将来の量子コンピュータでも解読が困難とされる暗号方式。ML-KEMはNISTが標準化した鍵交換方式
- ハイブリッド鍵交換: 従来方式（ECC等）と耐量子方式を組み合わせてTLSの鍵を作る方法。どちらかが破られても安全性が残る
- TLSセキュリティポリシー: ロードバランサー等で使う暗号方式の組み合わせを定義した設定。ポリシー名を切り替えて適用する
- HSM: 暗号鍵を安全に保管・演算する専用ハードウェア。オンプレミス機器は各ベンダーの対応待ちになりやすい
同分野を体系的に扱う関連書。
AWSが動かした主要サービス、その足並みは一様ではない
AWSのML-KEM対応は、CloudFrontの自動適用と、ALB/NLB・KMS/ACM/Secrets Managerの明示的対応が必要な部分に分かれる。CloudFrontはクライアントとエッジ間のTLS接続で、既存の全セキュリティポリシーがハイブリッドPQ鍵確立に対応済みで、追加設定は不要である[3]。一方ALBとNLBは、2025年11月に新しいPQ-TLSセキュリティポリシー（ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09、FIPS要件はFIPS-PQ-2025-09）を追加した段階で、既存リスナーには未適用のままである[2]。これらのポリシーはSecP256r1MLKEM768、SecP384r1MLKEM1024、X25519MLKEM768のハイブリッド鍵交換をサポートし、TLS 1.2のみの旧クライアントとの互換性も保つ[2]。KMS・ACM・Secrets Managerも非FIPSエンドポイントでML-KEMのハイブリッド鍵合意に対応したが、効果が出るかはクライアントSDKやエージェントのバージョン次第である[1][4]。
| サービス | ML-KEM対応状況 | デフォルト適用か | 運用チームの対応 |
|---|---|---|---|
| CloudFront | 全ポリシーでハイブリッドPQ鍵確立に対応[3] | デフォルト有効 | 対応不要 |
| ALB | PQ-TLS専用の新ポリシーを追加[2] | 非デフォルト | ポリシーを手動変更 |
| NLB | 同上[2] | 非デフォルト | ポリシーを手動変更 |
| KMS | 非FIPSエンドポイントでML-KEM対応[1] | 対応済み、クライアント依存 | SDK更新確認 |
| ACM | 同上[1] | 同上 | クライアント更新 |
| Secrets Manager | Agent/Lambda拡張/SCPで対応[1][4] | 対応版はデフォルト有効 | Agent 2.0.0以降へ更新 |
Azure Storage GPv1（General Purpose v1、汎用ストレージアカウント旧バージョン）が2026年10月13日に廃止される。Azureでストレージアカウントを持つ組織は、この期日までにGPv2（General […]
なぜALB/NLBの切替が最優先の実務判断になるのか
ALBとNLBはインターネットに面した接続点であり、暗号化通信を今のうちに収集し将来の量子コンピュータで復号する攻撃の主な標的になる。CloudFrontと違い、ALB/NLBは利用者が能動的にポリシーを切り替えない限り旧来のRSA/ECC単独の鍵交換のままになる。切替コストも無視できる範囲に収まっている。AWSの計測では、古典鍵交換からハイブリッドPQ鍵交換への切替でハンドシェイク時に約1600バイトの追加データ転送と、約80〜150マイクロ秒の追加処理時間が発生するとしている[1]。CloudFront・S3・KMSのような大規模サービスでもスループットやレイテンシへの有意な影響は確認されていない[1]。性能面の懸念よりも、切替作業を後回しにするリスクの方が実務上は大きい。
2026年6月10日、AWSが新世代ARMプロセッサーを搭載したEC2インスタンス「M9g」と「M9gd」をGA（一般提供）として発表した[1]。Graviton5（グラビトン5）はAWSが独自設計したCPUの第5世代で、192コアを最大[…]
HSM・証明書チェーン・VPNアプライアンスはどの順序で見直すか
AWSは移行計画を四つのワークストリームに分け、公開エンドポイントの機密性確保を最優先、署名・認証局まわりを次点、セッション認証の刷新を最後に置いている。順序は、第一に既存システムの棚卸し、第二に公開エンドポイントの機密性確保（ALB/NLB/CloudFront/KMS/ACM/Secrets Manager）、第三に署名・認証局の耐量子化（KMSとPrivate CAへのML-DSA導入）、第四にセッション認証の刷新である[1]。これをAWS環境に当てはめると、まずALB/NLBのTLSリスナーをPQ-TLSポリシーに切り替え、次にKMS/ACM/Secrets Managerと通信するSDK・エージェントを最新化する作業が先に来る。AWS Private CAはすでにML-DSA署名に対応しており、社内認証局の証明書チェーン更新の選択肢になる[1]。オンプレミスのHSMアプライアンスやVPN機器、自社実装のTLSライブラリはAWSの管理範囲外であり、各ベンダーのロードマップを個別に確認する必要がある。
CRYSTALS-Kyber（ML-KEM標準化前のドラフト実装）への対応は2025年中で終了し、2026年中に全AWSサービスエンドポイントから削除される予定である[1]。Kyberを暫定運用している場合は、削除時期までにML-KEMへの切替を終える必要がある。
⚠️ 結論：Sora 2（OpenAI）は提供終了しました Web版・アプリ版：2026年4月26日に提供終了（OpenAI公式ヘルプの案内）。 API：2026年9月24日に終了予定。 これ[…]
よくある質問（FAQ）
Q1. ALBのPQ-TLSポリシーへの切替で既存クライアントとの互換性は失われるか。
A. 失われない。ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09はハイブリッドPQ鍵交換対応クライアントに加え、TLS 1.3のみ・TLS 1.2のみのクライアントとの接続も維持できる[2]。
Q2. CloudFrontは何も設定しなくても量子コンピュータ対策になっているのか。
A. クライアントとエッジ間の接続は、既存の全セキュリティポリシーでハイブリッドPQ鍵確立がデフォルト有効である[3]。ただしエッジからオリジンまでの区間は別途確認が必要である。
Q3. CRYSTALS-Kyberで先行実装した場合、ML-KEMへの再対応は必須か。
A. 必須である。AWSはKyberのサポートを2025年中で終え、2026年中に全サービスエンドポイントから削除するとしている[1]。
まとめ
AWSのML-KEM対応は、CloudFrontのように自動で有効になる層と、ALB/NLB・KMS/ACM/Secrets Managerのように利用者側の作業が必要な層に分かれる。この違いを把握せず「AWSは対応済み」と判断すると、ロードバランサーの鍵交換だけ旧来のままという事態になりかねない。まず着手すべきは、ALB/NLBのリスナーをPQ-TLSセキュリティポリシーに切り替え、KMS/ACM/Secrets Managerと通信するSDKやエージェントのバージョンを確認することである。CRYSTALS-Kyberで暫定対応している場合は、2026年中の削除期限を踏まえて優先度を上げる必要がある。HSMやVPNアプライアンスなどAWS管理外の機器は、ベンダーごとのロードマップ確認を早めに始めると後工程の遅延を防げる。
