Terraform으로 AWS 인프라 자동화: VPC, EC2, RDS 실전 프로비저닝 가이드

Terraform을 활용하여 AWS 클라우드 인프라(VPC, EC2, RDS)를 효율적으로 자동 프로비저닝하는 실전 가이드를 제공합니다. 인프라 관리의 복잡성을 줄이고 안정성을 높이는 방법을 알아보세요.

클라우드 환경에서 인프라를 구축하고 관리하는 데 얼마나 많은 시간을 쏟고 계신가요? 혹시 수많은 클릭과 반복적인 작업으로 인해 지치거나, 설정 오류로 밤샘 작업을 해본 경험이 있으신가요? 개발 팀이 새로운 기능을 빠르게 배포하고 싶어도, 인프라 준비에만 며칠이 걸려 답답했던 적은 없으신가요? 이러한 문제들은 클라우드 인프라 관리의 고질적인 어려움이며, 많은 조직이 겪고 있는 현실입니다.

이 글에서는 이러한 문제들을 해결하기 위한 강력한 도구, Terraform을 소개하고, 이를 활용하여 AWS 클라우드 인프라를 자동으로 프로비저닝하는 실전 가이드를 제공합니다. AWS의 핵심 서비스인 VPC, EC2, RDS를 Terraform으로 구축하는 과정을 단계별로 살펴보며, 여러분의 인프라 관리 효율성을 혁신적으로 높이는 방법을 함께 알아보겠습니다.

📑 목차

• 왜 Terraform으로 클라우드 인프라를 자동화해야 할까요?
• 수동 인프라 관리의 한계와 비효율성
• IaC(Infrastructure as Code)의 등장과 Terraform의 역할
• Terraform 설치 및 AWS 환경 설정
• Terraform CLI 설치 가이드
• AWS 자격 증명 및 프로바이더 설정
• AWS VPC 기본 인프라 구축: 네트워크 설계의 시작
• 안전하고 확장 가능한 VPC 구조 설계
• VPC 및 서브넷 Terraform 코드 작성
• EC2 인스턴스 프로비저닝: 애플리케이션 서버 준비
• EC2 인스턴스 유형과 보안 그룹 설정
• EC2 Terraform 모듈 구성 및 배포
• RDS 데이터베이스 배포: 안정적인 데이터 계층 확보
• RDS 인스턴스 설정과 파라미터 그룹
• RDS Terraform 코드 작성 및 데이터베이스 연결
• Terraform으로 인프라 관리: 변경, 파괴, 모듈화
• 인프라 변경 및 삭제 워크플로우
• Terraform 모듈을 활용한 효율적인 관리
• 결론: Terraform으로 생산성을 극대화하세요

Image by Boskampi on Pixabay

왜 Terraform으로 클라우드 인프라를 자동화해야 할까요?

전통적인 클라우드 인프라 관리는 AWS 콘솔을 통한 수동 작업이나 스크립트 기반의 임시방편적인 방식이 주를 이뤘습니다. 하지만 이러한 방식은 여러 가지 심각한 문제를 야기합니다.

수동 인프라 관리의 한계와 비효율성

• 휴먼 에러 발생 가능성 증대: 수동으로 수십, 수백 개의 설정을 클릭하다 보면 실수할 확률이 높아집니다. 작은 오타 하나가 서비스 전체 장애로 이어질 수 있습니다.
• 일관성 부족: 여러 환경(개발, 스테이징, 운영)에 인프라를 구축할 때, 수동 작업으로는 정확히 동일한 환경을 재현하기 어렵습니다. 이는 환경 간의 불일치로 인한 버그 발생으로 이어집니다.
• 시간 소모 및 생산성 저하: 새로운 프로젝트를 시작하거나 기존 인프라를 확장할 때마다 수동으로 많은 시간을 투입해야 합니다. 이는 개발 팀의 생산성을 저해하고 시장 출시 시간을 지연시킵니다.
• 문서화의 어려움: 수동으로 구축된 인프라는 변경 이력을 추적하거나 문서화하기가 매우 어렵습니다. 누가, 언제, 어떤 부분을 변경했는지 파악하기 힘들어집니다.

IaC(Infrastructure as Code)의 등장과 Terraform의 역할

이러한 문제들을 해결하기 위해 등장한 개념이 바로 IaC (Infrastructure as Code)입니다. IaC는 인프라를 코드로 정의하고 관리하는 접근 방식으로, 소프트웨어 개발과 동일한 원칙(버전 관리, 테스트, 자동화)을 인프라에 적용합니다. 그중 Terraform은 HashiCorp에서 개발한 오픈소스 IaC 도구로, 다음과 같은 강력한 이점을 제공합니다.

• 선언적 구성 (Declarative Configuration): Terraform은 "어떻게" 인프라를 만들지가 아니라 "무엇을" 만들지를 정의합니다. 원하는 최종 상태를 기술하면, Terraform이 현재 상태와 비교하여 필요한 변경 사항을 자동으로 적용합니다.
• 불변성 (Immutability): 코드로 정의된 인프라는 항상 동일하게 배포될 수 있습니다. 이는 환경 간의 일관성을 보장하고, 예측 불가능한 변경을 방지합니다.
• 반복 가능성 (Repeatability): 동일한 코드를 사용하여 여러 환경에 동일한 인프라를 손쉽게 구축할 수 있습니다. 개발, 스테이징, 운영 환경을 완벽하게 동기화할 수 있습니다.
• 다중 클라우드 지원: AWS뿐만 아니라 Azure, Google Cloud Platform(GCP) 등 다양한 클라우드 제공업체와 온프레미스 솔루션까지 지원합니다.
• 버전 관리: 인프라 코드를 Git과 같은 버전 관리 시스템에 저장하여 변경 이력을 추적하고 협업을 용이하게 합니다.

수동 관리와 Terraform을 사용한 IaC 방식의 차이를 아래 표로 비교해 볼까요?

특징	수동 인프라 관리	Terraform (IaC)
작업 방식	클릭, GUI 조작	코드 작성, CLI 명령어
일관성	환경별 편차 발생 가능	높은 일관성 유지
오류 발생률	휴먼 에러 빈번	코드 검토 및 테스트로 오류 최소화
속도 및 효율성	느리고 반복적인 작업	빠르고 자동화된 배포
문서화 및 추적	어렵고 비효율적	버전 관리 시스템으로 용이
비용	인건비 및 오류 복구 비용	초기 학습 비용, 장기적 비용 절감

Terraform 설치 및 AWS 환경 설정

Terraform을 사용하여 AWS 인프라를 구축하기 전에, 먼저 필요한 도구들을 설치하고 AWS 환경을 설정해야 합니다.

Terraform CLI 설치 가이드

Terraform CLI는 HashiCorp 공식 웹사이트에서 다운로드할 수 있습니다. 사용하시는 운영체제에 맞는 버전을 선택하여 설치하세요. 설치 후, 명령 프롬프트나 터미널에서 terraform -v 명령어를 입력하여 정상적으로 설치되었는지 확인할 수 있습니다.

# Linux/macOS 예시 (brew 사용)
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

# 또는 수동 설치
# 1. https://www.terraform.io/downloads.html 에서 OS에 맞는 바이너리 다운로드
# 2. 압축 해제 후, terraform 실행 파일을 PATH 환경 변수에 추가

AWS 자격 증명 및 프로바이더 설정

Terraform이 AWS 리소스를 생성, 수정, 삭제하려면 AWS 계정에 접근할 수 있는 권한이 필요합니다. 이를 위해 AWS CLI를 설치하고 자격 증명을 설정하는 것이 일반적입니다.

# AWS CLI 설치 (OS에 따라 다름)
# curl "https://awscli.amazonaws.com/awscli-bundle.zip" -o "awscli-bundle.zip"
# unzip awscli-bundle.zip
# sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws

# AWS 자격 증명 설정
aws configure
AWS Access Key ID [None]: YOUR_ACCESS_KEY_ID
AWS Secret Access Key [None]: YOUR_SECRET_ACCESS_KEY
Default region name [None]: ap-northeast-2
Default output format [None]: json

자격 증명 설정 후, Terraform 프로젝트의 루트 디렉토리에 main.tf 파일을 생성하고 AWS 프로바이더를 정의합니다. 프로바이더는 Terraform이 어떤 클라우드 서비스와 통신할지 알려주는 역할을 합니다.

// main.tf
provider "aws" {
  region = "ap-northeast-2" // 원하는 AWS 리전으로 설정
  // profile = "default" // AWS configure에서 설정한 프로필 이름 (선택 사항)
}

이제 Terraform을 초기화하여 프로바이더 플러그인을 다운로드합니다.

terraform init

이 명령어를 실행하면 Terraform이 AWS 프로바이더를 다운로드하고, 필요한 초기 설정 파일을 생성합니다. 이제 AWS 리소스를 Terraform 코드로 정의할 준비가 완료되었습니다.

AWS VPC 기본 인프라 구축: 네트워크 설계의 시작

클라우드 인프라 구축의 가장 첫 단계는 네트워크 설계입니다. AWS에서는 VPC(Virtual Private Cloud)를 통해 격리된 가상 네트워크 환경을 제공하며, 이는 모든 클라우드 리소스의 기반이 됩니다. 안전하고 효율적인 인프라를 위해 VPC 설계는 매우 중요합니다.

안전하고 확장 가능한 VPC 구조 설계

일반적으로 VPC는 다음과 같은 요소들을 포함하여 설계됩니다.

• CIDR 블록: VPC의 IP 주소 범위를 정의합니다 (예: 10.0.0.0/16).
• 서브넷 (Subnet): VPC 내에서 IP 주소 범위를 분할하여 리소스를 논리적으로 그룹화합니다. 보통 Public Subnet과 Private Subnet으로 나누어 사용합니다.
  • Public Subnet: 인터넷에 직접 연결되는 서브넷으로, 웹 서버나 로드 밸런서 등이 위치합니다.
  • Private Subnet: 인터넷에 직접 노출되지 않는 서브넷으로, 데이터베이스나 애플리케이션 서버 등이 위치합니다.
• 인터넷 게이트웨이 (Internet Gateway, IGW): VPC와 인터넷 간의 통신을 가능하게 합니다. Public Subnet에 연결됩니다.
• NAT 게이트웨이 (NAT Gateway): Private Subnet의 리소스가 인터넷으로 나갈 수 있도록 합니다. Public Subnet에 위치하며, Private Subnet의 라우팅 테이블에서 NAT 게이트웨이를 통해 인터넷으로 향하는 트래픽을 라우팅합니다.
• 라우팅 테이블 (Route Table): 서브넷 내 트래픽이 어디로 향할지 경로를 정의합니다.

VPC 및 서브넷 Terraform 코드 작성

이제 위에서 설명한 VPC 구성을 Terraform 코드로 작성해 보겠습니다. vpc.tf 파일을 생성하여 다음 내용을 추가합니다.

// vpc.tf

// 1. VPC 생성
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "main-vpc"
  }
}

// 2. 인터넷 게이트웨이 생성
resource "aws_internet_gateway" "main_igw" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "main-igw"
  }
}

// 3. Public Subnet 생성 (예: 2개의 가용 영역)
resource "aws_subnet" "public_subnet_a" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-northeast-2a" // 사용 가능한 가용 영역으로 변경
  map_public_ip_on_launch = true // Public IP 자동 할당
  tags = {
    Name = "public-subnet-a"
  }
}

resource "aws_subnet" "public_subnet_b" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.2.0/24"
  availability_zone       = "ap-northeast-2b" // 사용 가능한 가용 영역으로 변경
  map_public_ip_on_launch = true
  tags = {
    Name = "public-subnet-b"
  }
}

// 4. Private Subnet 생성 (예: 2개의 가용 영역)
resource "aws_subnet" "private_subnet_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.11.0/24"
  availability_zone = "ap-northeast-2a"
  tags = {
    Name = "private-subnet-a"
  }
}

resource "aws_subnet" "private_subnet_b" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.12.0/24"
  availability_zone = "ap-northeast-2b"
  tags = {
    Name = "private-subnet-b"
  }
}

// 5. Public Route Table 생성 및 IGW 연결
resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0" // 모든 외부 트래픽
    gateway_id = aws_internet_gateway.main_igw.id
  }
  tags = {
    Name = "public-route-table"
  }
}

// 6. Public Subnet과 Public Route Table 연결
resource "aws_route_table_association" "public_a_association" {
  subnet_id      = aws_subnet.public_subnet_a.id
  route_table_id = aws_route_table.public_rt.id
}

resource "aws_route_table_association" "public_b_association" {
  subnet_id      = aws_subnet.public_subnet_b.id
  route_table_id = aws_route_table.public_rt.id
}

// 7. NAT Gateway 생성 (Public Subnet에 위치)
// EIP가 필요하므로 먼저 생성합니다.
resource "aws_eip" "nat_gateway_eip_a" {
  vpc        = true
  depends_on = [aws_internet_gateway.main_igw] // IGW가 먼저 생성되어야 함
  tags = {
    Name = "nat-gateway-eip-a"
  }
}

resource "aws_nat_gateway" "main_nat_gateway_a" {
  allocation_id = aws_eip.nat_gateway_eip_a.id
  subnet_id     = aws_subnet.public_subnet_a.id
  tags = {
    Name = "main-nat-gateway-a"
  }
}

// 8. Private Route Table 생성 및 NAT Gateway 연결
resource "aws_route_table" "private_rt_a" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main_nat_gateway_a.id
  }
  tags = {
    Name = "private-route-table-a"
  }
}

// 9. Private Subnet과 Private Route Table 연결
resource "aws_route_table_association" "private_a_association" {
  subnet_id      = aws_subnet.private_subnet_a.id
  route_table_id = aws_route_table.private_rt_a.id
}

// 필요한 경우, 두 번째 Private Subnet (private_subnet_b)도 NAT Gateway를 통해 인터넷에 접근하려면,
// 두 번째 EIP와 NAT Gateway를 생성하고 해당 Private Subnet의 라우팅 테이블과 연결해야 합니다.
// 여기서는 예시를 위해 하나의 NAT Gateway만 보여줍니다.

코드를 작성한 후, 다음 명령어로 계획을 확인하고 적용합니다.

terraform plan // 어떤 변경 사항이 적용될지 미리 확인
terraform apply // 실제 인프라 구축 시작

terraform apply 명령어를 실행하면, Terraform은 위 코드에 정의된 대로 VPC, 서브넷, 인터넷 게이트웨이, 라우팅 테이블, NAT 게이트웨이 등의 AWS 리소스를 자동으로 생성합니다. 이제 애플리케이션을 배포할 준비가 된 안전한 네트워크 환경이 구축되었습니다.

Image by onkelglocke on Pixabay

EC2 인스턴스 프로비저닝: 애플리케이션 서버 준비

네트워크 환경이 준비되었다면, 이제 애플리케이션을 실행할 서버를 프로비저닝할 차례입니다. AWS EC2(Elastic Compute Cloud)는 클라우드에서 확장 가능한 컴퓨팅 용량을 제공하는 핵심 서비스입니다.

EC2 인스턴스 유형과 보안 그룹 설정

• 인스턴스 유형 (Instance Type): CPU, 메모리, 스토리지, 네트워크 성능 등 인스턴스의 하드웨어 사양을 정의합니다 (예: t3.micro, m5.large). 애플리케이션의 요구사항에 맞춰 적절한 유형을 선택해야 합니다.
• AMI (Amazon Machine Image): 인스턴스를 시작하는 데 필요한 운영체제, 애플리케이션 서버, 애플리케이션 등을 포함하는 템플릿입니다.
• 보안 그룹 (Security Group): 인스턴스에 대한 네트워크 트래픽을 제어하는 가상 방화벽입니다. 인바운드(Inbound) 및 아웃바운드(Outbound) 규칙을 정의하여 어떤 포트와 IP 주소에서 접근을 허용할지 지정합니다.
• 키 페어 (Key Pair): EC2 인스턴스에 SSH로 접속하기 위한 암호화 키입니다. Public Key는 AWS에 등록하고, Private Key는 로컬에 보관합니다.

EC2 Terraform 모듈 구성 및 배포

ec2.tf 파일을 생성하여 EC2 인스턴스 및 관련 리소스를 정의해 보겠습니다. 여기서는 간단한 웹 서버 인스턴스를 Public Subnet에 배포하고 SSH(22번) 및 HTTP(80번) 포트를 허용하는 보안 그룹을 설정합니다.

// ec2.tf

// 1. EC2 인스턴스 접속을 위한 키 페어
resource "aws_key_pair" "web_key" {
  key_name   = "web-server-key" // 원하는 키 페어 이름
  public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ..." // 여러분의 SSH Public Key
}

// 2. EC2 보안 그룹 생성 (HTTP 및 SSH 허용)
resource "aws_security_group" "web_sg" {
  name        = "web-server-security-group"
  description = "Allow HTTP and SSH inbound traffic"
  vpc_id      = aws_vpc.main.id

  // 인바운드 규칙: SSH (22)
  ingress {
    description = "Allow SSH from anywhere"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] // 실제 환경에서는 특정 IP로 제한하는 것이 좋습니다.
  }

  // 인바운드 규칙: HTTP (80)
  ingress {
    description = "Allow HTTP from anywhere"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  // 아웃바운드 규칙: 모든 트래픽 허용
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-sg"
  }
}

// 3. EC2 인스턴스 생성
resource "aws_instance" "web_server" {
  ami             = "ami-0abcdef1234567890" // 사용하려는 리전의 Amazon Linux 2 또는 Ubuntu AMI ID로 변경
  instance_type   = "t3.micro"
  subnet_id       = aws_subnet.public_subnet_a.id // Public Subnet에 배포
  security_groups = [aws_security_group.web_sg.id]
  key_name        = aws_key_pair.web_key.key_name
  associate_public_ip_address = true // Public IP 자동 할당

  // 인스턴스 시작 시 실행될 스크립트 (Apache 웹 서버 설치 예시)
  user_data = <<-EOF
              #!/bin/bash
              yum update -y
              yum install -y httpd
              systemctl start httpd
              systemctl enable httpd
              echo "Hello from Terraform EC2!" > /var/www/html/index.html
              EOF

  tags = {
    Name = "web-server"
    Env  = "Dev"
  }
}

// EC2 인스턴스의 Public IP 주소 출력 (확인용)
output "web_server_public_ip" {
  description = "The public IP address of the web server"
  value       = aws_instance.web_server.public_ip
}

ami-0abcdef1234567890 부분은 실제 사용하려는 AMI ID로 변경해야 합니다. AWS 콘솔에서 해당 리전의 "Amazon Linux 2" 또는 "Ubuntu Server" AMI ID를 찾아서 사용하세요. public_key도 여러분의 SSH Public Key로 대체해야 합니다.

마찬가지로 terraform plan과 terraform apply를 실행하여 EC2 인스턴스를 프로비저닝합니다. 배포가 완료되면 web_server_public_ip 출력 값을 통해 웹 서버의 공인 IP를 확인할 수 있으며, 해당 IP로 접속하여 "Hello from Terraform EC2!" 메시지를 볼 수 있습니다.

RDS 데이터베이스 배포: 안정적인 데이터 계층 확보

애플리케이션의 핵심인 데이터는 안정적이고 관리하기 쉬운 환경에 저장되어야 합니다. AWS RDS(Relational Database Service)는 관계형 데이터베이스를 클라우드에서 손쉽게 설정, 운영 및 확장할 수 있도록 돕는 관리형 서비스입니다.

RDS 인스턴스 설정과 파라미터 그룹

RDS를 사용할 때 고려해야 할 주요 사항들입니다.

• 데이터베이스 엔진: MySQL, PostgreSQL, Oracle, SQL Server 등 다양한 엔진을 선택할 수 있습니다.
• 인스턴스 유형: EC2와 마찬가지로 데이터베이스 서버의 사양을 정의합니다.
• 멀티 AZ (Multi-AZ): 고가용성을 위해 다른 가용 영역에 대기 인스턴스를 자동으로 프로비저닝하여 장애 발생 시 신속하게 전환됩니다.
• 서브넷 그룹 (DB Subnet Group): RDS 인스턴스가 위치할 서브넷 집합을 정의합니다. Private Subnet에 배치하여 인터넷으로부터 직접적인 접근을 차단하는 것이 보안 모범 사례입니다.
• 파라미터 그룹 (Parameter Group): 데이터베이스 엔진의 런타임 설정을 세밀하게 제어할 수 있습니다 (예: max_connections, character_set).
• 보안 그룹: RDS 인스턴스에 대한 네트워크 접근을 제어합니다. 일반적으로 애플리케이션 서버의 보안 그룹에서만 DB 포트 접근을 허용합니다.

RDS Terraform 코드 작성 및 데이터베이스 연결

rds.tf 파일을 생성하여 PostgreSQL RDS 인스턴스를 Private Subnet에 배포해 보겠습니다. 데이터베이스는 애플리케이션 서버(EC2)에서만 접근 가능하도록 보안 그룹을 설정합니다.

// rds.tf

// 1. RDS DB Subnet Group 생성
// Private Subnet들을 포함하여 DB 인스턴스가 여러 가용 영역에 걸쳐 배포될 수 있도록 합니다.
resource "aws_db_subnet_group" "main_db_subnet_group" {
  name       = "main-db-subnet-group"
  subnet_ids = [aws_subnet.private_subnet_a.id, aws_subnet.private_subnet_b.id]
  tags = {
    Name = "main-db-subnet-group"
  }
}

// 2. RDS 보안 그룹 생성 (EC2 인스턴스에서만 접근 허용)
resource "aws_security_group" "rds_sg" {
  name        = "rds-security-group"
  description = "Allow inbound traffic from web servers"
  vpc_id      = aws_vpc.main.id

  // 인바운드 규칙: EC2 웹 서버의 보안 그룹에서 DB 포트 (PostgreSQL 기본 5432) 허용
  ingress {
    description     = "Allow DB access from web server SG"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.web_sg.id] // EC2 인스턴스의 보안 그룹 ID
  }

  // 아웃바운드 규칙: 모든 트래픽 허용
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "rds-sg"
  }
}

// 3. RDS 인스턴스 생성 (PostgreSQL)
resource "aws_db_instance" "main_db" {
  allocated_storage    = 20
  storage_type         = "gp2"
  engine               = "postgres"
  engine_version       = "13.7" // 원하는 엔진 버전
  instance_class       = "db.t3.micro"
  name                 = "mydb" // 데이터베이스 이름
  username             = "admin"
  password             = "MyStrongPassword123" // 강력한 비밀번호 설정
  port                 = 5432
  db_subnet_group_name = aws_db_subnet_group.main_db_subnet_group.name
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  skip_final_snapshot  = true // 삭제 시 최종 스냅샷 건너뛰기 (운영 환경에서는 false 권장)
  multi_az             = false // 고가용성을 위해 true로 설정 가능 (비용 증가)
  publicly_accessible  = false // Private Subnet에 있으므로 Public 접근 비활성화

  tags = {
    Name = "main-rds-instance"
    Env  = "Dev"
  }
}

// RDS 엔드포인트 출력 (애플리케이션에서 DB 연결 시 사용)
output "rds_endpoint" {
  description = "The endpoint of the RDS instance"
  value       = aws_db_instance.main_db.address
}

// RDS 포트 출력
output "rds_port" {
  description = "The port of the RDS instance"
  value       = aws_db_instance.main_db.port
}

password는 반드시 강력하고 복잡한 비밀번호로 변경해야 하며, 운영 환경에서는 AWS Secrets Manager와 같은 서비스를 활용하여 민감 정보를 관리하는 것이 좋습니다. 또한 multi_az = true로 설정하면 고가용성을 확보할 수 있지만, 비용이 증가하므로 필요에 따라 선택하세요.

마지막으로 terraform plan 및 terraform apply를 실행하여 RDS 인스턴스를 배포합니다. 배포가 완료되면 rds_endpoint 출력 값을 통해 데이터베이스에 접속할 수 있는 호스트 주소를 확인할 수 있습니다. 이제 애플리케이션 서버에서 이 엔드포인트를 사용하여 데이터베이스에 연결할 수 있습니다.

Image by jplenio on Pixabay

Terraform으로 인프라 관리: 변경, 파괴, 모듈화

Terraform은 단순한 인프라 구축을 넘어, 인프라의 생명주기 전반을 관리하는 데 강력한 도구입니다. 인프라 변경, 파괴, 그리고 효율적인 관리를 위한 모듈화에 대해 알아보겠습니다.

인프라 변경 및 삭제 워크플로우

Terraform으로 인프라를 변경하거나 삭제하는 과정은 다음과 같습니다.

• 변경 (Update): 인프라 코드(.tf 파일)를 수정한 후, 다시 terraform plan과 terraform apply를 실행하면 Terraform이 현재 인프라 상태와 코드에 정의된 상태를 비교하여 필요한 변경 사항만 적용합니다. 예를 들어, EC2 인스턴스 타입을 t3.micro에서 t3.medium으로 변경하면, Terraform은 기존 인스턴스를 파괴하고 새로 생성하거나, 인스턴스를 중지하고 타입을 변경하는 등 최적의 방법을 찾아 적용합니다.
• 파괴 (Destroy): 더 이상 필요 없는 인프라를 제거하려면 terraform destroy 명령어를 사용합니다. 이 명령어는 Terraform이 관리하는 모든 리소스를 안전하게 삭제합니다.

  
  terraform destroy
  

  이 명령어는 매우 강력하므로, 운영 환경에서는 신중하게 사용해야 합니다. 특정 리소스만 삭제하고 싶다면, 코드에서 해당 리소스를 제거하고 terraform apply를 실행하거나, -target 옵션을 사용할 수 있지만, 일반적으로 코드에서 리소스를 제거하고 apply하는 방식이 권장됩니다.
• Terraform State 파일: Terraform은 terraform.tfstate라는 파일을 통해 현재 인프라의 실제 상태를 추적합니다. 이 파일은 Terraform이 인프라를 관리하는 데 필수적이므로, 절대로 수동으로 수정하거나 삭제해서는 안 됩니다. 팀 환경에서는 이 State 파일을 S3와 같은 원격 백엔드에 저장하고 DynamoDB로 잠금(Locking)을 설정하여 동시성 문제를 방지하는 것이 중요합니다.

Terraform 모듈을 활용한 효율적인 관리

인프라 코드가 복잡해지고 규모가 커지면, 모든 리소스를 하나의 파일에 관리하는 것은 비효율적입니다. 이때 Terraform 모듈(Module)을 활용하면 코드를 재사용 가능한 단위로 분리하고 관리할 수 있습니다.

• 모듈의 장점:
  • 코드 재사용성: VPC, EC2, RDS 등 자주 사용하는 인프라 패턴을 모듈로 만들어 여러 프로젝트에서 재사용할 수 있습니다.
  • 코드 구성의 간결성: 복잡한 인프라를 논리적인 단위로 캡슐화하여 코드의 가독성을 높입니다.
  • 팀 협업 용이성: 각 팀원이 특정 모듈에 집중하여 작업할 수 있어 협업 효율을 높입니다.
• 모듈 사용 예시:예를 들어, 위에서 작성한 VPC 코드를 modules/vpc 디렉토리 안에 넣고, 다른 프로젝트에서 다음과 같이 호출할 수 있습니다.모듈을 사용하면 인프라 구조가 훨씬 명확해지고, 대규모 프로젝트에서 효율적인 관리가 가능해집니다.
• // main.tf (프로젝트 루트) module "network" { source = "./modules/vpc" // 로컬 모듈 경로 // 필요한 변수들을 여기에 전달 vpc_cidr_block = "10.0.0.0/16" public_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24"] private_subnet_cidrs = ["10.0.11.0/24", "10.0.12.0/24"] azs = ["ap-northeast-2a", "ap-northeast-2b"] } // modules/vpc/main.tf (모듈 내부) resource "aws_vpc" "main" { cidr_block = var.vpc_cidr_block // ... 나머지 VPC 리소스 정의 ... } variable "vpc_cidr_block" { description = "CIDR block for the VPC" type = string } // ... 다른 변수 정의 ...

결론: Terraform으로 생산성을 극대화하세요

지금까지 Terraform을 활용하여 AWS 클라우드 인프라의 핵심 요소인 VPC, EC2, RDS를 자동으로 프로비저닝하는 실전 과정을 살펴보았습니다. 수동 인프라 관리의 한계와 비효율성을 극복하고, IaC (Infrastructure as Code)의 원칙에 따라 인프라를 코드로 정의함으로써 얻을 수 있는 수많은 이점들을 확인했습니다.

Terraform을 도입하면 인프라 구축 및 변경에 드는 시간을 획기적으로 줄일 수 있으며, 휴먼 에러를 최소화하고 환경 간의 일관성을 보장할 수 있습니다. 이는 곧 개발 팀의 생산성 향상과 안정적인 서비스 운영으로 이어집니다. 또한, 인프라 코드를 버전 관리하여 변경 이력을 투명하게 관리하고, 모듈화를 통해 코드 재사용성을 높여 복잡한 인프라를 효율적으로 관리할 수 있습니다.

이 가이드는 Terraform과 AWS를 활용한 인프라 자동화의 시작점입니다. 여기서 다룬 내용들을 바탕으로 더욱 복잡한 아키텍처를 구축하고, CI/CD 파이프라인과 연동하여 완전한 DevOps 워크플로우를 구현해 보세요. Terraform은 여러분의 클라우드 여정을 더욱 빠르고 안정적으로 만들어 줄 것입니다.

Terraform을 사용하면서 겪었던 특별한 경험이나, 더 효율적인 인프라 관리 팁이 있다면 댓글로 공유해 주세요. 여러분의 지식이 다른 개발자들에게 큰 도움이 될 것입니다!

📌 함께 읽으면 좋은 글

• [클라우드 인프라] AWS Lambda, API Gateway로 서버리스 백엔드 구축: 운영 전략부터 비용 최적화까지
• [클라우드 인프라] 클라우드 비용 최적화: AWS, Azure, GCP 멀티 클라우드 절감 전략 심층 분석
• [클라우드 인프라] Terraform으로 클라우드 인프라 코드화: AWS/GCP/Azure 멀티 클라우드 관리 전략

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.