AWS What's New Digest

Appearance

2026年09月24日 ​

[EKS] Amazon SageMaker HyperPod Inference Gateway for scalable LLM inference ​

概要 ​

Amazon SageMaker HyperPod Inference Gatewayは、既存のSageMaker HyperPodインフラ上にEKSのマネージドアドオンとして導入するGPU対応のKubernetesネイティブなルーティング層です。リクエストごとの実行時インファレンス信号に基づく賢いルーティングにより、first-tokenレイテンシやp99 TTFTを大幅に改善します。

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

Gatewayは主に3つのコンポーネントで構成されます。1) Envoy Endpoint: HTTPS終端を行い、クラスタごとに単一のプライベートエンドポイントを公開します。2) Body-Based Router: 受信リクエストの本文からモデル名を直接読み取り、クライアント側の変更なしに1つのエンドポイントで複数モデルを振り分けます（OpenAI互換リクエスト形式を前提）。3) Endpoint Picker: 各モデルサーバPodをリアルタイムでスコアリングし、リクエスト単位で最適なPodを選択します。スコアリングに使う6つのインファレンスレベル信号は、KVキャッシュ利用率、キュー深さ、LoRAアダプタの在留（adapter residency）、prefixキャッシュヒット率、予測レイテンシ、実行中リクエスト数です。これにより、従来のラウンドロビン方式に比べ、混在ハードウェアやバーストトラフィック環境でfirst-tokenレイテンシを最大82%削減、p99 TTFTを97–98%削減できるとされています。vLLMやSGLangなどOpenAI互換のモデルサーバと連携可能で、アプリケーションコードは変更不要です。現在は各クラスタ内ルーティングが全対応リージョンで利用可能で、将来的にクロスクラスタ／クロスリージョンの集中ゲートウェイ、グローバルレート制御、コスト階層に応じたトラフィックシェーピングが提供予定です。

影響範囲・利用シーン ​

  • 対象ユーザー: MLエンジニア、MLOps、SRE/インフラ運用チーム、LLMをプロダクションでホストするサービスオーナー
  • 利用シーン: 単一のエンドポイントで複数モデルを公開するマルチモデル推論、混在GPU（異種GPU）環境での低レイテンシ推論、バーストトラフィック下でのレスポンス安定化
  • 運用効果: first-tokenレイテンシとp99 TTFTの大幅削減によりユーザ体験が向上し、キューイングとホット/コールドのばらつきを低減。Pod選択を動的に行うためGPU利用率やキャッシュ利用が最適化される
  • コスト効果: GPUリソースの効率向上により総コストが削減される可能性がある一方、ゲートウェイ自体の実行リソースや管理オーバーヘッドは別途コスト要因になる
  • リージョン: すでにSageMaker HyperPod inferenceアドオンがサポートされている全リージョンでクラスタ単位のルーティングが利用可能。クロスクラスタ/クロスリージョンは今後提供予定

技術的な注意点 ​

  • IAM権限: EKSアドオンのインストールやSageMakerリソースへのアクセスに必要なIAM権限（EKS、SageMaker、IAMロール/サービスアカウントの設定）を事前に用意すること
  • 導入要件: 対象のEKSクラスタにSageMaker HyperPod inferenceアドオンが導入されていること。対応KubernetesバージョンとEKSの設定要件を確認してください
  • 互換性: OpenAI互換のリクエスト形式（例: JSON本文にmodelフィールドなど）を前提としてルーティングを行うため、独自プロトコルや別形式のリクエストを使う場合は変換レイヤが必要になる可能性があります。vLLM、SGLangなど既存のOpenAI互換モデルサーバと動作します
  • メトリクス要件: Endpoint PickerはKVキャッシュ利用率やprefixキャッシュヒット率等の信号を用いるため、これらの指標が収集可能であること（モデルサーバがメトリクスを公開する／ゲートウェイが収集できる）を確認してください
  • セキュリティ: EnvoyがHTTPS終端を行いプライベートエンドポイントを公開します。VPC設定、セキュリティグループ、Kubernetesネットワークポリシー、TLS証明書管理（必要に応じて）を適切に構成してください
  • リージョン制限: 現状はSageMaker HyperPod inferenceアドオン対応リージョンでのクラスタ内ルーティングが対象。クロスクラスタ／クロスリージョン機能は将来リリース予定のため、導入前に利用可能リージョンを確認してください
  • コスト: ゲートウェイ（Envoy等）やスコアリングロジックを稼働させるリソースの費用が発生しますが、推論効率改善で総コスト削減が期待されます。コスト試算はワークロード特性で変動します
  • 運用/監視: リアルタイムスコアリングとルーティングの挙動を可視化するためのログ・メトリクス収集（Prometheus/Grafana等）の設定とアラート設計を推奨
  • 注意点: "アプリケーションコードは不要"というのはOpenAI互換リクエストを送れる前提です。クライアント側がモデル名をリクエスト本文に含めない、あるいはカスタムヘッダを使う等のケースでは事前の調整が必要です

参考情報 ​

[Emr] Run interactive workloads on Amazon EMR on EKS with Spark Connect ​

概要 ​

Amazon EMR on EKSがSpark Connectをサポートし、SageMaker Unified StudioのマネージドノートブックやJupyter／VS CodeなどのIDEから、EKS上で動作するSparkに対してインタラクティブに開発・デバッグできるようになりました。

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

Spark Connectによるインタラクティブセッションは、セルやスクリプトを跨いで持続するSparkコンテキスト（persistent Spark context）を提供します。クライアント・サーバーアーキテクチャにより、開発者はローカル環境でPythonコードやIDEを使いながら、実際のSpark処理はAmazon EKS上のEMRクラスタ（EMR on EKSのバーチャルクラスタ）で実行させることができます。各セッションはKubernetesのPodとして実行され、EMR on EKSのバーチャルクラスタ上で稼働します。セッションはIAM実行ロールで保護され、プロジェクトやユーザーでタグ付けされます。ワークフローとしては、対話的なデータ探索、段階的なPySparkジョブ開発（デバッグ→本番デプロイ）などに向きます。提供はEMR release 7.14（Apache Spark 3.5）およびemr-spark-8.1.0（Apache Spark 4.1）で、すべてのAWS商用リージョンで利用可能です。SageMaker Unified Studioでの体験は、対応リージョンで利用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データサイエンティスト、機械学習エンジニア、Spark開発者
  • 利用シーン: 対話的なデータ探索、ノートブックでのデバッグ、incrementalなPySpark開発→本番ジョブへの移行、IDEベースでの開発ワークフローの維持
  • 運用効果: 開発生産性の向上（ローカルIDEとリモートSparkの分離）、デバッグ時間の短縮、既存のEKS基盤を活かした一貫した実行環境の確保

技術的な注意点 ​

  • IAM権限: EMR on EKSの実行に必要なIAM実行ロール（pod作成、S3アクセス、EKSリソースアクセスなど）を正しく設定してください。クライアント側ユーザーのIAMポリシーとKubernetes RBACの整合性も必要です。
  • 対応バージョン: 利用にはEMR release 7.14（Spark 3.5）またはemr-spark-8.1.0（Spark 4.1）が必要です。クライアント（Spark Connectライブラリ）とサーバー側Sparkのバージョン整合性に注意してください。
  • リージョン制限: Spark Connect on EMR on EKSはすべてのAWS商用リージョンで利用可能とされていますが、SageMaker Unified Studioの体験は「対応リージョン」でのみ利用可能です。実際の可用性はリージョンごとに確認してください。
  • コスト: セッションはKubernetes Pod（EC2/EKSリソース）上で実行されるため、EC2/EKS/EMR on EKSの実行コストが発生します。長時間の対話セッションはランニングコスト増につながるため、セッションのライフサイクル管理を検討してください。
  • ネットワーク/セキュリティ: Podのネットワーク設定（セキュリティグループ、VPC、プライベートサブネット等）やS3エンドポイント、VPCエンドポイントの構成を確認してください。企業のセキュリティ要件に合わせて暗号化やログ取得を設定してください。
  • セッション管理: 永続Sparkコンテキストはセル間で状態を保持しますが、Podの再起動やスケールイベントでセッションが切断される可能性があります。状態保存や再接続戦略を設計してください。
  • 開発ツール: サポートされるクライアントはSageMaker Unified Studioのノートブックや一般的なIDE（Jupyter, VS Codeなど）。ローカルでSpark Connectクライアントライブラリをインストールし、適切な接続設定（ホスト/ポート、TLS/gRPC設定）を行う必要があります。
  • Kubernetes権限: EMR on EKSのバーチャルクラスタやPod起動に関するKubernetes RBAC設定とネームスペースの権限を事前に確認してください。

参考情報 ​

[Gamelift] Amazon GameLift Servers now available in 5 new regions and 8 Local Zones ​

概要 ​

Amazon GameLift Serversが5つの新しいAWSリージョンと8つのAWSローカルゾーンに対応しました。プレイヤーに近い場所でゲームサーバーフリートを展開できるようになり、レイテンシ低減と応答性向上が期待できます。

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

今回の拡張では、Amazon GameLift Serversを以下の5つの新リージョンと8つのローカルゾーンに展開できるようになりました。新リージョン: il-central-1 (Tel Aviv), mx-central-1 (Mexico/Queretaro), eu-south-2 (Spain/Zaragoza), ap-south-2 (Hyderabad), ap-southeast-3 (Jakarta)。新ローカルゾーン: us-east-1-atl-2 (Atlanta), us-east-1-chi-2 (Chicago), us-east-1-iah-2 (Houston), us-east-1-mia-2 (Miami), us-west-2-phx-2 (Phoenix), sa-east-1-bue-1 (Buenos Aires), us-east-1-nyc-2 (NYC), sa-east-1-lim-1 (Lima)。

技術的には、GameLift Serversのフリート作成時に対象のリージョン/ローカルゾーンを指定してデプロイ可能です。これによりプレイヤー分布に合わせた地理的なサーバー配置が容易になり、マッチメイキングやレイテンシベースのルーティングと組み合わせることでプレイ体験を改善できます。新しいロケーションではインスタンスタイプやキャパシティ上限、ネットワーク構成（VPC、サブネット、セキュリティグループ）が既存リージョンと同様に必要です。詳細なAPI/SDKやサーバービルドの手順、サポートされるリージョン一覧については公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチプレイヤーゲーム開発者、ゲームスタジオ、SRE/運用チーム
  • 利用シーン: 地理的に分散したプレイヤーに対してサーバーを近接配置し、レイテンシとパケットロスを抑えた対戦/協力プレイを提供する場面
  • 運用効果: プレイヤーごとの応答性向上と滞在時間/リテンション改善、地域向けイベントやトーナメントでの公平な遅延管理が可能
  • ビジネス効果: 新興市場（ラテンアメリカ、南アジア、東南アジア、中東等）への展開が現実的になり市場拡大の機会が増加

技術的な注意点 ​

  • IAM権限: GameLiftのフリート作成やEC2/S3アクセスに必要なIAM権限を事前に確認・付与してください（gamelift:, ec2:, s3:*等の最小権限設計を推奨）。
  • リージョン制限: 新しいリージョン/ローカルゾーンは利用可能になりましたが、アカウント側でローカルゾーンの有効化が必要な場合があります。リージョンごとのサービス可用性やインスタンスタイプの違いを確認してください。
  • コスト: フリートを多数のリージョン/ローカルゾーンに分散すると、インスタンス料金、データ転送費、運用コスト（監視・ログ保管など）が増加します。コスト試算を行ってから配置を決定してください。
  • インスタンスタイプと在庫: 新リージョンでは一部インスタンスタイプやスポット/オンデマンドの在庫が制限される可能性があります。必要なインスタンスが利用可能か事前確認を行ってください。
  • ビルド配置: ゲームサーバーのビルドやアーティファクトは、デプロイ先リージョンでの高速配信を考慮し、S3バケットのリージョンや配布戦略（複製/クロスリージョン配布）を検討してください。
  • サービスクォータ: フリート数や同時インスタンス数などのクォータはリージョン単位で管理されています。必要に応じてAWSサポートへ引き上げ依頼を行ってください。
  • モニタリング: CloudWatchやGameLiftのメトリクスをリージョン別に収集・集約する設計（ログ転送や中央監視）を検討してください。
  • 互換性: 既存のマッチメイキング/マルチリージョン設計との整合性（DNS、マッチングロジック、プレイヤー地理判定）を確認し、テストを実施してください。

参考情報 ​

[General] Amazon ElastiCache Global Datastore now supports tagging and tag-based access control ​

概要 ​

Amazon ElastiCache の Global Datastore がリソースタグ付けとタグベースのアクセス制御（TBAC）をサポートするようになりました。これにより、グローバルに跨る ElastiCache リソースへ一貫した権限・コスト配分ポリシーを適用できます。

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

今回の更新で、Global Datastore に対して AddTagsToResource、RemoveTagsFromResource、ListTagsForResource の API を利用できるようになりました。付与したタグは Global Datastore が跨るすべてのリージョンへ自動的に伝播するため、リージョンごとの個別操作を行わずにタグベースの IAM ポリシーや Organizations の Service Control Policies (SCP) の条件（例: aws:ResourceTag/<タグキー>）でアクセス権を制御できます。タグ変更や参照の操作方法は既存の ElastiCache のタグ操作と同様で、Global Datastore の作成・管理方法に変更はありません。追加料金は発生せず、ElastiCache Global Datastore が利用可能な全リージョンで有効です。

影響範囲・利用シーン ​

  • 対象ユーザー: ElastiCache を運用するクラウド管理者、SRE、セキュリティチーム、コスト管理担当者
  • 利用シーン: 複数リージョンにまたがる Global Datastore に対して一貫したアクセス制御ポリシーやコスト配分タグを適用したい場合。IAM／SCP 条件でタグを参照してリソースベースの許可を付与・制限可能。
  • 運用効果: リージョンごとの個別設定が不要になり、ポリシー管理・監査・コスト割当てが簡素化されることで運用負荷が低減。リソース列挙ではなくタグ条件でスケーラブルに権限管理できる。

技術的な注意点 ​

  • IAM権限: AddTagsToResource、RemoveTagsFromResource、ListTagsForResource を操作するために elasticache:AddTagsToResource 等の権限が必要です。また、タグ条件を用いる場合は適切な iam:Condition の設定（例: aws:ResourceTag/<Key>）を確認してください。
  • タグ伝播: タグ変更は Global Datastore が跨る全リージョンへ自動伝播しますが、伝播に短時間の遅延が発生する可能性があります。自動化スクリプトなどで即時性を期待する場合は遅延を考慮してください。
  • タグ制限: AWS の一般的な制限（リソースあたりのタグ数上限、キー/値の長さなど）が適用されます（例: 通常は最大50タグなど）。詳細はドキュメントを確認してください。
  • コスト: この機能自体に追加料金は発生しませんが、コスト配分レポートでタグを使う場合は AWS Billing の「コスト配分タグ」を有効にする必要があります。
  • リージョン制限: ElastiCache Global Datastore が利用可能なすべてのリージョンで本機能が有効です。特定リージョンでの対応状況は事前に確認してください。
  • 既存管理ツール: Global Datastore の作成・管理方法に変更はありません。既存の IaC/自動化ツールでタグ API を呼ぶことで対応可能です。

参考情報 ​

[Govcloud Us] Amazon RDS supports Multi-AZ for SQL Server Developer Edition ​

概要 ​

Amazon RDS for SQL Server が Developer Edition に対して Always On Availability Groups を使った Multi-AZ 配置をサポートしました。これにより非本番環境で Enterprise 相当の高可用性構成をライセンスコストなしで構築・検証できます。

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

RDS 上の SQL Server Developer Edition で、Always On Availability Groups を利用する Multi-AZ 配置が利用可能になりました。Multi-AZ 配置は別の Availability Zone に同期スタンバイレプリカを維持し、インフラ障害時に自動フェイルオーバーを行います。Developer Edition は Enterprise Edition と同等の機能を含んでいるため、Enterprise ライセンスを購入せずに高可用性アーキテクチャの検証、フェイルオーバー動作のテスト、プロダクション相当の構成での開発が可能です。サポートされるバージョンは SQL Server Developer Edition のメジャー版 2019 と 2022、および SQL Server 2025 Enterprise Developer Edition です。SQL Server 2025 Standard Developer Edition は本機能をサポートしていません。リージョン対応状況や料金は公式ドキュメントおよび価格ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者（DBA）、クラウドアーキテクト、SRE、アプリケーション開発者、QA/テストチーム
  • 利用シーン: 非本番環境での高可用性（HA）アーキテクチャ検証、フェイルオーバーテスト、Enterprise 機能を前提とした開発・統合テスト
  • 運用効果: Enterprise ライセンスを購入せずに本番相当の HA 動作を検証できるため、設計検証コストが低減される。フェイルオーバー動作確認により本番移行リスクを軽減。なお Multi-AZ によるスタンバイインスタンス分のリソースコスト増加が発生する

技術的な注意点 ​

  • サポートバージョン: SQL Server Developer Edition 2019、2022、および SQL Server 2025 Enterprise Developer Edition が対応。SQL Server 2025 Standard Developer Edition は未対応
  • ライセンス制約: Developer Edition は開発/テスト用途向けであり、本番稼働での使用は禁止されています（ライセンス条件を遵守してください）
  • リージョン制限: 全リージョンで即時利用可能とは限らないため、対象リージョンの対応状況は公式ドキュメントで確認してください（GovCloud (US) 含む）
  • コスト: 同期スタンバイ用の追加インスタンス/ストレージ分が発生します。インスタンスタイプ、ストレージ、I/O、データ転送の料金を考慮してください
  • 運用上の注意: フェイルオーバー時にクライアント接続が短時間切断されることがあるため、接続再試行や適切なタイムアウト設定が必要です。バックアップ/メンテナンスの挙動やパラメータグループ、オプショングループの設定も確認してください
  • 構成/制限: RDS 管理下の Always On AG による実装であり、従来のストレージレベルの Multi-AZ（同期レプリケーション）とは実装が異なります。詳細な設定手順や制約（ポートや設定項目）はドキュメント参照が必要です
  • IAM/権限: RDS の操作には適切な IAM 権限が必要です。RDS インスタンス作成やオプション変更を行う権限を付与してください

参考情報 ​

[Kinesis] Amazon Kinesis Data Streams announces Service-Managed Partition Keys for simplified data ingestion ​

概要 ​

Amazon Kinesis Data StreamsがOn-Demand StandardおよびOn-Demand Advantageストリーム向けに「サービス管理パーティションキー」をサポートしました。これにより、順序性が不要なワークロードでプロデューサーがパーティションキーを指定せずにデータを投入でき、自動的にシャード間へレコードを分散します。

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

サービス管理パーティションキーは、オンデマンドモードのストリームに対してプロデューサー側で明示的なパーティションキーを指定する必要をなくす機能です。従来はUUID等のランダムキーを生成して分散させる運用が一般的でしたが、ランダム化でもシャードごとのスループット不均衡（ホットパーティション）が起き得ました。本機能ではKinesis側が“ウォーム（prewarmed）キャパシティ”と利用可能なシャードリソースを基にレコードを自動分配するため、プロデューサー側で分散ロジックを実装する必要がなくなり、ギガバイト/秒クラスのスルーミングにも対応しやすくなります。利用するには最新のAWS SDKまたはKinesis Producer Library (KPL) にアップグレードし、パーティションキーを送らない（またはSDK/KPLの新機能を有効にする）だけで恩恵を受けられます。順序保証が不要なログ集約、メトリクス収集、IoTテレメトリ等の用途で有効で、追加料金はなく、すべてのAWS商用リージョンで利用可能です。なお、本機能はOn-Demand Standard／On-Demand Advantageのオンデマンドモードに限定され、プロビジョンドキャパシティ（手動シャード割当て）には適用されません。順序性やキー単位でのシャード局所性が必要なユースケースでは従来どおり明示的なパーティションキーを使う必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: ストリーミングデータを扱うアプリケーション開発者、SRE、IoT/ログ収集基盤担当者
  • 利用シーンまたは効果: ログ集約、メトリクス収集、IoTテレメトリ等、レコード単位の順序保証が不要なケースでのデータ投入を簡素化し、ホットパーティションを回避してスループットを安定化できます
  • 運用効果: プロデューサー側の分散ロジックやUUID生成などの実装・テスト工数が削減され、ストリーミング基盤の本番導入までの時間短縮とスケーラビリティ向上が期待できます

技術的な注意点 ​

  • 対応ストリーム: On-Demand StandardおよびOn-Demand Advantageのオンデマンドモードにのみ対応。プロビジョンドモード（手動シャード管理）では利用できません
  • 順序保証: レコード順序は保証されません。レコード間で順序性や同一シャード配置が必要な場合はパーティションキーを明示的に指定してください
  • SDK/KPL: 利用するには最新のAWS SDKまたはKinesis Producer Libraryへアップグレードが必要。アップグレード後はパーティションキーを送らない（またはSDKの該当オプションを有効化）ことで利用可能になります
  • 監視/デバッグ: パーティションキー情報が生成されないため、キー単位でのトラブルシューティングやログ相関が行えません。CloudWatchのシャード単位メトリクス等で動作監視・スロットリング確認を行ってください
  • 互換性: コンシューマ（KCL、Enhanced Consumers等）は従来通り動作しますが、アプリケーション側でシャード局所性やキー単位の順序を前提とした処理がある場合は影響を受けます
  • IAM権限: PutRecord/PutRecords 等の既存の書き込み権限が必要です。新たな権限追加は不要な想定ですが、IAMポリシーを確認してください
  • リージョン制限: すべてのAWS商用リージョンで利用可能（記事発表時点）。特別なリージョン制限はありません
  • コスト: 追加料金は発生しません。ただしストリームの利用量（PUTレコード数、出力転送、シャード相当の料金等）に基づく通常の課金は発生します

参考情報 ​

[Bedrock] Amazon Bedrock Managed Knowledge Base now supports Salesforce and Zendesk as native data source connectors ​

概要 ​

Amazon Bedrock Managed Knowledge BaseがSalesforceおよびZendeskをネイティブなデータソースコネクタとしてサポートしました。これにより、両プラットフォームのナレッジ記事やコミュニティ投稿を直接同期してRAG（retrieval-augmented generation）アプリで利用できます。

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

今回の追加で、Salesforce（Knowledge記事等）とZendesk（Help Center記事、コミュニティ投稿等）からデータを直接取り込み、BedrockのManaged Knowledge Baseに同期可能になりました。従来はカスタムの取り込みパイプライン（クローラーや抽出ロジック、増分同期処理など）を自分で構築する必要がありましたが、ネイティブコネクタはインスタンス認証情報（APIトークンやOAuthなど）を提供するだけで、データのクロール、メタデータ抽出、ドキュメント化、増分同期を自動で実行します。これにより、最新のサポート記事やナレッジを常に反映したRAGベースのチャットボットやアシスタント（カスタマーサポートボット、社内営業支援ツールなど）を容易に構築できます。同期時にはソースのメタデータ（作成日、更新日、タグ、カテゴリなど）を保持してKnowledge Base内の検索・フィルタに利用できるようにマッピングされる点や、増分（差分）同期により毎回フルインポートを行わずに済む点が特徴です。詳細な設定や制約、対応するコンテンツ種類・添付ファイルの扱い、認証フローはAmazon Bedrockのユーザーガイドの各コネクタ説明を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: AIエンジニア、チャットボット/アシスタント開発者、SRE/運用チーム、カスタマーサポート/セールス担当者
  • 利用シーンまたは効果: Zendeskのヘルプ記事やコミュニティ回答を用いた顧客対応チャットボット、Salesforceのナレッジを用いた営業準備支援アシスタントなど、既存のナレッジをすぐにRAGアプリで活用可能に
  • 運用効果: 手動や自作パイプラインのコストと運用負荷を削減し、最新コンテンツへの自動追従で回答の鮮度を維持できる

技術的な注意点 ​

  • IAM権限: Bedrock側アクセスとコネクタ設定に必要なIAM権限を確認してください（Knowledge Base管理やコネクタ作成の権限が必要）
  • 認証方式: Salesforce/Zendesk側でのAPIトークンやOAuth認証が必要。必要なスコープ（読み取り権限等）を事前に付与してください
  • データ同期: 初回フル同期後は増分同期を行う仕組みですが、同期間隔やスケジュール、レート制限は設定やソース側制約に依存します
  • レート制限: Salesforce/ZendeskのAPIレート制限やガバナ制約に注意。大量データ移行時は制限超過を回避する設計が必要です
  • PII/コンプライアンス: 同期するコンテンツに機密情報や個人情報が含まれる場合は取り込みルールとマスキング、アクセス制御を検討してください
  • 暗号化・データ保護: データの転送／保存は暗号化されますが、KMSキーやデータ保持ポリシーなど組織要件を確認してください
  • コスト: Bedrock Managed Knowledge Baseの利用料金やAPI呼び出し・データ転送コストが発生する可能性があります。大量同期や頻繁な増分同期はコストに影響します
  • リージョン制限: 利用可能なリージョンはサービスドキュメントを確認してください。特定リージョンで未対応の可能性があります
  • 対応コンテンツ: 記事本文やコミュニティ投稿の同期が主ですが、添付ファイルやカスタムフィールドの扱いは制約がある場合があるためドキュメントで確認してください
  • 既存パイプラインとの互換性: 既にカスタムETLを運用している場合は、移行計画（データ重複回避、IDマッピング、同期ポリシー）を検討してください
  • 監査・ログ: 同期ジョブのログや監査情報を有効にして、同期状況や失敗時の原因追跡を行ってください

参考情報 ​

[Connect] Amazon Connect Customer now provides routing step data in the analytics data lake ​

概要 ​

Amazon Connect Customerのアナリティクスデータレイクにルーティングステップ（routing step）データが追加され、ルーティング判断の挙動をAthenaやQuickSightで直接分析できるようになりました。これにより複雑なデータパイプラインを構築せずに、各ルーティングステップでのキュー長や参加数などの傾向分析が可能になります。

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

今回のアップデートで、Amazon Connect Customerのデータレイクにルーティングステップに関するテレメトリが格納されるようになりました。格納されたデータにより、各ルーティングステップでの「contacts queued」「contacts joined」などの指標をAmazon Athenaでクエリし、Amazon QuickSightでダッシュボード化できます。具体的には、コンタクトが各ステップをどのように進行したか（ステップでの滞留や離脱）、どのポイントでエージェントマッチングの条件が緩和されたか、ルーティング構成が待ち時間やエージェント稼働率に与える影響を測定・可視化できます。データレイクはAmazon Connect Customerの既存のデータレイク基盤上で提供され、S3上のデータに対してAthenaが直接クエリを実行する一般的なワークフローを想定しています。ルーティングステップデータはAmazon Connect Customerデータレイクを提供する全リージョンで利用可能です（利用開始やスキーマの詳細はAdministrator Guideを参照してください）。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンターの分析者、ルーティング設計者、BI/データチーム、SRE/運用担当者
  • 利用シーンまたは効果: ルーティング設計の評価（どのステップで待ち時間が発生しているか、どこでマッチング条件が緩むか）の可視化と改善
  • 運用効果: 複雑なETLを作らずにルーティング変更の影響を短期間で検証でき、待ち時間削減やエージェント効率化に寄与
  • 導入効果: 分析のスピードアップによりA/Bテストや設定変更のフィードバックループを短縮できる

技術的な注意点 ​

  • IAM権限: データレイク（S3）、Athena、Glue（カタログ）、QuickSightへアクセスできる適切なIAMロール/ポリシーが必要です。管理者ガイドで推奨ロールを確認してください。
  • データ有効化/設定: ルーティングステップデータを利用するにはAmazon Connect Customerのデータレイク機能が有効化されている必要があります。初期設定やスキーマの有効化はAdministrator Guideに従ってください。
  • リージョン制限: 記事のとおり、ルーティングステップデータは「Amazon Connect Customerデータレイクを提供するリージョン」で利用可能です。全リージョンで自動的に有効とは限らないため、利用リージョンの対応状況を確認してください。
  • データスキーマ/互換性: スキーマやカラム名、パーティション構成は将来変更される可能性があります。既存クエリが影響を受ける場合があるため、Glueカタログやスキーマ定義を定期的に確認してください。
  • データ更新頻度/レイテンシ: 記事では具体的な更新頻度は明記されていません。リアルタイム性が必要な用途では、管理者ガイドでレイテンシや収集間隔を確認してください。
  • コスト: S3ストレージ、Athenaクエリ実行、Glueカタログ/ETL、QuickSightのダッシュボード利用などの標準AWS料金が別途発生します。データ量やクエリ設計によりコストが増加するため見積りを行ってください。
  • アクセス/可視化: QuickSightで直接可視化するにはQuickSightからAthena/Glueへ接続する設定と権限が必要です。ダッシュボード共有やSPICE容量の考慮も必要です。
  • データ保持/プライバシー: 保存されるメタデータに個人情報が含まれる場合は、保持期間やマスキング方針を運用で整備してください。

参考情報 ​

[Emr] Amazon EMR on EKS now supports IPv6 Amazon EKS clusters ​

概要 ​

Amazon EMR on EKSがIPv6のAmazon EKSクラスターでのワークロード実行をサポートしました。大規模なSparkやFlinkジョブをIPv6のアドレス空間上でスケールさせられるようになります。

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

今回の対応により、Amazon EMR on EKSはIPv6で構成されたAmazon EKSクラスター上でApache SparkやApache Flinkなどのオープンソース解析フレームワークを実行できるようになりました。IPv6の大きなアドレス空間を利用できるため、セカンダリCIDRやプレフィックスデリゲーションといったIPv4節約のための回避策が不要になり、高い並列度（例: 500エグゼキュータ規模のSparkジョブ）をアドレス枯渇を心配せずに同時実行できます。ジョブ提出はStartJobRun、Spark Connect Interactive Endpoints、Amazon SageMaker Unified Studioで追加設定なしに可能で、Flink、Livy、Sparkオペレーターもサポートされています。対応は追加料金なしで、emr-7.14.0およびemr-spark-8.0.0以降のリリースで利用可能です。IPv6クラスターのサポートは、Amazon EMR on EKSおよびIPv6対応のEKSクラスターが利用可能なリージョンで提供され、セットアップ手順やサポートされるジョブ提出モデルのドキュメントが用意されています。

影響範囲・利用シーン ​

  • 対象ユーザー: データプラットフォームチーム、データエンジニア、SRE/運用チーム
  • 利用シーンまたは効果: 大規模なSpark/Flinkワークロードのスケールアウト（多数エグゼキュータ／タスク）をIPv6アドレス空間で実行し、IPv4アドレス制約による設計や運用上の回避策を不要にする
  • 運用効果: アドレス枯渇を気にせず高並列ジョブを同時実行できるため、クラスタ設計の単純化・運用負荷の軽減が期待できる
  • 互換性: StartJobRun、Spark Connect、SageMaker Unified Studio、Flink/Livy/Spark Operatorsなど標準的な提出モデルで追加設定不要
  • スケーラビリティ: 大規模ジョブ（例: 500エグゼキュータ）の同時実行や多ポッド構成の拡張が容易になる

技術的な注意点 ​

  • 対応リリース: emr-7.14.0およびemr-spark-8.0.0以降が必要です
  • クラスタ設定: 対象のEKSクラスターはIPv6（デュアルスタックまたはIPv6専用）で正しく構成されている必要があります。VPC、サブネット、CNI（ネットワークプラグイン）のIPv6サポートを確認してください
  • IAM権限: 既存のEMR on EKSで必要なIAMロール/ポリシーは引き続き必要です。IPv6特有の追加権限は通常不要ですが、クラスターやVPCリソースを作成/変更する権限は必要です
  • リージョン制限: Amazon EMR on EKSおよびIPv6対応のAmazon EKSが利用可能なリージョンでサポートされます。リージョン毎の提供可否は事前に確認してください
  • コスト: 機能自体に追加料金は発生しませんが、IPv6対応によるスケールアウトで利用するEC2/ノードコストや関連ストレージ・ネットワーキングの使用量は増加する可能性があります
  • 互換性注意: 一部の外部サービスやサードパーティ統合がIPv4のみを前提としている場合があるため、外部エンドポイントとの通信要件を確認してください
  • ネットワーク設計: セキュリティグループ、ルートテーブル、NACLなどのIPv6ルールの設定と、ログ・監視（IPアドレスベースのフィルタ等）の影響を確認してください

参考情報 ​

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

Copyright © 2026