cloudformation-best-practices について
cloudformation-best-practices は、AWS CloudFormation テンプレートの作成、レビュー、トラブルシューティングを支援するスキルです。構成、パラメーター化、リソース保持策、検証を扱い、テンプレート検査とデプロイの安全性を区別します。
主な機能
- 01YAML テンプレート構成の指針
- 02パラメーター化と環境条件
- 03ステートフルリソースの保持ポリシー
- 04スタック間の出力とエクスポート
- 05検証とトラブルシューティングの手法
活用シーン
- 01CloudFormation テンプレートの作成やレビュー
- 02ネスト構成やスタック間アーキテクチャの設計
- 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 を希望する場合
- タスクがインフラストラクチャではなく、アプリケーションコードに関する場合
手順
- 可読性のため、JSON より YAML を使用します。
- 環境固有の値はパラメーター化し、静的な参照には
Mappingsを使用します。 - ステートフルなリソース(RDS、S3、DynamoDB)には
DeletionPolicy: Retainを適用します。 - 複数環境に対応するテンプレートには
Conditionsを使用します。 - デプロイ前に
aws cloudformation validate-templateでテンプレートを検証します。 - 文字列の補間には
!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 の骨組みだけでは、本番環境に必要なネットワーク機能やパブリック/プライベートサブネットの分離は提供されません。
- 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中止して確認を求めてください。
コメント
Markdown 対応