CloudFormationの全てを味わいつくせ！「AWSの全てをコードで管理する方法〜その理想と現実〜」 #cmdevio

「俺は、なんだかんだCloudFormationが大好きだ！」

うららかな小春日和の11月、下記イベントで登壇してきました。

【11/1（金）東京】国内最大規模の技術フェス！Developers.IO 2019 東京開催！AWS、機械学習、サーバーレス、SaaSからマネジメントまで60を越えるセッション数！ ｜ Developers.IO

このブログでは、「AWSの全てをコードで管理する方法〜その理想と現実〜」というタイトルで思う存分喋ったその様子を丸ごと喋り含めてお届けいたします。主にCloudFormationについて紹介したのですが、機能を網羅的に紹介するというよりは全体的に主観強めに喋っているので、そこらへん味わい深く読んでいただければ楽しめますYO

（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     CloudFormationﾏﾂﾘﾀﾞﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

セッション概要「AWSの全てをコードで管理する方法」

セッション概要

AWSの最大の特徴の一つ、「コードによるインフラの運用管理」
アプリケーションやインフラ運用のさらなる効率化を目指す時、IaC（Infrastructure as Code）の導入は必須と言えます。その効果は絶大ですが、下手に導入してしまうと逆に運用管理自体の硬直化を招き「最初は楽しかったのに、今はなんでこんな辛いんだろう…」という気持ちになってしまいます。

このセッションでは、CloudFormationやTerraform、CDKなどのIaCの手段について触れつつ、各運用現場に即したIaCを導入するために考えるべきことについて、お話します。

セッション聴講対象者

対象者は大きは2つ

  • 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リソースが作成されます。

テンプレートのサンプルはこんな感じ。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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の基礎を理解できたかと思います。

「２．CLIで実行する」

ある程度CloudFormationに慣れて、本格的に実行していくとき必ず最初に慣れたほうが良いことがあります。CLIでCloudFormationを実行することです。

CloudFormationを使うことのメリットのところでも述べましたが、テンプレートにインフラの状態を落とし込み、そのテンプレートに沿って同じものが作成されるように整備したとしても、最初の実行方法がWebコンソールのままだと、作業の再現性が担保できません。じゃ、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の場合、一体どんな感じで実行できるか、シェルの例を記載します。

1
2
3
4
5
6
7
8
9
10
#!/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の実行できるのでオススメです。

depooyコマンドには大きすぎる罠がある

ここで、一つdeployコマンドの怖いところお話しますね。これ、自分が実際に事故ったときの話です。こんな感じでCodeCommitのリポジトリ２つ作りました。

で、別のアプリ用のCodeCommit欲しいなとおもって、もう一つテンプレート作って実行しました。

はい。みなさん、ここで盛大に事故っていることに気づいたでしょうか？ポイントは1回目と2回目で同じスタックに更新をかけていることです。賢明な皆さん、何が起こったかわかりますでしょうか？こうやって見渡してみると、ニヤニヤされている方は恐らく気づいてそうですね。

はい。そうです。最初に作っていたCodeCommitが消えました。

これすごいですよ。本当になんの前触れもアラートもなく消えます。普通こういうリソースって、Webコンソールから消すときはdeleteとか入れさせたり何らかのアラートが標準で出るじゃないですか。deployコマンドのデフォルトの挙動は、まったくそういうアラートでないです。スーッと消えます。本番環境でやったらと思うと、背筋が凍りますね。

ここで知っておいてほしいことは、CloudFormation、扱い方を間違えると劇薬となりうるということです。

チェンジセットを知ろう

ということで、皆さんには、こういった事故を防止するために、チェンジセットというものを必ず知っておいてもらいたいです。実は、deployコマンド使うと、スタックが更新されるまえに、必ずチェンジセットというものが作成されてから、それがスタックに適用されます。こんな感じです。

先程の例だと、実はマネジメントコンソールとかみると、削除されようとしていたリソースもちゃんとチェンジセットには表示されていたんですね。これ見てれば、事故は防げました。

ただ、deployコマンドはデフォルトの挙動では、チェンジセット作成後、それをそのままスタックに適用するという動きをします。これを、チェンジセットだけを出力するため、--no-execute-changesetというオプションが用意されています。

これをうまく使いたいですね。先程のシェルを改造して、引数にdeployが渡されていたときだけ、スタックを更新するようにします。

1
$ 010-vpc.sh

引数にdeploy指定時のみスタックを更新

1
$ 010-vpc.sh deploy

実際のシェルの中味見てみましょう。引数判定して、deployが指定されているときだけ、CHANGESET-OPTIONを空文字列にしているだけです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/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で扱おうとすると、テンプレートやスタックの分割をどうするかを必ず考える必要があります。

テンプレートとスタックに分け方

じゃぁ、どのようにスタックを分けるかですが、一つ実例をだして考えてみましょう。まずは各リソースの依存関係を図示してみます。こうすると、どのリソースから作っていくが良さそうなイメージがわきやすいかと。

具体的なシェルとテンプレートの一覧はこちら。

1
2
3
4
5
6
7
8
9
10
11
12
$ 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とかですね。何個か種類があります。

  1. クロススタック参照を使う
    • CloudFormationマネージドな仕組み
    • 基本はこれ（ハマコー一番好きなやつ）
  2. ダイナミック参照を使う
    • テンプレートからパラメータストアやSecrets Managerを参照
  3. シェルで頑張る
    • テンプレートを呼び出す前にシェルでパラメータを頑張って作る
    • 汎用性は一番高い

方法①「クロススタック参照」

一番汎用性が高い方法だと思います。

最初に作るリソースのテンプレートのOutputにExportとしてパラメータ名を付与。

vpc.yml
1
2
3
4
5
Outputs:
  PublicSubnet1a:
    Value: !Ref PublicSubnet1a
    Export:
      Name: PublicSubnet1a

別のテンプレートではパラメータ名を指定して参照。

ec2.yml
1
2
3
Type: AWS::EC2::Instance
  Properties:
    SubnetId: !ImportValue PublicSubnet1a

こうやって便利に使えるクロススタック参照ですが、注意点が一つあります。パラメーターを参照しているリソースがあると元のスタックの参照元リソースの変更や削除ができません。

これは安全設計という点で非常に良いんですが、これがために運用が詰むパターンがあります。それがこちら。こんなふうに参照元を先に変更する必要があるリソースはクロススタック参照使えません。

方法②「ダイナミック参照」

テンプレートからAWS Systems Managerのパラメータストアや、AWS Secrets Managerを直接参照する方法です。

使い方としては、予めシェルやWebコンソール、もしくはCloudFormationでも良いので、パラメータストアやSecrets Managerに値を登録しておきます。

そうすると、テンプレートの中で以下の記法で、その値を参照できます。これも便利。

rds.yml
1
2
3
4
5
Resources:
  rds:
    Type: AWS::RDS::DBInstance
    Properties: 
      MasterUserPassword: {{resolve:ssm-secure:RDSMasterUserPassword:10}}

方法③「シェルで頑張る」

これは、まぁ頑張れって話なんですが、CloudFormationでリソースを作っても全てのプロパティがエクスポートできるわけではないです。そういった値を別のテンプレートで参照したい場合は、これはもう、シェルで頑張りましょう。

下の例だとIMAGE_URIをCLIで取得しています。おうおうにこういうパターンも出てくるので、シェルを使っているとこういう場合に融通が効いて良いですね。

task.yml
1
2
3
4
5
6
7
8
9
10
11
12
# タスク設定用パラメータ
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つ目は非常に重要なやつです。

  1. スタックの作成〜削除がいつまでたっても終わらない場合がある
  2. 対応していないプロパティがある
  3. 循環参照するには書き方に工夫が必要
  4. Conditionsに頼らない（使わない）
  5. 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
1
2
3
4
5
6
7
8
9
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

CI/CD Pipeline for AWS CloudFormation Templates on the AWS Cloud Using AWS TaskCat - CI/CD Pipeline for AWS CloudFormation Templates on AWS Using 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）でした。

PR満足度98%