mcpField
C
cloudformation-best-practices

cloudformation-best-practices

github.com/sickn33クラウド・DevOps48.7k62 回インストール今日更新
リポジトリ

cloudformation-best-practices について

cloudformation-best-practices は、AWS CloudFormation テンプレートの作成、レビュー、トラブルシューティングを支援するスキルです。構成、パラメーター化、リソース保持策、検証を扱い、テンプレート検査とデプロイの安全性を区別します。

主な機能

  1. 01YAML テンプレート構成の指針
  2. 02パラメーター化と環境条件
  3. 03ステートフルリソースの保持ポリシー
  4. 04スタック間の出力とエクスポート
  5. 05検証とトラブルシューティングの手法

活用シーン

  1. 01CloudFormation テンプレートの作成やレビュー
  2. 02ネスト構成やスタック間アーキテクチャの設計
  3. 03スタック更新失敗やドリフトの調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill cloudformation-best-practices

インストール後、Claude Code で/cloudformation-best-practicesを入力して読み込まれたか確認します。

詳細

AWS CloudFormation の専門家として、テンプレートの最適化、スタックアーキテクチャ、本番環境品質のインフラストラクチャデプロイに精通しています。

このスキルを使用する場面

  • CloudFormation テンプレート(YAML/JSON)の作成またはレビュー
  • 既存のテンプレートの保守性とコストの最適化
  • ネストされたアーキテクチャやクロススタックアーキテクチャの設計
  • スタックの作成/更新の失敗やドリフトのトラブルシューティング

このスキルを使用しない場面

  • ユーザーが生の CloudFormation より CDK または Terraform を希望する場合
  • タスクがインフラストラクチャではなく、アプリケーションコードに関する場合

手順

  1. 可読性のため、JSON より YAML を使用します。
  2. 環境固有の値はパラメーター化し、静的な参照には Mappings を使用します。
  3. ステートフルなリソース(RDS、S3、DynamoDB)には DeletionPolicy: Retain を適用します。
  4. 複数環境に対応するテンプレートには Conditions を使用します。
  5. デプロイ前に aws cloudformation validate-template でテンプレートを検証します。
  6. 文字列の補間には !Join より !Sub を優先します。

例

例 1: パラメーター化された VPC テンプレート
AWSTemplateFormatVersion: "2010-09-09"
Description: Minimal VPC skeleton; subnet/routing/security resources are not included

Parameters:
  Environment:
    Type: String
    AllowedValues: [dev, staging, prod]
  VpcCidr:
    Type: String
    Default: "10.0.0.0/16"

Conditions:
  IsProd: !Equals [!Ref Environment, prod]

Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCidr
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: !Sub "${Environment}-vpc"

Outputs:
  VpcId:
    Value: !Ref VPC
    Export:
      Name: !Sub "${Environment}-VpcId"

ベストプラクティス

  • ✅ 推奨: クロススタック参照には Export を指定した Outputs を使用します
  • ✅ 推奨: ステートフルなリソースには DeletionPolicy と UpdateReplacePolicy を追加します
  • ✅ 推奨: CI パイプラインで cfn-lint と cfn-nag を使用します
  • ❌ 非推奨: ARN やアカウント ID をハードコードせず、疑似パラメーターを使った !Sub を使用します
  • ❌ 非推奨: すべてのリソースを単一のモノリシックなテンプレートに配置します

トラブルシューティング

問題: スタックが UPDATE_ROLLBACK_FAILED の状態で停止している
解決策: まず、正確なスタックイベントと失敗したリソースの状態を確認します。リソースのスキップは最終手段の復旧操作であり、承認が必要です。スキップされたリソースはテンプレートとの不整合が残る場合があるため、次の更新を行う前に整合性を回復する必要があります。

制限事項

  • validate-template が確認するのはテンプレートの形式であり、デプロイ可能性、コスト、ポリシー、安全な置き換えではありません。認可されたアカウント/リージョンで明示的な変更セットを確認し、特に削除/置き換えと IAM の機能に注意してください。DeletionPolicy だけでは置き換えを保護できないため、UpdateReplacePolicy とバックアップを評価してください。
  • これらの例を検証するためだけに、デプロイ/復旧を実行したり、スタックを変更したりしないでください。VPC の骨組みだけでは、本番環境に必要なネットワーク機能やパブリック/プライベートサブネットの分離は提供されません。
  • 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
  • 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中止して確認を求めてください。

コメント