2026 年 10 月 13 日で Azure Storage の GPv1 が廃止されて GPv2 へ完全に移行される予定なので、以下のようなメールを受け取っている人が多いと思います。特に Azure Functions を利用している場合は同時に GPv1 のアカウントが作成されていたので、多くの人がメールを受け取っているはずです。
既に新規の GPv1 のアカウント作成は Azure Portal からはブロックされていますが Bicep や Terraform を使った場合にはまだブロックされていません。予定では廃止と同日に ARM REST API レベルでの作成もブロックされるはずなので、IaC でインフラを管理している場合には新規に作成しないように定義の対応が必要です。
Migrate your general-purpose v1 (GPv1) storage account to a general-purpose v2 (GPv2) storage account by 13 October 2026
You're receiving this notification because you're associated with one or more Azure subscriptions that have a legacy blob storage account. For reference, you can find this notification in the Azure portal under Service Health/Health advisories using tracking ID: XTKT-BW8.
On 13 October 2026, we'll retire blob-only storage accounts. To avoid disruptions, migrate your GPv1 storage accounts to GPv2 accounts before that date. GPv2 accounts give you access to the latest Azure Storage features while providing improved performance and true zonal redundancy support.
Automatic migration warning
After 13 October 2026, all existing legacy blob storage accounts will be automatically migrated over to a GPv2 account, which may result in higher billing costs. Your decision not to migrate an existing legacy blob storage account will be construed as consent for Microsoft to migrate the account on your behalf.
Creation of all new GPv1 accounts will be blocked by 13 October 2026.
廃止日までに手動で GPv2 へのアップグレードを行わなかった場合は、Microsoft による GPv2 への自動マイグレーションへ同意したという扱いになります。その場合は GPv2 へのアップグレードが自動で開始されるため、既存の GPv1 のアカウントは最終的には GPv2 に自動で変更されますが、アップグレードはダウンタイムが発生しない安全な処理です。
アップグレードが安全な処理とはいえ手動の方がタイミングを完全にコントロールできるので、稼働しているアプリケーションで使っているアカウントは事前に GPv2 へのアップグレードを行っておくのが無難です。
主な用途がバックアップやアクセスの少ないファイルの保管に使っている場合には、ストレージ容量での単価が下がっているのでコスト削減につながる可能性がありますが、それ以外のトランザクションが多めの用途の場合はコストが増えます。価格が心配な人が多いはずなので詳細は後述します。
今回 GPv1 の廃止だけではなく以前にあった Blobs 専用のアカウントも同時に廃止されます。Queue や Table が使えない謎のアカウントの種類でしたが、使っているケースはかなり少ないと思うので、GPv1 のように影響範囲は広くないはずです。
今回廃止対象となっているアカウントを特定する方法はいくつか存在しますが、分かりやすいのはメールにもあるように Azure Portal から Storage Center を開いて、Kind の値でフィルタリングする方法です。
以下のようにフィルタの値に Storage と BlobStorage が表示される場合は移行対象のアカウントが存在することになるため、事前に GPv2 へのアップグレードを行っておくことを強く推奨します。
GPv1 から GPv2 へのアップグレードは前述したとおり、ダウンタイムが発生しない安全な処理にはなりますが、アップグレードを行うことで GPv2 の課金体系になるため、これまでと同じ使い方の場合にコストが大きく変わる可能性があります。大雑把な説明をしてしまうと GPv1 から GPv2 にアップグレードを行うと、トランザクションが多いワークロードの場合は GPv1 よりも大きくコストが上がることになります。
Azure Storage にはよく使われる機能として Blobs / Queues / Tables の 3 種類がありますが、GPv1 から GPv2 へのアップグレードで単価がどのように変わるかは、以下の価格ページで確認が可能です。実際に単価が変わるのは Blobs と Queues の 2 つで Tables は GPv2 になっても価格は変わらないようです。
トランザクションのコストがかなり上がっている一方で、ストレージの単価はそれに比例して下がっているわけではないため、Blob や Queue に対して大量のリクエストを投げる処理を書いている場合にはコストが数倍になる可能性があります。トランザクションを少なくする方法はいくつかありますが、Queue は Polling を行う処理が必須なのでインターバルを短くしすぎると危ないです。
まずは GPv2 へのアップグレードを行う前に、Azure Monitor を使ってメトリックを取得して試算するのがベストです。トランザクションを減らす余地がない場合もあるはずですが、その場合は GPv2 の機能を使ってストレージの保管コストを下げる対応が必要になるでしょう。
Azure Functions を利用している場合
正直なところ、ほとんどのケースで GPv1 を使っているのは Azure Functions と同時にデプロイされるアカウントだと思います。Azure Functions は状態の管理に Blob を使っているので、GPv2 へのアップグレードを行うとトランザクションの単価が直撃します。それ以外にも古い BlobTrigger や EventHubTrigger を使っている場合はトランザクションが多く発生するので EventGridTrigger へ移行する、Event Hubs はチェックポイントの書き込み頻度を調整するといった対応が必要になります。
古い Durable Functions を利用している場合は Blob と Queue に対する大量のトランザクションが発生するため、GPv2 へのアップグレードを行う前に最新の Durable Functions をアップグレードを行う必要があります。実際にチームから共有されている情報によると、最新の Durable Functions では GPv1 と GPv2 でほぼコストが変わらないという結果が出ています。
他にも各 Azure Storage SDK や Azure Functions の拡張の不具合などによって無駄なコストが発生する可能性もありますので、基本的には最新の SDK へのアップグレードを行うことをお勧めしています。古い SDK のままで運用しているケースは意外に多いと思うので、これを機にアップグレードを行うのは良いタイミングだと思います。
