AWS re:Invent 2025 技術者向け重要アップデート速報
2025/11/27
池 文光 | Mankwong Chi
AWS re:Invent 2025 は 12 月 1〜5 日に開催予定で、先週だけでも 100 件を超えるアップデートが公開されています。これらをすべて確認した上で、アナウンスやレポート、UX/UI の変更、また専門性が高すぎる内容を除外し、重要な技術アップデートに絞って要点をまとめました。
本記事の目的は、素早く理解していただけるよう、要点のみに絞って説明することです。詳細は公式ウェブサイトをご確認ください。それでは、分野ごとに簡潔に紹介します。
コンピューティング
[EKS] CloudWatch Network Flow Monitor によるコンテナネットワークの可観測性
過去 EKS にはネットワークフローに関する組み込みの可視化機能がありませんでした。
現在 CloudWatch Network Flow Monitor により、Pod や Service 間のフロー、コンテナ間通信、AZ をまたぐトラフィックまでネイティブに可視化できるようになりました。
Amazon CloudWatch Network Flow Monitor を Amazon EKS に導入したことで、クラスタ内通信だけでなくクラスタ外や AZ 間を跨ぐ通信も含め、Kubernetes のネットワークフローをネイティブかつほぼリアルタイムに可視化できるようになりました。
[EKS] Secrets Store CSI Driver Provider Add-on
新規 Secrets Manager と Parameter Store のシークレットを Pod がマウントできる、aws-secrets-store-csi-driver-provider のマネージドアドオンが追加されました。
これにより、AWS Secrets Manager や AWS Systems Manager Parameter Store に保存しているシークレットやパラメータを、手動でドライバをインストール／管理せずに、Pod 内のファイルとしてマウントできるようになります
[ECR] コンテナイメージ向けアーカイブストレージクラス
過去 ECR では全イメージが Standard 階層 1 種類しかなく、ストレージクラスは存在しませんでした。
現在 ライフサイクルポリシーで使用頻度の低いイメージをアーカイブ階層へ移動でき、より低コストで保持できます。
長期間保持する必要がある古いイメージや利用頻度の低いイメージを低コストで保存できるようになる点です。アーカイブされたイメージは標準階層より安価なストレージ料金が適用され、リポジトリの容量を効率よく管理できます。またライフサイクルポリシーで「最終プルからの経過日数」「タグ数」などを条件に自動でアーカイブへ移行できるため、手動で整理する手間を減らせます。
[ECR] 自動コンテナイメージ署名
過去 イメージは未署名または手動署名が多く、改ざん検出が難しい状況でした。
現在 プッシュ時にイメージへ自動署名され、追加の手順なしで完全性と真正性が保証されます。
Amazon ECR に自動コンテナイメージ署名が導入されたことで、イメージをプッシュするだけで AWS Signer による署名が自動で付与されるようになりました。これにより、手動で署名を行う手間が不要になり、イメージの真正性と完全性が保証されるようになります。
[ECS] Managed Instances のスケールイン遅延設定
過去 スケールインのタイミングは固定で、ECS のみが制御していました。
現在 0〜60 分の遅延を設定可能となり、アイドルインスタンスのスケールインを無効化する場合は -1 が利用できます。
ECS Managed Instances におけるスケールイン遅延設定の追加は、コスト効率と運用の安定性の両方に貢献します。新しい scaleInAfter 設定（0〜60分 または -1）により、インスタンスがアイドル状態になっても即座に削除されず、一定時間キープすることで、短期的な負荷変動にも柔軟に対応できます。これにより、頻繁なインスタンス起動／終了によるオーバーヘッドや起動遅延が減り、コスト・パフォーマンス・可用性のバランスを改善できます。
[ECS] Express Mode によるシンプルな Web アプリデプロイ
新規 ドメイン名、HTTPS、ALB ルーティング、スケーリングを含む自動構成済みの ECS 環境を提供し、コンテナイメージから迅速にデプロイできます。
Amazon ECS Express Mode によってコンテナイメージだけを指定すれば、すぐに HTTPS／ALB／ロードバランサー／スケーリング対応の Web アプリ環境を自動構築できるようになりました。
[Lambda] テナントレベル隔離モード
過去 Lambda は関数単位の隔離で、同じ関数内のテナントがウォーム環境を共有する可能性がありました。
現在 テナント ID ごとに専用の環境プールが割り当てられ、テナントごとに完全に隔離されます。
AWS Lambda に “テナント分離モード” が導入され、同じ Lambda 関数を使っていてもテナントごとに完全に分離された実行環境で処理できるようになりました。これによりマルチテナント SaaS などでテナント間のメモリやローカルストレージ共有によるデータ漏洩リスクを排除し、セキュリティ要件の厳しい環境にも対応しやすくなります。
[EC2] AMI 系譜の完全可視化
新規 リージョンや世代を跨いだ AMI 系譜を完全に表示でき、ガバナンス、セキュリティ、コンプライアンス用途での追跡が容易になりました。
過去は手動タグ付けやスクリプト管理が必要だった AMI の派生関係追跡が自動化され、どの AMI がどこから派生したかを確実に把握できるようになりました。これにより社内のガバナンス、セキュリティ、コンプライアンスの観点で AMI の由来と流通を明示化でき、特に脆弱性が報告された過去の AMI をまとめて追跡・無効化するのが容易になります。
[EC2 / ASG] ルートボリュームのホットスワップ
過去 ルートボリュームの修正や更新には、インスタンス停止または完全な交換が必要でした。
現在 稼働中のインスタンスまたは ASG リフレッシュ中でもルート EBS ボリュームをホットスワップでき、インスタンスを停止せずに継続稼働できます。
Amazon EC2 / ASG において、ルート EBS ボリュームを停止やインスタンス入れ替えなしで差し替えできるようになりました。
[Braket] QPU の支出上限設定
過去 QPU 単位の利用上限は存在しませんでした。
現在 デバイス単位で支出上限を設定でき、上限を超えるタスクは自動的に拒否されます。
[EC2 Image Builder] Lambda と Step Functions の統合
過去 Image Builder のワークフローで Lambda や Step Functions は実行できませんでした。
現在 Pre-Build、Build、Post-Build の全ステージで Lambda と Step Functions が利用可能となりました。
EC2 Image Builder が AWS Lambda および AWS Step Functions とネイティブ統合されたことで、イメージ作成ワークフローの各ステージ（Pre-Build／Build／Post-Build）でカスタム処理や複数ステップのオーケストレーションを簡単に組み込めるようになりました。
ネットワーキング
[PrivateLink] AWS マネージドサービスのクロスリージョン PrivateLink サポート
過去 PrivateLink を使った AWS サービスアクセスは同一リージョン内に限定されていました。
現在 あるリージョンに Interface VPC Endpoint を作成し、別リージョンの AWS マネージドサービスへプライベートにアクセスできます。
このアップデートによって、異なるリージョン間にある Amazon ECR や Amazon S3 などの AWS 管理サービスを、インターフェース VPC エンドポイント経由でプライベートかつセキュアに利用できるようになりました。
[WAN] 伝播制御のためのルーティングポリシー
過去 WAN 全体へルートが広く伝播され、細かな制御ができませんでした。
現在 特定ルートの許可または却下、match–action ルールによる伝播制御が可能になりました。
ルートの許可／拒否や match-action を設定できるようになったことで、不要な経路が世界中の WAN に広がることを防ぎ、セキュリティリスクと運用事故の両方を減らせます。さらに、誤った経路選択（遠回り、望まないリージョン経由など）を防止できるため、レイテンシの悪化やトラフィックループなどのネットワーク障害も回避できます。
[S2S VPN] VPN トンネル向け BGP ロギング
過去 IKE/IPSec トンネルイベントのみがログ対象でした。
現在 BGP セッション状態、ルーティング更新、エラーも CloudWatch に記録されます。
AWS Site-to-Site VPN が BGP ロギングに対応したことで、これまでブラックボックスになりがちだった BGP セッションの確立失敗、経路揺らぎ、ルート広告の問題、経路撤回 といったネットワーク障害の原因を CloudWatch Logs で追跡できるようになりました。これにより、VPN が切れる／ルートが消える／フェイルオーバーが期待通り動かない、といった問題を迅速に特定でき、運用時間の削減と信頼性向上につながります。
[CloudFront] エッジロケーションメタデータへのアクセス
過去 どの Edge POP や Regional Edge Cache が処理したか、関数から参照できませんでした。
現在 request.metadata を使用してエッジロケーションや REC の情報へアクセスできます。
エッジロケーションの情報を関数側で参照できることで、地理的ルーティング最適化、A/B テスト、キャッシュヒット率改善、特定エッジのみで起きる問題の切り分けといった用途に活用できるようになります。CloudFront の挙動を場所ごとに把握し、高速化と障害解析の両方がより精密に行えるようになります。
[CloudFront] Raw Query String の参照
過去 関数が受け取れるのはパース後のクエリ文字列のみで、順序や重複、特殊エンコード情報は失われていました。
現在 request.rawQueryString により、ビューアが送信した生のクエリ文字列をそのまま取得できます。
生のクエリ文字列を取得できることで、署名検証・セキュリティチェック・キャッシュキー最適化・API の厳密なパラメータ判定といった処理が CloudFront Functions 側で破綻なく実行できます。パース時に失われていた 順序・重複・エンコードの違い を正確に保持したまま判定できるため、CDN レイヤーでの高度なルーティングや攻撃検知、防御ロジックが組めるようになる のが大きな利点です。
[CloudFront] 高度な Origin Override と SNI 制御
過去 オリジン切り替えは可能でしたが、TLS 設定や SNI の細かな制御はできませんでした。
現在 CloudFront Functions 内でオリジン設定やハンドシェイク時の SNI をカスタマイズできます。
Amazon CloudFront での「高度なオリジンオーバーライドと SNI 制御」機能によって、エッジ側関数内でオリジン設定を動的に上書きできるようになりました。これにより、TLS／SNI を含む SSL ハンドシェイク時の振る舞いまでカスタマイズ可能となり、マルチテナント構成や証明書ドメインの異なるサーバへの転送も柔軟に扱えるようになりました。
[TGW] S2S VPN コンセントレーター
過去 サイトごとに 1 つの TGW VPN アタッチメントが必要で、マルチサイト接続には追加機器が必要なこともありました。
現在 最大 100 の低帯域サイトが、1 つの TGW VPN コンセントレーターアタッチメントで接続できます。
[VPC] IPAM アロケーション戦略ポリシー
過去 IPAM は許可制御のためのアロケーションルールのみを提供していました。
現在 アロケーション動作を制御するアロケーション戦略ポリシーが追加されました。
アロケーション戦略ポリシーによって、特定の部署・リージョン・サービスだけが決められた IPAM プールを使うよう強制できるため、誤った EIP 割り当て、勝手な IP 利用、枯渇リスク、アドレス管理の混乱 を防止できます。特に枯渇しやすい パブリック IPv4 の利用を一元統制 できるため、クラウド規模が大きい企業ほど運用コスト削減・セキュリティ確保・コンプライアンス遵守に直結します。
[VPC] NAT Gateway のリージョン単位提供モード
過去 AZ ごとに 1 つの NAT Gateway をパブリックサブネットに配置する必要がありました。
現在 単一のリージョン NAT Gateway がすべての AZ を処理でき、パブリックサブネットも不要になりました。
リージョン NAT Gateway によって、これまで AZ ごとに個別配置していた NAT Gateway を 1 つに統合できるため、VPC 設計が大幅に簡素化されます。パブリックサブネットも不要になり、管理対象が減ることで設定ミスや経路不整合による障害リスクも低下します。また、複数 NAT Gateway を維持する必要がなくなるためコスト削減効果が大きく、特に多 AZ 構成の VPC では運用効率・費用対効果が大きく向上します。
[VPC] 暗号化コントロールパネル
過去 VPC トラフィック暗号化の状態を一元的に確認できる場所がありませんでした。
現在 暗号化状況を表示し、暗号化を強制できる専用パネルが提供されました。
[Route 53] プロファイルが Resolver Query Logging に対応
過去 各 VPC ごとに resolver query logging 設定を個別リンクする必要がありました。
現在 プロファイル配下のすべての VPC が resolver query logging 設定を自動的に利用します。
[Route 53] 辞書ベース DGA 解析を Resolver Firewall に追加
過去 ランダムまたは疑似ランダムな DGA ドメイン、DNS トンネリングのみ検知していました。
現在 辞書ベースの DGA を検知し、人間可読の悪意あるドメインもブロックできます。
オペレーション、マネージメント
[CloudWatch] Database Insights のクロスアカウント・クロスリージョン対応
過去 モニタリングは単一アカウントと単一リージョン内に限定されていました。
現在 複数アカウントや複数リージョンのデータベースを一元的に可視化および分析できます。
これにより、組織全体に点在するデータベースのパフォーマンス状況や問題をまとめて把握でき、運用効率が大幅に向上します。これまでアカウントやリージョンを行き来しながら確認していた CPU・IO・待ち時間などの指標を一元的に比較できるため、異常検知やボトルネックの特定が迅速になり、障害対応の時間短縮や運用コスト削減につながります。また、マルチアカウント戦略を取る企業でも統合的な可観測性を得られ、データベース運用の品質と可視性が全体的に向上します。
[CloudWatch] Application Signals の GitHub 連携
過去 GitHub ベースの可観測性チェックは存在しませんでした。
現在 GitHub Actions から計測や問題検出の事前チェックを実行できます。
Amazon CloudWatch Application Signals が GitHub Actions との連携をサポートするようになりました。そのため DevOps／CI-CD パイプラインの中で SLO 違反や重大なサービスエラーを早期に検知できるようになり、デプロイ直後の品質チェック／問題の事前検出と運用監視がシームレスにつながります。
[CloudWatch] Logs Insights のスケジュールクエリ
過去 クエリは手動実行またはカスタムスクリプトによる自動化が必要でした。
現在 スケジュール実行が可能となり、S3 や EventBridge へ結果を自動送信できます。
[CloudWatch] モバイルアプリ向け RUM（iOS と Android）
過去 RUM は Web アプリケーションのみ対応でした。
現在 iOS と Android のモバイルアプリに対して、パフォーマンスやクラッシュのテレメトリ収集をサポートします。
[Organizations] Aurora と RDS のアップグレード管理
過去 DB のアップグレードはアカウントまたは DB 単位で手動調整が必要でした。
現在 組織全体で Aurora と RDS に対し一括アップグレードポリシーを設定できます。
[Organizations] ダイレクトアカウント転送
過去 アカウント移動には、まずスタンドアロン化する必要がありました。
現在 招待と承認のプロセスで、組織間を直接移動できるようになりました。
[MWAA] サーバレスワークフローモード
過去 MWAA はプロビジョニングされた固定キャパシティ環境が必要でした。
現在 完全サーバレスでオンデマンド実行されるワークフローモードが利用可能です。
Airflow を使うために常時稼働の環境を維持する必要がなくなり、ワークフロー実行時だけリソースを消費するため 大幅なコスト削減 が可能になります。インフラ管理やスケーリング調整も不要となり、Airflow の運用負荷がほぼゼロに近づきます。また、負荷に応じて自動的にスケールするため、大規模処理や突発的なジョブ増加にも柔軟に対応でき、パフォーマンスと可用性も向上します。サーバレス化により、「必要なときにだけ使う Airflow」という最適な運用モデルが実現します。
[CloudFormation] Drift 対応チェンジセット
過去 チェンジセットは設定ドリフトを検知できませんでした。
現在 三方向比較により、デプロイ時にドリフトを検出し修正できます。
ドリフト対応チェンジセットの導入により、テンプレート変更だけでなく実リソースとのずれも含めて三方向で比較できるようになり、意図しない差分をデプロイ前に確実に検知できるようになりました。これによって、手動変更の存在に気付かないままスタックを更新して設定を壊してしまうような事故を防ぎ、IaC 運用の安全性と信頼性が大幅に向上します。
[License Manager] ライセンスアセットグループ
過去 ライセンスをグルーピングする方法がありませんでした。
現在 複数アカウントやリージョンをまたいでライセンスをアセットグループとして整理できます。
[CloudTrail] Data Events Insights
過去 管理イベントのみが分析対象でした。
現在 データイベントも異常検知の対象となり、より広範な分析が可能です。
データ、バックアップ
[Athena] キャパシティ予約の自動スケーリング
過去 DPU キャパシティは固定で、手動スケーリングが必要でした。
現在 キャパシティ予約が利用率に基づいて DPU を自動スケーリングします。
Amazon Amazon Athena が「キャパシティ予約 (Capacity Reservations)」向けに自動スケーリング機能を提供するようになりました。予約した DPU（Data Processing Unit）数を，クエリ負荷に応じて動的に増減させられるようになったことで，手動での容量調整なしにコスト最適化とパフォーマンス保証が両立できるようになりました。
[OpenSearch] サーバレスクラスターのデータプレーンログ取得
過去 CloudTrail は OpenSearch Serverless のコントロールプレーン操作のみ記録していました。
現在 検索・読み取り・書き込みなど、データプレーン操作も CloudTrail にログ記録できます。
[QuickSight] インタラクティブダッシュボードテーブル
過去 ダッシュボードのテーブルはほぼ固定で、閲覧者の操作自由度が限られていました。
現在 閲覧者は並べ替え、再配置、列の表示・非表示、列の固定などをダッシュボード上で直接操作できます。
[KDS] 強化された Fan-Out スケーリング
過去 1 ストリームにつき最大 20 の EFO コンシューマーに制限されていました。
現在 専用スループットを持つ最大 50 の EFO コンシューマーをサポートします。
コンシューマー数が大幅に増えたことで、1つのストリームを複数の分析基盤・処理ワークフロー・監視ツールが同時に高スループットで利用できるようになり、データ活用の幅が一気に広がるのが最大の利点です。その結果、Kinesis ベースのデータ処理基盤をより柔軟・拡張性高く設計でき、ビッグデータやストリーミング分析のワークロードに対応しやすくなります。
[Redshift] Iceberg 書き込み対応
過去 Iceberg テーブルは読み取り専用でした。
現在 Redshift で Iceberg テーブルの作成およびデータ挿入が可能になりました。
[Transfer Family] Web アプリ向け VPC エンドポイント
過去 Web アプリのアクセスはパブリックエンドポイントのみ使用できました。
現在 VPC エンドポイント経由でプライベートかつ制御された Web アプリアクセスが可能になりました。
[S3] 属性ベースアクセス制御（ABAC）
過去 アクセス許可は IAM とバケットポリシーのみで管理されていました。
現在 S3 が ABAC を利用でき、タグ評価に基づいてアクセスを許可できます。
Amazon S3 が属性ベースアクセス制御 (ABAC) に対応したことで、バケットやアクセスポイントのタグを使ってアクセス権限を自動管理できるようになりました。
[DynamoDB] GSI の複数属性コンポジットキー対応
過去 GSI は 1 つのパーティションキー属性と 1 つのソートキー属性のみでした。
現在 最大 4 つのパーティションキー属性と最大 4 つのソートキー属性に対応します。
複数属性をそのまま GSI のキーとして扱えるため、検索条件の拡張や変更にも柔軟に対応でき、アプリケーション側での結合・分解ロジックや不自然なデータ構造が不要になります。その結果、開発負荷低減、バグ発生率の低下、将来的なデータモデルの拡張容易性が向上し、運用全体がよりシンプルで堅牢になります。
[Backup] S3 バックアップ向け低コストウォーム階層
過去 S3 バックアップは Standard 階層にのみ保存されていました。
現在 旧バックアップ向けに低コストの Warm 階層が利用可能です。
[Backup] 論理的エアギャップボールトへの直接バックアップ
過去 エアギャップボールトは標準ボールトからのバックアップコピーのみ受け取れました。
現在 バックアッププランでエアギャップボールトを主要バックアップ先として使用できます。
AI/ML
[Bedrock] Priority & Flex 推論ティアの追加
過去 Standard 推論ティアのみが存在していました。
現在 Priority と Flex ティアが追加され、高速推論または低コスト推論が選べます。
Amazon Bedrock に Priority と Flex の推論ティアが追加されたことで、高速応答が必要なリアルタイム系処理には Priority、コスト効率を優先するバッチや非リアルタイム処理には Flex という使い分けが可能になりました。
[Bedrock] Guardrails にコード生成向けセーフガードを追加
過去 Guardrails はテキストと画像にしか適用されませんでした。
現在 生成コードも対象とする新しいセーフガードが利用できます。
[SageMaker] カタログでのカラムレベルメタデータ拡張
過去 利用できたメタデータはテーブルレベルのみで、ビジネス名称、説明、用語集などに限定されていました。
現在 カラムレベルのメタデータに対応し、カスタムメタデータフォームやリッチテキスト（Markdown）記述も利用できます。
Amazon SageMaker Catalog のカタログ機能が拡張され、カラムレベルでカスタムメタデータフォームとリッチテキストによる説明が利用可能になりました。
[SageMaker] 長時間バックグラウンドセッション
過去 ユーザーがログアウトしたりブラウザを閉じるとセッションは停止していました。
現在 TIP により、最大 90 日間バックグラウンドでセッションを継続できます。
Amazon SageMaker において、バックグラウンドでの長時間セッション (user background sessions, via AWS IAM Identity Center の TIP 機能) が導入され、ノートブックやトレーニング・処理ジョブなどを、ユーザーがログアウトした後でも最長 90日間 実行し続けられるようになりました。
セキュリティ
[Inspector] 組織全体管理
過去 Inspector は各 AWS アカウントごとに個別で有効化と設定が必要でした。
現在 委任管理者が 1 つの組織レベルの Inspector ポリシーを適用すると、すべてのアカウントが自動的に継承します。
[WAF] Web Bot Auth マネージドルールグループ
新規 Web Bot Auth シグネチャを検証し、正当なボットを識別する新しいマネージドルールグループが提供されました。
[IAM] JWT を用いたアウトバウンド Identity Federation
新規 IAM が短期署名付き JWT を発行でき、AWS ワークロードが長期資格情報なしで外部クラウドや SaaS へ認証できます。
この機能により、IAM のロールやユーザーが短期間有効な署名付き JSON Web Token (JWT) を取得できるようになり、その JWT を使ってサードパーティのクラウドサービスや SaaS、自社サービスなど外部サービスへ安全に認証できます。
[GuardDuty] Malware Protection の AWS Backup 対応拡張
過去 Malware Protection は EBS と S3 のみ対応で、AWS Backup は対象外でした。
現在 Malware Protection が AWS Backup（EC2、EBS、S3 バックアップ）をスキャンし、バックアップデータ上のマルウェアも直接検出できます。
その他
[Cost Explorer] コスト異常検知のマネージドモニタリング
過去 アカウントやタグ、コストカテゴリごとに個別のモニターが必要でした。
現在 1 つのマネージドモニターで複数のディメンションをカバーできます。
[Compute Optimizer] EBS 自動化ルール
過去 未使用ボリュームの削除やボリュームタイプのアップグレードは手動対応が必要でした。
現在 スケジュールに基づいて自動化ルールがこれらの操作を実行できます。
[ELB] Network Load Balancer のウェイト付きターゲットグループ
過去 各リスナーは 1 つのターゲットグループしか使用できませんでした。
現在 1 つのリスナーで複数のターゲットグループを使用でき、ウェイト付きルーティングが可能です。
ウェイト付きターゲットグループにより トラフィックを段階的・戦略的に振り分けられるようになり、運用・デプロイの柔軟性が大幅に向上するのがポイントです。具体的には、ターゲットグループごとに割り当て比率を細かく調整できるため、カナリアリリースや段階的移行（Blue/Green）、バックエンドの能力差に応じた負荷分散が容易になります。これにより、リスクを抑えた安全なリリースや、バックエンドの性能に応じた最適なトラフィック配分が可能となり、信頼性とパフォーマンスの両方を改善できます。
[ELB] ALB ターゲットオプティマイザー
過去 ALB は同時リクエスト数が多すぎる場合、ターゲットを過負荷にする可能性がありました。
現在 ターゲットごとに最大同時リクエスト数を設定し、オーバーロードを防止できます。
ターゲットごとに処理できるリクエスト数の上限を設定できるようになったことで、特定のターゲットだけが集中攻撃のように過負荷になって落ちる…という典型的な障害パターンを防げるようになります。これにより、弱いバックエンドや一時的に性能が落ちているターゲットを ALB が自動的に保護し、全体のレスポンス低下や連鎖的な障害を回避できます。
[ASG] インスタンスライフサイクルポリシー
過去 ライフサイクルフックのタイムアウトや失敗は必ずインスタンスの終了に繋がっていました。
現在 マネージド Appium エンドポイントにより、ライブデバイス操作でリアルタイムの確認やデバッグが可能です。
インスタンスライフサイクルポリシーによって、デプロイや起動時処理で問題が起きても、ログ調査・手動修正・再実行などを行ったうえで廃棄・再利用を選択できるため、原因不明のままインスタンスがどんどん消えていく事態を避けられます。結果として、トラブルシューティングがしやすくなり、ローリングアップデートやバッチ投入時のリスク低減、運用の透明性と信頼性向上につながります。
[MQ] RabbitMQ の LDAP 認証対応
過去 RabbitMQ ブローカーは内部アカウントや OAuth 2.0 のみを利用していました。
現在 外部の LDAP ディレクトリを使用してユーザー認証が行えます。
[MediaConnect] MediaConnect ルーター
過去 ライブ映像のルーティングや切り替えには手動のフロー更新やカスタムロジックが必要でした。
現在 Router がライブ映像を動的にルーティングおよび切替し、フローの再構築なしで運用できます。
[API Gateway] REST API のレスポンスストリーミング
新規 REST API がチャンク単位でクライアントへレスポンスデータをストリーミングできるようになりました。
レスポンスストリーミングにより、API の応答性とユーザー体験が大幅に向上するのが最大のメリットです。クライアントは処理が完了するまで待つ必要がなく、データが生成された部分からすぐに受け取り始められるため、長時間かかる処理や大容量データの返却でも体感速度が改善します。また、途中経過を返しながらバックエンド処理を継続できるため、タイムアウトの発生を防ぎやすくなり、安定した API 運用が可能になります。これは特に AI 推論、レポート生成、ETL、検索処理などで大きな効果を発揮します。
[API Gateway] VPC Link の ALB 接続サポート
過去 VPC Link は必ず必要で、NLB にしか接続できませんでした。
現在 VPC Link は依然必要ですが、ALB に直接接続できるようになりました。
この変更により、NLB を中継するための余分なレイヤーが不要になり、ネットワーク構成がシンプルになっただけでなくレイテンシ削減やコスト最適化につながります。また ALB が持つ HTTP/HTTPS の高度な Layer-7 機能（ヘルスチェックやパスベースルーティングなど）をそのまま利用可能になるため、マイクロサービスやコンテナベースアプリケーションの設計がより柔軟になります。