AWS IaCツールの使い分けベストプラクティス

CDK / CloudFormation / SAM / Serverless Framework

目次

  1. 結論（早見表）
  2. 各ツールの特徴
  3. 比較表
  4. 選定フローチャート
  5. 組み合わせパターン（実務でよくある構成）
  6. 共通のベストプラクティス
  7. 避けたいアンチパターン
  8. まとめ

1. 結論（早見表）

こんなとき推奨
アプリ＋インフラを一体で、長期運用・大規模・マルチアカウントで管理したいAWS CDK
宣言的なテンプレートを厳密に管理したい／組織標準・StackSets・Service Catalogで配布したいCloudFormation
Lambda中心の小〜中規模サーバーレスを、AWS公式・YAMLでシンプルに作りたいAWS SAM
既存のServerless Framework資産がある／プラグイン資産を活かしたいServerless Framework
新規で迷ったらCDK（サーバーレス特化かつ小規模ならSAM）

前提：4つとも最終的には CloudFormation スタックとしてデプロイされる。つまり「CloudFormationの上にどの抽象化レイヤーを載せるか」の選択である。

           ┌──────────┐ ┌──────────┐ ┌──────────────────────┐
           │   CDK    │ │   SAM    │ │ Serverless Framework │
           │(TS/Py等) │ │ (YAML)   │ │       (YAML)         │
           └────┬─────┘ └────┬─────┘ └──────────┬───────────┘
                │ synth      │ transform        │ package
                ▼            ▼                  ▼
           ┌─────────────────────────────────────────────┐
           │           CloudFormation テンプレート         │
           └─────────────────────────────────────────────┘

2. 各ツールの特徴

2.1 AWS CloudFormation

  • 位置づけ：AWS IaCの基盤。JSON/YAMLの宣言的テンプレート。
  • 強み
    • 追加ツール不要、AWSサポート対象として最も安定
    • 生成物＝実体なので差分・レビューが明確
    • StackSets（マルチアカウント/リージョン配布）、Service Catalog、Control Tower等の組織機能と直結
    • Change Sets、ドリフト検出、スタックリファクタリングなどの運用機能
  • 弱み
    • 記述量が多く冗長。ループや条件分岐が貧弱（Fn::ForEach 等はあるが限定的）
    • ロジックの再利用はモジュール／ネストスタック頼み
  • 向いている用途
    • ランディングゾーン、ガードレール、ネットワーク基盤など「変更頻度が低く厳密さが重要」なもの
    • 他チームへ配布するテンプレート、Marketplace／パートナー向け提供物
    • CDKやSAMの出力を理解・デバッグするための前提知識

2.2 AWS CDK

  • 位置づけ：TypeScript / Python / Java / C# / Go でインフラを記述し、CloudFormationを合成（synth）する。
  • 強み
    • L2/L3 Constructによる高い抽象度（IAM権限付与 grant*() 等で記述量が激減）
    • 型補完・ユニットテスト（assertions）・IDE支援
    • 共通Constructをライブラリ化して組織横断で再利用可能
    • Mixins（.with()）でL1/L2/独自Constructに暗号化・パブリックアクセスブロック等のポリシーを後付けできる
    • CDK Pipelines、cdk diff、cdk refactor、テンプレート検証など開発体験が継続的に強化されている
  • 弱み
    • 生成されるテンプレートがブラックボックス化しやすい
    • 学習コスト（プログラミング言語＋Construct＋CFnの理解）
    • ライブラリ更新の追従（feature flags、alphaモジュールの破壊的変更）
    • 論理IDの変化によるリソース置換事故に注意が必要
  • 向いている用途
    • アプリとインフラを同じリポジトリ・同じ言語で管理したいプロダクト開発
    • コンテナ（ECS/EKS）、データ基盤、ネットワーク、サーバーレスを横断する中〜大規模構成
    • プラットフォームチームが「社内標準Construct」を提供するモデル

2.3 AWS SAM

  • 位置づけ：CloudFormationのサーバーレス向け拡張（Transform）＋ SAM CLI。
  • 強み
    • AWS::Serverless::Function 等で Lambda / API Gateway / DynamoDB / Step Functions を簡潔に書ける
    • sam local invoke / sam local start-api によるローカル実行・デバッグ
    • sam sync（Accelerate）による高速な反復開発
    • AWS公式・無償、CloudFormationとほぼ同じ感覚で扱える（素のCFnリソースも混在可）
  • 弱み
    • サーバーレス以外（VPC、ECS等）は素のCFn記述に戻るため冗長
    • YAMLゆえ抽象化・再利用性はCDKに劣る
  • 向いている用途
    • Lambda中心のAPI、イベント駆動処理、バッチ
    • CFnに慣れたチームが手軽にサーバーレスを始めたいとき
    • ※CDKで書いたスタックもSAM CLIでローカルテスト可能（cdk synth → sam local invoke -t）なので併用も現実的

2.4 Serverless Framework

  • 位置づけ：Serverless Inc. が提供するサードパーティのサーバーレス向けフレームワーク（serverless.yml）。
  • 強み
    • 簡潔なYAMLでLambda＋イベントソースを定義できる
    • 豊富なプラグインエコシステム、ステージ・パラメータ管理
    • 歴史が長く、ナレッジや既存資産が多い
  • 弱み・注意点（重要）
    • v4からライセンスが変更：v4ではCLI利用に認証（ダッシュボードログインまたはLicense Key）が必須。個人・小規模事業者は無料だが、売上が閾値以上の組織はクレジット制の有償サブスクリプションが必要
    • v3以前はオープンソース（MIT）のまま利用可能だが、新機能・サポートの面で将来性に注意
    • AWS以外のプロバイダはv4で非推奨（マルチクラウドの利点は薄れている）
    • CI/CDにライセンスキー管理が必要になるなど、運用要件が増える
  • 向いている用途
    • 既にServerless Frameworkで構築されたシステムの継続運用
    • 特定プラグインに強く依存している場合
    • 新規採用は、ライセンス条件（自社の売上規模）と費用を確認した上で判断する

3. 比較表

観点CloudFormationCDKSAMServerless Framework
記述形式YAML/JSON汎用プログラミング言語YAML（CFn拡張）YAML
提供元AWSAWS（OSS）AWS（OSS）Serverless Inc.
費用無料無料無料v4は規模により有償
対象範囲AWS全般AWS全般サーバーレス中心サーバーレス中心
抽象度低高中中
再利用性モジュール/ネストConstruct（非常に高い）ネスト/Serverless Application Repositoryプラグイン
ローカル実行なしSAM CLI併用◎（sam local）serverless invoke local・プラグイン
テストcfn-lint, cfn-guardユニットテスト＋snapshotcfn-lintプラグイン依存
学習コスト中高低〜中低〜中
ロックインAWSAWSAWSAWS＋ベンダー（ライセンス）

4. 選定フローチャート

既存資産がある？
├─ Serverless Framework資産 → ライセンス条件を確認
│     ├─ 問題なし → 継続利用（v4へ移行）
│     └─ 問題あり → v3維持（期限付き）または SAM / CDK へ段階移行
├─ CloudFormation資産 → 継続利用。新規部分はCDKで書き、必要に応じ CfnInclude で取り込み
└─ なし（新規）
      │
      ├─ サーバーレス専用・小〜中規模・YAML志向？ → SAM
      ├─ 組織横断のガードレール／StackSets配布？ → CloudFormation
      └─ それ以外（中〜大規模、複数サービス横断、開発者主体） → CDK

5. 組み合わせパターン（実務でよくある構成）

  1. 基盤はCFn、アプリはCDK
    • Control Tower / StackSets で配るガードレールはCFn
    • 各プロダクトチームはCDKでアプリ基盤を構築
  2. CDK＋SAM CLI
    • IaCはCDKに統一し、Lambdaのローカル実行・デバッグだけSAM CLIを利用
  3. 基盤はCDK、Lambdaアプリ部分はSAM
    • ネットワークや共有リソースはCDK、関数群はアプリチームがSAMで管理
    • スタック間はSSM Parameter Storeなどで疎結合に値を受け渡す（CFn Exportの多用は避ける）

1つのリソースを複数ツールで管理しないこと（スタックの「所有者」を明確にする）。

6. 共通のベストプラクティス

設計

  • スタック分割：ライフサイクル（変更頻度）と所有チームで分ける。ステートフル（DB、S3）とステートレス（Lambda、ECS）を分離
  • 削除保護：ステートフルリソースには DeletionPolicy: Retain／CDKなら RemovalPolicy.RETAIN、スタックの終了保護を有効化
  • 環境差分：ステージ（dev/stg/prod）差分はパラメータ・コンテキストで表現し、コードは共通化
  • 疎結合：スタック間参照はSSM Parameter Store等を優先。Exportは更新時にロックしやすい

品質・セキュリティ

  • cfn-lint、cfn-guard、cdk-nag、Checkov 等で静的チェックをCIに組み込む
  • CDKは assertions によるユニットテスト＋スナップショットテストで意図しない差分を検知
  • IAMは最小権限。CDKの grant*() を活用し、* 権限は避ける
  • シークレットはコードに書かず、Secrets Manager / SSM（SecureString）を参照

デプロイ・運用

  • 本番デプロイは必ず 差分確認（Change Set、cdk diff、sam deploy --no-execute-changeset）を経る
  • CI/CDから自動デプロイし、手動変更（ClickOps）を禁止。定期的にドリフト検出
  • CDKはリソースの論理IDが変わると置換が起きるため、リファクタリング時は cdk refactor やスナップショット差分で確認
  • ツール・ライブラリのバージョンはロックファイルで固定し、計画的にアップデート

7. 避けたいアンチパターン

  • 同じリソースを複数ツールで管理する（ドリフト・競合の原因）
  • CDKで生成テンプレートを一切見ない（置換・削除に気付けない）
  • 巨大な単一スタック（リソース上限500、デプロイ時間増大、障害時の影響範囲拡大）
  • Serverless Framework v4をライセンス確認なしに組織導入
  • CFnテンプレートのコピペ量産（モジュール化かCDK化を検討）
  • サーバーレス以外が大半なのにSAMを選ぶ（素のCFn記述が増えてSAMの利点が消える）

8. まとめ

  • CloudFormation：すべての基盤。厳密さと組織配布が必要な領域で使い、他ツールを使う場合も理解は必須。
  • CDK：新規開発の第一候補。抽象化・再利用・テスト容易性で中〜大規模に強い。
  • SAM：サーバーレスに特化したシンプルな選択肢。ローカル開発体験はCDKと併用しても価値がある。
  • Serverless Framework：既存資産の継続利用が主な用途。新規採用はライセンスと費用を確認してから。

0件のページ

    バックリンク