【運用保守からの脱却】TerraformでAWS構築した2年目エンジニアの挑戦記
こんにちは、インフラエンジニアの三瓶です。
今回は運用保守しかやったことがない2年目のエンジニアが、個人でAWS環境をTerraformを使って構築した話をまとめます。
「上流工程に進みたい」「自分の市場価値を高めたい」と思っている方に、少しでも参考になれば嬉しいです。
なぜAWS環境を構築したのか
現在私はSES企業に所属しており、1社目の現場では約1年間、運用保守を担当していました。
今は次の案件待機中で、せっかくの時間を「キャリアアップにつながる行動」に使いたいと思い、今回の構築を決意しました。
理由はシンプルです。
運用保守だけではキャリアの幅が狭くなる。だから、経験と実績を自分で作りたかった。
Terraformを選んだ理由
AWSには「CloudFormation」もありますが、私はTerraformを選びました。
理由は以下の通りです。
TerraformはAWS以外（AzureやGCPなど）でも使える → 今後のキャリアの広がりにつながる
IaC（Infrastructure as Code）の需要が高まっている → 市場価値が上がる
Gitと組み合わせて変更管理ができる → チームでの構成管理経験にもつながる
実際に構築した構成
アプリ要件
グループ向けの「収支管理アプリ」を前提にした構成です。
使ったAWSサービス（なるべく無料枠＆コスト最小に抑えました）
Lambda
IAM
Security Groups
VPC
NAT Gateway
ALB
Route 53
DynamoDB
S3
CloudWatch Logs
AWS WAF
Cognito
Secrets Manager
※一部サービスは有料となるため、利用時間を短く・トラフィックを最小にすることでコストを抑えています。
Terraformに大苦戦した話
正直、かなり苦労しました。
研修で少し触った程度では到底足りず、以下のようなハマりポイントが山ほどありました。
依存関係でエラーが連発
モジュール化して関数や変数が増え、逆に混乱
terraform plan で何度も怒られる
エラー文の意味がわからない
でも、調べて・試して・壊してを繰り返すことで、確実に力がついたと思います。
Terraformだからこそ学べたこと
Terraformを使って構築したからこそ得られたことも多くあります。
apply までは料金が発生しない → 試行錯誤がしやすかった
モジュールごとに分けて整理 → サービスごとの理解が深まった
Gitで構成管理 → 変更履歴を追える安心感
強い制約があるからこそ、AWSの仕様をよく読むようになった
今後の展望
今後はもっと実践的な構成にチャレンジしたいです。
まずは**AWS認定ソリューションアーキテクト アソシエイト（SAA）**の取得を目指しながら、構成の見直しとドキュメント化をしていく予定です。
具体的には：
コスト最適化の実践
CloudFrontやStep Functionsなど、より高度なサービスの導入
構成を他人にも共有・説明できる状態に整理
最後に
「運用保守しかやったことがないし…」と悩んでいた自分が、
Terraformを使ってゼロからAWS環境を作ったという経験は、間違いなく自信につながりました。
このあと、作った構成を営業さんにプレゼン予定です。
少しでも参考になった方は、ぜひLGTM・コメントをお願いします！
まとめ
運用保守経験だけでも、自分で構築はできる
Terraformは最初は難しいけど、やればやるほど理解が深まる
自主的に行動することで、キャリアは前に進む
ご希望があれば、この構成ファイルの一部や失敗談なども別記事で公開する予定です！
読んでいただき、ありがとうございました！