Cloud

概要 AWSは9月22日、生成AIおよびエージェント型ワークロード向けの新しい統合可観測性サービス「Amazon CloudWatch Omni」の一般提供を開始した。エージェント型AIは非決定的な振る舞いをするため、レイテンシやエラー率といった従来型のモニタリング指標だけでは応答品質の劣化を検知できないという課題があった。CloudWatch Omniはこの課題に対応するため、開発者がローカルのIDEで直接トレースを確認できる層と、オペレータが専用のWeb UIで本番環境を監視する層の二層構造を採用している。 主な機能 開発体験の中心となるのがIDE統合で、VS CodeとKiro向けにネイティブ拡張機能を提供する。コマンドパレット(Command + Shift + P)からプロジェクトを作成でき、AWSアカウントがなくても無料で使い始められる点が特徴だ。実際にBedrockを利用する段階になって初めて認証情報が必要になる。トレース機能では、LLM呼び出しやツール実行、推論といったエージェントの各ステップを階層的なタイムラインとして記録し、比較モードで異なるプロンプト間の挙動差を並べて検証できる。評価面では、一貫性(Coherence)、有用性(Helpfulness)、忠実性(Faithfulness)、ルーティング正確性(Routing correctness)などを含む17種類の組み込み評価器を搭載し、従来の指標では見逃されがちな品質低下を捕捉する。さらにプレイグラウンド・実験機能では、異なるシステムプロンプトやモデル構成をリアルタイムで比較テストでき、実験ビューでは同一データセットに対する複数エージェントのスコア、レイテンシ、トークン使用量を並列評価できる。 対応フレームワークと標準 CloudWatch OmniはLangChain、LangGraph、CrewAI、OpenAI SDK、Strands、Vercel AI SDK、Amazon Bedrock AgentCoreに対応し、PythonとTypeScriptの両方をサポートする。計装にはOpenInferenceとAWS Distro for OpenTelemetry(ADOT)という標準規格を採用しており、これにより、Lambda、ECS、EKSなど複数のデプロイ環境で既に計装・利用可能な設計となっている。プロンプトのバージョン管理、回帰テスト、マルチターン会話の分析、エージェントアーキテクチャの可視化といった用途を想定している。 今後の展望 AWSのブログ記事はDaniel Abib氏の執筆によるもので、まずは開発時点でのデバッグ体験向上に焦点を当てたIDE拡張機能を無料で提供することで、エージェント開発者への浸透を図る狙いがうかがえる。OpenInferenceやADOTといったオープンな計装標準を採用したことで、特定のフレームワークやデプロイ環境に縛られない可観測性基盤としての拡張が見込まれる。生成AIアプリケーションの本番運用が広がる中、非決定的な出力品質を継続的に監視・評価する仕組みへの需要は今後さらに高まるとみられ、CloudWatch Omniはその中核ツールの一つとなる可能性がある。

概要 Googleは、自律型AIエージェントの実行とスケーリングを担うオーケストレーター「AX」をApache 2.0ライセンスでオープンソース公開した。AXはGoogleの「Agent Substrate」上で動作し、エージェントを従来のマイクロサービスのようにではなく、状態を保持し続ける「ステートフルアクター」として扱う点が最大の特徴だ。Kubernetesの設計思想を色濃く受け継いでおり、Task（実行ライフサイクル）、Workspace（環境構築）、Gateway（ネットワークセキュリティ）、Model（LLMパラメータ管理）という4つの宣言型プリミティブを、ax.io/v1alpha1というAPIグループの下でKubernetesのCRD（カスタムリソース定義）さながらに提供する。ユーザーはax applyのようなkubectlライクなコマンドでこれらのリソースを操作できる。 gVisorサンドボックスとサブ秒復帰によるコスト最適化 AXの技術的な核心は、gVisorによるサンドボックス分離と、サブ秒単位のタスク一時停止・再開機能にある。各エージェントセッションは隔離された「アクターサンドボックス」として実行され、CPUとメモリに厳密なリソース境界が設定されることで、障害や誤動作が及ぼす影響範囲（ブラスト半径）を抑え込む設計だ。さらに、エージェントがモデル推論の応答待ちやツール呼び出しの完了待ちといったアイドル状態に入ると、実行状態がチェックポイントとして保存され一時停止する。再開時にはコールドスタート遅延がほぼゼロのサブ秒間隔で復帰できるため、数十のタスクを少数の共有ホストワーカー上に多重化することが可能になる。従来型のKubernetes運用では、アイドル中も専用サンドボックスを起動したままにしておく必要がありコンピュートリソースが無駄になりがちだったが、AXのこの仕組みはモデルAPIや人間の判断待ちで長時間アイドル状態になりやすいエージェントワークロード特有の無駄を大きく削減できるとされる。 位置づけと運用面への懸念 AXは、LangGraphやCrewAIのようなアプリケーションレベルの高水準オーケストレーターとは異なり、より低レイヤーの「基盤実行ランタイム」として位置づけられている。想定利用者も個人開発者というよりは、大規模かつ長時間稼働するエージェント群を管理する必要があるエンタープライズだ。一方で技術コミュニティからは、Kubernetesクラスタやコンテナレジストリ、koによるCRD管理を前提とすることへの懸念も上がっている。Googleが掲げる「エルゴノミックなワークフロー」という謳い文句に対し、実際の導入・運用に伴う複雑性を疑問視する声だ。エグレスプロキシ接続のドロップや、シークレット管理機能がまだ初期段階にとどまっている点も課題として指摘されている。 今後の展望 こうした課題を抱えつつも、AXは自律型AIエージェントを本番環境で大規模運用するための「本質的なコンピュートプリミティブ」として位置づけられている。エージェントワークロードの実行基盤という新しい領域において、Kubernetesが果たしてきた役割をAIエージェント向けに再構築しようとする試みであり、今後エンタープライズでの採用が進むかどうかは、運用オーバーヘッドの解消とセキュリティ機能の成熟度にかかっていると言えそうだ。

概要 AWSは9月19日、AWS Lambda Managed Instancesにおける関数実行時間の上限を、従来の15分から90分へと6倍に拡張したと発表した。これまでLambdaの実行時間制限は、メディア処理や大規模なAI推論バッチ処理、金融計算、データ処理・ETL、Webスクレイピングや大容量ファイル転送といった長時間ジョブをサーバーレスで扱う際の大きな障壁となっていた。今回の拡張により、こうしたワークロードもLambdaの枠組みの中で実行できるようになり、サーバーレスの適用範囲が長時間実行タスクへと広がる動きの一環と位置づけられている。 Lambdaの実行形式と今回の変更点 今回拡張されたのは、あくまでLambda Managed Instancesという実行形式に限られる点に注意が必要だ。AWS Lambdaは現在、用途に応じて複数の実行形式を提供している。従来からのイベント駆動型の同期リクエストは引き続き15分の上限のままで変更はない。長時間実行に対応するMicroVM形式では最大8時間まで実行可能だ。そして今回上限が引き上げられたManaged Instancesは、複数リクエストを処理できる定常状態ワークロード向けの形式であり、その上限が15分から90分に拡大された。なお、同時期にLambda Managed InstancesはGraviton5対応のEC2インスタンスのサポートも開始しており、性能面での強化も並行して進められている。 長時間実行がもたらす技術的な注意点 AWSは実行時間の延長に伴い、開発者に対して長時間実行関数特有の注意点を強調している。具体的には、ネットワーク接続の維持、一時的な認証情報の有効期限管理、そして処理の重複実行への対策に細心の注意を払う必要があるとしている。特に決済処理やデータベースへの書き込みのように、重複実行が業務上の不整合につながりかねない処理については、べき等性(idempotency)の担保が必須となる。AWSはこのための実装手段として「Powertools for AWS Lambda」の活用を推奨しており、重複実行が発生しても一貫した結果を保証できるようにする設計上の配慮を求めている。 今後の展望 今回の拡張は、単なる数値上の上限緩和にとどまらず、サーバーレスコンピューティングが従来の短時間・イベント駆動型のユースケースから、より長時間かつ状態を伴う処理領域へと適用範囲を広げていく流れを象徴する動きといえる。AI推論バッチのように処理時間が読みにくいワークロードや、大容量データを扱うETL処理などは、これまでコンテナやEC2インスタンスの管理が必要だったが、Lambda Managed Instancesの活用によって運用の簡素化が期待される。一方で、べき等性や認証情報の管理といった長時間実行特有の設計上の考慮事項も増えるため、移行にあたっては既存のイベント駆動型Lambda関数とは異なる設計指針が求められることになりそうだ。

概要 NVIDIAが出資する英ロンドン発のAIクラウド企業Nscaleが、ティッカー「NSCL」でニューヨーク証券取引所への上場を申請した。目標とする評価額は約300億ドルで、2026年3月時点の146億ドルから倍増する水準となる。主幹事はGoldman Sachs、JPMorgan、Morgan Stanleyの3社が務める。申請書類によれば、2026年上半期の売上高は前年同期の1,040万ドルから1,252%増の1億4,060万ドルへ急拡大した一方、純損失も前年同期の3億6,890万ドルから10億2,010万ドルへと大幅に膨らんでいる。同社は再登記を経て「Nscale plc」として上場する見込みで、CEOはJosh Payneが務める。 事業モデルと主要契約 Nscaleは発電、モジュール式液冷データセンター、GPUオーケストレーション、クラウドソフトウェアまでを自社で垂直統合するAIハイパースケーラーで、長期のテイク・オア・ペイ契約によって収益の安定性を確保するビジネスモデルを採る。世界14リージョンで事業を展開し、電力パイプラインは10ギガワット以上に達する。中核資産の一つが、2026年3月にAIPCorpの買収を通じて獲得した米ウェストバージニア州の「Monarch Compute Campus」で、同キャンパスはグロス発電容量で8ギガワット超まで拡張可能な計画を持つ。契約実績も急拡大しており、2026年8月末時点の契約総額(TCV)は1,034億ドルに達し、2025年末時点の380億ドルから大幅に積み上がった。主要顧客としては、同キャンパスでのデータセンターサービスに関して450億ドル規模の契約を結んだAnthropicと、ヒューマノイドロボティクス向けに複数年の展開契約を結んだFigure AIが挙げられており、最大顧客1社だけで上半期売上高の52%を占める。今後はMicrosoftとAnthropicが主要顧客としてさらに拡大する見通しも示されている。 財務基盤と資金調達 2026年8月末時点でNscaleの総資産は172.5億ドル、総負債は123.6億ドル、株主資本は47.9億ドルとなっている。資金調達面では、NVIDIAからの10億ドル出資を含む総額31億ドル規模の転換ローン(convertible bonds)パッケージを組成しており、急拡大するデータセンターや電力インフラへの投資を支えている。急速な事業拡大に伴う損失拡大と資本集約的な事業モデルは、AIインフラ企業に共通する構図であり、今回の上場でどこまで市場の評価を得られるかが注目される。 市場環境と今後の見通し アナリストのMatt Kennedy氏は今回の案件について「AIインフラを巡る環境は取引を成立させるには十分だが、数カ月前のような熱狂とはまるで違う」と指摘し、AI関連銘柄への投資家の姿勢が以前より慎重になっていることを示唆した。株式の発行株数や想定価格帯といった詳細は、今後提出される追加のSEC申請書類で明らかになる見通しだ。AIインフラ投資の持続可能性を測る試金石として市場の注目を集めそうだ。

概要 AWSは9月18日、Amazon Bedrock AgentCoreの次世代ランタイム(V2)を一般提供開始したと発表した。AIエージェントを実行するためのこのランタイムは、コンテナイメージのサイズや同時実行数によらず一貫して高速なコールドスタートを実現する点が最大の特徴で、P75のコールドスタート時間を1.9〜2.0秒まで短縮した。従来のV1では5.4〜30秒かかっていたため、最大で約93%の短縮となる。あわせて、実際のワークロードに応じてメモリを動的に確保・解放する弾力的なメモリ管理も導入し、ピーク使用量ではなく実使用分のみに課金される仕組みへと改めた。利用可能リージョンはus-east-1、us-east-2、us-west-2、eu-west-1、ap-northeast-1の5リージョン。 技術的な詳細 コールドスタート短縮の鍵となっているのは、エージェント実行環境を事前に一度準備してスナップショットを作成しておき、新しいインスタンスの起動時にはそのスナップショットから復元するという方式だ。この仕組みにより、200MBから2GBまで幅のあるコンテナイメージサイズや、同時実行数の多寡に関わらず、安定して短いコールドスタート時間を維持できるという。メモリ管理面では、小規模な効率的なプロファイルでインスタンスを起動し、ワークロードの負荷に応じて必要なメモリを動的に割り当て、不要になった分は回収するモデルを採用した。これにより開発者はピーク時を見込んだ過剰なメモリ確保をあらかじめ行う必要がなくなり、コストを実際の使用量に連動させられる。なお、AgentCore Runtime本来の特徴であるサーバーレス性――事前プロビジョニング不要、ゼロへのスケーリング、ハードウェアレベルで強制されるセッション分離――はV2でも維持されている。 利用方法と展望 既存または新規のランタイムでV2を利用するには、作成時または更新時にplatformVersionをV2に設定するだけでよく、移行の手間は比較的小さい。コールドスタートの短縮とコストの最適化は、リアルタイム性が求められる対話型AIエージェントや、負荷が変動しやすいワークロードにとって特に有効に働くと見られる。AWSはAgentCoreを通じてAIエージェントの本番運用基盤としての完成度を高めており、今回のV2投入により、エージェント基盤の性能面での競争力をさらに強化する狙いがあるとみられる。

概要 Google、Nvidia、Anthropicらは9月16日、電力網最適化スタートアップのEmerald AIとともに、データセンター向け電力の需給を柔軟に調整する業界連合「AI Energy Management Alliance(AEMA)」の発足を発表した。Emerald AI創業者のVarun Sivaram氏が主導し、National Grid、AES、Constellation、NRG Energyといった電力会社を含む約18〜20社規模の連合となる。狙いは、新規の発電設備増強に頼らずとも、既存の電力網から最大100ギガワット相当の新たなデータセンター容量を生み出すことだ。AI需要の急増により米国内では電力網への接続待ち時間が10年以上に及ぶケースも出ており、電力不足が新設データセンールの最大の制約要因になっている中での取り組みとなる。 需要応答という発想 AEMAが柱に据えるのは「デマンドレスポンス(需要応答)」と呼ばれる仕組みだ。電力網がピーク需要を迎えた際、データセンター側が優先度の低い計算タスクを一時的に停止したり、電力に余裕のある他拠点へ計算負荷をシフトしたりすることで、系統電力への負荷を抑える。バッテリーやオンサイト発電と組み合わせることで、非常時のバックアップとして使われてきたディーゼル発電機に頼らない、より環境負荷の低い対応が可能になるという。Emerald AIはユーティリティ企業とデータセンターを直接つなぐ技術を持ち、バッテリーのように素早く需要調整に応じられる点を強みとする。同社はEnergize CapitalとDCVCが主導するシリーズAで1億5000万ドルを調達済みだ。 Fortuneの報道によれば、現在の電力網の平均利用率はおよそ50%にとどまる。コンサルティング会社Brattle Groupの試算では、利用率が10ポイント向上すれば電気料金は約3.4%低下するとされ、データセンターの負荷調整が地域社会の電気料金抑制にもつながりうると位置づけられている。Googleはすでに約1ギガワット規模の需要応答ポートフォリオを運用しており、バージニア州ではNVIDIA、Digital Realty、Emerald AIが年内にほぼ100メガワット規模のプロジェクトを稼働させる予定だ。一方でGoldman Sachsの試算では、電力網利用率を90%に制限するだけでも76ギガワットの容量を解放できるとされており、AEMA参加各社が掲げる100ギガワットという目標の規模感を裏付けている。ただしEmerald AIの最高科学責任者は、需要応答だけで新規電源開発の必要性が完全になくなるわけではないとも釘を刺している。 政策動向と今後の見通し 米連邦エネルギー規制委員会(FERC)は6月、電力使用に一定の制限を受け入れる大口顧客について、電力網への接続をより迅速に認める方針を打ち出した。テキサス州の電力網運営機関は同様の柔軟な接続ルールを策定中であり、カリフォルニアの自治体電力事業者シリコンバレー・パワーはすでに全米初の柔軟接続プログラムを展開しており、AEMAはこうした規制・実務双方の潮流に乗る形だ。データセンターが「電力網の良き市民」として振る舞い運用方法を変える見返りに、より速い電力アクセスを得られるという発想は、AI関連投資の急拡大と電力インフラの整備ペースとのギャップを埋める現実的な解として、今後さらに参加企業や採用事例が広がるかが注目される。

概要 Microsoftの企業向けAI開発プラットフォーム「Azure AI Foundry」（現Microsoft Foundry）に、CVSS基本値で最大深刻度となる10.0を記録する脆弱性CVE-2026-85889が発見された。根本原因は「重要な機能における認証の欠如」(CWE-306)で、有効な認証情報を持たない攻撃者がネットワーク経由でバックエンドの特定機能に到達し、悪用できる状態にあった。攻撃には特別な権限やユーザーの操作が不要で、複雑度も低いとされ、悪用に成功すれば権限昇格につながる恐れがあった。発見・報告したのはセキュリティ研究者のRémy Marot氏(@R_Marot)で、2026年9月17日に情報が公開された。 影響範囲と深刻さ Azure AI Foundryは、企業が生成AIアプリケーションやAIエージェントを構築・デプロイ・管理するためのプラットフォームであり、モデルのホスティングやトレーニングデータ、各種システムとの統合機能を提供している。今回の脆弱性が悪用された場合、こうした企業のAIモデルや学習データ、連携する周辺システムへの不正アクセスにつながりかねない性質のものだった。CVSS10.0という評価は、攻撃元がネットワークであること、攻撃条件の複雑さが低いこと、事前の権限やユーザー操作が不要であることなど、悪用のハードルの低さを反映している。 対応状況 Microsoftはこの脆弱性についてサーバー側(バックエンドインフラ)で修正を既に完了しており、Azure AI Foundryはクラウドベースのサービスであるため、顧客側での追加のパッチ適用や設定変更といった対応は不要としている。現時点で野生での悪用の証拠や、悪用を実証するPoC(概念実証)コードの存在は確認されていない。もっとも、CVSS10.0という評価が示す通り、認証不要で権限昇格が可能な脆弱性がクラウドAI基盤に存在していたこと自体は、企業が利用するマネージドAIサービスであっても深刻な設計・実装上の不備が起こり得ることを改めて示す事例といえる。今後同種のサービスを利用する企業は、ベンダー側の修正が完了した後も、自社の統合設定やアクセス権限の棚卸しを行うことが望ましいだろう。

概要 PlanetScaleは、PostgreSQL向けにシャーディングを自動化する新しいデータベースサービス「Neki」のプレビュー版を公開した。YouTubeが開発した分散データベースミドルウェア「Vitess」に着想を得た設計で、PostgreSQLを大規模にスケールさせる際の複雑さを大幅に軽減することを狙っている。公開されたベンチマークでは、約1.4ペタバイト規模のデータを512シャードに分割した構成で、最大118,538,803クエリ/秒(QPS)という性能を記録したとしている。 アーキテクチャの特徴 Nekiの中核を担うのが「Nekiルーター」だ。Postgresのクエリパーサーを備え、受け取ったSQLを解析して分散クエリプランを作成し、複数シャードにまたがるクエリをバッファリングしたうえで各シャードからの結果を集約する役割を果たす。各シャードはPostgreSQL自体で構成され、プライマリ1台とレプリカ2台以上を異なるアベイラビリティゾーンに配置することで可用性を確保する。ベンチマークではこのシャード数を増やすにつれてほぼリニアにスループットが向上したとされ、水平スケーラビリティの高さを示す結果となった。 既存資産との互換性と導入のしやすさ Nekiは標準的なPostgresプロトコルで接続でき、既存のPostgreSQL用ドライバーやツールをそのまま利用できる点も特徴だ。これにより、アプリケーション側の大きな変更なしに移行できることを想定している。運用面では、最初は単一構成の通常のPostgreSQLとして始め、負荷が増大した段階でシャーディング構成へ段階的に移行できる設計になっており、小規模な利用から大規模運用まで同じサービス上で継続的にスケールさせられる点が、Vitessの思想を踏襲した狙いだと言える。 今後の展望 PostgreSQLは単一ノードでの運用を前提とした設計が根強く、大規模なシャーディングは従来アプリケーション側での実装や専用ミドルウェアの導入が必要とされてきた。Nekiはこの部分をマネージドサービスとして提供することで、MySQL向けのVitessが切り開いたような「透過的シャーディング」の恩恵をPostgreSQLエコシステムにもたらそうとする試みであり、プレビュー公開後の実運用での性能や信頼性の検証が今後の焦点になりそうだ。

概要 マルチクラスタ・マルチクラウド対応のKubernetesオーケストレーションプロジェクト「Karmada（Kubernetes Armadaの略）」が、CNCF（Cloud Native Computing Foundation）における最高成熟度レベルの「Graduated」ステータスに到達したと発表された。発表は中国・上海で開催された「KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China」の場で行われ、最新版v1.19のリリースと時を同じくしている。CNCFのGraduatedは「広く採用され、本番運用に耐える安定したプロジェクト」に与えられる位置づけで、Karmadaは2021年9月にSandboxへ参加、2023年12月にIncubatingへ昇格し、第三者によるセキュリティ監査、正式なステアリング委員会の設置、CNCF行動規範の採用、CII Best Practices Badgeの取得といった卒業要件を満たして今回の到達に至った。現時点でコントリビューターは292組織から1,214人以上、GitHubスターは5,600を超えており、エコシステムとしての広がりを示している。 技術的な特徴とアーキテクチャ KarmadaはKubernetesの標準APIを置き換えるのではなく、そのまま複数クラスタに拡張する設計を採る点が最大の特徴で、既存のマニフェストやコントローラ、ツール群を変更せずに利用できる。コントロールプレーンはKarmada API Server、Karmada Controller Manager、Karmada Schedulerの3コンポーネントから構成され、内部的にはCluster Controller（メンバークラスタのライフサイクル管理）、Policy Controller（PropagationPolicyオブジェクトの処理）、Binding Controller（クラスタごとのWorkオブジェクト生成）、Execution Controller（メンバークラスタへのマニフェスト適用）という4つのコントローラが伝播処理を担う。主要APIとしては、クラスタアフィニティやリージョン・ゾーン・プロバイダをまたいだ多次元の高可用性、マルチクラスタ分割などのスケジューリング制約を定義する「PropagationPolicy」と、リソーステンプレート自体は変更せずにイメージのプレフィックスやStorageClassなどクラスタ固有の設定を上書きできる「OverridePolicy」がある。今回卒業と同時にリリースされたv1.19では、AIトレーニングジョブ向けのマルチコンポーネントスケジューリングが強化されたほか、優先度ベースのスケジューリング機能がBetaに昇格しデフォルトで有効化されており、リージョンやプロバイダをまたいだ分散GPU/CPUオーケストレーションの課題に対応する。観測性の面ではコントロールプレーンの各コンポーネントからPrometheusメトリクスを出力し、Helmチャートも提供されるなど、既存のCNCFエコシステムのツール群にそのまま組み込める点も特徴である。 本番採用の広がりと競合との違い Bloomberg、Wellhub、Alibaba Cloud、Huawei、Trip.com、Bilibili、iFLYTEK、JDCloud、Kuaishou、RedNote、SenseTime、Vivo、WPS、ZTOなど、多岐にわたる企業がハイブリッドクラウドの容量確保、リージョンをまたいだ耐障害性の確保、AIワークロード向けのGPU/CPUスケジューリング、複数クラスタにまたがる設定の一括配布といった目的でKarmadaを本番導入している。Trip.comの担当者は「既存のKubernetesリソース定義を変更することなく」複数クラスタにまたがる統一的なリソースプール運用を実現し、クラスタ横断の弾力的なスケーリングとフェイルオーバーを可能にしたと述べている。Karmadaは、廃止されたKubeFed(Federation v2)の後継として位置づけられる2つのCNCFプロジェクトの一つで、もう一方のOpen Cluster Management(OCM)がハブ・アンド・スポーク型のエージェントベースでクラスタインベントリやガバナンスに重点を置くのに対し、Karmadaはワークロードの配置と動的スケジューリングに重きを置き、クラスタ横断クエリ向けのキャッシュ層やマルチクラスタサービスディスカバリを備える点で差別化されている。クラスタのライフサイクル管理を担うCluster APIや、Argo CDのApplicationSets、Rancher FleetといったGitOpsツール、Microsoft Azure Kubernetes Fleet Managerの基盤であるKubeFleetなども関連技術として挙げられており、マルチクラスタ運用領域では複数のアプローチが並立している状況がうかがえる。 今後の展望 CNCFにおけるGraduatedステータスへの到達は、マルチクラスタ・マルチクラウド運用がKubernetesエコシステムの周辺的なユースケースから、企業の本番基盤における標準的な選択肢の一つへと成熟しつつあることを示している。特にAIワークロードの急増に伴い、複数クラスタにまたがるGPU/CPUリソースの効率的なスケジューリングへの需要は今後も高まると見られ、v1.19で強化された優先度ベースのスケジューリングやマルチコンポーネントスケジューリングは、そうした需要を先取りする形での機能強化と言える。今回の卒業により、KubeFedの後継技術を巡る評価も一段落し、既存の大規模採用企業に加えて、より幅広い業種・規模の組織がマルチクラスタ運用基盤の選定においてKarmadaを有力な候補として検討する動きが進むことが予想される。

概要 AWSは9月17日、2026年3月にイラン革命防衛隊のドローン攻撃を受けたUAE(me-central-1)とバーレーン(me-south-1)のデータセンターについて、一部データが恒久的に復旧不可能になったと発表した。クラウド基盤が物理的な軍事攻撃によって永久的なデータ損失に至った前例のない事態であり、攻撃発生から約6カ月を経ての公表となる。米国とイスラエルによる軍事作戦への報復として実施された攻撃で、革命防衛隊はAmazonが米国に拠点を置く企業であり、当該施設が敵対勢力の軍事・諜報活動を支援していると判断し攻撃対象に選定したとされる。 被害の詳細 UAEリージョンでは3つのアベイラビリティーゾーンのうち「mec1-az2」が施設への直接攻撃を受け、構造的損傷や電力供給の途絶に加え、消火活動に伴う水損も発生し、当該ゾーンのデータは復旧不可能と判定された。残る「mec1-az1」「mec1-az3」は復旧作業が続いているが、再開の見通しは立っていない。単一ゾーンのみにリソースを配置していた顧客のデータが失われた一方、複数ゾーンに分散させていた顧客は被害を免れたとみられる。バーレーンのリージョンはさらに深刻で、複数のアベイラビリティーゾーンにまたがる損害が冗長化設計の許容範囲を超え、リージョン全体がオフラインとなった。加えて2026年4月には2つ目のアベイラビリティーゾーンを破壊する追加攻撃も発生していた。 AWSの対応と顧客への影響 AWSは当該中東リージョンの課金を停止するとともに、顧客に対して別リージョンへのデータ移行を強く促してきた。同社によれば、大半の顧客は永久的なデータ損失が確定する前にバックアップの活用や代替手段の実装によって既に移行を済ませていたという。今後の更新について、UAEは数カ月以内、バーレーンは2027年初頭を目処に続報を出すとAWSは表明している。 今後の見通し 今回の事態は、クラウドサービスの可用性設計が前提としてきた「同一リージョン内の複数アベイラビリティーゾーンによる冗長化」が、物理的な軍事攻撃という想定外の脅威の前では十分に機能しない場合があることを示した。中東地域では緊張の高まりが続いており、AWSをはじめとするクラウド事業者のインフラへのさらなる攻撃リスクも指摘されている。企業がクラウド基盤の地理的分散や災害復旧計画を見直す契機として、業界全体への影響が注視される。