CDKで管理するもの、しないもの 〜マルチアカウント環境のIaC設計判断〜

AWS CDK Conference Japan 2026 presented by JAWS-UGにて登壇した20分セッション
設定ミスで上げ直し

Transcript

1. CONFIDENTIAL CDKで管理するもの、しないもの 〜マルチアカウント環境のIaC設計判断〜 AWS CDK Conference Japan 2026 presented by JAWS-UG 2026.07.18 名前 森優斗 @kotukotuganbad ©Fusic Co., Ltd. 0
2. はじめに 自己紹介 株式会社Fusic @福岡 データソリューション 部門 エンジニア 森 優斗 Mori Yuto @kotukotuganbad ❖ I am - 消防10年 Fusic 3年 ❖ Skills - AWS (Web) / SORACOM / アプリケーション開発 ❖ Comment - 懇親会でいっぱい話したいです ©Fusic Co., Ltd. 1
3. はじめに CDKは非常に強力な素晴らしいツールです でも「全部CDKで管理する」が最適解とは限らない マルチアカウント環境では、CDKのデプロイモデルと噛み合わない領域があると考える というお話をしたいと思います ©Fusic Co., Ltd. 2
4. 目次 CONTENTS 1. AWSにおけるIaCサービスの全体像とCDKの強み 2. 実際のマルチアカウント環境のIaC設計判断のご紹介 3. 実際に運用してみての所感 4. まとめ ©Fusic Co., Ltd. 3
5. 1 AWSにおけるIaCサービスの全体像とCDKの強み ©Fusic Co., Ltd. 4
6. AWSにおけるIaCサービスの全体像を理解する 2026 AWS Summit / AWS Infrastructure as Code : 2025 年主要アップデートの振り返り by 菊池晏南様 より https://pages.awscloud.com/rs/112-TZM-766/images/R05_0625_DVT225_v2.pdf ©Fusic Co., Ltd. 5
7. 1. AWSにおけるIaCサービスの全体像とCDKの強み レイヤーが上がるほど抽象度が上がる、でもトレードオフがある レイヤー 代表サービス 抽象度 自由度 付随する学習コスト サービス層 Amplify / Service Catalog 高い 低い サービス固有の概念 抽象化層 CDK / SAM 中程度 高い プログラミング言語 基盤層 CloudFormation 低い 最大 YAML/JSON + 全リソース仕様 上に行くほど「早く作れる」けれど「枠から外れにくい」 下に行くほど「自由に書ける」けれど「記述量が増える」 本セッションの主題：CDK（抽象化層）と CloudFormation（基盤層）の使い分け ©Fusic Co., Ltd. 6
8. 1. AWSにおけるIaCサービスの全体像とCDKの強み CDKの強みは「言語で扱える」こと CDKの強み 具体的な恩恵 型安全 parameter.ts で環境パラメータを型で守る。不足や誤値は tsc / IDE が即エラー 抽象化 L2 の Grantsクラスで IAM ポリシーを自動生成。生成AIの膨大な出力にもレビュー対応しやすい テスト可能 vitestによる、Stack、Constructレベルでの自由なテスト。スナップショットでの簡易テスト。 コード再利用 Construct を分離し、props で依存関係を明示的に渡せる リソース数が多い・変更が頻繁・開発者が日常的に触る → CDKの強みが活きる ©Fusic Co., Ltd. 7
9. 1. AWSにおけるIaCサービスの全体像とCDKの強み CDKのビルドプロセスが前提にするもの CDKの強みは「言語で扱えること」 ©Fusic Co., Ltd. 8
10. 1. AWSにおけるIaCサービスの全体像とCDKの強み CDKのビルドプロセスが前提にするもの CDKの強みは「言語で扱えること」 ビルドプロセスが必要 ©Fusic Co., Ltd. 9
11. 1. AWSにおけるIaCサービスの全体像とCDKの強み CDKの本質は「CFnテンプレート生成ツール」 tsc トランスパイル TypeScript コード cdk deploy cdk synth JavaScript CloudFormation テンプ レート（JSON/YAML） AWS リソース ・cdk synth の出力は、素の CloudFormation テンプレートと同じ ・cdk deploy は aws cloudformation deploy と同等 CDKで管理する ＝ このビルドプロセス全体を前提にするということ ©Fusic Co., Ltd. 10
12. 1. AWSにおけるIaCサービスの全体像とCDKの強み CDKのビルドプロセスが前提にするもの CDKでデプロイするには、以下の環境・プロセスが必要 Node.js ランタイム npm install（依存パッケージ） CDK CLI（cdk deploy） TypeScript コンパイラ（tsc） cdk.json の設定 cdk bootstrap 済みアカウント 「アプリケーション開発」の文脈では当たり前だが、 でも「インフラ管理者がテンプレートを1つ展開したい」だけの場合、意外と準備が大変なのでは？？ すべてのIaCコンポーネントに、このプロセスが必要なのか？ ©Fusic Co., Ltd. 11
13. 2 実際のマルチアカウント環境のIaC設計判断 ©Fusic Co., Ltd. 12
14. 2. マルチアカウント環境のIaC設計判断 事例の全体像 ― 某国立大学のアカウント管理基盤 主な機能 アカウントダッシュボード root 情報管理者 Infrastructure OU/ アプリアカウント Security OU ・コスト可視化・閾値アラート通知 ・アカウント全リソース削除（aws-nuke） 利用者専用 OU コスト超過したアカウントのリソースをクリーンナップを実行 ・Landing Zoneによるマルチアカウント基盤 職員アカウント1 ・Organization SCP による利用制限 職員アカウント2 職員アカウント3 割り当てられたAWSアカウントを用いて研究 ・StackSets による共通ロール展開(Nuke利用) 職員アカウント4 ©Fusic Co., Ltd. 13
15. 2. マルチアカウント環境のIaC設計判断 補足：aws-nuke とは https://github.com/ekristen/aws-nuke 何をするもの？ アカウント内のほぼ全リソースを削除する OSS ツール（aws-nuke v3） どう動く？ 対象アカウントのロールを Assume し、リソースを列挙して削除。dry-run で事前確認できる ©Fusic Co., Ltd. 14
16. 某大学管理者 Fusic 某大学職員 ダッシュボードの確認、手動クリーンナップの実行 アカウントの使用 アカウント管理 AWS Cloud Organization アプリアカウント 職員アカウント ペイヤーアカウント SNS S3 CloudWatch Cloudtrail Route53 CDK (クリーンナップの結果通知) nuke用ロール AWS Orga nizati on ACM Cloudfront WAF StackSetsスタックインスタンス(nuke対象外) Amplify root Cognito アプリアカウント S3 accounts-table ほとんどのサービスをクリーンナップ 職員アカウント 職員アカウント API Gateway CodeBuild account-cleanup Stack Sets Budgets CostExplorer 1. 2. 3. 4. 5. 6. 7. 8. nukeの実行環境構築(バージョン差分検知) 職員アカウントのnuke用のロールをassume 実行モードに合わせて該当するconfigファイルをS3からコピー ストレージ類の削除保護を解除、Stackの削除保護の解除などの事前処理 nukeの実行に必要なアカウントエイリアスの設定 Nukeの実行 実行結果によって送信メールを調整 SNSによって、クリーンナップ結果をFusic及び、某大学管理者へ通知 AWS Nukeの実行 ストレージ類を残すをクリーンナップ 職員アカウント DynamoDB nuke用ロール StackSetsスタックインスタンス(nuke対象外) accounts-tableの取得 各職員用アカウント使用率 50%, 80%, 90%,95%時に、それぞれのメールアドレスにアラートメールを送信 account-cleanupからはクリーンナップの実行通知メール コスト情報の取得 scheduled-cost-monitor SES EventBridge(6時間定期実行) ©Fusic Co., Ltd. 15
17. 2. マルチアカウント環境のIaC設計判断 マルチアカウント環境の全てをGitで管理したい アカウントダッシュボード root 情報管理者 Infrastructure OU/ アプリアカウント バラバラな管理は避けたい、、、 Security OU 利用者専用 OU コスト超過したアカウントのリソースをクリーンナップを実行 職員アカウント1 職員アカウント2 職員アカウント3 割り当てられたAWSアカウントを用いて研究 職員アカウント4 ©Fusic Co., Ltd. 16
18. 2. マルチアカウント環境のIaC設計判断 マルチアカウント環境の全てをGitで管理したい アカウントダッシュボード root 情報管理者 Infrastructure OU/ アプリアカウント Security OU 利用者専用 OU コスト超過したアカウントのリソースをクリーンナップを実行 アプリケーションも、OU設定も、StackSetsの内容も SSOTの文脈で全てをGit管理で完結させよう 職員アカウント1 職員アカウント2 職員アカウント3 割り当てられたAWSアカウントを用いて研究 職員アカウント4 これでいけそう ©Fusic Co., Ltd. 17
19. 2. マルチアカウント環境のIaC設計判断 マルチアカウント環境の全てをGitで管理したい Kiroを用いた Spec駆動開発でSSOTを目指した内容については、以下の記事にまとめています ©Fusic Co., Ltd. 18
20. 2. マルチアカウント環境のIaC設計判断 SSOT を出発点を目標にIaCツールを選定した レイヤー 代表サービス 抽象度 自由度 学習コスト サービス層 Amplify / Service Catalog 高い 低い サービス固有の概念 抽象化層 CDK / SAM 中程度 高い プログラミング言語 基盤層 CloudFormation 低い 最大 YAML/JSON + 全リソース仕様 上に行くほど「早く作れる」けれど「枠から外れにくい」 下に行くほど「自由に書ける」けれど「記述量が増える」 保存場所は 1 つに保ち、道具はコンポーネントごとに最適な層を選ぶ ©Fusic Co., Ltd. 19
21. 2. マルチアカウント環境のIaC設計判断 Organization 全体を SSOT で管理したい 完成系はこのようになりました ©Fusic Co., Ltd. 20
22. 3. マルチアカウント環境のIaC設計判断 Organization 全体を SSOT で管理したい repository/ ├── basic-infra/ … │ ├── lib/constructs/ … │ ├── functions/ … ├── nuke-stack/ … │ └── nuke-cfn-stack.yaml … ├── stack-sets/ … │ └── stack-sets-template.yaml … ├── service-control-policy … | ├── deny-hoge.json … | ├── deny-huga.json └── frontend/ … CDKディレクトリ 1Stack構成 Lambdaの載せるバックエンドロジック（TypeScript） aws-nukeディレクトリ CloudFormation YAML（Step Functions + CodeBuild） StackSetsディレクトリ CloudFormation YAML SCPディレクトリ JSON（リージョン制限 / サービス禁止 / ロール保護） フロントエンドディレクトリ (Next.js → Amplify Hosting) 最終的に、全てをCDKで管理せず、一部はCfnで管理することを選択しました ©Fusic Co., Ltd. 21
23. 2. マルチアカウント環境のIaC設計判断 CDKで管理しているもの／していないもの コンポーネント 管理方式 理由（一言） アプリバックエンド（infra/） CDK 型安全・抽象化・テストの恩恵が大きい フロントエンド（frontend/） Amplify Hosting デプロイのみに利用（Backend は不使用） nuke実行基盤（nuke-stack/） CloudFormation 横展開ポータビリティ 共通ロール（stack-sets/） CloudFormation シンプルすぎてラップ不要 SCP（organization-scp-policy/） JSON 抽象化で隠すより、直接読めることが重要 CDK は「アプリ基盤、バックエンド」に集中させ、それ以外は最小の道具で管理 ©Fusic Co., Ltd. 22
24. 3. マルチアカウント環境のIaC設計判断 Organization 全体を SSOT で管理したい それぞれの設計判断 ©Fusic Co., Ltd. 23
25. 2. マルチアカウント環境のIaC設計判断 Amplify Backendを使わないという設計判断 Amplify Backend はスキーマ駆動で立ち上がりが速い。だが今回、バックエンドには採用しなかった。 学習コスト CDKと比較すると少し不自由 sandbox / backend definition / auth rules など Amplify固有の抽象化は、CDK・CFnとは別軸の学習 が必要 Cognito の MFA 設定、SES 送信元ドメイン、OU横 断のIAMロール設計など、要件を素直に満たせなかっ た 脱出コスト IaC全体像の把握 内部で作られるリソース（AppSync、Lambda Layer 等）がブラックボックス化し、後から CDK / CFn に 移行しにくい CDK / CFn / SCP を横断管理する環境に混ぜると、 IaCの全体像が見えにくくなる 今回の選択：Amplify は Hosting のみに利用。バックエンドは CDK で管理し、IaC の全体像を握る ©Fusic Co., Ltd. 24
26. 2. マルチアカウント環境のIaC設計判断 CDK の CfnStackSet（L1）を使わないと言う設計判断 CDK CfnStackSet CFnテンプレート直接管理（今回の選択） デプロイ方法 cdk deploy でアプリと一緒 コンソール / CLI で個別実行 ライフサイクル CDKに一定巻き込まれる 完全分離 テンプレート管理 TS内にインライン or S3参照 YAML をそのまま Git 管理 監査 synth 結果を追う必要あり YAML を直接読める ©Fusic Co., Ltd. 25
27. 2. マルチアカウント環境のIaC設計判断 CDK の CfnStackSet（L1）を使わないと言う設計判断 やりたいこと：利用者OU（数十アカウント）に共通のIAMロールを1つ配るだけ # stack-sets/stack-sets-template.yaml（全量：28行） Resources: CleanupTargetRole: Type: AWS::IAM::Role Properties: RoleName: cleanup-target-role ManagedPolicyArns: - arn:aws:iam::aws:policy/AdministratorAccess AssumeRolePolicyDocument: Statement: - Effect: Allow Principal: AWS: !Sub "arn:aws:iam::${AppAccountId}:role/nuke-codebuild-role" Action: "sts:AssumeRole" 初回設定以降触らないYAML 28行で完結 ― これを CDK でラップする価値があるか？ ©Fusic Co., Ltd. 26
28. 2. マルチアカウント環境のIaC設計判断 SCPをCfnPolicy(L1)で管理しなかった理由 Organization 全体に効く強力なポリシー → 抽象化で隠すより、JSON を直接読めることが重要 OU への attach は初回以降ほぼ変更なし。Git の差分管理とCLIによる適用作業で十分 影響力が非常に強いSCPの特性上、CDKの抽象化は相性が悪いと判断 ©Fusic Co., Ltd. 27
29. 2. マルチアカウント環境のIaC設計判断 nuke実行基盤を独立したCFn管理にした理由 account-cleanup アプリケーション側の仕様が絡む部分はCDK管理 大学Aの仕様によって随時デプロイが走る CodeBuild S3 Nuke基盤に期待するのは「実行したら全てのリソースが消える」こと これは不変 呼び出し側と、Nukeの実行基盤が完全に疎結合かつ、、、 ©Fusic Co., Ltd. 28
30. 2. マルチアカウント環境のIaC設計判断 nuke実行基盤を独立したCFn管理にした理由 account-cleanup アプリケーション側の仕様が絡む部分はCDK管理 大学Aの仕様によって随時デプロイが走る CodeBuild S3 Nuke基盤に期待するのは「実行したら全のリソースが消える」こと これは不変 account-cleanup アプリケーション側の仕様が絡む部分はCDK管理 B組織の仕様によって随時デプロイが走る 複数のランディングゾーンを管理していて、実行基盤自体は同一である ©Fusic Co., Ltd. 29
31. 3. マルチアカウント環境のIaC設計判断 Organization 全体を SSOT で管理したい Nuke実行基盤専用リポジトリ repository/ ├── nuke-stack/ └── nuke-cfn-stack.yaml 大学Aのリポジトリ … CloudFormation YAML … aws-nuke実行基盤（Step Functions + CodeBuild） サブモジュールとして共有 repository/ ├── basic-infra/ … CDKディレクトリ │ ├── lib/constructs/ … 1Stack構成 │ ├── functions/ … Lambdaの載せるバックエンドロジック（TypeScript） ├── nuke-stack/ … aws-nukeディレクトリ │ └── nuke-cfn-stack.yaml … CloudFormation YAML（Step Functions + CodeBuild） ├── stack-sets/ … StackSetsディレクトリ │ └── stack-sets-template.yaml … CloudFormation YAML ├── service-control-policy … SCPディレクトリ | ├── deny-hoge.json … JSON（リージョン制限 / サービス禁止 / ロール保護） | ├── deny-huga.json └── frontend/ … フロントエンドディレクトリ (Next.js → Amplify Hosting)] 大学Bのリポジトリ repository/ ├── basic-infra/ … CDKディレクトリ │ ├── lib/constructs/ … 1Stack構成 │ ├── functions/ … Lambdaの載せるバックエンドロジック（TypeScript） ├── nuke-stack/ … aws-nukeディレクトリ │ └── nuke-cfn-stack.yaml … CloudFormation YAML（Step Functions + CodeBuild） ├── stack-sets/ … StackSetsディレクトリ │ └── stack-sets-template.yaml … CloudFormation YAML ├── service-control-policy … SCPディレクトリ | ├── deny-hoge.json … JSON（リージョン制限 / サービス禁止 / ロール保護） | ├── deny-huga.json └── frontend/ … フロントエンドディレクトリ (Next.js → Amplify Hosting)] 素の CFnテンプレート だからこそシンプルに横展開しやすい ©Fusic Co., Ltd. 30
32. 2. マルチアカウント環境のIaC設計判断 CDKで管理しているもの／していないもの コンポーネント 管理方式 理由（一言） アプリバックエンド（infra/） CDK 型安全・抽象化・テストの恩恵が大きい フロントエンド（frontend/） Amplify Hosting デプロイのみに利用（Backend は不使用） nuke実行基盤（nuke-stack/） CloudFormation 横展開ポータビリティ 共通ロール（stack-sets/） CloudFormation シンプルすぎてラップ不要 SCP（organization-scp-policy/） JSON 抽象化で隠すより、直接読めることが重要 CDK は「アプリバックエンド」に集中させ、それ以外は最小の道具で管理 ©Fusic Co., Ltd. 31
33. 3 実際に運用してみての所感 ©Fusic Co., Ltd. 32
34. 3. 実際に運用してみての所感 CDKで管理する範囲を絞ったことで得られたもの CDK が1Stack構成の維持 ベストプラクティスに準拠。CDKでの複数Stack運用のつらみが少ない cdk deploy の責務が明確 「アプリバックエンドのデプロイ」以外の心配がない CFnテンプレートは可搬性が高い nuke-stack は独立リポジトリ化し、git submodule として 3 箇所のリポジトリから参照 ©Fusic Co., Ltd. 33
35. 3. 実際に運用してみての所感 逆に、分けたことで感じたデメリット デプロイ手順が分散 CDK は cdk deploy、nuke-stack は aws cloudformation deploy、StackSets / SCP はコンソール → 手順書の管理が必要 新メンバーの学習コスト 「なぜここは CDK じゃないの？」への説明コストがある ©Fusic Co., Ltd. 34
36. 4 まとめ ©Fusic Co., Ltd. 35
37. まとめ Point 01 CDKで管理しない選択肢を持つと、CDK部分の責務がシンプルになる Point 02 判断軸は「デプロイ頻度 × 変更の主体 × 横展開の必要性」 Point 03 ツールは分けても、管理は1箇所とする ©Fusic Co., Ltd. 36
38. Thank You ご清聴いただきありがとうございました We are Hiring! https://recruit.fusic.co.jp/ ©Fusic Co., Ltd. 37