DytnamoDB 없이 S3에서 Terraform 상태 잠금 관리
Source: Dev.to
Introduction
Terraform을 사용해 본 적이 있다면 아마도 다음과 같은 표준 구성을 따라왔을 것입니다:
- S3 – Terraform 상태 저장
- DynamoDB – 상태 잠금
Terraform의 S3 백엔드는 이제 DynamoDB 없이도 상태 잠금을 지원하여 더 간단한 대안을 제공합니다. 여기서 중요한 질문이 떠오릅니다: Terraform 상태 잠금에 여전히 DynamoDB가 필요할까요?
How Terraform State Locking Works
Terraform은 상태 파일을 인프라의 단일 진실 원천(single source of truth)으로 간주합니다. terraform apply를 실행하면 Terraform은 이 파일을 읽고 업데이트합니다. 적절한 상태 잠금은 동시 수정으로 인한 충돌을 방지합니다:
- Terraform이 잠금을 획득하려 시도합니다.
- 잠금이 존재하면 → 실행이 중단됩니다.
- 잠금이 없으면 → 실행이 진행됩니다.
- 완료 후 → 잠금이 해제됩니다.
잠금은 다음과 같이 저장될 수 있습니다:
- DynamoDB 레코드(전통적인 방법)
- S3 버킷 내
.tflock파일(S3‑only 방법)
When to Use S3‑Only Locking
Suitable Scenarios
- 소규모 팀 또는 개인 개발자
- 제어된 인프라 변경
- 동시에 실행되지 않는 CI/CD 파이프라인
- 비용 및 인프라 복잡성을 줄이고자 할 때
Situations to Avoid S3‑Only Locking
- 동시에 여러 파이프라인이 실행되는 경우(높은 동시성)
- 동시 작업이 빈번한 대규모 엔지니어링 팀
- 강력한 일관성 보장이 필요한 핵심 인프라
이러한 경우에는 DynamoDB 잠금이 더 안전한 선택입니다.
Common Issues with S3‑Only Locking
Terraform이 잠금을 해제하기 전에 크래시가 발생하면 .tflock 파일이 S3에 남아 이후 실행을 차단할 수 있습니다. 이 경우 수동으로 정리해야 합니다:
aws s3 rm s3://your-bucket/path/.tflock
Best Practices for S3 Backend Locking
- S3 버전 관리 활성화 – 상태 파일을 보호합니다.
- KMS 암호화 사용 – 데이터가 휴지 상태일 때 암호화합니다.
- 환경별로 상태 파일 분리(예: dev, prod).
- 최소 권한 원칙에 따라 IAM 권한 제한.
- 상태 접근 및 변경 모니터링(예: CloudTrail, S3 액세스 로그).
Migrating from DynamoDB to S3‑Only Locking
-
백엔드 설정에 lockfile 사용을 활성화합니다:
terraform { backend "s3" { bucket = "your-bucket" key = "path/to/terraform.tfstate" region = "us-east-1" encrypt = true kms_key_id = "alias/your-key" use_lockfile = true # S3‑only 잠금 활성화 } } -
상태를 마이그레이션합니다:
terraform init -migrate-state -
프로덕션에 적용하기 전에 동시성 시나리오를 테스트합니다.
Choosing the Right Approach
- 소규모 팀 / 낮은 동시성 → S3‑only 잠금으로 충분하며 비용을 절감할 수 있습니다.
- 대규모 / 빈번한 동시 배포 → DynamoDB 잠금이 더 강력한 일관성과 신뢰성을 제공합니다.
핵심은 기본값을 무조건 따르기보다 워크로드에 맞는 잠금 전략을 선택하는 것입니다.