スキル terraform-aws-modules
📦

terraform-aws-modules

安全

本番環境対応の Terraform AWS モジュールを構築

再利用可能な Terraform 인프라 の構築は複雑でエラーが発生しやすいものです。このスキルは、モジュール設計、状態管理、AWS 向けの運用対応 HCL パターンに関する専門的なガイダンスを提供します。

対応: Claude Codex Code(CC)
📊 71 十分
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「terraform-aws-modules」を使用しています。 適切な変数定義を持つ再利用可能な EKS クラスタモジュールを作成する

期待される結果:

validation ルールで cluster_name、node_count、instance_type を定義する variables.tf、ノードグループに for_each を使用する aws_eks_cluster および aws_eks_node_group リソースを含む main.tf、クラスタエンドポイントとノードグループ ARN をエクスポートする outputs.tf、aws プロバイダを >= 4.0 に固定する versions.tf を含む完全なモジュール構造を提供します

「terraform-aws-modules」を使用しています。 本番環境向けに状態ロックを設定する

期待される結果:

バケット terraform-state-prod、キー env/prod/terraform.tfstate、リージョン us-east-1、DynamoDB テーブル tf-state-lock、暗号化有効の S3 バックエンド設定を返し、初期状態のインポートとチームアクセスポリシーの指示を含みます

セキュリティ監査

安全
v1 • 2/25/2026

Static analysis detected 25 patterns but all are false positives. External command references are Terraform CLI documentation examples (terraform fmt, validate, plan, force-unlock), not executable code. The CIDR block 10.0.0.0/16 is standard RFC1918 private networking for VPC configuration. This is documentation-only content with no executable code.

1
スキャンされたファイル
80
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
31
コミュニティ
100
セキュリティ
91
仕様準拠

作れるもの

VPC モジュールを構築する DevOps エンジニア

環境全体で一貫したネットワークデプロイメントを実現するため、適切な変数定義、出力、タグ付け戦略を持つ再利用可能な VPC モジュールを作成します。

状態管理をセットアップするプラットフォームチーム

安全な同時実行操作と状態暗号化を確保するため、運用 Terraform 状態向けに DynamoDB ロッキング付き S3 バックエンドを設定します。

CloudFormation から移行する開発者

既存の CloudFormation テンプレートを、適切なモジュール構造と最初からの状態管理を備えた Terraform HCL に変換します。

これらのプロンプトを試す

基本的なモジュール構造を作成する
バージョン管理を有効にした AWS S3 バケット用の Terraform モジュール構造を作成してください。バケット名とバージョン管理フラグ用の variables.tf、リソースを含む main.tf、バケット ARN と名前用の outputs.tf、そして AWS プロバイダを固定する versions.tf を含めてください。
ベストプラクティスについてモジュールをレビューする
この Terraform モジュールをベストプラクティスとセキュリティの観点からレビューしてください。適切な変数バリデーション、センシティブ出力のマーキング、プロバイダバージョンの固定、一貫したタグ付け戦略を確認します。
リモート状態戦略を設計する
dev、staging、production 環境を持つチーム向けにリモート状態バックエンド設定を設計してください。ストレージに S3 を使用し、DynamoDB ロッキングを有効にします。環境ごとに別の状態キーを含め、暗号化を有効にしてください。
Count から For_Each に移行する
この Terraform 設定を、複数のサブネットを管理するために count の代わりに for_each を使用するようにリファクタリングしてください。現在のコードはリストインデックスを使用する count を使用しており、中央の要素を削除する際に問題を引き起こします。既存のすべての属性を維持してください。

ベストプラクティス

  • 更新時に破壊的変更を防ぐため、versions.tf でプロバイダとモジュールのバージョンを固定する
  • リソース識別が適用間で安定したままである必要がある場合は、count より for_each を使用する
  • リモート状態をサーバーサイド暗号化を有効にした DynamoDB ロッキング付き S3 に保存する

回避

  • 不要な再作成を引き起こす、中央の要素を削除する可能性があるリソースに count を使用する
  • センシティブなリソースデータを露出する .tfstate ファイルをバージョン管理にコミットする
  • terraform_remote_state データソースを使用せずに他の設定から状態を参照する

よくある質問

失敗した Terraform apply の後に状態ロックエラーを処理するにはどうすればよいですか?
まず他の実行中の操作がないことを確認します。次に、エラーメッセージのロック ID とともに terraform force-unlock を使用します。強制解除する前に、前回の操作が実際に失敗したことを必ず確認してください。
1 つの状態ファイルを使用するか、環境ごとに別の状態を使用すべきですか?
同じ S3 バケット内の異なるキーで環境ごと(dev、staging、prod)に別の状態ファイルを使用します。これにより、状態管理をシンプルに保ちながら分離が提供され、環境ごとに独立したライフサイクルが可能になります。
Terraform 変数でシークレットを管理するにはどうすればよいですか?
variables.tf でセンシティブな変数を sensitive = true としてマークします。実際の値は AWS Secrets Manager または SSM Parameter Store に保存し、データソースを通じて参照します。シークレットを含む変数値をバージョン管理にコミットしないでください。
Terraform で count と for_each の違いは何ですか?
count は数値インデックスを使用するため、要素が削除されるとシフトし、リソースの再作成を引き起こします。for_each は安定した文字列またはオブジェクトキーを使用するため、他の要素が変更されてもリソース識別が維持されます。ほとんどのユースケースで for_each を優先してください。
既存の AWS リソースを Terraform 状態にインポートするにはどうすればよいですか?
まず HCL でリソースを定義し、次にリソースアドレスと AWS リソース ID を使用して terraform import を実行します。複雑なインポートの場合、設定を自動生成するために -generate-config を使用した terraform import の使用を検討してください。
このスキルを Azure や GCP インフラで使用できますか?
このスキルは AWS プロバイダパターンに特化しています。一般的な Terraform の概念は Azure や GCP にも適用されますが、プロバイダ固有のリソースとベストプラクティスは異なります。非 AWS インフラにはプロバイダ固有のガイダンスを使用してください。

開発者の詳細

ファイル構成

📄 SKILL.md