AWS What's New Digest

Appearance

2026年06月06日 ​

[Bedrock] Amazon Bedrock AgentCore Runtime introduces interactive shells for terminal access into agent sessions ​

概要 ​

Amazon Bedrock の AgentCore Runtime に対して、PTY 付きの双方向インタラクティブシェルを提供する InvokeAgentRuntimeCommandShell API が追加され、WebSocket 経由で実行中のエージェントセッションに対して恒久的なターミナル接続が可能になりました。これにより、従来のワンショット実行 API と補完して、マイクロVM 内での対話的なデバッグや操作が容易になります。

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

主な変更点と技術的内容:

  • 新API: InvokeAgentRuntimeCommandShell を追加。WebSocket ベースで PTY を割り当て、端末入出力を双方向に送受信できるインタラクティブセッションを確立します。
  • PTY と端末機能: カラー表示、タブ補完、Ctrl+C（中断）、端末リサイズに対応。ローカルターミナルと同等の操作体験を提供します。
  • Persistent session state: 同一シェル内では環境変数、カレントディレクトリ、コマンド履歴が保持され、コマンド間で状態が継続します。
  • セッション識別: 各インタラクティブ接続は runtime session ID と shell ID で識別。両者を使って再接続すると同一シェルに戻れます。
  • 再接続: 軽微なネットワーク切断は自動的に再接続。長時間の切断は runtime session ID / shell ID を用いて手動で再開可能。
  • 並列シェル: 単一のエージェントランタイムで最大 10 個の同時シェルをサポート。複数ターミナルを同一／別マイクロVM に対して開き、並列で作業や確認ができます。
  • 既存APIとの違い: 既存の InvokeAgentRuntimeCommand はワンショット（非対話）コマンド実行向け。今回の InvokeAgentRuntimeCommandShell はインタラクティブなデバッグや対話操作向けに設計されています。
  • CLI 利用例: AgentCore CLI からは agentcore exec --it --runtime &lt;runtime-id&gt; 等で開始可能（<runtime-id> を指定）。
  • 主なユースケース: コーディングエージェント（例: Claude Code、OpenAI Codex、Amazon Kiro）をホストする際の認証、ファイル検査、アドホックコマンド実行、環境デバッグなどに最適化されています。

影響範囲・利用シーン ​

  • 対象ユーザー: コーディングエージェントを運用・開発する開発者、MLエンジニア、SRE／運用チーム
  • 利用シーン: エージェントの対話的デバッグ、ランタイム環境の調査（ファイル確認、依存関係の確認、手動コマンド実行）、長時間のデバッグ セッション、複数ブランチやエージェントインスタンスを並列で観察する作業
  • 運用効果: 問題の迅速な切り分けと修正、反復開発サイクルの短縮、ランタイム内部状態の可視化によりデバッグ時間を大幅に削減
  • スケーリング影響: 単一ランタイムあたり最大10シェルの同時接続制限があるため、大量同時接続が必要なワークロードは複数ランタイムで分散する設計が必要

技術的な注意点 ​

  • IAM権限: InvokeAgentRuntimeCommandShell を実行するための専用権限（API 呼び出し／WebSocket 接続関連）を事前に確認・付与してください
  • 認証: WebSocket 接続や CLI 利用時に適切な認証（IAM ロール／一時認証トークン等）が必要です
  • セッション永続性: 同一 runtime session ID と shell ID により再接続可。ただしランタイム（マイクロVM）が停止・終了した場合はシェル状態が失われる可能性があります
  • 接続の信頼性: 軽微なネットワーク切断は自動復旧しますが、長期間の切断は手動再開が必要です
  • 並列数制限: 単一エージェントランタイムで最大10コンカレントシェル
  • コスト: 長時間維持されるインタラクティブセッションやマイクロVM の稼働により追加料金（ランタイム時間やデータ転送）が発生する可能性があります
  • リージョン制限: 機能は順次展開される可能性があるため、利用前に対象リージョンでの提供状況を公式ドキュメントで確認してください
  • CLI/ツール: agentcore CLI のバージョン依存の可能性があるため、最新 CLI を利用しドキュメントの使用例に従ってください
  • セキュリティ注意: シェルはマイクロVM 内で強力な操作権限を与えるため、信頼できるユーザーのみが利用できるようアクセス制御と監査ログを適切に構成してください

参考情報 ​

[Simple Storage Service] Simplified permissions for Amazon S3 Tables and Iceberg materialized views are now available in AWS GovCloud (US) Regions ​

概要 ​

AWS Glue Data CatalogがAmazon S3 TablesとApache Icebergのマテリアライズドビューに対してIAMベースの認可をサポートするようになり、これがAWS GovCloud (US-East) と AWS GovCloud (US-West) リージョンでも利用可能になりました。これにより、ストレージ、カタログ、クエリエンジンに必要な権限を単一のIAMポリシーで定義でき、Athena/EMR/Redshift/Glueなどとの統合が簡素化されます。

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

・機能概要: AWS Glue Data CatalogがS3 TablesおよびApache Icebergマテリアライズドビューに対するIAMベースの認可をサポートします。従来はストレージ（S3）、カタログ（Glue Data Catalog / Lake Formation）、およびクエリエンジン（Athena, EMR, Redshift等）で別々に権限設定が必要になることがありましたが、IAMベースの認可によりこれらを単一のIAMポリシーでまとめて管理できます。 ・対応対象: Amazon S3 Tables と Apache Iceberg のマテリアライズドビュー（メタデータおよびデータアクセスの制御を含む）。 ・統合サービス: Amazon Athena、Amazon EMR、Amazon Redshift、AWS Glue など主要なAWSアナリティクスサービスと連携可能。 ・Lake Formationとの併用: いつでもLake Formationにオプトインして、コンソール/CLI/API/CloudFormationを使った細粒度アクセス制御（テーブル/カラム単位など）を有効化可能。IAMベースの簡易的管理とLake Formationの細粒度制御は選択して併用できます。 ・実装上のポイント: IAMポリシーにS3（例: s3:GetObject, s3:ListBucket等）、Glue（例: glue:GetTable, glue:GetPartitions, glue:GetDatabase等）、およびクエリエンジンに必要なアクションを含める必要があります。マテリアライズドビューやテーブルのARNをリソース指定することで権限を限定できます。また、SSE-KMSで暗号化されたデータにアクセスする場合は適切なKMS権限（kms:Decrypt等）を付与する必要があります。 ・リージョン提供: 本機能はAWS GovCloud (US-East) と AWS GovCloud (US-West) で利用可能になりました。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドのデータプラットフォーム管理者、データエンジニア、SRE/運用チーム
  • 利用シーンまたは効果: S3 Tables/ IcebergマテリアライズドビューをAthena/EMR/Redshift/Glueで利用する際に、ストレージ・カタログ・クエリエンジンの権限を単一のIAMポリシーで管理でき、権限設計と運用が簡素化されます。
  • 運用効果: ポリシーの集中管理により権限ミスが減り、アクセス許可の設定・監査がしやすくなるため導入・運用コストが低減します。GovCloud環境での公的機関向けワークロードの導入が容易になります。

技術的な注意点 ​

  • IAM権限: S3（s3:GetObject, s3:ListBucket等）、Glue（glue:GetTable, glue:GetPartition, glue:GetDatabase等）、クエリエンジン固有のアクションをIAMポリシーへ明示的に追加してください。必要に応じてテーブル／ビューのARNでリソース制限を行ってください。
  • KMS/暗号化: S3オブジェクトがKMSで暗号化されている場合、KMSキーに対する適切なアクセス許可（kms:Decrypt等）とキーの使用許可を付与する必要があります。
  • Lake Formation: 細粒度制御が必要な場合はLake Formationへオプトインしてください。オプトイン後はLake Formationのポリシーがアクセス制御の挙動に影響するため、移行計画とテストを推奨します。
  • リージョン制限: 本サポートは AWS GovCloud (US-East) および AWS GovCloud (US-West) で利用可能です。他リージョンの状況は公式ドキュメントで確認してください。
  • 互換性/移行: 既存のリソースベースポリシーやGlue/Lake Formationの設定と競合する可能性があるため、ポリシー適用前にステージング環境で動作検証してください。
  • コスト: 本機能利用自体に追加料金は発生しませんが、Lake Formationを利用する場合の運用負荷や、監査ログ（CloudTrail、S3アクセスログ等）の保管コストは考慮してください。

参考情報 ​

[Opensearch Service] Amazon OpenSearch UI is now available in GovCloud regions ​

概要 ​

Amazon OpenSearch Serviceの最新のUI（OpenSearch UI）がAWS GovCloud（US‑East/US‑West）リージョンで利用可能になりました。管理ドメインとサーバーレスコレクションを単一のエンドポイントから横断的に探索・可視化できるようになります。

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

今回の拡張で、GovCloudリージョンでもOpenSearchのモダンな運用分析体験（OpenSearch UI）が利用可能になりました。主な機能は以下の通りです。

  • Workspaces: チームごとに専用の作業空間を作成し、ダッシュボードや保存クエリ、関連コンテンツを共有・管理できます。コラボレーションと生産性の向上を目的としています。
  • Discoverの強化: ログ探索インターフェースが刷新され、Piped-Processing-Language (PPL) と SQL を含むクエリ言語サポート（既存のDQLやLuceneも含む）を統合。クエリ補完（オートコンプリート）や新しいビジュアルデザイン、データセレクタ機能により複数ソースのデータを切り替えずに分析可能です。
  • 単一エンドポイントでの横断検索: 管理対象のOpenSearchドメイン（バージョン1.3以上）とOpenSearch Serverlessコレクションの両方に接続でき、ユーザーはUI側の最新版機能を利用しながら、基盤となるクラスタやコレクションのバージョンに依存せずに最新のUI改良を享受できます。

技術的には、OpenSearch UIはフロントエンド側の体験を強化するもので、バックエンド（ドメイン/コレクション）が提供する検索・集計APIを利用します。接続対象はOpenSearchドメイン(v>1.3)とServerlessコレクションで、GovCloud (US‑East / US‑West) にデプロイされたリソースで利用可能です。開始方法はAWS Management ConsoleでOpenSearchアプリケーションを作成してください。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ解析者、SRE/運用チーム、ログ/トレース分析を行う開発者や分析者
  • 利用シーン: GovCloud環境でのログ探索・検索、可観測性（観測データ）の分析、セキュリティインシデントの調査、複数データソースを跨いだクエリ実行やダッシュボード作成
  • 運用効果: 単一UIで管理ドメインとサーバーレスデータを横断して分析できるため、ツール切替の手間削減と調査・可視化作業の効率化が期待できる

技術的な注意点 ​

  • サポートバージョン: OpenSearchドメインはバージョン1.3以上が必要です。Serverlessコレクションもサポート対象です。
  • IAM権限: OpenSearchの管理・閲覧に必要なIAMポリシー（およびOpenSearchのアクセスポリシーやCognito設定）が適切に構成されている必要があります。コンソールでのOpenSearchアプリ作成・操作権限を確認してください。
  • リージョン制限: 現時点での拡張対象はAWS GovCloud (US‑East) と AWS GovCloud (US‑West) のみ。商用パブリックリージョンとは別に展開されています。
  • VPC/ネットワーク: VPC内に配置されたOpenSearchドメインへはネットワーク経路（VPN、Direct Connect、またはプロキシ経由のアクセス）とセキュリティグループ/ネットワークACL設定が必要です。ブラウザからのアクセスやコンソール統合時の接続要件を確認してください。
  • 機能互換性: UIは最新の表示・UX機能を提供しますが、一部の高度な分析機能やプラグイン依存の機能はバックエンドのOpenSearchバージョンや設定に依存します。古いクラスタでは一部機能が制限される場合があります。
  • コスト: OpenSearch UI自体に明示的な追加料金は案内されていませんが、検索・クエリ実行、ストレージ、サーバーレスコレクションの利用等は通常のOpenSearch Serviceの料金が発生します。データ転送量にも注意してください。

参考情報 ​

[ECS] Amazon ECS with AWS Fargate now supports 32vCPU compute configurations ​

概要 ​

Amazon ECS on AWS Fargateで32vCPUのタスクサイズがサポートされました。最大244 GiBメモリまで選択でき、高負荷なバッチ処理やAI推論などのコンピュート集約型ワークロードをサーバーレスで実行できます。

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

新しいFargateタスクサイズは32vCPUに対応し、メモリは60 GiB、120 GiB、244 GiBのいずれかを選択可能です。x86（Intel/AMD）およびARM（Graviton）ベースのLinuxワークロードをサポートし、FargateおよびFargate Spotの両方で利用できます。既存のAmazon ECSのタスク定義に対して、vCPUを32に設定し（taskDefinitionでvCPU=32）、対応するメモリ値を指定するだけで利用開始できます。新しい構成はCompute Savings Plansの対象で、従来のFargateの信頼性・セキュリティ・スケーラビリティを維持しつつ、より大きなコンテナや単一タスク内での大規模処理を可能にします。料金や詳細はAWS Fargateの料金ページとAmazon ECSドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: コンピュート集約型アプリケーション開発者、データエンジニア、機械学習エンジニア、SRE/運用チーム
  • 利用シーン: 大規模データ処理（ETL/バッチ）、AI推論や推論サーバ、HPC風の処理、メモリ/CPUを大量に使う単一コンテナアプリケーションのコンテナ化
  • 運用効果: 単一タスクでより大きなワークロードを処理できるため、分割や複雑なオーケストレーションを減らして運用を簡素化できる
  • コスト面の影響: 大容量vCPU/メモリは従来より高コストとなるが、Fargateのオンデマンド／Spot選択肢やCompute Savings Plansで最適化可能

技術的な注意点 ​

  • IAM権限: タスク登録・実行にはecs:RegisterTaskDefinition、ecs:RunTask、ecs:CreateServiceなどのECS権限と、タスク実行ロールに対するiam:PassRoleが必要です
  • リージョン制限: 記事では全てのAWS商用リージョンおよびAWS GovCloud(US)で利用可能と明記されています。中国リージョン（aws.cn）での可用性は明記されていないため、利用前にリージョンごとのドキュメントを確認してください
  • コスト: 32vCPU/大容量メモリは従来の小さいタスクよりコストが上がります。Fargateの料金ページを確認し、必要に応じてFargate SpotやCompute Savings Plansでコスト最適化してください
  • タスク定義での指定方法: taskDefinitionでvCPU値を"32"に設定し、メモリはGiB指定に対応するMiB値（例: 60 GiB=61440 MiB、120 GiB=122880 MiB、244 GiB=249856 MiB）を設定してください（ECSのAPI/CLIではMiB単位で指定するケースが多い点に注意）
  • プラットフォーム/互換性: 現時点ではLinuxコンテナでのサポートが明記されています。Windowsコンテナの対応状況や特定のFargateプラットフォームバージョン要件はドキュメントで確認してください
  • サービスクォータ: アカウント/リージョンごとのFargate vCPU/タスク数のクォータが存在します。大規模導入時はクォータ引き上げ申請が必要になる場合があります
  • その他: コンテナごとのmemoryReservation/memory設定や各コンテナのメモリ・CPU割当は従来のルールが適用されます。大容量タスクではネットワークインターフェイスやENIに起因するIPアドレス制約、スタートアップ時間の増加など運用面の影響が出る可能性があるため検証を行ってください

参考情報 ​

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

Copyright © 2026