EN

クラウドデビューするインフラエンジニアへIaCのススメ

この記事は、インフラ構築の経験は豊富だけれど、クラウド（AWS・Azure・GCP）は初めてで、IaC（Infrastructure as Code）も使ったことがない、という人に向けて書いています。

そういう人がクラウドでインフラを作るとき、新しく覚えることは大きく2つです。

  • AWS・Azure・GCPといったクラウドプラットフォームそのもの
  • インフラをコードで管理する「IaC」という手法

この記事では後者のIaCについて、コンソールでの手動構築とIaCの違い、なぜIaCを使うべきか、どのツールを選ぶかを整理します。

IaCとは何か

IaCとは、サーバー・ネットワーク・ストレージなどのインフラ構成を、手作業ではなくコードとして記述・管理する手法です。手動のプロセスや設定の代わりにコードを使って、インフラを用意（プロビジョニング）します。

オンプレ経験者向けの比喩：紙の手順書や作業台帳で管理していたサーバー構築手順を、そのまま実行可能なコード（Gitで管理・レビューできるファイル）に置き換えるイメージです。Ansibleなどの構成管理を使っていた場合は、その延長線上にある考え方です。

手動構築（コンソール操作）のリスク

どのクラウドにも、ブラウザからリソースを作れる管理画面があります（AWSマネジメントコンソール、Azure Portal、Google Cloudコンソール）。クリック操作で仮想マシンやネットワークを作ることはできますが、次のようなリスクがあります。

  • 誰が・いつ・何を変更したかを追跡しづらい（作業ログが個人の記憶やスクリーンショットに依存する）
  • ステージング環境と本番環境で構成に差が出やすく、ヒューマンエラーの原因になる
  • 障害時にゼロから再構築する手順が、担当者の記憶やスキルに依存してしまう
  • レビュー（第三者チェック）ができない

IaCで解決できること

IaCでは、インフラの構成をテキストファイル（コード）として書くので、次のことができるようになります。

  • アプリケーションのコードと同じようにGitで履歴管理・レビューできる
  • 同じ構成を再現できる形で、ステージングと本番に展開できる
  • コードの差分（diff）を見るだけで変更内容を把握できる
  • 障害時にコードから環境を再構築できる（属人化をなくせる）

つまり「インフラもコードレビューする」という発想が、IaCを導入するいちばんのメリットです。

IaCツールの比較

IaCツールは、大きく「複数のクラウドで使えるもの」と「各クラウドの純正ツール」に分かれます。

項目Terraform各クラウドの純正ツール
代表例Terraform（HashiCorp）AWS：CloudFormation / AWS CDK
Azure：ARMテンプレート / Bicep
GCP：Infrastructure Manager（旧Deployment Manager）
記述言語HCL（宣言型）YAML / JSON / Bicep、CDKはTypeScriptやPythonなどの汎用プログラミング言語
対応クラウドAWS / Azure / GCPなど多数そのクラウドのみ
状態管理自前のstateファイル（S3・Azure Storage・Cloud Storageなどで管理）基本的にクラウド側が管理
覚えること1つの書き方で、どのクラウドにも使えるクラウドを変えるたびに別のツールを覚え直す
向いているケース複数のクラウドを扱う／将来の移行を見据えたい場合1つのクラウドだけを使い続け、純正のサポートを重視する場合

補足として、GCPのInfrastructure Managerは中身がTerraformなので、GCPでもTerraformの知識がそのまま活きます。なお、Deployment ManagerからInfrastructure Managerへの移行のように、各クラウドのツールの状況は変わることがあります。使う前に公式ドキュメントで最新の情報を確認してください。

結論：AWS・Azure・GCPのどれを使う場合でも同じ書き方で管理できること、宣言型で読みやすいこと、実務での使用実績が多いことから、私はTerraformをおすすめします。純正ツールにはクラウド側が状態管理を自動でやってくれる利点がありますが、そのクラウド専用なので、別のクラウドを扱うときに一から覚え直しになります。

導入時に押さえておくべき注意点

  • 学習コスト：HCLという宣言型言語の書き方、リソース間の依存関係、plan → apply というワークフローを覚える必要がある
  • stateファイルの管理：Terraformはstateファイルを自分たちで管理する運用設計が必須。保存先はクラウドごとに、AWSならS3、AzureならAzure Storage（Blob）、GCPならCloud Storageが定番で、同時実行を防ぐロックも合わせて設定する
  • ドリフト（構成のズレ）：コンソールから手動で変更すると、コードと実環境のあいだに差（ドリフト）が生まれる。運用ルールとして「手で直接触らない」を徹底する必要がある
  • ロールバック手順：Terraformは失敗時に手動での対応が必要な場面があるので、切り戻し手順を事前に整理しておく
  • クラウドごとの差：Terraformの書き方は共通でも、リソースの種類や名前（仮想マシン、ネットワーク、権限管理の仕組みなど）はクラウドごとに異なる。コードを別のクラウドにそのまま流用できるわけではない

次のアクション

  1. まずは小さなリソース（ストレージのバケットやファイアウォールのルールなど）からTerraformで作ってみる
  2. 使うクラウドに合わせて、stateファイルの保存先とロックの方法を決める
  3. チームの運用ルール（コンソールでの直接変更禁止、PRベースの変更フロー）を整える
  4. 慣れてきたら、CI/CD（Atlantis、HCP Terraformなど）でapplyを自動化することも検討する