この記事は下記のシリーズの第一回です。
AWSを使っていると、EC2やVPC、S3、RDSなど、さまざまなAWSリソースを作成することになります。
最初のうちは、AWSマネジメントコンソールから必要な項目を入力していけば、比較的簡単に環境を構築できます。
しかし、AWS環境が複雑になってくると、次のような問題に直面します。
- 同じ構成の環境をもう一度作りたい
- 開発環境と本番環境で同じ構成を用意したい
- 誰が、いつ、どの設定を変更したのか管理したい
- AWS環境の構成をコードとして残したい
- 手作業による設定ミスを減らしたい
- 一度削除した環境を同じ構成で再構築したい
こうした問題を解決するためのAWSサービスが、AWS CloudFormationです。
CloudFormationを使うと、AWSリソースの構成をテンプレートとして定義し、そのテンプレートをもとにAWS環境を構築・更新・削除できます。AWS公式ドキュメントでも、CloudFormationはAWSリソースをモデル化・セットアップするサービスとして説明されています。
この記事では、CloudFormationをこれから学ぶ方に向けて、まず押さえておきたい基本的な考え方を解説します。
この記事でわかること
この記事では、CloudFormationの細かな書き方に入る前に、まずCloudFormationが何のために存在するのかを理解します。
具体的には、以下について解説します。
- CloudFormationとは何か
- CloudFormationで何ができるのか
- なぜAWSをコードで管理するのか
- Infrastructure as Code（IaC）とは何か
- マネジメントコンソールで構築する場合との違い
- CloudFormationの基本的な仕組み
- Template、Stack、Resourceの関係
- CloudFormationを使うメリット
- CloudFormationを使う上での注意点
この記事では、まだCloudFormationの細かな構文を覚える必要はありません。
まずは、
「CloudFormationを使うと、AWS環境をどのように管理できるようになるのか？」
を理解することを目標にします。
CloudFormationとは？
CloudFormationは、AWSのインフラストラクチャをコードとして定義し、そのコードをもとにAWSリソースを構築・管理するためのサービスです。
例えば、AWS上に次のような環境を構築するとします。
Internet
│
▼
┌──────────┐
│ ALB │
└────┬─────┘
│
▼
┌──────────┐
│ EC2 │
└────┬─────┘
│
▼
┌──────────┐
│ RDS │
└──────────┘
通常であれば、AWSマネジメントコンソールなどから、それぞれのAWSリソースを作成していく必要があります。
一方、CloudFormationでは、この環境をテンプレートというファイルに定義します。
イメージとしては、
CloudFormation Template
│
│ 「この構成のAWS環境を作ってください」
▼
CloudFormation
│
├── VPC
├── Subnet
├── ALB
├── EC2
└── RDSという流れです。
CloudFormationがテンプレートに記述された内容をもとにAWSのAPIを呼び出し、必要なリソースをプロビジョニングしていきます。
つまり、CloudFormationを一言で表すなら、
AWSインフラの構成をコードで定義し、そのコードをもとにAWS環境を構築・管理する仕組み
と考えるとわかりやすいでしょう。
CloudFormationで何ができるのか？
CloudFormationでは、さまざまなAWSリソースをテンプレートに定義できます。
例えば、
- Amazon VPC
- Amazon EC2
- Amazon S3
- Amazon RDS
- Elastic Load Balancing
- Auto Scaling
- IAM
- Security Group
などです。
例えばS3バケットを作成するとします。
マネジメントコンソールから作成する代わりに、CloudFormationでは次のようなコードで定義できます。
Resources:
MyBucket:
Type: AWS::S3::BucketこのTemplateを使ってStackを作成すると、CloudFormationによってS3バケットが作成されます。
もちろん、実際のTemplateではバケット名や暗号化、ライフサイクルルールなど、必要に応じてさまざまな設定を追加できます。
このように、AWSリソースの構成をコードとして記述できることがCloudFormationの大きな特徴です。
Infrastructure as Code（IaC）とは？
CloudFormationを理解するためには、**Infrastructure as Code（IaC）**という考え方を知っておく必要があります。
IaCは、日本語では一般的に、
「インフラストラクチャをコードとして管理する」
という考え方です。
例えば、AWSでWebアプリケーションを構築するとします。
従来の方法では、
AWSコンソールを開く
↓
VPCを作成
↓
Subnetを作成
↓
Security Groupを作成
↓
EC2を作成
↓
RDSを作成
↓
各種設定を行うというように、人間が一つずつ操作していきます。
一方、IaCでは、
インフラ構成をコードで定義
↓
コードを実行
↓
AWS環境を構築という形にします。
つまり、
「AWSコンソールを操作すること」から「AWS環境をコードで定義すること」へ考え方を変える
のがIaCです。
CloudFormationは、このIaCをAWSで実現するためのサービスの一つです。AWS公式ドキュメントでも、CloudFormationはインフラストラクチャをコードとして扱い、AWSリソースのモデル化・セットアップを行うものとして説明されています。
なぜAWSをコードで管理するのか？
ここで、
「AWSコンソールから作ればいいのでは？」
と思う方もいるかもしれません。
実際、AWSコンソールから環境を構築すること自体は悪いことではありません。
むしろAWSを学び始めた段階では、コンソールから操作することでAWSの各サービスを理解しやすいというメリットがあります。
問題になるのは、環境が大きくなったときです。
手作業で構築すると再現が難しい
例えば、本番環境を次のように構築したとします。
VPC
├─ Public Subnet × 2
├─ Private Subnet × 2
├─ Internet Gateway
├─ NAT Gateway
├─ Route Table
├─ Security Group
├─ ALB
├─ EC2
└─ RDSこれをすべてAWSコンソールから手作業で構築したとします。
数週間後に、
「同じ構成の開発環境を作ってください」
と言われたらどうでしょうか。
もう一度、同じ設定を一つずつ入力する必要があります。
さらに、
- SubnetのCIDR
- Route Table
- Security Group
- IAM Role
- EC2の設定
- RDSの設定
などを完全に同じように設定しなければなりません。
ここで設定を一つ間違えると、最初の環境と異なる環境ができてしまいます。
コードなら同じ環境を再現できる
CloudFormationなら、AWS環境の構成をTemplateとして残せます。
CloudFormation Template
│
┌─────────┴─────────┐
▼ ▼
Development Production
│ │
▼ ▼
AWS環境 AWS環境
同じTemplateを使えば、同じ設計をベースに複数の環境を構築できます。
AWS公式ドキュメントでも、Templateを再利用することで、複数リージョンなどに一貫した繰り返し可能な方法でリソースをプロビジョニングできると説明されています。
マネジメントコンソールとCloudFormationの違い
CloudFormationを学ぶときに混乱しやすいのが、
「結局、AWSコンソールと何が違うの？」
という点です。
ざっくり比較すると、次のようになります。
| マネジメントコンソール | CloudFormation | |
|---|---|---|
| 構築方法 | 画面から操作 | Templateを記述 |
| インフラ構成 | 頭やドキュメントで管理 | コードとして管理 |
| 再構築 | 手作業が必要 | Templateから再構築 |
| 再利用 | 手順を再現 | Templateを再利用 |
| 変更管理 | 操作履歴などに依存 | Templateの変更として管理 |
| 自動化 | 別途仕組みが必要 | Templateをもとに自動構築 |
| 複数環境 | 手作業が増えやすい | 同じTemplateを利用可能 |
ただし、CloudFormationがマネジメントコンソールの完全な代替になるというわけではありません。
AWSの仕組みを理解したり、ちょっとした検証環境を作ったりする場合には、マネジメントコンソールが便利です。
一方で、
「AWS環境を繰り返し構築する」
「構成をコードとして管理する」
「変更内容を明確にする」
といった場面では、CloudFormationのメリットが大きくなります。
CloudFormationの基本的な仕組み
ここからは、CloudFormationを理解するうえで非常に重要な3つの言葉を覚えましょう。
Template
│
│ デプロイ
▼
Stack
│
├── Resource
├── Resource
└── ResourceCloudFormationでは、基本的に、
Template → Stack → Resource
という関係で考えると理解しやすくなります。
Templateとは？
**Template（テンプレート）**は、AWS環境の設計図にあたるファイルです。
CloudFormation Templateでは、
「どのAWSリソースを、どのような設定で作るのか」
を記述します。
CloudFormation Templateは、YAMLまたはJSON形式で記述できます。AWS公式ドキュメントでは、Resources セクションが必須で、少なくとも1つのリソースを宣言する必要があるとされています。
例えば、
Resources:
MyBucket:
Type: AWS::S3::BucketというTemplateがあったとします。
これは、
「S3バケットを1つ作ってください」
というAWS環境の定義です。
Templateは、あくまで**「こういうAWS環境を作りたい」という設計図**だと考えるとわかりやすいでしょう。
Stackとは？
次に、**Stack（スタック）**です。
Stackは、CloudFormationによって管理されるAWSリソースの集合です。
AWS公式ドキュメントでは、Stackを「関連するAWSリソースを一つの単位として管理するもの」と説明しています。Stack単位でリソースの作成・更新・削除を行えます。
例えば、
Template
│
│
▼
Stack
├── VPC
├── Subnet
├── Security Group
├── EC2
└── RDSという関係です。
TemplateにAWS環境の構成を記述し、そのTemplateを使ってStackを作成します。
するとCloudFormationが、Templateに定義されたAWSリソースを作成します。
Resourceとは？
最後が**Resource（リソース）**です。
Resourceは、実際にCloudFormationによって作成・管理されるAWSリソースです。
例えば、
- VPC
- Subnet
- S3 Bucket
- EC2 Instance
- RDS Database
- IAM Role
- Security Group
などがResourceに該当します。
Templateでは、Resources セクションの中にResourceを定義します。
例えば、
Resources:
MyBucket:
Type: AWS::S3::Bucketこの場合、
MyBucket
│
└── AWS::S3::BucketというResourceを定義しています。
MyBucketはCloudFormation上でResourceを識別するための論理IDで、AWS::S3::Bucketが作成するAWSリソースの種類を表しています。
Template・Stack・Resourceの関係
ここまでを整理すると、次のようになります。
┌─────────────────────────────┐
│ Template │
│ │
│ 「どんなAWS環境を作るか」 │
│ │
│ Resources: │
│ ├─ VPC │
│ ├─ Subnet │
│ ├─ EC2 │
│ └─ RDS │
└──────────────┬──────────────┘
│
│ Templateを使って
│ Stackを作成
▼
┌─────────────────────────────┐
│ Stack │
│ │
│ AWSリソースをまとめて管理 │
│ │
│ ├─ VPC │
│ ├─ Subnet │
│ ├─ EC2 │
│ └─ RDS │
└─────────────────────────────┘もっと簡単に言うと、
Template = 設計図
Stack = 設計図から作られたAWS環境を管理する単位
Resource = Stackに含まれるAWSリソース
と覚えておけば、最初は十分です。
CloudFormationはどのようにAWS環境を作るのか？
CloudFormationを使った構築の流れを整理すると、次のようになります。
① Templateを作成
│
▼
② Stackを作成
│
▼
③ CloudFormationがTemplateを読み取る
│
▼
④ AWSの各サービスへAPIを呼び出す
│
▼
⑤ AWSリソースを作成
│
▼
⑥ AWS環境が完成例えば、Templateに、
Resources:
MyBucket:
Type: AWS::S3::Bucketと書いてStackを作成すると、CloudFormationがAWS側で必要な処理を行い、S3バケットをプロビジョニングします。
CloudFormationはTemplateに記述された内容に基づいてAWSサービスへの呼び出しを行い、リソースをプロビジョニングします。
CloudFormationを使うメリット
ここまでの内容を踏まえると、CloudFormationを使うメリットは大きく4つあります。
1. AWS環境をコードとして管理できる
最大のメリットは、AWS環境の構成をコードとして残せることです。
例えば、
VPC
Subnet
Route Table
Security Group
EC2
RDSといった構成をTemplateとして管理できます。
そのため、
「このAWS環境はどういう構成になっているのか？」
をTemplateから確認できます。
2. 同じ環境を再現できる
Templateを使えば、同じ構成を繰り返し構築できます。
例えば、
Template
│
┌────────┼────────┐
▼ ▼ ▼
Dev Stg Prod
│ │ │
▼ ▼ ▼
AWS環境 AWS環境 AWS環境
のように、同じ設計をベースとして複数の環境を構築できます。
もちろん、環境ごとに異なる値を設定することもできます。
この仕組みについては、後の記事でParametersなどを使いながら詳しく扱います。
3. AWS環境の変更を管理しやすい
CloudFormationでは、Templateを変更してStackを更新するという形でAWS環境を変更できます。
例えば、
InstanceType: t3.smallを、
InstanceType: t3.mediumに変更するとします。
Templateの変更内容をCloudFormationに反映することで、Stackの更新を行えます。
また、更新前に**Change Set（変更セット）**を作成し、どのような変更が行われるかを確認することもできます。AWS公式ドキュメントでも、Change Setによって変更が実行中のリソースへ与える影響を事前に確認できると説明されています。
4. 環境をまとめて管理できる
CloudFormationでは、関連するAWSリソースをStackという単位で管理できます。
例えば、
WebApplicationStack
├── VPC
├── Subnet
├── Security Group
├── ALB
├── EC2
└── RDSというStackを作れば、この環境を一つのまとまりとして管理できます。
Stack単位で作成・更新・削除を行えるため、複数のAWSリソースを個別に操作するよりも、環境全体を管理しやすくなります。
CloudFormationの注意点
ここまでCloudFormationのメリットを紹介してきましたが、CloudFormationを使えばすべてが簡単になるわけではありません。
むしろ、AWS環境が複雑になるほど、CloudFormation自体の設計が重要になります。
Templateが複雑になる
AWS環境が大きくなると、Templateも大きくなります。
例えば、
VPC
├─ Subnet
├─ Route Table
├─ NAT Gateway
└─ Security Group
ALB
├─ Listener
└─ Target Group
EC2
└─ IAM Role
RDS
└─ Security Groupのような環境をすべて一つのTemplateに書くと、非常に長いTemplateになる可能性があります。
そのため、
「どこまでを一つのStackにするか？」
「Templateをどう分割するか？」
といった設計も重要になります。
このシリーズでは、後半でStackの分割や複数環境の管理についても扱います。
CloudFormation特有の知識が必要になる
CloudFormationでは、AWSそのものの知識に加えて、
- Template
- Stack
- Parameters
- Outputs
- Intrinsic Functions
- Resource Dependencies
- Change Sets
- Drift Detection
など、CloudFormation特有の概念を理解する必要があります。
最初は覚えることが多く感じるかもしれません。
しかし、一つずつ実際のAWS環境を作りながら学んでいけば、それほど難しいものではありません。
Templateを書いたからといって、必ず安全に変更できるわけではない
CloudFormationで特に重要なのが、Templateの変更によってAWSリソースが置き換えられる場合があることです。
例えば、あるプロパティを変更した結果、既存のリソースを変更するのではなく、
既存リソース
│
│ 変更
▼
新しいリソースを作成
│
▼
古いリソースを削除という動作になる場合があります。
特にデータベースなどの重要なリソースでは注意が必要です。
そのため、CloudFormationを実際の環境で使う場合には、
「Templateを書けば安全に更新できる」
と考えるのではなく、
「Templateの変更によってAWS上で何が起きるのかを確認する」
という意識が重要です。
Change Setを利用して、変更内容を事前に確認することもできます。
CloudFormationを使うと、AWSの設計方法も変わる
CloudFormationを学ぶうえで、個人的に特に重要だと考えているのがここです。
CloudFormationは単なる、
「AWS環境を自動で作ってくれるツール」
ではありません。
CloudFormationを使うことで、AWS環境そのものを、
「コードとして設計する」
という考え方が必要になります。
例えば、これまでは、
AWSコンソールを開く
↓
必要な設定を入力する
↓
AWSリソースを作るだったものが、
AWS環境を設計する
↓
構成をTemplateとして表現する
↓
CloudFormationでStackを作る
↓
AWS環境が構築されるという流れになります。
つまり、
「どうやってAWSリソースを作るか」だけではなく、「どのようなAWS環境を作るのか」を先に考える
ことが重要になります。
これは、このシリーズ全体で身につけていきたい考え方です。
まとめ
今回は、CloudFormationを学ぶ最初のステップとして、CloudFormationの基本的な考え方を紹介しました。
この記事の内容をまとめると、次のようになります。
| 用語 | 意味 |
|---|---|
| CloudFormation | AWSインフラをコードで定義・構築・管理するサービス |
| IaC | インフラをコードとして管理する考え方 |
| Template | AWS環境の構成を記述した設計図 |
| Stack | AWSリソースをまとめて管理する単位 |
| Resource | VPCやEC2、S3などのAWSリソース |
そして、CloudFormationの基本的な流れは、
AWS環境を設計
↓
Templateを書く
↓
Stackを作成
↓
CloudFormationがAWSリソースを構築
↓
Templateを変更
↓
Stackを更新となります。
CloudFormationを理解するうえで、まずは
Template → Stack → Resource
という関係を押さえておきましょう。
ここが理解できれば、これから学ぶCloudFormationの各機能も理解しやすくなります。
次の記事
次回は、いよいよCloudFormation Templateの書き方に入ります。
CloudFormation TemplateはYAMLまたはJSONで記述できますが、このシリーズでは基本的にYAMLを使って解説していきます。
次の記事では、実際に最小構成のTemplateを書きながら、
- Templateの基本構造
Resources- Resourceの論理ID
TypeProperties- YAMLの基本的な書き方
などを解説します。
最初はできるだけシンプルなTemplateから始め、少しずつAWSリソースを追加していきます。
コメント