AWS What's New Digest

Appearance

2026年06月04日 ​

[Mq] Amazon MQ is now available in the AWS European Sovereign Cloud (Germany) Region ​

概要 ​

Amazon MQ for RabbitMQがAWS European Sovereign Cloud (Germany)リージョンで利用可能になりました。EU域内に配置された独立クラウド環境で、規制産業や公共セクターのデータ主権要件に対応しつつ、マネージドRabbitMQブローカーを提供します。

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

Amazon MQ for RabbitMQは、ブローカーのプロビジョニング、パッチ適用、保守運用をマネージドで行うサービスです。今回、AWS European Sovereign Cloud (Germany)内で利用可能になり、データがEU内に留まる環境でRabbitMQを運用できます。サポートされるRabbitMQエンジンはバージョン4.2で、Graviton3ベースのm7gインスタンスタイプ（m7g.medium～m7g.16xlarge）を利用可能なため、低レイテンシかつ高スループットなメッセージングが期待できます。既存のRabbitMQアプリケーションはAPIやプロトコル互換によりアプリケーションコードを書き換えずに移行可能です。運用面ではAWSがブローカーの管理作業（パッチ、フェイルオーバー、バックアップ等）を代行するため、開発者はメッセージングロジックに集中できます。開始手順や詳細はAmazon MQ製品ページおよびDeveloper Guideを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 規制業界（金融、ヘルスケア等）や公共セクター、データ主権要件を持つ企業のクラウド/ミドルウェア担当者
  • 利用シーン: EU域内にデータを保持したままRabbitMQベースのメッセージングをマネージドで運用するケース（マイクロサービス間の非同期連携、キューイング、イベント駆動アーキテクチャ）
  • 運用効果: AWSがブローカーのプロビジョニング・パッチ適用・保守を代行することで、運用負荷と運用ミスを低減し、迅速なスケーリングと高可用性を実現可能
  • コンプライアンス効果: データがEU内に留まるため、データ主権・地域的規制（GDPRや国内法）対応が容易になる

技術的な注意点 ​

  • リージョン制限: 本対応はAWS European Sovereign Cloud (Germany)リージョンに限定されています。他のリージョンとは別の独立したクラウド環境であるため、利用前にリージョンの可用性とサービス連携を確認してください
  • エンジン/インスタンス: サポートされるRabbitMQエンジンは4.2、インスタンスタイプはGraviton3ベースのm7g.medium～m7g.16xlargeです。選定はパフォーマンスとコストのバランスを考慮してください
  • 互換性/移行: 既存のRabbitMQプロトコル（AMQP等）やAPIは互換性が保たれており、アプリケーションコードの大幅な書き換えなしに移行可能ですが、接続設定や認証情報は環境に合わせて更新が必要です
  • IAM権限: Amazon MQの操作には適切なIAM権限が必要です。事前に必要なAPIアクション（例: mq:CreateBroker 等）を確認し、最小権限でロール/ポリシーを設計してください
  • ネットワーク/接続: VPC、サブネット、セキュリティグループ、ENIなどのネットワーク設定が必要です。オンプレミスや他リージョンとの接続（VPN/Direct Connect/Transit Gateway）についてはSovereign Cloud側の接続オプションを確認してください
  • 監視・ログ: CloudWatchやログエクスポート等の連携状況を事前に確認してください。Sovereign Cloud環境でのログ保持や監査要件は別途確認が必要です
  • コスト: インスタンスタイプやストレージ、データ転送に基づく料金が発生します。Sovereign Cloudは特定リージョンの料金体系が適用されるため、利用前にリージョン別料金を確認してください
  • サポート/制限: 一部のAWSサービス連携やリージョン間機能は制限される場合があります。移行前に必須の統合（認証、監視、運用ツール等）が利用可能か確認してください

参考情報 ​

[Bedrock] Amazon Bedrock launches a redesigned console optimized for OpenAI- and Anthropic-compatible APIs ​

概要 ​

Amazon Bedrockが、OpenAIおよびAnthropic互換API（bedrock-mantleエンドポイント）に最適化された再設計コンソールを公開しました。モデルの比較、プロジェクト単位の評価→本番ワークフロー、プロジェクト対応のサンプルコードで評価から実装までを簡素化します。

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

新しいBedrockコンソールはbedrock-mantleエンドポイント（OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages API互換）向けにワークフローを刷新しています。主な技術的ポイントは以下の通りです。

  • モデルカタログ: ClaudeやGPT系、open-weightモデルを含むフルカタログを一画面で参照可能。能力（生成/補完などのモダリティ）、コンテキストウィンドウ、適用可能なサービスクォータをサイドバイサイドで比較できます。
  • プロジェクト単位ワークフロー: 開発ライフサイクルに合わせてプロジェクトを作成し、評価（ベンチマーク・メトリクス取得）、設定変更、利用状況のインサイトを一連の画面で実行・管理できます。
  • プロジェクト対応ドキュメント: コンソール内のコードサンプル、SDKスニペット、API参照は自動的にプロジェクトの選択したmodel ID、リージョン、bedrock-mantleエンドポイントURL、APIキー参照で事前入力されます。モデルや設定を切り替えるとスニペットも更新され、既存のOpenAI/Anthropicクライアントライブラリに対して修正不要でそのまま貼り付けて実行できる設計です。
  • 既存クライアント互換性: 開発者はOpenAIやAnthropicの既存ライブラリ（Responses/Chat Completions/Messages互換）をそのまま使用し、認証にAmazon BedrockのAPIキーを利用してbedrock-mantle経由でリクエスト可能です。
  • リージョン対応: bedrock-mantleを提供する全リージョンで新コンソールを利用可能（記事記載の米国・アジア太平洋・欧州・南米リージョン）。

影響範囲・利用シーン ​

  • 対象ユーザー: LLMを使ったアプリケーション開発者、データサイエンティスト、SRE/運用チーム
  • 利用シーンまたは効果: モデル比較→評価→本番デプロイの短縮化、既存のOpenAI/Anthropicクライアントを再利用して移行コストを低減
  • 運用効果: プロジェクト単位でのメトリクスとクォータ可視化により性能劣化やコスト高騰の早期検知が可能
  • 開発スピード: プロジェクト対応コードスニペットによりプロトタイプから実装への手戻りが削減され、実装速度が向上

技術的な注意点 ​

  • IAM権限: BedrockコンソールやAPIキーを操作するための適切なIAMポリシー（Bedrock関連のCreate/Describe/Invoke権限など）が必要です。APIキー管理やプロジェクト操作権限を分離することを推奨します。
  • リージョン制限: 新コンソールはbedrock-mantleエンドポイントを提供するリージョンで利用可能です。対象リージョンは記事の記載（US East N. Virginia, US East Ohio, US West Oregon, Asia Pacific Jakarta/Mumbai/Sydney/Tokyo, Europe Frankfurt/Ireland/London/Milan/Stockholm, South America São Paulo）です。リージョンによりモデル可用性が異なる場合があります。
  • コスト: Bedrockの通常課金体系（モデル呼び出しごとの料金、トークン単位の課金など）が適用されます。大量テストや長文コンテキストを用いる評価はコストが増加するため注意してください。ネットワーク転送（egress）やログ保管など追加コストも発生する可能性があります。
  • 互換性と挙動差異: bedrock-mantleはOpenAI/Anthropic互換APIを提供しますが、各モデルやプロバイダ固有の出力特性やパラメータ（トークン数の扱い、温度やストップシーケンスの細かい挙動など）に差異があります。実運用前に十分な評価を行ってください。
  • セキュリティ/データ保護: APIキーの管理（ローテーション、Secrets Manager連携）、アクセスログの監査、データの送信先・保持期間について社内ポリシーやコンプライアンス要件を確認してください。
  • サービスクォータ: モデルごとの同時リクエスト制限やトークン処理上限があるため、コンソールのクォータ表示やService Quotasの設定を確認し必要に応じて引き上げ申請してください。

参考情報 ​

[Iot Core] AWS IoT Device Management adds MQTT session data to connectivity status API ​

概要 ​

AWS IoT Device Managementのconnectivity status APIがMQTTセッション情報を返すよう拡張され、thing nameで取得できる詳細な接続・セッション情報（タイムアウト/expiryやソケット情報など）により接続障害の調査や接続パターンの監査が可能になりました。IoT CoreのGetConnection APIと機能的に揃い、接続データは無期限に保持されます。

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

追加された主な項目は、MQTTセッションのtimeout値およびsession expiry値、さらにオプションでソケットレベル情報（送信元/宛先IPアドレス、ポート、クライアントVPCエンドポイントID）です。既存の接続ステータス、タイムスタンプ、切断理由に加え、これらのメタデータをthing nameで取得できます。ソケット情報へのアクセスは細かいIAMポリシーで制御でき、必要なチームだけに許可可能です。AWS IoT CoreのGetConnection APIは切断後30分分のみデータを保持しますが、IoT Device Managementのconnectivity status APIは情報を無期限に保存するため、長期的な調査・監査が可能です。本機能はAWS IoT Device Managementがサポートされる全リージョンで利用可能です。注意点として、対象デバイスはAWS IoT CoreのThing Registryに登録されている必要があります。API利用は既存のDevice Management API/参照ドキュメントに従って行います。

影響範囲・利用シーン ​

  • 対象ユーザー: IoTプラットフォーム運用者、SRE、フィールドサービス/エンジニア、セキュリティ／コンプライアンス担当
  • 利用シーン: デバイス接続問題の原因追跡（切断理由、セッション期限、ソケット情報の確認）、接続/再接続パターンの監査、長期的な障害解析やフォレンジック
  • 運用効果: 切断原因やセッションメタデータをオフライン後も参照できるため、再現困難な接続障害の原因究明が容易になる。必要チームに限定したIP/ソケット情報の付与で調査と情報管理を両立可能
  • データ保持: GetConnection（IoT Core）は30分保持に対し、Device Managementのconnectivity status APIは無期限保持のため、長期間のトレンド分析や監査に向く
  • セキュリティ/ガバナンス: ソケット情報は機微データ（IP等）であるためIAM制御やログ保管ポリシー、プライバシー要件を適用する必要あり

技術的な注意点 ​

  • IAM権限: ソケットレベル情報へのアクセスは粒度の細かいIAMポリシーで制御されます。必要なAPI権限を事前に確認・付与してください
  • リージョン制限: 本機能はAWS IoT Device Managementがサポートされるすべてのリージョンで利用可能です（ただし、使用前に対象リージョンでのサービスサポート状況を確認してください）
  • コスト: 記事では追加料金は明記されていませんが、データを無期限に保持することで監査やログ保管に伴うストレージ・分析コストが増加する可能性があります。長期保持ポリシーやログのエクスポート先（S3/ログ管理）を設計してください
  • 前提/制約: 対象はAWS IoT CoreのThing Registryに登録されたデバイスのみです。また、接続情報の取得はthing nameをキーに行います
  • 互換性: AWS IoT CoreのGetConnection APIと機能的に整合しましたが、GetConnectionは短期間（30分）しか保持しない点が異なります

参考情報 ​

[SageMaker] Amazon SageMaker Data Agent now supports conversation history ​

概要 ​

Amazon SageMaker Data Agentが会話履歴をサポートするようになりました。SageMaker Unified Studio内で過去の会話やエージェント生成コードを参照・再開でき、分析セッションの継続性を保てます。

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

会話履歴の追加により、Data Agentのチャットパネル上で過去のやり取りをスクロールして参照可能になりました（チャットパネルヘッダーの時計アイコンからアクセス）。各会話には自動生成されたタイトルとタイムスタンプが付与され、ノートブックやQuery Editorワークフロー内でエージェントが生成したコードやトラブルシューティングの履歴を再利用・復元できます。これにより複数ステップの解析を途中から再開したり、以前の解析で得たコード断片を再利用して作業効率を上げることができます。会話履歴機能は、Amazon SageMaker Data Agentが利用可能な全リージョンで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: データアナリスト、データサイエンティスト、SageMakerを使う分析チーム
  • 利用シーン: マルチステップの解析を途中から再開する、エージェント生成コードを再利用する、過去のノートブック実行時のトラブルシューティング履歴を確認する
  • 運用効果: セッション間のコンテキスト保持により再作業を削減し、分析スピードを向上させる。複数プロジェクト並行時のコンテキスト管理が容易になる

技術的な注意点 ​

  • IAM権限: SageMaker Studio/Unified StudioおよびData Agentへのアクセス権限（sagemaker:OpenStudio、sagemaker:CreatePresignedDomainUrl等の権限やノートブック実行ロール）を確認してください
  • リージョン制限: Amazon SageMaker Data Agentが利用可能な全リージョンで提供されています。未対応リージョンでは利用できません
  • データ保持とセキュリティ: 会話内容（エージェント生成コードや入力データ）が保存されます。機密データの取り扱いや保存期間、ログ出力先については組織のポリシーに合わせて確認・制御してください（暗号化・アクセス制御の確認推奨）
  • コスト: 会話履歴そのものに明示的な追加料金は案内されていませんが、SageMakerのノートブック／インスタンスやクエリ実行等は通常の利用料金が発生します。大量の履歴保存や連携サービスの利用は間接的にコスト影響が出る可能性があります
  • 利用環境: 機能はSageMaker Unified Studioのチャットパネル（時計アイコン）から利用します。ノートブックとQuery Editorのワークフローに連携します
  • 注意点: 会話履歴の具体的な保持期間や共有スコープ（ユーザー単位かワークスペース単位かなど）はドキュメントで確認してください。履歴は便利ですが、再現性やバージョン管理のため重要なコードは別途リポジトリで管理することを推奨します

参考情報 ​

[SageMaker] Amazon SageMaker Unified Studio now supports notebook scheduling ​

概要 ​

Amazon SageMaker Unified Studioで、ノートブックをUIから直接スケジュール実行・パラメータ化・オーケストレーションできる機能が追加されました。外部オーケストレーション基盤を用意せずに実験ノートブックを定期処理や本番ワークフローへ移行しやすくなります。

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

主な機能と動作のポイント:

  • ノートブックのバックグラウンド実行: ノートブックの「Run all」メニューから「Run in background」を選択し、対話セッションを中断せずに専用のコンピュートで実行できます。オンデマンド実行と定期／繰り返しスケジュールの両方に対応します。
  • ノートブックのパラメータ化: ノートブック内でパラメータを定義し、スケジュールやオンデマンド実行時に値を上書きすることで、同一ノートブックを異なる入力（例：複数キャリア毎の配送レポート）で再利用できます。
  • マルチノートブックのオーケストレーション: Workflows ツールの Notebook Operator を使ってノートブック同士をチェーンし、ある実行の出力を次のノートブックの入力として受け渡すワークフローを構築できます。
  • AI支援トラブルシューティング（SageMaker Data Agent）: 定期実行やバックグラウンド実行で失敗が発生した場合、Data Agent がノートブック内で原因の特定と修正案の提示を行い、解決時間を短縮します。また、Data Agent に自然言語でスケジュール作成やノートブック実行を指示することも可能です。
  • 利用開始方法: Unified Studioでノートブックを開き、Run all ボタンのメニューから Run in background を選ぶか、ノートブックヘッダーのスケジュールアイコンからスケジュールを作成します。
  • リージョン: Amazon SageMaker Unified Studio がサポートされているすべての AWS リージョンで利用可能です（リージョンごとの対応状況は事前に確認してください）。

影響範囲・利用シーン ​

  • 対象ユーザー: データサイエンティスト、機械学習エンジニア、MLOpsチーム、SRE/運用チーム
  • 利用シーンまたは効果: 毎日・毎時のレポート生成、データ品質チェック、定期的なモデル再学習、パラメータを変えた多テナント処理の自動化、ノートブックベースのパイプライン化
  • 運用効果: 外部オーケストレーション基盤の運用負荷削減、実験から本番への移行が容易に、再現性の向上、障害発生時の診断時間短縮
  • コスト影響: 定期実行やバックグラウンド実行で専用コンピュートが起動するため、実行時間分のコンピュート・ストレージコストが発生します（頻度とリソースサイズに依存）

技術的な注意点 ​

  • IAM権限: ノートブック実行、Workflows、Data Agent を操作するために、SageMaker および関連サービス（S3、CloudWatch Logs、KMS、EventBridgeなど）への適切な権限が必要です。事前にStudioの実行ロール／ユーザーポリシーを確認してください。
  • リージョン制限: 「SageMaker Unified Studio がサポートされているリージョン」で利用可能です。実際に利用するリージョンで機能が有効か事前確認してください。
  • コスト: 定期実行はノートブック用のコンピュートリソースを消費します。実行頻度・インスタンスタイプ・ストレージ量に応じて課金されるため、コスト見積もりとガバナンス（実行上限やスケジュール設計）を検討してください。
  • ノートブック設計: パラメータ化・自動実行を行うにはノートブックをパラメータ受け取り可能な形にしておく必要があります（変数化、入出力の明確化、非対話的実行に耐える処理構成など）。
  • 互換性と権限周り: Notebook Operator や Workflows を用いる際はワークフロー実行ロールが各ノートブックで参照するリソース（S3バケット、モデルアーティファクト、ECRイメージなど）へアクセスできるか確認してください。
  • Data Agent 利用上の注意: 自然言語での操作は利便性が高い反面、機密情報や権限付与に関する操作を行う際は注意が必要です。出力や提案内容は必ずレビューしてください。

参考情報 ​

[Step Functions] AWS Step Functions adds AgentCore-powered agentic reasoning step ​

概要 ​

AWS Step FunctionsがAmazon BedrockのAgentCoreハーネス（プレビュー）と最適化統合され、ワークフロー内でエージェントによる推論（agentic reasoning）ステップを直接組み込めるようになりました。これにより文書分類や非構造化フォームからの抽出などの自動意思決定をワークフローでシームレスに実行できます。

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

今回の統合は、Amazon Bedrockの管理ハーネスであるAgentCore（現時点ではプレビュー）をStep Functionsのステップとして呼び出せる機能を提供します。AgentCoreハーネスは、モデル、ツール（外部APIやカスタムツール）、およびエージェントの振る舞いを設定ファイルで宣言でき、マネージド環境でエージェントのループ（思考→行動→観察→反復）をエンドツーエンドで実行します。主な機能は次のとおりです：

  • エージェントをワークフローのステップとして組み込み、文書分類・情報抽出・意思決定などのタスクを自動化可能。
  • 単一ワークフロー内で複数エージェントを並列または直列に実行し、重要アクションの前に人間の承認ステップを挟む設計が可能。
  • 実行履歴にエージェントの入力・出力・トークン使用量・実行時間を記録し、CloudWatchのエージェントターン詳細へのリンクで意思決定のトレーサビリティと監査を可能に。
  • 既存のAgentCoreハーネスを再利用できるほか、Step FunctionsのWorkflow Studio（ビジュアルビルダー）から直接新規ハーネスを作成可能。
  • per-invocation（実行ごと）オーバーライド機能によりモデル、システムプロンプト、使用ツールを実行単位で上書きでき、ハーネス設定の重複を避けつつコンテキストに応じた調整が可能。
  • セッションIDを使ってエージェントコンテキストを実行内外で永続化できるため、複数実行にまたがる会話や状態保持が可能。
  • 利用可能リージョンは、AgentCoreハーネスのプレビューが有効なリージョン（米国東部（バージニア北部）、米国西部（オレゴン）、欧州（フランクフルト）、アジアパシフィック（シドニー））。
  • 料金はStep Functionsの標準料金がワークフロー実行に適用され、AgentCore/Bedrockのモデル推論や関連リソースはそれぞれの標準料金が別途適用されます。統合利用に追加の統合料金は発生しません。

影響範囲・利用シーン ​

  • 対象ユーザー: ワークフロー自動化を行うクラウドエンジニア、SRE、データエンジニア、アプリケーション開発者
  • 利用シーン: 非構造化データからの情報抽出、文書分類、決定支援ワークフロー、チャットボットのバックエンド判断、承認ワークフローへの自動判定挿入
  • 運用効果: 人手による判断を自動化してスループットを向上させ、実行履歴とCloudWatch連携により意思決定のトレーサビリティと監査を強化できる
  • 設計上の利点: ハーネスの再利用と実行ごとのオーバーライドで設定の肥大化を避けつつ柔軟にモデル/プロンプトを切り替え可能
  • 制約: AgentCoreハーネスがプレビュー提供されているリージョンに限定されるため、本番導入前に利用可能リージョンを確認する必要あり

技術的な注意点 ​

  • IAM権限: Step Functions実行ロールにBedrock/AgentCore呼び出し、CloudWatch Logsへの書き込み、および必要なツール（Lambda、API呼び出し等）を実行するための権限を付与する必要があります
  • リージョン制限: AgentCoreハーネスのプレビュー提供リージョン（米国東部（バージニア北部）、米国西部（オレゴン）、欧州（フランクフルト）、アジアパシフィック（シドニー））でのみ利用可能です
  • コスト: Step Functionsの実行料金が適用され、AgentCore/Bedrockでのモデル推論は別途課金されます。トークン使用量（モデル呼び出し回数や生成トークン数）が増えるとコストが増加する点に注意してください。CloudWatch Logsの保存・取得にも費用が発生します
  • プレビュー注意: AgentCoreハーネス統合はAgentCore側がプレビューでの提供のため、機能や挙動、リージョン対応が将来変更される可能性があります
  • データ保護: セッションIDでコンテキストを跨いで永続化する場合、保存されるデータに個人情報や機密情報が含まれる可能性があるため暗号化・アクセス制御・保持ポリシーを設計してください
  • 性能/レイテンシ: モデル推論は外部呼び出し（Bedrock）のレイテンシや同時実行制限に依存します。高並列ワークロードではスループット制限やコストを事前に評価してください
  • 監査/可観測性: 実行履歴でトークン使用量やターン詳細へのリンクが提供されますが、詳細ログ保持ポリシー（CloudWatchの保持期間やS3アーカイブなど）を事前に設計してください

参考情報 ​

[Govcloud Us] OpenAI GPT-5.4 generally available on Amazon Bedrock in AWS GovCloud (US-West) ​

概要 ​

Amazon BedrockでOpenAIのGPT‑5.4がAWS GovCloud (US‑West)で一般提供開始されました。政府機関や規制業界向けに、GovCloudのコンプライアンス範囲内で最先端の大規模モデルを利用できます。

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

GPT‑5.4はネイティブな“computer‑use”能力（外部ツール操作やマルチステップのエージェントタスク実行を含む）と、コード理解・ドキュメント処理・深い推論能力を強化したフロンティアモデルです。Amazon Bedrock上では高性能な推論エンジンで動作し、ワークロードごとに分離されたキュー（isolated queues）と耐障害性のある状態保持（durable state）を提供するため、長時間あるいは状態を伴うマルチステップ処理でも安定した実行が可能です。データの取り扱いについては「in‑partition」に保持され、モデル学習に使用されないと明記されており、データレジデンシーや機密データ管理の要件に配慮されています。地域別の提供状況はAWS Regionsページで確認してください。導入手順やAPI/SDKの詳細はAmazon Bedrockのドキュメントと導入ブログを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 政府機関、規制業界（ヘルスケア、金融、防衛関連のSaaS/システムベンダー）およびセキュアな環境で最新LLMを使いたいエンタープライズ顧客
  • 利用シーン: コード生成・レビュー、法令・規程文書解析、マルチステップの自動化エージェント、機密データを扱う分析やレポート生成
  • 運用効果: GovCloud上のコンプライアンス枠組みに沿った形で高性能な推論を実行でき、状態保持や分離されたキューによりフォールトトレランスとスケーラブルなバッチ/対話処理が可能になる

技術的な注意点 ​

  • IAM権限: BedrockのAPI呼び出し権限（AmazonBedrock関連のポリシー）やKMSキーへのアクセス許可を事前に設定してください。サービスロールやVPCエンドポイントの設定が必要になる場合があります。
  • リージョン制限: 現時点でAWS GovCloud (US‑West)で一般提供。その他リージョンでの利用可否はAWS Regionsページで確認してください。商用リージョンとGovCloudの提供差異に注意。
  • コスト: Bedrockのモデル推論料金に加え、状態保持やストレージ、ネットワーク転送、KMS暗号化などの追加コストが発生する可能性があります。料金体系はリージョンとモデルによって異なります。
  • データ保護: 記載どおりモデル学習にはデータは使用されないとされていますが、機密データの取り扱いは組織のポリシーに従い、暗号化とアクセス制御を必須にしてください。
  • 互換性/SDK: AWS SDKおよびBedrockのAPIで利用可能。既存の推論パイプラインに統合する際はAPIバージョンとパラメータ（状態管理・キュー設定）に注意してください。
  • 運用上の注意: 長時間実行や状態を伴うワークロードは耐障害性のテスト（フェイルオーバー、再試行、スロットリング対策）を推奨します。

参考情報 ​

[Compute Optimizer] AWS Compute Optimizer now supports 32-day lookback for EBS volume and ECS service rightsizing recommendations ​

概要 ​

AWS Compute OptimizerがAmazon EBSボリュームとAmazon ECSサービスの権利適正化（rightsizing）推奨で、デフォルトの14日から32日へのルックバック期間拡張をサポートするようになりました。月次の利用パターンを考慮できるため、より適切なサイズ提案が可能になります。

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

これまではデフォルトで14日間の利用状況を基にCompute Optimizerが権利適正化の推奨を生成していましたが、今回EBSボリュームとECSサービスに対してルックバック期間を最大32日間に延長できるオプションが追加されました。32日間ルックバックは、既に対応している以下5種の推奨タイプで利用可能です：EC2インスタンス、EC2 Auto Scalingグループ、RDSデータベース、EBSボリューム、ECSサービス。ルックバック期間は組織（Organization）単位、アカウント単位、またはリソース単位で設定可能で、AWS マネジメントコンソール、AWS SDK、および AWS CLI から変更できます。追加料金は発生しません。利用状況のピーク（例：月末処理）など月次パターンを考慮することで、過小・過大プロビジョニングの防止やパフォーマンス確保に寄与します。対応リージョンはCompute Optimizer提供リージョンのうち、AWS GovCloud（US）および中国リージョンを除く全リージョンです。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド費用最適化担当者、SRE、プラットフォーム/インフラエンジニア、容量計画担当者
  • 利用シーンまたは効果: 月次や定期バッチ処理で利用パターンに周期性があるワークロード（例：月末処理、月次レポート、請求処理など）に対して、より実態に即したサイズ推奨が得られ、誤った縮小による性能劣化を防げます
  • 運用効果: 権利適正化の精度向上によりコスト削減の可能性が高まり、パフォーマンスリスク低減と運用判断の安定化につながります

技術的な注意点 ​

  • IAM権限: Compute Optimizerの推奨設定を変更するにはCompute Optimizerの設定変更権限および対象アカウント/組織の管理権限が必要です。組織レベルの変更はマネジメントアカウントまたは適切なOrganizations権限を持つユーザーで実施してください
  • リージョン制限: Compute Optimizerが提供されている全リージョンで利用可能ですが、AWS GovCloud (US) リージョンと中国リージョンでは未対応です
  • コスト: Compute Optimizer側の追加料金は発生しません。ただし、長期間のメトリクス収集やカスタム監視を別途有効にする場合はCloudWatchなどのサービスに関連する料金が発生する可能性があります
  • データ解釈: 32日ルックバックは月次ピークを反映するため、ピーク対策としてより保守的（大きめのサイズ推奨）になる傾向があります。推奨を適用する際は業務要件（性能SLAや一時的スパイクの許容度）を確認してください
  • 設定適用階層: ルックバック期間は組織→アカウント→リソースの階層で上書き可能です。組織レベルで設定する場合は、管理アカウントの操作と連携設定の確認が必要です

参考情報 ​

[General] ARC Region switch adds Amazon Aurora scaling and Amazon Neptune global database failover ​

概要 ​

Amazon Application Recovery Controller (ARC) の Region switch に、Amazon Aurora のスケーリング（serverless と provisioned）と Amazon Neptune グローバルデータベースのフェイルオーバーを自動化する3つの実行ブロックが追加されました。マルチリージョンのアクティブ-パッシブ構成における復旧時間短縮と手動作業の削減を目的としています。

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

今回追加された実行ブロックは以下の通りです。

  • Amazon Aurora serverless scaling 実行ブロック: Aurora Serverless のセカンダリクラスタを Region switch の一部として自動的にスケールさせ、フェイルオーバー後に本番負荷をさばける状態にします。これにより手動での容量調整や待ち時間を削減します。

  • Amazon Aurora provisioned scaling 実行ブロック: プロビジョンド（インスタンス型）Aurora クラスタのセカンダリに対してインスタンスの追加/サイズ変更やクラスタのリサイズを自動化します。アクティブ-パッシブ構成でコスト削減のために縮小している二次クラスタを、フェイルオーバー前後で適切なサイズに右詰め（right-size）します。

  • Amazon Neptune global database failover 実行ブロック: Neptune グローバルデータベースに対し、計画的なスイッチオーバー（planned switchover）と計画外のフェイルオーバー（unplanned failover／detach-and-promote のような操作）を一つのプラン内で自動化します。手動スクリプトやケースバイケースの判断を不要にします。

共通特長:

  • これらの実行ブロックは ARC の Region switch プランに組み込み可能で、フェイルオーバーのワークフロー中に自動実行されます。
  • クロスアカウントのオーケストレーションをサポートし、単一プランで複数アカウント／複数リージョンにまたがる DB 操作を調整できます。
  • 目的はフェイルオーバー時の手作業を削減し、復旧時間（RTO）を短縮するとともに運用ミスを減らすことです。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチリージョン構成で Amazon Aurora（Serverless／Provisioned）または Amazon Neptune グローバルデータベースを利用しているアプリケーション所有者／SRE/運用チーム
  • 利用シーン: リージョン障害発生時の Region switch（フェイルオーバー）実行時に、二次クラスタのスケーリングや Neptune のスイッチオーバー／フェイルオーバーを自動化して復旧を実行する場面
  • 運用効果: 手動でのクラスタリサイズやスクリプト実行を排除でき、フェイルオーバーに要する時間を短縮。コスト最適化（縮小済み二次クラスタの維持）と復旧時の性能確保を両立可能
  • クロスアカウント運用: 単一の Region switch プランで複数アカウントへまたがるデータベース操作を調整できるため、大規模組織の統合オーケストレーションが容易になる

技術的な注意点 ​

  • IAM権限: ARC が対象アカウントの RDS/Aurora および Neptune リソースへ操作を実行できるよう、適切なクロスアカウントロールと最小権限ポリシー（DB クラスタのスケール/変更、フェイルオーバー操作を許可する権限）が事前に必要です
  • リージョン制限: 新機能のサポート状況はリージョンによって異なる可能性があるため、利用前に対象リージョンでの対応状況を確認してください
  • コスト: フェイルオーバー前後で二次クラスタをスケールアップすると、スケール中は追加インスタンス／容量に対する料金が発生します。Serverless ではプロビジョニング容量（ACU 等）増加に伴う課金に注意してください
  • 前提条件: 対象 DB が Aurora Global Database や Neptune Global Database の適切な構成であること、セカンダリクラスタ（読み取りレプリカ等）が用意されていること、DNS 切替やロードバランサ設定などの運用フローがプランに組み込まれていること
  • テスト／リハーサル: 本番での運用前に ARC のプランを用いたドライランやリハーサルを実施し、スケール時間や接続影響、DNS 切替の手順を検証してください
  • 実行影響: スケーリングやプロモート操作は数分〜数十数分かかる場合があり、接続切断や一時的なパフォーマンス変動が発生する可能性があります。アプリケーション側のリトライや接続再確立を考慮してください
  • ロギング／監査: 実行ログやイベントは CloudWatch / CloudTrail で確認可能です。実行時のトラブルシュートのためにログ出力と通知（SNS 等）の設定を推奨します

参考情報 ​

[Keyspaces] Amazon Keyspaces (for Apache Cassandra) now provides CDC iterator position ​

概要 ​

Amazon Keyspaces の CDC ストリームの GetRecords レスポンスに iteratorPosition が追加され、コンシューマがストリームの先端（tip）に到達しているかどうかを判定できるようになりました。これによりポーリング頻度を動的に調整して CDC 消費コストを低減できます。

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

GetRecords API のレスポンスに iteratorDescription 構造体が追加され、その中の iteratorPosition フィールドが AT_TIP または BEHIND_TIP のいずれかを返します。AT_TIP はコンシューマがストリームの先端にあり追加レコードが現時点でない可能性を示し、BEHIND_TIP は処理待ちのレコードが存在することを示します。これにより、従来の固定間隔ポーリングではなく、ストリームの状態に応じたバックオフや短周期ポーリングの切り替えが可能になり、リアルタイム処理とコスト効率の両立ができるようになります。実装面では、最新の AWS SDK にアップデートする必要があり、既存の CDC コンシューマは GetRecords のレスポンス処理を変更して iteratorPosition を参照するロジック（例: AT_TIP 時は指数バックオフ、BEHIND_TIP 時は高頻度ポーリング）を組み込む必要があります。本機能は Amazon Keyspaces CDC をサポートする全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、ストリーム処理アプリケーション開発者、SRE/運用チーム
  • 利用シーンまたは効果: CDC を使ったリアルタイム分析、レプリケーション、イベント駆動アーキテクチャにおいて、ポーリング頻度の最適化により遅延とコストを両立
  • 運用効果: 無駄なポーリングを削減して CDC 消費コストを低減しつつ、BEHIND_TIP 検知時に即時処理へ移行してデータの取りこぼしを防止

技術的な注意点 ​

  • IAM権限: GetRecords など CDC ストリームにアクセスするための適切な Keyspaces/CDC 用の IAM 権限を確認・付与してください（既存のアクセス許可ポリシーを更新する必要がある場合があります）
  • SDK: iteratorPosition を受け取るには最新の AWS SDK へアップデートが必要です。古い SDK は新フィールドを認識しない場合があります
  • リージョン制限: 本機能は Amazon Keyspaces CDC をサポートする全リージョンで利用可能ですが、利用前に対象リージョンで CDC が有効化されているか確認してください
  • コスト: 本機能自体はポーリング最適化による CDC コンシューム量削減でコスト低減に寄与しますが、CDC ストリーム自体の料金は発生します。ポーリング設計の変更により総コストがどう変化するか検証してください
  • 互換性/移行: 既存のコンシューマは GetRecords レスポンス処理の変更が必要です。AT_TIP/BEHIND_TIP の両ケースを正しくハンドリングし、バックオフ戦略を設計してください

参考情報 ​

[SageMaker] Amazon SageMaker Unified Studio now supports a localized experience in twelve languages ​

概要 ​

Amazon SageMaker Unified Studio のユーザーインターフェイスが12言語のローカライズに対応しました。ブラウザの言語設定自動検出か、プロファイルの「Language selector」から言語を選択することで、UI全体が選択言語で表示されます。

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

対応言語は英語（米国）、中国語（簡体・繁体）、フランス語、ドイツ語、インドネシア語、イタリア語、日本語、韓国語、ポルトガル語（ブラジル）、スペイン語、トルコ語の12言語です。言語はブラウザのデフォルト言語から自動検出され、またはユーザープロファイルの『Language selector』で明示的に選択できます。選択した言語は SageMaker Unified Studio のユーザーインターフェイス全体に反映されます。本機能は SageMaker Unified Studio が利用可能な全リージョンで有効で、AWS IAM Identity Center ベースのドメインおよび IAM ベースのドメインの両方に対応します。なお、本ローカライズは主に Studio のUI文字列（メニュー、ダイアログ、ラベル等）に適用されるものであり、ユーザーがアップロードするデータやノートブック中のコード、モデル出力、CLI/SDK の出力そのものは対象外です。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データサイエンティスト、アナリスト、SRE/運用担当者など、SageMaker Unified Studio を利用するグローバルチームのメンバー
  • 利用シーンまたは効果: 多言語対応により、非英語話者がUIを母語で操作できるため学習コストと操作ミスが低減され、共同作業やオンボーディングが容易になります
  • 運用効果: ドキュメントやトラブルシューティングの言語的障壁が減り、生産性向上とコミュニケーション効率の改善が期待できます

技術的な注意点 ​

  • IAM権限: 基本的には既存の SageMaker Unified Studio へのアクセス権限があれば言語切替は可能です。組織側でプロファイル編集が制限されている場合は管理者の IAM/IAM Identity Center 設定を確認してください
  • リージョン制限: SageMaker Unified Studio が提供されているすべてのリージョンで利用可能です（Studio が未提供のリージョンでは利用できません）
  • コスト: UI ローカライズ自体に追加料金は発生しません（通常の SageMaker 利用料金に基づく）
  • 適用範囲: UI（メニュー、ラベル、ヘルプテキスト等）の表示言語が変更されます。ノートブック中のコードやデータ、モデル出力、CLI/SDK のメッセージは対象外です
  • 翻訳精度: 自動翻訳やローカライズされた表現は文脈に依存するため、専門用語の訳語や表現が期待と異なる場合があります。重要な運用手順は英語版ドキュメントと照合してください
  • 永続性: 記事ではブラウザ自動検出とプロファイルによる手動設定が可能であると明記されています。組織ポリシーによってユーザー側の設定が制限される場合があります

参考情報 ​

[Sagemaker Studio] Amazon SageMaker AI launches multi-turn reinforcement learning for AI agent model customization ​

概要 ​

Amazon SageMaker AIはマルチターン強化学習（Multi-turn RL）によるサーバーレスなモデルカスタマイズ機能を提供開始しました。エージェントの複数ステップ意思決定シーケンスを報酬で評価して小型モデルをタスク特化させることが可能です。

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

Multi-turn RLは、SageMaker AIのモデルカスタマイズ機能の一部として、エージェント環境に対する複数ターン（マルチステップ）のロールアウトを行い、軌跡（trajectory）全体に対する報酬を使って強化学習を実行するサーバーレスな仕組みです。SageMakerがロールアウトのオーケストレーション、軌跡収集、学習ループ、チェックポイント管理を自動で扱い、MLflowによるトラッキングで軌跡・報酬・トレースを可視化できます。評価ジョブはreward、pass@k、trajectoryメトリクスを出力し、SageMaker AIエンドポイントやAmazon Bedrockへのデプロイ前にベンチマーク可能です。エージェントはAmazon Bedrock AgentCore Runtimeでフルマネージドにホストするか、Amazon EKS/EC2/AWS Fargate、あるいは任意のフレームワーク上のインフラに接続できます。課金はサーバーレス方式で処理したトークンに対してのみ発生します。現在、SageMaker StudioとSageMaker Python SDKを通じて利用可能で、サポートモデルの例としてus-west-2でQwen 3.6 27B、Nova Lite 2.0、GPT-OSS-20B、Gemma 31B、および us-east-1でNova Lite 2.0、GPT-OSS-20Bが挙げられています。

影響範囲・利用シーン ​

  • 対象ユーザー: AIエージェント開発者、機械学習エンジニア、SRE/運用チーム
  • 利用シーン: マルチステップワークフロー（対話型アシスタント、業務プロセス自動化、チェーン・オブ・ツールを使うエージェント）のタスク特化モデル学習
  • 運用効果: 小〜中規模モデルをタスクに最適化して大規模汎用モデルと同等以上の精度を低コストで目指せる。インフラ構築の工数を削減し学習ループの管理負荷を軽減する

技術的な注意点 ​

  • IAM権限: SageMaker、S3、ECR（コンテナ利用時）、CloudWatch、必要に応じてEKS/EC2/Fargate関連の権限を用意してください（ロールとポリシーの事前設定が必要です）
  • リージョン制限: 一部モデルは us-west-2 / us-east-1 のみサポートと明記されています。利用前に対象モデルのリージョン対応を確認してください
  • コスト: サーバーレスで「処理したトークン分」で課金されますが、データ保管（S3）、ログ（CloudWatch）、エンドポイントのホスティング、外部インフラ（EKS/EC2/Fargate）使用時の追加費用が発生します
  • ネットワーク/VPC: エージェントをVPC内で動かす場合はVPCエンドポイントやセキュリティグループ、サブネットの設定が必要です。SageMakerのリソースがS3やMLflowにアクセスできるネットワーク構成を確認してください
  • モデルサポート: 対応モデルは限定的です（発表時点の一覧を確認）。カスタムモデルや他リージョンでのサポート状況はドキュメントを参照してください
  • データ保管/チェックポイント: チェックポイントやトラッキング情報（MLflow）はS3等に保存されるため、適切なバケットポリシーとライフサイクル管理（コスト管理）を検討してください
  • 評価と報酬設計: マルチターンRLでは報酬関数設計が結果に大きく影響します。報酬の偏りやスパース報酬に注意し、評価メトリクス（reward、pass@k、trajectory）で定量評価を行ってください
  • 安全性/ガバナンス: RLAIF/RLVR等を使う際はデータプライバシー、モデルの出力制御、監査ログの保持を考慮し、応答の安全性テストを実施してください

参考情報 ​

[Config] AWS Config now supports 9 new resource types ​

概要 ​

AWS ConfigがAmazon Bedrock、Amazon Bedrock AgentCore、Amazon SageMakerのリソースを含む9種類の追加リソースタイプをサポートしました。これにより、より広範なリソースの検出・評価・監査・自動修復が可能になります。

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

追加されたリソースタイプは以下の9件です：AWS::Bedrock::FlowAlias、AWS::BedrockAgentCore::Evaluator、AWS::BedrockAgentCore::GatewayTarget、AWS::BedrockAgentCore::OnlineEvaluationConfig、AWS::BedrockAgentCore::RuntimeEndpoint、AWS::SageMaker::Cluster、AWS::SageMaker::Endpoint、AWS::SageMaker::ModelPackageGroup、AWS::SageMaker::Pipeline。

技術的ポイント：

  • 記録：既に「すべてのリソースタイプ」を記録するようにAWS Configレコーダーを有効にしている場合、これらのリソースは自動的に追跡されます。個別にリソースタイプを指定している場合はレコーダー設定を更新して新リソースを追加してください。
  • 履歴と関係性：各リソースの設定アイテム（configuration item）やリソース間の関係性がConfigに保存されるため、変更履歴や依存関係のトラブルシュートが可能です。
  • ルールと集約：新しいリソースタイプはConfig RulesやConfig Aggregatorで利用可能。ルールを作成して準拠性チェックや自動修復（Remediation）を行えます。マルチアカウント／マルチリージョン集約にも対応しており、ガバナンスの一元管理が可能です。
  • 適用範囲：これらのリソースは、それぞれのサービスが利用可能なAWSリージョンで監視できます。サービス側のリージョン制限に従います。

利用例（技術的）：

  • SageMaker EndpointやPipelineの設定変更を追跡して、デプロイやMLパイプライン実行時の構成逸脱を検知
  • BedrockフローやAgentCoreのランタイム／評価設定を監査し、モデル推論パイプラインやエージェント評価のコンプライアンスを維持
  • Config Aggregatorとルールを組み合わせて、複数アカウントにまたがるML資産の準拠性レポートを作成

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドガバナンス/コンプライアンス担当、セキュリティチーム、MLエンジニア、SRE
  • 利用シーン: SageMakerのエンドポイント/パイプラインやBedrock関連のフロー・エージェント設定の変更監視／監査
  • 運用効果: モデルデプロイや推論パイプラインの構成逸脱を早期検知でき、コンプライアンス違反や運用障害のリスクを低減
  • マルチアカウント運用: Config Aggregatorと組み合わせることで複数アカウント・複数リージョン横断の統合監視・レポートが可能
  • 自動修復: Config RulesとRemediationを利用すれば、特定の設定逸脱に対する自動修復ワークフローを構築可能

技術的な注意点 ​

  • IAM権限: Configの記録やルール作成にはconfig:PutConfigurationRecorder、config:PutDeliveryChannel、config:PutConfigRule、config:DeliverConfigSnapshot、config:BatchGetResourceConfigなどの権限が必要です。Aggregatorsやクロスアカウント操作には追加のIAM/STS許可設定が必要です
  • リージョン制限: 新規リソースは各サービスが提供されているリージョンでのみ監視可能です。BedrockやBedrock AgentCoreはリージョン対応が限定的な場合があるため事前に確認してください
  • コスト: AWS Configは記録アイテム数・スナップショット・ルール評価／集約などに基づく課金があります。新たにリソースを記録するとコストが増加する可能性があるため、影響を見積もってください（料金ページ参照）
  • レコーダー設定: レコーダーが「すべてのリソースタイプ」を記録する設定なら自動で追跡されますが、個別指定の場合は明示的に追加が必要です
  • Config Rules/Remediation: 新リソースを対象にするルールや自動修復を作成する際は、対応するリソースプロパティと関連APIの挙動を確認してください
  • 互換性: Conformance Packsや既存の自動評価ロジックを更新して新しいリソースタイプを含める必要があります
  • 遅延・データ保持: 記録のタイミングやConfigのデータ反映に短い遅延が発生することがあります。長期保持ポリシーはConfigの設定に依存します

参考情報 ​

[ECS] Amazon ECS Managed Instances now supports AWS Trainium and AWS Inferentia ​

概要 ​

Amazon ECS Managed InstancesがAWSのAIアクセラレータ（AWS Trainium / AWS Inferentia）をサポートしました。これにより、管理されたコンピュートでトレーニング・推論向けのTrainium/Inferentiaインスタンスを簡単に利用できるようになります。

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

ECS Managed Instances（フルマネージドなコンピュートオプション）でInferentia2、Trainium1、Trainium2のインスタンスタイプが選択可能になりました。利用手順は、ECSクラスターでManaged Instancesのcapacity providerを作成し、対象のアクセラレータ型インスタンスを指定します。タスク定義のResourceRequirementセクションにNEURON_CORE=allを追加すると、ECSは指定インスタンスを起動し、インスタンスあたり1タスクを配置してアクセラレータの全リソースを当該コンテナに割り当てます。これにより、アクセラレータを専有して高いパフォーマンスを確保できます。Managed InstancesはAWSがインフラ運用を代行するため、インスタンスプロビジョニング・ライフサイクル管理の負担が軽減されます。利用開始はAWSコンソール、Amazon ECS MCP Server、またはIaCツールから可能です。料金は通常のAmazon EC2インスタンス費用に加え、Managed Instancesの管理料金が発生します。なお、推論・トレーニングワークロードではAWS Neuron SDK（フレームワーク向けのランタイム/ドライバ）を利用してモデルを最適化・実行する必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: Generative AIのトレーニング/推論をコンテナで実行する機械学習エンジニア、プラットフォーム/インフラ担当者
  • 利用シーン: 大規模なトレーニングジョブや低レイテンシの推論エンドポイントをコンテナで運用し、アクセラレータを専有して最大性能を引き出す場面
  • 運用効果: インフラ管理工数の削減（ECSがインスタンス管理を代行）とアクセラレータ専有配置による性能向上・予測可能なリソース割当でのコスト対効果向上

技術的な注意点 ​

  • IAM権限: capacity provider作成、クラスター更新、インスタンス管理などのECS/EC2関連権限が必要。タスク実行ロールやインスタンスプロファイルの設定も確認してください
  • リージョン制限: 記載なし。利用前に対象リージョンでInferentia/TrainiumインスタンスタイプとManaged Instancesのサポート状況を確認してください
  • コスト: EC2（Inferentia/Trainium）料金に加え、ECS Managed Instancesの管理料金が発生します。アクセラレータ付きインスタンスは高価なため、専有配置のコスト影響を評価してください
  • ランタイム/SDK: コンテナイメージ内でAWS Neuronランタイム/SDK（および対応するフレームワーク向けのパッケージ）を正しくインストール・ビルドする必要があります
  • タスク定義設定: ResourceRequirementにNEURON_CORE=allを追加し、インスタンスあたり1タスク配置となる点を考慮してタスクリソース設計を行ってください
  • 配置制約: Managed Instancesは指定インスタンスに対して1タスクを割付けるため、多数の小タスクを同一アクセラレータに詰める運用には向きません
  • 監視/デバッグ: Neuronデバイスのメトリクスやドライバログを収集できるようCloudWatchなどの監視設定を整備してください
  • 互換性: 使用するフレームワーク（PyTorch/XLAなど）やNeuralネットワーク最適化フローがTrainium/Inferentiaと互換であることを確認してください

参考情報 ​

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

Copyright © 2026