Terraformについて（実践・自動デプロイ編）

オンプレ歴5年以上のサーバ・NW インフラエンジニアです。(クラウド未経験)
AWS構築におけるIaC 化 （自動化）について記述していきます。
前回の【構築準備編】では、Ansible運用経験を持つインフラエンジニアの視点から、Terraformの選定理由や事前準備、ポータブル環境のセットアップについて解説しました。

今回は実践・自動デプロイ編として、実際にコマンドを実行してAWS上にサーバーレス環境を一括デプロイする流れと、自動化のために工夫したコードのポイントについて解説します。

---

1. 自動デプロイの全体フロー（コマンド実行手順）

Terraform でインフラを構築・更新する際は、以下の基本コマンドを順番に実行します。
え、これだけ？って感じですよね。

# 1. 初期化（プロバイダープラグインのダウンロード）
terraform init

# 2. 実行計画の確認（事前差分チェック）
terraform plan

# 3. リソースの構築・適用
terraform apply

# （補足）構築した全リソースを一括削除
terraform destroy

① terraform init（プロジェクトの初期化）

作業を始める前の【ダウンロード＆セットアップ】コマンドです。
Terraform の本体は、初期状態では AWS の操作方法を知りません。
terraform init を叩くことで、コード（.tf）に書かれた「AWS を使う」という指示を読み取り、AWS を操作するために必要な専用ツール（AWS Provider）を自動でネットからダウンロードして手元にセットアップしてくれます。

• 例えるなら: スマホを買ったあとに、最初に「AWS 操作用アプリ」をダウンロードする作業のようなものです。
• 実行タイミング: プロジェクトを新しく作ったとき（初回）や、新しいプラグインを追加したときに 1回だけ 実行します。

② terraform plan（実行計画の確認）

ドライランみたいな機能です。
Ansible の --checkと同様に、terraform plan を実行することで「これからどのリソースが追加・変更・削除されるか」を事前確認できます。
内部的には、「現在のAWS実環境」と「状態管理ファイル（terraform.tfstate）」、そして「ローカルの .tf コード」を比較し、正確な差分（+ 追加、~ 変更、- 削除）を提示してくれます。

---

2. 工夫した点

手動構築の際、最も手間に感じたのが「API Gateway を作成した後に発行されるエンドポイント URL をメモし、フロントエンドの HTML コード内へ手動で書き換える」という作業でした。

API Gateway を作成した後にエンドポイント URLが発行されるのですが、このURLをhtmlファイルに記述をしたものをS3にあげないとAPI Gateway -> Lambda　-> DynamoDBという処理ルートが確保できません。
初回では、記載＆S3にアップロードするところだけ手動で行っていたのですが、転記ミスや変更漏れのリスクが残ります。

そこで、main.tf 内で replace() 関数と file() 関数を組み合わせることで、API Gateway の作成と URL の動的置換・S3 へのアップロードを自動化することができました。

main.tf (一部抜粋)

# API Gateway のエンドポイント URL を HTML 内のプレースホルダー (__API_URL__) へ動的に差し替えて S3 へ配置
resource "aws_s3_object" "index_html" {
  bucket       = aws_s3_bucket.frontend.id
  key          = "index.html"
  content      = replace(
                   file("${path.module}/../frontend/index.html"), 
                   "__API_URL__", 
                   aws_apigatewayv2_stage.default.invoke_url
                 )
  content_type = "text/html"
  etag         = md5(replace(
                   file("${path.module}/../frontend/index.html"), 
                   "__API_URL__", 
                   aws_apigatewayv2_stage.default.invoke_url
                 ))
}

これにより、HTML 側に const API_URL = "__API_URL__"; と書いておくだけで、terraform apply 実行時に実際の AWS 環境 URL（https://xxx.execute-api.ap-northeast-1.amazonaws.com）へ全自動で置換されます。

---

3. デプロイ結果の確認と動作検証

terraform apply を実行し、プロンプトで yes を入力すると、数分で全リソース（S3, CloudFront OAC, API Gateway, Lambda, DynamoDB）が自動生成されます。

outputs.tf を定義しておくことで、構築完了後にターミナル上へアクセス用 URL が出力されます。

# デプロイ完了時のターミナル出力例
Outputs:

cloudfront_url = "[https://d111111abcdef8.cloudfront.net](https://d111111abcdef8.cloudfront.net)"

出力された CloudFront の URL へブラウザからアクセスすると、手動更新なしでお問い合わせフォームが表示されました。
また送信テストを行うと無事に DynamoDB へデータが保存されることを確認できました。

💡 検証後の後片付け（terraform destroy）

手動構築（コンソール操作）の場合、構築したリソースを削除する際に「S3バケット内のファイルを消して、CloudFrontの無効化を待って、LambdaとAPI Gatewayをそれぞれ削除して…」と各サービス画面を回る必要があり、削除漏れによる思わぬ課金リスクがつきまといます。

Terraform で管理していれば、検証が終わった後に以下のコマンドを実行するだけで、構築した全リソースが一括で自動削除されます。

# 構築した全リソースを一括削除
terraform destroy

実行すると削除予定のリソース一覧が表示され、yes を入力すれば数分で綺麗さっぱり跡形もなく消去されます。

「作るときも apply 一発、消すときも destroy 一発」で完結するため、個人開発での検証環境の立ち上げ・撤去や、課金リスクの制御において非常に強力なツールだと実感しました。

---

4. おわりに

今回、手動構築だったサーバーレス構成を Terraform で 100% コード化・自動化してみたことで、以下の大きなメリットを体感できました。

1. 完全な再現性とエラー排除: 人手による書き換えやコンソール操作のミスがゼロになった。
2. コマンド一発での一括構築・破棄: 構築だけでなく、検証が終われば terraform destroy で環境を跡形もなく消せるため、無駄な課金リスクを防げる。
3. Ansible 経験との親和性: 「あるべき状態を定義して適用する」という概念は Ansible と同じであり、 Terraform（HCL）は非常に馴染みやすいツールであると感じた。

全ソースコードは GitHub に公開していますので、興味のある方はぜひ参照してみてください。

• GitHub リポジトリ: finestar43/aws-terraform-form-portfolio