【DevelopersIO Tokyo 2026 】「CloudFormation のスタック、 どこで分けていますか？」

Transcript

1. CloudFormation のスタック、 どこで分けていますか？ コンサルティング1部 ソリューションアーキテクト 三⼭ 祐輝（みゃん）
2. アジェンダ 1. ⾃⼰紹介 2. 今⽇お話しすること 3. スタックの分割を⽐べてみた 4. 実際に運⽤していて困ったこと ~ Network Firewall ~ 5. まとめ 2
3. ⾃⼰紹介 名前：三⼭ 祐輝（みゃん） ロール：ソリューションアーキテクト 所属：コンサルティング部 主な業務： ◦ AWS 設計‧構築、セキュリティ⽀援 ◦ Google Cloud 技術⽀援 • ⼀⾔：7⽉に Join しました！ • • • •
4. 今⽇お話しすること
5. スタックの分け⽅、悩んだことはありませんか？ • 最初は1つのスタックで作り始めることが多いと思います • 慣れてくると、「どこで分けよう？」と悩み始めます • そもそも最近は⽣成AIに任せているから、作成されたテンプ レートをそのまま流していませんか？ • 今⽇は正解をお伝えするのではなく、同じ構成でいくつかの 分け⽅を⽐べてみます • これを機会に、AIに丸投げするのではなく、スタックの分割 について考えるきっかけになれば幸いです！
6. スタックの分割を⽐べてみた
7. そもそもスタックとは？ • スタックとはCloud Formationが管理するAWSリソースのか たまり • スタックを作成、更新、削除することで、AWSリソースの作 成、更新、削除を実⾏
8. 今回は EC2 で動く⼩さな Web システムを例にします
9. 具体的な変更例を元に、3通りの分け⽅を⽐べてみます 案 分け⽅ スタック例 A 1つのスタックにまとめる すべてのリソース B リソースの種類ごとに分ける network（VPC等） / security （SG等）/ alb / ec2 / rds C ⼀緒に変更するものをまとめる network（VPC等） / web （ALB‧EC2‧EC2 ⽤ SG）/ db（RDS‧RDS ⽤ SG）
10. 変更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：⼀緒に変更するものをまとめる
11. 変更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：⼀緒に変更するものをまとめる
12. 変更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：⼀緒に変更するものをまとめる
13. どの案にもメリット‧デメリットがあります 案 メリット デメリット A 1スタック 1回で作れる 置き換えにも Ref で追従 どの変更でも、全リソース に影響出る恐れあり B 種類ごと 作成順を気にしなくてよい 循環参照も起きない Export した値が変わると 更新が失敗する （変更1‧2） C ⼀緒に変更 するもの 変更が1つのスタックで完結 置き換えにも Ref で追従 web と db が値を渡し合う と循環する恐れがある （変更3）
14. 実際に運⽤して困ったこと ~ Network Firewall ~
15. スタックで管理するリソース単位が広すぎる！！！ VPC 系のスタック VPC‧サブネット Network Firewall VPCエンドポイント ドメインを1つ⾜すたびに、 VPC を含むスタック全体を更新していました
16. 余談 分割とはずれますが、ドリフト多数で変更⼯数が。。。 VPC 系のスタック AWS::Include VPC‧サブネット Network Firewall ルールグループ S3 上のドメインリスト ファイル名を変えて更新 許可するドメイン コンソールから直接追加 ファイアウォールポリシー →ドリフトの発⽣ コンソールから追加されているドメインがあり、 テンプレートと実機の差分を確認する作業が⼤変でした
17. 変更のたびに、影響調査に時間がかかっていました 調べる範囲が広い ドメインを1つ⾜すだけでも、VPC を含むスタック全体の影響を調べていました 変更する経路が2つ ルールを変える経路が、CFn とコンソールの2つありました 上書きで通信が⽌まる テンプレートに無いドメインは、CFn で更新すると消えて、通信が⽌まります
18. どうするべきだったのか、改めて考えてみました 案 内容 良い点 気になる点 1 変更単位でスタックを分 ける(VPC系とNetwork Firewallは分ける等) VPC 側への影響調査が 参照がスタックをまた 不要になる ぐ 2 CFn で更新する（⼿動変 更を許すな） テンプレートと実機の 差分がなくなる 急ぎの依頼でも CFn の ⼿順を踏む 3 ルールの中⾝は CFn で管 依頼にすぐ対応できる 理しない(割り切る！) CFn の更新で上書きさ れるリスクあり
19. まとめ
20. 分け⽅に迷ったときに考えている4つのこと 1. 2. 3. 4. このリソースを変えるとき、⼀緒に変えるものは何か 運⽤で変更頻度が⾼そうなものは何か スタック間で値をどう受け渡すか 構築作業をより簡略化できないか
21. 正解は環境ごとに違うと思っています • 今⽇の⽐較は、あくまで仮のシナリオでの⼀例です • 是⾮ご⾃⾝の環境に当てはめるとどうか考えてみてくださ い！