첫 AWS 리소스 생성 및 삭제하기

AWSBeginner
지금 연습하기

소개

팀에서 보고서를 보관할 비공개 스토리지가 필요합니다. 이 실습에서는 Terraform으로 첫 번째 버킷을 생성하고, 구성을 AWS 및 Terraform 상태와 비교한 다음, 삭제 계획을 검토하고 실행합니다. 별도로 존재하는 참조 보고서는 다른 팀의 소유이므로 그대로 보존해야 합니다.

Terraform 리소스, init, plan, apply, 상태, destroy를 이미 이해하고 있으며, 파일 편집과 AWS CLI를 사용한 S3 조회에 익숙해야 합니다. Terraform, AWS 프로바이더, CLI 접근 설정은 준비되어 있습니다. 명령은 Terminal에서 실행하고 스토리지는 AWS View에서 확인하세요. 개인 AWS 계정이나 액세스 키는 필요하지 않습니다. 각 실습은 독립적으로 시작합니다.

관련 자격증 시험 항목

자격증 시험 과제 실습 내용
Cloud Practitioner (CLF-C02) Task 3.1 코드형 인프라로 반복 가능한 배포를 수행하고 CLI 조회로 결과를 확인합니다.
Developer – Associate (DVA-C02) Task 3.3, Skill 3.3.4 IaC 리소스 정의를 구현하고 배포하는 기초 실습입니다.
DevOps Engineer – Professional (DOP-C02) Task 2.1 IaC로 리소스를 정의하고 생성 및 삭제를 관리하는 기초 실습입니다.

개념 개요: Terraform 구성이 상태 매핑을 통해 하나의 S3 버킷을 관리하며, 별도의 참조 버킷은 보존됩니다.

보고서 버킷 생성하기

이 단계에서는 Terraform 리소스 정의를 현재 AWS 계정에 연결하고 비공개 보고서 버킷을 생성합니다.

먼저 준비된 루트 디렉터리로 이동하여 리전과 호출자 신원을 조회합니다. 루트 디렉터리는 자체 상태를 갖는 하나의 독립적인 Terraform 구성을 담는 디렉터리입니다. 호출자의 계정은 프로바이더 요청이 어느 계정에서 작동하는지 알려 주며, ARN은 요청하는 주체를 식별합니다.

cd /home/labex/project/first-aws-resource
aws configure get region
aws sts \
  get-caller-identity
terraform version

리전은 us-east-1입니다. Terraform 버전은 1.17.2로 표시됩니다. 준비된 접근 권한은 개인 AWS 계정과 별개입니다.

제공된 provider.tf는 AWS 프로바이더 버전 6.14.0을 선택하고, 준비된 연결을 구성하며, Terraform 버전을 1.17.2로 고정합니다. 프로바이더는 리소스 작업을 AWS API 요청으로 변환합니다. 리소스 관리에 집중할 수 있도록 프로바이더 구성은 미리 제공됩니다.

다음 구성으로 main.tf를 생성합니다. cat과 <<'EOF'는 끝을 나타내는 EOF 앞까지의 모든 내용을 지정한 파일에 씁니다. aws_s3_bucket은 AWS 리소스 유형이고 reports는 Terraform의 로컬 레이블입니다. 둘을 합쳐 aws_s3_bucket.reports라는 주소가 됩니다. bucket 속성은 AWS 버킷 이름이며 이 주소와는 별개입니다. 태그는 리소스의 용도를 기록합니다.

cat > main.tf <<'EOF'
resource "aws_s3_bucket" "reports" {
  bucket = "terraform-first-reports"
  tags = {
    Project = "TerraformReports"
  }
}

output "report_bucket" {
  value = aws_s3_bucket.reports.id
}
EOF

이 루트를 초기화하고 구성의 유효성을 검사합니다.

terraform init
terraform validate

init은 준비된 캐시에서 고정된 버전의 프로바이더를 설치하고 .terraform.lock.hcl을 작성합니다. 실제 프로젝트에서는 이 의존성 잠금 파일을 구성과 함께 보관하세요. 선택한 프로바이더와 패키지 체크섬이 기록됩니다. 리소스 주소와 배포된 리소스 ID를 매핑하는 Terraform 상태와는 다른 파일입니다. 캐시가 이 Linux 환경에 맞게 준비되어 있으므로 init에서 잠금 파일의 체크섬이 linux_amd64만 포함한다는 경고가 나올 수 있습니다. 그래도 초기화는 완료됩니다. 다른 플랫폼에서도 사용하는 프로젝트라면 해당 플랫폼의 체크섬도 필요합니다.

리소스를 생성하기 전에 계획을 검토합니다.

terraform plan

Plan: 1 to add, 0 to change, 0 to destroy.가 표시되어야 합니다. 일부 속성은 생성 시 AWS가 할당하거나 반환하므로 (known after apply)로 표시됩니다. 버킷 이름과 프로젝트 태그를 확인하세요. 계획은 작업을 미리 보여 줄 뿐 버킷을 생성하지 않습니다.

구성을 적용하고 확인 프롬프트에 yes를 입력합니다.

terraform apply

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.가 표시되어야 합니다. report_bucket 출력은 terraform-first-reports입니다. AWS View에서 새 빈 버킷이 team-reference-reports 옆에 나타납니다. 해당 참조 버킷과 그 안의 keep.txt 객체는 변경하지 마세요.

생성 후 AWS View: 비어 있는 Terraform 관리 보고서 버킷이 변경되지 않은 팀 참조 버킷 옆에 표시됩니다.

명령을 완료한 후 Continue를 누르세요. 검사는 AWS와 상태 매핑을 각각 독립적으로 조회합니다. 명령이 성공했다는 사실만으로는 충분하지 않습니다.

구성, 상태, AWS 비교하기

이 단계에서는 Terraform 리소스 주소를 실제 비공개 버킷과 연결하여 살펴보고, 구성이 수렴했는지 확인합니다.

출력은 리소스 참조를 통해 버킷 ID를 읽습니다. state list는 관리 중인 주소를 표시하고, state show는 기록된 속성을 표시합니다. 이 명령들은 AWS를 변경하지 않고 매핑을 확인합니다.

terraform output report_bucket
terraform state list
terraform state show aws_s3_bucket.reports

aws_s3_bucket.reports와 그 ID인 terraform-first-reports를 찾으세요. 구성은 원하는 리소스를 표현하고, AWS는 리소스를 보유하며, 상태는 둘을 연결합니다. 상태 항목만으로 리소스가 여전히 존재한다고 입증할 수는 없습니다.

AWS를 직접 조회합니다. get-bucket-location은 S3의 us-east-1 리전에 대해 null을 반환합니다. ACL은 소유자인 정규 사용자(canonical user)에게만 접근을 허용해야 하며, 공개 그룹에 부여된 권한이 없어야 합니다. 이 실습에서는 비공개 버킷을 생성하며 공개 버킷 정책을 추가하지 않습니다.

aws s3api \
  get-bucket-location \
  --bucket terraform-first-reports
aws s3api \
  get-bucket-acl \
  --bucket terraform-first-reports
aws s3api \
  get-bucket-tagging \
  --bucket terraform-first-reports

Project 태그가 TerraformReports인지 확인하세요. 관련 없는 다른 보고서를 여전히 읽을 수 있는지도 확인합니다. --query 표현식은 바이트 길이만 선택하며, 이 명령은 저장된 객체를 변경하지 않습니다.

aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength
terraform plan

계획에 No changes.가 표시되어야 합니다. 이는 프로바이더가 관리 중인 리소스에 적용할 구성 변경을 발견하지 못했다는 뜻입니다. 모든 보안 속성을 입증하거나 보고서 데이터를 검증하는 것은 아닙니다. 그런 항목에는 별도의 검사가 필요합니다. 자세한 내용은 Terraform 상태와 S3 접근 제어를 참고하세요.

관리 중인 리소스만 삭제하기

이 단계에서는 삭제 계획을 검토하고 실행한 다음, 관리 중인 버킷과 상태 매핑은 사라지고 참조 보고서는 남아 있음을 확인합니다.

terraform plan -destroy는 이 루트의 상태에 있는 리소스의 삭제를 미리 보여 줍니다. “계정의 모든 버킷 삭제”를 뜻하지 않습니다. 계속하기 전에 주소와 버킷 ID를 읽어 보세요.

terraform plan -destroy

Plan: 0 to add, 0 to change, 1 to destroy.가 표시되어야 합니다. 이 루트는 참조 버킷을 관리하지 않으므로 참조 버킷은 계획에 나타나지 않습니다. 대상 버킷은 비어 있습니다. 저장된 데이터와 버전에 대해 별도의 보존 결정을 내려야 하는 이유는 이후 실습에서 설명합니다.

관리 중인 버킷을 삭제하고 확인 프롬프트에 yes를 입력합니다.

terraform destroy

Destroy complete! Resources: 1 destroyed.가 표시되어야 합니다. 이제 상태를 확인하고 남아 있는 버킷을 조회합니다.

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

상태 목록은 비어 있습니다. 성공적으로 조회된 버킷 목록에는 terraform-first-reports가 없고, team-reference-reports와 그 보고서는 남아 있습니다. 인증 오류를 삭제 성공으로 오해하지 않도록 최종 검사가 완료될 때까지 AWS 접근 설정을 유지하세요. 리소스를 다시 생성하려는 경우 사용할 수 있도록 구성과 잠금 파일은 그대로 남아 있습니다.

정리 후 AWS View: Terraform 관리 버킷은 사라지고 별도의 팀 참조 보고서는 남아 있습니다.

요약

고정된 버전의 AWS 프로바이더로 비공개 S3 버킷을 생성하고, AWS 조회를 통해 구성 및 상태와 비교하고, 수렴한 계획을 확인한 뒤 관리 중인 리소스만 삭제했습니다. 독립적인 참조 보고서는 온전히 보존되었습니다. 다음 실습에서는 입력값과 리소스 참조를 사용하여 보고서 내용을 관리합니다.