스킬 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 클러스터 모듈 생성

예상 결과:

유효성 검사 규칙과 함께 cluster_name, node_count 및 instance_type 을 정의하는 variables.tf, node 그룹을 위한 for_each 를 사용한 aws_eks_cluster 및 aws_eks_node_group 리소스가 포함된 main.tf, 클러스터 엔드포인트 및 node 그룹 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 환경이 있는 팀을 위한 원격 상태 백엔드 구성을 설계하세요. 잠금을 위한 DynamoDB 가 있는 S3 를 스토리지로 사용하세요. 환경별로 별도의 상태 키를 포함하고 암호화를 활성화하세요.
Count 에서 For_Each 로 마이그레이션 
이 Terraform 구성을 여러 서브넷을 관리하기 위해 count 대신 for_each 를 사용하도록 리팩토링하세요. 현재 코드는 중간 요소를 제거할 때 문제가 발생하는 list 인덱싱과 함께 count 를 사용합니다. 모든 기존 속성을 유지하세요.

모범 사례

  • 업데이트 중 중단 방지하기 위해 versions.tf 에 프로바이더 및 모듈 버전 고정
  • 리소스 식별이 apply 간에 안정적으로 유지되어야 할 때 count 대신 for_each 사용
  • 원격 상태를 S3 에 저장하고 DynamoDB 잠금 및 서버 측 암호화 활성화

피하기

  • 중간 요소가 제거될 수 있는 리소스에 count 사용하여 불필요한 재생성 발생
  • 민감한 리소스 데이터를 노출하는 .tfstate 파일을 버전 관리에 커밋
  • terraform_remote_state 데이터 소스를 사용하지 않고 다른 구성에서 상태 참조

자주 묻는 질문

실패한 Terraform apply 후 상태 잠금 오류를 어떻게 처리하나요?
먼저 다른 작업이 실행되지 않고 있는지 확인하세요. 그런 다음 오류 메시지의 잠금 ID 와 함께 terraform force-unlock 을 사용하세요. 강제로 잠금 해제하기 전에 이전 작업이 실제로 실패했는지 항상 확인하세요.
환경별로 하나의 상태 파일이나 별도의 상태를 사용해야 하나요?
동일한 S3 버킷에서 다른 키를 사용하여 환경별 (dev, staging, prod) 별도 상태 파일을 사용하세요. 이렇게 하면 격리를 제공하면서 상태 관리를 간단하게 유지하고 환경별로 독립적인 수명 주기를 활성화할 수 있습니다.
Terraform 변수에서 비밀을 어떻게 관리하나요?
variables.tf 에서 sensitive = true 로 민감한 변수를 마킹하세요. 실제 값을 AWS Secrets Manager 또는 SSM Parameter Store 에 저장하고 data sources 를 통해 참조하세요. 비밀을 포함한 변수 값을 버전 관리에 커밋하지 마세요.
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 인프라에는 프로바이더별 지침을 사용하세요.

개발자 세부 정보

작성자

sickn33

라이선스

MIT

리포지토리

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/terraform-aws-modules

참조

main

파일 구조

📄 SKILL.md