AWS What's New Digest

Appearance

2026年10月20日 ​

[Bedrock] Structured outputs for Claude models available on Amazon Bedrock ​

概要 ​

Amazon BedrockがAnthropicのClaudeモデル全種で「構造化出力（schema-compliant JSON）」をサポートしました。bedrock-runtime（boto3/API）とbedrock-mantle（Messages API）の両方で利用でき、定義したスキーマに準拠したJSONレスポンスを直接受け取れます。

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

今回のアップデートにより、Claude系モデル（Anthropic Claude）の出力をあらかじめ定義したJSONスキーマに従って生成させることが可能になりました。bedrock-runtimeエンドポイント経由（boto3など）でも、bedrock-mantleのMessages API経由でも同様にスキーマ準拠のレスポンスを受け取れます。これにより、カスタムパーシングや出力の正規化／再試行・後処理の負荷を大幅に低減でき、抽出タスクやデータ正規化をより確実に自動化できます。ユースケースとしては、決算報告やコンプライアンス文書からの必須フィールド抽出、臨床ノートのEHRへの構造化入力、製品カタログの正規化・検証、契約書からの主要条項/当事者/義務の抽出、サポートチケットのインテント／感情／エンティティに基づくルーティングなどが挙げられます。出力は定義したスキーマに合致するJSON形式で返るため、アプリケーション側のデータモデルに直接マップしやすく、受信側でのフィールド検証やバリデーションが容易になります。利用開始方法の概略は、呼び出し時に期待するフィールド・型・必須性を定義するスキーマ情報をリクエストに含め、返却されたJSONをそのまま利用またはバリデーションする流れです。詳細な実装例やリージョン対応状況はAmazon Bedrockの公式ドキュメントおよびリージョナル可用性ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データエンジニア、アプリケーション開発者、SRE/運用チーム
  • 利用シーン: 文書からのフィールド抽出、医療記録の構造化、製品データの正規化、契約解析、サポートチケットの自動振り分けなど、スキーマ準拠のデータ化を要するワークフロー
  • 運用効果: パーシングエラーやポストプロセッシング工数の削減、データ整合性の向上、下流システムへの直接連携が容易になることで処理の自動化と信頼性が向上

技術的な注意点 ​

  • IAM権限: Bedrockの呼び出しには適切なIAM権限（例: bedrock:InvokeModel などのモデル実行権限）が必要です。実運用では最小権限のロールを設定してください。
  • リージョン制限: claudeモデルが提供されているリージョンで利用可能です。利用前に対象リージョンの提供状況を公式のリージョナル可用性ページで確認してください。
  • コスト: 生成されたレスポンスは通常のモデル推論（インファレンス）に該当し、リクエスト数・出力トークン数に基づく課金が発生します。スキーマ指定により出力サイズが増える可能性があるためコスト影響を評価してください。
  • モデル互換性/制限: 本機能はAnthropic Claude系の各モデルで利用可能とされていますが、モデルごとに精度や最大トークン数・出力の厳密性に差が出る場合があります。スキーマに対するバリデーションはアプリ側でも行うことを推奨します。
  • エラーハンドリング: まれにスキーマ不整合や部分的な欠落が生じる可能性があるため、受信側で再試行ポリシー、スキーマ検証、例外処理を実装してください。
  • データ保護/コンプライアンス: 医療情報（PHI）や機密情報を扱う場合は、適切なデータ保護対策と法規制（HIPAA等）への対応状況を確認してください。

参考情報 ​

[Clean Rooms] AWS Clean Rooms now supports Databricks as a data source ​

概要 ​

AWS Clean RoomsがDatabricksをネイティブなデータソースとしてサポートしました。Delta Sharingで共有されたDatabricksのテーブルをコラボレーション内で直接クエリでき、S3へのエクスポートやデータ複製が不要になります。

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

今回の拡張により、コラボレーション参加者はDatabricksのワークスペース、スキーマ、テーブル情報とDelta Sharingのshareを指定して、Databricks上のテーブルをAWS Clean Roomsに登録できます。登録されたテーブルは、他のサポート済みデータソース（AWS Glue、Snowflake、Amazon Athena）と同様にコラボレーションで利用可能になり、基データを移動・複製せずに承認された分析を実行できます。従来はDatabricksのデータを使うにはS3へエクスポート／複製してテーブルを用意する必要があり、データパイプラインの追加やガバナンス対象データの複製が発生していました。本機能によりその手間と追加のデータコピーを削減できます。ユースケースの例としては、Databricksで顧客データを管理する小売企業が、メディアパートナーとキャンペーン計測をAWS Clean Rooms上で共同実行しつつ、元データを晒したり移動したりすることなく分析を行う、といったシナリオが想定されます。詳細な利用可能リージョンやコラボレーション方法については公式ドキュメントとリージョン一覧を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Databricks上にデータを持つデータチーム、マーケティング/アナリティクス担当、パートナーと安全に共同分析したい企業
  • 利用シーン: Databricksの顧客・行動データを用いた広告効果測定、アトリビューション分析、外部パートナーとの集計分析（データ移動なしでのクエリ実行）
  • 運用効果: S3へのエクスポートや複製パイプラインの削減により運用負荷とストレージコストが低減。データガバナンス対象が一本化され、コラボレーションの導入が迅速化される
  • セキュリティ/ガバナンス影響: 元データを直接渡さずに共同分析が可能なため、データ露出リスクが低減。ただし共有するメタデータやクエリ結果の制限は設計次第であり、ガバナンスルールの見直しが必要になる場合がある

技術的な注意点 ​

  • Delta Sharing: Databricks側でDelta Sharing（share）の設定が必要です。Clean RoomsはDelta Sharingで公開されたテーブルを参照します。
  • 接続情報: DatabricksのワークスペースURL、スキーマ名、テーブル名、およびDelta Sharingのshare情報を提供する必要があります。shareエンドポイントがAWS側から到達可能であることを確認してください。
  • IAM権限: AWS Clean Roomsと関連するリソース（登録・コラボレーションの作成やクエリ実行）に必要なIAM権限を付与する必要があります。Databricks側のアクセス制御も適切に設定してください。
  • リージョン制限: AWS Clean Rooms自体の提供リージョンに依存します。利用を検討するリージョンでClean Roomsがサポートされているか公式のリージョン一覧で確認してください。
  • コスト: Databricksへのクエリ実行コスト、AWS Clean Roomsの利用料、関連するデータ転送（ネットワーク）やS3ストレージ（従来の複製があった場合）などのコスト構造を見直してください。S3への恒久的な複製が不要になることでストレージコストは下がる可能性がありますが、クエリ実行時の処理コストやデータ転送費用が発生します。
  • その他の注意: データ共有はDelta Sharingの仕様に基づきます。分析で返される結果に関してはAWS Clean Rooms側のプライバシー制御（集計しきい値、クエリ制限など）とDatabricks側の共有設定の両方を考慮して設計してください。必要に応じてネットワーク（VPC/プライベートエンドポイント）やファイアウォール設定も確認してください。

参考情報 ​

[Iam Identity Center] AWS IAM Identity Center simplifies identity source changes from Active Directory ​

概要 ​

AWS IAM Identity Center（旧AWS SSO）は、アイデンティティソースをActive Directoryから外部IdP（例：Okta、Microsoft Entra ID）やIdentity Centerディレクトリに切り替えても、既存のユーザー・グループ・割当（permission sets・アプリケーション割当等）を保持するようになりました。以前必要だった再作成作業が不要になります。

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

主な変更点は、アイデンティティソースをActive Directoryから別のソースへ変更する際に、IAM Identity Center側の既存のアイデンティティストア（ユーザー、グループ、グループメンバーシップ、permission set割当、アプリケーション割当）を残したままにできる点です。既存のユーザー／グループは同じID（内部ID）を保持するため、これらのIDを参照するポリシーや設定は引き続き有効です。新しいアイデンティティソースは通常どおり設定（外部IdPのSAML/OIDC設定やIdentity Centerディレクトリの構成）しておく必要があります。変更後は、ワークフォースはdual-stack（IPv4/IPv6対応）のAWSアクセスポータルURLを経由してサインインします。Active Directoryへ戻す（逆方向の切り替え）場合の動作は従来どおりです。本機能はOrganizations配下のIAM Identity Center（組織インスタンス）で利用可能で、IAM Identity Center提供リージョンすべてで利用できます。追加料金は発生しません。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド／ID管理者、セキュリティチーム、SRE、IT運用チーム
  • 利用シーン: Active DirectoryからOktaやMicrosoft Entra IDなどの外部IdPへ移行するマイグレーション、M&Aや組織再編でのIDプロバイダ統合、オンプレAD依存からクラウドIdPへ切り替えるケース
  • 運用効果: ユーザーやグループの再作成作業を省略できるため移行工数削減・ヒューマンエラー低減・サービス停止時間の短縮が期待できる
  • セキュリティ効果: IDの内部IDを保持するため、既存のアクセス制御やログ、監査設定が継続して利用可能で、アクセス継続性が担保される

技術的な注意点 ​

  • IAM権限: アイデンティティソース変更を行うにはIdentity Center（旧SSO）を管理できる権限が必要です。コンソール/CLI操作を行うユーザーの権限を事前に確認してください。
  • リージョン制限: Organizationsのインスタンス（組織インスタンス）で利用可能。IAM Identity Centerが提供されているリージョンすべてで本機能が利用可能です。
  • コスト: IAM Identity Center自体に追加料金は発生しません（本機能も追加料金なし）。ただし外部IdPやプロビジョニングサービスには別途料金が発生する場合があります。
  • ユーザー同期/認証: 切り替え後の認証は新しいIdPに委ねられるため、新しいIdP側にユーザーが存在し、ID属性（例：NameID、メールアドレス等）のマッピングが一致している必要があります。必要に応じてSCIM等によるプロビジョニング設定を検討してください。
  • ポリシー互換性: ユーザーID／グループID／アイデンティティストアIDを参照するポリシーや外部連携は、内部IDが保持されるため基本的に引き続き機能します。ただしサインイン属性に依存するカスタム認証フローや外部システム側のID参照は確認が必要です。
  • 切り戻し: 外部IdP等からActive Directoryへ戻す操作は従来どおり動作しますが、切り戻し時の認証・プロビジョニング状況は事前に検証してください。
  • サインインURL: 切り替え後のアクセスはdual-stack対応のAWSアクセスポータルURLを使用します。ユーザーへ周知・ドキュメント更新を行ってください。
  • 検証推奨: 本番移行前にステージング環境でサインイン・アクセス確認を行い、認証成功・権限付与・監査ログなどを検証してください。

参考情報 ​

[Bedrock] Amazon Bedrock Guardrails now supports Standard tier for contextual grounding checks ​

概要 ​

Amazon Bedrock GuardrailsにContextual GroundingチェックのStandardティアが追加されました。従来のClassicより堅牢で、会話形式や推論を含む応答の『根拠（grounding）』をより柔軟かつ包括的に検証できます。

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

Standardティアは、モデル応答が参照ソースに基づいているか、ユーザーの問い合わせに関連しているかを検出・フィルタリングするContextual Groundingチェックを強化したものです。主な技術的特徴は以下の通りです。

  • 会話・推論対応: これまでのClassicティアが要約、言い換え、QA向けに厳格なグラウンディングを想定していたのに対し、Standardは会話形式のやり取りやソースを跨いだ推論を含む応答にも適用可能です。
  • 意味的同値性の評価向上: 同じ意味を持つ表現の言い回し違いをより一貫してスコアリングし、誤検知（false positive/negative）を低減します。
  • 言語サポート強化: Classicより広範な言語に対応し、コンテンツフィルタや禁止トピックのStandardティアに合わせた包括的な言語対応を提供します。
  • ティア選択可能: 各ガードレールはコンソールまたはAPI（ApplyGuardrail API）からClassic/Standardを選択できます。既存ガードレールは明示的に変更するまでClassicのままです。
  • 実行要件: Standardティアを利用するには、ガードレールがガードレールプロファイルを使ったクロスリージョン推論（cross-Region inference）を使用している必要があります。
  • 料金・可用性: 料金はClassicと同じです。Standardティアは次のリージョンで利用可能です: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Europe (Milan), Europe (Paris), Europe (Spain), Europe (Stockholm), Asia Pacific (Tokyo)。
  • API連携: ApplyGuardrail API経由で任意のファウンデーションモデルに対して設定可能なため、RAG（retrieval-augmented generation）やチャットボット等、幅広い生成AIアプリケーションに適用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: AIアプリケーション開発者、プロンプトエンジニア、SRE/運用チーム
  • 利用シーン: 会話型アシスタントやチャットボット、RAGベースのQA、推論を伴う出力の根拠チェック、要約・転載の正当性検証
  • 運用効果: ハルシネーションの検出精度向上による誤情報低減、複数言語や推論を含む応答への対応拡張、既存ワークフローへ段階的導入が可能（既存ガードレールは自動移行されないため選択的アップグレードが可能）

技術的な注意点 ​

  • IAM権限: ApplyGuardrail APIやガードレール設定の変更には適切なBedrock関連のIAM権限が必要です（コンソール/APIの権限を確認してください）。
  • リージョン制限: Standardティアは指定のリージョンでのみ利用可能（上記のリージョン一覧を参照）。利用不可リージョンではClassicが継続使用されます。
  • クロスリージョン推論要件: Standardを利用するにはガードレールプロファイルを用いたクロスリージョン推論が必須です。これによりレイテンシやリージョン間データ転送が発生する可能性があります。
  • コスト: ティア自体の料金差はありませんが、クロスリージョン推論に伴うデータ転送料やリージョン間呼び出しによる追加コスト、レイテンシ影響を評価してください。
  • 既存ガードレールの挙動: 既存のガードレールはユーザーが変更するまでClassicのままです。移行は個別に選択可能です。
  • コンプライアンス/データ所在: クロスリージョンでの検査を許容するかはデータ保護方針を確認してください（国・地域のデータ保管規制に注意）。

参考情報 ​

[General] AWS Partner Central launches Program Navigator, Case Study Generator, and streamlined specialization review ​

概要 ​

AWS Partner CentralにProgram NavigatorとCase Study Generatorが追加され、パートナーがAWS Specializationへの申請やケーススタディ作成・公開を一箇所で行えるようになりました。専門化申請のレビューが高速化され、Go-to-market用ケーススタディは軽量なポリシー確認で直接公開できるようになりました。

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

Program Navigatorは、Specializationプログラムの探索、要件・特典の確認、申請の作成と進捗追跡を一元化するUIワークフローを提供します。申請はガイド付きのステップバイステップで送信でき、審査プロセスは要件レベルでの詳細なフィードバックを提供するよう改善され、レビュー時間が短縮されています。Case Study Generatorはケーススタディ作成体験を再設計し、(1) AI支援で直接作成、(2) 既存の顧客サクセスストーリーURLからインポート、(3) 案件(opportunity)から自動入力、の3つの開始パスを提供します。Go-to-market目的のケーススタディは軽量なポリシー検証を経てAWSのドメインへ直接公開可能で、Specialization申請に紐づくケーススタディのみ従来のSpecializationレベルの詳細レビュー対象となります。非Specializationプログラムへの申請は既存の体験を継続して利用します。これらの機能はすべてのAWSパートナーがAWS Partner Centralの「Go to Market」→「Program Navigator」「Case Studies」から利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: AWSパートナー（ソリューションプロバイダー、コンサルティングパートナー、テクノロジーパートナー）
  • 利用シーンまたは効果: Specialization申請の簡素化と進捗管理、ケーススタディの迅速作成・公開によりマーケティング活動と認定取得のスピードが向上
  • 運用効果: 審査時間短縮と要件レベルのフィードバックにより申請・対応の反復が早くなり、承認までのサイクルが短縮される
  • ガバナンス/承認フロー: Go-to-marketケーススタディは軽量なポリシー検証で即時公開可能だが、Specializationに紐づくケーススタディは従来どおり深いレビューが必要
  • 作業負荷: Case Study Generatorの自動入力/インポート/AI支援によりケース作成工数が低減される

技術的な注意点 ​

  • IAM権限: AWS Partner Centralへのアクセス権およびパートナーポータル内の適切なユーザーロール（マーケティング/プログラム申請権限）が必要です。組織内のPartner Central管理者に権限付与を確認してください。
  • リージョン制限: Partner Centralはグローバルサービスとして提供されるためリージョン固有の制限は基本的にありませんが、組織の管理ポリシーやロール設定に依存します。
  • コスト: 本機能自体に追加のAWS利用料金は明示されていません。ただし、ケーススタディの制作や外部コンテンツ利用、マーケティング活動には別途費用が発生する可能性があります。
  • データ/コンプライアンス: AI支援やURLインポートを利用する際は顧客データや機密情報の取り扱いに注意し、必要な顧客同意や機密情報のマスキングを行ってください。
  • レビュー範囲: Go-to-market用ケーススタディは軽量なポリシー検証のみ（公開可否判断）で、Specialization申請に紐づくケーススタディはより詳細なSpecializationレベルの審査が適用されます。
  • 必要な準備物: Specialization申請ではプログラムごとの要件（技術検証、事例、認定、売上要件など）を満たすための証拠・ドキュメントを事前に用意しておくとスムーズです。
  • 既存ワークフローとの併用: 非Specializationプログラムは従来のPartner Centralの体験を継続して使用するため、両者の使い分けを運用に組み込んでください

参考情報 ​

[Bedrock] Amazon Bedrock Advanced Prompt Optimization now supports prompt shortening ​

概要 ​

Amazon BedrockのAdvanced Prompt Optimizationが「プロンプト短縮（prompt shortening）」に対応しました。プロンプトの長さを削減しつつ評価スコアを維持または改善するオプション設定で、トークンコストやレイテンシ改善につながります。

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

プロンプト短縮はオプション設定で、入力データセット内のプロンプトテンプレートごとに有効化できます。オプティマイザは指定した評価基準（ステアリング基準、LLM-as-a-judgeルブリック、カスタムLambda評価などを含む任意の評価方法）に基づいてプロンプトを最適化し、最終的に「元のプロンプトより短く、かつ評価スコアが同等以上」の場合のみ最適化プロンプトを返します。これにより、トークン単価に基づく入力コストやTime-to-first-token（初動トークンまでの遅延）を削減できます。最適化結果には圧縮比（例：圧縮比0.7は30%のトークン削減を意味）と元・最適化後のトークン数が出力ファイルとコンソール結果ページに表示されます。利用開始は、入力データセットのプロンプトテンプレートでプロンプト短縮を有効にし、通常どおり最適化ジョブを作成するだけです。なお、結果は常に元のプロンプトより短くかつスコアが維持されることを保証するため、短縮が不利になるケースでは元のプロンプトが返されます。

影響範囲・利用シーン ​

  • 対象ユーザー: プロンプトエンジニア、MLエンジニア、アプリケーション開発者、SRE/運用チーム
  • 利用シーン: レイテンシやトークンコストが重要な生成系API（大量バッチ推論、低レイテンシ対話アプリ、コスト最適化を行うプロダクション環境）のプロンプト改善
  • 運用効果: 入力トークン数の削減によるコスト低減とTime-to-first-token短縮、評価スコアを保持したまま実運用での効率向上
  • 導入効果の注意点: 最適化は評価基準に依存するため、評価ルーブリックやテストケースを慎重に設計する必要がある

技術的な注意点 ​

  • IAM権限: Bedrockの最適化ジョブ作成、S3アクセス、必要ならLambda評価を呼び出す権限などを事前に確認・付与してください
  • リージョン制限: Advanced Prompt Optimizationが利用可能なAWSリージョンで利用可能です。お使いのリージョンでの提供状況を確認してください
  • コスト: 入力トークン削減で推論コストは下がる可能性がありますが、Advanced Prompt Optimizationジョブの実行に対する料金が発生する場合があります。詳細は価格ページを確認してください
  • 評価互換性: ステアリング基準、LLM-as-a-judgeルブリック、カスタムLambda評価など、すべての評価方法と互換
  • 出力情報: 圧縮比および元/最適化後のトークン数が出力ファイルとコンソールに表示されます
  • 安全性・品質: 短縮により意図やコンテキストが変わる可能性があるため、生成品質とセーフガードを実運用前に十分に検証してください

参考情報 ​

[General] AWS Transform for migrations expands support for existing landing zones ​

概要 ​

AWS Transform for migrations が既存のランディングゾーン環境（AWS Control Tower や AWS Organizations ベースのランディングゾーン）をより広くサポートし、既存環境上にランディングゾーンを拡張して移行準備を短縮できるようになりました。加えて、IaC のみを出力する「IaC-only モード」が追加され、CDK/Terraform/LZA 形式で移行向けのインフラ定義を生成できます。

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

主な新機能と仕様:

  • 既存ランディングゾーンのサポート拡大: AWS Control Tower ランディングゾーンや、AWS Organizations を使って構築されたランディングゾーンを認識し、現在のアカウント構成とベストプラクティスのギャップ分析（foundation gap analysis）を実行した上で、既存ターゲットアカウントへランディングゾーンを拡張します。これにより、ゼロから作り直すことなく移行を早められます。
  • IaC-only モード: 組織の解析と推奨事項の生成を行い、AWS CDK、Terraform、Landing Zone Accelerator（LZA）形式の IaC を出力します。出力物は自前のデプロイパイプラインで使用可能で、Transform が管理アカウントへ直接アクセスする必要がないワークフローを実現します。
  • 接続オプション: 直接管理アカウントアクセスの代替として、委任管理者（delegated administrator, DA）アカウント経由で接続可能です。
  • ランディングゾーンエージェントの自動化範囲: 基盤セットアップ、組織単位（OU）とアカウント構成、サービスコントロールポリシー（SCP）、および移行計画や移行ウェーブに沿ったワークロードアカウントの自動作成・配置をサポートします。直接デプロイするか、IaC を生成して自社パイプラインで適用するかを選択できます。
  • リージョン対応: 新機能は、AWS Transform for migrations がサポートする全てのターゲット AWS リージョンで利用可能です（詳細は User Guide を参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド移行を行うクラウドエンジニア、クラウドアーキテクト、SRE/運用チーム
  • 利用シーン: 既存の Control Tower/Organizations ベース環境を再利用しつつ移行先ランディングゾーンを短期間で整備したい場合、またはセキュリティ制約で管理アカウントへ直接アクセスを許可できない組織で IaC を生成して自社パイプラインへ統合したい場合
  • 運用効果: ランディングゾーン設計と基盤設定の自動化により、移行準備期間を短縮し、標準化された OU/アカウント構成と SCP によるガバナンスを早期に適用可能

技術的な注意点 ​

  • IAM権限: 直接デプロイする場合は Transform に管理アカウント（または適切な権限を持つ委任管理者）へのアクセス権が必要。IaC-only モードを選ぶ場合でも、組織情報の読み取り権限など最低限の権限が求められる場合がある。出力した IaC を適用する際は実行ユーザー／CI の権限を整備してください。
  • リージョン制限: 新機能は AWS Transform がサポートするターゲットリージョンで利用可能です。利用可否・対応リージョンは AWS Transform User Guide で確認してください。
  • コスト: Transform 自体の利用条件に加え、ランディングゾーン構築で作成される AWS リソース（アカウント、ログ集約、ネットワーク等）に対する通常の課金が発生します。IaC を自社で適用する場合はデプロイ実行によるリソースコストを見積もってください。
  • IaCフォーマット: 出力形式は AWS CDK、Terraform、Landing Zone Accelerator（LZA）。生成されたコードは組織固有のポリシーや命名規則に合わせてレビュー・修正してから適用することを推奨します。
  • デプロイモデル: エージェントによる自動デプロイと IaC-only（手動でのパイプライン適用）を選択可能。自動デプロイは素早く反映できる反面、組織の運用ポリシーに応じた権限付与が必要です。
  • レビューとガバナンス: 自動生成される SCP や OU 設計は環境に大きく影響するため、本番適用前にセキュリティ・コンプライアンス担当者による検証を行ってください。

参考情報 ​

[ElastiCache] Amazon ElastiCache Serverless for Valkey now supports online migration with zero downtime ​

概要 ​

Amazon ElastiCache Serverless for Valkeyがセルフ管理のValkey／Redis OSS（Amazon EC2上）からゼロダウンタイムでのオンライン移行をサポートしました。アプリケーションの読み書きを止めずに、ElastiCacheが継続的にデータ同期とカットオーバーを管理します。

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

オンライン移行は「準備（prepare）」「データ同期開始（start sync）」「カットオーバー完了（cutover）」の3段階で実行されます。準備フェーズでElastiCacheが移行用のエンドポイントを発行し、同期を開始するとソース（セルフ管理のValkeyまたはRedis OSS）から継続的にデータを複製します。書き込みの切替は手動カットオーバーか、データが同期された時点での自動カットオーバーを選べます。移行中にクライアントへ返るエラーはゼロ（ElastiCache SLAで測定する可用性定義に準拠）とされ、サードパーティのレプリケーションツールは不要です。接続はTLSによる通信暗号化と認証を使用し、認証情報はAWS Secrets Managerから取得するため既存のセキュリティコントロールを活かせます。サポートされるソースはクラスターモードで稼働するセルフ管理キャッシュ（Redis OSS 4.0〜7.2、Valkey 7.2〜8.1）で、ターゲットはValkey 9.0へ直接移行可能です。移行の各ステップはElastiCacheコンソールのEventsタブに記録され、失敗理由も確認できます。移行に必要なElastiCache側の移行ノード利用はアカウント単位で最初の180日間は無料（最初に「準備」を実行した日時からカウント）で、その後は移行がアクティブな期間に対してノード時間単位で課金されます。ElastiCache Serverlessキャッシュ自体のストレージ・ECPU料金は移行の無料期間中も通常通り課金されます。サービスは全ての商用リージョン、中国リージョン、AWS GovCloud（US）で利用可能です。開始手順は、空のElastiCache Serverlessキャッシュを作成（または選択）してからコンソールまたはAWS CLIで移行を開始します。

影響範囲・利用シーン ​

  • 対象ユーザー: Redis/Valkeyをセルフ管理している開発者、SRE、クラウド移行チーム
  • 利用シーン: オンプレやEC2上のRedis/Valkeyをダウンタイム無しでElastiCache Serverless for Valkeyへ移行したい場合（アプリを停止できないリアルタイムサービスやピーク時の環境）
  • 運用効果: アプリケーション停止なしでの移行によりリリース窓口・メンテナンス工数が削減され、移行リスク（クライアントエラーや可用性低下）を抑えられる
  • コスト影響: 最初の180日間は移行ノード利用が無料だが、Serverlessキャッシュのストレージ/ECPUは常に課金されるため移行期間中の総コストを評価する必要あり
  • セキュリティ影響: TLSとSecrets Managerを用いた認証により既存のセキュリティポリシーを維持できるが、ソースへのネットワークアクセスとSecretの権限制御が必要

技術的な注意点 ​

  • IAM権限: ElastiCacheの移行操作、対象キャッシュの作成/変更、Secrets Managerからのシークレット参照、必要なVPC/SG操作権限（Network関連）が必要です
  • リージョン制限: 公表では全商用リージョン、中国リージョン、GovCloud（US）で利用可能とされていますが、利用前に対象リージョンのコンソールで確認してください
  • コスト: 移行ノードはアカウント単位で最初の180日間無料（最初の準備実行からカウント）。その後は移行ノードのノード時間課金。ElastiCache Serverlessのストレージ/ECPUは常に課金されます。さらに、ソースとAWS間のデータ転送（クロスAZやインターネット経由など）で追加のネットワーク費用が発生する可能性があります
  • 互換性: サポートされるソースはクラスターモードのRedis OSS 4.0〜7.2およびValkey 7.2〜8.1。ターゲットはValkey 9.0へ直接移行可能。互換性の詳細（コマンドやデータ型の差異）は事前確認が必要です
  • ネットワーク/接続: ソースRedisがTLSでの接続をサポートし、ElastiCache側から接続可能なネットワーク経路（VPCピアリング、Transit Gateway、適切なセキュリティグループ等）が必要です
  • 運用上の注意: 移行先は空のElastiCache Serverlessキャッシュである必要があります。移行イベントはEventsタブで追跡でき、失敗理由の確認とリトライが可能です
  • 切替挙動: 書き込み切替は手動または自動（同期完了時）を選択可能。自動切替を使う場合は同期状態の確認ポリシーを事前に設計してください

参考情報 ​

[Connect] Amazon Connect Customer Global Resiliency now provides business users visibility into resiliency readiness across linked Regions ​

概要 ​

Amazon Connect Customer Global Resiliencyの管理コンソールに「Global Resiliency」ページが追加され、管理者が複数リージョンにまたがる障害対策（Region切替）準備状況を一元的に確認・修正できるようになりました。準備状況の概要と、ネイティブにレプリケートされるリソース毎の同期状態（同期済み／保留／要対応）を表示します。

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

管理者向け管理サイトにGlobal Resiliencyページが追加され、以下の機能を提供します。

  • 全体のReadyステータス表示: インスタンスがリージョン切替に対してどの程度準備できているかを一目で確認できます。
  • リソース単位の同期状況表示: Global Resiliencyがネイティブにレプリケートするリソース（例: ユーザー、電話番号、トラフィック配布グループ、ルーティング/キュー/フロー設定、営業時間など）について「in sync（同期済み）」「pending（同期保留）」「action required（要対応）」の状態を示します。
  • コンソール上での修復アクション: 例えば電話番号やユーザーがトラフィック配布グループに紐づいていない等の問題が検出された場合、その場で該当リソースを紐付ける操作が可能で、切替準備を進められます。
  • リージョン対応: Amazon Connect Customer Global ResiliencyがサポートするすべてのAWSリージョンで利用可能です。 運用上は、定期的にこのページでレジリエンシー状況を確認し、必要に応じてリソースの割当てや再同期を行うことで、実際のリージョン切替時に発生するトラブルを低減できます。ページの表示はOperational/管理APIやバックグラウンドのレプリケーション状態に基づくため、最終的には整合性が取れるまで遅延（イベントュアルコンシステンシー）が生じることがあります。

影響範囲・利用シーン ​

  • 対象ユーザー: Amazon Connectの管理者、SRE、クラウド/コンタクトセンター運用チーム
  • 利用シーン: リージョン障害時のフェイルオーバー準備確認、事前のDR（ディザスタリカバリ）検証、運用手順のチェックリストとしての利用
  • 運用効果: リソースの未紐付けや同期遅延を事前に発見・修正できるため、実際のリージョン切替時のダウンタイムや設定漏れを減らせる
  • 導入効果: 管理コンソールでの一元確認により、複数リージョンに跨る手作業やスクリプトの負担を軽減できる

技術的な注意点 ​

  • IAM権限: 管理コンソールで状態確認・修正を行うにはAmazon Connectの管理者権限、または該当API（リソースの読み取り・更新）を許可するIAMポリシーが必要です。CloudTrailでAPI呼び出しが記録されます。
  • リージョン制限: この機能は「Amazon Connect Customer Global Resiliency」をサポートするリージョンで利用可能です。未サポートのリージョンでは表示されませんので、対象リージョンの対応状況はコンソールまたはドキュメントで確認してください。
  • コスト: 機能自体の表示・操作に対する追加料金は通常発生しませんが、クロスリージョンのレプリケーションに伴うデータ転送費用や、複製先で保持するリソース（電話番号の割当・通話料金等）に関連する料金が発生する可能性があります。詳細は料金ページを確認してください。
  • 同期特性: レプリケーションは最終的整合性を前提としているため、状態表示と実際のリソース同期にタイムラグが発生する場合があります。重大なフェイルオーバー前には実際に切替テストを行って確認してください。
  • 運用手順: 定期的なレジリエンシーチェック、検出された「要対応」項目の即時修正、定期的なリージョン切替演習（DRテスト）を推奨します。

参考情報 ​

[CloudWatch] Amazon CloudWatch Omni is now available in additional AWS Regions ​

概要 ​

Amazon CloudWatch Omni（AI対応の統合オブザーバビリティ体験）が8つの追加リージョンで利用可能になりました。これにより、マルチアカウント／マルチリージョン／マルチクラウド環境の可観測性をCloudWatch上で統合して扱えます。

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

CloudWatch OmniはOpenTelemetryと互換性を持ち、CloudWatchのスケールと信頼性を組み合わせた観測プラットフォームです。ユーザーは中央アカウントに“スペース”を作成して複数のAWSアカウント、リージョン、さらにAzureやGCPといった他クラウドからのテレメトリを集約できます。自動サービス検出、依存関係マッピング、ゴールデンメトリクスの抽出を行い、チャット操作・ポイント＆クリック・Agent Toolkit経由のAPI呼び出しでテレメトリに対話できます。ルートコーズ分析はAWS DevOps Agentで強化され、エージェント向けにはLangGraph、CrewAI、OpenAI Agents SDK、Vercel AI SDK、Strandsなどのフレームワークに対する評価駆動ワークフロー（エージェント観測体験）が用意されています。利用形態は（1）単独のWebコンソール（SSO対応）と、（2）VS Code、Cursor、Kiro向けのOmni拡張を使ったローカルIDE拡張の双方があり、拡張機能は無料で利用可能です。今回の拡張で新たに利用可能になったリージョンは、Canada (Central)、Asia Pacific (Mumbai)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Europe (Frankfurt)、Europe (London)、South America (São Paulo)で、既存のUS East (N. Virginia)、US West (Oregon)、Europe (Ireland)と合わせて利用できます。開始手順はCloudWatchコンソールでOmniスペースを作成し、SSOを設定してサインインするだけです。価格は専用のCloudWatch Omni料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE／プラットフォームエンジニア、アプリケーション開発者、オブザーバビリティチーム、マルチクラウド運用チーム
  • 利用シーン: 複数アカウントや複数リージョン、他クラウドにまたがるログ・メトリクス・トレースを一元観測しての障害調査とパフォーマンス解析
  • 運用効果: 依存関係の自動マッピングとゴールデンメトリクス抽出によりMTTR（平均復旧時間）の短縮、IDE統合で開発者のデバッグ効率向上
  • エージェント開発者向け効果: VS Code等の拡張でローカル開発時にテレメトリを即時確認でき、エージェント評価ワークフローによりフレームワーク互換検証が容易に
  • コンプライアンス／レイテンシ効果: 対応リージョン拡大によりデータレジデンシー要件や低レイテンシ観測が必要なワークロードでの利用がしやすくなる

技術的な注意点 ​

  • IAM権限: スペース作成・テレメトリ収集・クロスアカウント参照にはCloudWatch関連権限に加え、Organizations/STSを使ったクロスアカウントアクセス権限やSSO設定権限が必要です。事前に最小権限ポリシーを確認してください。
  • リージョン制限: 追加で有効化されたリージョンは Canada (Central)、Mumbai、Singapore、Sydney、Tokyo、Frankfurt、London、São Paulo です。利用前に該当リージョンでサービスが有効化されていることを確認してください（すべてのリージョンで即時提供されない場合があります）。
  • コスト: Omni自体の利用は別途課金（データ取り込み、保存、分析機能など）があります。IDE拡張は無料ですが、テレメトリの送信・保存はCloudWatch Omniの料金体系に従います。料金ページで見積りを行ってください。
  • 対応エージェント／SDK: OpenTelemetry互換の収集経路をサポート。Agent Toolkit for AWSおよびAWS DevOps Agentと統合してルートコーズ分析やダイナミックビューを構築できます。特定フレームワーク（LangGraph等）向けの評価ワークフローが用意されています。
  • SSO/IdP: Webコンソール利用時はSSO設定（SAMLやAWS SSO等）の構成が推奨されます。IdP側の設定や属性マッピングを事前に計画してください。
  • データレジデンシー／コンプライアンス: マルチクラウドのテレメトリ収集を行うため、送信先リージョンや保存場所のデータ保護要件を確認し、必要ならデータ転送ポリシーや暗号化設定を調整してください。
  • 前提構成: 既存のCloudWatch Logs/Metric/Traceの設定、OpenTelemetryエージェントや収集パイプラインの準備があると移行・統合がスムーズです。

参考情報 ​

[Ec2 Auto Scaling] EC2 Image Builder now integrates with ASG for faster image builds ​

概要 ​

EC2 Image BuilderがAuto Scaling Group（ASG）内の既存の稼働中インスタンスをビルドに再利用できるようになり、インスタンス起動やブートストラップにかかる時間を省くことでイメージ作成を高速化します。設定はオプトインで、既存のパイプラインには影響しません。

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

新機能では、Image Builderのインフラストラクチャ設定にASGを指定できます。ビルド実行時に新規インスタンスを起動する代わりに、指定したASGから既に稼働中のインスタンスを選択し、ビルドコンポーネント（パッケージインストール、設定適用、カスタムスクリプト等）を適用してイメージ（例：AMI）を作成します。ASGはビルドに使用されたインスタンスを自動的に補充してプールを維持するため、次回のパイプライン実行時にも利用可能なインスタンスが確保されます。既存パイプラインでASGを設定していない場合は、従来どおり新規インスタンスの起動経路が使われ、動作は変わりません。本機能は全リージョンで利用可能で追加料金は発生しません。導入手順の概略：インフラ構成で対象ASG（ARNなど）を指定し、ASG内インスタンスがImage Builderのビルド要件（対応OS、SSMエージェント、適切なインスタンスプロファイルなど）を満たすことを確認します。

影響範囲・利用シーン ​

  • 対象ユーザー: イメージ作成を行う開発者、プラットフォームエンジニア、SRE/運用チーム
  • 利用シーンまたは効果: 定期的なAMI作成やパッチ適用パイプラインでのビルド時間短縮（インスタンス起動/ブート時間の削減）およびCI/CDパイプラインの高速化
  • 運用効果: ビルド待ち時間低減によりデプロイサイクルが短縮され、既存の実行中インスタンスを活用することで短時間のスパイク時にもスループットを維持しやすくなる

技術的な注意点 ​

  • IAM権限: Image Builderと関連する実行ロールに、ASGおよびEC2/SSM操作を参照/実行するための必要な権限（Auto ScalingのDescribe/Update系、EC2のDescribe/CreateImage系、SSM実行に必要な権限等）を付与することを確認してください
  • インスタンス要件: ASG内のインスタンスは対象OS/イメージビルドの要件（OSバージョン、SSMエージェントの稼働、十分なディスク容量、必要なランタイム等）を満たしている必要があります
  • ASG設定: ASGの最小/希望/最大キャパシティをビルド同時実行数に合わせて設計してください。ASGはビルドで使用されたインスタンスを補充しますが、補充中は一時的に利用可能インスタンスが減るため、同時ビルド数が多い場合は容量不足に注意が必要です
  • 競合と隔離: 稼働中インスタンスをビルドに使うため、アプリケーションプロセスやユーザートラフィックとビルド処理が競合する可能性があります。必要に応じて専用のASG（ビルド用インスタンスプール）を用意してください
  • コスト: 機能自体に追加料金はありませんが、ASGで常時稼働させるインスタンスの費用は発生します。従来のオンデマンド起動を減らせる場面もありますが、運用設計次第でコスト影響が変わります
  • リージョン制限: 全リージョンで利用可能と明記されていますが、利用前にターゲットリージョンでのサービスバージョンを確認してください
  • 既存パイプラインへの影響: 本機能はオプトインです。ASGを設定しないパイプラインは従来の起動フローのまま動作します
  • その他: ビルドのためにインスタンスに変更を加える（ソフトウェアインストールや設定変更など）ため、インスタンスの状態管理と監視（ログ、メトリクス）を適切に行ってください

参考情報 ​

[Govcloud Us] Amazon GuardDuty adds optional threat detection rules for Runtime Monitoring ​

概要 ​

Amazon GuardDutyがRuntime Monitoring向けの「オプション検出ルール」を追加しました。50以上のルールを任意で有効化でき、プロセス／ファイル／ネットワークの実行時挙動から環境に依存する不正を検出します。

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

主な内容は以下の通りです。GuardDutyのRuntime Monitoringに対して50以上のオプション検出ルール（Custom Detection Rules for Runtime Monitoring）が提供され、sudoersの改変や監査ログ無効化のように、ある環境では通常でも別の環境では侵害の兆候となるプロセス・ファイル・ネットワークの活動を検出できます。検出はAmazon EC2、Amazon EKS、Amazon ECS（EC2およびAWS Fargate両方）で動作し、13のfinding typeにマッピングされた検出を提供します。検出はMITRE ATT&CKの戦術（persistence、privilege escalation、execution、defense evasion、discovery、exfiltration、command and controlなど）に対応します。本リリースで追加された4つの新しいfinding typeは、CommandAndControl:Runtime/SuspiciousCommand、CredentialAccess:Runtime/SensitiveFileRead、Discovery:Runtime/SensitiveFileRead、Exfiltration:Runtime/SuspiciousCommandです。ルールはコンソールから有効化でき、運用前にdry-runモードで検出の有効性（誤検知率など）を評価できます。Custom Detection Rules for Runtime Monitoringは全てのAWS商用リージョンとAWS GovCloud（US）で利用可能です。また、新機能や検出の更新を受け取るためのAmazon GuardDuty SNSトピックへの購読が案内されています。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティチーム、SOC、クラウドSRE/運用チーム、インシデント対応担当者
  • 利用シーン: EC2/EKS/ECS（EC2およびFargate）上でのランタイム活動監視、プロセス・ファイル・ネットワークの不正検出、侵害の早期発見やフォレンジック調査のトリガー
  • 運用効果: MITRE ATT&CKマッピングに基づく優先度付けが可能になり、dry-runでルールを評価して誤検知を抑えつつ本番検出を導入できるため、誤検出による運用負荷を低減しつつ検出網を強化できる

技術的な注意点 ​

  • IAM権限: GuardDutyおよびCustom Detection Rulesの設定にはGuardDutyの管理権限（例: AmazonGuardDutyFullAccess または相応のカスタムIAMポリシー）が必要です。SNS購読やリージョン間操作には追加のIAM権限が必要になる場合があります。
  • リージョン制限: この機能は全てのAWS商用リージョンとAWS GovCloud (US)で利用可能とされていますが、特定リージョンでの反映状況はコンソールで確認してください。
  • コスト: ガードデューティ自体の料金体系（検出結果数、データ解析量など）に基づくため、ルール有効化により検出数・ログ解析量が増えると料金が増加する可能性があります。dry-run自体の料金扱いはGuardDutyのドキュメントで確認してください。
  • 設定／運用: dry-runモードでまず評価してから本番検出を有効化することを推奨します。初期は誤検知が発生しやすいためアラート閾値や通知フローを調整してください。
  • 対応リソース: Amazon EC2、Amazon EKS、Amazon ECS（EC2およびFargate）に対して適用されます。環境ごとのベースライン差分に注意してください。
  • アラート管理: 新しいfinding typeが追加されるためSIEM/SOCフローや自動対応（Lambda、EventBridge連携など）を更新する必要があります。
  • 互換性／前提: GuardDuty Runtime Monitoringが有効になっていることが前提です。ホスト側の追加エージェントや設定は不要なケースが多いですが、環境によってはログ設定や権限調整が必要になる場合があります。

参考情報 ​

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

Copyright © 2026