Infrastructure as Code

Infrastructure as Code とは

Infrastructure as Code (IaC) は、インフラの構成をコード (YAML, JSON, HCL) で定義し、バージョン管理・自動化・再現性を実現する手法である。手動でコンソールを操作する代わりに、コードでインフラを宣言する。

IaC のメリット

同じコードから同じ環境を何度でも作成できる再現性が最大の利点だ。Git で変更履歴を追跡でき、PR でインフラ変更をコードレビューできる。CI/CD パイプラインに組み込めば自動デプロイが可能で、コードと実際のインフラの差分 (ドリフト) も検出できる。

AWS の IaC ツール

AWS の IaC ツールを以下に示す。

ツール	言語	特徴
CloudFormation	YAML/JSON	AWS ネイティブ
SAM	YAML	サーバーレス特化
CDK	TypeScript 等	プログラミング言語で定義
Terraform	HCL	マルチクラウド

Terraform を選ぶときだけはライセンスを先に確認する。2026 年 8 月時点で Terraform 1.6.0 以降は Business Source License 1.1 が適用され (ライセンサーは IBM)、1.5.x までの Mozilla Public License 2.0 とは条件が異なる。追加使用許諾により自社インフラを構築する通常の本番利用は認められるが、Terraform をホスト型あるいは組み込み型で第三者へ提供し IBM の有償版と競合する用途は除外される。このライセンス変更を契機に、MPL 2.0 のままフォークされた OpenTofu が生まれ、Linux Foundation の下で開発が続いている。OpenTofu は Terraform との機能上の同等性を維持する方針を掲げているため、ライセンス条件が問題になる組織の退避先になる。

SAM テンプレートの例

SAM テンプレートの例を以下に示す。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: nodejs22.x
      Handler: index.handler
      Events:
        Api:
          Type: HttpApi
          Properties:
            Path: /hello
            Method: GET

  MyTable:
    Type: AWS::DynamoDB::Table
    Properties:
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - { AttributeName: id, AttributeType: S }
      KeySchema:
        - { AttributeName: id, KeyType: HASH }

宣言的 vs 命令的

宣言的と命令的の違いを以下にまとめる。

方式	説明	ツール
宣言的	望ましい状態を定義	CloudFormation, Terraform
命令的	手順を記述	AWS CLI スクリプト

# 宣言的: 「DynamoDB テーブルが存在すべき」
Resources:
  MyTable:
    Type: AWS::DynamoDB::Table
# CloudFormation が差分を計算して適用

CDK はプログラミング言語で書くので命令的に見えるが、合成 (synth) の結果として CloudFormation テンプレートを出力するため、実際にインフラへ適用される段階では宣言的だ。命令的なのは、作成と削除の順序を自分で組み立てて API を呼ぶ CLI スクリプトの側である。

IaC のベストプラクティス

全リソースをコードで管理し、コンソールで手動作成しない。dev/stg/prod を同じテンプレートでパラメータ化し、デプロイ前に変更セットで影響範囲を確認する。ネストされたスタックでモジュール化し、再利用性を高める。

IaC の落とし穴

IaC ツールは「自分が管理している状態」を正として差分を計算する。そのためコンソールで手を入れた後に適用すると、その変更が巻き戻るだけでは済まない場合がある。CloudFormation のリソース仕様には属性ごとの更新方法 (中断なし / 一部中断あり / 置換) が定義されており、DB インスタンスの識別子のように置換を伴う属性を書き換えると、リソースが作り直されてデータが失われる。デプロイ前に変更セットで影響範囲を見る作業が効くのは、この置換を事前に洗い出せるからだ。

秘密情報の扱いも定番の事故である。テンプレートに接続文字列やトークンを直接書くと Git の履歴に永久に残り、後から消しても回収できない。CloudFormation と SAM は {{resolve:ssm:...}} や {{resolve:secretsmanager:...}} の動的参照でデプロイ時に値を解決できるので、コードに残すのは参照名だけにする。

既にコンソールで作った資産を後から IaC に寄せる作業も軽くない。CloudFormation にはリソースを既存スタックへ取り込むインポート機能があるが、テンプレートの記述を実物と一致させないと失敗する。最初からコードで作った方が結局は安い、というのがこの手戻りの教訓だ。

コンソール操作の禁止

コンソール操作の禁止を図で示す。

❌ コンソールで Lambda を作成 → Git に記録されない → ドリフト
✅ SAM テンプレートで定義 → Git で管理 → 再現可能

実務での活用方法は関連書籍にも詳しい。

サイト情報