はじめに

クラウド移行を進める現場では、Terraform・Ansible・CloudFormation・Argo CDといったIaC（Infrastructure as Code）ツールが広く採用されている。オンプレミスでRHELサーバを手作業で運用してきたエンジニアがAWSへ移行する際、これらのツールの役割と使い分けを正確に理解することは設計品質に直結する。

本記事では以下を整理する。

IaCとは何か、なぜ必要か
Terraform / Ansible / CloudFormation それぞれの役割と違い
オンプレの手作業がどの場面でどのツールに置き換わるか

1. IaC（Infrastructure as Code）とは

一言で言うと

インフラの構築・設定作業を「コード」として記述し、自動実行する考え方

手作業との比較

オンプレ時代、Webサーバを1台立てるとき以下のような流れだったはずだ。

物理サーバを調達・ラッキング
OSインストール（キックスタートまたは手動）
ネットワーク設定（IP、ゲートウェイ、DNS）
yum install でパッケージ導入
設定ファイルを手で編集
サービス起動・確認
手順書に記録

この作業は属人化しやすく、環境差異が生まれやすい。

IaCはこの手順書をコードに変換し、何度実行しても同じ結果が得られる状態にする。

2. 主要3ツールの役割分担

混乱しやすいのが「Terraform / Ansible / CloudFormation の使い分け」だ。それぞれ対象レイヤーが異なる。

ツール	対象	一言
Terraform	AWSリソース（インフラ層）	インフラを「作る」
CloudFormation	AWSリソース（インフラ層）	TerraformのAWS公式版
Ansible	OS・ミドルウェア層	サーバ内部を「設定する」
Argo CD	Kubernetes・アプリ層	デプロイを「自動化する」

3. Terraform ─ インフラをコードで管理する

基本概念

Terraformは、AWSのリソース構成をHCL（HashiCorp Configuration Language）というコードで記述し、terraform apply 一発でリソースを作成・変更・削除するツールだ。

# EC2インスタンスを作るコードの例
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"

  tags = {
    Name = "web-server"
  }
}

手作業との対応関係

手作業（コンソール操作）	Terraformで書くと
VPCを手動で作成	`resource "aws_vpc"`
セキュリティグループを設定	`resource "aws_security_group"`
EC2を起動	`resource "aws_instance"`
EBSをアタッチ	`resource "aws_ebs_volume"` + `aws_volume_attachment`

Terraformのワークフロー

tfstateによる状態管理

Terraformは現在のインフラ状態を terraform.tfstate というファイルに記録する。このため、「コードと実際のインフラがどう違うか」を常に把握でき、差分だけを適用できる。

冪等性（何度実行しても同じ結果）

手作業だと「もう一度実行したら重複作成してしまった」というミスが起きるが、Terraformはこれを自動的に防ぐ。

CloudFormationとの使い分け

	Terraform	CloudFormation
対応クラウド	AWS / Azure / GCP（マルチクラウド）	AWS専用
記述言語	HCL（独自）	YAML / JSON
AWS新機能への追従	若干遅れる場合あり	最速（AWS公式）
状態管理	tfstateで管理	AWSが自動管理（スタック）
推奨場面	マルチクラウド・チーム標準化	AWSのみの環境

4. CloudFormation ─ AWSネイティブなIaC

基本概念

CloudFormationはAWSが公式に提供するIaCサービスだ。YAMLまたはJSONで記述したテンプレートをスタックという単位で管理し、一括で作成・更新・削除できる。

# webserver.yaml（簡略版）
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16

  MyEC2:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.medium
      ImageId: ami-0c55b159cbfafe1f0

# このコマンド1発で全リソースが作られる
aws cloudformation deploy \
  --template-file webserver.yaml \
  --stack-name my-web-stack

手作業からの移行で得られるメリット

① 環境複製が一瞬

# 本番と同じ構成の検証環境を作る（パラメータだけ変える）
aws cloudformation deploy \
  --template-file webserver.yaml \
  --stack-name my-web-stg \
  --parameter-overrides Environment=stg

② 変更履歴がGitで管理できる

# git diff でインフラの変更差分が一目でわかる
- InstanceType: t3.medium
+ InstanceType: t3.large

③ 削除が安全・確実

手作業だと「EBSを消し忘れてコストが発生し続けた」という事故が頻発するが、スタック単位で管理することで防げる。

④ Change Setで本番適用前に変更内容を確認

手作業では「本番で変更して初めてミスに気づく」ことが多いが、Change Setを使えば事前確認してから適用できる。

5. Ansible ─ サーバ内部の設定を自動化する

基本概念

AnsibleはRHELを開発するRed Hat社が主導するオープンソースの構成管理ツールだ。今まで yum install・systemctl・vi /etc/httpd/conf/httpd.conf でやっていたサーバ設定作業を、YAMLのコード（Playbook）で記述して自動実行できる。

エージェントレスが最大の特徴だ。ターゲットノードにAnsibleをインストールする必要はなく、SSHとPythonが使えれば動く。

手作業との対応関係（RHELエンジニア向け）

手作業でやっていたこと	Ansibleで書くと
`yum install httpd`	`yum: name=httpd state=present`
`systemctl enable --now httpd`	`service: name=httpd state=started enabled=yes`
`vi /etc/httpd/conf/httpd.conf`	`template: src=httpd.conf.j2 dest=/etc/httpd/conf/httpd.conf`
`useradd deploy`	`user: name=deploy state=present`
`firewall-cmd --add-service=http`	`firewalld: service=http state=enabled`

Playbookの例

# Webサーバ構築 Playbook
- hosts: webservers
  become: yes   # sudo相当
  tasks:

    - name: httpdのインストール
      yum:
        name: httpd
        state: present

    - name: 設定ファイルを配布
      template:
        src: httpd.conf.j2
        dest: /etc/httpd/conf/httpd.conf
      notify: restart httpd   # 設定変更時にだけ再起動

    - name: httpdの起動と自動起動設定
      service:
        name: httpd
        state: started
        enabled: yes

  handlers:
    - name: restart httpd
      service:
        name: httpd
        state: restarted

冪等性の保証

「何度実行しても同じ結果」になる。

手作業で繰り返し実行すると2重インストールや設定の上書きで問題が起きるが、Ansibleはこれを自動的に回避する。

6. Argo CD ─ KubernetesへのデプロイをGit連携で自動化する

基本概念

Argo CDはKubernetes（コンテナ基盤）に特化したデプロイ自動化ツールだ。GitリポジトリをKubernetesの「あるべき状態」の定義場所として扱い、Gitとクラスタを常に同期させる（GitOpsと呼ぶ）。

Terraformとの役割分担

Argo CDの活用にはKubernetesの基礎知識が前提となる。まずTerraform / Ansible / CloudFormationを習得してから取り組むのが現実的だ。

7. オンプレ手作業 × IaC 全体マッピング

インフラ構築作業

オンプレでやっていたこと	AWSでのIaC対応	ツール
物理サーバ調達・ラッキング	EC2リソースをコードで定義	Terraform / CloudFormation
IPアドレス・VLAN設計	VPC・サブネットをコードで定義	Terraform / CloudFormation
ファイアウォール設定	セキュリティグループをコードで定義	Terraform / CloudFormation
NASサーバ構築	EFS・FSxリソースをコードで定義	Terraform / CloudFormation
ロードバランサ設定	ALB・NLBをコードで定義	Terraform / CloudFormation

サーバ設定作業

オンプレでやっていたこと	AWSでのIaC対応	ツール
キックスタートでOS初期設定	Playbook / UserDataで自動実行	Ansible
`yum install` でパッケージ導入	Playbookのyumモジュール	Ansible
設定ファイルの手動編集	Jinja2テンプレートで自動配布	Ansible
`systemctl` でサービス管理	Playbookのserviceモジュール	Ansible
複数台への同じ作業（n番煎じ）	インベントリに追記して一括実行	Ansible
ゴールデンイメージ作成	Packerで自動AMIビルド	Packer（＋Ansible）

変更管理・障害対応

オンプレでやっていたこと	AWSでのIaC対応	ツール
変更手順書をExcelで管理	コード変更をGit PRで管理	Git + IaCツール
変更前後の確認は目視	`terraform plan` / Change Set で差分確認	Terraform / CloudFormation
環境再構築（障害時）	コードから全自動で再構築	Terraform / CloudFormation
検証環境は手動で複製	同じコードでスタック名を変えるだけ	Terraform / CloudFormation

8. 学習の優先順位とロードマップ

RHELエンジニアがAWS移行後にIaCを習得する場合の推奨順序を整理する。

各ステップで身につく能力のイメージ

ステップ	習得後にできること
CloudFormation	手動構築していた環境をテンプレート化・チームで再利用できるようにする
Ansible	複数台のEC2設定を手順書なしで一括実行できるようにする
Terraform	AWSリソース全体をGitで版管理し、本番環境への変更をレビュープロセスに乗せる
Argo CD	コンテナ化されたアプリのデプロイを全自動化する

9. IaC導入時のよくある落とし穴

① 「コードに書いた = 安全」ではない

② コンソール直接変更との競合（ドリフト）

IaCで管理しているリソースをコンソールで手動変更すると、コードと実態が乖離する（「ドリフト」と呼ぶ）。IaC導入後はコンソールからの手動変更を禁止するルールを定めることが重要だ。

③ tfstate / スタックの管理

問題	対策
tfstateをローカルに置くとチームで競合する	S3 + DynamoDBでリモート管理する
CloudFormationスタックを直接削除するとリソースが残る	`retain` ポリシーの設計を事前に行う

参考

ツール	公式ドキュメント
Terraform	https://developer.hashicorp.com/terraform/docs
CloudFormation	https://docs.aws.amazon.com/ja_jp/cloudformation/
Ansible	https://docs.ansible.com/
Argo CD	https://argo-cd.readthedocs.io/