목차
AWS에서 CloudFront 배포(Distribution)를 콘솔로 만들었지만, 나중에 코드 기반 관리(IaC)를 위해 Terraform으로 전환하고 싶을 때 어떻게 해야 할까요?
이번 글에서는 Terraform의 import 기능을 통해 콘솔로 만든 CloudFront 리소스를 Terraform으로 상태 일치시켜 관리하는 전체 과정을 실습 기반으로 정리합니다.
🎯 목표
- 콘솔에서 만든 CloudFront 배포를 삭제하지 않고 Terraform으로 가져옴
- Terraform 상태(state)와 코드(.tf)를 일치시켜 안전하게 관리
- Terraformer 사용 시 주의점까지 포함
✅ 전체 작업 흐름 요약
| 단계 | 설명 |
| 1 | 최소한의 .tf 리소스 블록 작성 |
| 2 | terraform import로 상태(state) 연결 |
| 3 | terraform state show로 실제 리소스 속성 추출 |
| 4 | .tf 코드에 필요한 필수 속성만 수동 반영 (더미 값 포함) |
| 5 | 읽기 전용 속성 제거 |
| 6 | terraform plan으로 일치 여부 확인 후 관리 시작 |
Step 1. 최소한의 리소스 선언 (더미 값 필요)
CloudFront 리소스는 필수 속성이 많아 빈 리소스 블록만으로는 terraform validate 에 실패합니다.
따라서, 아래처럼 실제 값 또는 더미 값(dummy) 으로 구성된 리소스 블록을 선언해야 합니다:
resource "aws_cloudfront_distribution" "cf1" {
enabled = true
is_ipv6_enabled = true
comment = "import dummy"
default_root_object = "index.html"
origin {
domain_name = "dummy-origin.com"
origin_id = "dummy-origin-id"
}
default_cache_behavior {
target_origin_id = "dummy-origin-id"
viewer_protocol_policy = "redirect-to-https"
allowed_methods = ["GET", "HEAD"]
cached_methods = ["GET", "HEAD"]
forwarded_values {
query_string = false
cookies {
forward = "none"
}
}
}
restrictions {
geo_restriction {
restriction_type = "none"
}
}
viewer_certificate {
cloudfront_default_certificate = true
}
}이 값들은 import 후 terraform state show 결과를 바탕으로 실제 값으로 교체하면 됩니다.
Step 2. 상태 import
terraform init
terraform import aws_cloudfront_distribution.cf1 E2LBMBNBDI16ZI- E2LBMBNBDI16ZI: AWS 콘솔에서 확인한 배포 ID
- 리소스 이름 cf1과 .tf 코드의 리소스 이름이 반드시 일치해야 합니다
Step 3. 상태에서 속성 추출
terraform state show aws_cloudfront_distribution.cf1 > cf1_state.txt이 파일에서 CloudFront 설정값을 확인하고 .tf 코드에 반영합니다.
단, 읽기 전용 속성은 절대 .tf에 넣으면 안 됩니다.
🚫 넣으면 안 되는 읽기 전용 속성들
아래 속성들을 .tf 코드에 넣으면 terraform apply 시 다음과 같은 에러가 발생합니다:
Error: Value for unconfigurable attribute ...
| 속성 | 설명 |
| arn | CloudFront 리소스 ARN |
| id | 배포 ID |
| status | 배포 상태 (Deployed, InProgress 등) |
| etag | 리소스 상태 해시값 |
| domain_name | CloudFront 도메인 (*.cloudfront.net) |
| hosted_zone_id | Route53 연동을 위한 내부 Zone ID |
| caller_reference | 내부 유니크 식별자 |
이 값들은 terraform state show 결과에만 존재해야 하고, .tf 코드에서는 제거해야 합니다.
🧪 Step 4. .tf 코드에 실제 값 반영
state show에서 가져온 실제 속성으로 .tf 코드를 채워넣고, terraform plan 으로 확인합니다.
- 결과가 No changes. → 상태와 코드가 일치한 것
- 이후부터는 완전히 Terraform으로 리소스를 관리할 수 있게 됩니다
⚠️ Terraformer로 CloudFront 가져오면 안 되는 이유
Terraformer는 기존 리소스를 자동으로 .tf 코드와 .tfstate로 추출해 주는 편리한 도구지만, CloudFront에는 적합하지 않습니다. 이유는 다음과 같습니다:
| 문제점 | 설명 |
| 필수 속성 누락 | Terraformer가 생성한 .tf에 필수 속성들이 빠지거나 더미로 들어감 |
| 읽기 전용 속성 포함 | id, arn 등이 그대로 들어가 terraform plan 시 오류 발생 |
| 의존성, 캐시 정책 누락 | origin, default_cache_behavior 등 구조적으로 중요한 블록이 비정상적 |
| 상태 병합 어려움 | 기존 프로젝트와 상태 통합 시 수동 수정 필요 |
| 코드 품질 낮음 | naming, 변수화, 모듈 구조 등 팀 표준에 안 맞는 코드 생성 |
따라서 CloudFront의 경우, Terraformer보다 terraform import + 수동 정리가 훨씬 안전하고 권장됩니다.
마무리 요약
| 항목 | 내용 |
| CloudFront .tf 코드 작성 | 필수 속성은 더미 값이라도 채워야 함 |
| 읽기 전용 속성 제거 | arn, id, status, caller_reference 등 제거 필수 |
| 상태와 코드 일치 확인 | terraform plan 결과가 No changes.이면 완료 |
| Terraformer 사용 여부 | CloudFront에 대해서는 비추천 |
마무리
CloudFront는 구조가 복잡하고 설정이 많기 때문에, terraform import 이후에도 수동으로 상태를 분석해 정확히 .tf 코드에 반영하는 작업이 필요합니다.
그러나 이 초기 과정만 잘 해두면, 이후에는 CloudFront를 안전하고 재현 가능하게 코드로 관리할 수 있습니다.
댓글