AWS 18：IaC ― 構成をコードにする

しかも「今どうなっているか」を誰も説明できない

手作業の問題は、「もう1つ作れない」だけではありません。今ある本番が、どういう状態なのかを誰も説明できなくなることです。

図の本番では、セキュリティグループが「全開放」になっています。

手順書は、書いた日から古くなり始めます。結局「画面に今出ている状態だけが正解」になり、その正解の理由は誰も知らない、という状態に陥ります。

この2つの困りごと、再現できないと差分（何がどう違うか）がわからないを解決するのが、この章のテーマ IaC です。

IaC：構成を「設計図のコード」に書き、AWS に組み立てさせる

IaC（Infrastructure as Code、構成をコードとして扱うこと）は、作りたい構成をファイルに書き、道具に渡して、その通りに作らせるやり方です。

家を建てるときの設計図にたとえるとわかりやすいでしょう。大工さんに口で1つずつ指示する（手作業）のではなく、設計図を渡します。設計図があれば、同じ家を別の土地にもう1軒建てられますし、「窓を1つ増やす」という変更も設計図の差分として残ります。

図では、左の設計図（コード）を道具に渡すと、右に AWS 上の構成ができあがっています。

IaC の最大の価値は「速く作れる」ことよりも、構成が「読めるもの」「比べられるもの」「戻せるもの」になることです。

「手順」ではなく「あるべき姿」を書く（宣言型）

IaC のコードには、多くの場合「こうなっていてほしい」というあるべき姿を書きます。これを宣言型と呼びます。

図の順番で、道具が何をするかを見てみます。

結果として、道具は「1台だけ足す」を行います。既にある1台には触りません。もし今3台あれば、1台を消します。差を埋める手順は、道具が考えてくれるのです。

これに対して、「EC2 を1台作る」「もう1台作る」と手順を並べるやり方（手順型）では、2回実行すると台数が増えてしまいます。宣言型なら、何回実行しても結果は「2台」のままです。このように何度実行しても同じ結果になる性質は、自動化にとってとても大事です（次の第19章で、コードを自動で何度も当てるようになります）。

CloudFormation：テンプレートから「スタック」を作る

AWS 純正の IaC の道具が AWS CloudFormation（クラウドフォーメーション）です。

図の左は、フォトログのセキュリティグループを書いたテンプレートの一部です。

YAML（ヤムル）は、字下げ（行頭の空白）で入れ子を表す設定ファイルの書き方です。字下げがずれると意味が変わるので、注意して書きます。

テンプレートを CloudFormation に渡すと、中の部品がすべて作られ、「photolog-app」という名前のスタックになります。

スタック：まとめて作り、まとめて消す

スタックという単位があることで、手作業では大変だったことが楽になります。

1. 順番を道具が決める。 部品には作る順番があります。VPC が無いとサブネットは作れず、SG が無いと EC2 に付けられません。CloudFormation は、テンプレートの中の参照（!Ref など）から依存関係を読み取り、正しい順番で作ります。依存していないものは同時に作ります。図の番号札が、その順番です。

2. 失敗したら元に戻す。 10個の部品のうち7個目で失敗したら、どうなるでしょう。手作業なら「作りかけの6個」が残ります。CloudFormation は既定で、作りかけを消して実行前の状態に戻します。これをロールバックと呼びます。変更の途中で失敗したときも、変更前の状態に戻します。

3. まとめて消せる。 スタックを消すと、中の部品が作ったときと逆の順番でまとめて消えます。練習で作った環境の片付けが、1回の操作で済みます。

変える前に、何が起きるかを確かめる（変更セット）

テンプレートを直して、既にあるスタックに当てるとき、いきなり当ててはいけません。先に 変更セット（Change Set）を作ります。変更セットは、「このテンプレートを当てると、何を足し、何を変え、何を消すか」の一覧です。確かめてから実行します。

図の変更セットを読んでみます。

いちばん気をつけたいのが「置き換え」です。部品の設定の中には、後から変えられず、変えると作り直しになるものがあります。RDS で置き換えが起きると、新しい空の DB が作られ、古い DB はデータごと消えます。

こうした事故を防ぐために、CloudFormation には次の備えがあります。

コードと実物がずれる：ドリフト

IaC を始めても、誰かが画面から直接部品を変えてしまうことがあります。すると、コード（あるべき姿）と実物がずれます。このずれをドリフト（漂流）と呼びます。

図では、コードには「443 だけ開ける」と書いてあるのに、実物の SG は誰かが画面で「全開放」に変えています。

CloudFormation にはドリフト検出の機能があり、スタックの部品がテンプレートとどう違っているかを一覧にできます。見つけたら、次のどれかで片付けます。

そして根本の対策は、チームの決まりです。「本番は画面で変えない。変えるときはコードを直して当てる」。IaC は、この決まりが守られてはじめて効果を出します。緊急で画面から変えた場合も、後で必ずコードに反映します。

なお、ドリフト検出はすべての設定を見るわけではなく、テンプレートに書いた項目が中心です。細かい対応範囲は公式ドキュメントで確認してください。

CDK：ふだんのプログラミング言語で書く

CloudFormation のテンプレートは、部品が増えると何千行にもなります。VPC 1つでも、サブネット・ルートテーブル・インターネットゲートウェイ・NAT（第5〜7章）を全部書くと、かなりの量です。

そこで AWS CDK（Cloud Development Kit）の出番です。CDK では、TypeScript・Python・Java・C#・Go などのプログラミング言語で構成を書きます。

図の流れのとおり、CDK は自分で部品を作るわけではありません。

つまり、中身は CloudFormation です。スタック・ロールバック・変更セット・ドリフト検出は、そのまま使えます。

CDK のよさは、よい既定値の入った部品（コンストラクト）が用意されていることです。「2つの AZ にまたがる VPC」と1行書けば、パブリックとプライベートのサブネット、ルートテーブル、ゲートウェイまで、第5〜7章で学んだ形に沿って作ってくれます。

初めて CDK を使うアカウントとリージョンでは、cdk bootstrap という準備が1回だけ要ります。CDK が使う S3 バケットや IAM ロールが入ったスタック（CDKToolkit）が作られます。

CDK で書くフォトログ（抜粋）

図は、フォトログの構成を CDK（TypeScript）で書いた例の抜粋です（起動テンプレートの細かい設定など、一部を省いています）。

最後の1行に注目してください。「どの SG の、どのポートを、どこから許すか」を、CDK が部品どうしの関係から作ってくれます。手で書くと間違えやすいところです。

手で数百回クリックしていた構成が、このくらいの量のコードになります。そしてこのコードは、Git で履歴を残し、他の人にレビューしてもらえます。

Terraform：AWS 以外もまとめて書ける

AWS 純正ではない IaC の道具として、広く使われているのが Terraform（テラフォーム、HashiCorp 社）です。HCL という、設定を書くための専用の言語で書きます。

図の左は、EC2 を2台作る Terraform のコードです。count = 2 が「2台」を表します。

Terraform の使い方は、図の番号の2段階です。

CloudFormation との大きな違いは、状態（state）を自分で持つことです。

state には、部品の設定がそのまま書かれ、DB のパスワードなどの秘密が入ることもあります。Git に入れず、暗号化した S3 バケットに置き、読める人を絞ります。

Terraform は、AWS だけでなく、他のクラウドや DNS・監視などの外部サービスも、同じ書き方でまとめて扱えるのが強みです。なお、Terraform から分かれたオープンソースの OpenTofu という道具もあり、ほぼ同じ書き方で使えます。

3つの違いと、選び方

ここまでの3つを並べます。

どれを選んでも、宣言型で書き、差分を見てから当て、Git で履歴を残すという考え方は同じです。1つを身につければ、他の道具も読めるようになります。

選ぶときの問いは、次の3つです。

フォトログは AWS だけで作っていて、アプリも TypeScript で書いているので、CDK を選ぶことにします。

スタックの分け方：変わる速さと寿命で分ける

フォトログの全部を1つのスタックに入れることもできます。でも、それはおすすめしません。アプリの小さな変更を当てるたびに、VPC や DB まで変更の対象になるからです。

スタックは、変わる速さと寿命で分けます。図の番号の3つに分けると、次のようになります。

分けたスタックの間では、値を受け渡します。たとえば①が作った VPC の ID を、②と③が使います。CloudFormation では出力（Outputs）と、他のスタックからの参照でつなぎます。CDK では、スタック間でオブジェクトを渡すだけで、この受け渡しを作ってくれます。

こうしておけば、アプリの変更（③）で DB（②）が置き換えられる、という最悪の事故が起こりにくくなります。

同じコードで、環境をいくつでも作る

IaC の大きなごほうびが、同じコードから、いくつでも環境を作れることです。

図の左のように、コードは1つで、環境ごとに違うのは値だけにします。

冒頭の「本番と同じ試験環境を作って」は、stg の値で同じコードを当てるだけになりました。しかも、本番との違いは値の表として見えるので、「試験で通ったのに本番で壊れる」の原因を減らせます。

さらに、環境ごとに AWS アカウントを分けるのがおすすめです。開発者が dev で何を壊しても、本番のアカウントには届きません。複数のアカウントをまとめて管理する方法は、第27章（Organizations）で扱います。

試験環境は、使わない夜や週末に消しておき、朝に同じコードで作り直す、という使い方もできます。

手で作ったものを、コードに取り込む

「IaC がよいのはわかった。でも、フォトログの本番はもう手で作ってしまった」。そういうときの道具もあります。

進め方の例です。まず、IaC ジェネレーターで今の本番からテンプレートを起こし、中身を読んで理解します。次に、そのテンプレートでスタックを作り、部品を取り込みます。ここからは、そのスタックのコードが正解になります。

最初から全部を一度に移す必要はありません。変更の多いアプリの部分から少しずつ取り込むのが安全です。

取り込んだ後に守ることは1つです。「本番は画面で変えない。変えるときは、コードを直す → 変更セットで確かめる → デプロイする」。

お金：道具そのものより、作った部品に払う

IaC の道具にかかるお金は、思ったより小さいものです。

つまり、IaC にしたからといって、AWS の請求が大きく増えることはありません。

むしろ IaC はお金を守る道具です。

よくある落とし穴

IaC で起きやすい事故を並べます。

図のいちばん下の、緑の印の項目が基本の守りです。DB のように消えてはいけない部品には、削除保護と削除ポリシーを付け、差分を見てから当てる。

もう1つの落とし穴は、「コードの書き方」より「当て方」です。開発者が自分のパソコンから cdk deploy を実行していると、その人のパソコンにあるまだレビューされていないコードが本番に当たるかもしれません。これは次の第19章の話題です。

片付け：スタックを消せば、まとめて消える

IaC で作った練習環境は、片付けも簡単です。

ただし、次のものは残るので、確かめて必要なら手で消します。

データの入った S3 バケットは、中身が空でないと消せないことがあります。最後に Cost Explorer（第4章）で、料金が止まったことを確かめます。