CloudFormation のスタック、 どこで分けていますか？ コンサルティング1部 ソリューションアーキテクト 三⼭ 祐輝（みゃん） 

アジェンダ 1. ⾃⼰紹介 2. 今⽇お話しすること 3. スタックの分割を⽐べてみた 4. 実際に運⽤していて困ったこと ~ Network Firewall ~ 5. まとめ 2 

⾃⼰紹介 名前：三⼭ 祐輝（みゃん） ロール：ソリューションアーキテクト 所属：コンサルティング部 主な業務： ○ AWS 設計‧構築、セキュリティ⽀援 ○ Google Cloud 技術⽀援 ● ⼀⾔：7⽉に Join しました！ ● ● ● ● 

今⽇お話しすること 

スタックの分け⽅、悩んだことはありませんか？ ● 最初は1つのスタックで作り始めることが多いと思います ● 慣れてくると、「どこで分けよう？」と悩み始めます ● そもそも最近は⽣成AIに任せているから、作成されたテンプ レートをそのまま流していませんか？ ● 今⽇は正解をお伝えするのではなく、同じ構成でいくつかの 分け⽅を⽐べてみます ● これを機会に、AIに丸投げするのではなく、スタックの分割 について考えるきっかけになれば幸いです！ 

スタックの分割を⽐べてみた 

そもそもスタックとは？ ● スタックとはCloud Formationが管理するAWSリソースのか たまり ● スタックを作成、更新、削除することで、AWSリソースの作 成、更新、削除を実⾏ 

今回は EC2 で動く⼩さな Web システムを例にします 

具体的な変更例を元に、3通りの分け⽅を⽐べてみます 案 分け⽅ スタック例 A 1つのスタックにまとめる すべてのリソース B リソースの種類ごとに分ける network（VPC等） / security （SG等）/ alb / ec2 / rds C ⼀緒に変更するものをまとめる network（VPC等） / web （ALB‧EC2‧EC2 ⽤ SG）/ db（RDS‧RDS ⽤ SG） 

変更1 EC2 を置き換えると、案 B では⾯倒なことに AMI を更新 ec2 スタック alb スタック（案 B） EC2 が置き換わり、 インスタンス ID が変わる インスタンス ID を Export している ImportValue で その Export を使っている 使⽤中の Export は値を変更できないので、更新が失敗します Cannot update export EXPORT_NAME as it is in use by STACK_NAME 案 A‧C は同じスタック内の Ref で参照しているので、新しい ID にそのまま追従します 案 A：1つのスタックにまとめる 案 B：リソースの種類ごとに分ける 案 C：⼀緒に変更するものをまとめる 

変更2 SG を1か所に集めるとどうなるか 案 B の security スタック ALB ⽤ SG ← 誤った変更リスクあり EC2 ⽤ SG RDS ⽤ SG ← ルールを追加 ← 誤った変更リスクあり 良い点 SG を先に作れるので、ec2 と rds の作成順を 気にしなくてよい。スタック間の循環参照も起きない 気になる点 関係のない SG に編集ミスやタイポが及ぶおそれがある GroupDescription を直すと SG が作り直される （Export していれば変更1と同じエラー） 案 C なら web スタックの中だけで変更が済みます 案 A：1つのスタックにまとめる 案 B：リソースの種類ごとに分ける 案 C：⼀緒に変更するものをまとめる 

変更3 案 C では作る順番が決まりません（循環参照） RDS⽤SGのID web スタック（案 C） db スタック（案 C） ALB‧EC2‧EC2 ⽤ SG RDS‧RDS ⽤ SG EC2 ⽤ SG の ID web と db が、お互いの値を Import し合っています web を作るには db の Export が、db を作るには web の Export が必要です 案 B は SG を security スタックにまとめているので、循環しません 案 A：1つのスタックにまとめる 案 B：リソースの種類ごとに分ける 案 C：⼀緒に変更するものをまとめる 

どの案にもメリット‧デメリットがあります 案 メリット デメリット A 1スタック 1回で作れる 置き換えにも Ref で追従 どの変更でも、全リソース に影響出る恐れあり B 種類ごと 作成順を気にしなくてよい 循環参照も起きない Export した値が変わると 更新が失敗する （変更1‧2） C ⼀緒に変更 するもの 変更が1つのスタックで完結 置き換えにも Ref で追従 web と db が値を渡し合う と循環する恐れがある （変更3） 

実際に運⽤して困ったこと ~ Network Firewall ~ 

スタックで管理するリソース単位が広すぎる！！！ VPC 系のスタック VPC‧サブネット Network Firewall VPCエンドポイント ドメインを1つ⾜すたびに、 VPC を含むスタック全体を更新していました 

余談 分割とはずれますが、ドリフト多数で変更⼯数が。。。 VPC 系のスタック AWS::Include VPC‧サブネット Network Firewall ルールグループ S3 上のドメインリスト ファイル名を変えて更新 許可するドメイン コンソールから直接追加 ファイアウォールポリシー →ドリフトの発⽣ コンソールから追加されているドメインがあり、 テンプレートと実機の差分を確認する作業が⼤変でした 

変更のたびに、影響調査に時間がかかっていました 調べる範囲が広い ドメインを1つ⾜すだけでも、VPC を含むスタック全体の影響を調べていました 変更する経路が2つ ルールを変える経路が、CFn とコンソールの2つありました 上書きで通信が⽌まる テンプレートに無いドメインは、CFn で更新すると消えて、通信が⽌まります 

どうするべきだったのか、改めて考えてみました 案 内容 良い点 気になる点 1 変更単位でスタックを分 ける(VPC系とNetwork Firewallは分ける等) VPC 側への影響調査が 参照がスタックをまた 不要になる ぐ 2 CFn で更新する（⼿動変 更を許すな） テンプレートと実機の 差分がなくなる 急ぎの依頼でも CFn の ⼿順を踏む 3 ルールの中⾝は CFn で管 依頼にすぐ対応できる 理しない(割り切る！) CFn の更新で上書きさ れるリスクあり 

まとめ 

分け⽅に迷ったときに考えている4つのこと 1. 2. 3. 4. このリソースを変えるとき、⼀緒に変えるものは何か 運⽤で変更頻度が⾼そうなものは何か スタック間で値をどう受け渡すか 構築作業をより簡略化できないか 

正解は環境ごとに違うと思っています ● 今⽇の⽐較は、あくまで仮のシナリオでの⼀例です ● 是⾮ご⾃⾝の環境に当てはめるとどうか考えてみてくださ い！ 

No content