Skip to content

Instantly share code, notes, and snippets.

@koudaiii

koudaiii/1.md

Last active August 28, 2025 07:47
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save koudaiii/17d9d62238b10481ffd478583efb566b to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save koudaiii/17d9d62238b10481ffd478583efb566b to your computer and use it in GitHub Desktop.
Download ZIP
第13回 「Azure Verified Modules ってなーに？」
Raw
1.md

ライブ配信 第13回 「Azure Verified Modules ってなーに？」

https://msdevjp.connpass.com/event/367122/

Developers Night Cafe くらでべチャンネル ライブ配信 8月28日(木) YouTube https://youtube.com/live/927MktvN7_E

これは Microsoft が提供する公式の Infrastructure as Code (IaC) モジュール ライブラリ であり、Bicep と Terraform の両方に対応した再利用可能なテンプレート群です。クラウド環境の構築・管理において一貫性やベストプラクティス遵守を容易にし、インフラ構築の効率化と標準化を実現することが目的です。

アジェンダ

  1. Azure Verified Modules の概要と目的 – AVMが生まれた背景と解決する課題、メリット
  2. モジュールの種類 – Resource/Pattern/Utility 各モジュール種別の特徴と役割
  3. AVMの利用方法（Bicep & Terraform） – モジュールの入手・統合方法とIaCへの組み込み方
  4. 実践ユースケース・利用例 – AVMを使った典型的な環境構築例と効果、導入事例
  5. コミュニティと貢献方法 – GitHubを通じたモジュールへの貢献手順とガバナンス
  6. 最新情報とFAQ – AVMに関する最新のアップデート、ワークショップやFAQ情報

1. Azure Verified Modules の概要と目的

Azure Verified Modules (AVM) は、Microsoft が公式に開発・維持する検証済みのIaCモジュール集です1。Azureリソースをデプロイするための再利用可能なテンプレートが事前定義されており、小規模なアプリケーションから大規模なシステムまで、Azure環境の構築管理で高い一貫性と信頼性を発揮します1。AVMが目指すのは「高品質なIaCモジュールをワンストップで提供し、Azure上のインフラ展開を加速する」ことです2。具体的には以下のような課題を解決します。

  • 従来、AzureポータルからのエクスポートやOSSツールを用いて既存環境をコード化することも可能でしたが、そのままではメンテナンスが大変でベストプラクティスに沿った構成になっている保証もありませんでした。AVMはそのギャップを埋めるために誕生しました。
  • 毎回インフラ構成を書き起こす手間の削減: 標準化されたモジュールを使うことで、仮想ネットワークやストレージアカウント等のリソースをゼロから記述・テストする手間を省けます3（「車輪の再発明」の防止）。
  • ベストプラクティスの即適用: セキュリティ設定やタグ付けなど、Azureの推奨設定があらかじめ組み込まれており、利用者は意識せずともWell-Architected Framework (WAF) に沿った構成をデプロイできます14。例えば多くのモジュールでTLS1.2の強制やストレージのPublicアクセス禁止などがデフォルト設定となっています4。
  • 設定の一貫性: リソース名や場所、タグといった共通パラメータは統一的なインターフェースで扱われ、複数モジュール間でばらつきが生じません33。その結果、開発チーム間・環境間で同じ設定が再現され、環境差異による不具合を減らせます。

こうした特徴により、AVMはクラウドインフラ構築の標準化と迅速化を実現します。そのミッションはMicrosoft自身が「複数のIaC言語で包括的なモジュール ライブラリを提供し、Microsoftが信頼するソース（Single Source of Truth）となること」と表明している通りです2。

AVMの主なメリット

AVMを活用することで得られる代表的なメリットをまとめます。

  • 標準化と一貫性: すべてのモジュールが統一された構成基準・フォルダ構造で作られており、誰がデプロイしても似た構成になります5。例えば仮想マシンのデプロイ方法がプロジェクト毎に異なる、といった事態を避けられます。
  • 公式サポートと継続性: Microsoft によって公式にサポート・メンテナンスされているため、Azureの新機能への追随や不具合修正が継続的に行われます5。長期的な利用に耐えるモジュールであり、安心感があります。
  • マルチ言語対応: Bicep と Terraform の両方で利用可能です。社内のIaCツール標準に合わせて使え、将来的に切り替える場合もモジュール設計思想が共通しているため学習コストが低減します52。
  • コンプライアンス遵守: Azure Well-Architected Framework (WAF) や各種セキュリティ ベンチマークの高優先度推奨事項が組み込まれているため、モジュールを使うだけでセキュリティや信頼性の原則を満たしやすくなります5。ガバナンス強化にも有用です。
  • 自動テストとドキュメント: AVMの各モジュールはリリース前に単体テストや統合テストが実施され品質保証されています5。また自動生成される詳細な利用手引きドキュメントが付属し、パラメーターの説明や使用例も明示されています16。これにより利用者は安心してモジュールを導入でき、実装方法もすぐ参照できます。

上記のように、AVMは開発スピードの向上と運用上の安心感を提供する仕組みとして設計されています。23

補足: AVMは従来Microsoft内部やコミュニティで進められていたモジュール集（BicepのCARMLやTerraformのTFVM）の発展形として位置付けられています7。それらの既存資産を統合・改良し、「One Microsoft」の理念で生まれた統合プロジェクトがAVMです7。

2. モジュールの種類と特徴

AVMのモジュールはその用途に応じて3つの分類に分けられています12。理解しておくことで、必要なモジュールを選択しやすくなります。各分類とその特徴は以下の通りです。

image 
    --font: "Segoe Sans", "Segoe UI", "Segoe UI Web (West European)", -apple-system, "system-ui", Roboto, "Helvetica Neue", sans-serif;

上記のように、Resourceは単体リソース志向、Patternはアーキテクチャ志向、Utilityはコード関数志向という違いがあります。それぞれモジュール名にもプレフィックスとしてavm-res- / avm-ptn- / avm-utl-が付与されており判別できます。目的に応じて、**「必要なリソース単位で組み合わせる」場合はResource Moduleを、「一般的な構成をまとめて展開する」**場合はPattern Moduleを選ぶと良いでしょう。11

例: Resource Moduleの例として、avm-res-compute-virtualmachine は仮想マシン (VM) をデプロイするモジュールです。VM本体に加え、関連するNICやディスク、セキュリティ設定（NSGや管理ID割り当て、ログ診断設定など）を包含し、「VMを安全に動かすのに必要なもの一式」をデプロイします1。しかしVMが所属する仮想ネットワークやサブネット自体は利用者が別途用意する想定で、モジュールには含まれていません1。一方でPattern Moduleの例としてavm-ptn-aks-productionは、AKSクラスターというワークロード全体を構成するためのパターンモジュールで、内部で複数のResource Module（AKSやVNet、Container Registry等）を組み合わせて、プロダクション水準のAKS基盤一式をデプロイします55。

補足: Utility Moduleは現在提案段階の新しい概念であり、2025年時点では数も少なく実験的です8。しかし将来的には、複数モジュールで共通的に使われるネーミング規則ロジックやリージョンマップ、設定値の計算などをUtilityとして切り出し、より洗練されたモジュール再利用が可能になると期待されています。2

3. Azure Verified Modules の使い方 (Bicep & Terraform)

続いて、実際にAVMを利用してAzureインフラをデプロイする方法を説明します。AVMモジュールは Bicep でも Terraform でも使用できますが、取得先（レジストリ）や記述方法がそれぞれ少し異なります。それぞれの基本的な使い方とポイントを見てみましょう。

3.1 Bicepでの利用方法

Bicep版のAVMモジュールは、Azure公式のBicepパブリックモジュール レジストリに公開されています6。開発環境（Visual Studio Code + Bicep拡張など）には既定で br/public: というエイリアスが設定されており、これを使って簡単に参照できます6。例えばBicepでストレージアカウントをデプロイするには、次のようにモジュールとして記述します。

module storageAccount 'br/public:avm/res/storage/storage-account:<バージョン>' = {
  name: 'storageDeployment'
  params: {
    name: 'mystorageaccount'
    location: 'japaneast'
    tags: {
      Environment: 'Demo'
    }
    // ... 必要に応じ他のパラメーターを指定 ...
  }
}

上記の例では、avm/res/storage/storage-account というResource Moduleを指定しています（<バージョン>にはバージョン番号を指定）。パラメーターとしてストレージアカウント名やロケーション、タグなどを与えると、モジュール内部で定義されたリソース（Storage Account本体や必要に応じたDiagnostic設定等）がまとめてデプロイされます。各モジュールには必要なパラメーターがドキュメントに明記されており、不明な場合はVS CodeのIntelliSenseで補完候補と説明が表示されます99。Bicepの場合、Azure CLI/PowershellでBicepファイルをデプロイすればバックエンドで自動的にレジストリからAVMモジュールが取得され実行されます。

  • インポートやセットアップ不要: Bicepパブリックレジストリ上のAVMモジュールは特別な認証や事前ダウンロードなしに参照可能です。br/public:avm/...:<version>という書式で記述するだけで、裏で必要なコードが取得されます6。
  • バージョン管理: モジュール識別子にバージョンを指定することで、将来AVM側が更新された際でも意図しない変更が起きないようにできます。例えば:0.3.0など特定バージョンを明示しておくと、同じBicepコードは常にその版のモジュールで動作します。バージョンを上げるときだけモジュールを更新する形です。

Bicep向けAVMモジュールの一覧や使用例は、Azure公式のドキュメントサイトおよびGitHub上のリポジトリに公開されています66。AVMではモジュール名が直感的になるよう命名されているため（例: Key Vaultならavm/res/key-vault/vault）、必要なサービス名で検索すると目的のモジュールが見つかりやすくなっています。各モジュールのREADMEにはパラメーター一覧やデプロイ例が載っているので参照してください。

3.2 Terraformでの利用方法

Terraform版のAVMモジュールは、Terraformの公式モジュールレジストリ（Terraform Registry）に公開されています2。Terraformから利用する際は、モジュールブロック内で source に**Azure/<モジュール名>/azurerm** という指定を行います。例えばTerraformで仮想ネットワーク(VNet)をデプロイする場合、以下のように記述します。

module "network" {
  source  = "Azure/avm-res-network-virtualnetwork/azurerm"
  version = "0.1.0"
  name                = "demo-vnet"
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = ["10.0.0.0/16"]
}

この例では、Azure/avm-res-network-virtualnetwork/azurerm というモジュールソースを指定しています。バージョンも "0.1.0" とピン留めし、パラメーターとして仮想ネットワーク名やリソースグループ名、アドレス空間を渡しています。これにより、指定したAVMモジュールがTerraform実行時に自動取得され、VNet本体と関連する設定（必要に応じてデフォルトのサブネットやセキュリティ設定など）が作成されます。

TerraformでAVMモジュールを使う際のポイント:

  • Terraform Registryから自動取得: 初回実行時（terraform init）に、指定されたAzure/<名前>モジュールがTerraform Registryからダウンロードされキャッシュされます。一度取得すればオフラインでも利用可能です。
  • 名前空間と命名: すべてのAVM TerraformモジュールはAzure名前空間で公開されています。またavm-res-やavm-ptn-で始まり、最後にazurermプロバイダーを示します。この統一された命名により、Azure公式のAVMモジュールであることが一目でわかります2。例えば上記のavm-res-network-virtualnetworkは「Azure公式のAVM版仮想ネットワークモジュール」という意味です。
  • モジュールのバージョン管理: version を指定することで、Terraformでも特定バージョンのモジュールを使用できます。運用中にモジュールのメジャーバージョンを固定することは重要なベストプラクティスです（機能追加やBreaking Changeによる影響を制御するため）2。公式リリースノートやCHANGELOGを確認しながら適宜バージョンアップを検討しましょう。

使用例: TerraformでWindows VMをデプロイする構成を考えてみます。通常であればリソースグループ、ネットワーク、NIC、NSG、ディスク、VM本体…と複数のリソースブロックを記述し、それぞれ関連付ける必要があります。しかしAVMのResource Module 「avm-res-compute-virtualmachine」 を使うと、1つのモジュール呼び出しでこれらが包括的にデプロイされます。実際のコード例では、リソースグループ (avm-res-resources-resourcegroup)、ネットワーク (avm-res-network-virtualnetwork) と併せてVMモジュールを呼び出すだけで、内部で必要なNICやストレージが作成され、NSGルールや動的IP割当などの設定も自動適用されます22。例えば:

module "vm" {
  source  = "Azure/avm-res-compute-virtualmachine/azurerm"
  version = "0.1.0"
  name                       = "demo-vm01"
  resource_group_name        = module.resource_group.name
  location                   = module.resource_group.location
  network_interfaces = {
    nic1 = {
      subnet_resource_id = module.network.subnets["default"].resource_id
    }
  }
  os_type      = "Windows"
  admin_username = "azureuser"
  # ...
}

上記のようなモジュール構成により、ネットワークインターフェイスやOSディスクの紐付けも含め、セキュアなWindowsサーバVMが一度に構築されます。この構成では例えばRDPアクセス用のNSGルールが組み込まれ、パスワード認証情報も安全に扱われ、VMには最新のWindows Serverイメージが適用されます2。つまり、AVMモジュールを使うことで**「自分でベストプラクティスを調べて設定すること」を大幅に省略できるのです。同様に、Terraform Registry上のAVM Moduleカタログから目的のモジュールを探して組み合わせれば、ほぼあらゆるAzureサービスのデプロイに対応できます2。公式ドキュメントの「Module Index」によれば、2025年7月時点で約100個近いResource Moduleと数十のPattern Module**がTerraform向けに公開済みです8。代表的なAzureサービス（VM, VNet, Storage, KeyVault, AKS, APIM, etc.）は網羅されており、必要なものは大抵見つかるでしょう。

🔎 参考情報: 公式のAzure Terraformモジュール リポジトリ（GitHub上の Azure/terraform-azure-modules）にはソースコードや例が公開されています。また、Terraform向けの包括的なラボ資料も提供されており10、AVMを使った環境構築をステップごとに学習できます。AVMを使い始める際は、小規模な環境でモジュール動作を試しながら理解を深めると良いでしょう。

4. AVMの実践ユースケースと利用例

では、AVMが実際の現場でどのように使われ得るか、ユースケースや導入事例をいくつか紹介します。

4.1 典型的な利用シナリオ

  • シナリオ① 単一リソースを素早くセキュアに構築: 例えば「まずはAzureに仮想マシン1台立てて試したい」といった場合、AVMのVM用Resource Moduleを使えば、ネットワークやストレージのベストプラクティス設定も含めて短時間で環境準備ができます。前述のように、モジュール内で必要な構成要素が揃っているため、抜け漏れなく安全なVM環境が構築されます2。このとき繰り返し指定しがちなパラメータ（リソースグループ名や場所など）はモジュール間で使い回せるので、一貫性を保ったまま定型作業を自動化できます4。結果として、手作業や独自コードによるミスを減らし、Azure上での検証を迅速に開始できます。

  • シナリオ② 複数リソースにまたがるパターン展開: より複雑な例として、「Webアプリ用の基盤（フロントエンド+バックエンド+DB）をまとめて用意したい」場合を考えます。AVMのPattern Moduleには、Azureの一般的なアーキテクチャを反映したものがあり、それらを使うとまとまったリソース群を一括デプロイできます1。例えばAKS（Azure Kubernetes Service）を本番水準で構築するavm-ptn-aks-productionモジュールでは、AKSクラスターに加えてそれを支える仮想ネットワークやAzure Container Registryまでも含めてデプロイします55。利用者はクラスター名やリージョンといった基本情報を渡すだけで、複数のサービスが相互に接続された環境が手に入ります。このようにパターンモジュールを使えば、知見の詰まったリファレンス設計をそのまま手元で再現でき、サービス間の組み合わせ検証やPoC環境構築が飛躍的に効率化します。

  • シナリオ③ 既存環境のコード化と標準化: 既にAzure上に手動で構築した環境をコード化（IaC化）し直す際にもAVMは有用です。手作りのTerraformテンプレートを一から書く代わりに、AVMモジュールを組み合わせて同等の構成を再現することで、コードをシンプルに保ちながらAzure推奨構成へアップデートできます。例えば既存の仮想ネットワークやサブネット設定を分析し、対応するavm-res-network-virtualnetworkモジュール＋パラメーターに置き換えることで、将来のメンテナンス性を向上させつつコード化が完了します。AVM経由でIaC化すれば、後述するようなMicrosoftのサポートも受けられるため、社内標準テンプレートとして採用しやすくなる利点もあります。

4.2 導入事例・コミュニティでの活用

  • Microsoft社内外での活用: AVMはMicrosoft自身が提唱する標準ということもあり、Azureエンジニアリング チームやソリューション アーキテクトによって積極的に活用・検証されています。たとえば Microsoftのクラウド支援パートナー企業では、AVMの考え方に沿って独自のモジュールを拡張し、自社向けにカスタマイズした例があります。ドイツのパートナー企業では、自社の知見を加えた独自モジュール群を「GKVM (GlueckKanja Verified Modules)」として作成し、AVMの要件に準拠させつつOSSとして公開する取り組みも行われています4。このように、AVMはオープンな枠組みであり、必要に応じて組織独自のモジュール拡充も可能となっています。

  • Azure Developer CLI との統合: Azure 開発者向けCLIツールである Azure Developer CLI (azd) においても、AVMのモジュールが統合活用され始めています。公式FAQによれば、AZDチームは既にパブリックレジストリ上のBicep版AVMモジュールを取り込みつつあり、将来的にAZDからAVMモジュールを直接利用するシナリオが計画されています7。これにより、開発者がAZDでプロジェクトを初期化する際にAVM準拠のリソース展開が選択肢となり、開発フローにシームレスにAVMを組み込めるようになるでしょう。

  • コミュニティイベントでの注目度: AVMは発表以来、グローバルにも注目を集めています。Microsoft Tech Communityのブログでは定期的にAVMアップデート情報が共有されており、月次のコミュニティコール（外部参加可能なオンライン説明会）も開催されています。日本国内でも、Japan Azure User GroupのイベントでAVMが紹介されるなど（2024年10月のJAZUG14周年イベントなど）、エンジニアコミュニティで情報共有が進んでいます11。こうした場でのフィードバックや要望がAVM改善にもフィードバックされており、オープンソースコミュニティ主導の発展が進んでいます。

  • 導入による効果: 具体的な効果として、「IaC開発の生産性向上」や「構成ミスの削減」が報告されています。あるケースでは、AVMを使うことでTerraformコードの行数が大幅に減り、従来何日もかかっていた環境構築が数時間で完了したとの声もあります（コード行数が減る=レビュー工数やバグも減る）。また **「複数環境で設定の齟齬がなくなった」**というメリットも指摘されています。開発～本番まで同じモジュールを使い回すことで、設定漏れや差異を極小化でき、運用後のトラブル対応コストが下がる効果が期待できます。

5. コミュニティとGitHubでの貢献方法

AVMはオープンソースプロジェクトとしてGitHub上で開発が進められています。社内外のユーザーが参加できるコミュニティ主導のプロジェクトであり、Azureユーザーからのフィードバックや貢献を歓迎しています。ここでは、AVMコミュニティへの参加方法や貢献の仕組みについて紹介します。

5.1 GitHub リポジトリとドキュメント

AVMのソースコードおよびドキュメントは、GitHub上の Azure/Azure-Verified-Modules リポジトリで公開されています。このリポジトリ自体には主にプロジェクト全体の仕様やガイドラインが含まれ、実際の各モジュールコードは別リポジトリ（たとえばTerraform用は Azure/terraform-azurerm-avm-xxx のような個別リポジトリ）で管理されています2。GitHub上のAVM関連主要リポジトリ・ページは以下のとおりです。

  • Azure-Verified-Modules リポジトリ – AVM全体のREADME、コントリビューションガイド、Issues一覧など。新規提案や全般的な問い合わせはこちらで扱います。
  • Bicep Modules リポジトリ – Azure公式のBicepモジュール集（bicep-registry-modules リポジトリ内の avm フォルダー）。各Bicepモジュールのコード・テスト・READMEが含まれます。
  • Terraform Modules リポジトリ – Azure公式のTerraformモジュール集。モジュールごとに独立したリポジトリ（例：terraform-azurerm-avm-res-storage-storageaccount）があり、Azure組織配下に多数存在します。モジュール単位でIssue管理・PR受付が行われます2。
  • AVM Docs (azure.github.ioサイト) – AVMの公式ドキュメントサイトです。概要、使用方法、貢献手順、FAQなどがMarkdownベースで掲載されており、最新情報もここに反映されます712。

まずAVMに関する疑問や要望がある場合、このGitHub上のリポジトリやドキュメントを調べるところから始めましょう。特にFAQページにはよくある質問がまとまっており一読をおすすめします7。

5.2 AVMへの貢献方法

AVMはオープンソースであるため、誰でもIssueの提出やPull Requestによる貢献が可能です。貢献の方法はいくつかあります。

  • バグ報告や機能要望のIssue登録: モジュールを使っていて不具合を見つけた場合や「この機能が欲しい」というリクエストがある場合、該当モジュールのリポジトリにIssueを起票できます。モジュール所有者が内容を精査し、対応が検討されます13。Issueには可能な限り詳細な再現手順や提案内容を書くとスムーズです。

  • ドキュメントの改善やタイポ修正: 軽微な修正でもPRは歓迎されています。例えばREADMEの誤字修正や説明改善など、小さなPRでも積極的に受け入れる姿勢が示されています13。「OSS貢献はハードルが高い…」と構えず、気付いた点があれば気軽にPRを送ってよいでしょう。

  • コードへの貢献（Pull Request）: 新しい機能の追加や既存バグの修正をコードで提供することも可能です。各リポジトリには**Contribution Guide（貢献ガイド）**が用意されており、それに沿って環境構築～開発～テスト～PR作成を行います。特にTerraformモジュールについてはテスト環境やCIパイプラインも整備されているため、提供された雛形に従って変更を加える形になります。PRを送るとモジュール所有者やコアチームがレビューし、基準を満たせばマージ・リリースされます。

  • 新モジュール提案と作成: 「このAzureサービス向けのAVMモジュールがまだ無いので作りたい/提案したい」といった場合、新規モジュール提案 (New Module Proposal) のIssueを起こすことになります8。AVMでは各モジュールに必ずモジュールオーナー (所有者) が必要で、通常はMicrosoft社員が責任者となります6。しかし、新規提案に対して社内でオーナー選出が可能な場合や、外部コントリビュータが共同オーナーになるケースもあります8。提案Issueではそのモジュールの目的や範囲を明記し、賛同が得られれば開発が進められます。作成したコードはGitHub上でレビューを経て公式モジュールとして組み込まれます。

  • 既存モジュールへの参加: AVMのモジュールの中には**メンテナーが不足して「オーナー募集中」**のものもあります（いわゆるオーファンモジュール）88。こうしたモジュールに対して積極的にPRやIssue対応を行い、コミュニティで貢献実績を積むことで共同オーナーとして認められる道もあります。その際はIssue上で意思表示をし、コアチームのガイダンスに従って役割を担っていきます。

また、コミュニティへの参加として月次のExternal Community Call（オンラインミーティング）に参加したり、Tech CommunityのAVMフォーラムで質問・回答することも有意義です。AVM Core Team（中心開発チーム）は外部からの声を重視しており、積極的な意見交換がプロジェクトの向上に繋がっています。

参考: 2025年6月にはAVMモジュールのサポート体制強化がアナウンスされ、Issue対応の目安時間などが明確化されました13。例えばバグ報告の場合、5営業日以内にモジュール所有者が初期対応/ETA提示を行う、といった目標が設定されています13。仮に所有者から対応が無い場合でもコアチームが介入し、さらに5営業日以内にフォローする仕組みです1313。このようにコミュニティからのIssueは重視されるため、遠慮なくフィードバックを寄せて問題ありません。

6. 最新情報・関連リソースとFAQ

最後に、AVMに関する最新トピックや参照すべき公式情報源をまとめます。

  • 最新アップデート情報: AVMの進捗や重要なお知らせは、Microsoft Tech Communityの「Azure Tools Blog」カテゴリで随時共有されています。例えば2025年6月の投稿では前述のサポートポリシー変更が詳しく説明されていました13。また、同ブログでは毎月のAVM更新状況報告や新機能紹介が掲載されています（「Monthly Update」シリーズ）。AVM利用者はこれらをフォローしておくと、新しいモジュール公開やBreaking Changesの情報をいち早く得られるでしょう。

  • ワークショップ/学習コンテンツ: AVMの公式ラボやハンズオン資料も充実しつつあります。Microsoft Learn上にはAVMを使ったTerraformハンズオンのサンプルコードが公開されており、順を追って実践的に学べるようになっています。さらに、Microsoftのパートナー経由で WorkshopPLUS: Infrastructure as Code with AVM といった有償ワークショップが提供される例も出てきました。これは3日間かけてAVM＋Terraformの使いこなしを習得する研修であり、2025年末に開催が予定されています。企業内研修や自己学習にこうしたリソースを活用することで、AVMのノウハウを体系的に身につけられます。

  • FAQ（よくある質問）: 公式サイトのFAQページにはAVMに関する様々なQ&Aが掲載されています7。例えば「従来のCARML/TFVMとどう違うのか」「他のクラウド製品（M365やAzure DevOps）も対象か」「今後azd CLIに統合されるのか」といった疑問に答える形で詳しく説明されています77。AVMはまだ新しい取り組みのため疑問点も多いかもしれませんが、まずFAQを読めば大抵のポイントは解消するでしょう。特に**「AVMは今後AzureにおけるIaCモジュールの単一標準になる」ことや7、「現時点ではAzureリソースに専念しており、Microsoft 365等は範囲外」である**こと7など、戦略的な位置づけについても触れられています。未回答の質問がある場合はGitHub Issueで質問すればコミュニティが回答し、FAQにも追加されていく運用となっています7。

  • 関連リンク集: 以下に公式情報へのリンクを記載しますので、さらに詳しく知りたい場合は参照してください。

@koudaiii
Copy link
Author

koudaiii commented Aug 28, 2025

AzureUpdatePPTX における AVM

https://github.com/koudaiii/AzureUpdatePPTX/tree/d8c711ea97520be2524c052dbc61d4c7f435bc7d/infra

@koudaiii
Copy link
Author

koudaiii commented Aug 28, 2025

bicep MCP

https://github.com/Azure/bicep/blob/19874098b144e260efb53a92e0a8f3ddb06c01f1/docs/experimental/mcp-tools.md

@koudaiii
Copy link
Author

koudaiii commented Aug 28, 2025

Introduction to using Azure Verified Modules for Terraform

https://learn.microsoft.com/en-us/samples/azure-samples/avm-terraform-labs/avm-terraform-labs/

https://github.com/azure-samples/avm-terraform-labs/tree/main/

@koudaiii
Copy link
Author

koudaiii commented Aug 28, 2025 •
edited
Loading

contribution 診断設定の例

resource "azurerm_monitor_diagnostic_setting" "vgw" {
  for_each = var.diagnostic_settings_virtual_network_gateway

  name                           = each.value.name != null ? each.value.name : "diag-${var.name}"
  target_resource_id             = azapi_resource.vgw.id
  eventhub_authorization_rule_id = each.value.event_hub_authorization_rule_resource_id
  eventhub_name                  = each.value.event_hub_name
  log_analytics_destination_type = each.value.log_analytics_destination_type
  log_analytics_workspace_id     = each.value.workspace_resource_id
  partner_solution_id            = each.value.marketplace_partner_resource_id
  storage_account_id             = each.value.storage_account_resource_id

  dynamic "enabled_log" {
    for_each = each.value.log_categories

    content {
      category = enabled_log.value
    }
  }
  dynamic "enabled_log" {
    for_each = each.value.log_groups

    content {
      category_group = enabled_log.value
    }
  }
  dynamic "metric" {
    for_each = each.value.metric_categories

    content {
      category = metric.value
    }
  }
}

https://github.com/Azure/terraform-azurerm-avm-ptn-vnetgateway/pull/131/files#diff-05b5a57c136b6ff596500bcbfdcff145ef6cddea2a0e86d184d9daa9a65a288eR23-R66

variable "diagnostic_settings_virtual_network_gateway" {
  type = map(object({
    name                                     = optional(string, null)
    log_categories                           = optional(set(string), [])
    log_groups                               = optional(set(string), ["allLogs"])
    metric_categories                        = optional(set(string), ["AllMetrics"])
    log_analytics_destination_type           = optional(string, "Dedicated")
    workspace_resource_id                    = optional(string, null)
    storage_account_resource_id              = optional(string, null)
    event_hub_authorization_rule_resource_id = optional(string, null)
    event_hub_name                           = optional(string, null)
    marketplace_partner_resource_id          = optional(string, null)
  }))
  default     = {}
  description = <<DESCRIPTION
A map of diagnostic settings to create on the gateway. The map key is deliberately arbitrary to avoid issues where map keys maybe unknown at plan time.
- `name` - (Optional) The name of the diagnostic setting. One will be generated if not set, however this will not be unique if you want to create multiple diagnostic setting resources.
- `log_categories` - (Optional) A set of log categories to send to the log analytics workspace. Defaults to `[]`.
- `log_groups` - (Optional) A set of log groups to send to the log analytics workspace. Defaults to `["allLogs"]`.
- `metric_categories` - (Optional) A set of metric categories to send to the log analytics workspace. Defaults to `["AllMetrics"]`.
- `log_analytics_destination_type` - (Optional) The destination type for the diagnostic setting. Possible values are `Dedicated` and `AzureDiagnostics`. Defaults to `Dedicated`.
- `workspace_resource_id` - (Optional) The resource ID of the log analytics workspace to send logs and metrics to.
- `storage_account_resource_id` - (Optional) The resource ID of the storage account to send logs and metrics to.
- `event_hub_authorization_rule_resource_id` - (Optional) The resource ID of the event hub authorization rule to send logs and metrics to.
- `event_hub_name` - (Optional) The name of the event hub. If none is specified, the default event hub will be selected.
- `marketplace_partner_resource_id` - (Optional) The full ARM resource ID of the Marketplace resource to which you would like to send Diagnostic LogsLogs.
DESCRIPTION
  nullable    = false

  validation {
    condition     = alltrue([for _, v in var.diagnostic_settings_virtual_network_gateway : contains(["Dedicated", "AzureDiagnostics"], v.log_analytics_destination_type)])
    error_message = "Log analytics destination type must be one of: 'Dedicated', 'AzureDiagnostics'."
  }
  validation {
    condition = alltrue(
      [
        for _, v in var.diagnostic_settings_virtual_network_gateway :
        v.workspace_resource_id != null || v.storage_account_resource_id != null || v.event_hub_authorization_rule_resource_id != null || v.marketplace_partner_resource_id != null
      ]
    )
    error_message = "At least one of `workspace_resource_id`, `storage_account_resource_id`, `marketplace_partner_resource_id`, or `event_hub_authorization_rule_resource_id`, must be set."
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment