AWS What's New Digest

Appearance

2026年09月01日 ​

[Bedrock] Claude Fable 5.1, Anthropic's new frontier model is now available on AWS ​

概要 ​

Anthropicの最上位フロンティアモデル「Claude Fable 5.1」がAWSで一般提供開始されました。より高度な推論・判断力を持ち、コーディングや科学研究、エンタープライズワークフロー向けの長時間・高重要度タスクに適しています。

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

Claude Fable 5.1は、前バージョンFable 5からの改良で、最難関の推論タスクや曖昧な要求に対する判断力が向上し、自信のある誤答（確信を持った間違い）が減少しています。長時間にわたるセッションや複数アプリにまたがる作業を想定して設計されており、コードベース全体の機能実装・コードレビュー・パフォーマンス改善などをセッションを跨いで継続的に扱うことが可能です。モデルが行き詰まった場合は成功と誤報せずに「行き詰まった」と報告する挙動改善も含まれます。同一の基盤モデルで、サイバーセキュリティや生物学的能力を保持した「Claude Mythos 5.1」も存在しますが、これは限定アクセスで提供されます。AnthropicはFable 5.1を「Covered Model」に指定しており、追加のデータ保持ポリシー、セーフティレビュー、アクセス管理が適用されます。AWSとAnthropicの共同の仕組みとして、Enterprise Frontier Safeguards (EFS) により、対象顧客はCovered Modelsを自分たちが管理するクラウド環境内で利用できる等のガバナンスが提供されます。アクセス経路は主にAmazon BedrockとClaude Platform on AWSで、詳細はそれぞれのドキュメントとリージョン対応表で確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: AIを利用した高度な知識作業や長時間にわたるソフトウェア開発プロセスを自動化・補助したいソフトウェアエンジニア、研究者、エンタープライズITチーム
  • 利用シーン: 大規模コードベースの機能実装／レビュー、科学研究の長期的な解析ワークフロー、サイバー／バイオ分野の専門的調査（Mythosは限定アクセス）
  • 運用効果: モデルがより正確に判断し誤答が減ることでレビュー工数低減や意思決定支援の品質向上が期待できる。長時間セッション対応により作業の継続性が高まる
  • アクセス制約: Claude Mythos 5.1は限定提供のため、利用申請や事前審査が必要になる可能性がある
  • ガバナンス影響: Covered Model指定およびEFSにより、データ保持・アクセス制御・セーフティ要件を満たす企業向けの運用設計が必要になる

技術的な注意点 ​

  • IAM権限: BedrockやClaude Platformへアクセスするための適切なAWS IAM権限（Bedrock呼び出し権限や関連リソースの権限）を準備してください。EFS利用時は追加のアカウント設定／アクセス許可が必要になる場合があります
  • リージョン制限: すべてのAWSリージョンで即座に利用可能とは限りません。導入前にAmazon Bedrockのリージョン対応状況を確認してください
  • コスト: フロンティアモデルのため、APIコールあたりの料金や長時間セッションでの使用量が高くなる可能性があります。費用見積りと予算管理（使用量上限やモニタリング）を行ってください
  • データ保持・コンプライアンス: Fable 5.1はCovered Modelに指定されており、追加のデータ保持ルール・セーフティレビュー・アクセス制御ポリシーが適用されます。機密データや規制対象データを扱う場合はEFSや社内コンプライアンスと整合させてください
  • アクセス制限: Claude Mythos 5.1はサイバー・バイオの機能を保持していますが限定提供です。利用には申請・審査や追加契約が必要となる可能性があります
  • 運用上の挙動: 長時間・複雑タスクに強く、途中で行き詰まった際にその旨を明示する設計ですが、依然としてモデルの出力は検証が必要です。自動化ループに組み込む際は人間による監査やテストを継続してください

参考情報 ​

[CloudWatch] Amazon CloudWatch now supports warm-up periods for alarms ​

概要 ​

Amazon CloudWatchは、メトリクスアラームとログアラームに対してウォームアップ期間（warm-up period）を設定できるようになりました。アラーム作成直後のリソース起動時にメトリクスが未到着で発生する不要な通知（ノイズ）を抑制できます。

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

新機能では、アラーム作成後に一定時間評価を遅延させるウォームアップ期間を設定できます。主なポイントは以下の通りです。

  • 対象: メトリクスアラームおよびログアラームに適用。
  • 設定方法: アラーム作成・更新時に WarmUpConfiguration パラメータで指定。
  • 期間: 1 分〜2,880 分（最大2日）を指定可能。
  • 評価開始の挙動: デフォルトでは、アラームの評価ウィンドウ（evaluation window）を埋めるのに十分なデータが揃った時点でウォームアップを早期終了して評価を開始します。オプションで「指定したフル期間が経過するまで評価を開始しない」設定にして、強制的に全期間待機させることも可能です。
  • 目的: 新しくデプロイしたアプリやサービスがメトリクス送信を開始するまでの“空白期間”における誤検知（missing data による状態遷移やアクション実行）を防ぐ。
  • 既存動作との違い: これまではアラーム作成直後に CloudWatch が即座に評価を行い、'treat missing data' の設定に基づいて動作していました。ウォームアップ設定により、これを回避できます。
  • 利用方法: AWS マネコン、AWS CLI、SDK から設定可能（詳細はドキュメント参照）。
  • 料金・リージョン: CloudWatch が提供されているすべてのリージョンで利用可能で、追加料金はなく標準の CloudWatch アラーム料金のみが適用されます。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE/運用チーム、開発チーム、CI/CD パイプラインでリソースとアラームを同時に作成するチーム
  • 利用シーン: 新規デプロイ直後のマイクロサービスやアプリケーションがメトリクス送信を開始するまでの監視を一時的に抑制する場面（CI/CD でアラームとリソースを同時作成する等）
  • 運用効果: スタートアップ時の誤アラートを削減し、オンコール通知のノイズを減らすことで不必要なページングや対応コストを低減できる

技術的な注意点 ​

  • IAM権限: アラーム作成/更新には cloudwatch:PutMetricAlarm などアラーム操作に必要な権限が必要です（参照権限は cloudwatch:DescribeAlarms 等）。
  • WarmUpConfiguration: アラーム作成・更新時に WarmUpConfiguration パラメータで設定します（期間は 1〜2,880 分）。
  • デフォルト動作: デフォルトでは評価ウィンドウに必要なデータが揃うとウォームアップを早期終了して評価を開始します。フル期間待機するオプションを指定することで、指定時間を完全に待ってから評価を始めることも可能です。
  • 適用範囲: メトリクスアラームとログアラームに適用されます。既存の 'treat missing data' の動作との組み合わせを設計時に確認してください。
  • リージョン制限: CloudWatch を提供しているすべてのリージョンで利用可能です（ただし、最新のリージョンやサービス導入状況はドキュメントで確認してください）。
  • コスト: ウォームアップ期間自体に追加料金は発生しません。アラームに関する通常の CloudWatch アラーム料金のみが適用されます。
  • ツールサポート: マネジメントコンソール、AWS CLI、SDK で設定可能です。CloudFormation や他のIaCツールでのサポート状況はバージョンによるため、テンプレート記述時はドキュメント/リリースノートを確認してください。

参考情報 ​

[Rds For Sql Server] Amazon RDS Custom now supports the latest CU and GDR updates for Microsoft SQL Server ​

概要 ​

Amazon RDS Custom for SQL Server が、Microsoft SQL Server の最新の Cumulative Update (CU) と General Distribution Release (GDR) をサポートしました。セキュリティ修正（複数のCVE）と修正・改善を含むアップデートが適用可能です。

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

今回のリリースでサポートされたバージョンは、SQL Server 2019: CU32 + GDR (KB5102335) に対応する RDS バージョン 15.00.4480.2.v1 と、SQL Server 2022: CU25 + GDR (KB5101347) に対応する RDS バージョン 16.00.4262.2.v1 です。GDR はセキュリティ脆弱性（CVE-2026-47295、CVE-2026-47296、CVE-2026-54118、CVE-2026-55002）に対処します。これらの更新には Microsoft 側のバグ修正や機能改善も含まれるため、安定性・セキュリティ向上が期待できます。RDS Custom のインスタンスは AWS マネジメントコンソール、AWS SDK、または AWS CLI を使ってアップグレードできます。詳細な修正内容は Microsoft の KB ドキュメント（KB5101347、KB5102335）を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Amazon RDS Custom for SQL Server を利用しているデータベース管理者、クラウド/DB運用チーム
  • 利用シーン: セキュリティ脆弱性修正の適用、安定性や不具合修正を取り込むための定期メンテナンス
  • 運用効果: 既知の脆弱性対応によりセキュリティリスク低減。最新 CU の修正でパフォーマンスや信頼性が向上する可能性
  • 対応バージョン: SQL Server 2019 (RDS 15.00.4480.2.v1) および SQL Server 2022 (RDS 16.00.4262.2.v1) に対して提供
  • ダウンタイム影響: アップグレードでインスタンス再起動やサービス停止が発生する可能性があるため、メンテナンスウィンドウや業務影響を考慮して適用推奨

技術的な注意点 ​

  • IAM権限: インスタンス変更/管理に必要な IAM 権限（例: rds:ModifyDBInstance、rds:DescribeDBInstances、rds:RebootDBInstance 等）を持っていることを確認してください
  • リージョン制限: 提供状況はリージョンごとに異なる場合があります。対象リージョンでのサポート状況は AWS コンソールで確認してください
  • コスト: パッチ適用自体に追加料金は通常発生しませんが、RDS Custom の利用料やアップグレードによる一時的なパフォーマンス影響が運用コストに影響する可能性があります
  • バックアップ: アップグレード前にスナップショットまたはバックアップを取得しておくこと。RDS のロールバックは一般にスナップショットからの復元が必要です
  • 互換性検証: CU/GDR による機能や動作変更がアプリケーションに影響を与える可能性があるため、ステージング環境で事前検証を実施してください
  • メンテナンス運用: 即時適用(ApplyImmediately) はダウンタイムが発生するため、メンテナンスウィンドウでの適用や業務時間外の計画を推奨します
  • 監視/検証: アップデート後はエラーログ、パフォーマンス指標、アプリケーション挙動を確認し、必要に応じてロールバック計画を実行できるようにしておいてください
  • その他: RDS Custom はより高い管理権限を提供しますが、OS 側の更新や設定変更が必要になるケースもあるため、運用手順を整備しておくこと

参考情報 ​

[Documentdb] Amazon DocumentDB now supports direct major version upgrades to version 8.0 ​

概要 ​

Amazon DocumentDB がエンジンのメジャーバージョンを直接 3.6 または 4.0 から 8.0 にインプレースでアップグレードできるようになりました。中間バージョンを経由する必要がなく、既存データ・設定・クラスター構成を維持したまま移行できます。

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

今回の機能追加により、Amazon DocumentDB (with MongoDB compatibility) はエンジンバージョン 3.6 および 4.0 から直接 8.0 へのメジャーバージョンアップ（MVU: major version upgrade）をサポートします。中間バージョンへの段階的なアップグレードが不要となり、既存のデータ、パラメータ設定、セキュリティグループやサブネットなどのクラスター設定を保持したままアップグレードできます。バージョン 8.0 への移行で最新のセキュリティパッチ、パフォーマンス改善、および新しい開発者向け機能（MongoDB 8.0 相当の新機能）を利用可能になります。メジャーアップグレードは、3.6/4.0 がサポートされているすべての AWS リージョンで提供されます。詳細な手順、互換性差分、注意点については Amazon DocumentDB の MVU（メジャーバージョンアップ）ドキュメントとリリース情報を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Amazon DocumentDB を運用している開発者、データベース管理者、SRE／運用チーム
  • 利用シーンまたは効果: レガシーな 3.6/4.0 クラスターを中間バージョンを経ずに 8.0 に移行して最新のセキュリティ修正や性能改善をすばやく反映できる。アプリケーションで新機能を利用可能にすることで機能開発の加速が期待できる。
  • 運用効果: アップグレード手順が簡潔化され、移行工数とリスク（複数回のアップグレード中の不整合や手順ミス）を低減できる。既存設定を保持するため復旧作業が軽減される。

技術的な注意点 ​

  • IAM権限: クラスターの変更やスナップショット作成が必要なため、docdb のクラスタ変更権限（例: docdb:ModifyDBCluster / docdb:ModifyDBInstance / docdb:CreateDBClusterSnapshot 等）を持つことを確認してください
  • ダウンタイム: メジャーバージョンアップではインスタンスの再起動やフェイルオーバーが発生する可能性があり、短時間の接続断やレプリカの再同期が起きる場合があります。メンテナンスウィンドウでの実施や事前検証を推奨します
  • 互換性（クライアント/ドライバ）: アプリケーションが使用する MongoDB クライアントドライバや依存ライブラリが MongoDB 8.0 相当に対応しているか確認してください。動作しない非推奨機能や挙動変更がある可能性があるためアプリケーション側のテストが必要です
  • テストとバックアップ: 本番アップグレード前にステージング環境でアップグレードを検証し、フルスナップショットを取得しておくこと（ロールバック用の方針）を推奨します
  • リージョン制限: 発表によれば、3.6/4.0 がサポートされている全リージョンで利用可能です。ただしリージョンごとのロールアウト状況はドキュメントで再確認してください
  • コスト: アップグレードそのものに追加料金は通常発生しませんが、スナップショット保存コストやアップグレード中の一時的なリソース利用（リードレプリカの追加検証など）によりコストが発生する場合があります

参考情報 ​

[General] Partner Revenue Measurement expands service coverage for User Agent string capability ​

概要 ​

Partner Revenue MeasurementのUser Agent文字列による計測範囲が拡張され、CloudTrailにコントロールプレーン操作を記録する追加のAWSサービスに対してパートナーの帰属収益を測定できるようになりました。既にAPN_1.1/pc_$形式のUser Agentを組み込んでいるパートナーは追加実装不要で自動的に恩恵を受けられます。

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

これまでUser Agent文字列は限定的なサービス消費の計測に使われていましたが、今回の拡張により、AWS CloudTrailにコントロールプレーン（管理イベント）アクティビティをログする追加のサービスに対してもUser Agentベースの消費計測が可能になりました。技術的には、API呼び出しに含まれるUser Agentヘッダ（APN_1.1/pc_$のフォーマット）をCloudTrailのログ内のuserAgentフィールドで識別し、パートナー提供ソフトウェアやソリューションによる消費・収益を帰属させます。既に指定フォーマットのUser Agentをアプリケーションに組み込んでいる場合、追加の実装作業は不要で、計測結果はAWSコンソールのPartner Central内 Partner Analytics にあるAttributed Revenue Dashboardで確認できます。本方法は、既存のResource TaggingやAWS Marketplaceのメータリング統合による帰属手法を補完します。Partner Revenue Measurementは全ての商用リージョンでGAです。

影響範囲・利用シーン ​

  • 対象ユーザー: AWSパートナー（ISV、SaaSプロバイダ、ソリューションプロバイダ）およびパートナーのビジネス/収益アナリスト
  • 利用シーン: パートナー提供アプリケーション・サービスがAWS上で発生させるコントロールプレーン操作を基に、どの程度のAWS消費・収益がそのソリューションに帰属するかを可視化する場面（製品別収益分析、契約報告、営業/マーケティング効果測定）
  • 運用効果: 追加の実装なしに計測対象サービスが増えることで、帰属精度と可視性が向上し、売上貢献の把握や価格戦略・パートナーマネジメントの改善に繋がる

技術的な注意点 ​

  • User Agentフォーマット: APN_1.1/pc_$ の形式をアプリケーションやクライアントのUser Agentに含める必要があります。既に組み込んでいる場合は追加作業不要です
  • CloudTrail設定: 対象となるサービスのコントロールプレーン（管理イベント）がCloudTrailで記録されていることが前提です。management eventsが有効であるか確認してください
  • ログ項目: CloudTrailのuserAgentフィールドに当該文字列が含まれていることが必要です。プロキシやカスタムHTTPクライアントでUser Agentが上書きされないよう注意してください
  • IAM権限: Partner Analytics / Partner Central上のAttributed Revenue Dashboardへアクセスするための適切なパートナーアカウント権限が必要です。また、CloudTrailログやS3バケット等の設定確認には該当リソースへの閲覧権限が必要になる場合があります
  • コスト: CloudTrailで管理イベントを有効化するとログ配信・保管（S3、CloudTrail Data Eventsなど）に対する料金が発生する可能性があります。ダッシュボード利用自体の課金モデルも確認してください
  • リージョン制限: 発表では「全ての商用リージョンでGA」とされています。GovCloudや中国リージョンなど商用外リージョンは対象外となる可能性があるため、利用リージョンを確認してください
  • プライバシー/セキュリティ: User Agentに機微情報や顧客の個人情報を含めないでください。ログ取扱いやデータ保持に関するコンプライアンス要件に留意してください

参考情報 ​

[General] AWS Agent Registry agents and MCP servers now available in Amazon Quick ​

概要 ​

Amazon QuickがAWS Agent Registryと統合され、組織のAgent Registryに登録されたagentsおよびMCPサーバーをQuick上で検索・有効化し、チームで共有して利用できるようになりました。接続情報はレジストリから自動で反映され、ビジネスユーザーは設定の重複なしに既存のエージェントを活用できます。

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

本アップデートにより、Amazon Quickの管理コンソールからAWS Agent Registryに接続すると、レジストリ内のMCPサーバーおよびagentsを検索・ブラウズでき、目的のリソースを数クリックで有効化できます。有効化時にはレジストリに登録された接続詳細（エンドポイント、認証情報の参照先等）が自動入力され、Quick内のチャット、agents、アプリ、フロー、Deep Researchなど複数の機能で共有・利用可能になります。これにより、Amazon Bedrock AgentCoreで技術チームが構築したエージェントを、ビジネスユーザーが自身のQuickワークスペースから容易に利用できるようになり、手動での接続設定や二重管理を削減します。導入は管理者コンソールの「Manage account」→「Permissions」→「AWS Agent Registry」から行います。対応リージョンは、Amazon QuickとAmazon Bedrock AgentCoreの両方が利用可能なリージョン（US East (N. Virginia)、US West (Oregon)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Europe (Frankfurt)、Europe (Ireland)）です。

影響範囲・利用シーン ​

  • 対象ユーザー: プラットフォーム/インフラチーム、エージェント開発者（AgentCore利用者）、ビジネスユーザー（Amazon Quick利用者）、SRE/運用チーム
  • 利用シーン: 既存のMCPサーバーやエージェントをQuickワークスペースにすばやく取り込み、チャットやワークフロー、アプリ内で再利用するケース（例: ナレッジ検索エージェントの共有、業務アプリでの自動化エージェント活用）
  • 運用効果: 接続設定の二重作業削減、エージェント導入のスピードアップ、組織内でのリソース共有による運用負荷低減とガバナンスの一元化

技術的な注意点 ​

  • IAM権限: Quick側でAgent Registryを接続するには管理者権限が必要。レジストリ・エージェントへアクセスするためのIAMポリシー（読み取りやシークレット参照等）を適切に付与してください。
  • リージョン制限: Amazon QuickとAmazon Bedrock AgentCoreの両方が利用可能なリージョンでのみ有効（記事記載のリージョン: US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland)）。
  • 前提条件: 組織のAWS Agent Registryに対象のMCPサーバー/agentが事前に登録されていること。レジストリに接続情報（エンドポイント、認証方法）が正しく登録されている必要があります。
  • ネットワーク/認証: レジストリの接続情報が自動入力されるものの、エージェント側で追加のネットワーク設定（VPC接続やセキュリティグループ）、あるいはシークレットマネージャー等の認証情報参照が必要な場合は別途設定が必要です。アクセス制御はレジストリとQuick両方で整合させてください。
  • コスト: Agentの実行やBedrock API呼び出しにはそれぞれ課金が発生する可能性があります。Quickでの共有自体に追加料金が発生するかは利用状況によるため、サービスごとの料金表を確認してください。

参考情報 ​

[Redshift] Amazon Redshift now supports AWS IAM Identity Center authentication with enhanced VPC routing ​

概要 ​

Amazon Redshiftが、Enhanced VPC Routing（EVR）を有効にしたプロビジョンドクラスターとServerlessワークグループでAWS IAM Identity Center（旧AWS SSO）認証をサポートしました。認証トークンの検証と交換はVPC内のAWS PrivateLinkインターフェイスエンドポイント経由で行われ、認証トラフィックもAWSネットワーク内に留まります。

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

技術的には、RedshiftはEVRを有効にした環境において、IAM Identity Centerのトークン検証および交換をVPC内のAWS PrivateLinkインターフェイスVPCエンドポイント経由で行います。これにより、クライアントのシングルサインオン（企業認証情報）による接続時の認証・認可処理がパブリックインターネットを経由せずVPC内の同一の経路を通るため、データ所在・規制遵守・ネットワーク分離要件を満たしやすくなります。EVRではRedshiftと他のAWSサービス間の全トラフィックがVPC経由となり、セキュリティグループ、ネットワークACL、エンドポイントポリシーで制御でき、VPC Flow Logsで可視化できます。本機能はプロビジョンドクラスターとServerlessワークグループの双方をサポートし、IAM Identity Centerのマルチリージョン複製（primary Identity Centerが別リージョンにあるケース）にも対応します。機能は、両サービスが利用可能なリージョンで利用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: 規制対応が必要な組織、データレジデンシー要件のある企業、ネットワーク分離を重視するSRE/セキュリティチーム
  • 利用シーン: 社内シングルサインオン（IAM Identity Center）でRedshiftへ接続しつつ、認証/データトラフィックをパブリックインターネットに出さずVPC内で完結させたい分析基盤
  • 運用効果: 認証フローも含めた全トラフィックをVPCで一元管理でき、セキュリティポリシー適用・ログ収集・ネットワーク監査が容易になり、コンプライアンス要件の満たしやすさが向上する

技術的な注意点 ​

  • IAM権限: VPCエンドポイント作成（ec2:CreateVpcEndpointなど）やRedshiftの設定変更（クラスター/ワークグループの変更権限）が必要。事前に最小権限を確認してください
  • VPCエンドポイント: IAM Identity Center（旧AWS SSO）用のAWS PrivateLinkインターフェイスVPCエンドポイントをVPC内に作成・構成する必要があります。エンドポイントポリシーやセキュリティグループの設定でアクセス制御を行ってください
  • EVR設定: 対象のプロビジョンドクラスターまたはServerlessワークグループでEnhanced VPC Routingを有効にする必要があります
  • リージョン制限: 本機能は「Amazon Redshift」と「IAM Identity Center」の両方が利用可能なリージョンで提供されます。IAM Identity Centerの配置（プライマリのリージョン）とRedshiftのリージョンが異なる場合は、IAM Identity Centerのマルチリージョン複製がサポートされていますが、事前にレプリケーション設定を確認してください
  • コスト: インターフェイスVPCエンドポイントは時間課金とデータ処理料金が発生します。NAT Gateway経由のトラフィック削減でコスト構造が変わる可能性があるため、費用影響を評価してください
  • 監査/可視化: 認証トラフィックはVPC内を通るためVPC Flow Logsや既存のネットワーク監視で可視化・監査可能です

参考情報 ​

[Timestream] Amazon Timestream for InfluxDB is now available in 8 additional AWS Regions ​

概要 ​

Amazon Timestream for InfluxDB が8つの追加リージョン（アフリカ（ケープタウン）、アジア太平洋（バンコク／香港／ハイデラバード／メルボルン／ソウル）、ヨーロッパ（チューリッヒ）、イスラエル（テルアビブ））で利用可能になりました。InfluxDB互換のフルマネージド時系列データベースをこれらのリージョンで低遅延かつリージョン内データ保持で利用できます。

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

今回の拡張により、Amazon Timestream for InfluxDB を次の8リージョンで利用可能になりました：Africa (Cape Town), Asia Pacific (Bangkok), Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Asia Pacific (Seoul), Europe (Zurich), Israel (Tel Aviv)。

Timestream for InfluxDB は InfluxDB のオープンAPI（InfluxDB互換API）をサポートするフルマネージドサービスで、アプリ開発者やDevOpsがリアルタイム時系列アプリケーションを構築しやすくします。主な技術的特徴は以下の通りです：

  • マルチAZ高可用性（Multi-AZ）と読み取りレプリカによる可用性向上
  • 強化されたデータ耐久性
  • ノードの水平スケーリング（シングルノードから最大15ノードのEnterpriseクラスターまでスケール可能）
  • 必要に応じた「right-size」なデプロイが可能で、アーキテクチャを変更せずにノード数を増減できる
  • コンソール、AWS CLI、AWS SDKs を用いたデータベース作成・管理

これにより、地域的に分散したユーザーやデータレジデンシー要件を持つワークロードで、InfluxDB互換のAPIで既存アプリケーションをほぼそのまま移行・運用できる可能性が高まります。

影響範囲・利用シーン ​

  • 対象ユーザー: 時系列データを扱うアプリ開発者、SRE/運用チーム、IoT/産業計測・モニタリング担当者
  • 利用シーン: ローカルリージョンでの低遅延データ収集・クエリ（例：工場のセンサー監視、リアルタイムメトリクス、監視ダッシュボード）
  • 運用効果: マネージド運用によりインフラ管理負荷が低減し、Multi-AZや読み取りレプリカで可用性の向上とフェイルオーバー耐性を確保可能
  • データ主権・コンプライアンス: 指定リージョンでのデータ保持が可能になり、データレジデンシー要件への対応性が向上
  • 移行・互換性: 既存のInfluxDBクライアント（InfluxDB互換API）を利用した移行が容易になり、アプリケーション改修を最小限にできる可能性が高い

技術的な注意点 ​

  • IAM権限: サービス利用・データベース作成には適切なIAMポリシー（Timestream関連の権限）が必要です。AWS CLI/SDKから操作する場合は実行IAM権限を確認してください
  • リージョン制限: 本リリースで追加されたのは上記8リージョンのみ。利用前に対象リージョンでサービスが有効化されているか確認してください
  • コスト: マルチノード構成や読み取りレプリカ、リージョン間転送、ストレージ・リクエストに対する課金が発生します。特にEnterpriseクラスターやレプリカ使用時はコスト増加に注意してください。詳細は料金ページを確認してください
  • 互換性: 「InfluxDB互換API」を提供しますが、InfluxDB OSS/Enterpriseのすべての拡張機能やバージョン固有の挙動が完全一致するとは限りません。移行前にクエリ・書き込みパターンで互換性テストを実施してください
  • 運用上の注意: スケーリング（ノード増減）やフェイルオーバーの挙動、バックアップ・リストアの要件・手順を事前に確認し、監視・アラート設定を整備してください
  • 上限: 記事では最大15ノードのEnterpriseクラスターまで言及されています。大規模構成を予定する場合はサービスクォータやサポートに相談してください

参考情報 ​

[Redshift] Amazon Redshift now supports Apache Iceberg v3 tables ​

概要 ​

Amazon RedshiftがApache Icebergのフォーマットバージョン3（v3）を読み書きできるようになりました。v3の主要機能（デフォルト列値、行系譜、削除ベクター）を利用して、スキーマ進化や高頻度更新/削除、CDC/増分処理が容易になります。

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

今回のアップデートで、RedshiftはIceberg v3テーブルの読み取りと書き込みをサポートします。主な技術的追加点は以下のとおりです。

  • デフォルト列値 (default column values): 新たに追加された列に対して初期値を定義でき、INSERT時に値が与えられなかった場合に自動で適用されます。既存テーブルへのスキーマ拡張が簡単になり、既存データのバックフィルやETLの変更を最小化できます。

  • 行系譜 (row lineage): 各行の識別子や最終更新シーケンス番号を参照する疑似カラムを公開します。これにより、変更された行のみを抽出する増分パイプラインやCDC（変更データキャプチャ）ワークフローの構築が容易になります。

  • 削除ベクター (deletion vectors): Iceberg v2で使われていた位置ベースのdeleteファイルを廃し、圧縮されたビットマップによる削除ベクターを採用します。これにより、高頻度のUPDATE/DELETEワークロードに対して読み取り・書き込みのパフォーマンスと効率が向上します（コンパクトなメタデータ、より高速なフィルタリング）。

運用面では、v3テーブルはCREATE TABLE ... USING ICEBERG TABLE PROPERTIES ('format-version' = '3')で作成できます。既存のv2テーブルはALTER TABLE SET TABLE PROPERTIES ('format-version' = '3')でインプレースアップグレードが可能です。GravitonベースのプロビジョンドクラスタおよびServerlessクラスターの両方でv3がサポートされています。

注意点として、v3はテーブルのメタデータフォーマットや削除管理手法が変わるため、v2を前提とした外部ツールやカタログとの互換性を事前に確認する必要があります。バックアップ（スナップショット）やクライアント互換性テストを推奨します。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データプラットフォームチーム、BIチーム、SRE/運用チーム
  • 利用シーン: 増分ETL/CDCパイプライン（変更分のみ処理）、スキーマ進化が頻繁なデータレイクテーブル、コンプライアンス要件での高頻度レコード削除
  • 運用効果: スキーマ追加時の運用負荷低減（デフォルト値適用）、増分処理の効率化（row lineageによる差分抽出）、更新/削除負荷の軽減と読み取り性能向上（削除ベクター）
  • 互換性リスク: v2を前提とする解析ツールやカタログとの互換性問題が発生する可能性があるため、移行前にクライアント・ETLの動作確認が必要です

技術的な注意点 ​

  • IAM権限: RedshiftからIcebergテーブルとその基になるオブジェクト（S3、Glue/Hiveカタログ等）へアクセスするための適切なIAMロール/権限（S3:Get/Put/Delete、Glueカタログの読み書きなど）を設定してください。
  • リージョン制限: What's New記事で特にリージョン制限は示されていませんが、導入前に使用するリージョンでのサポート状況を公式ドキュメントで確認してください。
  • コスト: 追加料金の専用項目は明示されていませんが、アップグレード処理やメタデータ操作、Serverless/プロビジョンドのクエリ実行に係る通常のRedshift料金、S3ストレージ・データ転送、Glueカタログ利用料などが発生します。インプレースアップグレード時は試験やバックアップに伴う処理コストに留意してください。
  • 互換性: v3の削除ベクターやメタデータ仕様に対応していない外部クライアントやツールは期待どおりに動作しない可能性があります。v2↔v3の混在運用は制約が出るため、移行計画を立てて段階的に検証してください。
  • 運用上の推奨: アップグレード前にスナップショット取得、ステージング環境での互換性検証、クエリパフォーマンス比較（特に高頻度UPDATE/DELETEワークロード）を推奨します。
  • 実装コマンド: 新規作成 -> CREATE TABLE ... USING ICEBERG TABLE PROPERTIES ('format-version' = '3')。既存v2のアップグレード -> ALTER TABLE SET TABLE PROPERTIES ('format-version' = '3')。
  • 対応クラスター: GravitonベースのプロビジョンドクラスタおよびServerlessクラスターでサポートされています。

参考情報 ​

[Ec2] Amazon EC2 R9g and R9gd memory optimized instances are now available ​

概要 ​

Amazon EC2 の新しいメモリ最適化インスタンス R9g / R9gd（AWS Graviton5 搭載）が一般提供開始されました。高いメモリ性能とキャッシュを備え、メモリ集約型ワークロードでの価格性能改善を狙ったインスタンスです。

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

R9g および R9gd は AWS 独自設計の第5世代プロセッサ AWS Graviton5 を搭載したメモリ最適化インスタンスです。R9gd は加えてローカル NVMe ベースの SSD（インスタンスストア）を持ち、ブロックレベルの低レイテンシなローカルストレージを提供します。R9g / R9gd は R8g / R8gd（Graviton4）比で最大 25% のコンピュート性能向上を実現し、データベースで最大 30% 高速化、ウェブアプリで最大 35% 高速化、機械学習で最大 35% 高速化するとされています。処理性能向上の背景には 5 倍の大容量キャッシュとクラウド上で最速クラスのメモリ性能があります。これらのインスタンスは第6世代 AWS Nitro System 上に構築され、初めて Nitro Isolation Engine（形式的検証によりワークロード分離を数学的に保証する機能）を採用しています。販売は Savings Plans、オンデマンド、スポット、Dedicated インスタンス / ホストで可能です。対応リージョンは現時点で US East (N. Virginia, Ohio)、US West (Oregon)、EU (Frankfurt) に限定されています。主要なユースケースはデータベース、インメモリキャッシュ、大規模インメモリデータ処理、リアルタイム分析、コンテナ化された Linux ワークロード（Kubernetes/EKS/ECS 等）や C/C++, Rust, Go, Java, Python, .NET Core, Node.js, Ruby, PHP などの言語ベースアプリケーションです。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、SRE、プラットフォーム/インフラエンジニア、機械学習エンジニア、コンテナ運用者
  • 利用シーン: 大規模インメモリデータベースやキャッシュ（Redis, Memcached 等）、リアルタイムビッグデータ解析、低レイテンシ要件のデータベース、コンテナ化されたマイクロサービス群のホスティング
  • 運用効果: 同等ワークロードでの価格/性能比向上によるコスト削減、レスポンス向上とスループット増加、ローカル NVMe 必須のワークロードでのディスク I/O 性能改善
  • 移行影響: x86→ARM（aarch64）移行が必要な場合があり、バイナリ再ビルドやコンテナイメージのマルチアーキ対応が必要になる可能性が高い

技術的な注意点 ​

  • AMI/互換性: Graviton5 は ARM (aarch64) アーキテクチャのため、対象 AMI（Amazon Linux 2/2023、対応版 Ubuntu など）やライブラリ、ネイティブバイナリが aarch64 に対応していることを確認してください
  • ドライバ/対応: ENA（Enhanced Networking）や NVMe ドライバ（R9gd のインスタンスストア利用時）が必要です。カーネル/ドライバの互換性を事前検証してください
  • リージョン制限: 2026-08-31 時点で利用可能リージョンは US East (N. Virginia, Ohio)、US West (Oregon)、EU (Frankfurt) のみ。その他リージョンは順次対応の可能性あり
  • ストレージ: R9gd のローカル NVMe はインスタンスストア（揮発性）です。永続化が必要なデータは EBS や外部ストレージに保存する設計にしてください
  • IAM権限: 特段の新権限は不要ですが、インスタンス起動や専有ホスト/Dedicated オプション利用時の既存 EC2/IAM 権限が必要です
  • コスト: 単純な時間当たり料金はリージョン/サイズに依存しますが、AWS の提示どおり価格性能比が向上しているため既存環境から移行すると総コスト削減効果が期待できる一方、移行のための検証/改修コスト（再ビルド、テスト等）が発生します
  • その他: Nitro Isolation Engine はセキュリティ/分離性を強化しますが、運用手順（アクセス制御、監査）は引き続き必要です。特になし、ではありません。

参考情報 ​

[Cognito] Amazon Cognito now supports machine-to-machine authorization without a user pool domain ​

概要 ​

Amazon CognitoにGetClientToken APIが追加され、ユーザープールドメインを設定せずにアプリクライアントがクライアントID/シークレットでM2M（machine-to-machine）用のアクセストークンを取得できるようになりました。

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

GetClientTokenはアプリクライアントがclient_idとclient_secretで認証し、リソースサーバーに定義したカスタムスコープに対するアクセストークンを取得するためのネイティブAWS API操作です。従来のドメインを使ったOAuth 2.0のclient-credentialsフローに加えて、AWS SDK、CLI、およびAPI経由で直接呼び出せる経路を提供します。GetClientTokenはAWS WAFやVPCインターフェイスエンドポイント（AWS PrivateLink）と連携可能であり、Cognitoユーザープールが利用可能なすべてのリージョンで利用できます。利用開始は、ユーザープールでアプリクライアント（クライアントシークレット有効化、許可スコープ設定等）を設定し、SDK/CLI/APIでGetClientTokenを呼び出すだけです。料金は標準のCognito M2M料金が適用されます。

影響範囲・利用シーン ​

  • 対象ユーザー: マイクロサービス開発者、バックエンド開発者、SRE/運用担当者
  • 利用シーン: サービス間認可（マイクロサービス間通信、バッチ/自動化ワークロード、CI/CDパイプラインの認証）でユーザープールドメインを用いずにアクセストークンを取得したい場合
  • 運用効果: ドメイン設定やホスト管理の手間を減らし、AWS SDK/CLIから直接トークン取得が可能になることで実装・運用の簡素化と自動化が進む
  • セキュリティ/アーキテクチャ: VPCエンドポイントやWAFと組み合わせることでネットワーク分離や防御を保ちつつM2M認可を組み込める

技術的な注意点 ​

  • IAM権限: 呼び出し元のIAMエンティティは Amazon Cognito Identity Provider の cognito-idp:GetClientToken 権限が必要になる可能性があるためポリシーを確認してください
  • クライアント設定: アプリクライアントでクライアントシークレットを有効化し、対象のリソースサーバーとスコープを事前に設定する必要があります
  • トークン管理: 発行されるアクセストークンのスコープ・有効期限はユーザープールおよびアプリクライアント設定に依存します。シークレットのローテーションや安全な保管を徹底してください
  • 既存フローとの共存: ドメインベースのOAuth 2.0 client-credentialsフローは引き続き使用可能です。移行は任意です
  • ネットワーク/統合: GetClientTokenはAWS WAFおよびVPCインターフェイスエンドポイント（PrivateLink）をサポートします。プライベート接続を利用したい場合はVPCエンドポイントを構成してください
  • リージョン制限: Amazon Cognitoユーザープールが利用可能な全リージョンで提供されています（利用前に対象リージョンでのサービス有無を確認してください）
  • コスト: 標準のAmazon Cognito M2M料金が適用されます。トークン発行量によりコストが増加する可能性があるため想定負荷に基づく見積もりを行ってください

参考情報 ​

[Lambda] AWS Lambda recursive loop detection is now available in all commercial AWS Regions ​

概要 ​

AWS Lambda の再帰的ループ検出機能がすべての商用 AWS リージョンで利用可能になりました。デフォルトで有効なガードレールとして、Lambda とサポートされるイベントソース間の再帰呼び出しを自動検出して停止します。

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

この機能は、Amazon S3、Amazon SQS、Amazon SNS といったイベントソースやその他サポートされるサービスを介した誤った構成やコード不具合により、イベントが元のトリガー先に戻されることで発生する再帰的な呼び出し（ループ）を検出して自動的に処理を停止します。ループを検出すると、当該イベントの処理を中断し、トラブルシューティング手順を含む AWS Health Dashboard の通知が送られます。検出はデフォルトで有効ですが、意図的に再帰呼び出しを行っている関数がある場合は PutFunctionRecursionConfig API を使ってその関数単位で検出を無効化できます。利用には「サポートされる SDK バージョン以降」を使用していることが条件となる点に注意してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Lambda を利用する開発者、SRE/運用チーム、アーキテクト
  • 利用シーン: S3/SQS/SNS 等のイベントソースからのトリガーで誤設定によりイベントが発信元に戻るパターン（例: ファイルアップロード→Lambdaで処理→同バケットに結果を戻す）
  • 運用効果: 再帰ループによる無限実行や予期せぬコスト増加を未然に防止し、早期に原因通知（AWS Health Dashboard）を受け取れることで復旧時間を短縮
  • ビジネス影響: 無限実行による過剰課金リスクを低減し、運用負荷とコストの削減に寄与

技術的な注意点 ​

  • IAM権限: PutFunctionRecursionConfig を実行・変更するには lambda:PutFunctionRecursionConfig 権限が必要です。Health イベントを参照するには AWS Health 関連の表示権限やサポートプランに依存する機能がある点に注意してください
  • SDK/ランタイム: 検出機能の恩恵を受けるには「サポートされる SDK バージョン以降」を使用する必要があります。古い SDK/ランタイムでは正しく動作しない可能性があります
  • 無効化方法: 意図的な再帰を行う関数は PutFunctionRecursionConfig API を使い、関数単位で検出をオフにできます（設定変更は慎重に行ってください）
  • リージョン制限: すべての商用 AWS リージョンで利用可能です（AWS GovCloud/中国リージョンは別扱いの可能性あり）
  • コスト: 検出自体による追加課金は通常発生しませんが、検出により無限実行を防げるため潜在的なコスト削減効果があります
  • ログ/監視: 事象発生時は AWS Health Dashboard に通知が出ます。CloudWatch Logs/metrics による補完的な監視やアラート設定を推奨します

参考情報 ​

[Aurora] Amazon Aurora serverless is now available with 30% better performance and smarter scaling in additional AWS Regions ​

概要 ​

Amazon Aurora Serverless がプラットフォームバージョン4で最大30%の性能向上と改善されたスケーリングを追加リージョンで提供開始しました。Aurora PostgreSQL と Aurora MySQL の両方に適用され、追加費用なしで利用可能です。

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

今回のアップデートでは、Aurora Serverless がリソース競合のある負荷（多数の同時タスクやバーストするトラフィック）に対してより効率的に拡張・縮退する改良されたスケーリングアルゴリズムを導入し、最大で約30%の性能向上を実現しています。特にトラフィックの急増・無負荷期間・利用パターンが予測しづらいワークロード（例: エージェント型AIアプリ、バーストするWeb/APIサービス）に適しています。これらの改善はプラットフォームバージョン4で提供され、新しいクラスター・リストア・クローンは自動的にバージョン4で起動します。既存クラスターは保留中のメンテナンス、停止→再起動、またはブルー/グリーン展開によってバージョン4へ移行できます。追加リージョンは Asia Pacific (New Zealand)、Asia Pacific (Thailand)、Africa (Cape Town)、Europe (Milan)、Mexico (Central) で、改善は Aurora PostgreSQL と Aurora MySQL の両方に適用されます。これらの性能改善・スケーリング改善は追加コストなしで提供されますが、通常のAurora Serverlessの使用量に応じた課金は発生します。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース/クラウドエンジニア、SRE、アプリ開発者（Aurora PostgreSQL/MySQL を利用するチーム）
  • 利用シーン: バースト的なトラフィックやアイドル期間が混在する Web/API サービス、エージェント型AIやバッチ処理のスパイク対応、テスト/ステージング環境のオンデマンドスケール
  • 運用効果: リソース競合時のスループット改善によりレスポンス安定化とスケール時間短縮が期待でき、利用量に応じたコスト効率の向上（アイドル時はゼロまで縮退可能）
  • リージョン影響: 新たに対応したリージョン（NZ/Thailand/Cape Town/Milan/Mexico Central）で同等の性能とスケーリング特性が利用可能となる

技術的な注意点 ​

  • プラットフォームバージョン: 改善はプラットフォームバージョン4で提供されます。新規クラスター・リストア・クローンは自動でv4になります
  • 既存クラスターのアップグレード: 保留中のメンテナンス、停止→再起動、またはブルー/グリーンデプロイで移行可能です。スイッチ時は接続中のワークロードに影響が出るため計画的に実施してください
  • エンジン互換性: Aurora PostgreSQL および Aurora MySQL の両方で有効です
  • リージョン制限: 改善は記事に記載の追加リージョンで利用可能です。全リージョンで即時利用できるわけではないため、利用前に対象リージョンでの可用性を確認してください
  • コスト: パフォーマンス改善そのものに追加料金はありませんが、通常のAurora Serverlessの課金（実際に割り当てられた容量に基づく課金）は発生します。スケーリングで一時的に容量が増えると料金が増える点に注意
  • 運用監視: CPU/メモリ/接続数に加え、スケールイベント（スケールアウト/イン）、レイテンシ、スロットリングや待ち行列の指標をCloudWatchで監視することを推奨します
  • 互換性注意: アプリケーション側で接続再試行や短期的な接続断に対する設計（リトライ/バックオフ）をしておくと、スケールやメンテナンス時の影響を軽減できます

参考情報 ​

[Opensearch Service] Amazon OpenSearch Service adds new Cluster Insights for faster diagnosis of cluster status ​

概要 ​

Amazon OpenSearch ServiceはCluster Insightsを拡張し、Red/Yellowステータスの根本原因を自動で特定する17の新しいインサイトを追加しました。各インサイトは影響ノードと具体的な対処案を提示し、クラスタの復旧を高速化します。

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

追加された17のインサイトは、JVMのOOM、持続的なCPU飽和、ディスク容量不足、AZのアンバランス、レプリカ数の誤設定など、リソース枯渇や設定ミスに起因する問題を自動的に特定します。内訳は、プライマリシャードがアンアサインされる原因（Redステータス）を検出する重大(Critical)なインサイトが6件、レプリカ割当てを妨げる問題（Yellowステータス）を検出するMedium〜Criticalのインサイトが11件です。各インサイトは影響を受けるノードやAZを明示し、インスタンスタイプのスケールアップ、ディスク増量、シャード割当設定の修正、ゾーン再バランスなどの具体的な推奨アクションを提示します。従来は複数のノード・メトリクスやAZを手作業で相関させる必要がありましたが、今回の拡張により根本原因の特定とターゲットを絞った修復が自動化されます。これらのインサイトは追加料金なしで提供され、OpenSearch 1.0以降およびElasticsearch 6.8以降を実行するドメインで利用可能です（11リージョン対応）。

影響範囲・利用シーン ​

  • 対象ユーザー: OpenSearch/Elasticsearchを運用するSRE、プラットフォームチーム、データエンジニア
  • 利用シーンまたは効果: クラスタがRed/Yellowになった際の原因特定・復旧作業の短縮（JVM OOM、CPU飽和、ディスク不足、ゾーン不均衡、誤設定レプリカ等に対する即時の診断と対策提示）
  • 運用効果: ダウンタイムや検索/インデックス性能劣化の早期解消、無駄なフルクラスタ調査の削減、適切なスケーリングや設定変更によるリソース最適化

技術的な注意点 ​

  • 対応バージョン: OpenSearch 1.0以上、Elasticsearch 6.8以上のドメインで利用可能
  • リージョン制限: 利用可能リージョンは11リージョン（US East (N. Virginia, Ohio)、US West (Oregon)、Canada (Central)、Asia Pacific (Sydney, Tokyo)、Europe (Frankfurt, Ireland, London, Paris, Stockholm)）に限定
  • コスト: Cluster Insights自体は追加料金なしで提供。ただし、推奨される対処（インスタンスのスケールアップ、ディスク追加、AZの再構成など）はインフラコスト増を招く可能性あり
  • IAM権限: インサイトを閲覧・診断するにはOpenSearch Serviceおよび関連メトリクス（CloudWatch等）への読み取り権限が必要。具体的にはOpenSearch Serviceのドメイン閲覧/記述系権限やCloudWatch/Logsの読み取り権限を付与することを推奨
  • 注意点: インサイトは原因候補と推奨を提示するが、変更の実行（スケール、設定変更、シャード再割当など）は運用者が影響範囲を評価して実施する必要あり

参考情報 ​

[Bedrock] AWS Agent Registry for centralized agent discovery and governance is now generally available ​

概要 ​

AWS Agent Registryが一般提供（GA）になりました。組織内のエージェント、ツール、スキル、MCPサーバー、カスタムリソースを一元的にカタログ化・発見・ガバナンスするためのプライベートなレジストリ機能を提供します。

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

AWS Agent Registryは、コンソール・AWS CLI・AWS SDK経由で利用できるガバナンス付きの中央カタログ／発見レイヤーです。主な機能は以下の通りです。

  • レコード作成と管理：プレビューで提供されていた手動およびURLベースのレコード作成、承認ワークフロー、CloudTrailによる監査トレイルがGAで利用可能です。
  • 検索とブラウズ：セマンティック検索（意味検索）とキーワード検索を組み合わせた検索機能、専用のブラウズ画面でレジストリやレコードを探索できます。
  • 統合エコシステム：Amazon Bedrock AgentCore、Amazon Quick、Kiro IDEなどから直接レジストリのリソースを発見・利用できる統合を提供します。レジストリ自体はMCP（Model Control Plane）サーバーとしてエクスポーズされ、ビルダーやIDEから直接クエリ可能です。
  • エンタープライズ機能：CloudFormation、Terraform、AWS CDKを使ったレジストリのコードでのプロビジョニングと管理をサポート。レジストリとレコードにタグ付けして組織分類・コスト配分・アクセス制御に利用できます。
  • 共有とスケール：AWS Resource Access Manager（AWS RAM）を使い、アカウント間や組織全体でレジストリを共有可能。組織横断の共通カタログ構築ができます。
  • 自動検出：AgentCoreランタイムおよびAgentCoreゲートウェイ上のエージェントを組織全体で自動検出して中央レジストリに登録・更新する機能により、手動でのレコード作成負荷を低減します。
  • Amazon Quick連携：QuickのConnectorsページからレジストリ内のカスタムコネクタを直接発見して利用可能になりました。

GA時点での提供リージョンは5つ（US West (Oregon)、Asia Pacific (Tokyo)、Asia Pacific (Sydney)、Europe (Ireland)、US East (N. Virginia)）です。コンソール操作に加え、CLI/SDK/APIにより自動化・CI/CD統合が可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: AI/MLプラットフォームチーム、アプリ開発者、SRE/運用チーム、セキュリティ／ガバナンス担当者
  • 利用シーン: 既存のエージェント／コネクタ／スキルの発見と再利用（重複開発の防止）、組織横断での資産共有、IDEやAgentCoreからの直接クエリによる開発効率化
  • 運用効果: 可視化と承認ワークフローにより安全な利用を担保しつつ再利用を促進、管理対象が中央化されることで運用負荷とコストの削減が期待できる
  • ガバナンス効果: タグとAWS RAMによる共有制御、CloudTrail監査でコンプライアンス対応がしやすくなる
  • 開発効率: AgentCoreやIDE統合によりコンテキスト切替を減らし、素早く適切なエージェントを利用可能

技術的な注意点 ​

  • IAM権限: レジストリの作成・更新・共有には専用の権限が必要（Console/CLI/SDK操作用のポリシー確認を推奨）。AWS RAMやタグ付け操作の権限も必要です
  • リージョン制限: GA時点で利用可能なリージョンは US West (Oregon)、Asia Pacific (Tokyo)、Asia Pacific (Sydney)、Europe (Ireland)、US East (N. Virginia) の5リージョンのみ
  • コスト: レジストリ自体の基本機能に対する明確な追加料金は公表されていませんが、CloudTrailログ保存やデータ転送、AgentCoreランタイムの運用、関連サービス（S3等）利用に伴う通常のAWS料金が発生する可能性があります。詳細は料金ページで確認してください
  • 自動検出の前提: AgentCoreランタイム/ゲートウェイから自動検出するため、該当ランタイムのネットワーク到達性と適切な識別情報が必要です。誤検出やプライバシー制御の設計を検討してください
  • 共有設計: AWS RAMでの共有は組織ポリシーやアカウント境界の影響を受けます。組織単位でのレジストリ設計とアクセスモデル（読み取り専用 vs 管理者）を明確にしてください
  • IaCサポート: CloudFormation / Terraform / AWS CDKを用いたプロビジョニングが可能。テンプレート化してCI/CDへ組み込むことで一貫したガバナンスを実現できます
  • 監査: CloudTrailと連携して操作履歴を取得可能。監査要件に合わせてログ収集・保持ポリシーを設定してください

参考情報 ​

[Direct Connect] AWS announces AWS Interconnect - multicloud connectivity with Microsoft Azure in preview ​

概要 ​

AWS Interconnect - multicloud が Microsoft Azure 向けにパブリックプレビューで提供開始されました。AWS と他のクラウド間で専用かつスケーラブルなプライベート接続を一元管理できる、目的設計されたマルチクラウド接続サービスです。

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

AWS Interconnect - multicloud は、複数クラウドプロバイダ間の相互接続を簡素化するために設計された新サービスです。業界向けに公開されたオープンなネットワーク相互運用仕様を基盤としており、従来の“自前で接続を構築する”アプローチが抱えていたグローバルかつ多層のネットワーク運用の複雑さを削減します。今回、Microsoft Azure がこの公開仕様を採用し、AWS と Azure 間の接続を AWS 側からコンソール／CLI／API でプレビュー作成できるようになりました。サービスは耐障害性・スケーラビリティを念頭に置いたプライベート接続を迅速にプロビジョニングすることを目的とし、既に Oracle Cloud（GA）および Google Cloud（GA）との相互接続もサポートしています。Azure とのプレビューは以下の AWS リージョンで利用可能です：US East (N. Virginia)、US West (N. California)、Asia Pacific (Sydney)、Europe (Frankfurt)。詳細設定（ルーティング、相互運用パラメータ、接続冗長化など）はコンソール／CLI／API を通じて管理できます。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチクラウド構成を採用するクラウドアーキテクト、ネットワークエンジニア、SRE/運用チーム
  • 利用シーン: AWS と Azure 間で低遅延・プライベートなデータ転送が必要なハイブリッド／マルチクラウドアプリケーション、データベースレプリケーション、クロスクラウド災対構成
  • 運用効果: 接続のプロビジョニングと管理を一元化でき、従来の自前ソリューションに比べて運用負荷と構成ミスを低減。マルチクラウド間での可用性向上と接続のスケーラビリティ確保が期待できる

技術的な注意点 ​

  • IAM権限: Interconnect リソースの作成/管理に必要な IAM 権限（コンソール/CLI/API 操作権限）を事前に付与してください
  • リージョン制限: Azure プレビューは US East (N. Virginia)、US West (N. California)、Asia Pacific (Sydney)、Europe (Frankfurt) のみで利用可能です。他リージョンでは未対応の可能性があります
  • コスト: クロスクラウドの専用接続やデータ転送に対して追加料金（データ転送量、ポート/接続料金、パートナー経由の料金など）が発生する可能性があります。導入前に料金体系を確認してください
  • プレビューの注意: Azure 対応はプレビュー版のため、機能・性能・SLA が将来変更される可能性があります。商用クリティカルな用途では GA 状態やサポート条件を確認のうえ採用判断してください
  • ネットワーク設計: ルーティング（BGP 等）の設定、ASN/プレフィックス管理、MTU、暗号化/コンプライアンス要件（データ主権）を事前に検証してください
  • 互換性とエコシステム: オープン仕様に基づくため今後他 CSP やネットワークベンダも採用可能。既存の Direct Connect/専用回線やパートナー接続との組み合わせ設計を検討してください

参考情報 ​

[Msk] Amazon MSK Connect now supports restarting connectors ​

概要 ​

Amazon MSK Connectでコネクタとそのタスクを再起動できる機能が追加され、障害からの復旧や一時的な問題の解消、外部依存の変更反映が容易になりました。コンソール、AWS CLI、SDK、CDKから追加コストなしで利用可能です。

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

Amazon MSK Connect（Managed Streaming for Apache Kafka Connect）の機能拡張により、作成済みのコネクタおよびそのタスクを再起動できるようになりました。従来は障害時にコネクタを削除して作り直す必要がありダウンタイムと運用コストが発生していましたが、本機能により以下が可能になります。

  • コネクタ全体の再起動（コネクタと全タスクを再初期化）
  • 失敗したタスクのみの再起動（影響範囲を限定）
  • 失敗していないコネクタの再起動（外部システムの一時的不整合回復や設定変更の反映） 再起動操作はAmazon MSK Console、AWS CLI、AWS SDK、およびAWS CDKから実行でき、MSK Connectが提供されている全リージョンで追加料金なしに利用できます。運用上は再起動でコネクタのライフサイクルが再初期化されるため、接続先や認証情報、タスク構成が正しく整っていることを確認したうえで実行します。詳細は公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Kafkaコネクタを運用するデータエンジニア、SRE、プラットフォームチーム
  • 利用シーン: コネクタやタスクの障害復旧、外部システム変更後の再同期、一時的な接続エラーからの回復
  • 運用効果: コネクタ削除／再作成の不要化によりダウンタイムと運用負荷を低減し、復旧時間を短縮
  • コスト: 再起動機能自体に追加料金は発生しません（ただし再処理に伴うデータ転送や downstream の処理コストは別途発生する可能性あり）
  • リージョン: Amazon MSK Connect が利用可能な全リージョンで提供

技術的な注意点 ​

  • IAM権限: 再起動を実行するためのMSK Connect関連の適切なIAM権限（Console/CLI/SDKでの実行権限）を付与してください
  • CLI/SDK/CDK: 再起動操作はコンソールだけでなくAWS CLI、AWS SDK、およびAWS CDKからも実行可能です（各ツールでの最新API/コマンド名を公式ドキュメントで確認してください）
  • 動作上の注意: 再起動によりタスクは再初期化されるため、インプレースでの処理の再試行やデータの重複処理が発生する可能性があります。コネクタ固有のオフセット管理や冪等性の仕様を事前に確認してください
  • 監視/ログ: 再起動実行時および後はCloudWatchログ／メトリクスやコネクタのステータスを監視し、正常に再稼働していることを確認してください
  • 外部依存: 再起動前に接続先システム（認証情報、ネットワークアクセス、外部APIなど）が利用可能であることを確認してください
  • コスト管理: 再処理に伴う転送/処理コスト増加の影響を考慮し、必要に応じて運用手順に組み込んでください

参考情報 ​

[Appstream 2 0] Amazon WorkSpaces Applications is now available in three new AWS Regions ​

概要 ​

Amazon WorkSpaces Applicationsがヨーロッパ（チューリッヒ）、アジアパシフィック（大阪）、カナダ西部（カルガリー）の3リージョンで利用可能になりました。これにより、エンドユーザーに近いリージョンでアプリ配信でき、応答性向上やデータレジデンシ要件への対応が容易になります。

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

Amazon WorkSpaces Applicationsはフルマネージドのアプリケーション/デスクトップストリーミングサービスで、今回の拡張によりEurope (Zurich)、Asia Pacific (Osaka)、Canada West (Calgary)でのデプロイと配信が可能になりました。サービスはAWS上でホストされるアプリケーションとデスクトップをユーザーにストリーミングし、クライアント側でのインストールや管理を不要にします。WorkSpaces Applicationsは必要なAWSリソースを管理し、自動でスケールし、オンデマンドでユーザーにアクセスを提供します。利用開始はWorkSpaces Applications管理コンソールにサインインし、対象リージョンを選択するだけです。料金体系は従量課金（pay-as-you-go）で、詳細は公式の価格ページを参照してください。利用可能リージョンのフル一覧はAWSリージョンテーブルで確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: エンドユーザー向けにアプリ配信を行うアプリケーションオーナー、VDI/仮想化担当、SRE/クラウド運用チーム
  • 利用シーンまたは効果: エンドユーザーに近いリージョンでアプリを配信することでレイテンシ低減・応答性改善、欧州/アジア/カナダのデータレジデンシやコンプライアンス要件への対応が容易になる
  • 運用効果: マネージドサービスによる運用負荷低減、自動スケーリングでピーク時対応が容易になり、オンデマンドでのユーザー提供が可能

技術的な注意点 ​

  • リージョン制限: 本拡張は Zurich (Europe)、Osaka (Asia Pacific)、Calgary (Canada West) に追加。ただし全リージョンで未対応の機能やローカル規制が存在する可能性があるため、利用前にAWSリージョンテーブルで提供状況を確認してください
  • IAM権限: WorkSpaces Applicationsの管理操作やリソース作成には対応するIAM権限が必要です。最小権限の役割/ポリシーを適用して運用してください（コンソールでの操作権限、VPC/EC2/Elastic Load Balancing等の作成権限など）
  • ネットワーク: アプリ配信のためにVPC、サブネット、セキュリティグループ、必要に応じてNATやインターネット接続が必要です。ネットワーク設計はレイテンシとセキュリティ要件に応じて構成してください
  • データ転送とコスト: WorkSpaces Applications自体は従量課金ですが、関連するEC2、ストレージ、データ転送（リージョン間やインターネット）など追加コストが発生する可能性があります。費用見積りはワークロードと接続パターンを考慮してください
  • コンプライアンス/データレジデンシ: 新リージョンによりデータの地理的配置が柔軟になりますが、各国・業界の規制に従い設計・監査を行ってください
  • 互換性/機能差異: 一部リージョンでは提供機能や統合サービスに差異がある場合があるため、導入前に公式ドキュメントで機能一覧・制限を確認してください

参考情報 ​

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

Copyright © 2026