AWS What's New Digest

Appearance

2026年09月10日 ​

[General] Amazon CloudWatch now supports network health indicator for TGW inter-Region peering using synthetic monitors ​

概要 ​

Amazon CloudWatch の Network Monitoring において、synthetic monitors が AWS Transit Gateway のリージョン間ピアリング経由のパスに対するネットワークヘルス指標（Network Health Indicator, NHI）をサポートするようになりました。これにより、当該経路で発生する性能劣化が AWS 側ネットワークに起因するかを迅速に判定でき、原因切り分け時間が短縮されます。

変更内容・新機能の詳細 ​

これまで synthetic monitors の NHI は AWS Direct Connect 経由の経路に対してのみ提供されていましたが、本リリースにより Transit Gateway (TGW) のリージョン間ピアリング経由で宛先がピアリング済みリージョンに到達するパスについても NHI が拡張されました。NHI は、TGW のピアリング接続までの AWS 側ネットワーク経路のヘルスを反映し、その結果は Amazon CloudWatch のメトリクスとして発行されるため、ダッシュボード表示やアラーム設定が可能です。利用にあたっては対象の経路が TGW リージョン間ピアリングを経由することが前提で、NHI はピア接続点（Transit Gateway peering connection）までの AWS ネットワーク区間を評価するものであり、ピア先リージョン内の VPC 内やオンプレミス側の顧客管理区間までは含みません。利用可能な AWS リージョンは提供されているリージョンリストを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク運用者、SRE、クラウド/アプリケーション開発者
  • 利用シーン: マルチリージョン構成で Transit Gateway のリージョン間ピアリングを利用するアプリケーションのパフォーマンス劣化切り分け、Synthetic monitor を用いた経路監視とアラート運用
  • 運用効果: AWS 側ネットワークが原因かどうかを自動的に示すことで、原因切り分け時間（MTTR）の短縮、ダッシュボードやアラーム連携による迅速な対応が可能

技術的な注意点 ​

  • IAM権限: CloudWatch のメトリクス閲覧・管理権限（例: CloudWatchReadOnlyAccess / CloudWatchFullAccess、必要に応じて synthetic monitor の作成権限）が必要です。サービスリンクドロールや追加の Network Monitoring 用権限を求められる場合があります。
  • リージョン制限: すべてのリージョンで利用可能ではありません。対応リージョンは公式のリージョンリストを確認してください（記事参照）。
  • コスト: synthetic monitors の実行、CloudWatch メトリクスの発行・保存、アラーム作成には料金が発生する可能性があります。監視頻度やメトリクス保存期間によってコストが変動します。
  • 設定要件: 対象パスは Transit Gateway のリージョン間ピアリング経由である必要があります。TGW とピアリング接続が正しく構成されていることを事前に確認してください。
  • カバレッジ: NHI は AWS ネットワーク区間（エンドポイントから TGW ピア接続まで）を評価します。ピア接続先の VPC 内やオンプレミスのネットワーク、あるいはアプリケーション層の問題は NHI の評価対象外です。

参考情報 ​

[Elemental Medialive] AWS Elemental Inference now generates contextual metadata from live video in real time ​

概要 ​

AWS Elemental Inferenceがライブ映像をリアルタイムで解析し、シーン単位のコンテクストメタデータ（IABカテゴリ、GARMブランド適合性、検出オブジェクト/アクション、ショット／シーン記述など）を自動生成できるようになりました。カスタムMLインフラ不要のサーバーレス運用で、広告決定やメディア資産の強化、コンテンツ発見に利用できます。

変更内容・新機能の詳細 ​

新機能はライブ映像のエンコード処理と並列にAI解析を行い、次のようなシーンレベルの知見を生成します：IABコンテンツタクソノミーカテゴリ、GARMブランド適合性シグナル、検出されたオブジェクトおよびアクション、ショット／シーンの記述。広告用途では、MediaLiveがElemental InferenceのフィードIDをSCTE-35アドマーカーに埋め込み、各広告枠でMediaTailorがMonetization Functionを通してそのフィードIDに紐づくシーン信号を取得し、広告サーバーが期待するターゲティングパラメータに変換します。これによりカスタム統合を行わずにコンテキストベースのアドディシジョン（コンテクスチュアルディール振り分け、ブランド適合スコア等）が可能になります。メディア管理面では、オブジェクト／アクションの検出やショット／シーン記述によって自動的に構造化メタデータが生成され、アーカイブの強化、編集支援、パーソナライズ推奨が手作業なしに実現できます。機能はAWS Elemental MediaLiveコンソールから利用可能で、Elemental Inferenceが提供されているリージョンで有効です。

影響範囲・利用シーン ​

  • 対象ユーザー: 放送事業者、OTTプラットフォーム、広告テクノロジー（AdOps）チーム、メディア資産管理（MAM）担当者
  • 利用シーン: ライブ番組のコンテキスト広告配信（SCTE-35でのフィードID→MediaTailor経由によるターゲティング）、自動メタデータ生成によるアーカイブ強化と検索性向上、アシスト編集やパーソナライズ推薦の自動化
  • 運用効果: カスタムMLや後処理なしでリアルタイムな文脈理解が得られ、広告収益の最適化（ブランド適合対応、コンテキストターゲティング）や運用コストの削減（手作業によるログ取りやポストプロダクションの工数削減）につながる

技術的な注意点 ​

  • IAM権限: MediaLive、Elemental Inference、MediaTailor、Monetization Functionを連携するための適切なIAMロールとポリシー（各サービスへのアクセス許可）を事前に設定してください
  • SCTE-35要件: MediaLiveが埋め込むSCTE-35アドマーカーにElemental InferenceのフィードIDを含めるフローが必要です。既存のSCTE-35ワークフローとの整合性を確認してください
  • MediaTailor設定: MediaTailorのMonetization Functionを実装して、フィードIDに紐づくシーンシグナルを取得・マッピングし、広告サーバーが期待するターゲティングパラメータに変換する設定が必要です
  • リージョン制限: 本機能は『AWS Elemental Inferenceが利用可能なリージョン』で利用可能です。利用前に対象リージョンでElemental Inferenceの提供状況を確認してください
  • レイテンシ: 解析はエンコードと並列に行われますが、シーン解析の完了タイミングやネットワーク条件により実際の利用可能タイミングに遅延が生じる可能性があります。特に短い広告ブレークや低遅延要件のワークフローは事前検証が必要です
  • フォーマット／コンテンツ制約: ライブストリームベースの機能です。入力コーデックや解像度、フレームレートによる解析精度やコスト影響が出る可能性があるため、想定する配信フォーマットでの検証を推奨します
  • コスト: Elemental Inferenceの解析処理、追加のMediaTailor呼び出しやMonetization Functionの実行などで追加料金が発生します。想定トラフィックでコスト試算を行ってください
  • データ保護／コンプライアンス: 映像解析に伴うプライバシーやブランドポリシーの考慮が必要です。地域の規制や社内ポリシーに従って利用してください

参考情報 ​

[General] AWS Elemental MediaTailor now offers Yield Optimization to automatically fill ad breaks with Amazon Ads demand ​

概要 ​

AWS Elemental MediaTailorにYield Optimization機能が追加され、ライブ配信のSSAI中に未使用の広告枠をAmazon Adsの需要で自動的にマネタイズできるようになりました。APS（Amazon Publisher Services）Streaming TVプログラム参加出版社向けの機能で、追加インフラ不要・無償で有効化できます。

変更内容・新機能の詳細 ​

Yield Optimizationはサーバーサイド広告挿入（SSAI）を行うライブストリーミングで、未充填の広告ブレイクをAmazon Adsの需要で自動的に埋める機能です。広告は視聴者に届く前にストリームに直接ステッチされるため、デバイスに依存せずシームレスに再生されます。主な技術的特徴は以下の通りです：

  • 大規模対応：プロリーグの大会などピーク視聴時の大量リクエストに対応する低レイテンシ設計で、広告フィル（fill）率を最大化します。
  • ブランドセーフティと制御：カテゴリフィルタリングにより同一広告ブレイク内の競合を回避でき、出版社は価格フロア（最低入札価格）やカテゴリルールを設定して配信制御が可能です。
  • 簡単導入：MediaTailorのAPIまたはコンソールから設定可能で、追加のインフラやクライアント側の変更は不要です。
  • 可視化とレポート：広告フィル率などのMediaTailorメトリクスはAmazon CloudWatchで監視でき、収益・支払いはAPS Publisherポータルで確認できます。
  • 利用条件：本機能はAPS Streaming TVプログラムに参加している出版社専用で、ライブ配信向けのSSAIに適用されます。
  • 価格とリージョン：機能自体は有効化費用不要で、MediaTailorが利用可能な全リージョン（記事に列挙された主要リージョンを含む）で提供されます。

影響範囲・利用シーン ​

  • 対象ユーザー: ライブ配信を行う放送局／メディア出版社、OTTサービス、広告収益化を図るプラットフォーム事業者（APS Streaming TV参加が必要）
  • 利用シーンまたは効果: ライブイベントやスポーツ中継で未使用の広告枠を自動的にマネタイズすることで広告フィル率と収益を向上させる（SSAI環境での即時収益化）
  • 運用効果: クライアント側変更不要で導入が容易、CloudWatchおよびAPSポータルで効果測定が可能なため運用負荷を低減しつつ収益化を迅速化できる

技術的な注意点 ​

  • APS参加要件: この機能はAmazon Publisher Services (APS) Streaming TVプログラムに参加している出版社のみ利用可能です
  • 対応コンテンツ: 主にライブストリーミング（SSAI）向けに設計されており、VODへの適用は記事では明示されていません。VODでの利用可否はドキュメントで確認してください
  • IAM権限: MediaTailorの設定を変更するためのAPI/コンソールアクセス権限（mediatailor関連のIAMポリシー）が必要です。APSポータルへのアクセス権は別途管理されます
  • リージョン制限: MediaTailorが利用可能な全リージョンで提供されます（例：US East (Ohio/N. Virginia)、US West (Oregon)、東京、ソウル、シンガポール、フランクフルト、ロンドン、パリ、シドニーなど）。ただし、利用前に対象リージョンでAPS連携が有効か確認してください
  • コスト: 機能の有効化自体に追加料金は発生しませんが、CloudWatchのメトリクスやログ、通常のMediaTailorおよびデータ転送コストは別途発生する可能性があります。また、Amazon Adsとの収益分配はAPSの契約条件に従いますので契約内容を確認してください
  • 広告制御設定: 価格フロアやカテゴリルールは出版社側で設定・管理可能です。ブランドセーフティのためのカテゴリフィルタリングや除外設定を適切に構成してください
  • クライアント影響: SSAIでサーバー側に広告がステッチされるため、プレイヤーSDKやクライアント側の変更は不要ですが、再生確認やQAは実施してください
  • モニタリング: 広告フィル率やレスポンス指標はCloudWatchで確認できます。収益レポートはAPS Publisherポータルで確認してください
  • パフォーマンス: 大規模イベント向けに低遅延設計ですが、具体的なSLAsやスループット要件は導入前に検証してください

参考情報 ​

[General] AWS Elemental MediaLive adds support for A/B forensic watermarking ​

概要 ​

AWS Elemental MediaLiveがA/B方式のフォレンジック・ウォーターマーキングをサポートしました。ライブ映像の不正再配布元を追跡できるよう、同一チャネルで2種類の透過ウォーターマークを付与した同期出力を生成します。

変更内容・新機能の詳細 ​

MediaLiveは単一チャネルから同期した2つの出力バリアント（A/B）を生成し、それぞれに視認性のほとんどない（visually transparent）別々のフォレンジックウォーターマークを埋め込みます。これらのウォーターマークは再エンコードや画面キャプチャ後も残存する設計で、下流のパッケージャとCDNが各セッション毎にA/Bバリアントを組み合わせて一意のセッションシーケンスを作成することで、リーク元の特定が可能になります。実装はDASH Industry Forum（DASH-IF）のA/Bウォーターマーキング仕様（ETSI TS 104 002）に準拠しており、標準に準拠したパッケージャやCDNと相互運用できます。設定はMediaLiveコンソールまたはAPIから、Common Media Application Format（CMAF）Ingest出力グループに対して行います。MediaLiveはCMAF Ingest経由でウォーターマーク付きA/BバリアントをAWS Elemental MediaPackageやサードパーティのパッケージャへ配信し、対応するCDN（例：Amazon CloudFront）を用いて下流でのセッション単位のウォーターマーク組み立てを行います。A/Bフォレンジック・ウォーターマーキングは、MediaLiveが利用可能な全リージョンで使用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: ライブ映像を配信するコンテンツホルダー、放送事業者、OTT プロバイダ、セキュリティ/法務チーム
  • 利用シーン: ライブスポーツや有料イベントの不正再配布（スクリーンキャプチャや再エンコードによる流出）を特定して法的措置や配信遮断に繋げるための追跡
  • 運用効果: 流出ソースの特定が可能になり、不正流通の抑止や調査工数の削減につながる。標準準拠のため既存のMediaPackageやCloudFront等のインフラに組み込みやすい

技術的な注意点 ​

  • IAM権限: MediaLiveの設定・CMAF出力作成・MediaPackageへの接続には該当するMediaLive/MediaPackage/APIの実行権限が必要です。事前に最小権限のIAMポリシーを用意してください
  • リージョン制限: 記事によれば、MediaLiveが利用可能なすべてのリージョンで利用可能とされていますが、実際の利用前に個別リージョンでの提供状況をAWSコンソールで確認してください
  • コスト: MediaLiveの通常のインスタンス/チャンネル課金、出力ビットレートに伴う帯域・MediaPackage/CloudFront等の下流サービスの料金が発生します。A/Bの同期出力や下流でのセッション別配信によりオリジン帯域やトランスコード負荷が増える可能性があるため請求影響を確認してください
  • 互換性: 本機能はCMAF Ingest出力グループでの利用が前提です。下流のパッケージャとCDNがDASH-IF（ETSI TS 104 002）に準拠したA/Bウォーターマーキングのセッション組み立てをサポートしている必要があります。MediaPackageは対応していますが、サードパーティ製パッケージャやCDNでは事前確認が必要です
  • 運用上の留意点: フォレンジックウォーターマークは検出防止（盗聴・コピー防止）ではなく追跡手段です。テスト環境で再エンコードやキャプチャ条件下でのウォーターマーク残存性を検証し、ログ/セッション情報の保管運用を設計してください
  • CMAF制約: 設定はCMAF Ingest出力グループに対して行うため、既存ワークフローがCMAFを前提としているか確認してください

参考情報 ​

[Elemental Mediatailor] AWS Elemental MediaTailor now supports Low-Latency HLS ad insertion ​

概要 ​

AWS Elemental MediaTailorがLow-Latency HLS（LL-HLS）での広告挿入をサポートしました。これにより、低遅延のライブ配信（スポーツ、ニュース、ベッティング等）で視聴者に期待される短い遅延を維持しつつ広告を挿入できます。

変更内容・新機能の詳細 ​

MediaTailorはHLS Interstitialsを用いてLL-HLS広告挿入を実現します。LL-HLSはEXT-X-PART等の部分セグメント（partial segments）を配信し、プレーヤーが次パートが準備されるまでプレイリスト要求をオープンに保持することで低遅延を達成します。従来の広告挿入方法だと各視聴者ごとにマニフェストをステッチする必要がありキャッシュが効きにくかったのに対し、HLS Interstitialsは広告を個別のプレイリストとして参照する方式を採るため、メディアプレイリストをCDNエッジでキャッシュ可能に保てます。結果として、すべての視聴者が同一のキャッシュ可能なプレイリストを受け取り、MediaTailorはマニフェスト要求パス上での広告決定サーバー（ADS）呼び出しを切り離してスケールした低遅延再生を維持できます。実運用ではマルチミリオンビュー規模のライブスポーツで検証済みです。利用想定はライブスポーツ、速報ニュース、ベッティング・ワager、ウォッチパーティ、インタラクティブライブなど、遅延がプロダクト要件となるケースです。また、本機能はMediaTailorが利用可能なすべてのAWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: ライブ動画配信事業者、OTTプラットフォームのエンジニア、広告配信エンジニア
  • 利用シーンまたは効果: 低遅延を必須とするライブ配信（スポーツ中継、速報、ベッティング、インタラクティブ配信）での広告挿入をスケールして実現
  • 運用効果: マニフェストを共通化してCDNキャッシュを効かせることで高負荷下でも低遅延を維持しつつ一貫した広告配信が可能
  • ビジネス効果: 大規模同時視聴時でも広告挿入によるユーザー体験悪化を抑え、収益化機会を維持・向上できる

技術的な注意点 ​

  • IAM権限: MediaTailorの設定変更やチャネル/コンフィグ作成に必要なIAM権限（mediatailor:*系）を付与してください。ADSや配信に関わるAWSリソースへの権限も確認が必要です
  • プレーヤー互換性: クライアント側でLL-HLS（EXT-X-PART等）をサポートするプレーヤーが必要です。全てのデバイス/SDKでサポートされているわけではないため対象端末で事前検証を行ってください
  • CDN要件: メディアプレイリストがエッジでキャッシュ可能であること、部分セグメントやブロッキング的なplaylist挙動を許容することが必要です。利用するCDN（例: Amazon CloudFrontなど）がLL-HLSの要件を満たすか確認してください
  • リージョン制限: 本機能はAWS Elemental MediaTailorが提供されているすべてのリージョンで利用可能です（リージョン可用性は変更される可能性があるため事前確認を推奨）
  • コスト: MediaTailor利用料に加え、CDN（エッジキャッシュ）によるデータ転送量・リクエスト数の増加、ADSやログ・監視の追加コストが発生する可能性があります。変更前にコスト影響を試算してください
  • 導入上の注意: ADS呼び出しはマニフェスト経路から切り離されるものの、広告決定の遅延は再生中断リスクに直結します。ADSの応答時間や冗長化、キャッシュTTL設計を含めたエンドツーエンドの負荷試験を実施してください

参考情報 ​

[General] AWS Elemental introduces Dynamic Multiview for live video ​

概要 ​

AWS Elemental MediaPackageにDynamic Multiview機能が追加され、複数のライブ映像ソースをサーバー側でタイル状レイアウトに動的合成し、視聴者が選んだ組み合わせを標準のHLS/DASHストリームとして配信できるようになりました。プレイヤー側の変更や再エンコード不要で多角度・マルチゲーム・パーソナライズ配信が可能です。

変更内容・新機能の詳細 ​

Dynamic MultiviewはMediaPackageのサーバー側機能で、視聴者のリクエストに応じて複数の個別にエンコードされたライブソースを圧縮ドメインで組み合わせ（再エンコードやピクセル合成を行わず）タイルレイアウトの映像をオンデマンドで生成します。各ソースはAWS Elemental MediaLiveで一度エンコードしておき、MediaPackageが必要時に組み合わせを構築するため、あらかじめ全組み合わせをプリエンコードしておく必要がありません。出力は標準的なHLSおよびDASHで配信されるため、既存の多くの消費者デバイス、テレビ、セットトップボックス上のネイティブプレーヤーで再生可能です。対応技術としてAVC（H.264）およびHEVC（H.265）のコーデック、DRM暗号化（パススルー/適用可）、SCTE-35広告マーカーのパススルー、およびフルスクリーン広告差し替えをサポートします。Dynamic MultiviewはMediaPackageおよびMediaLiveが利用可能な全リージョンで提供されます。

影響範囲・利用シーン ​

  • 対象ユーザー: ライブ放送事業者、スポーツ中継・マルチアングル配信事業者、放送系SaaSプロバイダ
  • 利用シーン: マルチアングル視聴（スポーツの複数カメラ）、複数試合の同時視聴（マルチゲーム）、視聴者選択によるパーソナライズ画面の提供
  • 運用効果: 事前の組み合わせプリエンコードが不要になりストレージと準備工数を削減、オンデマンドで組み合わせを生成することで運用の柔軟性が向上
  • 視聴者体験: 既存のHLS/DASH対応プレーヤーでネイティブ再生できるためアプリ改修なしで導入可能
  • コストへの影響: MediaLiveでの各ソースの常時エンコードコストは発生するが、プリエンコード保存コストや多段のストレージコスト削減により総コスト構造が改善される可能性あり。MediaPackageでのオンデマンド組み立てや出力配信に伴うリクエスト/パッケージング/データ転送コストも考慮が必要

技術的な注意点 ​

  • IAM権限: MediaLiveおよびMediaPackageのリソース作成・操作に必要なIAMポリシーを付与してください（パッケージングや出力設定の変更権限が必要）
  • リージョン制限: MediaPackageおよびMediaLiveが利用可能な全リージョンで提供されています。両サービスが利用可能か事前に確認してください
  • コーデック/DRM: AVC（H.264）およびHEVC（H.265）をサポート。DRM（Widevine/PlayReady/FairPlay等）の適用はMediaPackageの既存ワークフローに従います
  • エンコード要件: 各角度・ソースはMediaLiveであらかじめ個別にエンコードしておく必要があります（1ソース1エンコードで再利用）
  • 広告/マーキング: SCTE-35マーカーのパススルーとフルスクリーン広告差し替えをサポートしますが、差し替えロジックは既存の広告挿入フローと整合させる必要があります
  • 遅延: サーバー側でのオンデマンド組み立てにより若干のパッケージング遅延が発生する可能性があります。リアルタイム性が厳しいユースケースは検証を推奨します
  • コスト: MediaLiveのエンコード料金、MediaPackageのパッケージング/リクエスト/出力（転送）コストが発生します。オンデマンド生成はプリエンコード保存のコストを削減しますが、トラフィック増加によるデータ転送料金に注意してください

参考情報 ​

[S3] AWS Storage Gateway now supports FIPS-compliant private connectivity for Amazon S3 File Gateway ​

概要 ​

AWS Storage Gateway の Amazon S3 File Gateway が、AWS PrivateLink（Interface VPC エンドポイント）経由で FIPS 140-3 準拠のエンドポイントをサポートしました。これにより、規制対象ワークロード向けに FIPS 準拠トラフィックをパブリックインターネットを経由させずにプライベートな AWS ネットワーク内で完結できます。

変更内容・新機能の詳細 ​

今回の更新により、File Gateway は Storage Gateway サービスおよび Amazon S3 への通信を FIPS 140-3 準拠のインターフェイス VPC エンドポイント（PrivateLink）経由で行えるようになりました。従来は FIPS エンドポイントはパブリックインターネット経由のみの提供でしたが、今後は VPC 内に FIPS インターフェイスエンドポイントを作成して、ゲートウェイのアクティベーション時およびファイル共有（NFS/SMB）設定時に「FIPS VPC エンドポイント」オプションを選択することで、エンドツーエンドで FIPS 準拠のプライベート接続を実現できます。動作条件として、ゲートウェイのソフトウェアバージョンは 2.1.10 以降が必要です。本機能は Storage Gateway の FIPS エンドポイントを提供する下記 8 リージョンで利用可能です：US East (N. Virginia)、US East (Ohio)、US West (N. California)、US West (Oregon)、Canada (Central)、Canada West (Calgary)、AWS GovCloud (US-East)、AWS GovCloud (US-West)。実装手順の概略は、VPC に Storage Gateway と S3 用の FIPS インターフェイスエンドポイントを作成し、ゲートウェイのアクティベーションまたは既存ゲートウェイの設定で FIPS VPC エンドポイントを選択、必要に応じてエンドポイントポリシー・セキュリティグループ・Private DNS を設定する、という流れです。

影響範囲・利用シーン ​

  • 対象ユーザー: 規制準拠（FIPS 140-3）が必要な企業、セキュアなオンプレミス→S3 ファイルアクセスを求めるエンタープライズ
  • 利用シーン: 規制対応が必要なバックアップ／アーカイブ、医療・金融などのセキュアなファイル共有（NFS/SMB）ワークロード、オンプレミス機器からの安全な S3 連携
  • 運用効果: トラフィックをパブリックインターネットに出さずに FIPS 準拠通信が可能になり、コンプライアンス要件の満たしやすさとネットワークセキュリティの向上が期待できる
  • 導入影響: ネットワーク構成（VPC エンドポイント、セキュリティグループ、Private DNS）とゲートウェイのソフトウェアアップデートが必要

技術的な注意点 ​

  • ソフトウェアバージョン: ゲートウェイはソフトウェア v2.1.10 以上が必要です
  • リージョン制限: 本機能は下記 8 リージョンで利用可能—US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Canada (Central), Canada West (Calgary), AWS GovCloud (US-East), AWS GovCloud (US-West)
  • IAM権限: VPC エンドポイントの作成、エンドポイントポリシー編集、Storage Gateway のアクティベーション設定に必要な権限を持つ IAM ロール/ユーザーが必要です
  • ネットワーク設定: Interface VPC エンドポイントは ENI を作成するため、適切なサブネット・セキュリティグループ設定、必要に応じて Private DNS の有効化またはカスタム DNS の設定が必要です
  • エンドポイントポリシー: S3 および Storage Gateway のエンドポイントに対するアクセス制御（エンドポイントポリシー）を適切に設定してください
  • コスト: Interface VPC エンドポイントの時間課金とデータ処理料金、追加のデータ転送料金が発生する可能性があります。コスト見積りを行ってください
  • 運用上の注意: 既存ゲートウェイを FIPS PrivateLink に切り替える場合は計画的なメンテナンスを推奨します（接続設定変更や再アクティベーションが必要となるケースあり）

参考情報 ​

[General] Amazon EVS is now available in more regions ​

概要 ​

Amazon Elastic VMware Service (Amazon EVS) がアジア太平洋（大阪、台北）、ヨーロッパ（スペイン）、イスラエル（テルアビブ）リージョンで利用可能になりました。これにより、AWS上でVMware Cloud Foundation (VCF) をEC2ベアメタル（AWS Nitro）上で直接稼働させられる選択肢が拡大します。

変更内容・新機能の詳細 ​

Amazon EVS はお客様の VPC 内で EC2 ベアメタルインスタンス上に VMware Cloud Foundation (VCF) をデプロイするマネージドサービスです。今回のリージョン拡張により、アジア太平洋（大阪、台北）、ヨーロッパ（スペイン）、イスラエル（テルアビブ）で利用可能になりました。主な技術的特徴は以下の通りです。

  • VCF ネイティブ実行: VCF を直接同一 VPC/ベアメタル上で稼働させ、従来のオンプレミス運用と同様のハイパーバイザー管理を維持します。
  • EC2 ベアメタル + AWS Nitro: ベアメタルインスタンス上で VMware を動作させるため、パフォーマンスとハードウェア分離（Nitro ベアメタルの利点）を活かせます。
  • VCF バージョン対応: 発表時点で VCF 9.0 と 9.1 をサポートし、メモリティアリングなど最新の VMware 機能を利用可能です。
  • 短時間セットアップ: 完全な VCF 環境を数時間で構築でき、データセンターからの迅速な移行や老朽化インフラの置換が可能です。
  • レイテンシ・コンプライアンス・冗長性: 追加リージョンによりエンドユーザーに近い配置でレイテンシ低減、データ居住性／主権要件への対応、さらなる高可用性構成の選択肢が得られます。

影響範囲・利用シーン ​

  • 対象ユーザー: オンプレミスの VMware 環境をクラウドへ移行・延命したい企業、クラウド上でベアメタル性能を必要とするアプリケーション運用者
  • 利用シーン: データセンターの撤退（データセンター・エグジット）、レイテンシ要件の厳しいアプリケーションの近接展開、データ主権／居住性準拠のためのリージョン移設
  • 運用効果: 数時間で VCF 環境を立ち上げられるため移行期間短縮、オンプレ運用の運用負荷軽減とインフラ老朽化リスクの低減、ユーザー近接配置による応答性向上

技術的な注意点 ​

  • IAM権限: EVS の利用には EC2 (ベアメタル)、VPC、IAM の適切な権限が必要です。サービス固有の IAM ポリシーを確認してください。
  • リージョン制限: 今回追加された4リージョン（大阪、台北、スペイン、テルアビブ）で利用可能ですが、他リージョンとはサービス提供状況が異なる可能性があります。利用前に対象リージョンでの提供状況を確認してください。
  • コスト: ベアメタル EC2 インスタンス、ストレージ、データ転送などに対する課金が発生します。既存オンプレ移行による総所有コスト（TCO）比較を事前に実施してください。
  • VCFバージョン互換性: 発表時点で VCF 9.0 / 9.1 をサポート。導入前に利用中の VMware コンポーネント（vCenter、ESXi、NSX 等）との互換性を確認してください。
  • ネットワーク/接続: VPC 内での設計となるため、オンプレとの接続（Direct Connect / VPN）やルーティング、帯域要件を検討してください。レイテンシや MTU 等も影響します。
  • バックアップ/復旧: 従来の VMware バックアップツールや AWS のバックアップ方針との整合性を確認し、データ保護戦略を設計してください。

参考情報 ​

[Govcloud Us] Amazon Connect Customer now lets you set specific capacity limits for different types of Tasks and Emails ​

概要 ​

Amazon Connect Customerは、タスクおよびメールの各種コンタクトに対して、複雑度や優先度に基づく個別の同時処理上限（キャパシティ）と割り込みルールを設定できるようになりました。これによりチャネル単位だった従来の同時処理設定を細分化できます。

変更内容・新機能の詳細 ​

これまで同時処理（concurrency）設定はチャネル単位で一律に適用され、同じチャネル内の全コンタクトが同一の扱いでした。本リリースでは、管理者がTaskおよびEmailコンタクトを「ワークロードタイプ」（複雑性・優先度・業務機能等で分類）に割り当て、それぞれに対して独立した同時処理上限と割り込み（中断）ルールを設定できます。たとえば「低負荷の簡易Taskは最大3件を同時処理」「高負荷の複雑Taskは同時1件に制限」といった動作が可能です。これらの設定はAmazon Connect Customer提供リージョン（AWS商用リージョンおよびAWS GovCloud (US-West) の提供リージョン）で利用可能です。詳細と設定手順はAmazon Connect Customer Administrator Guideを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンターマネージャー、ワークフォース管理者、運用／SREチーム、CTIインテグレータ
  • 利用シーン: タスクやメールを複雑度や優先度で分類して適切な同時処理数を割り当てることで、応答品質やSLAを維持しつつエージェントの負荷を管理する場面（例: 高集中業務は同時1件、簡易業務は同時複数可）
  • 運用効果: エージェントのオーバーロード低減、優先度に応じた処理の最適化、SLA達成率向上、より正確なキャパシティプランニングが可能になる

技術的な注意点 ​

  • IAM権限: 管理コンソールやAPIで同時処理設定を変更するにはAmazon Connectの管理権限（関連するIAMポリシー）が必要です。事前に適切なIAMロール/ポリシーを確認してください
  • リージョン制限: AWS商用リージョンおよびAWS GovCloud (US-West) のAmazon Connect Customer提供リージョンで利用可能。利用可否は各リージョンのサービス提供状況を確認してください
  • 適用チャネル: 本機能はTaskおよびEmailチャネルに対して提供されます。他チャネル（例: 音声/チャット）への同様の細分化が可能かはドキュメントで確認してください
  • 設定の影響範囲: 同時処理上限と割り込みルールの変更はルーティングやエージェントのUI/フロー挙動に影響を与える可能性があるため、ステージング環境で十分に検証してから本番適用してください
  • パフォーマンスとコスト: 機能自体で直接の追加料金が発生するとは明記されていませんが、同時処理の緩和により必要なエージェント数や外部連携リソースが増減し、運用コストに影響する可能性があります
  • 監査・ロギング: 設定変更や割り込み動作の影響を追跡するため、CloudWatchログやAmazon Connectの監査ログ設定を確認・有効化することを推奨します
  • 導入手順・テスト: 実運用前にワークロードタイプの定義（複雑度基準・優先度ルール）を作成し、エージェント側のUXとルーティング挙動を確認してください

参考情報 ​

[General] AWS Transform for .NET modernization is now generally available via CLI ​

概要 ​

AWS Transform の .NET モダナイゼーションが CLI からワンライナーで実行できる形で一般提供（GA）になりました。対話実行とパイプライン組込の両方に対応し、既存のWebアプリ、Visual Studio、Kiro Power、MCPエージェントの体験を補完します。

変更内容・新機能の詳細 ​

AWS Transform の "AWS-managed transformation for .NET modernization" が AWS Transform custom を通じて CLI で利用可能になりました。単一の一行コマンドで変換をトリガーでき、対話モードまたは自動化されたCI/CDパイプライン内での実行が可能です。提供される変換には、言語バージョンのアップグレード、フレームワークのマイグレーション、パフォーマンス最適化、コードベース解析などが含まれ、AWS 管理の標準変換をそのまま使うか、組織固有の要件に合わせてカスタマイズすることができます。変換ロジックはエンゲージメントからの学習により継続的に改善され、より正確で効率的な結果が期待できます。サービスは以下の8リージョンで利用可能です: US East (N. Virginia)、Asia Pacific (Mumbai, Tokyo, Seoul, Sydney)、Canada (Central)、Europe (Frankfurt, London)。また、.NET モダナイゼーション変換には月間50,000分の無料エージェント時間が含まれます（詳細は料金ページ参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: .NET アプリケーションを保守・近代化するソフトウェアエンジニア、プラットフォーム/クラウドアーキテクト、SRE/運用チーム
  • 利用シーンまたは効果: レガシー .NET Framework から新しい .NET バージョンへのアップグレード、フレームワーク移行（例: .NET Framework → .NET Core/.NET）、パフォーマンス改善、コード品質解析を自動化して大規模なコードベースを短期間で近代化
  • 運用効果: パイプラインに組み込むことで人的作業を削減し、変換の一貫性と再現性が向上。自動化によりマイグレーション作業の速度とスケールが大幅に改善される
  • コスト影響: 月間50,000無料エージェント分の提供により小規模～中規模の作業はコスト抑制が期待できるが、超過分や追加のカスタム変換に対しては課金が発生する可能性がある
  • リージョン影響: 現時点で利用可能なリージョンは限定されており（記事記載の8リージョン）、未対応リージョンでは利用できない

技術的な注意点 ​

  • IAM権限: CLI 実行には AWS Transform へのアクセス権（Transform の実行・管理に必要な IAM ポリシー）が必要。S3/CodeCommit/ECR などソース・成果物の読み書き権限も要確認
  • リージョン制限: サービスは記事記載の8リージョンのみでGA。対象リージョン以外では利用不可（リージョンを跨いだデータ転送やレイテンシに注意）
  • コスト: .NET モダナイゼーション変換は月間50,000無料エージェント分が含まれるが、超過分や追加のカスタム変換は料金が発生。事前に AWS Transform の料金ページで想定コストを確認してください
  • CLI利用上の注意: ワンライナーで実行可能だが、対話モードと非対話モード（スクリプト化）の振る舞いを確認し、CI/CD パイプラインに組み込む際はログ・出力先（S3 等）の取り扱いを定義しておくこと
  • 互換性/テスト: 自動変換は高い精度を目指すが、特に大規模または複雑なコードベースでは事前のテスト、ステージング環境での検証、コードレビューが必須
  • エージェント/リソース: 変換はエージェント（実行時間）を消費する。エージェントのキャパシティや並列実行の挙動、ネットワーク/ストレージ要件を設計に組み込むこと
  • 監査/コンプライアンス: 生成されたコードや変更履歴の保存・監査要件がある場合は、成果物の保存先とアクセス管理を明確にすること

参考情報 ​

[General] AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances ​

概要 ​

AWS Lambda の Lambda Managed Instances (LMI) で、非同期およびイベントソースマッピング（ESM）呼び出しに対する関数タイムアウトが従来の15分から最大90分に拡張されました。これにより、メディアトランスコーディングや大規模なデータ処理、金融シミュレーション、AI推論など長時間実行が必要なジョブを再設計せずに Lambda 上で実行できます。

変更内容・新機能の詳細 ​

今回のアップデートでは、Lambda Managed Instances を利用する非同期呼び出しおよびイベントソースマッピング（ESM）に対して、関数タイムアウトを最大90分まで設定できるようになりました（従来は最大15分）。LMI はインスタンス上で複数の同時リクエストを処理でき、専用のコンピューティング構成や EC2 に準じたコスト効率の恩恵を受けながらインフラ管理なしで実行できるのが特徴です。90分の拡張は Lambda Durable Functions（チェックポイントとリプレイを行う長期実行の仕組み）内の呼び出しにも適用されます。さらに、非同期でトリガーされたマルチステップな Durable 実行はチェックポイントを組み合わせることで最長1年までの実行シナリオをサポートします。タイムアウト設定は AWS コンソール、AWS CLI、Lambda API、IaC ツール群、Agent Toolkit for AWS などから変更可能です。一方で同期呼び出し（同期的な API 呼び出し等）は従来どおり最大15分が上限です。機能は Lambda Managed Instances が提供されているすべてのリージョンで利用可能ですが、実際の利用前に対象リージョンの LMI 提供状況を確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバーレスで長時間実行ワークロードを扱う開発者、SRE、データエンジニア、MLエンジニア
  • 利用シーンまたは効果: メディアトランスコーディング、バッチデータ処理、Monte Carlo 等の金融シミュレーション、AI 推論や大規模前処理など、以前は15分制限のために分割や別サービス化が必要だった処理をそのまま Lambda で実行可能に
  • 運用効果: アーキテクチャの単純化（分割・キュー連携の不要化）、LMI によるコスト効率向上（EC2 型の利点）および Durable Functions 組合せでの回復性強化

技術的な注意点 ​

  • IAM権限: 関数のタイムアウトを変更するには lambda:UpdateFunctionConfiguration 等の権限が必要です。ESM や Durable Functions を構成する場合は追加のリソースアクセス権限を確認してください
  • リージョン制限: 本機能は Lambda Managed Instances が利用可能なリージョンで提供されます。利用前に対象リージョンで LMI が有効か確認してください
  • コスト: 実行時間が長くなるほど課金が増加します。LMI は EC2 風のコスト優位性がある場合がありますが、実行時間・メモリ・vCPU 構成に基づく料金影響を事前に評価してください（詳細は Lambda の料金ページ参照）
  • 同期呼び出しの制限: 同期（同期API呼び出し等）は従来どおり最大15分のままです。長時間実行を行う場合は必ず非同期またはESMでの実行を検討してください
  • 互換性とトリガー: 一部トリガーや統合は非同期実行をサポートしない場合があります。使用するイベントソースが非同期/ESM 呼び出しをサポートするか事前に確認してください
  • Durable Functions: チェックポイントとリプレイを組み合わせることで最長1年のマルチステップ実行が可能ですが、ステート管理やリトライ戦略、エラー処理設計は別途検討が必要です
  • 設定方法: コンソール、AWS CLI、Lambda API、IaC（CloudFormation/CDK/Terraform 等）、Agent Toolkit からタイムアウト値を設定可能です。変更はデプロイ/設定更新の一部として適用されます

参考情報 ​

[Lambda] AWS Lambda now supports Graviton5-powered EC2 instances on Lambda Managed Instances ​

概要 ​

AWS LambdaのLambda Managed Instancesで、最新のGraviton5搭載EC2インスタンスタイプ（C9g、C9gd、M9g、M9gd）が利用可能になりました。Graviton4と比べて最大25%の計算性能向上が見込まれます。

変更内容・新機能の詳細 ​

Lambda Managed Instancesは、EC2のインスタンス上でLambda関数を運用の簡便さを保ったまま実行できるマネージドサービスです。本アップデートにより、C9g、C9gd、M9g、M9gdといったGraviton5（ARMベース）搭載インスタンスを選択できるようになりました。これにより、同等のワークロードで最大25%のコンピュート性能向上が期待できます。利用方法としては、Capacity Provider作成時に希望するGraviton5インスタンスタイプを指定するか、インスタンスタイプをdefaultに設定すると、Lambdaが関数の設定（アーキテクチャ、メモリサイズ、メモリ対vCPU比）に基づいて自動的にGraviton5インスタンスを候補に含めます。Lambda Managed Instancesはインスタンスライフサイクル管理、OS/ランタイムのパッチ適用、内蔵ルーティング、ロードバランシング、設定可能なパラメータに基づくオートスケーリングなどをフルマネージドで提供します。Graviton5サポートは、Lambda Managed Instancesと対象EC2インスタンスが両方利用可能なリージョンで提供されます。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバレスを好むが専用インスタンスやEC2の価格優位性を活かしたい開発者・SRE/運用チーム
  • 利用シーン: CPU集約型バッチ処理、リアルタイムデータ変換、ハイパフォーマンスAPIバックエンドなどのワークロードでの性能向上とコスト最適化
  • 運用効果: Lambdaの運用簡便性を維持しつつ、Graviton5の性能向上で処理時間短縮やスループット向上、EC2料金の恩恵によるコスト削減が期待できる
  • 互換性注意点: ARM（arm64）アーキテクチャ向けにビルドされたランタイムやバイナリが必要なため、x86_64専用のネイティブ依存は再ビルドが必要

技術的な注意点 ​

  • IAM権限: Capacity Providerの作成・管理やLambda Managed Instancesの利用に必要なIAM権限（Capacity Provider作成、EC2関連、Lambdaの管理権限等）を事前に確認・付与してください
  • リージョン制限: Graviton5インスタンスとLambda Managed Instancesの両方が利用可能なリージョンでのみ有効です。利用前に対象リージョンでの提供状況を確認してください
  • アーキテクチャ互換性: Graviton5はARM（arm64）ベースです。関数・コンテナイメージ・ネイティブライブラリはarm64向けにビルド／テストする必要があります
  • ネイティブ依存: ネイティブ拡張やサードパーティライブラリを含むレイヤーやコンテナは、arm64ビルドや代替バージョンの準備が必要です
  • コスト: Lambda Managed InstancesはEC2の価格体系を活用できますが、Graviton5のインスタンスタイプごとに単価が異なります。性能向上に伴うコスト効率をベンチマークして評価してください
  • 運用自動化: インスタンスのライフサイクル・パッチ適用・オートスケーリングはマネージドだが、スケーリングパラメータやキャパシティ設定は適切に設計してください

参考情報 ​

[Quicksight] Amazon Bedrock Managed Knowledge Base adds APIs and console support for debugging document-level access control ​

概要 ​

Amazon Bedrock Managed Knowledge Baseに、ドキュメント単位のアクセス制御(ACL)をデバッグ・監査するための2つのAPI（CheckIngestedDocumentAcl、GetIngestedDocumentAcl）とコンソール機能が追加されました。これにより、アクセスできないドキュメントの原因切り分けが迅速に行えます。

変更内容・新機能の詳細 ​

追加されたAPIは以下のとおりです。

  • CheckIngestedDocumentAcl: 指定したインジェスト済みドキュメントIDとユーザー（例: メールアドレス）を指定し、そのユーザーが当該ドキュメントへアクセス可能かどうか（true/false など）を確認します。これにより、検索/取得結果にドキュメントが現れない原因がアクセス権によるものかどうかを即座に判定できます。

  • GetIngestedDocumentAcl: 指定したドキュメントに紐づくフルACL（許可されたプリンシパルと権限の一覧）を返します。ACLの内容を直接確認することで、誤った許可設定や抜けを監査・修正できます。

コンソール側ではデータソース詳細ページに「Document Access Control」セクションが追加され、ドキュメントIDとユーザー情報を入力してアクセス可否をチェックしたり、ドキュメントIDからフルACLを取得して表示できます。これらはACL対応データソース向けの機能で、管理者が大規模なナレッジベースのアクセス制御を可視化・運用するのに役立ちます。APIは自動化スクリプトやCI/CDパイプラインに組み込めるため、権限変更後の検証や定期監査にも利用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: ナレッジベース管理者、セキュリティ/ガバナンス担当、SRE/運用チーム
  • 利用シーン: 検索結果に期待するドキュメントが表示されない際の原因切り分け、ドキュメント単位の権限設定の監査と修正確認
  • 運用効果: サポートケースを開かずに自己解決が可能になり、トラブル対応時間の短縮と誤設定検出の効率化が期待される
  • スケーラビリティ: APIを使った自動チェックで大量ドキュメントの権限監査や定期検査が容易になる

技術的な注意点 ​

  • IAM権限: API呼び出しには bedrock:CheckIngestedDocumentAcl および bedrock:GetIngestedDocumentAcl に対する許可が必要（マネージドポリシー/カスタムポリシーでの権限付与を確認してください）
  • リージョン制限: Managed Knowledge Base機能が利用可能なリージョンのみで使用可能。未対応リージョンでは利用不可の可能性あり
  • 対象データソース: ACL対応（ACL-enabled）として設定されたデータソースに対してのみ有効。ACL未設定のデータソースでは意味を持ちません
  • 入力要件: 照会には正確なドキュメントIDと照合するユーザー識別子（例: メールアドレス）が必要
  • ログ/監査: API呼び出しはCloudTrail等で記録される（一般的なAWS APIの挙動に準拠）。監査ログとして利用可能です
  • コスト: これら管理API/コンソール操作自体に特別な料金が発生する可能性は低いが、Knowledge BaseやBedrockの利用料、データ転送等の通常コストは発生します
  • 運用上の注意: ACLの変更や検証を行う際は、変更前後の状態を記録し、誤設定による過剰公開を防ぐため最小権限の原則を遵守してください

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026