従来の物理サーバー中心の環境から、クラウドサービスの活用が進む中で、インフラ管理の効率化や自動化に向けたIaC（Infrastructure as Code）の活用がますます進んでいます。
IaCによってインフラの構成をコードで管理し、ソフトウェア開発と似た手法で管理することが可能です。
IaCのメリットには以下のようなものがあります。
- 効率性の向上
インフラのプロビジョニング・設定・管理を自動化し、時間とコストを削減します。 - 再現性の向上
コードでインフラを定義することで、同じ環境を何度でも再現可能です。 - 一貫性の向上
コード化によって手作業による操作ミスや設定のばらつきを抑制します。 - バージョン管理
コードをバージョン管理システムで管理することで、変更管理の追跡や以前の状態へのロールバックが容易になります。
IaCの概念自体はクラウド以前から存在していましたが、クラウドの普及と共にIaCの普及も拡大しています。
そのため、クラウド黎明期に構築されたシステムではIaC化されていないものも多くあります。
IaC化されていないインフラをIaC化することで、前述のメリットに加えて、現在のインフラ構成をコードとして可視化することで現状把握が容易になります。
このため、既存インフラをIaC化しようとする動きも増えています。
IaCツールにはTerraform、Pulumi、AWS CDK、AWS CloudFormationなどがあります。
例えば、AWS CloudFormationを用いて既存インフラをIaC化するには、AWSサービスであるIaCジェネレーターを使ってテンプレートを作成し、AWS CloudFormationのスタックにテンプレートをインポートするだけで完了します。
今後、このインフラに対して修正を行う場合は、AWS CloudFormation上でスタックに入っているテンプレートのコード修正を行い、インフラに適用します。
これで既存インフラのIaC化が完了です。
ただし、このコードをベースにしてインフラをカスタマイズする場合には注意が必要です。
例えば、すでにあるEC2のコードを使って新しいEC2を複製する場合、該当のコードにはEC2とネットワークインターフェースの両方にセキュリティグループやサブネットの設定があると重複エラーが発生します。
その場合は、EC2側の設定を削除するか、EC2のDependsOnでネットワークインターフェースの論理IDを指定するといった回避策が必要になります。
