AWS構築をコードにする最初の一歩 — CDKとTerraformの選び方と、どこから手作業をやめるか

「マネジメントコンソールで作ったあの環境、もう一度まったく同じものを作れますか」——環境構築の引き継ぎでいちばん困りやすいのが、この問いです。クリックで作った環境は手順書が古くなりがちで、誰がいつ何を変えたのかも追えなくなります。これを解くのが IaC（Infrastructure as Code＝インフラをコードで宣言し再現する考え方）です。本記事では、IaCの代表である AWS CDK と Terraform をどう選ぶか、そして手作業をどこからコード化していくかの最初の一歩を、実務の判断軸で整理します。なお、コマンドや仕様はバージョンで変わるため、本記事は現行時点の記述として読み、細部は公式ドキュメントも併せてご確認ください。

なぜ手作業構築から抜けるのか

コンソールでの手作業構築には、規模が大きくなるほど効いてくる弱点があります。

• 再現できない：同じ環境を別アカウント・別リージョンに作り直すとき、クリック手順を完全には再現できません。
• 差分が読めない：誰が何を変えたのかが履歴に残らず、トラブル時に「いつから挙動が変わったか」を追えません。
• レビュー・引き継ぎができない：構成の意図がコードとして残らないため、第三者の確認や担当交代が属人的になります。

IaCは、環境の構成をコードとして宣言し、そのコードから何度でも同じ環境を作れるようにする方法です。コードはGitで履歴管理でき、差分のレビューも、引き継ぎも、通常のソフトウェア開発と同じやり方に乗せられます。とくに複数環境を再現する受託や運用の現場では、この「壊れても同じものを作り直せる」性質が効いてきます。AWSにはこの土台として CloudFormation があり、その上での開発体験を提供するのがCDK、独自のエンジンで動くのがTerraform、という関係になります。

CDKとTerraformをどう選ぶか

最初の分かれ道が、CDKとTerraformのどちらで始めるかです。ここで大事なのは、**どちらが優れているかではなく、自分のチームと対象にどちらが合うか（適性）**で選ぶことです。

**AWS CDK（v2）**は、TypeScript・JavaScript・Python・Java・C#（.NET）・Goといった汎用プログラミング言語でインフラを記述します。書いたコードは cdk synth でCloudFormationテンプレートに変換され、CloudFormationがデプロイと状態管理を担います。つまりCDKはCloudFormationの上位にある開発体験で、状態は基本的にAWS側（CloudFormation）が持ちます。既にプログラミングに慣れたメンバーが多く、AWS中心で組むチームに向きます。

Terraformは、HCLという宣言的な専用言語で記述し、独自のstate（状態ファイル）とエンジンでAWS APIを直接操作します。CloudFormationは使いません。AWS以外のプロバイダも同じ流儀で扱えるため、マルチクラウドや既存のTerraform資産があるチーム、IaC専任を置く体制に向きます。

観点	AWS CDK（v2）	Terraform
記述	汎用言語（TS/JS/Python/Java/C#/Go）	HCL（宣言的な専用言語）
対象	AWSフォーカス（CloudFormationを生成）	マルチプロバイダ（AWS含む・非CloudFormation）
state	CloudFormationが管理（stateファイル不要）	独自state（S3バックエンドで共有）
ライセンス	OSS（Apache 2.0）	BUSL（OSSフォークのOpenTofuはMPL 2.0）
学習	既存のプログラミングスキルを活かせる	HCLの習得が必要・周辺ツールは成熟
向くチーム	AWS中心・アプリ開発者主体	マルチクラウド／既存Terraform資産／IaC専任

ライセンスも選定材料になります。Terraformはバージョン1.5以降 BUSL（Business Source License） に変わり、これを受けてOSSフォークの OpenTofu（MPL 2.0）が登場しています。受託先や自社にOSSポリシーがある場合は、どちらを採るかが判断に効くため、事実として押さえておくとよいでしょう（適用範囲は変わりうるので公式でご確認ください）。なお「Terraform＝マルチクラウド、CDK＝AWS専用」という整理は概ね妥当ですが、CDK for Terraform（cdktf）のような選択肢もあるため、硬い線引きではなく適性の話として捉えるのが安全です。

どこから手作業をやめるか

ツールを決めたら、次は移行の順番です。よくある失敗は、いきなり既存の本番環境を丸ごとコード化しようとして挫折することです。小さく始めて、影響範囲の小さいところからコード化するのが鉄則です。

実務で取られる順番は次のとおりです。

1. 新規・使い捨ての環境から：検証用や短命な環境は、壊れても影響が小さく、作り直しの練習に向きます。まずここでツールの流儀に慣れます。
2. 共通基盤（ネットワーク・IAMなど）へ：VPCやサブネット、IAMロールのように、複数の環境で繰り返し作るものをコード化すると、再現性の恩恵が大きく出ます。
3. 既存の本番環境は最後に：稼働中のリソースは、差分（CDKなら合成結果、Terraformなら plan）を必ず確認しながら慎重に取り込みます。

どの段階でも、適用前に差分を読む習慣が事故を防ぎます。コードが実環境に何をしようとしているのかを plan や合成結果で確認してから適用する、という流れを最初から身につけておくことが、手作業時代との大きな違いになります。

最初のハマりどころ

IaCは「コードにすれば安心」というものではなく、最初に必ず引っかかる運用上の注意点があります。古い記事の手順をそのままなぞると躓きやすい箇所でもあるため、現行の作法を押さえておきます。

CDKの cdk bootstrap 忘れ：CDKは初回に cdk bootstrap を実行し、デプロイに使うリソース（CDKToolkitスタック）をアカウント×リージョンごとに用意する必要があります。これを忘れると初回の cdk deploy が失敗します。

# 初回だけ：対象アカウント×リージョンに一度実行
cdk bootstrap
# 以降はデプロイ
cdk deploy

Terraformのstateロックは現行の方式で：複数人でTerraformを使うときは、stateの同時書き込みを防ぐロックが要ります。ここが古い情報の事故が多い箇所です。現行では S3バックエンドのネイティブロック（use_lockfile = true）が推奨で、stateの破損対策にBucketのバージョニングを有効にします。かつて定番だったDynamoDBテーブルによるロック（dynamodb_table）は現在は非推奨で、将来のマイナーバージョンで削除予定です。古い記事にある「S3＋DynamoDBが必須」という手順には従わないようにします。

terraform {
  backend "s3" {
    bucket       = "your-tfstate-bucket"
    key          = "envs/dev/terraform.tfstate"
    region       = "ap-northeast-1"
    use_lockfile = true   # 現行のS3ネイティブロック
  }
}

このほか、コードと実環境がずれる drift（ドリフト）、適用に使うIAM権限の設計、環境（dev/stg/prod）の分離も、早い段階で方針を決めておくと後がラクになります。バージョンによってコマンドや引数は変わるため、細部は必ず公式ドキュメントの現行版で確認してください。

まとめ

手作業のコンソール構築から、コード化された再現性へ移ると、環境は「壊れても同じものを作り直せる」ものになります。CDKとTerraformは優劣でなく適性で選び、移行は新規・使い捨て環境から始めて共通基盤へ広げ、既存の本番は最後に回す——この順番なら無理なく一歩を踏み出せます。

コード化が回り始めたら、次の関心は自然と「変更を安全に届ける」ことに移ります。pushをきっかけに安全にデプロイするCI/CDの仕組みや、CloudWatchのOpenTelemetryメトリクス対応 で壊れたときに気づける可観測性、AWS FinOps Agent で無駄なコストを抑える運用は、IaCで作った基盤を実務で支える組み合わせになります。まずは小さな環境を一つ、コードで作り直すところから始めてみてください。コマンドや仕様の最新情報は、導入時に公式ドキュメントでご確認ください。