Azure Cloud Services (延長サポート) に関してよく寄せられる質問

• Cloud Services (クラシック): microsoft.classiccompute/domainnames
• Cloud Services (延長サポート): microsoft.compute/cloudservices

Cloud Services (延長サポート) は、すべてのパブリックおよびソブリン クラウド リージョンで使用できます。

お客様は、他の Azure Resource Manager 製品と同じプロセスを使用してクォータを要求する必要があります。 Azure Resource Manager のクォータはリージョン別であり、リージョンごとに個別のクォータ要求が必要になります。

Cloud Services (延長サポート) では、2 つのスロット (運用とステージング) が含まれていたホステッド サービスの論理的な概念はサポートされません。 各デプロイが、独立した Cloud Service (延長サポート) のデプロイです。 クラウド サービスの新しいリリースをテストしてステージングするには、クラウド サービス (延長サポート) をデプロイし、それを別のクラウド サービス (延長サポート) との VIP スワップ可能としてタグ付けします。

ホステッド サービス名の概念が存在しなくなったため、空の Cloud Service (延長サポート) を作成することはできません。

いいえ。Cloud Services (延長サポート) では、リソース正常性チェック (RHC) はサポートされていません。

ロール インスタンスのメトリックに変更はありません。

Web および worker ロールの設計、アーキテクチャ、またはコンポーネントに変更はありません。

同じクラウドサービスで (異なるロールについて) 複数のスケール呼び出しがほぼ同時に発生した場合、競合状態が原因で、Microsoft プラットフォームのコンポーネントが非同期状態になり、エラーにつながることがあります。 Microsoft はこの問題の解決に積極的に取り組んでいます。 一時的に推奨されている回避策は、すべてのロールを同時に自動スケーリングしないことです。

ロール インスタンスの設計、アーキテクチャ、コンポーネントに変更はありません。

ロールアウト方法に変更はありません。 Cloud Services (クラシック) と Cloud Services (延長サポート) では、同じ更新プログラムが取得されます。

Cloud Services (延長サポート) のデプロイでは、停止済み、割り当て済み状態のみサポートされます。これは、Azure portal では "停止済み" と表示されます。 停止済み、割り当て解除済み状態はサポートされていません。

Cloud Services (延長サポート) のデプロイでは、複数のクラスター、可用性ゾーン、リージョン間のスケーリングはできません。

プライベート ID とも呼ばれるデプロイ ID には、CloudServiceInstanceView API を使用してアクセスできます。 また、Azure portal 内、Cloud Service (延長サポート) の [ロールとインスタンス] ブレードからもアクセスできます

Cloud Services (延長サポート) では、Azure Key Vault と基本 (Azure Resource Manager) パブリック IP アドレスが使用されます。 証明書を必要とするお客様は、証明書の管理に Azure Key Vault を使用する必要があります (Azure Key Vault の価格の詳細をご確認ください)。 Cloud Services (延長サポート) の各パブリック IP アドレスは個別に課金されます (パブリック IP アドレスの価格の詳細をご確認ください)。

帯域幅課金のバグは 2022 年 11 月に修正されました。その結果、他のリージョンまたはインターネットへのデータ転送 (送信) に基づいて課金が増加する可能性があります。 詳細については、Azure 帯域幅の価格に関するページを参照してください。

Cloud Services (延長サポート) のサービス レベル アグリーメント (SLA) は、Cloud Services (クラシック) の SLA と同じです。 ライセンスに関するドキュメントを参照してください。

ロード バランサー、ネットワーク セキュリティ グループ、ルート テーブルは、同じリージョンとリソース グループに配置する必要があります。

Key Vault、仮想ネットワーク、パブリック IP アドレス、ネットワーク セキュリティ グループ、ルート テーブルは、同じリージョンに配置する必要があります。

パブリック IP アドレス、ロード バランサー、ネットワーク セキュリティ グループ、ルート テーブルは、同じ仮想ネットワークに配置する必要があります。

REST、PowerShell、CLI を使用して、テンプレートとパラメーターのファイルをパラメーターとして渡すことができます。 また、Azure portal を使用して、これらをアップロードすることもできます。

テンプレートとパラメーターのファイルは、デプロイの自動化にのみ使用されます。 Cloud Services (クラシック) と同様に、最初に依存リソースを手動で作成し、次に PowerShell、CLI コマンドを使用して、またはポータルで既存の csdef、cscfg を使用して、Cloud Services (延長サポート) のデプロイを作成できます。

cspkg にパッケージされているアプリケーション コードに必要な変更はありません。 既存のアプリケーションは、以前と同じように引き続き動作します。

CTP パッケージ形式は Cloud Services (延長サポート) ではサポートされていません。 ただし、800 MB の拡張パッケージ サイズ制限は許可されています。

CSES はマネージド ID サポートに対応していません。 そのため、設定で選択された仮想ネットワークのみがストレージ アカウントで有効になっている場合、ストレージ アカウントでは設計上、CSES によるパッケージ ファイルへのアクセスが許可されません。

いいえ。Cloud Service (延長サポート) のデプロイは、Cloud Services (クラシック) と同様にクラスターに関連付けられています。 そのため、クラスターがいっぱいになった場合、割り当てエラーは引き続き発生します。

移行に必要な時間と複雑さの見積もりは、さまざまな不確定要素によって異なります。 移行の作業範囲、阻害要因、複雑さを理解するためには、計画を立てることが最も効果的な手順です。

仮想ネットワークは、Azure Resource Manager でのすべてのデプロイに必要なリソースです。 Cloud Services (延長サポート) のデプロイは、仮想ネットワーク内に配置する必要があります。

Azure Resource Manager では、可視性と制御を向上させるために、お使いの Cloud Services (延長サポート) のデプロイのコンポーネントがリソースとして公開されます。 同じ種類のリソースが Cloud Services (クラシック) で使用されていましたが、非表示になっていました。 このようなリソースの 1 つの例として、パブリック ロード バランサーがあります。これは、現在、プラットフォームによって自動的に作成される明示的な "読み取り専用" リソースです。

Cloud Services (延長サポート) のデプロイを含むサブネットは、Virtual Machines、Virtual Machines Scale Sets、Service Fabric などの他のコンピューティング製品のデプロイと共有できません。

Cloud Services (延長サポート) では、動的および静的 IP 割り当て方法がサポートされています。 静的 IP アドレスは、cscfg ファイルで予約済み IP として参照されます。

お客様は、ユーザーが仮想マシンに関連する IP アドレスについて課金されるのと同じように、Cloud Services (延長サポート) での IP アドレスの使用について課金されます。

デプロイの更新中またはアップグレード中に、予約済み IP を追加、削除、または変更することはできません。 IP アドレスを変更する必要がある場合は、スワップ可能なクラウドサービスを使用するか、Azure DNS\Traffic Manager に CName を持つ 2 つの Cloud Services をデプロイして、IP がそれらのどちらかを指すようにします。

はい。 Cloud Services (延長サポート) に DNS 名を付けることもできます。 Azure Resource Manager では、DNS ラベルは、Cloud Service に割り当てられるパブリック IP アドレスのオプション プロパティです。 Azure Resource Manager ベースのデプロイの DNS 名の形式は、<userlabel>.<region>.cloudapp.azure.com です。

不正解です。 仮想ネットワークの参照は、クラウド サービスの作成時に必須です。 既存のクラウド サービスの場合、仮想ネットワークの参照を変更することはできません。 仮想ネットワークのアドレス空間自体は、仮想ネットワーク API を使用して変更できます。

Cloud Services (延長サポート) では、カスタマー マネージド Key Vault 内に証明書が格納される他のコンピューティング オファリングと同じプロセスが採用されています。 このプロセスにより、お客様はシークレットと証明書を完全に制御できます。

不正解です。 Key Vault はリージョン別のリソースであるため、お客様は、リージョンごとに 1 つの Key Vault を使用する必要があります。 ただし、1 つの Key Vault を、特定のリージョン内のすべてのデプロイに使用することは可能です。

はい。 Cloud Services でのクロス サブスクリプションのキー コンテナー参照は許可されません。これにより、CS-ES による特権攻撃のエスカレーションを防ぐことができます。 このサブスクリプションは、CS-ES がシークレットを参照するために使用する境界ではありません。 相互サブスクリプション参照を許可しない理由は、悪意のあるユーザーが特権エスカレーション メカニズムとして CS-ES を使用して他のユーザーのシークレットにアクセスすることを防ぐための重要な最終手順としてです。 サブスクリプションはセキュリティの境界ではありませんが、多層防御が必要です。 ただし、Key Vault 拡張機能を使用して、証明書のクロス サブスクリプションとリージョン間サポートを取得することができます。 こちらのドキュメントを参照してください

はい。 領域の境界を適用する理由は、ユーザーがリージョン間の依存関係を持つアーキテクチャを作成できないようにするためです。 リージョン分離は、クラウドベースのアプリケーションの主要な設計原則です。 ただし、Key Vault 拡張機能を使用して、証明書のクロス サブスクリプションとリージョン間サポートを取得することができます。 こちらのドキュメントを参照してください

同じクラウドサービスで (異なるロールについて) 複数のスケール呼び出しがほぼ同時に発生した場合、競合状態が原因で、Microsoft プラットフォームのコンポーネントが非同期状態になり、エラーにつながることがあります。 Microsoft はこの問題の解決に積極的に取り組んでいます。 一時的に推奨されている回避策は、すべてのロールを同時に自動スケーリングしないことです。

このシナリオは、Visual Studio 経由ではサポートされません。 PowerShell または Portal を使用してデプロイしてください。

次のステップ

Cloud Services (延長サポート) の使用を開始するには、PowerShell を使用した Cloud Service (延長サポート) のデプロイに関する記事を参照してください。