⛅
［詳解］AWS Infrastructure as Code ~ FL#86 イベントレポート
公開
2025-03-29
更新
2025-03-29
文章量
約3608字
2025年3月18日、Forkwell主催で「［詳解］AWS Infrastructure as Code ~ FL#86」がオンライン開催されました。
著書『［詳解］AWS Infrastructure as Code 使って比べるTerraform＆AWS CDK』の内容を軸に、Infrastructure as Code（以下IaC）の必要性やツール選定のポイント、そして著者が実際に感じたTerraformとAWS CDKの違いなどが語られ、IaCにこれから取り組みたい人はもちろん、片方のツールだけを知っていてもう一方の知識を得たい方にも、大変刺激的な時間となりました。
Part1: 講演「使って比べるTerraformとAWS CDK」
IaCとは何か、そして何が課題を解決するのか
原氏の話は、「なぜIaCが必要なのか」という根源から始まりました。 AWSに限らずクラウドでは、マネジメントコンソールからポチポチ設定するやり方は直感的で便利。しかし複数環境への再現や変更の追跡、人的ミス防止などを考えると、コードによるインフラ管理（IaC）が欠かせない時代に。
そして数あるIaCツールの中で、TerraformとAWS CDKがよく挙がる2大選択肢。これは「宣言的にAWSリソースの状態を記述し、差分をツールが埋めてくれる点は共通だが、実は細部で大きな違いがある」と指摘します。
Terraformの特徴
TerraformはHashiCorp社製で、AWSだけでなくGCPやDatadog、GitHubなど他クラウド・外部サービスも同じ感覚で管理できる汎用性が強み。
ローカル実行で
plan→applyのプロセスを踏むため、現在のリソースの“実際の状態”とコード側の差分を常に意識できる。リソースの管理操作（状態ファイルの調整）とリソースの変更操作がある程度分離されているため、「管理対象から除外したいだけ」でリソースは削除しないといった運用がしやすい。
一方で、抽象化は自力でモジュールを作るか、公式/コミュニティ提供のモジュールを利用する。モジュール次第でコード量が削減できるが、“どこまで抽象化するか”の設計は自分で考える必要がある。
AWS CDKの特徴
AWS CDKはクラウドフォーメーションを内部的に使い、最終的にCloudFormationテンプレートを生成→デプロイするスタイル。
L2コンストラクタをはじめとする抽象化が非常に強力。例えばVPCやECSなどの複雑なリソース群を、一行のコンストラクタ呼び出しで作成できる。
しかし、その抽象化された「裏側で生成される細かいリソース」がユーザーにとってブラックボックス気味になる。何をどう変更すれば、どこまでリソースに影響が及ぶかが把握しにくいケースもある。
差分判定は
cdk diffがメインだが、それは「CloudFormationテンプレート上の差分」であり、現行のAWSリソースそのものを差分比較するわけではない。そのため手動変更があっても検出されないケースがあるなど、使い方には注意が必要。
差分抽出・既存リソースインポートなど、運用での違い
なかでも原氏が強調したのは、手動変更したAWSリソースをツール側が検知してくれるかどうかの違い。
Terraformは、現行リソース（API取得）とコードの差を必ず比較し、想定外の変更を発見しやすい。
CDK/CloudFormationは、“前回のテンプレート”との比較なので、現行リソースが何者かに変えられていても差分が分からない場合がある。 手動変更（ポチポチ運用）をできる限り防ぐか、あるいは防げないならTerraformのようなツールのほうが安全性が高い可能性がある、と述べていました。
その他にも、既存リソースをIaC管理下に移すインポート機能の話や、lambdaなどアセット管理が絡む場合のパターンなども細やかに解説。「どちらが優れているというより、それぞれ設計思想が違うので、そこを理解して選ぶ・共存することが大事」とのこと。
Part2: Q&Aパネルトーク ～スムーズなTerraform/CDK運用のために～
小西氏（モデレーター）からの問い
モデレーターの小西氏は、サイバーエージェントでAIオペレーション室 CTOを務めるAWSのエキスパート。各種質問を原氏に投げかけ、さらに実体験でのコメントも交えたトークが展開されました。
「IACをしない判断」 小規模でリソースの変更がほとんどないなら、ポチポチでも差は無いかも。だが運用フェーズで人が変わり“何がどのように構築されているか”を失念すると悲劇が起きやすい。それを嫌ってIACにする場合が多い。
「CDKのブラックボックス問題」 L2/L3コンストラクタのような抽象化は、コード量が少なくなる利点がある半面、裏で自動生成されるリソースを把握していないと、予期せぬ変更を招く恐れが。運用チーム全員の技術力が高ければこそ成り立つ抽象化かもしれない。
「最新情報のキャッチアップ」 原氏は公式ブログやGitHubのリリースノートを地道にウォッチしている。AWSはもちろん、CDKやTerraformの更新ペースも非常に速いので、すぐに紙面が古くなる苦労を痛感したとのこと。
視聴者からの質問（一部抜粋）
「設計書は必要？」 設計書をどう位置づけるかはプロジェクト次第だが、モジュール化の範囲やパラメーターの設計方針は必ず考える必要がある。ドキュメントや設計書的な整理が何らかの形で存在しないと、あとから属人化しがち。
「手動ポチポチ運用が想定外に多い」 やむを得ない事情で手動変更が入る現場もあるが、CDK/CloudFormationは手動変更を検知しない。Terraformなら差分を検出できるが、そもそも手動変更を完全に防ぐセキュリティモデルを検討するほうが本筋かも。
「小規模リソースで運用も少ない場合、本当にIaCは要るの？」 それを課題と感じないなら不要だが、複数環境や後継運用者への引き継ぎを想定するなら大いに役立つ。短期スパンで終わるPoCならともかく、長期プロダクトならIacの利点は大きい。
全体を踏まえた感想
書籍が教えてくれる「IaCの必要性」と「ツール選定のリアル」
今回の講演とディスカッションを通じて、改めてTerraformとAWS CDKの相違が明確になりました。一見「どちらも宣言的にAWSを操作するツール」ですが、
Terraform 現行リソースとコード差分を照らし合わせるので、手動変更が混在するケースでもズレを可視化しやすい。抽象化はモジュール次第。
AWS CDK L2/L3コンストラクタによる抽象化はとても便利でコード量を削減。ただしクラウドフォーメーションの特性上、手動変更の検出は苦手。また「管理操作」と「変更操作」を分けにくく、リソース全体の置き換えが起きやすいことも要注意。
あらためて「自社・自チームが何を求めてIaCを採用するのか」を振り返り、それに沿ったツールを選ぶのが肝だと感じさせられました。 また、使い分けや共存の余地もある――たとえばクラウドフロントをTerraformで管理するなど――実務では部分的にツールを切り替える戦略もアリという具体例も興味深かったですね。
今後、新サービスや機能はさらに増え続け、IaCツールもまた進化していくでしょう。そんな中で「なぜIaCが必要なのか」「どの部分を抽象化するか」を理解し、適切な設計と運用フローを築くことが、私たちエンジニアに求められているのだと実感する内容でした。
最後に ― 安定か、抽象化か、まずは自分たちの課題を見極めよう
本イベントを通じて「TerraformとAWS CDK、どっちを使うべき？」という疑問に対する明確な“正解”はありませんでした。しかし、それぞれのメリット・デメリットが具体的に見えたことで、自社・自チームの抱える課題（例えば「差分検知の強さ」「コード量の削減」「マルチクラウド対応」「ブラックボックスの可否」など）に合った選択がしやすくなるはずです。
原氏の著書『［詳解］AWS Infrastructure as Code』では、さらにVPCやECSなどの具体事例をベースに、両ツールのコード例と運用設計が丁寧に比較解説されています。
Terraformだけ使っている人がCDKの抽象化を理解したり、CDKユーザーがTerraformの操作性に触れたりする絶好の教材と言えるでしょう。
IaCがもたらす「安全なマルチ環境運用」「設定の再現性」「属人化解消」といった恩恵を、ぜひ自分たちのチームでも最大化できるよう、本日の内容を踏まえ検討してみてはいかがでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
