AWS What's New Digest

Appearance

2026年05月06日 ​

[Elemental Mediatailor] AWS Elemental MediaTailor now supports ad trickplay personalization and compact DASH manifest optimization via dynamic transcoding ​

概要 ​

AWS Elemental MediaTailorが、動的トランスコーディングを通じてHLS/DASHのトリックプレイ対応広告パーソナライズと、コンパクトDASHマニフェスト最適化をネイティブサポートするようになりました。これによりカスタムトランスコードプロファイル不要で、視聴体験の一貫性とマニフェスト配信効率が向上します。

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

主な変更点は二つあります。1) Ad Trickplay Personalization: MediaTailorの動的トランスコーディングが、HLSおよびDASHワークフローにおいてトリックプレイ（早送り・巻き戻しなど）用のバリアントとそれに付随するイメージストリーム（サムネイルやスプライトなど）を広告側にも自動で生成／整合させるようになりました。これらのトリックプレイバリアントはオリジンコンテンツの仕様（解像度、コーデック、フレームレートやセグメント境界など）に合わせて提供されるため、シーク時に広告と本編の表示が一貫します。従来必要だったカスタムトランスコードプロファイルは不要になりました。2) Compact DASH Manifest Support: 動的トランスコーディングを利用して、DASHマニフェストをコンパクト化できます。具体的には、各Representationで冗長に記述されていたSegmentTemplate要素をAdaptationSetレベルへ持ち上げることでマニフェストサイズを削減し、配信効率と一部プレーヤ／ワークフローとの互換性を向上させます。こちらもカスタムトランスコードプロファイルは不要です。両機能とも、MediaTailorが提供するサーバーサイド広告挿入（SSAI）フロー内でネイティブに動作します。記事発表時点で、MediaTailorが利用可能な全リージョンで有効化されており、機能自体に追加料金はありません（ただし従来の配信・トランスコード・データ転送などのコストは引き続き発生します）。

影響範囲・利用シーン ​

  • 対象ユーザー: OTTプラットフォーム運営者、動画配信エンジニア、広告配信事業者
  • 利用シーンまたは効果: 視聴者が早送りや巻き戻し（トリックプレイ）する際も広告表示を本編と整合させ、UXの一貫性を維持。DASHマニフェストのサイズ削減によりマニフェスト配信効率が向上し、プレーヤの初期読み込み性能やマニフェスト処理コストが改善される
  • 運用効果: カスタムトランスコードプロファイルの作成・管理工数が不要になり、導入・保守の負担を軽減。マニフェスト転送量の削減で帯域使用の最適化が期待できる
  • リージョン: MediaTailorが利用可能な全リージョン（例: US East (Ohio, N. Virginia), US West (Oregon), Africa (Cape Town), Asia Pacific (Hyderabad, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), Canada (Central), Europe (Frankfurt, Ireland, London, Paris, Stockholm), Middle East (UAE), South America (São Paulo)）で利用可能
  • コスト影響: 新機能自体に追加料金は無し。ただし通常のMediaTailor処理、トランスコード処理、データ転送（アウトバウンド）等の料金は適用される

技術的な注意点 ​

  • IAM権限: MediaTailorを操作するIAMロール/ユーザーに必要な権限（MediaTailorの設定変更、関連するS3/originアクセス等）を付与してください
  • 動的トランスコーディング設定: 該当ストリームで動的トランスコーディングが有効になっていることを確認してください。既存のカスタムトランスコードプロファイルは不要だが、既存設定との影響確認を推奨します
  • コンテンツ要件: 広告アセットはオリジンのトリックプレイ仕様（解像度、コーデック、フレームレート、セグメント境界、時間基準など）に整合させる必要があります。オリジン側と広告側で仕様不整合があるとシーク時の表示崩れが起こる可能性があります
  • プレーヤー互換性: クライアント側プレーヤーがHLS/DASHのトリックプレイ仕様およびコンパクトDASH（AdaptationSetレベルのSegmentTemplate）をサポートしているか確認してください。プレーヤーの実装差異により挙動が異なる場合があります
  • テスト: 本番導入前に主要ターゲットデバイス／ネットワーク条件でトリックプレイ挙動とマニフェスト互換性の包括的なテストを行ってください
  • リージョン制限: 記事記載の通り、MediaTailorが提供されているリージョンで利用可能です。特定リージョンでの利用可否は最新のリージョン対応状況を確認してください
  • コスト: 機能追加に対する直接料金はありませんが、動的トランスコーディングや配信に伴う通常料金（処理時間、転送量等）は発生します

参考情報 ​

[Developer Tools] Announcing Agent Toolkit for AWS — help AI coding agents build effectively on AWS ​

概要 ​

Agent Toolkit for AWS は、AIコーディングエージェントがAWS上でより正確かつ低コストに、エンタープライズ向けのガバナンスで動作できるようにする、本番運用対応のツール群とガイダンスです。MCPサーバー／スキル／プラグインの後継として提供されます。

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

主な構成要素は「エージェント・スキル」「フルマネージドのAWS MCP Server」「エージェント・プラグイン」です。エージェント・スキルはCloudFormationテンプレート作成、データパイプライン構築、サーバーレスやコンテナの構成など、エージェントが従うべき検証済みで最新の手順（ベストプラクティス）を提供します。ローンチ時点でインフラストラクチャー・コード、ストレージ、解析、サーバーレス、コンテナ、AIサービス分野で40以上のスキルを公開しており、今後データベース、ネットワーク、IAM向けのスキルを追加予定です。AWS MCP Server（一般提供）はフルマネージドで、エージェントが任意のAWSサービスと対話できるようにしつつ、IAMベースのガードレール（どのアクションを実行できるかの制御）、Amazon CloudWatch／AWS CloudTrailによる可観測性、マルチステップ操作のためのサンドボックス化されたコード実行環境を提供します。さらに、ドキュメント検索・取得機能によりエージェントは常に最新のサービス情報にアクセスできます。エージェント・プラグインはMCP Serverとキュレーションされたスキル群を一括でインストール可能にしたパッケージで、ローンチ時には「AWS Core（フルスタック開発向け）」「AWS Data Analytics（データパイプライン・解析向け）」「AWS Agents（Amazon Bedrock AgentCoreを利用した本番エージェント構築向け）」の3種類を提供します。既存のAWS LabsにあるMCPサーバー／スキル／プラグインは引き続き利用可能で、良質なものから順次Agent Toolkitに移行されます。Agent Toolkit自体の利用料はなく、エージェントが消費するAWSリソース（API呼び出し、ストレージ、CloudWatch/CloudTrail、Bedrockなど）は別途課金されます。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、AIエンジニア、データエンジニア、SRE/運用チーム
  • 利用シーン: エージェントを使ったCloudFormation作成、データパイプライン構築、サーバーレス／コンテナアプリの自動構築と運用、Bedrockベースの本番エージェント構築
  • 運用効果: エージェントの誤操作や不適切な設計による手戻りを減らし、トークン・APIコールの無駄を抑えてコスト効率を改善
  • ガバナンス効果: IAMベースのガードレール＋CloudTrail/CloudWatchでエージェントの操作を監査・制御しやすくなる
  • 導入効果: 開発速度の向上（反復タスクの自動化）と本番利用に向けた安全性の担保が容易になる

技術的な注意点 ​

  • IAM権限: MCP Serverが実行するAWSアクションを制限するためのIAMロール／ポリシー設定が必要です。最小権限の原則でロールを設計してください。
  • リージョン制限: 公開記事に具体的なリージョン対応表は記載されていません。利用前に対象リージョンでサービスが利用可能か確認してください。
  • コスト: Agent Toolkit自体に追加料金はありませんが、エージェントが利用するAPI呼び出し、CloudWatch/CloudTrailのログ、サンドボックス実行による計算、Amazon Bedrockなどのサービス利用料は別途発生します。
  • セキュリティ監査: CloudTrailとCloudWatchでエージェントの行動を必ずログ化し、ログの保持期間・アラートを運用ポリシーに組み込んでください。
  • サンドボックスの制限: サンドボックス化されたコード実行は安全性を高めますが、実行時間・ネットワークアクセス・外部リソースへのアクセス制限などの制約がある可能性があるため、マルチステップワークフローの動作確認が必要です。
  • 互換性: AWS AgentsプラグインはAmazon Bedrock AgentCoreとの連携を想定しています。他エージェントフレームワークとの互換性は事前に確認してください。
  • 移行: 既存のAWS LabsにあるMCP／スキルは引き続き利用可能ですが、将来的にAgent Toolkitへ移行されます。移行計画と互換性確認を行ってください。

参考情報 ​

[Developer Tools] The AWS MCP Server is now generally available ​

概要 ​

AWS MCP Serverが一般提供（GA）になりました。Model Context Protocol (MCP) を通じて、AIコーディングエージェントに対してIAMベースのガードレールや監査ログを維持しつつAWSサービスへの安全で可観測なアクセスを提供するマネージドサーバーです。

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

AWS MCP ServerはAgent Toolkit for AWSの中核コンポーネントで、エージェントがAWS上で安全かつ監査可能に動作するためのブローカーを提供します。主な機能は以下の通りです。1) 単一ツール経由で任意のAWS APIを呼び出せるようになり、ファイルアップロードや長時間実行を伴う操作にも対応可能になった点。2) サンドボックス化されたPythonスクリプト実行により、エージェントがマルチステップ処理をAWSサービスに対して行えるが、ローカルファイルシステムやシェルツールへのアクセスは遮断される点（セキュリティ強化）。3) エージェントSOPに代わる「agent skills」機構により、事前にキュレーションされた手順を必要に応じてロードし、コンテキストウィンドウの消費を抑えつつ複雑タスクを実行できる点。4) ドキュメント検索やスキルの検出がクレデンシャル不要で利用可能になり、導入のハードルが低下した点。運用面では、IAMベースのガードレールでアクセス制御を行い、Amazon CloudWatchメトリクスとAWS CloudTrailによる監査・可視化が可能です。料金はMCP Server自体に追加費用はなく、エージェントが利用するAWSリソース（API呼び出し、ストレージ、実行時間など）に対して通常の課金が発生します。

影響範囲・利用シーン ​

  • 対象ユーザー: AI/コーディングエージェントをAWS上で使いたい開発者、SRE、プラットフォームチーム
  • 利用シーンまたは効果: 自動化エージェントによるインフラ操作、デプロイ、データ処理ワークフローの実行において、アクセス制御・監査を維持しつつエージェントにAWS APIを利用させることが可能
  • 運用効果: CloudTrail/CloudWatchと連携した可観測性により、エージェントの操作を監査・モニタリングでき、誤操作や不正アクセスの追跡が容易になる
  • 開発効果: agent skillsやサンドボックス実行により、複雑なマルチステップ処理を安全に自動化し、手動作業や手順書の依存を低減できる
  • コスト影響: MCP Server自体は追加料金なしだが、エージェントが呼び出すAWS API、S3保存、実行リソース（Lambda/EC2/Step Functions等）に対して通常の利用料金が発生する

技術的な注意点 ​

  • IAM権限: エージェントが操作する権限はIAMロール/ポリシーで厳密に設計すること（最小権限原則を適用）
  • ログ監査: CloudTrail と CloudWatch によるログ/メトリクス収集を有効化して監査・アラートを構築することを推奨
  • サンドボックス制限: サンドボックス化されたPython実行はローカルファイルシステムやシェルツールにアクセスできないため、外部依存やネイティブバイナリを必要とする処理は事前に再設計が必要
  • 長時間処理: 長時間実行や非同期処理はバックエンドでのジョブ化（Step Functions、ECS、Batch等）を組み合わせることを検討
  • リージョン制限: 記事中に明示的なリージョン制限は記載されていないが、導入前に使用予定リージョンでのサポート状況を確認すること
  • コスト: サーバー自体は無料だが、エージェントによるAPI呼び出し数やデータ転送、ストレージなどのコストが発生する点に注意
  • 互換性・移行: 既存のエージェントやカスタムツールを接続する場合、MCPプロトコルへの対応やagent skillsフォーマットへの変換が必要になる可能性がある

参考情報 ​

[Transfer Family] AWS Transfer Family web apps are now available in the AWS Asia Pacific (New Zealand) Region ​

概要 ​

AWS Transfer Family の Web アプリ機能が AWS Asia Pacific (New Zealand) リージョンで利用可能になりました。ブラウザ経由で Amazon S3 のデータを参照・アップロード・ダウンロードできる、フルマネージドでブランド化されたポータルを提供します。

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

Transfer Family の Web アプリは、エンドユーザー向けにブラウザベースで S3 のオブジェクトを参照・アップロード・ダウンロードするためのフルマネージドなポータル機能です。組織向けにブランディングを行った UI を提供でき、バックエンドは Amazon S3 を利用します。管理者は Transfer Family のコンソールや API から Web アプリを作成・設定し、対象の S3 バケットやアクセスロールを紐付けて公開できます。認証やユーザー管理は既存の Transfer Family の認証オプション（サービス管理のユーザーや外部 ID プロバイダ等）を利用して統合可能です。なお、サポートされるリージョンの一覧は AWS Capabilities ツール（Builder Center）で確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: S3 を業務データの共有/入出力に使っているアプリ開発者、ファイル共有を簡易化したい業務部門、SRE/運用チーム
  • 利用シーン: 社内または取引先向けの簡易ファイルポータル（ブラウザ経由でのファイル受け渡し／アップロード／ダウンロード）、非技術者向けのデータアクセス提供、SFTP 等の既存接続手段を補完するブラウザ UI 提供
  • 運用効果: エンドユーザーの操作負荷削減とサポート工数の低減、S3 へのアクセスを統一した UI で提供することでアクセスルールや監査の一元化が可能

技術的な注意点 ​

  • IAM権限: Web アプリ作成・管理には Transfer Family および関連する IAM 権限（Transfer の管理、S3 バケットへのアクセスロール作成等）が必要です。事前に権限設計を確認してください。
  • リージョン制限: 本リリースは Asia Pacific (New Zealand) リージョンでの提供開始です。その他リージョンの対応状況は AWS Capabilities ツールで確認してください。
  • コスト: Web アプリ自体や S3 のストレージ・データ転送、Transfer Family の利用に伴う通常の料金が発生する可能性があります。コスト影響を事前に評価してください。
  • セキュリティ: S3 バケットポリシーと IAM ロールで最小権限を適用し、必要に応じて暗号化やアクセスログ（S3 Access Logs / CloudTrail）を有効にしてください。
  • 既存環境との統合: 認証方式（サービス管理ユーザー／外部 ID プロバイダ等）やユーザーホームディレクトリのマッピング、ポリシー適用の挙動を事前にテストしてください。

参考情報 ​

[Directory Service] AWS Directory Service expands directory security settings with STIG-aligned controls for Managed AD ​

概要 ​

AWS Managed Microsoft AD に対して、DISA の STIG に整合するセキュリティ設定の選択肢が拡張されました。コンソールおよび API から自己サービスで有効化でき、複数ディレクトリへの一貫した適用とスケール時の自動反映が可能です。

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

今回の拡張で、AWS Directory Service for Microsoft Active Directory（AWS Managed Microsoft AD）は「STIG（Security Technical Implementation Guides）に整合した」セキュリティ設定群を提供します。これらは Windows Server / Active Directory に関する高影響度のセキュリティ項目を対象とし、管理者が望む構成を宣言すると AWS がその設定を実装・永続化します。設定は AWS Management Console とプログラム経由（API/SDK/Infrastructure as Code）で操作可能で、複数のマネージドディレクトリ間での一貫性を保てます。リージョン追加やドメインコントローラのスケールアウト時には、新しいインスタンスへ自動的にこれらの設定が適用されます。具体的な項目は記事中で個別列挙されていませんが、一般に STIG が対象とするパスワード/アカウントポリシー、監査（Auditing）設定、LDAP/Kerberos などのディレクトリセキュリティ関連が想定されます。詳細な設定方法やサポートされる具体的な制御項目は AWS Directory Service Administration Guide を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/アイデンティティ管理者、規制準拠（コンプライアンス）対応チーム、SRE/運用チーム
  • 利用シーン: DISA STIG 準拠が求められる環境や、組織内でディレクトリ構成の一貫性を自動化・強制したい場面（複数ディレクトリの集中管理、リージョン展開時の設定適用）
  • 運用効果: 手動設定ミスの低減、複数環境での一貫したセキュリティ設定の適用、スケールアウト時の設定適用漏れ防止

技術的な注意点 ​

  • IAM権限: Directory Service の設定変更を行うための IAM 権限が必要です（Directory Service 管理系 API へのアクセス権を付与してください）。
  • リージョン制限: 全リージョンで同時に利用可能とは限りません。利用可否は AWS リージョン対応表で確認してください。
  • コスト: 設定自体に追加料金が発生するケースは基本的に少ないですが、設定適用に伴うドメインコントローラの追加やリージョン展開を行うとそれらのリソース料金が発生します。
  • 互換性/影響: 既存のカスタム設定やアプリケーションの要件と矛盾する可能性があるため、まずステージング環境で検証してください。特定の設定変更は認証やレプリケーションに影響を与えることがあります。
  • 適用範囲と永続性: 管理者が宣言した設定は AWS が実装し永続化します。リージョン拡張やスケールアウト時に新しいドメインコントローラへ自動適用されますが、詳細な挙動（既存インスタンスへの即時反映やロールバック方法）はドキュメントで確認してください。
  • テスト/ロールバック: 本番環境適用前に影響範囲の確認とロールバック手順を用意してください。特に認証周り（Kerberos、LDAP、パスワードポリシー）への影響は注意が必要です。

参考情報 ​

[Elemental Mediatailor] AWS Elemental MediaTailor now provides automatic secure server-to-server integration with Google's ad platforms ​

概要 ​

AWS Elemental MediaTailorがGoogleの広告プラットフォーム（GAM、GCM、DV360）へのサーバー間接続を自動的に認証する機能を提供開始しました。これにより、従来必要だったAWSサポート経由の有効化や許可リスト登録が不要になり、Google向けのSSAI（サーバーサイド広告挿入）連携がシームレスになります。

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

MediaTailorはサーバーサイド広告挿入（SSAI）で配信中の動画に対して広告リクエストやインプレッション追跡を行います。GoogleはSSAIプロバイダに対して広告リクエストおよびトラッキングイベントの送信時に安全で認証されたサーバー間接続を要求しており、本アップデートによりMediaTailorはGoogleの広告サーバー宛てリクエストを自動検出して必要な認証付き接続を確立します。具体的には、Google Ad Manager（GAM）向けのサーバーサイド広告リクエストは自動的に保護され、Authorized Buyers（Googleのリアルタイム広告マーケットプレイス）へのアクセス要件を満たします。Google Campaign Manager（GCM）およびDisplay & Video 360（DV360）向けのインプレッション追跡リクエストはGoogleの認証エンドポイント経由でルーティングされ、より正確なレポーティングと拒否インプレッションの削減を支援します。その他の広告リクエスト動作は変更されません。機能はMediaTailorが利用可能な全リージョンで提供され、追加費用は発生しません。

影響範囲・利用シーン ​

  • 対象ユーザー: 動画配信事業者、OTTプラットフォーム、パブリッシャー、広告運用者、SRE/運用チーム
  • 利用シーンまたは効果: SSAIを使った個別化広告配信でGoogleの広告プラットフォーム（GAM/GCM/DV360）と安全に連携し、Authorized Buyers参加やインプレッション計測精度を確保
  • 運用効果: AWSサポートへの連絡や許可リスト登録が不要になり、オンボーディングが迅速化。誤拒否されたインプレッションの減少とレポート精度向上で広告収益化の安定化が期待できる

技術的な注意点 ​

  • IAM権限: MediaTailor設定やチャネル管理には該当するIAM権限（mediatailor:*等）が必要。自動化機能自体は顧客操作不要だが、MediaTailorリソースを変更する権限は確認してください
  • リージョン制限: MediaTailorが提供されている全リージョン（記事記載のUS/EU/Asia等複数リージョン）で利用可能。詳細はドキュメントで最新の対応リージョンを確認してください
  • コスト: 本機能に追加料金は発生しません。ただしMediaTailorの通常料金（リクエスト処理やアウトバウンドデータ転送など）は適用されます
  • 互換性: 本機能はサーバー間（サーバー→Google広告サーバー）リクエストにのみ影響します。クライアントサイド広告挿入や非Googleの広告エンドポイントには影響しません
  • 監視/トラブルシューティング: 関連のログ・メトリクスはCloudWatchやMediaTailorのアクセスログで確認可能。Google側での拒否が発生する場合は広告タグ設定やGoogle側のアカウント設定（Authorized Buyers設定等）も合わせて確認してください
  • その他: 以前必要だったAWSサポート経由の許可リスト登録は不要になりましたが、Google側のアカウント構成や広告タグの指定が正しいことは引き続き必要です

参考情報 ​

[Serverless Application Model Sam] AWS SAM CLI adds BuildKit support for AWS Lambda functions packaged as container images ​

概要 ​

AWS SAM CLIがBuildKitをサポートし、DockerfileからLambdaコンテナイメージをビルドする際に高速化・最適化されたビルド機能（マルチステージ、改善されたキャッシュ、並列化、クロスアーキテクチャ、ビルド時シークレットなど）が利用可能になりました。sam buildで--use-buildkitフラグを使うことで有効化できます。

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

BuildKitはDockerの次世代ビルドエンジンで、SAM CLI（バージョン1.159.0以上）から利用可能になりました。主な技術的利点は以下です。

  • マルチステージビルド: 開発依存を最終イメージに含めずに小さく最適化されたイメージを作成できます。
  • 改善されたレイヤーキャッシュ: 変更が小さい箇所のみ再ビルドすることで再ビルド時間を短縮できます。リモートキャッシュやbuildxのキャッシュ機構と組合せ可能です。
  • ビルドステップの並列化: 複数ステップをより効率的に実行して全体のビルド時間を短縮します。
  • クロスアーキテクチャビルド: 同一開発マシンからx86_64とarm64（例: AWS Graviton2）向けイメージをビルドできます（platform指定やbinfmt/qemuの準備が必要となる場合があります）。
  • BuildKitシークレット: ビルド時に認証情報やAPIキーなどを渡して最終イメージに含めない構成が可能です。 SAM CLI側の操作はシンプルで、sam build --use-buildkit を実行するだけでBuildKitを利用したビルドが行えます。BuildKitの機能はDockerとFinchのいずれのランタイム利用時にもアンロックされます。最終的に作成したコンテナイメージは通常どおりECRへプッシュしてLambdaにデプロイします。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバーレス開発者、DevOps/CIエンジニア、SRE
  • 利用シーン: ローカルおよびCI環境でのコンテナイメージビルド（マルチステージで小型化したLambdaイメージ、Graviton対応イメージの生成、ビルド時に秘密情報を安全に扱うケース）
  • 運用効果: ビルド時間短縮、イメージサイズ削減によるデプロイ高速化とコスト削減、クロスアーキテクチャ対応によるGraviton移行の容易化、ビルド時シークレットで安全性向上

技術的な注意点 ​

  • SAM CLIバージョン: sam CLI 1.159.0 以上が必要です
  • 有効化方法: sam build --use-buildkit フラグを使用してBuildKitを有効化します
  • コンテナランタイム: DockerまたはFinchで動作します。ローカル実行環境にBuildKit対応のDockerが必要です
  • クロスアーキテクチャ: arm64向けビルドにはbinfmt/qemuやDocker buildxの準備が必要になる場合があります（環境依存）
  • BuildKit依存: 古いDocker Engineや無効化されたBuildKitでは動作しないことがあります。必要に応じてDOCKER_BUILDKIT=1やbuildxを使って設定してください
  • セキュリティ: BuildKitのシークレットはビルド時に渡す方式ですが、Dockerfileの書き方次第で誤ってシークレットをイメージに残す可能性があるため注意が必要です
  • CI/CDとの併用: キャッシュ（ローカル/リモート）を適切に設定するとCIのビルド時間を大幅に短縮できます
  • IAM権限: ECRへプッシュする場合は適切なIAM権限（ecr:PutImage等）が必要です
  • コスト: ローカルビルド自体にAWS側の追加料金は発生しませんが、生成イメージのECR保存・転送には通常のストレージ/データ転送コストが発生します
  • リージョン制限: 本機能はローカルビルド機能でありリージョン制限は特にありません（ただしECR利用時はECRのリージョンに依存）

参考情報 ​

[API Gateway] AWS SAM now supports WebSocket APIs for Amazon API Gateway ​

概要 ​

AWS Serverless Application Model (AWS SAM) が Amazon API Gateway の WebSocket API をネイティブにサポートするようになりました。SAM テンプレートで最小限の定義だけで完全な WebSocket API を生成・管理できます。

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

新しく追加されたリソースタイプ AWS::Serverless::WebSocketApi により、SAM テンプレート上で $connect、$disconnect、$default などのルートおよびカスタムルートを Lambda ハンドラーにマッピングして定義できます。SAM はテンプレートから CloudFormation リソース（例: AWS::ApiGatewayV2::Api、Route、Integration、Stage、DomainName、ApiMapping、Models、RouteSettings など）を自動生成し、各ルートの統合設定と必要な権限（Lambda へのリソースベースポリシーや実行ロール）を自動で作成します。これにより、従来手動で設定していた IAM 権限不足や統合ミスといったトラブルシューティングが軽減されます。機能面では API Gateway の WebSocket API と機能同等（IAM および Lambda 認可、カスタムドメイン、RouteSettings、Models、StageVariables）を提供し、Globals セクションで複数の WebSocket API に共通設定を適用できます。導入はテンプレートに AWS::Serverless::WebSocketApi を追加し、Route 定義で Lambda 関数を指定するだけです。SAM はルートごとの統合・権限を自動で配線し、認可設定やステージ設定、カスタムドメインもリソース定義内で設定可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバーレス開発者、バックエンドエンジニア、リアルタイムアプリ開発チーム（チャット、ライブダッシュボード、LLM/ストリーミング、IoT）
  • 利用シーン: WebSocket を使った双方向リアルタイム通信の API をサーバーレスで迅速に構築・デプロイする場面（$connect/$disconnect/$default とカスタムルートのハンドリング）
  • 運用効果: マニフェストベースでの定義により CloudFormation テンプレートの手作業の削減、Lambda と API Gateway 間の権限設定ミスの低減、共通設定の再利用（Globals）による運用効率向上
  • 移行効果: 既存で手動構成している API Gateway WebSocket を SAM 管理下に移すことで管理一元化とデプロイ自動化が容易に可能

技術的な注意点 ​

  • IAM権限: SAM は Lambda への AWS::Lambda::Permission や必要な実行ロールなどを自動生成しますが、デプロイに使用する IAM ユーザー/ロール（CloudFormation 実行ロール / SAM CLI の認証情報）に必要な権限があることを事前に確認してください
  • SAM/CLI バージョン: この機能を使うには対応する新しい AWS SAM (テンプレート変換) と SAM CLI のバージョンが必要です。古い CLI/transform では未対応の可能性があるためアップデートしてください
  • リージョン制限: WebSocket API 自体がサポートされているリージョンでのみ利用可能です。リージョンごとの API Gateway サービス提供状況を確認してください
  • コスト: API Gateway（WebSocket）のコスト（接続時間、メッセージ数、データ転送）および関連する Lambda 実行コストが発生します。カスタムドメインや ACM 証明書利用に伴う別途料金は通常ありませんが、全体コストに注意してください
  • 破壊的変更の注意: Route/Stage 等のリソース変更はデプロイ時に置換（replacement）や一時的な接続切断を引き起こす可能性があります。ステージ運用中の変更は影響範囲を考慮して行ってください
  • ローカルテスト: sam local の WebSocket サポートやエミュレーションは限定的な場合があるため、本番同等の動作検証はデプロイ先環境でのテストを推奨します

参考情報 ​

[ElastiCache] Amazon ElastiCache adds thirteen new Amazon CloudWatch metrics for network capacity planning and engine diagnostics ​

概要 ​

Amazon ElastiCache はノード単位クラスタ向けに13個の新しい CloudWatch メトリクスを追加しました。これによりネットワーク容量（スロットリング）、メモリ断片化、接続枯渇などのホスト／エンジンレベルの診断を直接 CloudWatch で行えるようになります。

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

今回追加された 13 のメトリクスはホスト（ノード）レベルとエンジンレベルの診断を目的としており、個々のノードに対して INFO コマンドを実行したり、生のバイトカウンタからベースラインを算出したりする必要を無くします。主なカテゴリと代表メトリクスは以下の通りです。

  • ネットワーク容量: NetworkBaselineUsageInPercentage, NetworkBaselineUsageOutPercentage, NetworkBaselineMaxUsageInPercentage, NetworkBaselineMaxUsageOutPercentage

    • インスタンスタイプごとのネットワークベースラインに対する利用率を示します。100%超はバーストクレジット消費中であり、持続的負荷が続くとクレジット枯渇→スロットリングに繋がる予兆です。Max 系は秒単位のバーストを可視化し、平均化された指標で見えにくい瞬間的なピークを抽出します。

  • メモリ健全性: UsedMemoryDataset, AllocatorFragmentationBytes, AllocatorFragmentationRatio, MajorPageFaults

    • UsedMemoryDataset はエンジンオーバーヘッドを除いた実データ領域のメモリ使用量を報告します。AllocatorFragmentation* はメモリアロケータ由来の断片化を分離して報告し、active-defrag 等の設定変更が有効かどうか判断できます。MajorPageFaults は OS レベルのページフォルトを示し、エンジンからは見えにくいメモリ圧迫を検出します。

  • 接続性健全性: BlockedConnections, RejectedConnections

    • BlockedConnections はブロッキングコマンド待ちで停滞している接続数、RejectedConnections は maxclients 到達で拒否された接続数を示します。RejectedConnections が増えている場合は maxclients の引き上げやクライアント側の接続プールリーク調査が必要です。

  • Pub/Sub ワークロード: PubSubChannels, PubSubShardChannels

    • 各ノードで稼働中のクラシックチャンネル／シャードチャンネル数を報告します。クラシックチャンネル数増加と利用率上昇が同時に起きる場合はシャード化を検討して水平スケールさせる手がかりになります。

  • コマンドスループット: ProcessedCommands

    • 全コマンドタイプに対する合計スループットを示します。

これらのメトリクスは node-based クラスタ（ノード単位クラスタ）で利用可能で、CloudWatch の AWS/ElastiCache 名前空間に出力されます。ElastiCache コンソールのモニタリングタブや CloudWatch コンソールで確認でき、メトリクス自体の追加コストは発生しません（ただし CloudWatch のアラーム/ダッシュボード/API 呼び出し等は通常の課金対象となります）。また、Max 系のメトリクスは平均化で埋もれる短時間のピークを検出できる点が運用上有用です。

影響範囲・利用シーン ​

  • 対象ユーザー: ElastiCache を運用・監視する SRE／DBA／アプリケーションエンジニア
  • 利用シーンまたは効果: ネットワークバースト消費の早期検出、メモリ断片化の可視化、接続制限による拒否の検出、Pub/Sub スケーリング判断、全体的なコマンドスループット監視により障害予防と性能問題の特定が容易になる
  • 運用効果: 個々のノードで INFO 実行や生データの集計を行わずにホスト健全性を把握でき、閾値アラームによる自動検知・対応が可能になる（例: RejectedConnections 発生時に maxclients 増加やアラート発行）
  • 制限・注意: node-based（ノード単位）クラスタに限定されるため、クラスタ構成やエンジン互換性については導入前に確認が必要

技術的な注意点 ​

  • IAM権限: CloudWatch メトリクス閲覧のために cloudwatch:ListMetrics, cloudwatch:GetMetricData/GetMetricStatistics; ElastiCache コンソールでメトリクスを参照する場合は elasticache:Describe* 系の権限が必要になる可能性があります
  • リージョン制限: 商用 AWS リージョンおよび ElastiCache がサポートされている AWS China / AWS GovCloud (US) リージョンで利用可能（記事記載の通り）。ただしお使いのリージョンでの反映状況はコンソールで確認してください
  • コスト: メトリクス自体は追加料金なしで提供されますが、CloudWatch のアラーム数、ダッシュボード、GetMetricData API 呼び出し等は通常の CloudWatch 課金対象です。多数のノードで高頻度に取得する場合はコスト増の可能性があります
  • 対応範囲: node-based クラスタ（ノード単位）向けのホスト／エンジンレベル診断メトリクスです。クラスタ構成やエンジンバージョンによる差異があるため、詳細はドキュメントで確認してください
  • 運用上のポイント: NetworkBaseline* の 100% 超はバーストクレジット消費を示すため、持続的な高負荷ではインスタンスタイプ変更やネットワーク帯域拡張の検討が必要です。AllocatorFragmentation* は active-defrag 等のメモリ断片化対策で改善される場合があります。RejectedConnections は即時対応の優先度が高い指標です

参考情報 ​

[Workspaces] Amazon WorkSpaces now lets AI agents operate desktop applications (Preview) ​

概要 ​

Amazon WorkSpacesがプレビュー機能として、AIエージェントに対して管理されたクラウドデスクトップ上のアプリを安全に操作させる機能を提供します。MCP（Model Context Protocol）でエージェントを接続し、既存のデスクトップアプリをアプリ改修せずに自動化できます。

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

本機能は、WorkSpacesの管理されたデスクトップ環境上でAIエージェントが人間と同様に“ポイント・クリック・ナビゲート”してデスクトップアプリケーション（レガシーのメインフレーム端末、ERP、独自ツール等）を操作できるようにするものです。エージェント側は任意のフレームワークで構築し、クラウド／オンプレ／ハイブリッドどこからでも動作可能で、業界標準のModel Context Protocol（MCP）による統合で最小限の実装工数で接続できます。IT管理者は既存のWorkSpacesと同様の中央集権的な権限管理、ログ収集、監査（CloudTrail/CloudWatch等を想定）を適用でき、スクリーンショットや操作メトリクスなどのエンタープライズ向け可観測性機能によりエージェント活動の可視化が可能です。これによりアプリケーションのモダナイズを行わずに、保険請求処理、決済／決済照合、候補者スクリーニング、バックオフィス処理など規制のある業界での業務自動化が促進されます。課金は従量制（pay-as-you-go）かつAWSのグローバルインフラでの弾性的スケールを活かせるため、インフラ維持コストの削減と迅速な導入が見込めます。なお本機能は「Preview」で提供されるため、一般提供（GA）時に仕様やリージョンサポート、料金体系が変更される可能性があります。

影響範囲・利用シーン ​

  • 対象ユーザー: デスクトップアプリに依存した業務を持つエンタープライズ（SRE/運用、RPA/自動化チーム、AIエンジニア、セキュリティ/コンプライアンス担当）
  • 利用シーン: レガシーGUIベースの業務プロセス自動化（請求処理、決済照合、HRの候補者スクリーニング、バックオフィス操作など）、API未提供アプリの“最後の一歩”の自動化
  • 運用効果: アプリ改修不要でAIを迅速に業務に組み込めるためTCO低減と導入時間短縮、中央管理されたログ/監査でガバナンスを維持しつつスケール可能
  • セキュリティ・コンプライアンス: 管理されたWorkSpaces環境を通すことでセッション隔離・監査証跡（スクリーンショット/メトリクス）を確保し、規制業界での利用ケースに適合しやすい

技術的な注意点 ​

  • IAM権限: WorkSpaces管理、起動/終了、ログ取得等の権限設定が必要。エージェント用の最小権限ポリシー設計を推奨
  • リージョン制限: プレビュー段階では提供リージョンが限定される可能性あり。事前に対応リージョンを確認してください
  • コスト: WorkSpacesの利用料金（時間/固定）、ログ保管（CloudWatch、S3等）、データ転送費が発生する可能性があります。従量課金の内訳はプレビュー/GAで変わる可能性あり
  • ネットワーク要件: WorkSpacesがアクセスするオンプレ/内部システムとの接続（VPCピアリング、VPN、Direct Connect等）が必要な場合あり。エージェントが操作するアプリのネットワーク到達性を確認してください
  • ログ・監査: スクリーンショットや操作メトリクスは保存先・保持期間・漏えい対策を設計する必要があります。CloudTrail/CloudWatchとの連携設計を検討してください
  • セキュリティ注意点: エージェントの認証情報管理、秘密情報の扱い（入力自動化によるCredential流出リスク）、DLPルールの適用を必須で検討してください
  • MCP互換性: エージェント側はModel Context Protocol準拠での統合が必要です。MCP対応フレームワーク／ライブラリの確認と実装が必要
  • プレビュー注意: PreviewはAPI/機能/リージョン/料金が変わる可能性があり、SLAや長期サポートは保証されないことに留意してください

参考情報 ​

[General] AWS IoT Core for Device Location adds Confidence Level Configuration and Measurement Type support ​

概要 ​

AWS IoT Core for Device Locationは、位置解決の信頼度（Confidence Level）を50%〜99%の範囲で指定できる機能と、解決された位置情報のメタデータに測定タイプ（measurementType）を追加しました。これにより、精度と信頼度のトレードオフを制御でき、位置決定手法の可視化が可能になります。

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

主な変更点は2つです。

  1. Confidence Levelの設定: Cell ID、Wi‑Fi、Cell+Wi‑Fiソルバーを使用する際に、位置解決リクエストで希望する信頼度（50%〜99%）を指定できるようになりました。ここでの「信頼度」は、報告された精度半径（accuracy radius）内に実際の端末が存在する確率を統計的に表したものです。信頼度を高く設定すると（例：95%）その確率は上がりますが、返される精度半径は大きくなります。逆に低い信頼度（例：50%）では半径は小さくなりますが確実性は低くなります。現時点ではこのConfidence Levelの指定はHTTPベースの位置解決リクエストでサポートされています。
  2. measurementTypeフィールドの追加: 解決された位置情報のメタデータにmeasurementTypeフィールドが追加され、各位置がGNSS（GPS等）、Wi‑Fi、BLE（Bluetooth Low Energy）などどのロケーションリゾルバ／測定手段で判定されたかが明示されます。これにより、位置データの品質評価や位置決定のデバッグ、条件に応じたフィルタリング（例えばGNSSのみを採用するなど）が容易になります。 なお、これらの更新はAWS IoT Core for Device Locationがサポートする全リージョンで利用可能です。実装・利用方法の詳細はAWSのDeveloper Guide（Device LocationおよびIoT Wirelessのドキュメント）を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: IoTデバイス開発者、位置情報を扱うアプリケーション開発者、SRE/運用チーム、位置情報品質を評価するデータ分析者
  • 利用シーン: ジオフェンシングや資産追跡で精度と確度のバランスを調整する場合（例：重要資産は高信頼度を要求、一般トラッキングは小さい半径で頻繁に位置更新）
  • 運用効果: 位置解決の信頼度をアプリ要件に合わせて制御できるため、誤検知の低減やアラート閾値調整が容易になる
  • データ品質管理: measurementTypeにより測位手法ごとの信頼度差を定量的に扱えるため、低品質データの除外や重み付けが可能
  • 互換性影響: 既存の位置処理ロジックでaccuracy radiusや位置ソースを前提にしている場合、信頼度設定やmeasurementTypeの導入に応じたロジック修正が必要になる可能性がある

技術的な注意点 ​

  • 対応ソルバー: Confidence LevelはCell ID、Wi‑Fi、Cell+Wi‑Fiソルバーでサポートされています（GNSS専用の処理には影響しません）
  • プロトコル制限: Confidence Levelの指定は現時点でHTTPベースの位置解決でのみサポートされています（MQTT等の他プロトコルでの可否はDeveloper Guideを確認してください）
  • リージョン制限: 本機能はAWS IoT Core for Device Locationがサポートする全リージョンで利用可能とされていますが、個別リージョンのサービス提供状況は公式ドキュメントで確認してください
  • API/SDK: 実際の設定方法（リクエストパラメータ名やレスポンスのmeasurementTypeフィールド名など）はDeveloper Guideおよび最新SDKのリファレンスを参照し、必要に応じてSDKを最新版にアップデートしてください
  • 互換性: measurementTypeフィールドはレスポンスに新たに追加されるメタデータです。既存のパーサやログフォーマットが新フィールドを想定していない場合は処理対応が必要です
  • 精度とコスト: 高い信頼度指定は返されるaccuracy radiusが大きくなるため、位置に基づく処理（例：通知範囲の判定）やデータ集計ロジックへの影響を検証してください。位置解決リクエスト数や頻度が増えると通信コストやAPI利用コストに影響する可能性があります
  • プライバシー: measurementTypeにより測位手法が明示されるため、利用用途によってはユーザープライバシーや同意管理に注意してください
  • 権限: 位置解決APIの呼び出しには適切なIAM権限が必要です。実運用では最小権限の原則に基づいた権限設定を推奨します

参考情報 ​

[Govcloud Us] Amazon MQ now supports in-place major version upgrades for RabbitMQ 4 ​

概要 ​

Amazon MQがRabbitMQブローカーに対するインプレース（既存ブローカー上での）メジャーVersionアップグレードをサポートし、RabbitMQ 3.13から4.2へデータ移行や新ブローカー作成なしでアップグレードできるようになりました。アップグレードはコンソール、AWS CLI、APIで実行可能です。

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

Amazon MQはRabbitMQのメジャーアップグレードをインプレースで実行できる機能を追加しました。対象はRabbitMQ 3.13からRabbitMQ 4.2へのアップグレードで、ブローカーの設定、キュー、exchange、binding、ユーザー、ポリシーなどのメタデータを保持したまま移行できます。RabbitMQ 4.2は互換性に影響する変更（classic mirrored queuesの削除、メタデータストアのMnesiaからKhepriへの移行など）を含むため、classic mirrored queuesを使用しているブローカーは事前にクォーラムキュー等へ変換する必要があります。対象ブローカーはM7G（Graviton）インスタンスタイプで稼働している必要があり、classic mirrored queuesを持たないことが条件です。classic mirrored queuesをクォーラムキューに変換するためのキュー移行ツールが提供されています。メジャーアップグレード実行中はブローカーが利用不可（ダウンタイム）となります。アップグレードはAWS Management Console、AWS CLI、AWS SDKsから行え、Amazon MQはRabbitMQ 4.2のパッチ（マイナー/パッチ）バージョンの自動管理を行うため、ユーザーはmajor.minor（例: 4.2）を指定するだけで運用可能です。機能はRabbitMQ 4インスタンスが提供されている全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: メッセージング基盤をAmazon MQ（RabbitMQ）で運用している開発者、SRE、プラットフォームチーム
  • 利用シーンまたは効果: 既存ブローカーを停止して新規ブローカーへデータ移行することなく、RabbitMQ 4の機能（Khepriメタデータ、クォーラムキューなど）へ移行可能。運用負荷と移行工数の削減に寄与
  • 運用影響: メジャーアップグレード中はブローカーが利用不可（ダウンタイム発生）。classic mirrored queues利用中は事前移行が必要で、移行作業の計画が必須
  • 互換性リスク: RabbitMQ 4.2は破壊的変更を含むため、アプリケーションや運用ツール側での互換性検証が必要

技術的な注意点 ​

  • インスタンスタイプ: 対象はM7G（Graviton）インスタンスタイプで稼働しているブローカーのみ
  • 古典ミラーキュー: classic mirrored queuesはRabbitMQ 4で削除されるため、事前にクォーラムキュー等へ移行する必要あり（移行ツールあり）
  • ダウンタイム: メジャーアップグレード中はブローカーが利用不可になります。業務影響を考慮したメンテナンス時間の計画を行ってください
  • 自動パッチ管理: Amazon MQはRabbitMQ 4.2のパッチ（マイナー）アップデートを自動で管理するため、ユーザーはmajor.minorを指定します
  • リージョン制限: RabbitMQ 4インスタンスが利用可能なリージョンでこの機能が提供されます（GovCloudカテゴリでの発表だが、機能自体は提供リージョンに依存）
  • IAM権限: ブローカーのアップグレードにはAmazon MQの管理操作（UpdateBroker等）を実行できるIAM権限が必要です。CLI/SDK/コンソール操作を行うユーザーに適切なIAMポリシーを付与してください
  • コスト: アップグレード自体で追加課金は発生しない想定ですが、インスタンスタイプ要件や移行作業（テスト、追加リソース）に伴うコスト増加の可能性あり
  • 事前準備: classic mirrored queuesの有無確認、M7Gへのインスタンスタイプ変更（未実施の場合は計画）、アプリケーション互換性テスト、バックアップ/スナップショット取得を推奨

参考情報 ​

[General] Amazon Quick now integrates with New Relic for observability-driven AI agents ​

概要 ​

Amazon QuickがNew RelicのAIエージェントと連携可能になり、オンコールエンジニアやSREがQuickの会話UI内で観測データを横断してインシデント調査、RCA作成、タスク作成・追跡を行えるようになりました。Quick Flowsから定型トリアージやエスカレーションの自動化も可能です。

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

本統合はQuickからNew RelicのリモートModel Context Protocol（MCP）サーバーへ接続し、New Relic側のAIエージェントを会話プロンプトから直接呼び出せるようにするものです。呼び出せる機能にはアラート洞察（alert insights）、ユーザー影響分析、ログ解析、トランザクション診断、自然言語NRQLクエリなどが含まれます。単一のチャット操作で観測データを横断的に調べ、エビデンスリンク付きのRCAドキュメントを生成してメール添付で送信したり、生成したタスクをトラッキングしたりできます。Quick Flows（ワークフロー自動化）からNew Relicエージェントを組み込み、定期的なトリアージやエスカレーション手順を自動化することも可能です。さらにQuickはSpacesに格納された組織固有の知識（ランブック、設計書、オンコールポリシー等）とリアルタイムのテレメトリを合わせて回答を生成するため、回答は組織コンテキストを反映します。本機能はAmazon Quickが提供されている全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: オンコールエンジニア、SRE、信頼性/運用チーム、エンジニアリングマネージャー
  • 利用シーン: インシデントの迅速な調査と根本原因分析（RCA）作成、ログやトレースを横断した診断、自然言語でのNRQLクエリによるメトリクス抽出、定型トリアージやエスカレーションの自動化
  • 運用効果: 調査時間短縮、人的ミス低減、RCA作成の効率化と証跡付与により事後対応の品質向上
  • 導入効果: Quick上で組織知とライブテレメトリを結合できるためオンコール負荷の軽減と意思決定の速さが向上

技術的な注意点 ​

  • New Relic側設定: New RelicアカウントでMCP（Model Context Protocol）エンドポイントと該当AIエージェントを有効にし、必要なAPIキー/認証情報を準備してください
  • 認証/権限: QuickからNew Relicへ接続するための資格情報管理（シークレットストアや統合設定）およびQuick上でのユーザー権限設定を確認してください
  • ネットワーク/データ転送: Quickが外部のMCPエンドポイントにアクセスできるようにネットワーク経路（プロキシ、アウトバウンドアクセス、ファイアウォール設定）を許可してください。クロスリージョン通信によるネットワークコストが発生する場合があります
  • データ共有とコンプライアンス: 観測データやログ、トレースがNew Relic経由で処理・保存される可能性があるため、機密データの取り扱い・マスキング・保持ポリシーを事前に確認してください
  • リージョン制限: 記事では "Amazon Quickが利用可能な全リージョン" で利用可能とされていますが、組織のリージョンポリシーやデータ主権要件を確認してください
  • コスト: New RelicのAI機能利用料およびAmazon Quick自体の利用料（ある場合）が発生する可能性があります。さらに、データ転送（クロスリージョン）や保存による追加コストにも注意してください
  • 監査/ログ: 統合の利用やAPI呼び出しの監査ログ（Quick側、New Relic側）を有効化し、アクセスと操作のトレーサビリティを確保してください

参考情報 ​

[Ec2] EC2 Instance Store CSI driver now generally available in EKS add-ons ​

概要 ​

Amazon EKSでEC2 Instance Store CSIドライバーがEKSアドオンとして一般公開され、EKSコンソールおよびAWS CLIから簡単にインストール・管理できるようになりました。これにより、EC2のローカル（インスタンスストア）NVMeボリュームをKubernetesのPersistentVolumeとして利用できます。

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

Amazon EC2 Instance Store CSIドライバーは、EC2インスタンスに物理的に接続されたエフェメラルなブロックストレージ（インスタンスストア/NVMe）をKubernetesに提供するCSIプラグインです。EKSアドオンとして提供されることで、EKSコンソールやAWS CLIからドライバーのインストール・アップデート・管理が可能になり、インスタンスストアのライフサイクル（アタッチ/デタッチ/フォーマット等）をドライバーが管理してPersistentVolume（PV）として利用できるようになります。この記事によれば、本機能は全ての商用リージョンで利用可能です。ドライバー自体に追加課金はなく、インスタンスストアを持つEC2インスタンス上でのみ使用できます。インスタンスストアはホストに直接接続された一時ストレージであり、インスタンスの停止・終了・置換でデータは消失します。

影響範囲・利用シーン ​

  • 対象ユーザー: EKSを利用するクラウドエンジニア、Kubernetesアプリ開発者、SRE/運用チーム
  • 利用シーンまたは効果: 高IOPS/低レイテンシの一時ストレージが必要なワークロード（キャッシュ、バッファ、テンポラリファイル、ビルド/CIジョブ、データ処理のワークスペースなど）に適する
  • 運用効果: EKSコンソール/CLIからアドオンとして簡単に導入・管理でき、ローカルNVMeの性能をKubernetes上で直接活用できるためパフォーマンス改善が期待できる
  • 制約: データはインスタンスの停止・終了・置換で失われるため永続データ保存には不向き。利用可能なインスタンスタイプが限定される

技術的な注意点 ​

  • IAM権限: EKSアドオンの作成/更新/削除（eks:CreateAddon 等）を実行できる権限が必要。アドオン導入時に作成されるIAMロールやServiceAccountの設定を確認してください
  • リージョン制限: 記事では「全ての商用リージョンで利用可能」と明記。Gov/Chinaなど非商用リージョンの対応は個別確認が必要
  • インスタンスタイプ: インスタンスストア（NVMe）を提供するEC2インスタンスタイプでのみ利用可能。インスタンスによってはインスタンスストアを持たないため事前に確認が必要
  • データ永続性: インスタンスストアはエフェメラルストレージです。耐久性が必要なデータはEBS/EFS/S3等の永続ストレージを併用してください
  • ノードスケジューリング: PVは物理ノードに結び付くためPodは該当ノードにスケジュールされる（データローカリティ／ノード置換時の再スケジュール戦略を設計してください）
  • 互換性/前提: EKSクラスターがアドオン管理をサポートしている必要があります。利用するKubernetesバージョンやAMIによる制約がある場合があるため導入前に公式ドキュメントで互換性を確認してください
  • コスト: ドライバー自体の追加料金はないが、インスタンスタイプ選定によるEC2コストや、データ損失対策（バックアップやレプリケーション）に伴う追加コストが発生する可能性があります

参考情報 ​

[Connect] Amazon Connect Cases now supports customer profile identity resolution ​

概要 ​

Amazon Connect Casesが、Amazon Connect Customer ProfilesのIdentity Resolutionで重複プロファイルをマージした際に、自動でケースを再関連付けするようになりました。これによりエージェントは顧客ごとの完全なケース履歴を一箇所で参照できます。

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

変更はCasesとCustomer Profiles間の連携強化で、Identity Resolution（重複プロファイル検出・マージ）が実行されると、Cases側の関連ケースも統一されたプロファイルに自動的に再関連付けされます。複数チャネルや異なる連絡先情報により同一顧客が複数プロファイルとして存在する場合でも、重複が検出・マージされれば、マージ後の単一プロファイルに紐付く全ケースがまとめて表示されます。これによりエージェントは複数プロファイルを横断して履歴を手作業で追う必要がなくなります。機能は以下のリージョンで利用可能です: US East (N. Virginia)、US West (Oregon)、Canada (Central)、Europe (Frankfurt)、Europe (London)、Asia Pacific (Seoul)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Africa (Cape Town)。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンター運用者、エージェント、Amazon Connect導入/管理者、CRM統合担当者
  • 利用シーン: チャネル横断で同一顧客が複数プロファイルを持つケース（電話・チャット・メールなど）を統合して、顧客対応時に一貫した履歴表示を行う場面
  • 運用効果: エージェントによるプロファイル横断検索や手動突合せの削減、平均処理時間（AHT）や解決率の向上、ケースデータの一貫性向上

技術的な注意点 ​

  • IAM権限: Amazon Connectインスタンスや運用ロールがCustomer Profilesへのアクセス権限を持っていることを確認してください（インスタンスプロファイル/サービスロールの設定、必要なAPIアクセス権の付与）。エージェントや管理者のIAMポリシーでCasesおよびCustomer Profilesの参照権限を許可する必要があります。
  • リージョン制限: 本機能は記事記載のリージョン（US East (N. Virginia)、US West (Oregon)、Canada (Central)、Europe (Frankfurt)、Europe (London)、Asia Pacific (Seoul)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Africa (Cape Town)）で利用可能です。これ以外のリージョンでは未対応の可能性があるため、事前確認してください。
  • コスト: Customer ProfilesのIdentity ResolutionやAmazon Connect Casesの利用はそれぞれ課金対象となる場合があります。重複検出・マージ処理やCasesのストレージ/API利用に伴うコスト影響を事前に確認してください（料金ページを参照）。
  • 設定/運用注意: Identity Resolutionのマッチングルールやしきい値設定によって誤マージのリスクがあるため、ルール設計と検証（ステージ環境でのテスト）を推奨します。マージの監査ログや履歴保持の運用ポリシーも確認してください。

参考情報 ​

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

Copyright © 2026