AWS What's New Digest

Appearance

2026年08月18日 ​

[Workspaces] Amazon WorkSpaces now supports Nested Virtualization ​

概要 ​

Amazon WorkSpacesがネスト型仮想化（Nested Virtualization）をサポートしました。WindowsおよびLinuxのWorkSpaces上でDocker Desktop、WSL2、KVMベースのワークロードやエミュレータなどを直接実行できます。

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

ネスト型仮想化を有効にすると、Windows WorkSpaces上でDocker DesktopやWindows Subsystem for Linux (WSL2) などハイパーバイザ依存のツールを、Linux WorkSpaces上でKVMベースのワークロード、Androidエミュレータ、ネストコンテナを実行可能になります。サポート対象はAmazon WorkSpaces PersonalおよびCore Managed Bundlesで、ライセンスインクルード（パブリック／カスタム）、BYOL、BYOPのバンドルで利用できます。サポートOSは Windows Server 2019/2022/2025、Windows 11、Ubuntu 22.04/24.04、Red Hat Enterprise Linux 8/9、Rocky Linux 8/9（Linux側はDCVプロトコルの利用が前提）です。推奨はPower（4 vCPU）以上のバンドル。GPUバンドルおよびPCoIPプロトコル、Windows Server 2016やWindows 10ベースのWorkSpacesではネスト型仮想化はサポートされません。管理者は個々のWorkSpace単位でコンソール、API、CLIからネスト型仮想化を有効／無効にできます。対応リージョンはAmazon WorkSpaces提供リージョンのほとんど（中国（寧夏）リージョンとイスラエル（テルアビブ）リージョンを除く）で利用可能です。詳細はWorkSpacesドキュメントの「Nested Virtualization」と料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者（ローカルでのコンテナ／仮想マシン実行が必要な開発者）、SRE/プラットフォーム/VDI管理者
  • 利用シーン: Docker DesktopやWSL2を用いた開発環境、KVMを使ったテスト／CI、Androidエミュレータやネストコンテナによる検証環境のクラウド移行
  • 運用効果: 物理端末や別ホストを用意せずにWorkSpaces上でネイティブにハイパーバイザ機能を利用できるため、開発者の環境統一・セットアップ時間短縮やオンプレ運用コスト削減に寄与
  • 制約／注意事項: GPUを必要とするワークロードやPCoIPを利用する既存構成は対象外のため、要件に応じてバンドルやプロトコルを見直す必要がある

技術的な注意点 ​

  • IAM権限: 管理者がWorkSpacesを変更できる適切なIAM権限（コンソール/API/CLIでの有効化・無効化が可能な権限）が必要です
  • リージョン制限: 全リージョン対応（Amazon WorkSpaces提供リージョン）だが、中国（寧夏）とイスラエル（テルアビブ）リージョンは除外
  • サポートOS/バンドル: Windows Server 2019/2022/2025、Windows 11、Ubuntu 22.04/24.04、RHEL 8/9、Rocky Linux 8/9 をサポート。ライセンスインクルード、BYOL、BYOPバンドルで利用可
  • プロトコル／ハードウェア制限: DCVプロトコルを利用するLinux WorkSpacesでの利用が前提。GPUバンドルおよびPCoIPプロトコルは非対応。Windows Server 2016/Windows 10ベースのWorkSpacesも非対応
  • 推奨リソース／パフォーマンス: Power（4 vCPU）以上を推奨。ネスト型仮想化はCPU・メモリ負荷が高くなるため、必要に応じて上位バンドルへ変更を検討
  • コスト: 大きめのバンドルを使う可能性やネスト環境の追加リソース消費により料金が増加する場合あり。詳細は料金ページを確認
  • ライセンス／サードパーティ: Docker Desktop等のサードパーティソフトは別途ライセンス条件があるため利用前に確認を推奨
  • 有効化方法: 管理者は個別WorkSpace単位でコンソール、API、CLIからネスト型仮想化を有効／無効化可能。設定変更は即時反映される場合と再起動が必要な場合があるため事前確認を推奨

参考情報 ​

[S3] Amazon S3 Metadata and annotations are now available in AWS GovCloud (US) Regions ​

概要 ​

Amazon S3のMetadataとAnnotations機能がAWS GovCloud (US-East) と AWS GovCloud (US-West) リージョンで利用可能になりました。これにより、S3オブジェクトに紐づくシステムメタデータや最大1GBの業務コンテキスト注釈をオブジェクト単位で扱えるようになり、検索・分析・AI推論に必要なコンテキストをS3内で保持できます。

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

S3 Metadataはオブジェクトサイズやソースなどのシステム定義メタデータを自動的に収集し、Amazon S3 Tablesに保存します。S3 Tablesはリアルタイムに近いタブ型クエリに最適化されており、ビジネス分析やリアルタイム推論での利用を簡素化します。AnnotationsはMetadataを拡張する機能で、JSON、XML、YAML形式のリッチな業務コンテキストをオブジェクトに直接添付できます。1オブジェクトあたり最大1GBまで格納可能で、アノテーションはオブジェクトと同じ耐久性・整合性特性を持ち、オブジェクトのコピー／レプリケーション時に移動し、オブジェクト削除時に除去されます。これにより、別途メタデータストアを構築・維持することなく、AIエージェントや分析ツールがデータを見つけて利用するためのコンテキストを容易に提供できます。Annotationsは全リージョンおよびGovCloudリージョンで利用可能で、S3 Metadata（およびannotation用テーブル）のリージョン対応状況はリージョン一覧で確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドアプリ/データプラットフォーム開発者、データサイエンティスト、AI/MLエンジニア、SRE/運用チーム
  • 利用シーンまたは効果: オブジェクトに業務コンテキストを付与して検索性・発見性を向上（例: データカタログ不要でAIエージェントが適切なデータを特定）
  • 運用効果: メタデータ同期や外部カタログの管理工数を削減、オブジェクトの移動/複製に伴うメタデータ維持が自動化されるため一貫性が保たれる
  • セキュリティ/準拠: GovCloud上での提供により、米国政府向け/コンプライアンス要件のあるワークロードで利用可能（各規制要件は個別に確認が必要）
  • コスト影響: アノテーションの保存やS3 Tablesへのクエリに対して追加料金が発生する可能性があるため、格納サイズやクエリ頻度によりコストが増加する

技術的な注意点 ​

  • IAM権限: アノテーション/メタデータの読み書きに必要なS3権限（およびS3 Tables/関連APIの権限）を確認して最小権限で設定してください。新しいAPIやアクションが導入されている可能性があるため公式ドキュメントでアクション名を確認してください。
  • リージョン制限: 本リリースでAWS GovCloud (US-East) および AWS GovCloud (US-West) に対応しました。Annotationsは全リージョン対応とされていますが、S3 Metadataやannotation用テーブルの利用可否はリージョンごとに異なるため事前にリージョン一覧を確認してください。
  • データ形式/サイズ: アノテーションはJSON/XML/YAMLをサポートし、最大1GB/オブジェクトまで格納可能です。大容量注釈はストレージ・データ転送・クエリコストに影響します。
  • レプリケーション/コピー: アノテーションはオブジェクトとともにコピー/レプリケーションされますが、クロスリージョンレプリケーションやレプリケーションルールの設定によって挙動が異なる場合があるため、設定を確認してください。
  • 整合性/耐久性: アノテーションはオブジェクトと同等の整合性・耐久性を持ちます。オブジェクト削除時にアノテーションも削除されます。
  • コスト: S3 Tablesへの保存やクエリ、アノテーション保持分のストレージなど追加コストが発生する可能性があります。料金ページで見積もりを行ってください。

参考情報 ​

[General] Amazon Bedrock expands API support and introduces Cross Region Inferencing for OpenAI models ​

概要 ​

Amazon BedrockがOpenAI GPT-5.6（Sol、Tera、Luna）をbedrock-runtimeエンドポイントでサポートし、Responses/Converse/Chat Completionsの各OpenAI APIを利用可能にしました。また、GlobalおよびGeoのクロスリージョン推論を導入し、スループット向上と推論コスト低減を実現します。

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

技術的には、OpenAIのGPT-5.6ファミリー（Sol、Tera、Luna）がbedrock-runtimeエンドポイント上でネイティブに動作し、OpenAI互換のResponses API、Chat Completions API、Converse APIを直接呼び出せます。新しいクロスリージョン推論（Cross-Region Inferencing）は自動ルーティング機能を持ち、複数のAWSリージョンにまたがって推論リクエストを分散することで高いスループットを確保します。Geoクロスリージョン（今回はUS Geo／US CRISが追加）はあらかじめ定義した地理内のみでリクエストを処理するため、データがその地理内に留まることを重視するユースケースに適します。Globalクロスリージョンは、OpenAIモデルが提供されている任意の商用リージョンからリクエストを配信し、需要スパイク時の最大スループットを得られるほか、OpenAIモデルに関してはGlobal推論のトークン単価がIn-RegionやGeo推論より低価格に設定されています。さらに、bedrock-runtimeで実行されるこれらのOpenAI API呼び出しは既存のアカウントレベルの制御に統合され、モデル呼び出しログ（S3またはCloudWatch Logsへ出力可能）、CloudWatchメトリクス（呼び出し数、トークン数、レイテンシ、スロットル、エラー等）、およびAWS Cost ExplorerやCost and Usage Reportでの課金内訳が利用できます。クロスリージョン推論は、OpenAIモデルが提供されている全てのAWSリージョンで利用可能です。導入前にGPT-5.6のモデルカードやAmazon Bedrock User Guideを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習プラットフォーム運用者、アプリケーション開発者、SRE/運用チーム、コスト管理担当者
  • 利用シーンまたは効果: 大量同時リクエストのある推論ワークロード（チャットボット、カスタマーサポート、生成AIサービス）でスループットを向上し、需要スパイク時の性能確保とコスト低減を図れる
  • 運用効果: リージョンごとの容量管理が不要になり、オペレーション負荷を削減できる。Geoオプションによりデータ主権/準拠要件に対応可能
  • コスト影響: Global推論はOpenAIモデルに対してトークン単価が低くなるためトークン課金を抑えられる可能性がある一方、クロスリージョン通信や追加ログ/ストレージ利用によるコスト発生も考慮が必要
  • レイテンシ影響: スループットは向上するが、リクエストが別リージョンで処理されるとレイテンシが増加する可能性があるため、対話系サービスではGeoオプションやエンドユーザー位置を考慮した設計が必要

技術的な注意点 ​

  • IAM権限: bedrock:InvokeModel 等のBedrock実行権限に加え、ログ出力先（S3 PutObject、CloudWatch Logs PutLogEvents 等）やCloudWatch Metricsの閲覧権限を付与する必要があります
  • リージョン制限: クロスリージョン推論はOpenAIモデルが提供されているリージョンで利用可能です。全リージョンで一律に提供されるわけではないため、利用前に対象リージョンの提供状況を確認してください
  • コスト: Global推論はトークン単価が低い設定ですが、インターリージョンのデータ転送費や追加ログ保存（S3）・メトリクス費用が発生する可能性があります。Cost ExplorerやCURでモデル別に費用配分を確認してください
  • データ主権/コンプライアンス: Geo推論は指定ジオグラフィ内で処理を完結させるため、データ居住要件への対応に有効ですが、組織の規制要件に照らして設定を確認してください
  • レイテンシ/スループット設計: 高スループットを得るためにリージョン間ルーティングが行われるため、応答時間要件が厳しいケースはGeoやIn-Region優先の設計検討が必要です
  • ログ/監視: bedrock-runtime上のOpenAI API呼び出しは既存のBedrockログ・CloudWatchメトリクス・CURに統合されます。適切なログ保存先とメトリクス監視を設定してコスト・利用状況を可視化してください
  • API互換性: Responses、Chat Completions、Converseの各OpenAI APIがbedrock-runtimeで動作するため、既存のOpenAI互換実装の移行が容易ですが、モデル固有のプロンプト挙動や出力差異はモデルカードで確認してください

参考情報 ​

[ECR] Amazon ECR now supports 25 replication rules per registry ​

概要 ​

Amazon ECR（Elastic Container Registry）は、1つのレジストリあたり設定できるレプリケーションルールの上限を10から25に引き上げました。複数リージョン／複数アカウントへのイメージ配布がより柔軟になります。

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

これまで1レジストリあたり最大10ルールだったレプリケーションの上限が25ルールに拡大されました。レプリケーションルールはレジストリ単位で定義し、リポジトリのフィルタ条件に基づいて指定した宛先リージョンや宛先アカウントへイメージを自動で複製します。今回の上限緩和により、より細かなリージョン／アカウント別の配布ポリシーを作成可能になり、例えば多数のリージョンへ低遅延でプル可能にする用途や、本番環境とステージング環境それぞれへ別ルールで複製する構成が簡単になります。変更はすべてのAmazon ECR対応リージョンで有効です。

影響範囲・利用シーン ​

  • 対象ユーザー: コンテナイメージを多リージョン／多アカウントへ配布するアーキテクチャを持つSRE/プラットフォームチーム
  • 利用シーン: 多数リージョンへ低遅延アクセスを提供するためのイメージ配布、プロダクション／ステージング等のアカウント別複製、リージョン単位で異なるレテンションポリシーやアクセス制御を適用する場合
  • 運用効果: ルールを統合せずに細分化できるため管理が容易になり、意図しない一括複製や複雑なルール合成による運用ミスを減らせる
  • 注意点（運用上）: ルール数が増えると設定管理が煩雑になるため命名規則やドキュメント化、テストを徹底する必要がある

技術的な注意点 ​

  • IAM権限: レプリケーション設定の変更には ecr:PutReplicationConfiguration などのECR操作権限が必要です。実運用では最小権限のIAMポリシーを適用してください
  • リージョン制限: 本アップデートはAmazon ECRがサポートされるすべてのリージョンで有効です（地域未対応はなし）
  • コスト: レプリケーション先へのデータ転送（クロスリージョン転送）および複製先でのストレージ料金が発生します。大量のプッシュ／複製を行う場合はコスト試算が必要です
  • 既存設定への影響: 既存のレプリケーション動作に自動的な変更はありません。上限が増えただけなので、既存ルールはそのまま動作します。新規ルール追加時は重複するフィルタや想定外の複製先が発生しないか確認してください
  • 運用推奨: 本番導入前にステージングでルールを検証し、監視（CloudWatch Logs/Events）や通知を設定して複製失敗を検知できるようにしてください

参考情報 ​

[Ec2 Auto Scaling] Amazon EC2 Auto Scaling now supports batch instance termination ​

概要 ​

Amazon EC2 Auto Scaling の TerminateInstanceInAutoScalingGroup API が一度に最大100インスタンスの一括終了をサポートしました。スケールダウン時のAPIコール数を削減し、大量に短時間で縮退するワークロードの運用を容易にします。

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

新機能により、TerminateInstanceInAutoScalingGroup API に対して一度に最大100個のインスタンスIDを渡してバッチ終了を実行できます。バッチ内のすべてのインスタンスは終了処理開始前に原子的に検証され、検証に失敗した場合はバッチ全体の終了が開始されません。ライフサイクルフックやロードバランサのコネクションドレイニング（接続の待ち受け）など、既存の Auto Scaling の挙動は各インスタンスごとに維持されます。これにより、AI/MLトレーニングやコンテナオーケストレータ、大量の一時的なフリートを生成するイベント駆動アーキテクチャなど、短時間で大規模に縮退するユースケースでのスケールダウンをより効率的に行えます。全リージョンで利用可能で、追加費用は発生しません。詳細なパラメータや挙動（例: ShouldDecrementDesiredCapacity の扱い、エラー応答形式など）は API リファレンスを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用者、SRE、プラットフォームエンジニア、AI/ML バッチ実行者、コンテナオーケストレータ運用者
  • 利用シーン: 大量インスタンスを短時間で縮退させる必要があるジョブ（例: AI/ML トレーニング後のクラスター縮退、イベント後に立ち上げた一時フリートの削除、バースト的に増減するコンテナノードの縮小）
  • 運用効果: API 呼び出し数の大幅削減によりレイテンシーとオペレーション負荷が低減され、短時間でのスケールダウンを効率化
  • 可用性/安全性への影響: ライフサイクルフックや接続ドレインは保持されるため、急速な縮退でもGracefulな終了が可能。ただし原子的検証により一部のインスタンスが問題あるとバッチ全体が実行されないケースがある
  • コスト: 機能自体に追加料金はなし。短時間でインスタンスを削除できるため、無駄な稼働時間削減によるコスト低減効果が期待できる

技術的な注意点 ​

  • IAM権限: autoscaling:TerminateInstanceInAutoScalingGroup の実行権限が必要（ロールやポリシーで付与を確認）
  • バッチサイズ上限: 一度に渡せるインスタンスIDは最大100件（超える場合は複数呼び出しが必要）
  • 原子検証: バッチ内の全インスタンスは終了開始前に検証され、検証に失敗した場合はバッチ全体が実行されない（エラー応答を確認して個別再試行等を行う必要あり）
  • ライフサイクルフックとデプロイ挙動: ライフサイクルフック、ロードバランサの接続ドレイン等は各インスタンスごとに適用されるため、実際の終了までに時間がかかる可能性がある
  • Desired Capacity の扱い: TerminateInstanceInAutoScalingGroup の既存パラメータ（例: ShouldDecrementDesiredCapacity）の扱いを事前に確認すること。バッチ操作時の desired capacity への影響を設計に反映する必要あり
  • APIレート制限: 一括化でAPIコール数は減るが、APIのスロットリングや他のAPI制限は依然存在するため、大規模運用ではレートやエラーハンドリングを考慮すること
  • テスト推奨: 本番投入前にステージング環境で動作確認（失敗時のエラーハンドリング、ライフサイクルフックの動作、desired capacity 変化など）を行うこと
  • リージョン制限: 全リージョンで利用可能と明記（ただし組織の制約や特殊リージョンでは事前確認を推奨）
  • コスト: 機能利用自体に追加料金は発生しないが、終了処理に伴うリソースの稼働時間短縮でコスト影響が出る可能性あり

参考情報 ​

[Msk] Amazon MSK now supports configuring custom domain names for MSK Provisioned clusters ​

概要 ​

Amazon MSKのプロビジョンドクラスタで、クラスタ単位のカスタムドメイン名を設定できるようになりました。ZooKeeperモードとKRaftモードの両方で利用可能で、各ブローカーに個別設定する必要がなくなります。

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

本機能により、クラスタレベルで一度カスタムドメイン名を定義すれば、Amazon MSKがクラスタ内の全ブローカーへ自動的にそのドメイン名を適用します。これにより、従来必要だった「各ブローカーへ個別にカスタムドメインを設定する」手順が不要になります。設定はスケール操作（ブローカーの追加・削除など）を経ても維持され、ZooKeeperベースおよびKRaftベースの両方で同じ挙動を示します。主なユースケースは、Network Load Balancer（NLB）経由でトラフィックをルーティングする構成、クラスタ移行やDRフェイルオーバー時に接続エンドポイントを固定したい場合、組織の命名規約やセキュリティ要件に基づく恒久的なエンドポイント管理などです。新規クラスタだけでなく既存のMSK Provisionedクラスタにも適用でき、MSKが提供される全リージョンで追加料金なしで利用可能です。なお、MSK Serverlessでは対象外です（本機能はProvisionedクラスタ向け）。

影響範囲・利用シーン ​

  • 対象ユーザー: Kafkaクライアントを利用するアプリケーション開発者、SRE/運用チーム、クラスタ移行担当者
  • 利用シーン: クラスタのスケール・移行・フェイルオーバー時にクライアント接続先を変更したくない場合（恒久的なDNS名による接続維持）、NLB経由のルーティング構成や組織命名規約に沿ったエンドポイント管理
  • 運用効果: クライアント側の再設定やリリース作業を削減でき、DRやスケール操作時のダウンタイム低減や運用負荷の軽減につながる

技術的な注意点 ​

  • 対応モード: MSK ProvisionedクラスタのZooKeeperモードおよびKRaftモード両方で利用可能（Serverlessは対象外）
  • リージョン制限: Amazon MSK Provisionedが提供されている全リージョンで利用可能（記事時点）
  • IAM権限: クラスタ設定を更新するためのMSK操作権限が必要（例: クラスタ更新に関するkafka系のIAM権限）。実運用前に必要なIAMポリシーを確認してください
  • DNS/TLS: カスタムドメインを利用する場合、DNSレコード（A/CNAME）やロードバランサ（例:NLB）との紐付け、TLS証明書（ACMや外部CAで発行）の設定が必要になる場合があります。証明書のCN/SANがドメイン名と一致していることを確認してください
  • ネットワーク構成: NLBやRoute53、VPCエンドポイント等を組み合わせる構成では、関連リソースの設定（ターゲット登録、セキュリティグループ、サブネット等）を確認してください
  • 互換性: 設定はスケーリング（ブローカーの増減）をまたいで維持され、既存のクライアント設定はドメイン名を指すように変更しておくことで透明性を保てます
  • コスト: 本機能自体に追加料金は発生しませんが、NLB、Route53、TLS証明書発行（ACMの範囲外を使用する場合）やデータ転送などの関連サービス利用に伴うコストは発生する可能性があります
  • 注意点: 既存の運用手順や監視設定（ログ・メトリクスのラベル、アラートのターゲット名など）にドメイン名変更が影響する場合は事前に洗い出しを行ってください

参考情報 ​

[Ec2] Amazon EC2 R8i and R8i-Flex instances are now available in Canada West (Calgary) region ​

概要 ​

Amazon EC2の新しいメモリ最適化インスタンス「R8i」と「R8i-flex」がカナダ西部（カルガリー）リージョンで利用可能になりました。カスタムIntel Xeon 6プロセッサを搭載し、従来のIntelベース世代比でメモリ帯域や価格性能が改善されています。

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

R8iおよびR8i-flexはAWS専用カスタムIntel Xeon 6プロセッサを採用したメモリ最適化インスタンスです。R8シリーズは従来のIntelベース世代に対して最大でメモリ帯域が2.5倍、価格性能が最大約15%向上するとされ、R7i比では平均20%高い性能を提供します。ワークロード別の公表例としては、PostgreSQLで最大30%高速化、NGINXで最大60%高速化、AIのディープラーニング推薦モデルで最大40%高速化が示されています。R8i-flexは“メモリ最適化のFlex”として初導入されたフレーバーで、一般的に多く使われるサイズ（large～16xlarge）を提供し、計算リソースを完全に使い切らないアプリケーションでコスト効率を出しやすい設計です。R8iは13種類のサイズ（うち2つはベアメタル）を用意し、新たに96xlargeサイズを追加、継続的に高いCPU使用率が必要な大規模メモリ負荷や最大サイズを要するアプリケーションに向きます。さらにR8iはSAP認定（142,100 aSAPS）を取得しており、ミッションクリティカルなSAPワークロードに対して高性能を提供することがアピールされています。これらはカナダ西部（カルガリー）リージョンで今日から起動可能で、購入はSavings Plans、オンデマンド、Spotから選べます。

影響範囲・利用シーン ​

  • 対象ユーザー: メモリ集約型アプリケーションを扱うクラウドエンジニア、データベース管理者、SRE、機械学習エンジニア、SAP運用チーム
  • 利用シーン: 大規模インメモリデータベース（例: PostgreSQL）、高トラフィックなWebサーバ（NGINX）、ディープラーニング推薦モデル、SAP HANAなどミッションクリティカルで高メモリ帯域を必要とするワークロード
  • 運用効果: 同世代比での処理速度向上によりレスポンスタイム短縮やスループット改善、R8i-flexによりインスタンスサイズを過剰にプロビジョニングせずコスト効率良くメモリ性能を得られるため運用コスト最適化が期待できる

技術的な注意点 ​

  • リージョン制限: 本アナウンスはCanada West (Calgary)リージョンでの利用開始を示します。その他リージョンでの提供状況はリージョンごとに確認してください
  • AMI/互換性: ベアメタルや大規模サイズ（96xlarge）を利用する場合は対応するAMIやOSカーネル、ドライバの互換性を事前に確認してください（NUMAや大メモリ構成のチューニングが必要な場合があります）
  • SAP関連: R8iはSAP認定（142,100 aSAPS）ですが、SAP導入時はSAPとAWSの導入ガイドライン、ライセンス要件を確認してください
  • 購入オプション/コスト: 公式には価格性能が向上するとされていますが、実コストは利用時間、サイズ、EBS/ネットワークI/O、Savings PlansやSpotの利用有無で変動します。事前にベンチマークとコスト試算を行ってください
  • パフォーマンス評価: 公表値は代表的ワークロードでの結果です。移行前に実ワークロードでのベンチマーク（CPU/メモリ帯域/ストレージI/O/ネットワーク）を推奨します
  • 起動権限/IAM: 新インスタンスをプロビジョニングするための通常のEC2起動権限（ec2:RunInstances等）が必要です。Savings PlansやSpotを使う場合はそれぞれの管理設定やポリシーを確認してください

参考情報 ​

[Govcloud Us] Amazon Connect Customer dashboards now support reporting on routing steps and agent proficiencies ​

概要 ​

Amazon Connect Customer の分析ダッシュボードで、ルーティングステップ（routing steps）とエージェントのプロフィシェンシー（技能・熟練度）に関するレポートが可能になりました。監督者がコンタクトのマッチング状況を可視化し、ルーティング条件の調整で待ち時間やキューの偏りを解消できます。

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

今回のアップデートにより、Amazon Connect Customer の管理用分析ダッシュボードで以下が可能になります。

  • エージェントを割り当てられたプロフィシェンシー（skill/proficiency）でフィルタリングし、特定技能を持つエージェント群のパフォーマンスや負荷を把握可能。
  • メトリクスをルーティングステップ単位でグルーピングでき、各ルーティング段階ごとの状況（例：キューに入っているコンタクト数）を可視化。
  • 新しい計測項目として「ルーティングステップ内のキューに入っているコンタクト数」などが追加され、ボトルネックとなっているルーティング段階を特定可能。 これにより、例えば「あるステップで高スキルを要求するルーティングが集中している→条件を緩和して対象エージェントを拡大→待ち時間を短縮」といった運用改善が行えます。機能は Amazon Connect Customer の既存の分析ダッシュボードに統合され、ルーティング設定（ルール、ステップ）とエージェントのプロフィシェンシー設定を組み合わせて利用します。利用可能リージョンは、Amazon Connect Customer を提供する全ての AWS commercial リージョンおよび AWS GovCloud (US-West) です。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンターのスーパーバイザー、マネージャー、SRE/運用チーム
  • 利用シーン: ルーティング設計の評価、特定ルーティングステップのキュー監視、スキルベースルーティングの調整（例：スキル要件を緩和して待ち時間を削減）
  • 運用効果: ルーティングごとのボトルネック特定と迅速なルール調整により平均応答時間（AHT/待ち時間）の改善、適切なエージェント配分によるサービスレベル向上が期待できる

技術的な注意点 ​

  • IAM権限: ダッシュボード閲覧・分析データ取得に必要な Amazon Connect の IAM 権限（管理者/監査ロール、Analytics 関連 API へのアクセス権）を事前に確認・付与してください
  • リージョン制限: Amazon Connect Customer を提供する AWS commercial リージョンおよび AWS GovCloud (US-West) のみで利用可能です。その他の GovCloud リージョンや未提供リージョンでは利用できません
  • コスト: 記事では追加料金の明記はありませんが、Amazon Connect の通常の利用料金（通話・接続・保存・分析関連）やログ保存・クエリに伴う料金が適用される可能性があります。コスト影響を事前に確認してください
  • 前提条件: エージェントのプロフィシェンシー（技能）を事前に定義し、エージェントへ割り当てておく必要があります。ダッシュボードのデータ更新頻度や遅延は既存の分析仕様に依存します
  • 互換性/統合: 本機能は既存の Amazon Connect Customer 分析ダッシュボードへ統合されます。ルーティング定義・コンタクトトレースレコード（CTR）等の既存データを利用します

参考情報 ​

[General] AWS Network Firewall Now Supports Stateful Rule Hit Counts ​

概要 ​

AWS Network Firewallがステートフルルールに対する「ルールヒットカウント」を提供開始しました。各ステートフルルールがどの程度トラフィックにマッチしているかを可視化し、インシデント対応やポリシーの改善に活用できます。

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

ルールヒットカウントは、Firewallポリシー内のステートフルルール（カスタムおよびAWS管理のルールグループ両方）について、各ルールがネットワークトラフィックにマッチした回数を計測・表示する機能です。ヒット数はデフォルトで有効化されており、更新間隔を最短5分に設定できます。本機能はAWS Network Firewallの機能として追加料金なしで利用可能です（ただしログデータの保存やクエリには標準のログストレージ／クエリ料金が適用されます）。運用上は、どのルールが実際に動作しているかを把握して、発火したルールに基づく迅速なインシデント対応、シャドウ／重複／不要ルールの特定、ポリシー変更後の検証などに活用できます。表示方法（コンソール／API／SDKでの取得方法）やメトリクス名・エンドポイントの詳細は公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク管理者、セキュリティエンジニア、SRE/運用チーム
  • 利用シーン: インシデント対応時の発火ルール特定、ファイアウォールポリシーの最適化（シャドウ／重複ルールの検出）、新規ルール導入後の動作確認
  • 運用効果: 実際にマッチしているルールが可視化されることで、不要ルールの除去やポリシー簡素化が進み、トラブルシューティングとポリシー検証の工数削減が期待できる

技術的な注意点 ​

  • 対象ルール: ステートフルルールに対するヒットカウントのみが対象です（ステートレスルールは含まれません）
  • 有効化/設定: デフォルトで有効。メトリクスの更新間隔は最短5分まで設定可能です。詳細な設定手順はドキュメントを参照してください
  • IAM権限: Network Firewallリソースの参照権限に加え、CloudWatchやログ関連の閲覧権限（例: CloudWatch:GetMetricData、logs:DescribeLogStreams/FilterLogEvents 等）が必要になる可能性があります。具体的な最小権限はドキュメントで確認してください
  • リージョン制限: AWS Network Firewallがサポートする全リージョンで利用可能ですが、Middle East (UAE) および Middle East (Bahrain) の各リージョンでは未対応です
  • コスト: ルールヒットカウント自体に追加料金はありませんが、ログの保存やクエリには標準のストレージ・ログクエリ料金が発生します
  • 互換性: カスタムルールグループとAWS管理のルールグループ双方でヒットカウントが取得可能です
  • 運用注意: ヒット数の更新間隔やメトリクスの保持期間により可視化の粒度や履歴が変わります。長期間の分析が必要な場合はログ保存方針とコストを検討してください
  • 参照方法: コンソールやAPI/SDK経由で確認できる見込みです。実際のエンドポイント名やレスポンス形式は公式ドキュメントを参照してください

参考情報 ​

[General] Amazon Quick Microsoft 365 extensions are now generally available ​

概要 ​

Amazon QuickのMicrosoft 365拡張機能（Excel、PowerPoint、Word、Outlook向け）が一般提供（GA）になりました。QuickのAIが各アプリ内で文書編集、スプレッドシート分析、プレゼン作成、メール／カレンダー運用などを自動化します。

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

各拡張機能はMicrosoft 365アドインとして動作し、ユーザーのM365コンテキスト（ファイル、メール、カレンダー、組織テンプレートなど）を参照してAgentic AIの処理を行います。主な機能は以下の通りです。

  • Excel: 複雑なスプレッドシート分析、ピボットテーブル／グラフの作成、データインポートとクリーニング、財務モデルの生成（自然言語で要件を指定してモデルを構築）
  • PowerPoint: Quick上のデータや指示から組織定義テンプレートに沿ったスライドを生成・整形し、プレゼン資料を仕上げる
  • Word: Wordのプリミティブ（段落・スタイル・目次等）を用いた書式付き文書生成、大規模な改変をトラック変更（Track Changes）付きで実行、コメントへのレビューワー参加
  • Outlook: 受信箱の優先付け、メール整理、会議のスケジューリング、受信箱全体のコンテキストを使った返信ドラフト生成

これにより、財務、営業、マーケティング、法務、運用、ITなどのチームが従来手作業で行っていたデータ集約・整形・文書作成・メール運用をアプリ内から自動化できます。GA時点での提供リージョンは US East (N. Virginia)、US West (Oregon)、Asia Pacific (Sydney)、Europe (Ireland)、Asia Pacific (Tokyo)、Europe (Frankfurt) です。導入・配布や追加の設定はQuickのダウンロードページとドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 財務、営業、マーケティング、法務、SRE/運用、IT管理者など、M365を業務で使うチーム全般
  • 利用シーン: 財務モデル作成や複雑なスプレッドシート分析、CRMデータを使った提案書作成、ブランドテンプレートに沿ったプレゼン自動生成、契約書レビューのドラフトとトラック変更、受信箱整理と会議調整の自動化
  • 運用効果: 手作業によるデータ整形や文書フォーマット作業を削減し、レビューサイクル短縮・ヒューマンエラー低減・メール対応効率化が期待できる

技術的な注意点 ​

  • IAM権限: QuickがM365のファイル・メール・カレンダーにアクセスするためのOAuthスコープと管理者同意が必要になる可能性があります。事前に必要権限を確認・承認してください
  • 管理者展開: 組織向け配布（Microsoft 365 管理センターからの組織展開）や個別インストールの方法があり、企業ポリシーに合わせた配布が必要です
  • データ処理/転送: 拡張機能はM365コンテキストをQuickサービスへ渡して処理する設計のため、データ転送先と保存ポリシー（ログ、キャッシュ、モデル入力データ）を確認してください
  • コンプライアンス: 機密データや個人情報を扱う場合はDLPポリシー、監査、契約上のデータ処理条件（データ居住地、処理者）を確認してください
  • リージョン制限: GA時点での提供リージョンは US East (N. Virginia)、US West (Oregon)、Asia Pacific (Sydney)、Europe (Ireland)、Asia Pacific (Tokyo)、Europe (Frankfurt) です。その他リージョンでは未対応の可能性があります
  • 互換性/クライアント要件: M365のデスクトップアプリとWeb版で動作するアドインが想定されますが、特定のクライアントバージョンやブラウザでの制限があるため導入前にサポート要件を確認してください
  • コスト: 公式アナウンスに個別料金情報は含まれていません。Amazon Quickの利用料や追加の商用ライセンスが発生する可能性があるため、コスト見積もりを確認してください
  • 精度とガバナンス: 自動生成コンテンツ（特に法務・財務出力）は誤りや過度の一般化が発生する可能性があるため、人による検証プロセスを維持してください
  • 運用上の注意: 組織テンプレートやスタイルガイドを事前に整備すると生成品質が向上します。ログ／監査設定とバックアップ手順も整備してください

参考情報 ​

[Opensearch Service] Amazon OpenSearch Service now supports automatic semantic enrichment for VPC domains ​

概要 ​

Amazon OpenSearch Serviceは、VPC有効ドメインでも自動セマンティック強化（Automatic Semantic Enrichment）をサポートするようになりました。これにより、プライベートネットワーク内にある検索ドメインでもAIによる意味理解ベースの検索が利用可能になります。

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

自動セマンティック強化は、従来のキーワード一致中心の検索を超えてクエリの意味を理解し、関連性の高いドキュメントを返す機能です（例：「lightweight laptop for travel」→「ultrabooks」「portable notebooks under 3 lbs」などを関連語として取得）。この機能はAWS側で機械学習モデルと推論パイプラインを管理・運用するため、ユーザーがモデル管理や外部統合を行う必要はありません。本アップデートにより、これまではVPC無効ドメインでのみ利用可能だった自動セマンティック強化がVPC内ドメインでも利用可能になりました。技術要件としては、対象ドメインがOpenSearchバージョン2.19以降であること、強化用フィールドを含むインデックスを作成することが必要です。既存のVPC設定を変更する必要はなく、サービス側のソフトウェアを最新にする（必要に応じてドメインのサービスソフトウェア更新）ことで利用を開始できます。提供リージョンは11箇所（US East: N. Virginia, Ohio / US West: Oregon / APAC: Mumbai, Singapore, Sydney, Tokyo / EU: Frankfurt, Ireland, Spain, Stockholm）です。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティポリシーでパブリックアクセスを禁止している企業、社内検索を改善したい開発者/検索エンジニア
  • 利用シーン: 社内ドキュメント検索、Eコマースの商品検索、ナレッジベース検索、CX向上のための意味検索実装
  • 運用効果: 検索関連性が向上し、キーワード不一致による検索ミスを削減。外部にドメインを公開せずにAI検索を導入可能でセキュリティポリシーを維持できる
  • リージョン: 利用可能リージョンは記事記載の11リージョン（US East(N. Virginia, Ohio)、US West(Oregon)、APAC(Mumbai, Singapore, Sydney, Tokyo)、EU(Frankfurt, Ireland, Spain, Stockholm)）
  • 前提条件: ドメインがOpenSearch 2.19以上であること、インデックスに自動セマンティック強化用のフィールド設定が必要

技術的な注意点 ​

  • IAM権限: ドメイン管理やインデックス作成/更新を行うためのOpenSearch関連API操作権限（ドメインポリシーやIAMロールの確認を推奨）
  • リージョン制限: 現時点で11リージョンのみ対応（上記参照）。他リージョンでは未対応の可能性あり
  • コスト: セマンティック処理は追加の推論/処理コストが発生する可能性があるため、料金ポータルや課金レポートで影響を確認してください
  • サービス要件: ドメインのOpenSearchバージョンが2.19以上であること。必要に応じてサービスソフトウェアの更新を実施
  • VPC設定: 記事では既存のVPC設定変更は不要とされているが、セキュリティグループ、ネットワークACL、プライベートサブネットのルーティングなどドメインへのアクセス経路は事前に確認してください
  • 互換性/実装: 自動セマンティック強化を利用するにはインデックスマッピングで所定のセマンティック用フィールドを設定する必要あり。具体的なフィールド設定・API手順は公式ドキュメントに従ってください

参考情報 ​

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

Copyright © 2026