本文へスキップ
AWS DAILY

AWS Daily Report

Lambda MicroVMs x86対応・EKS Auto ModeのPodセキュリティグループ・OpenSearch クロスリージョンDRなど12件の発表

2026年11月12日は、AWS Lambda MicroVMs の x86 アーキテクチャ対応、Amazon EKS Auto Mode での Pod レベルセキュリティグループ、Amazon OpenSearch Service のマネージドクロスリージョンディザスタリカバリなど、運用・セキュリティ・可用性に関わる重要な発表が相次ぎました。Amazon DocumentDB 8.0.3 のポスト量子TLS対応や、AWS Network Firewall の NGFW policy 追加など、セキュリティ強化に関する発表も含まれています。

公開
更新
情報取得

新着情報

12件

この日に掲載した AWS の新着情報

重要な変更

0件

重要度「最重要」「重要」のアップデート

対応要確認

2件

「対応必要」または「確認推奨」の項目

本日の重要ニュース

重要度の高い順に掲載しています。

#01重要度:通常新機能対応不要

Amazon SES がメールアイデンティティ・テナント・設定セットの上限を引き上げ、マルチテナント運用が1アカウントで完結

Amazon SES
要約
Amazon SES でメールアイデンティティ、テナント、設定セットの上限が引き上げられました。複数アカウントに分散していたメールワークロードを1つのアカウントに集約できるようになります。
何が変わったか
  • メールアイデンティティのアカウントあたりの上限が引き上げられました。
  • テナントのアカウントあたりの上限が引き上げられました。
  • 設定セットのアカウントあたりの上限が引き上げられました。
  • AWS Service Quotas コンソールで現在の使用量を確認し、上限引き上げをリクエストできるようになりました。
  • メールアイデンティティ、テナント、設定セットを名前またはステータスで検索できるようになりました。
既存環境への影響
マルチテナントワークロードを運用している顧客は、顧客・ブランド・AIエージェントごとに作成するリソースが増えても、複数アカウントに分散させる必要がなくなります。上限引き上げにより、成長するワークロードを1つのアカウントで管理できます。名前やステータスによる検索機能の追加で、大規模アカウントの運用管理も容易になります。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
対応不要既存環境への強制的な変更はありません。上限引き上げが必要な場合は AWS Service Quotas コンソールからリクエストできます。
#02重要度:通常新機能対応不要

AWS Lambda MicroVMs が x86 CPU アーキテクチャをサポート、既存の x86 アプリをそのまま実行可能に

要約
AWS Lambda MicroVMs が x86 CPU アーキテクチャに対応し、既存の x86 アプリケーションやツール、ソフトウェア依存関係を再コンパイルやポーティングなしに実行できるようになりました。MicroVM イメージ作成時に x86 と Arm(AWS Graviton)を選択できます。
何が変わったか
  • Lambda MicroVMs で x86 CPU アーキテクチャが選択可能になった。
  • MicroVM イメージ作成時に x86 と Arm(AWS Graviton)のいずれかを指定できるようになった。
  • 既存の x86 アプリケーションを再コンパイルやポーティングなしにそのまま実行できる。
  • Arm ワークロードは引き続き AWS Graviton プロセッサ(デフォルト)を使用できる。
既存環境への影響
x86 ベースのワークロードを Lambda MicroVMs 上でそのまま実行できるため、移行コストが削減されます。AI コーディングアシスタント、CI/CD ランナー、インタラクティブ開発環境、脆弱性スキャナーなどのユースケースで x86 アーキテクチャを選択できます。x86 CPU アーキテクチャのサポートは、Lambda MicroVMs が利用可能なすべての AWS リージョンで提供されますが、Asia Pacific (Hong Kong)、Asia Pacific (Malaysia)、Asia Pacific (Thailand)、Europe (Spain) は除外されます。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
対応不要既存の Arm ワークロードへの影響はなく、x86 アーキテクチャの利用は任意です。x86 ワークロードを実行したい場合は、Dockerfile から MicroVM イメージを作成する際に x86 アーキテクチャを選択してください。
#03重要度:通常新機能対応不要

Amazon EKS Auto Mode がPodレベルのセキュリティグループに対応、追加料金なしでKubernetes 1.36以降で利用可能

要約
Amazon EKS Auto Mode がPodに対して個別のEC2セキュリティグループルールを適用できる「Security groups for Pods」をサポートしました。同一ノード上の異なるワークロードに異なるセキュリティグループを割り当てられるため、アプリケーションごとに別のノードプールを作成せずにネットワークレベルの分離が実現できます。
何が変わったか
  • EKS Auto ModeでPodごとに個別のEC2セキュリティグループルールを適用できるようになりました。
  • 同一ノード上の異なるワークロードに異なるセキュリティグループを割り当てられるようになりました。
  • SecurityGroupPolicyリソースを使ってどのPodにどのセキュリティグループを適用するかを定義できます。
  • ポリシーに一致しないPodはノードのセキュリティグループを引き続き使用します。
  • Amazon RDSやAmazon ElastiCacheなどセキュリティグループで接続を認可するリソースへPodから直接アクセスできるようになりました。
  • EKS Auto Modeの一部として追加料金なしで提供されます。
  • Kubernetes 1.36以降を実行するクラスターで利用可能です。
  • EKS Auto ModeがサポートされているすべてのAWSリージョンで利用できます。
既存環境への影響
アプリケーションごとに別のノードプールを用意しなくても、Pod単位でネットワーク分離が実現できるため、クラスター構成をシンプルに保てます。既存のVPCセキュリティグループの仕組みをそのままPodレベルに拡張できるため、RDSやElastiCacheなどへのアクセス制御を統一的に管理できます。追加料金が発生しないため、コストを増やさずにセキュリティ強化が可能です。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
対応不要既存のEKS Auto Modeクラスターへの強制的な変更はありません。Pod単位のネットワーク分離が必要な場合はKubernetes 1.36以降へのアップグレードとSecurityGroupPolicyリソースの設定を検討してください。
#04重要度:通常新機能対応不要

AWS Billing and Cost Management のカスタム請求ビューが AWS Billing Conductor と AWS Billing Transfer のビューをソースとしてサポート開始

AWS Billing Conductor
要約
カスタム請求ビューで AWS Billing Conductor の請求グループビューと AWS Billing Transfer のビューをソースとして利用できるようになりました。複数のビューを1つに統合してフィルターを適用し、Cost Explorer や AWS Budgets などで活用できます。
何が変わったか
  • カスタム請求ビューのソースとして AWS Billing Conductor の請求グループビューが追加された
  • カスタム請求ビューのソースとして AWS Billing Transfer の転送ビューおよび転送ショーバックビューが追加された
  • 複数のソースビューを1つのカスタム請求ビューに統合してフィルターを適用できるようになった
  • 作成したカスタム請求ビューを AWS Resource Access Manager を使って組織内外のアカウントと共有できる
  • 統合されたビューを Cost Explorer、AWS Budgets、Billing and Cost Management コンソールで利用できる
既存環境への影響
AWS Partner として AWS サービスを再販している場合や、組織内で請求グループを使ってプロフォーマ請求を行っている場合に、顧客やグループごとに個別のビューを管理する必要がなくなり、1つの統合ビューで管理できます。財務チームや下流の販売者が自分のアカウント内でデータを扱えるよう、カスタム請求ビューを共有することも可能です。既存のアクセス権限は変更されず、AWS マネージドビューはすでにアクセスできる範囲でのみソースとして利用できます。
利用可能リージョン
東京(ap-northeast-1)
提供中
大阪(ap-northeast-3)
提供中

公式記事の「all AWS Regions」の記載を、東京と大阪にも当てはめています。個別のリージョン一覧は確認していません。

対応が必要か
対応不要既存環境への強制的な変更はありません。チャージバックやショーバックの管理を効率化したい場合は、新しいソースビューを活用したカスタム請求ビューの作成を検討してください。
#05重要度:通常リージョン拡張対応不要

Amazon EC2 G7インスタンスがEurope (London)、Asia Pacific (Mumbai, Sydney)、South America (Sao Paulo)リージョンで利用可能に

要約
NVIDIA RTX PRO 4500 Blackwell Server Edition GPUを搭載したAmazon EC2 G7インスタンスが、Europe (London)、Asia Pacific (Mumbai, Sydney)、South America (Sao Paulo)の各リージョンで新たに利用可能になりました。G6インスタンスと比較してAI推論性能が最大4.6倍、グラフィックス性能が最大2.1倍向上しています。
何が変わったか
  • G7インスタンスがEurope (London)リージョンで利用可能になりました。
  • G7インスタンスがAsia Pacific (Mumbai)リージョンで利用可能になりました。
  • G7インスタンスがAsia Pacific (Sydney)リージョンで利用可能になりました。
  • G7インスタンスがSouth America (Sao Paulo)リージョンで利用可能になりました。
  • G7インスタンスの提供リージョンはUS West (Oregon)、US East (N. Virginia, Ohio)、Europe (London, Spain, Frankfurt, Stockholm)、Asia Pacific (Mumbai, Sydney)、South America (Sao Paulo)となりました。
既存環境への影響
新たに追加されたリージョンのユーザーは、G7インスタンスをAI推論、グラフィックスレンダリング、ビデオトランスコーディング、データアナリティクスなどのワークロードに利用できるようになります。G6インスタンスを使用しているユーザーは、G7インスタンスへ移行することでAI推論性能を最大4.6倍、グラフィックス性能を最大2.1倍向上させることができます。On-Demand、Spot、Savings Plansの各購入オプションが利用可能です。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
対応不要既存環境への強制的な変更はありません。新たに対象リージョンでG7インスタンスを利用したい場合は、AWS Management Console、CLI、またはSDKから起動できます。
#06重要度:通常新機能対応不要

Amazon OpenSearch Service がマネージドなクロスリージョンディザスタリカバリを発表、RPO 1分未満・RTO 20分未満を実現

要約
Amazon OpenSearch Service がマネージドなクロスリージョンディザスタリカバリ機能を提供開始しました。2つのリージョンにドメインを作成し、1回の API 呼び出しまたは AWS Management Console の数ステップでペアリングでき、RPO 1分未満・RTO 20分未満を達成します。
何が変わったか
  • マネージドなクロスリージョンディザスタリカバリ機能が Amazon OpenSearch Service に追加された。
  • 1回の API 呼び出しまたは AWS Management Console の数ステップでプライマリとセカンダリのドメインをペアリングできるようになった。
  • RPO 1分未満・RTO 20分未満のディザスタリカバリが実現できるようになった。
  • 計画的なイベント向けのスイッチオーバー(ゼロデータロス)と、障害時のフェイルオーバー(レプリケーションラグ分のデータロス)の2つの切り替え方式が利用できる。
  • Amazon CloudWatch メトリクスでレプリケーションの健全性とラグを監視できるようになった。
  • マネージドディザスタリカバリに追加料金はなく、セカンダリドメインとクロスリージョンデータ転送の標準料金のみが発生する。
  • OpenSearch 3.7 以降が必要で、カスタマーマネージド AWS KMS キーで暗号化されたドメインもサポートされる。
  • UltraWarm ストレージまたは OpenSearch Optimized インスタンス(OR1 または OR2)を使用するドメインはサポートされない。
既存環境への影響
ミッションクリティカルな検索・AI・分析ワークロードに対して、自前でレプリケーションを構築・維持することなく、厳格な可用性とビジネス継続性の要件を満たせるようになります。セカンダリドメインはプライマリと継続的に同期されるため、障害発生時のデータロスをレプリケーションラグの範囲内に抑えられます。UltraWarm ストレージや OR1・OR2 インスタンスを使用している場合はサポート対象外となるため、利用前に構成の確認が必要です。OpenSearch 3.7 未満のバージョンを使用している場合は、クローンベースのアップグレードで移行できます。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
対応不要新機能のオプトイン型であり、既存環境への強制的な変更はありません。利用するには OpenSearch 3.7 以降が必要なため、古いバージョンを使用している場合はアップグレードの検討が推奨されます。
#07重要度:通常新機能対応不要

Amazon S3 Access Grants が複数 AWS アカウントをまたいだ一括グラント一覧取得に対応

要約
Amazon S3 Access Grants で、複数の AWS アカウントにまたがるすべてのグラントを 1 回の API 呼び出しで取得できるようになりました。ListCallerAccessGrants に新しい InstanceScope パラメータを追加することで実現しています。
何が変わったか
  • ListCallerAccessGrants リクエストに新パラメータ InstanceScope が追加されました。
  • InstanceScope を ALL に設定すると、AWS Resource Access Manager (AWS RAM) 経由で共有されたすべてのインスタンスのグラントを 1 回の呼び出しで取得できます。
  • レスポンスには各グラントを所有するアカウントの情報が含まれます。
  • GetDataAccess で InstanceScope を ALL に設定すると、S3 パスに対応するアカウントを自動的に特定し、そのインスタンスへリクエストをルーティングして認証情報を返します。
  • この機能は S3 Access Grants が利用可能なすべての AWS リージョンで追加コストなしで利用できます。
  • AWS SDK、API、CLI から利用できます。
既存環境への影響
これまで複数アカウントのグラントを確認するには各アカウントを個別にクエリする必要がありましたが、1 回の API 呼び出しで完結するようになります。マルチアカウント環境での S3 データアクセス管理が大幅に簡素化されます。GetDataAccess でも同様に、アクセス先アカウントを手動で特定する手間がなくなります。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
対応不要既存の環境に対する必須の変更はありません。マルチアカウント環境で S3 Access Grants を利用している場合は、新しい InstanceScope パラメータの活用を検討できます。
#08重要度:通常新機能確認推奨

Amazon BedrockのbedRock-runtimeエンドポイントでOpenAIのサイバーセキュリティ特化モデル「Daybreak」が利用可能に

要約
Amazon Bedrockのbedrock-runtimeエンドポイントを通じて、OpenAIのサイバーセキュリティ特化モデル「Daybreak Red: GPT-5.6 Cyber」と「Daybreak Blue: GPT-5.6 Sol」が利用可能になりました。利用にはOpenAIによるDaybreakアクセスへの登録が必要です。
何が変わったか
  • bedrock-runtimeエンドポイントでDaybreak Red: GPT-5.6 CyberおよびDaybreak Blue: GPT-5.6 Solが利用可能になった
  • Daybreak Blueは脆弱性発見、検知エンジニアリング、インシデントレスポンスなどの防御ワークフローに対応する
  • Daybreak Redは脆弱性調査、エクスプロイト再現、緩和策開発などの高度な承認済みタスク向けに設計されている
  • 推論データはモデルのトレーニングに使用されず、OpenAIへのデータ共有のオプトインも不要である
  • モデルはUSおよびGlobalのクロスリージョン推論(CRIS)プロファイルを通じて提供される
  • 利用にはOpenAIのDaybreakアクセスへの登録が必要で、OpenAIまたはAWSアカウントチームへの連絡が必要である
既存環境への影響
セキュリティチームはAmazon Bedrockのbedrock-runtimeエンドポイントを通じてOpenAIのサイバーセキュリティ特化モデルにアクセスできるようになります。Daybreak Blueは防御的なセキュリティワークフローの出発点として、Daybreak Redは高度な脆弱性調査などの承認済みタスクに活用できます。ただし、利用開始にはOpenAIによる事前審査と登録が必要なため、すぐに利用できるわけではありません。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
確認推奨利用を希望する場合はOpenAIまたはAWSアカウントチームに連絡してDaybreakアクセスへの登録を申請し、承認後にAWS側でのアクセス申請を行う必要があります。
#09重要度:通常新機能対応不要

Amazon S3 Tables がサーバーアクセスログに対応、テーブルバケットへのリクエストを詳細記録

要約
Amazon S3 Tables でサーバーアクセスログがサポートされ、テーブルバケットへのリクエストの詳細記録が取得できるようになりました。ログ配信は追加料金なしで利用でき、ログファイルのストレージ料金のみが発生します。
何が変わったか
  • S3 Tables のテーブルバケットに対してサーバーアクセスログを有効化できるようになった
  • ログにはリクエスト元、オペレーション、テーブル名、名前空間、レスポンスステータス、リクエストタイミングが記録される
  • ログは同一アカウント・同一リージョンの汎用バケットに配信される
  • ログ形式は汎用バケット向け S3 サーバーアクセスログと同じスペース区切り形式を採用している
  • Amazon Athena や DuckDB など任意のクエリエンジンで既存のログ分析ワークフローを再利用できる
  • AWS Management Console、AWS CLI、AWS SDK、AWS CloudFormation から有効化できる
  • ログ配信は追加料金なしで、ログファイルのストレージ料金のみ発生する
既存環境への影響
セキュリティ監査やアクセス分析、コスト配賦のためにテーブルバケットへのリクエストを詳細に追跡できるようになります。既存の S3 サーバーアクセスログ分析ワークフローをそのまま流用できるため、導入コストを抑えられます。ログ配信自体に追加料金はかからないため、コストへの影響はログ保存ストレージ分のみです。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
対応不要既存の S3 Tables 環境に対して強制的な変更はありません。セキュリティ監査やアクセス分析が必要な場合は任意で有効化することを検討してください。
#10重要度:通常新機能対応不要

AWS Network Firewall が次世代ファイアウォールポリシー(NGFW policy)を提供開始、ファイアウォールと IPS のルール容量を分離し管理を簡素化

要約
AWS Network Firewall に新しいポリシーモデル「NGFW policy」が追加されました。ファイアウォールルールと IPS ルールの容量を独立させ、deny-by-default のアクセス制御と脅威検知を分離して管理できるようになります。
何が変わったか
  • ファイアウォールルールと IPS ルールがそれぞれ独立したルール容量を持つようになり、互いにトレードオフする必要がなくなりました。
  • ファイアウォールと IPS の保護を組み合わせるのではなく、レイヤーとして重ねる新しいポリシー構造が導入されました。
  • deny-by-default のアクセス制御(承認済みドメインへのトラフィックのみ許可など)をファイアウォールルールで設定できます。
  • AWS および AWS Marketplace パートナーが提供するマネージドルールグループを IPS ルールに利用でき、新たな脅威に応じて自動更新されます。
  • ポリシー間で共有しないルール向けに、事前割り当て不要で容量をオンデマンドで使用できる埋め込みルールグループを作成できます。
  • NGFW policy ではすべてのルールがステートフルで、完全な接続コンテキストで評価されるため、一貫した予測可能なトラフィック処理が実現します。
  • 既存のポリシーは変更なしで引き続き動作し、IPS ルールは後方互換性を維持します。
  • NGFW policy はすべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで追加料金なしで利用できます。
既存環境への影響
既存の Network Firewall ポリシーは変更なしで引き続き動作するため、現在の環境への影響はありません。新しい NGFW policy を採用することで、ファイアウォールと IPS のルール容量が独立し、より多くのルールを柔軟に管理できるようになります。マネージドルールグループの自動更新により、新たな脅威への対応を手動で行う手間が軽減されます。
利用可能リージョン
東京(ap-northeast-1)
提供中
大阪(ap-northeast-3)
提供中

公式記事の「all AWS Regions」の記載を、東京と大阪にも当てはめています。個別のリージョン一覧は確認していません。

対応が必要か
対応不要既存のポリシーは変更なしで動作し続けるため、対応は不要です。新しいポリシーモデルへの移行は任意であり、セキュリティポリシーの簡素化や容量拡張が必要な場合に検討できます。
#11重要度:通常新機能対応不要

Amazon GameLift Servers がゲームセッション配置インサイト機能を提供開始、キューのルーティング診断ログを詳細に取得可能に

要約
Amazon GameLift Servers に Game Session Placement Insights が追加され、ゲームセッションキューのルーティング判断に関する詳細な診断ログをプレイスメントごとに取得できるようになりました。CloudWatch Logs、Amazon S3、Amazon Data Firehose へのログ配信に対応しています。
何が変わったか
  • ゲームセッションキューのルーティングに関する詳細な診断ログをプレイスメントごとに取得できる Game Session Placement Insights が追加された。
  • 評価されたフリートロケーション、プレイヤーレイテンシー、コスト要因、最終的な配置結果がすべてのプレイスメントについて記録される。
  • ログの配信先として Amazon CloudWatch Logs、Amazon S3、Amazon Data Firehose の 3 つが選択できる。
  • この機能はキュー単位で有効化できる。
  • Amazon GameLift Servers がサポートするすべてのリージョンで利用可能になった。
既存環境への影響
これまでゲームセッションの配置が成功・失敗・タイムアウトした理由を把握する手段が限られており、キューの最適化が困難でした。本機能により、配置が遅い、繰り返し失敗する、想定外のロケーションにセッションが配置されるといったパターンを特定しやすくなります。取得したログをもとにキューの設定を調整することで、プレイヤー体験の向上が期待できます。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
対応不要既存の GameLift Servers 環境に対して必須の変更はありません。インサイトを活用したい場合はキューごとに機能を有効化し、ログ配信先を設定する作業が必要です。
#12重要度:通常新機能確認推奨

Amazon DocumentDB 8.0.3 がポスト量子TLS・ワイルドカードインデックス・$unionWith に対応

要約
Amazon DocumentDB (with MongoDB compatibility) のバージョン 8.0.3 が公開され、ポスト量子TLS、ワイルドカードインデックス、$unionWith 集計ステージ、新しいチェンジストリームイベントが追加されました。MongoDB ワークロードをアプリケーションコードを変更せずに Amazon DocumentDB へ移行しやすくなります。
何が変わったか
  • TLS 1.3 接続でクライアントが対応している場合に ML-KEM を用いたハイブリッドポスト量子鍵交換を使用するようになりました。
  • CloudWatch に TLSHandshakesClassical と TLSHandshakesPostQuantum の 2 つの新しいメトリクスが追加されました。
  • ワイルドカードインデックスにより、動的スキーマを持つドキュメントのすべてのフィールドまたは特定パス配下のフィールドをインデックス化できるようになりました。
  • $unionWith 集計ステージが追加され、1 つのパイプラインで複数コレクションの結果を結合できるようになりました。
  • $lookup と $graphLookup がビューで動作するようになり、相関 $lookup サブパイプラインで $unionWith と $facet が使用できるようになりました。
  • dropIndex() と dropIndexes() がチェンジストリームで dropIndexes イベントを発行するようになりました。
  • collStats と stats() がコレクションごとの入力バイト数・出力バイト数・圧縮率を報告するようになりました。
既存環境への影響
ポスト量子TLSにより、現在の通信を記録して将来量子コンピューターで復号する「収穫して後で復号する」攻撃に対する耐性が向上します。ワイルドカードインデックスと $unionWith の追加により、MongoDB との互換性が高まり、アプリケーションコードを変更せずに移行できるワークロードが増えます。既存の接続はクライアントが ML-KEM に対応していない場合は従来の鍵交換を引き続き使用するため、互換性は維持されます。
利用可能リージョン
東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

対応が必要か
確認推奨ポスト量子TLSの恩恵を受けるには、ML-KEM に対応したクライアントライブラリを使用することが推奨されます。CloudWatch の新しいメトリクスで各接続タイプの割合を確認できます。バージョン 8.0.3 への移行を検討する際は Amazon DocumentDB Developer Guide を参照してください。

インフラ運用者への影響

既存環境で確認すべき設定、サポート終了、セキュリティ、東京・大阪リージョンへの影響などを整理しています。

  1. 採用時の注意

    EKS Auto Mode の Security groups for Pods は Kubernetes 1.36 以降が必要

    Amazon EKS Auto Mode で Security groups for Pods を利用するには、クラスターを Kubernetes 1.36 以降にアップグレードする必要があります。既存クラスターへの強制変更はなく、SecurityGroupPolicy リソースを作成することでオプトイン方式で利用できます。

  2. 採用時の注意

    OpenSearch Service クロスリージョン DR は OpenSearch 3.7 以降が必要

    マネージドクロスリージョンディザスタリカバリを利用するには OpenSearch 3.7 以降が必要です。UltraWarm ストレージや OpenSearch Optimized インスタンス(OR1 または OR2)を使用するドメインはサポート対象外です。既存ドメインへの影響はなく、任意で有効化できます。

  3. セキュリティ

    Amazon DocumentDB 8.0.3 でポスト量子TLSが自動有効化

    DocumentDB 8.0.3 では、TLS 1.3 接続でクライアントが ML-KEM に対応している場合にポスト量子鍵交換が自動的に使用されます。CloudWatch の TLSHandshakesClassical と TLSHandshakesPostQuantum メトリクスで接続状況を確認できます。

  4. セキュリティ

    S3 Tables のサーバーアクセスログ有効化を推奨

    Amazon S3 Tables でサーバーアクセスログが利用可能になりました。セキュリティ監査やコンプライアンス対応のために、テーブルバケットに対してサーバーアクセスログを有効化することを推奨します。ログ配信は追加料金なしで利用できます。

  5. 採用時の注意

    Amazon Bedrock の Daybreak モデル利用には OpenAI による事前審査が必要

    Daybreak Red: GPT-5.6 Cyber および Daybreak Blue: GPT-5.6 Sol を利用するには、OpenAI の Daybreak アクセスへの登録申請と承認が必要です。利用を検討する場合は OpenAI または AWS アカウントチームに連絡して資格要件を確認してください。

今日の主な発表

  • AWS Lambda MicroVMs が x86 CPU アーキテクチャをサポート: 既存の x86 アプリケーションを再コンパイルやポーティングなしにそのまま実行可能になりました。MicroVM イメージ作成時に x86 と Arm(AWS Graviton)を選択できます。Asia Pacific (Hong Kong)、Asia Pacific (Malaysia)、Asia Pacific (Thailand)、Europe (Spain) を除くリージョンで利用可能です。
  • Amazon EKS Auto Mode が Security groups for Pods に対応: 同一ノード上の異なるワークロードに異なるセキュリティグループを割り当てられるようになりました。Kubernetes 1.36 以降を実行するクラスターで追加料金なしで利用できます。
  • Amazon OpenSearch Service がマネージドクロスリージョンディザスタリカバリを提供開始: RPO 1分未満・RTO 20分未満を実現します。OpenSearch 3.7 以降が必要で、セカンダリドメインとクロスリージョンデータ転送の標準料金のみが発生します。
  • Amazon DocumentDB 8.0.3 がポスト量子TLS・ワイルドカードインデックス・$unionWith に対応: TLS 1.3 接続で ML-KEM を用いたハイブリッドポスト量子鍵交換を使用するようになりました。CloudWatch に TLSHandshakesClassical と TLSHandshakesPostQuantum の新しいメトリクスが追加されています。
  • AWS Network Firewall が NGFW policy を提供開始: ファイアウォールルールと IPS ルールの容量を分離し、互いにトレードオフなく設定できるようになりました。すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで追加料金なしで利用できます。
  • Amazon EC2 G7 インスタンスが Europe (London)、Asia Pacific (Mumbai, Sydney)、South America (Sao Paulo) で利用可能に: NVIDIA RTX PRO 4500 Blackwell Server Edition GPU を搭載し、G6 インスタンスと比較して AI 推論性能が最大 4.6 倍向上しています。
  • Amazon Bedrock で OpenAI の Daybreak(GPT-5.6 Cyber / GPT-5.6 Sol)が利用可能に: サイバーセキュリティ特化モデルが bedrock-runtime エンドポイントを通じて提供されます。利用には OpenAI による審査と承認が必要です。
  • Amazon S3 Tables がサーバーアクセスログに対応: テーブルバケットへのリクエストの詳細記録が取得できるようになりました。ログ配信は追加料金なしで利用できます。
  • Amazon S3 Access Grants がマルチアカウントをまたいだ一括グラント一覧取得に対応: ListCallerAccessGrants に新しい InstanceScope パラメータが追加され、複数アカウントのグラントを 1 回の API 呼び出しで取得できます。
  • Amazon SES がメールアイデンティティ・テナント・設定セットの上限を引き上げ: マルチテナントワークロードを 1 つのアカウントで管理できるようになりました。AWS Service Quotas コンソールから上限引き上げをリクエストできます。
  • AWS Billing and Cost Management がカスタム請求ビューで Billing Conductor および Billing Transfer ビューに対応: 複数のソースビューを統合・フィルタリングして Cost Explorer や AWS Budgets で活用できます。
  • Amazon GameLift Servers がゲームセッション配置インサイトに対応: キューのルーティング診断ログをプレースメントごとに取得できるようになりました。

運用担当者への影響

  • EKS Auto Mode で Security groups for Pods を利用するには Kubernetes 1.36 以降へのアップグレードが必要です。既存クラスターへの強制変更はなく、SecurityGroupPolicy リソースを作成することでオプトイン方式で利用できます。
  • OpenSearch Service のクロスリージョンディザスタリカバリは OpenSearch 3.7 以降が必要です。UltraWarm ストレージや OpenSearch Optimized インスタンス(OR1 または OR2)を使用するドメインはサポート対象外です。
  • Amazon DocumentDB 8.0.3 のポスト量子TLSはクライアントが ML-KEM に対応している場合に自動的に有効になります。CloudWatch の新しいメトリクスで接続状況を確認できます。
  • S3 Tables のサーバーアクセスログはセキュリティ監査やコンプライアンス対応のために有効化を推奨します。ログ配信自体は追加料金なしで利用できます。

この日報は、当サイトが掲載したニュースをもとに AI が作成し、自動で公開しています。

その他のニュース

重要度「参考」のアップデートです。

この日のその他のニュースはありません。

出典情報

「公式発表」は AWS が情報を公開した日時、「取得」は当サイトが情報を収集した日時です。

この日報で参照した AWS 公式情報
記事AWS 公式情報公式発表取得
Amazon SES がメールアイデンティティ・テナント・設定セットの上限を引き上げ、マルチテナント運用が1アカウントで完結Amazon SES now supports higher limits for email identities, tenants, and configuration sets(新しいタブで開く)2026/11/11 17:002026/11/12 06:10
AWS Lambda MicroVMs が x86 CPU アーキテクチャをサポート、既存の x86 アプリをそのまま実行可能にAWS Lambda MicroVMs now supports the x86 CPU architecture(新しいタブで開く)2026/11/12 03:002026/11/12 06:02
Amazon EKS Auto Mode がPodレベルのセキュリティグループに対応、追加料金なしでKubernetes 1.36以降で利用可能Amazon EKS Auto Mode now supports security groups for Pods(新しいタブで開く)2026/11/12 02:262026/11/12 06:02
AWS Billing and Cost Management のカスタム請求ビューが AWS Billing Conductor と AWS Billing Transfer のビューをソースとしてサポート開始AWS Billing and Cost Management now supports AWS Billing Conductor and AWS Billing Transfer views as source views for custom billing views(新しいタブで開く)2026/11/11 08:222026/11/12 06:02
Amazon EC2 G7インスタンスがEurope (London)、Asia Pacific (Mumbai, Sydney)、South America (Sao Paulo)リージョンで利用可能にAmazon EC2 G7 instances now available in additional regions(新しいタブで開く)2026/11/11 04:302026/11/12 06:02
Amazon OpenSearch Service がマネージドなクロスリージョンディザスタリカバリを発表、RPO 1分未満・RTO 20分未満を実現Amazon OpenSearch Service announces managed cross-Region disaster recovery(新しいタブで開く)2026/11/11 04:002026/11/12 06:02
Amazon S3 Access Grants が複数 AWS アカウントをまたいだ一括グラント一覧取得に対応Amazon S3 Access Grants now support listing grants across multiple AWS accounts(新しいタブで開く)2026/11/10 23:002026/11/12 06:02
Amazon BedrockのbedRock-runtimeエンドポイントでOpenAIのサイバーセキュリティ特化モデル「Daybreak」が利用可能にAmazon Bedrock adds bedrock-runtime endpoint support for Daybreak models(新しいタブで開く)2026/11/10 19:142026/11/12 06:02
Amazon S3 Tables がサーバーアクセスログに対応、テーブルバケットへのリクエストを詳細記録Amazon S3 Tables now support S3 server access logging(新しいタブで開く)2026/11/10 17:002026/11/12 06:02
AWS Network Firewall が次世代ファイアウォールポリシー(NGFW policy)を提供開始、ファイアウォールと IPS のルール容量を分離し管理を簡素化AWS Network Firewall launches next-generation firewall policy(新しいタブで開く)2026/11/10 17:002026/11/12 06:02
Amazon GameLift Servers がゲームセッション配置インサイト機能を提供開始、キューのルーティング診断ログを詳細に取得可能にAmazon GameLift Servers now supports Game Session Placement Insights(新しいタブで開く)2026/11/10 17:002026/11/12 06:02
Amazon DocumentDB 8.0.3 がポスト量子TLS・ワイルドカードインデックス・$unionWith に対応Amazon DocumentDB (with MongoDB compatibility) now supports post-quantum TLS, wildcard indexes, and $unionWith in version 8.0.3(新しいタブで開く)2026/11/10 09:002026/11/12 06:02

収集元:AWS What's New RSS(2026/11/12 06:10 取得)