Azure Database for PostgreSQL Flexible Server をデプロイしようとして、プロビジョニングが Failed のまま固まり、その後もサーバーがポータルから削除できない――そんな “幽霊リソース” に悩むことがあります。本記事では、実際に遭遇した事例をベースに、原因の切り分けと安全な解決手順を詳しく解説します。
症状：PostgreSQL Flexible Server が「Failed」のまま削除できない
まず、この記事で扱う典型的な症状を整理します。Azure Portal から PostgreSQL Flexible Server を作成しようとしたところ、デプロイが次のようなメッセージで失敗します。
The resource operation completed with terminal provisioning state 'Failed'.
その後、ポータル上では次のような状態になります。
- Azure CLI の
az postgres flexible-server listにもサーバーが出てこない - ポータルの概要ページを開こうとすると、画面上部に
Cannot read properties of undefined (reading ‘createdAt’) といった JavaScript エラーが表示され、操作不能 - リソースのコマンドバーに 削除 ボタンが表示されず、ポータルから消せない
このように「実体は無いのにポータル上だけに何か残っている」状態は、いわゆる ゴーストリソース（幽霊リソース） と呼ばれることがあります。
先に結論を書くと、今回のケースでは Azure サポートに依頼し、ARM（Azure Resource Manager）のキャッシュをリフレッシュ してもらうことで、ポータル上から該当サーバーの表示が完全に消えました。実際には ARM 上にリソースの実体は存在せず、ポータル側のキャッシュ不整合 が原因だったと考えられます。
とはいえ、毎回すぐにサポートに投げてしまうと、原因の切り分けも進まず対応も長引きがちです。そこで以下では、自力で確認できる範囲の切り分けと対処フロー を実務的な手順として整理していきます。
全体像：ゴーストリソース対応フロー
最初に、この記事で紹介する対応の流れを俯瞰しておきます。
| ステップ | 目的 | 主な手段 |
|---|---|---|
| 1. 実体の有無を確認 | リソースが ARM 上に存在するか切り分ける | Azure CLI / Resource Graph / Resource Explorer |
| 2. 実体がある場合 | 通常の削除手順と削除を妨げる要因の解消 | CLI で削除、ロック・ポリシー・依存リソースを確認 |
| 3. 実体が無い場合 | ポータルにだけ残る表示を消す | ポータル設定リセット & サポートに ARM キャッシュ刷新を依頼 |
次のセクションから、この流れに沿って詳細を解説していきます。
ARM 上に実体があるかの切り分け
最初に必ず行うべきなのが、「その PostgreSQL Flexible Server が ARM 上に本当に存在するのか」 という切り分けです。ここを曖昧にしたまま進めると、ポータルの表示不具合なのか、本当に消しきれていないのかが分からなくなります。
Azure CLI で存在確認する
最も手軽で確実なのは、Azure CLI を使ってリソースを列挙・参照する方法です。事前に az login と az account set で対象サブスクリプションを選択しておきましょう。
# PostgreSQL Flexible Server の一覧を取得
az postgres flexible-server list -g <ResourceGroupName>
# 個別リソースを参照（見つかれば resourceId が取れる）
az resource show \
-g <ResourceGroupName> \
-n <ServerName> \
--resource-type Microsoft.DBforPostgreSQL/flexibleServers
よくあるミスとして、次のようにコマンドを打ち間違えてしまうパターンがあります。
# ❌ 誤りの例（末尾の "-server" が抜けている）
az postgres flexible list
正しくは az postgres flexible-server list です。意外とケアレスミスしやすいので注意してください。
上記コマンドで、対象のサーバー情報が返ってくるかどうかを確認します。
- 情報が返ってくる → ARM 上にリソースの実体がある
- 何も返ってこない / Not Found → 少なくとも ARM からは見えていない
Azure Resource Graph で全サブスクリプションを横断確認
複数サブスクリプションを扱っている環境では、単に CLI でリソースグループ単位で見るだけでは取りこぼす可能性があります。その場合、Azure Resource Graph を使って、サブスクリプションをまたいで検索してしまうのが便利です。
Azure Portal から「Resource Graph Explorer」を開き、次のようなクエリを実行します。
resources
| where type == "microsoft.dbforpostgresql/flexibleservers"
| where name == "<ServerName>"
これでどのサブスクリプション / リソース グループに存在しているのか、あるいはそもそも存在していないのかを素早く確認できます。
Azure Resource Explorer（resources.azure.com）で直接確認
さらに踏み込んで確認したい場合は、Azure Resource Explorer を使う方法もあります。ARM に対して直接 REST 相当の参照を行うツールで、次のような手順で確認できます。
- Azure アカウントで Resource Explorer にサインインする
- 左ペインから対象サブスクリプション → リソースグループ →
Microsoft.DBforPostgreSQL→flexibleServersを展開 - 該当の
ServerNameが存在するかどうかを確認
CLI・Resource Graph・Resource Explorer のいずれを使っても、どこにもリソースが見つからない 場合は、ARM 上には実体が存在しておらず、ポータル表示だけが残っている状態 と判断できます。
実体の有無を整理するチェック表
ここまでの内容を、判断に使える簡易チェック表としてまとめておきます。
| 確認項目 | 結果 | 考えられる状態 |
|---|---|---|
az postgres flexible-server list に表示されるか | はい | ARM 上に実体あり。通常の削除フローで対応可能 |
az postgres flexible-server list に表示されるか | いいえ | 実体が無い可能性。次の確認へ進む |
Resource Graph で microsoft.dbforpostgresql/flexibleservers が見つかるか | はい | ARM 上に実体あり。ID を特定して削除を試みる |
| Resource Graph / Resource Explorer いずれにも存在しない | はい | ポータル表示のみのゴーストリソースの可能性が高い |
実体が存在する場合の削除手順
CLI や Resource Graph でリソースが見えている場合は、通常の削除手順で対応できます。ただし、削除をブロックしている要因 があると、削除コマンドが失敗し、結果として「消えないリソース」に見えてしまいます。
Azure CLI から通常削除を行う
もっともシンプルなのは、Azure CLI を使った削除です。
# 名前で削除
az postgres flexible-server delete \
-g <ResourceGroupName> \
-n <ServerName> \
--yes
# ResourceId が分かっている場合は直接削除
az resource delete --ids <ResourceId>
コマンド実行後、アクティビティ ログ で結果と詳細なエラーメッセージを確認しておきましょう。ここでエラーになっている場合は、何らかのブロック要因が存在します。
削除ロック・ポリシー・ネットワークリソースを確認する
PostgreSQL Flexible Server は、ネットワークやポリシーなど周辺の設定に依存しているため、途中でデプロイが失敗すると中途半端な状態のリソースが残ることがあります。代表的なブロック要因を整理しておきます。
| カテゴリ | 確認ポイント | 対処の方向性 |
|---|---|---|
| 削除ロック | リソースグループ / サブスクリプションに「削除ロック」が設定されていないか | 一時的にロックを解除してから削除を実行 |
| Azure Policy | 作成や削除を拒否するポリシー（Deny）が適用されていないか | ポリシーを確認し、対象リソースに対する例外や一時的な緩和を検討 |
| ネットワーク | 委任サブネット / Private Endpoint / Private DNS Zone が中途半端に残っていないか | 関連リソースの残骸をクリーンアップした上で削除を再実行 |
| RBAC 権限 | 自分のアカウントに「削除」権限（Contributor 以上）があるか | ロール割り当てを確認し、必要な権限を付与してもらう |
| クォータ / 名前重複 | サーバー名の重複やクォータ超過による中途半端な状態になっていないか | 別名で作り直すか、クォータ調整を依頼 |
ネットワーク周りの残骸をクリーンアップする
とくに Flexible Server は VNet 統合や Private Endpoint を使う構成が多く、作成に失敗した場合に次のようなリソースだけが残りやすくなります。
- 委任されたサブネット（
Microsoft.DBforPostgreSQL/flexibleServersへの委任） - Private Endpoint（接続先が中途半端な状態）
- Private DNS Zone と VNet リンク
これらを手作業で削除したあと、改めて本体のサーバー削除を試みると、あっさり消えるケースも多いです。
実体が無いのにポータルにだけ見える場合（ゴーストリソース）
CLI・Resource Graph・Resource Explorer などで確認しても、該当の PostgreSQL Flexible Server がどこにも見つからない。それにもかかわらず、Azure Portal には中途半端なリソースとして表示され、“Cannot read properties of undefined (reading ‘createdAt’)” などのエラーとともに操作不能――これが今回のような ゴーストリソース の典型です。
まずはポータル側の設定をリセットする
単純な UI 側のキャッシュやブラウザの問題である可能性もあるので、次のような対処を最初に試してみましょう。
- Azure Portal 右上の「Portal 設定」から「リセット」実行
- 別ブラウザ、またはシークレットウィンドウで Azure Portal を開き直す
- ブラウザのキャッシュや Cookie を削除したうえで再ログインする
それでも対象リソースの表示が消えない場合は、ポータルの UI と ARM の状態が不整合を起こしている 可能性が高くなります。
Azure サポートに ARM キャッシュのリフレッシュを依頼する
ARM 上に実体が無いことが確認でき、かつポータル側のリセットでも解消しない場合は、Azure サポートに「ARM キャッシュのリフレッシュ」 を依頼するのが現実的な解決策です。
サポートチケットを起票する際、以下の情報を添えておくと対応がスムーズになります。
- サブスクリプション ID
- リソース グループ名（表示されているもの）
- 問題の PostgreSQL Flexible Server 名
- リージョン（例：japaneast, japansouth など）
- 発生日時と、ポータル上に表示されるエラーメッセージ（例：
Cannot read properties of undefined (reading 'createdAt')） - アクティビティ ログから取得できる場合は、相関 ID（Correlation ID）
- CLI および Resource Graph でリソースが見つからないことを確認した旨
実際の事例では、サポート側で ARM キャッシュのリフレッシュ等を実施してもらった結果、ポータル上のゴースト表示が消え、何もなかったかのようにリソース一覧から消えた、という形で解決しました。
サポート依頼文のサンプル
実務でそのまま使えるよう、サポートチケットに記載する内容のイメージを簡単にまとめておきます。
Azure Portal 上で PostgreSQL Flexible Server のデプロイに失敗し、
その後もリソースが「Failed」状態のまま削除できない事象が発生しています。
・サブスクリプション ID: <SubscriptionId>
・リソース グループ: <ResourceGroupName>
・サーバー名: <ServerName>
・リージョン: <Region>
・発生時刻: <Time>
現象:
・ポータルの概要ページで「Cannot read properties of undefined (reading 'createdAt')」と表示され、操作不能
・削除ボタンが表示されず、自力で削除できない
・Azure CLI (az postgres flexible-server list / az resource show) では当該リソースが表示されない
・Azure Resource Graph でも microsoft.dbforpostgresql/flexibleservers にリソースが見つからない
上記より、ARM 上には実体が存在せず、ポータル表示のみが残っていると考えています。
ARM キャッシュのリフレッシュなど、本事象の解消についてご支援いただけないでしょうか。
ここまで書いておくと、サポート側も「まずは CLI で確認してください」といったやり取りを省略しやすくなり、結果的に解決までの時間短縮につながります。
なぜ「Failed 固着 + ゴーストリソース」が起きるのか
少し技術寄りの観点から、今回のような事象が起きる背景を簡単に整理しておきます。理解しておくことで、今後のトラブルシューティングもしやすくなります。
ARM テンプレートとバックエンドプロビジョニング
Azure の多くのリソースは、ARM（Azure Resource Manager）を経由して作成・更新・削除されます。PostgreSQL Flexible Server の場合も同様で、
- ARM に「Flexible Server を作ってほしい」というリクエストが送られる
- バックエンドでネットワークやストレージなど複数のコンポーネントが順次プロビジョニングされる
- すべて成功すると、プロビジョニング状態が「Succeeded」になる
何らかの理由で途中のステップが失敗すると、最終的に terminal provisioning state ‘Failed’ で止まります。この時点で、「一部だけ作られて残っている」状態になることが多く、削除時にはその不整合の影響を受けることがあります。
“Cannot read properties of undefined (reading ‘createdAt’)” の意味
ポータル上のエラーメッセージである Cannot read properties of undefined (reading 'createdAt') は、JavaScript の典型的なエラーで、「createdAt プロパティを持っているはずのオブジェクトが undefined だった」という意味です。
すなわち、
- ポータル側は「Resource の詳細情報に
createdAtがあるはず」と期待している - しかし実際には ARM から返ってきたデータにそのプロパティが含まれていない
という 状態不整合 が発生していることを示しています。今回のように、ARM 上に実体が存在しないのに、ポータルが古いキャッシュや途中までの情報を表示しようとすると、この手のエラーが発生しがちです。
再発防止のためのチェックポイント
最後に、同様のトラブルを避けるために、PostgreSQL Flexible Server を新規作成する前に確認しておきたいポイントと、失敗時の後片付けのコツをまとめます。
作成前に確認したいポイント
- サブネットの委任設定
- VNet 統合の構成では、対象サブネットが
Microsoft.DBforPostgreSQL/flexibleServersに正しく委任されているかを確認 - 同じサブネットに他のサービスの委任が設定されていないか（1 サブネット 1 委任が基本）
- VNet 統合の構成では、対象サブネットが
- Private DNS Zone と名前解決
- Private Endpoint を使うかどうか、その場合の Private DNS Zone 名やリンク構成を事前に設計
- オンプレ環境からの名前解決が必要な場合は、DNS フォワーダー等の構成も検討
- リソース グループ / サブスクリプションのロック・ポリシー
- 「誤削除防止」のための削除ロックが、逆に今回のような障害時の削除も妨げてしまわないか
- ポリシーで特定リージョン・SKU が禁止されていないか
- サーバー名 / クォータ / RBAC 権限
- 同じサーバー名が別リージョンや別サブスクリプションで既に使われていないか
- PostgreSQL サーバーのクォータが上限に達していないか
- 自分のアカウントに必要な権限（少なくとも Contributor）が付与されているか
デプロイ失敗時の後片付けのコツ
PostgreSQL Flexible Server の作成が失敗した場合は、次の順番で後片付けを行うと事故を減らせます。
- アクティビティ ログで失敗した操作の詳細を確認
- 関連するネットワークリソース（Private Endpoint, DNS Zone, サブネットの委任など）の「残骸」を確認
- 削除しても問題ないことを確認したうえで、残骸を手動削除
- 本体の PostgreSQL Flexible Server の削除（あるいは RG 全体の削除）を実施
この際、すぐにリソースグループごと削除してしまうのも手ですが、RG を共有している他のシステムがある場合は影響範囲が大きくなるので、慎重に判断しましょう。
まとめ：Failed 固着時の最短ルート
ここまでの内容を、あらためて要点として整理します。
- PostgreSQL Flexible Server が “Failed” 固着 + 削除できない 場合、まずは ARM 上に実体があるかどうか を切り分ける
- 実体がある場合は、Azure CLI や Resource Graph で
resourceIdを特定し、az postgres flexible-server delete/az resource deleteで削除を試行- 削除ロック・ポリシー・ネットワークリソース・権限など、削除をブロックする要因を解消する
- CLI や Resource Graph でもリソースが見つからず、ポータルにだけ残っている場合は、
- ポータル設定リセットやブラウザ変更を試す
- それでも解消しなければ、Azure サポートに ARM キャッシュのリフレッシュ を依頼する
要するに、
① 実体の有無を切り分け → ② 実体があれば CLI で削除 & 依存を解消 → ③ 実体がなく表示だけならサポートに ARM キャッシュのリフレッシュを依頼
という三段構えが、PostgreSQL Flexible Server の「Failed 固着」問題を手早く解消するための最短ルートです。
同様のトラブルで悩んでいる方の、原因切り分けと再発防止の一助になれば幸いです。
コメント