先日、「Introducing Azure Verified Modules!」という記事が投稿されました。
AzureをProvisioningするIaCの信頼性を高めるための活動という位置づけのようです。当初の対象ツールは「Bicep」と「Terraform」です。
なぜこうした取り組みをはじめたのか、その背景にあるものが YouTubeの投稿を見るとわかります。
これまでIaC(Infrastructure as Code)はBicepやTerraformのようなツールが主体で発展してきました。みなさんもそうしたツールでIaCを実践してきたと思います。そうした活動でさまざまなIaCコードが作成されることで重複した部分が多数出てきていると思います。当然そうした重複を減らし再利用したいと考えたと思います。（私達もこうした重複する部分をできるだけ減らし、再利用できるものを提供したいとさまざまな取り組みをしてまいりました。）その成果として、それぞれのIaCツールのコミュニティでも再利用可能なコードのリポジトリを公開されてきています。
こうした取り組みはともするとそれぞれの組織・チーム・コミュニティが独自の「標準」をつくることになり、「標準の乱立」といった弊害も出てきていたのではないでしょうか。利用者の立場からみるとこうした乱立は選択肢を増やす以上に「なにを選択すればいいのかわからなくなる」といったマイナスの側面がより強くなります。 その結果として「あれは難しい」「信頼する情報を見つけるのが大変」といったよくない評価にもつながってしまうおそれがあります。
クラウドインフラストラクチャーリソースを提供する立場から見るとこうした状況は避けなければならず、すくなくともAzureに関しては信頼できるIaCの標準テンプレートを、プラットフォームプロバイダーであるMicrosoftがツール横断的に提供することで安心して活用できるプラットフォームにしていくという思いから開始されたのがAzure Verification Module（AVM）ということのようです。詳細は https://aka.ms/AVM で確認することができます。
私自身は Bicep をよく利用していますが、 Bicep Public Registry でもAVMに合わせた修正が活発に行われてるようで、急速に活動が強化されていることを感じます。
まだAVMの活動は立ち上がって時間もたっておらず十分に準備が進んでる状況ではないとは思いますが、今後標準テンプレートが多数用意されていくことになると思います。ぜひ今後はAVMの動向をウォッチして、公開される標準テンプレートやその周辺の情報（プラクティス）を活用していただきたいと思います。
