mcpField
C
cdk-patterns

cdk-patterns

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

cdk-patterns について

AWS CDK によるインフラ設計とコードレビューを支援するスキルです。再利用可能なコンストラクトやマルチスタック構成を扱い、CloudFormation や Terraform のタスクは対象外です。

主な機能

  1. 01再利用可能な CDK コンストラクトの設計
  2. 02マルチスタックアプリケーションの計画
  3. 03L1 より L2 コンストラクトを優先
  4. 04最小権限ポリシーの適用
  5. 05監視とデプロイ前確認の指針

活用シーン

  1. 01サーバーレス API インフラの構築
  2. 02コンテナサービスやデータパイプラインの設計
  3. 03CDK コードやアンチパターンのレビュー
  4. 04ステートフルとステートレスなリソースの分離

インストール

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

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill cdk-patterns

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

詳細

AWS Cloud Development Kit(CDK)のエキスパートです。再利用可能なパターン、L2/L3 コンストラクト、本番環境に対応したインフラストラクチャスタックを専門としています。

このスキルを使う場面

  • 再利用可能な CDK コンストラクトやパターンを構築する場合
  • マルチスタックの CDK アプリケーションを設計する場合
  • 一般的なインフラストラクチャパターン(API + Lambda + DynamoDB、ECS サービス、静的サイトなど)を実装する場合
  • ベストプラクティスやアンチパターンに照らして CDK コードをレビューする場合

このスキルを使わない場面

  • ユーザーが CDK を使わずに CloudFormation テンプレートを直接必要としている場合
  • タスクが Terraform 固有の場合
  • 単発のシンプルな CLI リソース作成で十分な場合

手順

  1. 必要なインフラストラクチャパターン(サーバーレス API、コンテナーサービス、データパイプラインなど)を特定します。
  2. より安全なデフォルト設定を利用できるよう、可能な限り L1(Cfn*)コンストラクトより L2 コンストラクトを使用します。
  3. すべての IAM ロールとポリシーに最小権限の原則を適用します。
  4. 本番環境への対応として、RemovalPolicy と Tags を適切に使用します。
  5. 再利用性を高めるためにスタックを構成します。ステートフル(データベース、バケット)とステートレス(コンピューティング、API)を分離します。
  6. デフォルトでモニタリングを有効にします(CloudWatch アラーム、X-Ray トレース)。

例

例 1:サーバーレス API パターン
import { Construct } from "constructs";
import * as cdk from "aws-cdk-lib";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";

export class ServerlessApiPattern extends Construct {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    const table = new dynamodb.Table(this, "Table", {
      partitionKey: { name: "pk", type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
    });

    const handler = new lambda.Function(this, "Handler", {
      runtime: lambda.Runtime.NODEJS_20_X,
      handler: "index.handler",
      code: lambda.Code.fromAsset("lambda"),
      environment: { TABLE_NAME: table.tableName },
      tracing: lambda.Tracing.ACTIVE,
    });

    table.grantReadWriteData(handler);

    new apigateway.LambdaRestApi(this, "Api", { handler });
  }
}

合成を実行する前に、lambda/ アセットディレクトリにプロジェクトの実際のハンドラーを格納してください。 このスニペットはコンストラクトの例であり、デプロイ可能な完全なアプリケーションではありません。 まず、API 認可、入力検証、ログ記録、コスト、アカウント/リージョン、IAM の適用範囲を確認してください。 プロジェクトのテストを実行し、cdk synth を実行して、cdk diff を確認してください。デプロイには、指定した環境に対する認可が必要です。 L2 コンストラクトだけでは、安全なデフォルト設定が保証されるわけではありません。

ベストプラクティス

  • ✅ 推奨: 一貫したタグ付けには cdk.Tags.of(this).add() を使用します
  • ✅ 推奨: ステートフルリソースとステートレスリソースを別々のスタックに分けます
  • ✅ 推奨: デプロイの前に必ず cdk diff を実行します
  • ❌ 非推奨: L2 の代替がある場合に L1(Cfn*)コンストラクトを使用します
  • ❌ 非推奨: アカウント ID やリージョンをハードコードします。cdk.Aws.ACCOUNT_ID を使用してください

トラブルシューティング

問題: スタック間に循環依存関係がある 解決策: 共有リソースを専用のベーススタックに切り出し、コンストラクターの props で参照を渡します。

制限事項

  • タスクが上記の範囲に明確に該当する場合に限り、このスキルを使用してください。
  • 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
  • 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認してください。

コメント