Azure Policy
この記事では、DevOps のプラクティスを中断することなく、仮想マシン (VM) コンプライアンスを管理する方法について説明します。 Azure VM Image Builder と Azure Compute Gallery を使用すると、システム イメージからのリスクを最小限に抑えることができます。 ソリューションは、ゴールド イメージ発行プロセスと VM コンプライアンス追跡プロセスで構成されます。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
データ フロー
次のセクションでは、このソリューションの 2 つのプロセスについて説明します。
ゴールデン イメージの公開
次のデータ フローは、前の図に対応しています。
毎月、ゴールデン イメージ発行プロセスでは 、Microsoft Marketplace から基本イメージがキャプチャされます。 ゴールデン イメージは、Marketplace イメージの公開バージョンです。
VM Image Builder によって、イメージがカスタマイズされます。
画像入れ墨プロセスでは、ソースや公開日などの画像バージョン情報が追跡されます。
自動テストによってイメージが検証されます。
イメージのテストが失敗した場合は、修復のためのカスタマイズ手順に戻ります。
公開処理により、完成したイメージが公開されます。
Compute Gallery で、DevOps チームがイメージを使用できるようになります。
VM コンプライアンスの追跡
このアーキテクチャの Visio ファイルをダウンロードします。
次のデータ フローは、前の図に対応しています。
VM コンプライアンス追跡プロセスでは、Azure Policy を使用して VM にポリシー定義を割り当て、VM のコンプライアンスを評価します。
Azure Policy によって、VM とその他の Azure リソースのコンプライアンス データが Azure Policy ダッシュボードに公開されます。
Components
VM Image Builder は、システム イメージをカスタマイズするためのマネージド サービスです。 DevOps チームが使用するイメージを構築します。 このアーキテクチャでは、VM Image Builder によって Marketplace から月単位の基本イメージがキャプチャされ、強化された変更が適用され、エージェントがインストールされます。 このプロセスでのイメージのビルドはゴールデン イメージです。
コンピューティング ギャラリー は、カスタム VM イメージを格納および整理するための Azure サービスです。 イメージの管理を一元化し、内部チームと承認した外部テナントのアクセスを制御します。 このアーキテクチャでは、コンピューティング ギャラリーには、DevOps チームが使用する必要があるゴールデン イメージが格納されます。 Azure Policy では、DevOps チームがこのギャラリー内のイメージからのみ VM をプロビジョニングすることを強制します。
Azure Policy は、ポリシー定義を提供する Azure ガバナンス サービスです。 これらの定義を使用して、組織の標準を適用し、大規模なコンプライアンスを評価できます。 Azure Policy ダッシュボードには、Azure Policy の評価結果が表示され、リソースのコンプライアンス状態に関する情報が常に表示されます。 このアーキテクチャでは、Azure Policy は VM にポリシー定義を割り当て、コンプライアンスを評価し、結果を Azure Policy ダッシュボードに発行し、DevOps チームがコンピューティング ギャラリー イメージのみを使用するように制限します。
Azure Policy の Azure マシン構成機能は、コードを使用して構成を動的に監査またはマシンに割り当てる方法を提供します。 通常、構成には環境または OS の設定が含まれます。 このアーキテクチャでは、Azure Machine Configuration が、イメージのカスタマイズによって確立された構成設定を監査し、構成のずれが発生した場合には、Azure Policy ダッシュボードで VM を非準拠としてマークします。
Alternatives
Microsoft 以外のツールを使用してコンプライアンスを管理できます。 通常、ターゲット VM にエージェントをインストールする必要があり、ライセンス料金を支払う必要がある場合があります。
カスタム スクリプト拡張機能を使用して、VM にソフトウェアをインストールしたり、デプロイ後に VM を構成したりできます。 各 VM または仮想マシン スケール セットは、1 つのカスタム スクリプト拡張機能のみをサポートします。
シナリオの詳細
コンプライアンス規制、セキュリティ標準、許容されるリスク レベルは、組織や地域によって異なります。
クラウド環境を動的にスケーリングする場合、オンプレミス システムの場合と異なる標準に従うのが難しい場合があります。 チームが DevOps プラクティスを使用する場合、多くの場合、VM などの Azure リソースを作成できるユーザーに対する制限が少なくなります。 この柔軟性により、コンプライアンスの取り組みが複雑になります。
Azure Policy とロールベースのアクセス制御 (RBAC) の割り当ては、企業が Azure リソースに標準を適用するのに役立ちます。 ただし、VM の場合、これらのコントロールはコントロール プレーンまたは VM へのルートにのみ適用されます。 VM 上で実行されるシステム イメージは、セキュリティ上の脅威となります。 一部の企業では、開発者が VM にアクセスできなくなるため、機敏性が低下し、DevOps のプラクティスに従うのが困難になります。
このソリューションでは、VM Image Builder、コンピューティング ギャラリー、Azure Policy を使用して、Azure での VM コンプライアンスを管理します。 コンプライアンスを追跡し、VM で実行されるシステム イメージからのリスクを最小限に抑え、DevOps プラクティスをサポートします。
考えられるユース ケース
組織で VM を使用していて、次の操作を行う必要がある場合は、このソリューションを使用します。
DevOps チームにゴールデン イメージを提供します。
DevOps チームが使用できるようにする前に、イメージをテストして検証します。
各 DevOps チームが使用するイメージを追跡します。
生産性を損なうことなく、会社の標準を適用します。
DevOps チームが最新のイメージ バージョンを使用していることを確認します。
メンテナンスを集中的に行う ペットサーバーと、簡単に交換できる 牛サーバーのコンプライアンスを管理します。
Approach
以下のセクションでは、ソリューションのアプローチの詳細について説明します。
ペットと家畜を識別する
DevOps チームは、 ペットと牛の 類推を使用してサービス モデルを定義します。 VM のコンプライアンスを追跡するには、まず、それがペットか牛サーバーかを判断します。
ペットサーバーには大きな注意が必要であり、交換が容易ではありません。 ペット サーバーの回復には、かなりの時間と財務リソースが必要です。 たとえば、SAP が実行されているサーバーは、ペットである可能性があります。 サーバー上のソフトウェア以外にも、他の考慮事項によってサービス モデルが決まります。 また、障害許容度が低い場合は、リアルタイムおよびほぼリアルタイムのシステムの運用サーバーをペットにすることもできます。
牛サーバーは同じグループの一部であり、交換が簡単です。 たとえば、仮想マシン スケール セットで実行される VM は牛です。 テスト環境サーバーは、次の条件を満たす牛のもう 1 つの例です。
- 自動化された手順を使用して、サーバーを最初から作成する。
- テストを実行した後、サーバーの使用を停止します。
環境には、ペット サーバーのみ、または牛サーバーのみが含まれる場合があります。 これに対し、環境内の一連の VM がペットになることがあります。 同じ環境内の別の一連の VM が家畜であることがあります。
ペットと牛の環境では、コンプライアンスに関する考慮事項が異なります。
ペットのコンプライアンスは、家畜のコンプライアンスよりも追跡するのが困難な場合があります。 通常、ペットの環境とサーバーのコンプライアンスを追跡して管理することができるのは、DevOps チームのみです。 このソリューションにより、組織内のすべてのユーザーがコンプライアンスを追跡できるように、各ペットの状態の可視性が向上します。
牛の環境では、VM を更新し、コンプライアンスを維持するために定期的にゼロから再構築します。 この更新サイクルを DevOps チームの通常のリリース周期に合わせることができます。
イメージを制限する
DevOps チームが Marketplace VM イメージを使用することを許可しないでください。 Compute Gallery によって公開される VM イメージのみを許可します。 この制限は、VM のコンプライアンスに不可欠です。 Azure Policy のカスタム ポリシーを使用すると、この制限を適用できます。 サンプルについては、イメージの公開元の許可を参照してください。
このソリューションの一部として、VM Image Builder は Marketplace イメージを使用する必要があります。 Marketplace で利用可能な最新のイメージを使用することが重要です。 そのイメージの上にカスタマイズを適用します。 Marketplace イメージは頻繁に更新され、イメージを既定でセキュリティで保護する事前設定が含まれています。
イメージをカスタマイズする
ゴールデン イメージは、DevOps チームが使用するためにコンピューティング ギャラリーに発行する、カスタマイズされたバージョンの Marketplace イメージです。 カスタマイズのアクティビティは各企業に固有です。 一般的なアクティビティには、以下のものがあります。
OS のセキュリティ強化
Microsoft 以外のソフトウェア用のカスタム エージェントの展開
エンタープライズ証明機関 (CA) ルート証明書のインストール
VM Image Builder を使用して、OS 設定を調整し、カスタム スクリプトとコマンドを実行することで、イメージをカスタマイズできます。 VM Image Builder では、Windows と Linux のイメージがサポートされます。 詳細については、 Azure Virtual Machines の Azure Policy 規制コンプライアンス制御に関するページを参照してください。
Important
Azure 仮想ネットワークは、送信接続がないプライベート サブネットに既定で設定されます。 VM Image Builder ビルドで、更新プログラムのダウンロードなどの送信インターネット アクセスが必要な場合は、指定したサブネットで送信アクセスを明示的に構成する必要があります。
信頼できる起動を使用してイメージを強化する
アプリケーション レベルのカスタマイズ以外に、ゴールデン イメージは、ブートから実行時までのハードウェアルートの信頼チェーンを確立する必要があります。 信頼できる起動は、第 2 世代 VM にこの基盤を提供します。 次の Trusted Launch 機能を使用してゴールデンイメージを構成します。
セキュア ブート: 起動時に、署名済みの信頼された OS ローダー、カーネル、ドライバーのみが実行されるようにします。 この方法では、ブートキットとルートキットから保護します。
仮想トラステッド プラットフォーム モジュール (vTPM): VM 内のハードウェアトラステッド プラットフォーム モジュール (TPM) をエミュレートし、暗号化キー、証明書、およびブート測定用のセキュリティで保護されたストレージを提供します。 vTPM では、BitLocker ディスク暗号化や暗号化ゲスト構成証明などのシナリオがサポートされています。
ブート整合性の監視: ブート チェーン全体を測定し、テレメトリを Microsoft Defender for Cloud に表示します。
Note
すべての VM サイズと OS イメージでトラステッド起動がサポートされているわけではありません。 イメージの検証手順中に互換性を確認します。
イメージタトゥーを追跡する
イメージの入れ墨は、VM が使用するすべてのイメージ バージョン管理情報を追跡するプロセスです。 この情報は、トラブルシューティング時に非常に貴重であり、次のような情報が含まれます。
発行元の名前やバージョンなど、イメージの元のソース。
インプレースアップグレードの OS バージョン文字列。
カスタム イメージのバージョン。
あなたの公開日。
追跡する情報の量と種類は、組織のコンプライアンス レベルによって異なります。
Windows VM のイメージ タトゥーの場合は、カスタム レジストリを設定します。 必要なすべての情報をこのレジストリ パスにキーと値のペアとして追加します。 Linux VM では、イメージの入れ墨データを環境変数またはファイルに入力します。 開発者の作業やアプリケーションと競合しない /etc/ フォルダーにファイルを配置します。 Azure Policy を使用して入れ墨データを追跡またはレポートするには、各データを一意のキーと値のペアとして格納します。 詳細については、「 Marketplace イメージのバージョンを検索する」を参照してください。
ゴールデン イメージのソフトウェア部品表を生成する
画像の入れ墨は、ソース、バージョン、公開日など、イメージに関するメタデータを記録します。 ソフトウェア部品表 (SBOM) は、OS パッケージ、エージェント、ライブラリ、パッチなど、イメージ内の内容を記録することで入れ墨を補完します。 このインベントリは、脆弱性対応、コンプライアンス監査、サプライ チェーンの透明性をサポートします。
ゴールデンイメージ向けのSBOMは、次の点で役立ちます。
一般的な脆弱性と露出 (CVE) 応答の高速化: 重大な脆弱性が開示されると、SBOM は、影響を受けるコンポーネントを含むゴールデン イメージ バージョンを識別します。
規制コンプライアンス: 規制に関する法律や標準では、多くの場合、ソフトウェア成果物に対して SBOM が必要です。 VM イメージは、そのソフトウェア サプライ チェーンの一部です。
監査の追跡可能性: イメージタトゥーと SBOM を組み合わせることで、監査担当者は VM で使用されているイメージと、ビルド時にそのイメージに含まれるソフトウェアコンポーネントの全容を把握できます。
イメージのビルド中に SBOM を生成する
カスタマイズの直後と検証の前に、SBOM 生成を VM Image Builder パイプラインのステップとして追加します。
オープン ソースの Microsoft SBOM ツール を使用して、 SPDX 形式の SBOM を生成します。 このツールは、インストールされている OS パッケージ、エージェント、および依存関係を列挙します。 カスタマイズされたイメージに対して、VM Image Builder のカスタマイズ手順として、またはパイプラインのカスタマイズ後スクリプトとしてツールを実行します。 生成された SBOM に暗号で署名し、その整合性を確保します。
SBOM をイメージと共に格納します。 SBOM を Azure Storage アカウントまたはコンピューティング ギャラリー イメージ バージョンにリンクされたアーティファクト ストアにアップロードします。 各 SBOM ファイルをイメージ定義、バージョン、ビルド日にマップする一貫した名前付け規則を使用します。 イメージ バージョンが使用中である限り、SBOM は少なくとも使用可能な状態に保ちます。
自動テストを使用してゴールデン イメージを検証する
一般に、最新の更新プログラムと Marketplace イメージの変更を最新の状態に保つには、ゴールデン イメージを毎月更新する必要があります。 このためには、繰り返しのテスト手順を使用します。 イメージ作成プロセスの一環として、テストに Azure パイプラインまたは他の自動化されたワークフローを使用します。 毎月初めまでにテストを実行する新しい VM をデプロイするようにパイプラインを設定します。 テストでは、使用するために発行する前に、準備されたイメージを確認する必要があります。 テスト自動化ソリューションを使用するか、VM でコマンドまたはバッチを実行して、テストを自動化します。
一般的なテスト シナリオは次のとおりです。
VM の起動時間を検証します。
OS 構成設定やエージェントのデプロイなど、イメージのカスタマイズを確認します。
テストに失敗したら、プロセスが中断される必要があります。 問題の根本原因に対処した後、テストを繰り返します。 テストがスムーズに実行される場合、テストプロセスを自動化することで、常に最新の状態を維持するための作業が軽減されます。
ゴールデン イメージを公開する
DevOps チームが使用できるマネージド イメージとして、コンピューティング ギャラリーで最終的なイメージを発行します。 以前の画像を古いとしてマークします。 Compute Gallery でイメージ バージョンの有効期限を設定していない場合は、会社のポリシーに基づいて最も古いイメージを廃止することを検討してください。
Note
コンピューティング ギャラリーの 論理的な削除機能 (プレビュー) では、誤って削除されたイメージに対して 7 日間の復旧期間が提供されます。 意図しない画像の損失から保護するために、ギャラリーで論理的な削除を有効にすることを検討してください。
コンピューティング ギャラリーの使用時に適用される制限の詳細については、「 コンピューティング ギャラリーでイメージを格納および共有する」を参照してください。
異なるリージョン間で最新のイメージを公開することをお勧めします。 コンピューティング ギャラリーを使用して、さまざまな Azure リージョン間でのイメージのライフ サイクルとレプリケーションを管理できます。
ゴールデン イメージを更新する
アプリケーションでイメージを使用する場合、基になる OS イメージは、最近のコンプライアンスの変更で更新するのが難しい場合があります。 厳しいビジネス要件の場合、基になる VM を更新するプロセスが複雑になる可能性があります。 更新は、ビジネスクリティカルな VM でも複雑です。
使い捨て可能なサーバーなので、DevOpsチームと調整して、計画されたメンテナンス期間に定期的な作業として更新できます。
ペットサーバーは更新が困難です。 イメージを廃止すると、アプリケーションが危険にさらされる可能性があります。 スケールアウト シナリオでは、Azure でそれぞれのイメージが見つからないため、エラーが発生します。
ペット サーバーを更新する場合は、次のガイドラインを考慮してください。
ベスト プラクティスについては、Azure Well-Architected Framework の 信頼性の柱の概要 を参照してください。
プロセスを簡略化するには、次の記事の原則を参照してください。
各ペット サーバーをペットとしてタグ付けします。 更新中にこのタグを考慮するように Azure Policy でポリシーを構成します。
Note
VM Image Builder では、ビルド パイプラインが特定の条件を満たしている場合に、イメージの自動作成がサポートされます。 VM Image Builder でトリガーを設定して、イメージを毎月自動的に更新します。 詳細については、「 VM Image Builder トリガーを使用してイメージの自動作成を有効にする」を参照してください。
重大な脆弱性に対する緊急パッチの適用
毎月のゴールデン イメージの更新頻度は定期的な更新に適していますが、重大なセキュリティ脆弱性と CVE は、次のスケジュールされたサイクルの前にアクションを必要とします。 毎月の周期とは無関係に実行され、オンデマンドでトリガーされる帯域外 (OOB) 緊急パッチ適用プロセスを確立します。 ベース イメージに影響を与える CVE アラートについて 、Azure Service Health と Microsoft Security Response Center の通知をサブスクライブします。
重要な CVE が公開されたゴールデン イメージに影響する場合は、脆弱なバージョンで新しい VM をプロビジョニングしないように直ちに対処してください。 まず、影響を受けるイメージバージョンを、ユーザーまたは自動化が最新バージョンを要求したときに Azure が選択するイメージ バージョンから除外されるようにマークします。 コンピューティング ギャラリーで、影響を受けるすべてのイメージ バージョンで excludeFromLatest プロパティを true に設定します。 この変更後、自動化と、使用可能な最新バージョンを要求するユーザーは、脆弱なバージョンを受け取らなくなります。 Azure Policy の割り当ての説明を使用して、CVE、影響を受けるイメージのバージョン、および必要な修復アクションを一覧表示する Runbook または内部 Wiki にリンクします。
OOB イメージ ビルドをトリガーする
毎月のゴールデン イメージを生成するのと同じ VM Image Builder パイプラインを使用しますが、必要に応じてトリガーします。
セキュリティパッチを適用します。 OS の更新、構成の変更、または特定の脆弱性を修復するスクリプトとして、イメージのカスタマイズ手順に重要な修正プログラムを追加します。
自動テスト スイートを実行します。 検証をスキップしないでください。 毎月のサイクル中に実行されるのと同じテストは、緊急ビルドに対して実行する必要があります。
修正プログラムが適用されたイメージを発行します。 新しいイメージ バージョンをコンピューティング ギャラリーに発行し、必要なすべてのリージョンにレプリケートします。 影響を受けるバージョンは最新バージョンの選択から除外されるため、修正プログラムが適用されたバージョンは、新しいデプロイで使用されるバージョンになります。
イメージのタトゥーを更新します。 イメージの入れ墨に更新プログラムの OOB の性質を記録し、CVE 識別子、パッチの日付、およびスケジュールされた毎月のリリースと区別するフラグを含めます。 このデータは、コンプライアンス監査をサポートします。
Important
OOB パッチ適用は月単位の周期を補完しますが、置き換えることはありません。 定期的な毎月の更新を続行して累積的な更新プログラムをキャプチャし、緊急プロセスを使用して、迅速な対応を必要とする脆弱性に厳密に対処します。
可視性の向上
一般に、Azure Policy を使用してコントロール プレーン コンプライアンス アクティビティを管理する必要があります。 Azure Policy を使用して、次のタスクを実行することもできます。
VM コンプライアンスを追跡します。
Azure エージェントをインストールします。 監視には Azure Monitor エージェント を使用します。
診断ログをキャプチャします。
VM コンプライアンスの可視性を向上させます。
Azure マシン構成を使用して、イメージのカスタマイズ中に行った構成の変更を監査します。 誤差が発生すると、Azure Policy ダッシュボードに、影響を受ける VM が非準拠として一覧表示されます。 Azure Policy では、イメージ タトゥーを使用して、古いイメージやオペレーティング システムがいつ使用されたかを追跡できます。
各アプリケーションのペット サーバーを監査します。 監査効果がある Azure ポリシーを使用して、これらのサーバーの可視性を向上させることができます。 会社の許容されるリスク レベルと内部リスク管理プロセスに従って監査プロセスを調整します。
各 DevOps チームは、Azure Policy ダッシュボードでアプリケーションのコンプライアンス レベルを追跡し、適切な是正措置を実行できます。 これらのポリシーを管理グループまたはサブスクリプションに割り当てる場合は、ポリシーに関する会社全体のドキュメントの URL を割り当ての説明に含めます。 ドキュメントには、DevOps チームが VM を準拠させるために従う必要がある手順が記載されている必要があります。
IT リスク マネージャーとセキュリティ責任者は、Azure Policy ダッシュボードを使用して、会社の許容されるリスク レベルに従って会社のリスクを管理することもできます。
修復オプションを使用した Azure マシンの構成では、修正アクションが自動的に適用されます。 ただし、ビジネス クリティカルなアプリケーションに使用する VM に対する頻繁なクエリや変更は、パフォーマンスに影響する可能性があります。 実稼働ワークロードの修復アクションは慎重に計画してください。 すべての環境でアプリケーション コンプライアンスの DevOps チームの所有権を割り当てます。 このアプローチは、通常は長期的な Azure コンポーネントであるペット のサーバーと環境に使用します。
ゴールデンイメージ衛生管理のベストプラクティス
適切に構造化されたイメージ ビルド プロセスにより、セキュリティ インシデント、構成の誤差、運用上の摩擦につながる一般的なミスを防ぐことができます。 ゴールデン イメージをカスタマイズして維持する場合は、次のガイドラインに従ってください。
シークレットをイメージにベイクしないでください。 API キー、接続文字列、パスワード、証明書の秘密キー、またはトークンをイメージに埋め込むことはありません。 イメージにシークレットを埋め込む場合は、イメージを使用するすべての VM と、コンピューティング ギャラリーへの読み取りアクセス権を持つすべてのユーザーに公開します。 代わりに、マネージド ID を使用して、実行時に Azure Key Vault からシークレットを取得します。
ハードコーディングされた値よりも外部構成を優先します。 エンドポイント、機能フラグ、地域設定、ログ レベルなど、環境間または次のイメージ ビルドの前に変更される可能性がある設定を外部化します。 すべてのデプロイで静的でユニバーサルな設定用にイメージのカスタマイズを予約します。
ソフトウェアフットプリントを最小限に抑えます。 イメージのすべてのコンシューマーが必要とするコンポーネントのみをインストールします。 拡張機能または構成管理を使用して、プロビジョニング後に 1 つのユース ケースまたはワークロードに固有の追加のツールをデプロイします。 フットプリントが小さいと、攻撃対象領域と、修正プログラムを適用する必要があるコンポーネントの数が減ります。
アプリケーション コードとデプロイ成果物をイメージから除外します。 ゴールデン イメージは、セキュリティで保護された準拠した OS 基盤を提供する必要があります。 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用して、アプリケーション コードを個別にデプロイします。 この分離により、イメージのライフ サイクルとアプリケーションのライフ サイクルが独立して維持されます。
確定的で反復可能なビルド スクリプトを使用します。 カスタマイズ スクリプトでパッケージバージョンをピン留めします。 ビルド日ごとに異なるイメージを生成できる
apt-get upgradeやyum updateなどのコマンドは使用しないでください。
Considerations
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。
Reliability
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性
このソリューションでは、リージョン レベルで自動的な回復性があるマネージド コンポーネントを使用します。 詳細については、 Azure の回復性のあるアプリケーションの設計に関するページを参照してください。
コンピューティング ギャラリーに格納される各イメージのレプリカの数を構成できます。 レプリカの数が多いほど、複数の VM を同時にプロビジョニングするときの調整のリスクが軽減されます。 詳細については、「 コンピューティング ギャラリーのスケーリング」を参照してください。
コストの最適化
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コストの最適化
Microsoft サービスのみを使用する場合は、Ansible や Terraform などの Microsoft 以外のツールの追加コストを回避できます。 ただし、ストレージ、エグレス、イメージの構築、レプリケーション、ハイブリッド リソースには引き続き Azure の料金が適用されます。 また、次のコンポーネントでは料金が発生することがあります。
Azure Policy と Azure マシンの構成 は、Azure リソースに対して無料です。 会社でハイブリッド アプローチを使用している場合は、Azure Arc リソースに追加料金が追加されます。
VM Image Builder では、1 つのコンピューティング インスタンスの種類と 1 つの vCPU と 3.5 GB の RAM が使用されます。 データの保存と転送に料金が適用される場合があります。
コンピューティング ギャラリー では、レプリカ ストレージとイメージ レプリケーションに関連付けられているネットワーク エグレスに対してのみ料金が発生します。
Contributors
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
主要著者:
- Yunus Emre Alpozen | プログラム アーキテクト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ
- Azure ランディング ゾーン
- クラウド インフラストラクチャの概要
- VM イメージ ビルダー
- コンピューティング ギャラリー
- Azure Policy とポリシー ダッシュボード
- Azure マシンの構成