この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「俺は、なんだかんだCloudFormationが大好きだ！」
うららかな小春日和の11月、下記イベントで登壇してきました。
このブログでは、「AWSの全てをコードで管理する方法〜その理想と現実〜」というタイトルで思う存分喋ったその様子を丸ごと喋り含めてお届けいたします。主にCloudFormationについて喋ったのですが、機能を網羅的に紹介するよりは全体的に主観強めに喋っているので、そのあたり味わい深く読んでいただければ楽しめますYO
（祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 CloudFormationﾏﾂﾘﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ
セッション概要「AWSの全てをコードで管理する方法」
セッション概要
AWSの最大の特徴の一つ、「コードによるインフラの運用管理」 アプリケーションやインフラ運用のさらなる効率化を目指す時、IaC（Infrastructure as Code）の導入は必須と言えます。その効果は絶大ですが、下手に導入してしまうと逆に運用管理自体の硬直化を招き「最初は楽しかったのに、今はなんでこんな辛いんだろう…」という気持ちになってしまいます。
このセッションでは、CloudFormationやTerraform、CDKなどのIaCの手段について触れつつ、各運用現場に即したIaCを導入するために考えるべきことについて、お話します。
セッション聴講対象者
聴講対象者と、どこに着目して欲しいかをざっくりまとめると下記の通り。
- Infrastructure as Code未体験の人
- その可能性に気づきCloudFormationを書きたくてうずうずしてもらう
- Infrastructure as Code未体験の人
- 今の運用を見直すきっかけとしてもらう
冒頭「なぜ、ハマコーはここに立っているのか？」
本日ですが、ちょっとデカ目の煽ったタイトルでお話します。
「AWSの全てをコードで管理する方法 〜その理想と現実〜」
みなさん、AWSをコードで管理することにどんなイメージをお持ちですかね？自分はこんなイメージです。
滑ってますかね。良いんです。じわじわ来るぐらいで良いです。まぁなんか強そうですね。CloudFormationって、他のAWSのサービスとはレイヤーが違うと思うんですね。全てのサービスの産みの親といっても過言じゃないです。
めちゃくちゃ強力、だけどつかいこなしが難しい。そんなCloudFormationですが、もしCloudFormationを知らないとどうなるか？
皆さん、本日このイベントに来ているということは、AWS好きですよね。AWSの経験も様々だと思うんですが、日々AWSを運用していくなかで、その工程を自動化するかどうか？判断する手段を知っておかないと、機会損失が大きくなります。これはもったいない。
みなさんのこれからのAWSライフがより良いものになることを願って、今自分はここに立っております。
セッションの全体構成
こんな流れでお話しします。CloudFormation、歴史が長いだけあってものすごく機能が豊富なんですが、その機能を網羅的に一つずつ解説していっても面白くないんですよね。どちらかというと、CloudFormationを使いこなしていく段階を追いながら、一つずつよくある課題とそれを解決する機能で説明したほうが頭に入るとおもうので、こういう構成にしています。
あともう一点。今日のセッション、全体的に自分の主観が強めです。個人的に、要らない機能は要らないとはっきり言うのでその点きをつけてください。
ほな、いきますか！
「１．Infrastructure as Code」を理解する
Infrastructure as Codeって何か？単純に言うとこんな感じです。
特徴としては、何回このテンプレートを実行しても、インフラ側は変わりません。対して、AWS CLIの例を見てみましょう。
AWS CLIは処理を定義しているため、インフラ増えていきます。この「インフラの状態を定義」しているのか「処理を定義」しているのか、この違いが根本的な違いです。
本日は、このInfrastructure as Codeの手法として、次の3つの中から、CloudFormationについてお話します。
- AWS CloudFormation（今日のメイン）
- Terraform by HashiCorp
- Cloud Development Kit（CDK）
CloudFormationの概要
最初にCloudFormationの概要をおさえておきましょう。CloudFormationでは、テンプレートというテキストファイルからスタックが作成され、そこからAWSリソースが作成されます。
テンプレートのサンプル。
AWSTemplateFormatVersion: '2010-09-09'
Description: ecr
Parameters:
accountAlias:
Type: String
Resources:
ecr:
Type: AWS::ECR::Repository
Properties:
RepositoryName: !Sub ${accountAlias}-ecr
Outputs:
ecr:
Value: !GetAtt ecr.Arn
Export:
Name: ecrテンプレートには、いろんな要素が入ります。こちらはテンプレートに含まれる要素の一覧ですが、個人的に重要な部分は以下の部分。Conditionsが取り扱い注意なのは、後で説明します。
- AWSTemplateFormatVersion（書いておきましょう）
- Parameters（ほぼ必須）
- Conditions（取り扱い注意）
- Resources（必須）
- Outputs（ほぼ必須）
また、CloudFormationはAWSの全てのリソースに対応しているわけではないのでそこも注意。といっても、ほぼ普通に使うリソースは対応しているので、困ることはあまりないんじゃないでしょうか。一覧はこちら。
CloudFormationを使う主なメリット
- インフラの管理を簡略化
- 一度テンプレートからスタックを作成しておくと変更が簡単。また、スタック単位でのリソース一括削除も可能
- インフラを簡単に複製可能
- テンプレートを使い回すことで、複数リージョンへのインフラ展開が簡単
- インフラの変更管理が可能
- テンプレートのテキストファイルをベースにすることでバージョン管理システムによるインフラ管理が可能
CloudFormationを学ぶための資料
実際に、CloudFormationのテンプレートを書いて学んでいくためにいろんな資料がありますが、まずはこれを読むことをオススメします。一番ミニマムなテンプレートから、テンプレートの書き方の基礎と実行方法を段階的に解説します。
【CloudFormation入門】5分と6行で始めるAWS CloudFormationテンプレートによるインフラ構築
また、各種テンプレートのスニペットはこちらから参照できます。
ここまでで、CloudFormationの基礎を理解していただきました。
「２．CLIで実行する」
ある程度CloudFormationに慣れて、本格的に実行していくとき必ず最初にとりいれたほうが良いことがあります。CLIでCloudFormationを実行することです。
CloudFormationを使うメリットでも述べましたが、テンプレートにインフラの状態を落とし込み、そのテンプレートに沿って同じものが作成されるように整備したとしても、実行方法がWebコンソールのままだと、作業の再現性が担保できません。
そこで、CloudFormationをCLIで実行するときに、皆さんに必ず注意しておいてほしいことがあります。
「CLIでCloudFormationを実行する場合、必ずdeployを使う」
CLIで実行する場合、aws cloudformationコマンドを使います。
ここにサブコマンドが大量にありますが、必ず、create-stack、update-stackではなくdeployを使ってください。
（非推奨）create-stack、update-stackの挙動
create-stack、update-stackの代表的な挙動をあげます。
- 何故かコマンドに冪等性がない
- スタックが無いときはcreate→２回目以降はエラー
- スタックが有るときはupdate→1回目はエラー
- コマンドが非同期で実行される→別途結果を待ち受ける必要有り
- 関連コマンドを使い分ける必要がある
- wait stack-create-complete
- create-change-set
- wait change-set-create-complete
- execute-change-set
- wait stack-update-complete
- wait stack-delete-complete
一番つらいのは、スタックの有無によって、コマンドを切り替える必要がある点です。関連して、その他のコマンドの使い分けも必要になってきます。
（推奨）deployの挙動
自分が推奨しているdeployの特徴を以下にあげます。
- 新規も更新もこのコマンドで完結
- チェンジセット（後述）が必ず作成される
- validate-templateの実行とか流さなくてもdeployするだけでエラーは把握可能
- コマンドが同期的に実行される→スタック作成完了時に結果が戻る
じゃぁ、deployの場合、一体どんな感じで実行できるか、シェルの例を記載します。
#!/bin/bash
CFN_TEMPLATE=vpc.yml
CFN_STACK_NAME=vpc
# テンプレートの実行
aws cloudformation deploy --stack-name ${CFN_STACK_NAME} --template-file ${CFN_TEMPLATE} \
--parameter-overrides \
NameTagPrefix=prd \
VPCCIDR=10.70特に難しいものではないのですね。こんなシェルを用意しておけば、いつでもCloudFormation実行できるので参考にしてください。
deployコマンドには大きすぎる罠がある
ここで、deployコマンドの怖いところお話しします。自分が実際に事故ったときの話です。こんな感じでCodeCommitのリポジトリ２つ作りました。
その後、別のアプリ用のCodeCommit欲しいなと思い、もう一つテンプレート作って実行しました。
はい。みなさん、ここで盛大に事故っていることに気づいたでしょうか？ポイントは1回目と2回目で同じスタックに更新をかけていることです。賢明な皆さん、何が起こったかわかりますでしょうか？こうやって見渡すと、ニヤニヤされている方いますね。恐らく気づいてそうです。
はい。そうです。最初に作っていたCodeCommitが消えました。
これすごいですよ。本当になんの前触れもアラートもなく消えます。普通こういうリソースって、Webコンソールから消すときは「delete」とか入れさせたり何かのアラートが標準で出るじゃないですか。deployコマンドのデフォルトの挙動は、まったくそういうアラートでないです。スーッと消えます。本番環境でやったらと思うと背筋が凍りますね。
CloudFormation、扱い方を間違えると劇薬となります。
チェンジセットを知ろう
皆さんには、こういった事故を防止するため、チェンジセットを必ず知っておいてもらいたい。実は、deployコマンド使うと、スタックが更新されるまえに、必ずチェンジセットが作成されてから、スタックに適用されます。こんな感じです。
先程の例だと、実はマネジメントコンソールをみると、これから削除されるリソースもちゃんとチェンジセットに表示されていたんですね。これ見てれば、事故は防げました。
ただ、deployコマンドはデフォルトの挙動では、チェンジセット作成後、それをすぐにスタックに適用します。これを、チェンジセットだけ出力してスタックに適用しないために、--no-execute-changesetというオプションが用意されています。
これをうまく使うため、先程のシェルを改造して、引数にdeployが渡されていたときだけ、スタックを更新するようにします。
この場合、チェンジセット作成するだけでスタックの更新はしません。
$ 010-vpc.sh引数にdeploy指定時のみスタックを更新するようにします。
$ 010-vpc.sh deploy実際のシェルの中味見てみましょう。引数判定してその文字列がdeployと指定されているときのみ、CHANGESET-OPTIONを空文字列にしてスタックを更新します。
#!/bin/bash
CHANGESET_OPTION="--no-execute-changeset"
if [ $# = 1 ] && [ $1 = "deploy" ]; then
echo "deploy mode"
CHANGESET_OPTION=""
fi
CFN_TEMPLATE=App2Repos.yml
CFN_STACK_NAME=AppRepos
# テンプレートの実行
aws cloudformation deploy --stack-name ${CFN_STACK_NAME} --template-file ${CFN_TEMPLATE} ${CHANGESET_OPTION} \
--parameter-overrides \
NameTagPrefix=prd \
VPCCIDR=10.70これで、無駄な事故はある程度防げることでしょう。
CloudFormationの実行結果確認はGUIが圧倒的に便利
ここまで説明したとおり実行はCLIが便利ですが、実行結果の閲覧は、無理にコマンド使ってJSONみるよりもGUIのほうが圧倒的に見やすいです。コンソールもどんどん改良されているので、作成されたリソースの確認やエラーのデバッグなど是非コンソールを活用してみてください。
「３．複数リソースを作成する」
CloudFormationに慣れてくると、皆さんいろんなリソースを作りたくなってきます。VPC、ネットワーク、SecurityGroup、ALB、EC2、RDSをCloudFomationで作りたい。これらを1つのテンプレートに書いても良いんですが、全部含めると恐らく1000行を超えるテンプレートになります。そんなテンプレート、メンテできますかね？
というわけで、ある程度の規模のリソースをCloudFormationで扱おうとすると、テンプレートやスタックの分割をどうするかを必ず考える必要があります。
テンプレートとスタックの分け方
どのようにスタックを分けるかですが、一つ実例をだして考えてみましょう。まずは各リソースの依存関係を図示してみます。こうすると、どのリソースから作っていくのが良さそうかイメージが湧きやすいですね。
具体的なシェルとテンプレートの一覧はこちら。
$ tree
.
├── 010-vpc.sh
├── 020-security-group.sh
├── 030-alb.sh
├── 040-ec2.sh
├── 050-rds.sh
├── alb.yml
├── ec2.yml
├── rds.yml
├── securitygroup.yml
└── vpc.ymlものすごい地味で簡単ですね。でもこれぐらい地味なほうがわかりやすいと思います。
- 依存関係をシェルのファイル名のプレフィックスで明示
- シェル実行順と依存関係がひと目で分かる
- テンプレートは別ディレクトリにまとめても良い
具体的に各スタックに含まれるリソースの一覧がこちら。これはあくまで一例なので、各リソースのライフサイクルなどに合わせて、個別に調整してみてください。
スタック間のパラメーターの参照方法
こうやって、スタックを分割したわけですが、スタックを分けたときのスタック間でのリソースの参照方法をどうするのか？という問題がでてきます。例えば、EC2を作るときのサブネットのIDとかですね。このスタック間のリソースを参照するための方法は、いくつか種類がありますが、ここでは3つあげます。
- クロススタック参照を使う
- CloudFormationマネージドな仕組み
- 基本はこれ（ハマコー一番好きなやつ）
- ダイナミック参照を使う
- テンプレートからパラメータストアやSecrets Managerを参照
- シェルで頑張る
- テンプレートを呼び出す前にシェルでパラメータを頑張って作る
- 汎用性は一番高い
方法①「クロススタック参照」
一番汎用性が高い方法です。自分は一番これが好みですね。最初に作るスタックのテンプレートOutputにExportでパラメータ名を付与します。ここではパラメータ名をPublicSubnet1aとしています。
vpc.yml
Outputs:
PublicSubnet1a:
Value: !Ref PublicSubnet1a
Export:
Name: PublicSubnet1a別のテンプレートでは!ImportValue句を使い、パラメータ名を指定して参照が可能です。
ec2.yml
Type: AWS::EC2::Instance
Properties:
SubnetId: !ImportValue PublicSubnet1aこうやって便利に使えるクロススタック参照ですが、注意点が一つあります。パラメーターを参照しているスタックがあると元のスタックの参照元リソースの変更や削除ができません。
これは安全設計という点で非常に良いんですが、このために運用が詰むパターンがあります。それがこちら。こんなふうに参照元を先に変更する必要があるリソースはクロススタック参照使えません。
これは、実際に運用を開始しないと気づかない場合が多いと思いますが、頭の片隅に置いといてください。
方法②「ダイナミック参照」
テンプレートからAWS Systems Managerのパラメータストアや、AWS Secrets Managerを直接参照する方法です。
使い方としては、予めシェルやWebコンソール、もしくはCloudFormationでも良いので、パラメータストアやSecrets Managerに値を登録しておきます。
そうすると、テンプレートの中で以下の記法で、その値を参照できます。これも便利。
rds.yml
Resources:
rds:
Type: AWS::RDS::DBInstance
Properties:
MasterUserPassword: {{resolve:ssm-secure:RDSMasterUserPassword:10}}方法③「シェルで頑張る」
これは頑張れって話なんですが、CloudFormationでリソースを作っても全てのプロパティがエクスポートできるわけではないです。そういった値を別のテンプレートで参照したい場合は、これはもうシェルで頑張りましょう。
下の例だとIMAGE_URIをCLIで取得しています。こういうパターンもよく出てくるので、シェルを使っているとこういう場合に融通が効いて良いですね。
task.yml
# タスク設定用パラメータ
CPU=256
MEMORY=512
IMAGE_URI=$(eval aws ecr describe-repositories --repository-names app-ecr --query 'repositories[0].repositoryUri' --output text)
# テンプレートの実行
aws cloudformation deploy --stack-name ${CFN_STACK_NAME} --template-file ${CFN_TEMPLATE} \
--capabilities CAPABILITY_NAMED_IAM \
--parameter-overrides \
cpu=${CPU} \
memory=${MEMORY} \
imageUri=${IMAGE_URI}「４．運用上の辛みを理解する」
ここまで、CloudFormationの嬉しさを中心に話してきましたが、ここでは実際にCloudFormationをあれこれ触ってみたときに感じた辛みを中心にお話します。ちょっと愚痴が多いかもしれませんｗ 5つ目は非常に重要なやつです。
- スタックの作成〜削除がいつまでたっても終わらない場合がある
- 対応していないプロパティがある
- 循環参照するには書き方に工夫が必要
- Conditionsに頼らない（使わない）
- （重要）CloudFormation以外でリソースが変更されたときの対処
ハマリポイント①「スタックの作成〜削除がいつまでたっても終わらない場合がある」
完全にケースバイケースなんですが、スタックの作成や削除がいつまでたっても終わらない場合が結構あります。エラーにすぐなる場合もあれば、全然返ってこないときもあったりとか。
返ってこない例「すでにリソースにアタッチされているセキュリティグループの削除」
EC2等にアタッチされているセキュリティグループをCloudFormationから削除しようとすると、スタックの削除が全然終わらないです。デフォルトタイムアウト（1時間）までずーっと頑張っているので、全然結果が返ってこずに変だと思ったら、スタックの実行をキャンセルしましょう。
返ってこない例「ECSサービスの作成」
CloudFormationでECSのサービスが作成される→タスクが起動する→コンテナ起動して普通に使える→ログも正常と普通に使えているんですが、何故かスタック作成が終了しない。で1時間後、スタック作成タイムアウトからロールバックでコンテナもECSサービスも削除されるという事象が発生しました。
これ、3日間ぐらいドハマリしてたんですが、結論としてはテンプレートの書き方に不備がありました。ただ、それならエラーを出していただけると…と思った次第です。
ハマリポイント②「新機能など、対応していないプロパティがある」
これはあるあるです。AWSで新機能がでたとしても、それを設定するためのプロパティがCloudFormationに対応していないことが多くあります。。だいたい1ヶ月〜半年ぐらいはかかるので、気長に待ちましょう。AWS CLIはたいてい対応しているので、我慢できないときはそちらで頑張るのも一つの手です。
ハマリポイント③「リソースを循環参照させるには書き方に工夫が必要」
複数リソースが相互に参照しているテンプレートは、そもそもスタックを作成できません。セキュリティグループなどでよくありますね。アプリケーションサーバが相互参照するなど。そのまま書くとcircular dependencies（循環参照）というエラーがでます。
こういう場合は、リソースを直接相互参照させないような書き方の工夫が必要になります。セキュリティグループの場合、以下の2つを分けてリソース定義するなどで対処します。
- AWS::EC2::SecurityGroup
- AWS::EC2::SecurityGroupIngress
ハマリポイント④「Conditionsに頼らない（使わない）」
Conditionsはテンプレートの中に条件分岐を埋め込む記法です。
Resourcesに対して、パラメータの条件によりリソースの作成有無などを指定可能。例えば、パラメータに”prod”が記載されている場合にEC2インスタンスを作成するなどの使い方ができる。
ec2.yml
Parameters:
Env:
Type: String
Conditions:
CreateResources: {"Fn::Equals" : [{"Ref" : "Env"}, “prod"]}
Resources:
Ec2:
Type: "AWS::EC2::Instance"
Condition: "CreateResources"これ便利なのですが、使いすぎないほうがよいです。理由は、インフラをそのまま定義するテンプレートの記法と、条件を記述する記法が相性が悪く可読性が著しく下がるためです。
基本はテンプレートへ「処理」は記載しないほうがよくて、どうしても1テンプレートで完結させたい場合のみ利用することを推奨します。そもそも環境で構成が違うのであればテンプレート自体を分けるか、もしくはシェルの中で条件判定をして、その結果をパラメータとして渡して処理するほうがわかりやすいです。
ハマリポイント⑤「CloudFormation以外でリソースが変更されたときの対処」
めちゃくちゃよくある事故です。
本来こういうことがおこらないように、リソースを変更する人の権限をIAMで絞ったりとか運用上の工夫をするべきですが、一人でやっててもこういうことは起こりえます。対処方法として、CloudFormationのドリフト検出という機能が使えます。
こんな感じで、スタックの状態とリソースの状態を比較して、もしそこに差分があったらそれを表示してくれる機能です。ただ、これを、手動で毎回実行するのも手間で、検出自体は自動的にやりたいじゃないですか。
そこで、AWS Configの出番です。AWS Configにはcloudformation-stack-drift-detection-checkというマネージドルールがあって、これを使うことでドリフト検出を自動化することが可能です！最高に便利です。
実際の設定方法は、こちらのブログにまとめられているので、是非こちら参考に皆さんの環境で設定しておきましょう。
ただ、ドリフト検出も万能ではないので以下の点注意です。
検出できるリソースに制限があります。まぁメジャーどころのリソースはだいたい対応しています。素晴らしい。
また、動的に設定されたプロパティなどは検出対象外だったりします。ここらへんも、以下のマニュアルを事前に読み込んでおくことを推奨します。
「５．パイプラインでインフラ構築を自動化する」
最後に、パイプラインでインフラ構築を自動化するお話です。実は、今までCloudFormationをどこで実行するかの話をしていませんでした。候補としてはだいたい3つあるかと思います。
- 個人のクライアントPC
- 適切な権限を保持したIAMユーザーでAWS CLIをインストールして実行
- 適当なEC2インスタンス（Cloud9）
- EC2インスタンスに適切なIAMロールを付与
- EC2インスタンスにSSH接続できるユーザーにより実行
- リポジトリからのパイプライン実行
- テンプレートのリポジトリコミットからのパイプラインによる実行
ただ、テンプレートをバージョン管理する前提であれば、おのずから最終的には、パイプラインからの実行が必然的な最終形態になりますよね。だって、そうしないとリポジトリにあるテンプレートと、AWS インフラの同期が保証されないわけですから。
ただ、これを本気でやろうとすると、非常に難しいです。CloudFormationやそもそものIaCになれた組織じゃないとメリットを享受できないとおもいますが、取り組んでみる価値も十分にあると思います。
CodePipelineを利用して、CodeCommitにプッシュされたテンプレートをAWSインフラに反映する例を紹介します。
CodeBuildは任意のコマンドをbuildspec.ymlから実行できるので、もともと用意していたシェルを実行しつつ、チェンジセットを作成してあげて、承認からのAWSリソース適用といったことも簡単にできます。
この前後で、CloudFormationのテンプレートのテストを自動化したくなりますが、そのために以下のツールの利用を検討してみるのも良いでしょう。
cfn-nag
stelligent/cfn_nag: Linting tool for CloudFormation templates
CloudFormationテンプレートを解析し、セキュリティ的に脆弱な内容を検査するツールで、例えば以下のテンプレートがあったときに、エラー判定してくれます。また、自分で独自のルールを作成したり、カスタマイズでエラーとワーニングの切り替えもできます。
- 非常に強いIAMポリシーの適用
- 脆弱なセキュリティグループの適用
- S3バケットポリシーのワイルドカードプリンシパル
こういったツールはテンプレートに対して自動チェックするようにパイプラインを構築することも可能なので、テンプレート反映を自動化するときは、前後にこういったツールを挟むのもテンプレートの品質向上に役立つと思います。
AWS CloudFormation Validation Pipeline
AWS CloudFormation Validation Pipeline - AWS CloudFormation Validation Pipeline
さらに本格的な運用を目指す場合、AWS Solutionsに、CloudFormationのバリデーションパイプラインを構築するサンプル一式が紹介されているので、こちらも参考にしてみてください。最初からテストするステージが用意されていたり、より実践的です。
CI/CD Pipeline for AWS CloudFormation Templates on the AWS Cloud Using AWS TaskCat
こちらは、Quick Starg Guidesに含まれているCloudFormationのテンプレートをCI/CDパイプラインに乗せるサンプルです。こちらでは、aws-quickstart/taskcatというツールを使って、GitHubベースでパイプラインを作成する方法が紹介されています。
まとめ「CloudFormationをフル活用して、みなさんのAWSライフをより豊かなものになることを願って」
ここまで順を追ってCloudFormationを中心に、AWS上にリソースを作成していく手法を紹介してきました。CloudFormationの学習コストは、正直他のサービスと比べても高いですしとっかかりづらいところはあります。
ただ、一度その手段をしっておけば皆さんの普段のAWS運用を劇的に効率化できる可能性もあるので、ぜひ一度未体験の人は、CloudFormation試してみることを強くオススメします。
そして、AWS運用を効率化させて、みなさんのビジネスがより良いものになることを願っております。ご静聴、ありがとうございました！
登壇資料
実際の登壇資料はこちら。
ブログ記事に自分の喋り含めて全て記載しているので、内容把握される場合は、このブログを見ていただくほうが伝わるかと思います。
ハマコーによる登壇後日談
普段、AWSインフラのコンサルや構築の中でCloudFormationを使うことは多くあります。使えば使うほど味があるサービスというか、強いんですよ。ほんとめちゃくちゃ強いんですが、やっぱり使いこなしが難しく感じる部分も多いです。そこらへんのモヤモヤを可能な限り昇華してつめこんだのがこのセッションでした。
Terraformと比べたとき、CloudFormationはマネージドサービスとして使える部分が多くGUIでできる範囲が広いためが、逆にCLIのコマンド体系が洗練されているとは言い難いです。そこらへんは「CLIで実行しよう」のなかで、余さずお伝えできたかと思ってます。
また、「運用上の辛みを理解する」では、あまりマニュアルにのってないような、自分なりにどっぷりCloudFormationにハマっているときに気づいた内容を一通り書いてみました。ここらへんも貴重な情報だと思うので、是非みなさんに現場に活かしてもらえれば。クロススタック参照の罠とかね。これね。運用しないとわからないですよｗでもまぁ良い経験でした。
時間の関係で最後の章のパイプラインの部分がまき気味なってしまったのは反省点です。このあたりも物凄く面白いトピック満載なので、是非ここを深堀りした登壇もしてみたいと思ってます。
自分としては、CloudFormationであれTerraformであれCDKであれ、インフラをコードで管理することが好きだしそれこそ無限の可能性があると思ってます。自分のセッションがきっかけになって、皆さんに「IaCやってみよ」思ってもらえれば、自分の登壇には価値があったかと思ってます。
最後に、再演含めて実際に会場にお越しいただき聞いていただいた方に改めてお礼申し上げます。あの広い会場が完全に満席になっていて皆さんの熱気を感じて、自分としては非常にやりがいを感じましたし楽しい時間でした。ありがとうございました。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
12
