濱田孝治(174)30この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。全国のCloudFormationファンで、CloudFormation大好きな皆様!マニアックですね!re:Invent2017において、以下のセッションに参加したので、そのレポートをお届けします。CloudFormationせっション概要はこちら。deploymentsCloudFormatrionで構築したリソースをメンテナンスする上での永遠の課題。スタックとリソース内容の差分を検証する機能のリリース告知やデモがあったり、様々なユースケースにおけるCloudFormation活用のベストプラクティスが詰まった非常に濃いセッションでした。CloudFormationが好きな方は、是非御覧ください。́J以下、スピーカーのノリを折り込みながら、セッションレポートしていきいます。セッション内容このセッションでは、こんなことを喋るぜ。開発者向け:サーバーレスアーキテクチャへの適用このセッションから得られる学びスタックを保護しながら、リソースの変更を検知する方法リソースに対する、マルチリージョン、マルチアカウントでのプロビジョニング手法バリデーション機構によるデプロイの信頼性確保サーバーレスアプリケーションのデプロイ手法CloudFormationに対する話題がてんこ盛りだ。さぁ、みんなついてきておくれよ!!システム管理者向け:CloudFormation利用における安全性の確保ここに来ている物好き連中には当然のことかもしれないが、一応、CloudFormationについて、その概要をおさらいしておくぜ。YAMLやJSONで記述されたテンプレートファイルを、S3かローカルファイルシステムに格納。WebコンソールかAPIかCLIを利用してスタックを作成し、それを元に、リソースを作成していく。CloudFormationの利用状況はこんな感じだ。35万以上のアカウントがCloudFormationを利用しているAWS利用料トップ1万アカウントにおいて、75%以上がCloudFormationを利用している240万を超えるスタックが存在している4つの層に分けて、スタックとリソースを保護していく考え方が重要だ。先日リリースされた、スタックレベルの保護機能を利用すると、スタック削除を防ぐことができる。スタック自身でのポリシー適用スタックに対するポリシー適用の例。このポリシーでは、RDSリソースに対する更新を制御している。このようにスタックに対するポリシーの適用により、そのスタックが更新することのできるリソースを制限することができるので、スタック編集時の予期しない自己を未然に防ぐことができる。リソース自身でのポリシー適用この例では、リソースに対してポリシーを適用し、バックアップ/スナップショットの削除を保護している。ユーザー自身でのポリシー適用この例では、IAMに対してポリシーを制御し、そのユーザーがスタックを作成することができないようにポリシーを設定している。(最重要)CloudFormationにおいて必ず起こる課題とその解決策CloudFormationを長期にわたり利用していて必ず発生する課題。それが、スタックとリソースとの差分。インフラ修正を全てスタックに集約しておいたつもりでも、運用において、スタック以外の手操作でリソースを直接編集してしまうことはよくある。これは、非常によくない事態だ。この、スタックの内容と実際のリソースの状態が異なることを、drift状態にあるという。以下の理由で、こういう状態に陥ることはよくある。スタックリソースのプロパティを変更したスタックリソースの初期値を変更したスタックリソースを削除したdrift状態の定義は以下の通り。valuesの差分では、一体我々になにができるのか?CloudFormationの外で変更された内容と、CloudFormationにより定義されている内容の差分を可視化することだ。2018年にリリースされる!!全リージョンで利用できるようになる予定だ。DETECTIONのデモここでは、その機能をデモしていく。CLIを利用した、DRIFTの確認をデモで見ることができました。使い方は簡潔で簡単だという印象でした)Webコンソールももちろんあるぜ!このようにコンソール上で、現在のスタックにdrift状態かどうかが表示される。コンソール上で、現在のリソースとスタックの差分を表示することが可能だ。スタック外で削除されたリソースも確認できる。