【セッションレポート】AWS Infrastructure as Code : 2025 年主要アップデートの振り返り（DVT225）
AWS Summit Japan 2026 Day1のセッション「AWS Infrastructure as Code : 2025 年主要アップデートの振り返り」に参加してきたのでレポートです。
セッション概要（AWS Summit Japan公式サイトより）
タイトル: AWS Infrastructure as Code : 2025 年主要アップデートの振り返り
スピーカー: AWS Japan ソリューションアーキテクト 菊地 晏南
AWS は、アプリケーションインフラストラクチャをプログラマティックで、記述的で、かつ宣言的な方法で作成、デプロイ、保守できるサービスを提供しています。これらのサービスは、アプリケーション開発に厳密性、明確性、信頼性をもたらします。本セッションでは、AWS CloudFormation と AWS Cloud Development Kit (AWS CDK)における最新の機能強化について学び、これらがチームにもたらすメリットをご紹介します。
レポート
AWSにおけるIaC ポートフォリオ
AWS IaC ポートフォリオについて、どのような仕組みで成り立っているのかが説明がありました。
あまり意識せずに使っているところもありますが、新サービスでもすぐにIaCを利用できるようになる背景として、AWS CloudFormation resource registryに即統合されるため、CloudFormationからすぐに利用できるところが印象的でした。
また、レジストリ自体がAPIとして公開されているため、Terraformなど他のIaCツールを利用する場合でも、すぐに新しいサービスに対応できる仕組みがあるとのことです。
アップデート情報
IaCを利用、または活用していくにあたって、以下の3点をテーマにアップデート情報の説明がありました。
- クラウドの活用を迅速かつ安全に拡大
- セキュリティやコンプライアンス
- 開発速度の高速化
IaC開発の簡略化
従来では、使いたいサービスに対してドキュメントを確認する必要がありました。その後、必要なプロパティや構文を確認する必要があるため、ブラウザのタブが大量に開かれたりIDEとブラウザの行き来が大量に発生することが課題に挙げられました。
これに対する解決として対応IDEにAWS Toolkitプラグインを利用した自動補完やホバー、構文の検証、セキュリティベストプラクティスのチェックが具体的な対応策として挙げられていました。
本来、ブラウザに行き来してドキュメントを確認する必要がありましたが、基本的にIDE上で完結できるようになっており、開発者体験がよくなることがわかりました。
（自分も前職でソフトウェア開発をしていましたが、ブラウザには数十個のタブを開いたりしていました...ただ、IDE上で見れると、その場で必要な情報をすぐに取りに行けるのでこれはいいなと思いました。）
デプロイ時のサイクル短縮
IaCを使っているとあるあるなのですが、デプロイしたIaCに対して更新をかける際、プロビジョニングエラーが発生するとロールバックが行われ、修正してから最初から更新し直す必要があります。
変更セットのプレビュー時では構文上問題がなくても、命名の競合やプロパティの構文エラー、リソースの競合は実際にデプロイをしないと検出できないのが従来の課題でした。
この課題に対して、変更セット作成中にリソース名の競合やプロパティの構文エラー、オブジェクトが残っているS3バケットの削除を検出できるようになったアップデートが紹介されていました。
デプロイの検証タブでエラーの詳細やテンプレート上の具体的な失敗箇所などが表示されるようになり、より早くエラーに気づきながら、修正も高速化できる点が魅力的でした。
リソースのドリフトに対する変更セットの作成
IaCでデプロイできても、手動でAWSマネジメントコンソール上からプロパティの変更を行った場合、IaCテンプレートと状態に差分が発生する「ドリフト」状態となります。
ドリフト状態となると、今後のIaCデプロイで意図せずプロパティが変更されたりと、IaCによる更新を諦めざる得ない状態になる問題が発生します。
この問題への解決として、ドリフト対応変更セットが紹介されていました。
仕組みとして、IaCの更新時にリソースの実際の状態を取得し、変更セットの時点で意図しない変更を検出できるようになるとのことです。
これにより、変更の競合を事前に解決してからデプロイができるようになり、ドリフト状態を安全に解消できます。
ガバナンスへの対応
従来では組織のセキュリティポリシーなどで、禁止されている設定を行った際、デプロイが行われてから事後スキャンなどでリスクを検出するのが標準でした。
この問題点として、事後の発見的スキャンではどうしてもデプロイされてからタイムラグが発生するため、一時的なポリシー違反が発生してしまうことが問題として挙げられます。
また、アラートが検出されてから、デプロイ担当者にフィードバックが必要となるため、手段によってはフィードバックの工数が発生することも問題です。
この問題に対してCloudFormation フックが紹介されました。
このフックを利用することでデプロイ時のリソース作成やスタックでの検証、変更セットの作成時、Cloud Control APIの4つのタイミングで検証を行うことができます。
また、AWS Control Catalogとの統合により、セキュリティプラクティスのルール集から選択して検証する内容を有効化できるようになりました。これにより、ルール記述の知識がなくても簡単
に検証を行えるとのことです。
MCPサーバーを活用したIaCの作成
AIを利用したIaCの開発について、AIエージェントがデプロイの失敗などを都度取得して修正する特徴を持ちます。
これはAIエージェントが常にIaCに関するコンテキストを持っていないため、段階的に問題を解決する仕組みとなっています。一方で、段階的にデプロイと修正を繰り返すため、AIならではのスピード感を得られないデメリットがあります。
そこで、AWS IaC MCP Serverを利用することで、ナレッジやトラブルシューティング、事前の検証などを適切にAIエージェントに渡すことができるようになり、ベストプラクティスを満たしながら効率化を期待できます。
終わりに
IaCならではの辛みが様々なアップデートにより解消、さらにAIツールも出てきて従来に比べてハードルが下がってきたなと実感できるセッションでした。
アップデートにより常に進化しているので、今後もどんどんIaCを触って進化を自身に取り込んでいければと思いました。
