次の方法で共有

Azure Monitor のカスタマー マネージド キー

  • [アーティクル]

Azure Monitor のデータは、Microsoft マネージド キーを使用して暗号化されます。 独自の暗号化キーを使用して、ワークスペース内のデータと保存済みクエリを保護できます。 Azure Monitor のカスタマー マネージド キーを使用すると、ログへのアクセス制御をより柔軟に管理できます。 構成が完了すると、リンクされたワークスペースに取り込まれた新しいデータは、Azure Key Vault または Azure Key Vault マネージド "HSM" に格納されているキーで暗号化されます。

構成前に制限事項と制約を確認してください。

カスタマー マネージド キーの概要

保存時の暗号化は、組織の一般的なプライバシーおよびセキュリティ要件です。 保存時の暗号化は Azure で完全に管理できます。または、暗号化および暗号化キーを厳密に管理するさまざまなオプションを使用できます。

Azure Monitor により、Microsoft マネージド キー (MMK) を使用して、すべてのデータおよび保存されたクエリが保存時に暗号化されるようになります。 Azure Monitor での暗号化の使用は、Azure Storage の暗号化での運用方法とまったく同じです。

キーのライフサイクルを管理し、データへのアクセスを取り消すことができるようにするには、Azure Key Vault を使用して独自のキーでデータを暗号化します。

カスタマー マネージド キーは、専用クラスターで使用できるもので、より高いレベルの保護と制御を実現できます。 データはストレージ内で 2 回暗号化されます。サービス レベルでは Microsoft マネージド キーまたはカスタマー マネージド キーが使用され、インフラストラクチャ レベルでは 2 つの異なる暗号化アルゴリズムと 2 つの異なるキーが使用されます。 二重暗号化により、暗号化アルゴリズムまたはキーのいずれかが侵害される可能性があるシナリオから保護します。 専用クラスターを使用し、ロックボックスでデータを保護することもできます。

過去 14 日間に取り込まれたデータと、クエリで最近使用されたデータは、クエリ効率を高めるホットキャッシュ (SSD バックアップ) に保持されます。 SSD データは、カスタマー マネージド キーを構成しているかどうか関係なく、Microsoft キーで暗号化されますが、SSD アクセスに対する制御はキーの失効に従います。

重要

専用クラスターには、1 日あたり 100 GB 以上のコミットメント レベル価格モデルが使用されます。

Azure Monitor でのカスタマー マネージド キーのしくみ

Azure Monitor は、マネージド ID を使用して Azure Key Vault にアクセス権を付与します。 Log Analytics クラスターの ID はクラスター レベルでサポートされます。 複数のワークスペースでカスタマー マネージド キーを使用できるように、Log Analytics クラスター リソースは、キー コンテナーと Log Analytics ワークスペース間の中間 ID 接続として機能します。 クラスターのストレージは、クラスターに関連付けられているマネージド ID を使用して、Microsoft Entra ID 経由で Azure キー コンテナーに対する認証を行います。

クラスターでは、システム割り当てとユーザー割り当ての 2 つのマネージド ID の種類がサポートされていますが、シナリオに応じて単一の ID をクラスターで定義できます。

  • システム割り当てマネージド ID はよりシンプルであり、identity type が SystemAssigned に設定されている場合にクラスターで自動的に生成されます。 この ID は、後でデータの暗号化と復号化のために Key Vault に対するストレージ アクセス権を付与するために使用されます。
  • ユーザー割り当てマネージド ID を使用すると、クラスターの作成時、identity type を UserAssigned に設定するときに、カスタマー マネージド キーを構成できます。また、クラスターの作成前にお使いのキー コンテナーでそれにアクセス許可を付与できます。

カスタマー マネージド キーは、新しいクラスター、またはワークスペースにリンクされ、既にデータを取り込んでいる既存のクラスターで構成できます。 リンクされたワークスペースに取り込まれた新しいデータはユーザーのキーで暗号化され、構成前に取り込まれた古いデータは Microsoft キーで暗号化されたままになります。 カスタマー マネージド キー構成はクエリに影響せず、新旧のデータに対して引き続きシームレスに実行されます。 いつでも、クラスターからワークスペースのリンクを解除できます。 リンク解除後に取り込まれた新しいデータは Microsoft キーで暗号化され、クエリは新旧のデータ全体に対してシームレスに実行されます。

重要

カスタマー マネージド キー機能はリージョン単位で機能します。 Azure キー コンテナー、クラスター、リンクされたワークスペースは、同じリージョンに存在している必要がありますが、サブスクリプションは異なっていてもかまいません。

カスタマー マネージド キーの概要のスクリーンショット。

  1. Key Vault
  2. Key Vault へのアクセス許可があるマネージド ID を持つ Log Analytics クラスター リソース。この ID は、土台となる専用のクラスター ストレージに伝達されます。
  3. 専用クラスター
  4. 専用クラスターにリンクされているワークスペース

暗号化キー操作

ストレージ データの暗号化には、次の 3 種類のキーが関係します。

  • "KEK" - キー暗号化キー (カスタマー マネージド キー)
  • "AEK" - アカウント暗号化キー
  • "DEK" - データ暗号化キー

次の規則が適用されます。

  • クラスター ストレージには、すべてのストレージ アカウントに対して一意の暗号化キーがあります。これは "AEK" と呼ばれます。
  • "AEK" は、ディスクに書き込まれた各データ ブロックの暗号化に使用されるキーである "DEK" を派生させるために使用されます。
  • Key Vault でキーを構成してクラスターでキーの詳細を更新すると、クラスター ストレージは、暗号化と暗号化解除のために "AEK" を "折り返す" および "折り返しを解除する" する要求を実行します。
  • "KEK" がキー コンテナーの外部に出ることはありません。また、マネージド "HSM" を使用している場合、それがハードウェアの外部に出ることはありません。
  • Azure Storage は、認証に "クラスター" リソースに関連付けられているマネージド ID を使用します。 これは Microsoft Entra ID 経由で Azure Key Vault にアクセスします。

カスタマー マネージド キーのプロビジョニング手順

  1. Azure Key Vault の作成とキーの格納
  2. クラスターの作成
  3. Key Vault へのアクセス許可の付与
  4. キー識別子の詳細を使用したクラスターの更新
  5. ワークスペースのリンク

現在、カスタマー マネージド キーの構成は Azure portal でサポートされておらず、プロビジョニングは PowerShell、CLI、または REST の要求を使用して実行できます。

暗号化キー ("KEK") の格納

Azure Key Management 製品のポートフォリオには、使用できるコンテナーとマネージド HSM がリスト表示されています。

クラスターが計画されているリージョンで、Azure キー コンテナーを作成するか、既存のものを使います。 キー コンテナーで、ログの暗号化に使うキーを生成するかインポートします。 キーと Azure Monitor のデータへのアクセスを保護するには、Azure Key Vault を回復可能として構成する必要があります。 この構成は Key Vault のプロパティで確認できます。 [論理的な削除] と [Purge protection](消去保護) の両方を有効にしてください。

論理的な削除および消去保護の設定のスクリーンショット。

これらの設定は、CLI と PowerShell を使用して Key Vault で更新できます。

クラスターの作成

クラスターでは、Azure Key Vault でのデータ暗号化にマネージド ID が使用されます。 データの暗号化と復号化の操作のためにお使いのキー コンテナーにアクセスできるようにするには、クラスターの作成時に identity type プロパティを SystemAssigned または UserAssigned に構成します。

システム割り当てマネージド ID に関するクラスターの ID 設定

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Note

ID の種類は、クラスターの作成後に、次の点を考慮して、インジェストやクエリを中断することなく変更できます

  • SystemAssigned を UserAssigned に更新する - Key Vault で UserAssign ID を付与してから、クラスター内の identity type を更新します
  • UserAssigned を SystemAssigned に更新する - クラスター identity type を SystemAssigned で更新した後にシステム割り当てマネージド ID が作成されたため、以下の手順に従う必要があります
    1. クラスターを更新し、キーを削除します。keyVaultUri、keyName、keyVersion に値 "" を設定します
    2. クラスター identity type を SystemAssigned に更新します
    3. ID にアクセス許可を付与するように Key Vault を更新します
    4. クラスター内のキーを更新します

専用クラスターに関する記事で示されている手順に従います。

Key Vault アクセス許可を付与する

Key Vault には、クラスターと基になるストレージへのアクセス権を付与するために、Azure ロールベースのアクセス制御 (Azure RBAC) と Vault アクセス ポリシーの 2 つのアクセス許可モデルがあります。

  1. 制御する Azure RBAC を割り当てる (推奨)

    ロールの割り当てを追加するには、ユーザー アクセス管理者や所有者など、Microsoft.Authorization/roleAssignments/write と Microsoft.Authorization/roleAssignments/delete のアクセス許可を持つロールが必要です。

    1. Azure portal でキー コンテナーを開き、[設定]>[アクセス構成]>[Azure ロールベースのアクセス制御]、[適用] の順に選択します
    2. [アクセス制御 (IAM) に移動する] ボタンをクリックし、キー コンテナー暗号化サービスの暗号化ユーザー ロールの割り当てを追加します。
    3. [メンバー] タブで [マネージド ID] を選択し、ID のサブスクリプションと、メンバーとしての ID を選択します

    Key Vault RBAC アクセス許可の付与のスクリーンショット。

  2. Vault アクセス ポリシーを割り当てる (レガシ)

    Azure portal でキー コンテナーを開き、[アクセス ポリシー]>[コンテナーのアクセス ポリシー]>[+ アクセス ポリシーの追加] を選択し、次の設定でポリシーを作成します。

    • キーのアクセス許可: [取得]、[キーを折り返す]、[キーの折り返しを解除] を選択します。
    • プリンシパルの選択 — クラスターで使用される ID の種類に応じて選択 (システムまたはユーザー割り当てマネージド ID)
      • システム割り当てマネージド ID - クラスター名またはクラスター プリンシパル ID を入力します
      • ユーザー割り当てマネージド ID - ID 名を入力します

    Key Vault アクセス ポリシー アクセス許可のスクリーンショット。

    [取得] アクセス許可は、キーを保護し、Azure Monitor データへのアクセスを保護するために、Key Vault が回復可能として構成されていることを確認するために必要です。

キー識別子の詳細を使用してクラスターを更新する

クラスター上のすべての操作には、Microsoft.OperationalInsights/clusters/write アクションのアクセス許可が必要です。 このアクセス許可を付与するには、*/write アクションを含む所有者または共同作成者、または Microsoft.OperationalInsights/* アクションを含む Log Analytics 共同作成者ロールを使用します。

この手順では、"AEK" の折り返しと折り返しの解除に使用するキーとバージョンを使用して専用クラスター ストレージを更新します。

重要

  • キーの交換は自動で行うか、明示的なキー バージョンごとに行うことができます。クラスター内のキー識別子の詳細を更新する前に、キーの交換に関する記事を参考にして自分に適したアプローチを判断してください。
  • クラスターの更新では、同じ操作に ID とキー識別子の詳細の両方を含めることをしないでください。 両方の更新が必要な場合、更新は 2 つの連続する操作で行ってください。

Key Vault アクセス許可の付与のスクリーンショット。

クラスターの KeyVaultProperties を、キー識別子の詳細で更新します。

操作は非同期であり、完了するまでに時間がかかることがあります。

該当なし

重要

この手順は、クラスターのプロビジョニング後にのみ実行してください。 プロビジョニングの前にワークスペースをリンクしてデータを取り込むと、取り込まれたデータは削除され、回復できなくなります。

この操作を実行するには、ワークスペースおよびクラスターに対する "書き込み" 権限が必要です。 それには、Microsoft.OperationalInsights/workspaces/write と Microsoft.OperationalInsights/clusters/write が含まれます。

専用クラスターに関する記事で示されている手順に従います。

キーの失効

重要

  • データへのアクセスを失効させる方法としては、キーを無効にするか、Key Vault でアクセス ポリシーを削除することをお勧めします。
  • クラスターの identity type を None に設定すると、データへのアクセスも失効しますが、サポートに連絡しない限り取り消すことができないため、この方法はお勧めできません。

クラスター ストレージは常に 1 時間以内にキーのアクセス許可の変更に対応し、ストレージは使用できなくなります。 リンクされたワークスペースに取り込まれた新しいデータは削除され、回復できません。 これらのワークスペースではデータにアクセスできないので、クエリは失敗します。 クラスターおよびワークスペースが削除されていない限り、以前に取り込まれたデータはストレージに残ります。 アクセスできないデータは、データ保持ポリシーによって管理され、リテンション期間に達すると削除されます。 過去 14 日間に取り込まれたデータと、クエリで最近使用されたデータも、クエリ効率を高めるホットキャッシュ (SSD ベース) に保持されます。 SSD のデータはキーの失効操作で削除され、アクセスできなくなります。 クラスター ストレージは、ラップとラップ解除のためにキー コンテナーに定期的にアクセスを試みます。そしてキーが有効になると、ラップ解除が成功し、SSD データがストレージから再読み込みされ、データ インジェストとクエリが 30 分以内に再開されます。

キーの交換

キーの交換には、次の 2 つのモードがあります。

  • 自動交換 - クラスター内の "keyVaultProperties" プロパティを更新して、"keyVersion" プロパティを省略するか、"" に設定します。 ストレージには、最新のキー バージョンが自動的に使われます。
  • 明示的なキー バージョンの更新 - "keyVaultProperties" プロパティを更新し、"keyVersion" プロパティのキー バージョンを更新します。 キーの交換には、クラスター内の "keyVersion" プロパティの明示的な更新が必要です。 詳細については、「キー識別子の詳細を使用してクラスターを更新する」を参照してください。 Key Vault で新しいキー バージョンを生成しても、そのキーをクラスターで更新していない場合、クラスター ストレージでは以前のキーが引き続き使われます。 クラスターの新しいキーを更新する前に古いキーを無効にしたり削除したりすると、キー失効状態になります。

キーの交換操作の最中とその後も、すべてのデータに引き続きアクセスできます。 データは常にアカウント暗号化キー ("AEK") で暗号化されます。これは、Key Vault の新しいキー暗号化キー ("KEK") バージョンで暗号化されます。

保存されたクエリおよびログ検索アラート用のカスタマー マネージド キー

Log Analytics で使用されるクエリ言語は表現力が豊かで、コメントまたはクエリ構文に機密情報を含めることができます。 組織によっては、このような情報をカスタマー マネージド キー ポリシーによって保護する必要があり、キーで暗号化された状態でクエリを保存する必要があります。 Azure Monitor を使用すると、ワークスペースとリンクした場合に、保存されたクエリとログ検索アラートをキーで暗号化して、独自のストレージ アカウント内に保存することができます。

ブック用のカスタマー マネージド キー

「保存されたクエリおよびログ検索アラート用のカスタマー マネージド キー」で言及した考慮事項を踏まえて、Azure Monitor を使用すると、ブックの '保存' 操作で [内容を Azure Storage アカウントに保存する] を選択した場合に、ブック クエリをキーで暗号化して、独自のストレージ アカウントに保存することができます。

ブックの保存のスクリーンショット。

Note

次のシナリオでは、カスタマー マネージド キーの構成に関係なく、Microsoft キー ("MMK") でクエリの暗号化が維持されます (Azure ダッシュボード、Azure Logic App、Azure Notebooks、Automation Runbooks)。

保存されたクエリのストレージ アカウントをリンクすると、サービスは保存されたクエリとログ検索アラート クエリをストレージ アカウント内に保存します。 ストレージ アカウントの保存時の暗号化ポリシーを制御すると、カスタマー マネージド キーを使用して、保存されたクエリとログ検索アラートを保護することができます。 ただし、そのストレージ アカウントに関連するコストについてはお客様の負担になります。

クエリにカスタマー マネージド キーを設定する前の考慮事項

  • ワークスペースとストレージ アカウントに対する "書き込み" 権限が必要です。
  • ストレージ アカウントは、カスタマー マネージド キーの暗号化を使い、Log Analytics ワークスペースと同じリージョンに作成してください。 保存されたクエリはテーブル ストレージに格納され、暗号化できるのはストレージ アカウントの作成時のみなので、これは重要です。
  • クエリ パックに保存されたクエリは、カスタマー マネージド キーを使って暗号化されていません。 クエリを保存する場合は、代わりに [レガシ クエリとして保存] を選び、カスタマー マネージド キーを使って保護します。
  • ストレージ内の保存済みクエリはサービスの成果物と見なされ、その形式は変更される可能性があります。
  • クエリ用のストレージ アカウントをリンクすると、ワークスペースから既存の保存クエリが削除されます。 必要な保存済みクエリは、この構成前にコピーしてください。 PowerShell を使用して、保存済みクエリを表示できます。
  • クエリ用のストレージ アカウントをリンクすると、クエリ 'history' と 'pin to dashboard' はサポートされません。
  • 1 つのストレージ アカウントを、保存されたクエリとログ検索アラート クエリのどちらのワークスペースに対してもリンクすることができます。
  • ログ検索アラートは BLOB ストレージ内に保存され、カスタマー マネージド キーによる暗号化は、ストレージ アカウントの作成時またはそれ以降に構成することができます。
  • 発生したログ検索アラートには、検索結果もアラート クエリも含まれません。 発生したアラートの背景を取得する目的でアラート ディメンションを使用できます。

保存済みクエリ用に BYOS を構成する

クエリ用のストレージ アカウントをリンクして、ストレージ アカウントに保存済みクエリを保持します。

該当なし

構成が完了すると、新しい保存された検索条件クエリがストレージに保存されます。

ログ検索アラート クエリ用に BYOS を構成する

"アラート" 用のストレージ アカウントをリンクして、ストレージ アカウント内に "ログ検索アラート" クエリを保持します。

該当なし

構成が完了すると、新しいアラート クエリがストレージに保存されます。

カスタマー ロックボックス

お客様は、ロックボックスを使用して、サポート リクエストへの対応時の Microsoft のエンジニアによる顧客データへのアクセス要求を承認または拒否できます。

ロックボックスは Azure Monitor の専用クラスターに用意されており、データにアクセスするアクセス許可はサブスクリプション レベルで付与されます。

詳細については、「Microsoft Azure 用カスタマー ロックボックス」を参照してください。

カスタマー マネージド キーの操作

カスタマー マネージド キーは専用クラスター上で指定されます。これらの操作については専用クラスターに関する記事を参照してください。

  • リソース グループ内のすべてのクラスターを取得する
  • サブスクリプション内のすべてのクラスターを取得する
  • クラスターの "容量予約" を更新する
  • クラスターの billingType を更新する
  • クラスターからワークスペースのリンクを解除する
  • クラスターを削除する

制限と制約

  • 各リージョンとサブスクリプションには、最大 5 つのアクティブ クラスターを作成できます。

  • 各リージョンとサブスクリプションには、最大 7 つの予約済みクラスター (アクティブまたは最近削除されたもの) が存在できます。

  • 1 つのクラスターには、最大 1,000 の Log Analytics ワークスペースをリンクできます。

  • 特定のワークスペースでは、30 日間に最大 2 つのワークスペース リンク操作が許可されます。

  • 別のリソース グループまたはサブスクリプションへのクラスターの移動は、現時点ではサポートされていません。

  • クラスターの更新では、同じ操作に ID とキー識別子の詳細の両方を含めることはしないようにする必要があります。 両方の更新が必要な場合、更新は 2 つの連続する操作で行ってください。

  • ロックボックスは、現在、中国では使用できません。

  • ロックボックスは、Auxiliary プランのテーブルには適用されません。

  • 二重暗号化は、サポートされているリージョンで 2020 年 10 月以降に作成されたクラスターに対して自動的に構成されます。 クラスターが二重暗号化されるように構成されているかどうかを確認するには、クラスターに対して GET 要求を送信し、二重暗号化が有効になっているクラスターの isDoubleEncryptionEnabled の値が true かどうかを検査します。

    • クラスターを作成したときに、"リージョン名ではクラスターの二重暗号化がサポートされていません" というエラーが表示された場合でも、REST 要求本文に "properties": {"isDoubleEncryptionEnabled": false} を追加すると、二重暗号化なしでクラスターを作成できます。
    • クラスターの作成後に、二重暗号化の設定を変更することはできません。

  • リンクされたワークスペースは、クラスターにリンクされている間は削除できます。 論理的な削除期間中にワークスペースを回復することにした場合、以前の状態に戻り、クラスターへのリンクは維持されます。

  • カスタマー マネージド キーの暗号化は、構成後に新しく取り込まれたデータに適用されます。 構成より前に取り込まれたデータは、Microsoft キーで暗号化されたままになります。 カスタマー マネージド キーの構成の前後に取り込まれたデータのクエリは、シームレスに実行できます。

  • Azure Key Vault は、回復可能として構成する必要があります。 これらのプロパティは既定では有効になっておらず、CLI または PowerShell を使用して構成する必要があります。

    • 論理的な削除。
    • 論理的な削除の後でもシークレットやコンテナーの強制削除を防ぐには、消去保護を有効にする必要があります。

  • Azure Key Vault、クラスター、ワークスペースは、同じリージョンかつ同じ Microsoft Entra テナント内に存在している必要がありますが、サブスクリプションは異なっていても構いません。

  • クラスターの identity type を None に設定すると、データへのアクセスも失効しますが、サポートに連絡しない限り取り消すことができないため、この方法はお勧めできません。 データへのアクセスを失効させる方法としては、キーの失効をお勧めします。

  • Key Vault がプライベート リンク (VNet) に配置されている場合は、ユーザー割り当てマネージド ID を持つカスタマー マネージド キーを使用できません。 このシナリオでは、システム割り当てマネージド ID を使用できます。

  • Auxiliary テーブル プランは、カスタマー マネージド キーをサポートしていません。 Auxiliary プランに関連するテーブル内のデータは、Log Analytics ワークスペースの残りの部分のデータを独自の暗号化キーで保護している場合であっても、Microsoft が管理するキーで暗号化されます。

トラブルシューティング

  • Key Vault の可用性ごとの動作:

    • 通常の操作 - ストレージは一時的に "AEK" をキャッシュし、定期的に Key Vault に戻って折り返しを解除します。

    • Key Vault 接続エラー - ストレージは、可用性の問題が発生している間キーをキャッシュに残して、一時的なエラー (タイムアウト、接続エラー、"DNS" の問題) を処理します。これにより、中断と可用性の問題が解決されます。 クエリ機能と取り込み機能は中断されることなく続行されます。

  • Key Vault へのアクセス レート - クラスター ストレージがラップとラップ解除のために Key Vault にアクセスする頻度は、6 秒から 60 秒です。

  • プロビジョニングの状態または更新中の状態のときにクラスターを更新すると、更新は失敗します。

  • クラスターの作成時に競合 (エラー) が発生した場合は、同じ名前のクラスターが過去 14 日間に削除され、予約されたままになっている可能性があります。 削除されたクラスター名は、削除されてから 14 日後に使用できるようになります。

  • ワークスペースが別のクラスターにリンクされている場合、クラスターへのワークスペースのリンクは失敗します。

  • クラスターを作成し、すぐに KeyVaultProperties を指定すると、クラスターに ID が割り当てられて Key Vault に付与されるまで、操作は失敗する可能性があります。

  • KeyVaultProperties で既存のクラスターを更新し、Key Vault に "Get" キーのアクセス ポリシーがない場合、操作は失敗します。

  • クラスターのデプロイに失敗した場合は、Azure Key Vault、クラスター、およびリンクされているワークスペースが同じリージョンにあることを確認してください。 サブスクリプションは異なっていてもかまいません。

  • Key Vault でキーをローテーションし、クラスターの新しいキー識別子の詳細を更新しない場合、クラスターでは以前のキーが引き続き使われるので、データにアクセスできなくなります。 クラスターで新しいキー識別子の詳細を更新して、データ インジェストとクエリを再開します。 "''" を指定してキー バージョンを更新すると、ストレージが常に最新のキー バージョンを自動的に使うようになります。

  • クラスターの作成、クラスター キーの更新、クラスターの削除など、一部の操作は実行時間が長く、完了するまでに時間がかかる場合があります。 クラスターまたはワークスペースに GET 要求を送信して操作の状態を確認し、応答を確認できます。 たとえば、リンクされていないワークスペースには、features の下に clusterResourceId が存在しません。

  • エラー メッセージ

    クラスターの更新

    • 400 - クラスターは削除中の状態です。 非同期操作が進行中です。 更新操作を実行する前に、クラスターでの操作が完了している必要があります。
    • 400 - KeyVaultProperties は空ではありませんが、形式が無効です。 キー識別子の更新に関するセクションを参照してください。
    • 400 - Key Vault 内のキーの検証に失敗しました。 必要なアクセス許可がないことが原因である可能性があります。または、キーが存在しません。 Key Vault でキーとアクセス ポリシーを設定したことを確認してください。
    • 400 - Key を回復できません。 Key Vault に論理的な削除と消去保護を設定する必要があります。 Key Vault のドキュメントを参照してください
    • 400 - 現在、操作を実行できません。 非同期操作が完了するまで待ってから、もう一度お試しください。
    • 400 - クラスターは削除中の状態です。 非同期操作が完了するまで待ってから、もう一度お試しください。

    クラスターの取得

    • 404 - Cluster not found, the cluster might have been deleted. (404 - クラスターが見つかりません。クラスターは削除された可能性があります。) クラスターをその名前で作成しようとして、競合が発生した場合、そのクラスターは削除プロセスにあります。

次のステップ