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

AWS CDK Conference Japan 2026 presented by JAWS-UGにて登壇した20分セッション

Transcript

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