【AWS】CloudFormationのベストプラクティスを読んで
最近、CloudFormationでサービス環境を構築しています。
VPCからEC2まで、コマンド一発で作成できるのは便利ですね。
ベストプラクティスを読んだことなかったので、読んでメモしておきたいと思います。
docs.aws.amazon.com
jsonでの管理が死ぬほどめんどくさいので、ラッパーであるkumogataを使用してrubyで管理しています。
github.com
kumogataについては別記事で書きたいと思います。
計画と編成
ライフサイクルと所有権によるスタックの整理
- スタックの規模が大きくなった場合は、共通のライフサイクルと所有権を持つリソースでグループ化
- 各層のスタックは類似したライフサイクルと所有権を持つ AWS リソースで分ける
- 例えばウェブサイトチームまたはデータベースチームで分ける
スタックの規模は大きいのでグループ化しています。インフラチームしか触らないので所有権は有無でしか管理していません。
IAM を使用したアクセス制御
- CloudFormationだけでなく各スタックのリソースに対するアクセス権限が必要
まぁ、当然ですね。
すべてのリソースタイプのクォータを確認する
しばらくは200あれば問題なさそうです。
テンプレートの作成
テンプレートに認証情報を埋め込まない
- 機密情報はテンプレートに埋め込まず、入力パラメータを使用してスタックの作成や更新のたびに渡す
- 埋め込む場合は、NoEcho プロパティを使用してパラメータ値を難読化する
パスワードなどは今はchef実行時に作成しているので出番はなさそう。そこらへんもCloudFormationで実施するようになったら意識する必要がありそう。
AWS 固有のパラメータタイプの使用
- 固有のパラメータが使える
パラメータの制約の使用
- 文字数制限とかができる
AWS::CloudFormation::Init を使用して Amazon EC2 インスタンスにソフトウェアアプリケーションをデプロイする
- cfn-init でデプロイする
デプロイするのにchefを使ってるので、chefを叩くのがいいのだろうか。
初回だけじゃなく、定期的なデプロイも必要なのでちょっと考える必要がありそう。
テンプレートを使用する前に検証する
- 依存関係の循環などの構文エラーや意味的エラーを検証するコマンドがある
スタックの管理
スタックポリシーを使用する
- スタックポリシーを使用することで、意図しない更新でリソースが中断されたり置き換えられるのを防ぐ
更新がどういう挙動をするのかわからないので何とも言えないけど、DataBaseとかは更新がかからないように保護しつつスタックを更新したほうが良いのだろうか。
最後に
共通テンプレートのネスト、cfn-initでどこまでやるか、スタックの更新
、テンプレートのリビジョン管理あたりをもう一度検討する必要がありそうなことがわかりました。
中身を理解し始めてきたら、ちゃんと世の中のベストを読んでみるのも良いですね。
気が向いたら、また書きます。
