生成日時: 2026年10月07日 対象期間: 過去 24 時間以内 処理モード: 詳細モード 更新件数: 5 件
公開日時: 2026年10月06日 22:37:54 UTC リンク: Retirement: Pod name dimension in AKS pod platform metrics
アップデートID: 570232 情報源: Azure Updates API
カテゴリ: Compute, Containers, Azure Kubernetes Service (AKS), Retirements
要約:
【何が更新されたか】
Azure Kubernetes Service（AKS）のプラットフォームメトリックにおいて、「Pod name」ディメンションのサポートが2027年9月30日をもって終了します。
【主な変更点や新機能】
これまでAzure Monitorのプラットフォームメトリックでは、Podごとの名前（Pod name）をディメンションとして利用できましたが、今後はPod名による詳細なメトリック取得ができなくなります。対象となるメトリックは「kube_pod_status_phase」などのPodカウンターで、今後はPodごとの集計値（aggregate pod counters）に移行します。
【影響を受ける対象】
AKS環境でAzure Monitorを利用し、Pod名単位でメトリックを取得・監視している技術者やシステムが影響を受けます。Pod名による粒度での監視やアラート設定を行っている場合、今後は集計値ベースでの対応が必要となります。
【注意点】
2027年9月30日以降、Pod名ディメンションを利用したメトリック取得や監視はできなくなります。監視設計やダッシュボード、アラート設定などの見直しが必要です。今後は集計値を活用した監視方法への移行を検討してください。
詳細:
2027年9月30日より、Azure Kubernetes Service（AKS）におけるAzure Monitorプラットフォームメトリックの「Pod name dimension」のサポートが廃止されます。このアップデートの背景には、メトリックの管理効率化と集約的な監視手法への移行があり、個々のPod名に基づく詳細なメトリック収集から、Podの状態ごとに集計されたカウンターへの移行が目的となっています。具体的には、「kube_pod_status_phase」などのメトリックでPod名をディメンションとして利用することができなくなり、今後はPodのフェーズ（Running、Pending、Succeeded、Failedなど）ごとに集計されたPod数をカウンターとして取得する形に変更されます。
技術的な仕組みとしては、これまでAzure Monitorは各Pod名をディメンションとしてメトリックデータを保持していましたが、今後はPod名を識別子として利用せず、Podの状態ごとに集計された数値のみを提供する形になります。これにより、メトリックの粒度が粗くなりますが、監視データのスケーラビリティやパフォーマンス向上が期待されます。実装方法としては、既存のメトリッククエリやダッシュボードでPod名を利用している場合、今後はPod名を用いたフィルタリングや分析ができなくなるため、集計カウンターを活用した監視設計への変更が必要です。
活用シナリオとしては、Podの状態ごとの全体数を把握することで、クラスタの健全性やリソース状況を効率的に監視することが可能です。例えば、異常な数のFailedやPending状態のPodが発生した場合、集計カウンターを用いて迅速に検知し、対応策を講じることができます。ただし、個々のPod名に基づく詳細なトラブルシューティングや特定Podの挙動分析には制限が生じるため、必要に応じて他の監視手法やログ分析を併用することが推奨されます。
注意点としては、Pod名ディメンションの廃止に伴い、既存の監視設定やアラートルール、ダッシュボード構成の見直しが必要となります。特に、Pod名を基準としたアラートやレポートを利用している場合は、集計カウンターへの移行に合わせて設定変更を行う必要があります。また、Azure Monitor以外の監視ツールやサービスとの連携についても、Pod名ディメンションの廃止による影響を事前に確認しておくことが重要です。
関連するAzureサービスとしては、Azure Monitorが中心となりますが、Log AnalyticsやApplication Insightsなどの他の監視・分析サービスと連携する際にも、Pod名ディメンションの廃止によるデータ構造の変更が影響する可能性があります。今後は、集計カウンターを活用した監視設計や、必要に応じてログベースの詳細分析を組み合わせることで、AKS環境の運用管理を継続的に最適化していくことが求められます。
公開日時: 2026年10月06日 18:24:43 UTC リンク: Retirement: Azure App Service on Azure Stack Hub
アップデートID: 568178 情報源: Azure Updates API
カテゴリ: Compute, Mobile, Web, Hybrid + multicloud, App Service, Azure Stack Hub, Retirements
要約:
何が更新されたか
Azure App Service on Azure Stack Hubのサービスが2029年9月30日にリタイア（提供終了）されることが発表されました。
主な変更点や新機能
2026年9月30日以降、新規インストールのサポートが終了し、新しいプロダクトリリースや機能追加、機能強化は行われなくなります。既存のサポート対象デプロイメントについては、リタイアまでサポートが継続されます。
影響を受ける対象
Azure Stack Hub上でAzure App Serviceを利用しているすべてのユーザーおよび組織が対象です。新規導入を検討している場合も、2026年9月30日以降は導入できなくなります。
注意点
既存環境の運用継続は可能ですが、2029年9月30日以降は完全にサポートが終了します。今後のアプリケーション運用や移行計画を早めに検討する必要があります。新規導入や機能拡張を予定している場合は、他のサービスへの移行も視野に入れてください。
詳細:
Azure App Service on Azure Stack Hubは、2029年9月30日をもってサービス提供が終了します。このアップデートは、Azure Stack Hub上で稼働するApp Serviceの長期的な運用計画に関する重要な変更を示しています。背景として、Azure Stack Hubはオンプレミス環境やハイブリッドクラウド構成においてAzureのサービスをローカルで利用可能にするプラットフォームですが、App Serviceの提供終了は、今後の製品戦略や技術的進化に伴うものです。
具体的な変更内容として、2026年9月30日以降は新規インストールがサポートされなくなり、以降は新しい製品リリースや機能追加、機能強化が行われません。既存のサポート対象デプロイメントについては、2029年9月30日まで利用可能ですが、それ以降は完全にサービスが終了します。技術的な仕組みとして、Azure App Service on Azure Stack Hubは、AzureのWebアプリケーション、API、モバイルバックエンドなどをオンプレミス環境でホストするためのサービスであり、Azure Stack Hubのリソース管理やネットワーク構成と連携して動作します。
活用シナリオとしては、法規制やデータ主権の要件によりクラウドへのデータ移行が難しい場合や、レイテンシの低減を目的としたローカル運用が求められるケースで利用されてきました。また、Azure App Service on Azure Stack Hubは、Azure Active DirectoryやAzure Monitor、Azure DevOpsなどの関連サービスと連携し、ハイブリッドクラウド環境におけるアプリケーション開発・運用を支援していました。
注意点として、2026年以降は新規インストールが不可となるため、既存環境の維持や移行計画の策定が必要です。さらに、サービス終了後はセキュリティアップデートやサポートが提供されないため、運用リスクが高まります。関連するAzureサービスとの連携については、App Serviceのクラウド版や他のPaaSサービスへの移行を検討する必要があります。
以上の内容は、公式アップデート情報に基づき、技術者が今後の運用や移行計画を立てる際に必要なポイントをまとめたものです。詳細は公式サイトのアナウンスをご参照ください。
公開日時: 2026年10月06日 18:21:59 UTC リンク: Retirement: Support for Java 8, 11 and 17 will end on September 1, 2027
アップデートID: 568585 情報源: Azure Updates API
カテゴリ: Compute, Mobile, Web, App Service, Retirements
要約:
何が更新されたか
Azure App ServiceにおけるJava 8、11、17のサポート終了が発表されました。
主な変更点や新機能
2027年9月1日をもって、Java 8、11、17のサポートが終了します。これ以降、これらのバージョンに対するセキュリティアップデートやカスタマーサポートの提供は行われません。
影響を受ける対象
Azure App Service上でJava 8、11、17を利用しているアプリケーションが対象となります。既存のアプリケーションは引き続き稼働しますが、サポート対象外となります。
注意点があれば記載
サポート終了後はセキュリティリスクが高まるため、対象バージョンを利用している場合は、早めに新しいJavaバージョンへの移行を検討してください。また、サポート終了後は技術的な問い合わせやトラブル対応も受けられなくなりますのでご注意ください。
情報源: Azure Update
詳細:
2027年9月1日をもって、Azure App ServiceにおけるJava 8、11、17のサポートが終了します。本アップデートの背景には、Javaプラットフォームの進化と、セキュリティやパフォーマンスの観点から最新バージョンへの移行を促進する目的があります。これにより、これらのバージョンを利用しているアプリケーションは引き続きApp Service上で稼働しますが、マイクロソフトからのセキュリティアップデートやバグフィックスの提供が終了し、サポート窓口での技術的な問い合わせ対応も受けられなくなります。
具体的な変更内容としては、Java 8、11、17のランタイムに対する公式サポートが打ち切られる点が挙げられます。これにより、これらのバージョンで稼働しているアプリケーションは、脆弱性が発見された場合でも修正パッチが提供されなくなり、セキュリティリスクが高まることになります。App Serviceの基盤自体は引き続き利用可能ですが、サポート対象外となることで、運用上の責任が利用者側に移行します。
技術的な仕組みとして、App ServiceはPaaS（Platform as a Service）として、複数のJavaランタイムバージョンを選択してアプリケーションをデプロイできる環境を提供しています。サポート終了後も、既存のJava 8、11、17ランタイムは選択可能であり、アプリケーションの稼働自体に即時の影響はありませんが、今後のセキュリティアップデートや新機能の追加は受けられません。
活用シナリオとしては、現在これらのJavaバージョンで運用しているWebアプリケーションやAPIサービスが該当します。今後も安全かつ安定した運用を継続するためには、サポートが継続されるJavaの新しいバージョンへの移行が推奨されます。移行作業にあたっては、アプリケーションの互換性検証や、依存ライブラリのアップデートが必要となる場合があります。
注意点として、サポート終了後は新たな脆弱性が発見された場合でも修正が提供されないため、情報漏洩やサービス停止などのリスクが顕在化します。また、Azureサポートチームによるトラブルシューティングや技術的な問い合わせ対応も受けられなくなるため、自己責任での運用が求められます。
関連するAzureサービスとしては、App Service以外にも、Javaを利用するAzure FunctionsやAzure Spring Appsなどが存在しますが、今回のアップデートはApp ServiceにおけるJavaランタイムのサポート終了に限定されています。今後、他のサービスでも同様のサポートポリシー変更が行われる可能性があるため、公式情報の継続的な確認が重要です。詳細については、公式アップデート情報（https://azure.microsoft.com/updates?id=568585）を参照してください。
公開日時: 2026年10月06日 16:42:33 UTC リンク: Retirement: Always Encrypted with Intel SGX Enclaves
アップデートID: 569236 情報源: Azure Updates API
カテゴリ: Databases, Hybrid + multicloud, Azure SQL Database, Retirements
要約:
【何が更新されたか】
Azure SQL Databaseの「Always Encrypted with Intel SGX enclaves」機能が2027年10月31日に廃止されることが発表されました。
【主な変更点や新機能】
Intel SGX対応のDCシリーズハードウェアのサポート終了に伴い、「Always Encrypted with Intel SGX enclaves」が利用できなくなります。今後は、ハードウェアに依存しない「Virtualization-Based Security（VBS）enclaves」への移行が推奨されています。
【影響を受ける対象】
Azure SQL Databaseで「Always Encrypted with Intel SGX enclaves」を利用しているユーザーやシステムが対象となります。特に、DCシリーズハードウェア上で暗号化処理を行っている環境は影響を受けます。
【注意点】
2027年10月31日以降はSGX enclavesを利用した暗号化機能が利用できなくなるため、早めにVBS enclavesへの移行計画を立てる必要があります。移行に際しては、アプリケーションやセキュリティ要件の見直しも必要となりますのでご注意ください。
詳細:
Azure SQL Databaseにおける「Always Encrypted with Intel SGX Enclaves」の機能は、2027年10月31日をもって廃止されます。この廃止は、SGX（Software Guard Extensions）対応のDCシリーズハードウェアのサポート終了に伴うものです。これにより、現在SGX Enclaveを利用しているユーザーは、今後ハードウェア非依存のVirtualization-Based Security（VBS）Enclaveへの移行が求められます。
「Always Encrypted with Intel SGX Enclaves」は、Azure SQL Database上で機密データを安全に処理するための機能です。従来のAlways Encryptedでは、暗号化されたデータはクライアント側でのみ復号可能でしたが、SGX Enclaveを利用することで、データベース内の特別なハードウェア領域（Enclave）で復号・処理が可能となり、より高度なセキュリティと柔軟なクエリ実行を実現していました。SGX Enclaveは、IntelのSGX技術を活用し、外部からのアクセスや改ざんが極めて困難な隔離環境を提供していました。
今回のアップデートでは、SGX対応DCシリーズハードウェアの段階的な廃止により、SGX EnclaveによるAlways Encrypted機能が利用できなくなります。これに伴い、MicrosoftはVBS Enclaveへの移行を推奨しています。VBS Enclaveは、仮想化技術を用いたハードウェア非依存のセキュリティ機能であり、今後のAzure SQL DatabaseにおけるAlways Encryptedの実装はVBS Enclaveを基盤としたものになります。
技術的な仕組みとして、SGX EnclaveはCPUレベルで隔離されたメモリ空間を利用していましたが、VBS EnclaveはHyper-Vなどの仮想化基盤を活用し、OSレベルで隔離されたセキュアな環境を提供します。これにより、特定のハードウェアに依存せず、より広範なAzure環境で利用可能となります。
活用シナリオとしては、機密性の高いデータ（個人情報や金融データなど）をAzure SQL Database上で安全に処理したい場合に、Always Encrypted with Enclave機能が有効です。従来SGX Enclaveを用いていたユーザーは、今後VBS Enclaveへの移行を計画する必要があります。
注意点として、SGX Enclaveの廃止により、DCシリーズハードウェア上でのAlways Encrypted with Enclave機能は利用できなくなります。移行に際しては、アプリケーションやデータベースの設定変更が必要となる場合がありますので、十分な検証と準備が求められます。
関連するAzureサービスとしては、Azure SQL Databaseが中心となりますが、Always Encrypted機能はAzure Key Vaultなどの暗号化キー管理サービスとも連携しており、セキュリティポリシーの一貫した運用が可能です。今回のアップデートにより、今後はVBS Enclaveを基盤としたAlways Encrypted機能がAzure SQL Databaseの標準となります。
公開日時: 2026年10月06日 15:44:06 UTC リンク: Public Preview: AKS on bare metal now on Ubuntu
アップデートID: 573782 情報源: Azure Updates API
カテゴリ: In preview, Feature
要約:
何が更新されたか
Azure Kubernetes Service（AKS）が、Ubuntu上のベアメタル環境で利用できるパブリックプレビューが開始されました。
主な変更点や新機能
これまでAKSは主に仮想化環境で提供されていましたが、今回のアップデートにより、仮想化レイヤーを介さずに直接ベアメタル上でAKSを動作させることが可能になりました。特にAIワークロードなど、ハードウェアリソースへの直接アクセスが求められるケースで、パフォーマンス向上や柔軟なインフラ管理が期待できます。
影響を受ける対象
オンプレミス環境でKubernetesを運用している技術者や、AKSを利用しているユーザー、AIや高負荷ワークロードを扱う開発者が主な対象です。
注意点があれば記載
本機能はパブリックプレビュー段階のため、本番環境での利用は推奨されません。Ubuntuベースのベアメタル環境に限定されている点にもご注意ください。
詳細:
本アップデートは、「AKS on bare metal now on Ubuntu」のパブリックプレビュー開始に関するものです。従来、Kubernetesをオンプレミス環境で運用する場合、仮想化レイヤーの追加や、慣れないインフラストラクチャへの適応、さらにはアプリケーションが依存するハードウェアやソフトウェアの制御権を放棄する必要がありました。特にAIワークロードにおいては、これらのトレードオフがローカルリソースへのアクセスを制限し、パフォーマンスや柔軟性に影響を及ぼしていました。
今回のアップデートでは、Azure Kubernetes Service（AKS）をUbuntu上のベアメタル環境で実行できるようになったことが特徴です。これにより、仮想化レイヤーを介さず、直接ハードウェア上でKubernetesクラスタを構築・運用することが可能となります。Ubuntuは広く利用されているLinuxディストリビューションであり、安定性やセキュリティ、パッケージ管理の面で多くの技術者に支持されています。AKS on bare metal on Ubuntuは、既存の仮想化基盤を必要とせず、よりダイレクトにリソースを活用できる点が大きな利点です。
技術的な仕組みとしては、AKSの管理機能やオーケストレーション機能はそのままに、Ubuntuベースのベアメタルサーバ上でKubernetesノードを展開します。これにより、仮想化によるオーバーヘッドを排除し、ハードウェアリソースを最大限に活用することができます。AIや機械学習ワークロード、ハイパフォーマンスコンピューティング（HPC）など、リソース消費が大きいアプリケーションにおいて、より高いパフォーマンスが期待できます。
活用シナリオとしては、オンプレミス環境でAIモデルのトレーニングや推論を行う場合、データのローカル処理が必要な場合、またはセキュリティやコンプライアンス上クラウドにデータを移動できないケースなどが挙げられます。AKS on bare metal on Ubuntuは、クラウドネイティブな管理性とオンプレミスの柔軟性を両立するため、企業のデータセンターやエッジ環境でのKubernetes運用に適しています。
注意点としては、パブリックプレビュー段階であるため、商用利用や本番環境への導入には慎重な検証が必要です。また、Ubuntu以外のOSや特定のハードウェア構成には対応していない可能性があります。運用管理やアップデート、サポートの範囲についても、現時点では限定的であることが想定されます。
関連するAzureサービスとの連携については、AKSの標準機能を活用できるため、Azure MonitorやAzure Policy、Azure Active Directoryなどの統合管理機能を利用することが可能です。これにより、オンプレミス環境でもクラウドと同様の運用管理やセキュリティ対策を実現できます。
以上が、「AKS on bare metal now on Ubuntu」パブリックプレビューの技術者向け詳細説明です。
このレポートは自動生成されました - 2026-10-07 12:02:00 JST