RDS 스냅샷 복원 완벽 가이드: 기존 인스턴스 덮어쓰기 vs 새 엔드포인트 생성

RDS 스냅샷 복원을 처음 시도하는 엔지니어들이 가장 많이 하는 실수가 있다. '복원하면 기존 DB가 덮어써지겠지'라고 가정하고 애플리케이션 설정을 그대로 두는 것이다. 실제로는 RDS 스냅샷 복원은 항상 새로운 DB 인스턴스를 생성하며, 엔드포인트도 완전히 달라진다. 이 동작을 모르면 복원 후 애플리케이션이 여전히 구 인스턴스(또는 없는 인스턴스)에 연결을 시도하는 상황이 발생한다.

TL;DR — RDS 스냅샷 복원 핵심 요약

항목	동작
기존 인스턴스 덮어쓰기 여부	❌ 덮어쓰지 않음. 항상 신규 인스턴스 생성
엔드포인트 변경 여부	✅ 새 인스턴스 식별자 기반의 새 엔드포인트 생성
기존 인스턴스 상태	복원 후에도 기존 인스턴스는 그대로 유지됨
파라미터 그룹 / 보안 그룹	기본값으로 초기화됨 — 수동 재적용 필요
애플리케이션 연결 문자열	새 엔드포인트로 업데이트 필요
Multi-AZ / 스토리지 설정	스냅샷에서 복원되지 않음 — 복원 시 재지정 필요

RDS 스냅샷 복원 동작 원리

RDS 스냅샷은 특정 시점의 스토리지 볼륨 전체를 캡처한 것이다. 복원 명령을 실행하면 AWS는 해당 스냅샷 데이터를 기반으로 완전히 독립된 새 DB 인스턴스를 프로비저닝한다. 기존 인스턴스의 데이터를 교체하거나 덮어쓰는 개념이 아니다.

새 인스턴스는 복원 시 지정한 --db-instance-identifier 값을 기반으로 고유한 DNS 엔드포인트를 갖는다. 기존 인스턴스와 신규 인스턴스는 복원 직후 동시에 존재하며, 각자 독립적인 엔드포인트를 가진다.

graph TD A["RDS 원본 인스턴스
my-production-db"] -->|"자동/수동 스냅샷 생성"| B["DB 스냅샷
rds:my-production-db-2024-01-15"] B -->|"restore-db-instance-from-db-snapshot"| C["신규 RDS 인스턴스
my-restored-db"] A -->|"복원 후에도 유지"| D["기존 인스턴스 계속 실행 중"] C --> E["새 엔드포인트
my-restored-db.xxxx.rds.amazonaws.com"] A --> F["기존 엔드포인트
my-production-db.xxxx.rds.amazonaws.com"] style C fill:#2e7d32,color:#fff style E fill:#1565c0,color:#fff style D fill:#e65100,color:#fff

스냅샷 트리거: 수동 또는 자동 스냅샷이 S3 기반 내부 스토리지에 저장된다.
복원 요청: restore-db-instance-from-db-snapshot API 호출 시 새 인스턴스 식별자를 지정한다.
신규 인스턴스 프로비저닝: AWS가 새 컴퓨팅 및 스토리지를 할당하고 스냅샷 데이터를 복사한다.
기존 인스턴스 유지: 원본 인스턴스는 영향받지 않고 그대로 실행 중이다.
엔드포인트 분리: 두 인스턴스는 서로 다른 DNS 엔드포인트를 가진다.

RDS 스냅샷 복원 단계별 실행 가이드

1단계: 사용 가능한 스냅샷 확인

복원 전에 어떤 스냅샷이 존재하는지, 그리고 스냅샷 상태가 available인지 확인한다. 상태가 creating이거나 failed인 스냅샷으로는 복원할 수 없다.

aws rds describe-db-snapshots \
  --db-instance-identifier my-production-db \
  --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier,Status:Status,Time:SnapshotCreateTime}' \
  --output table

2단계: 스냅샷에서 새 인스턴스 복원

핵심 파라미터는 --db-snapshot-identifier(원본 스냅샷)와 --db-instance-identifier(새로 생성될 인스턴스 이름)다. 두 값이 다르다는 점이 '덮어쓰기가 아님'을 명확히 보여준다. 파라미터 그룹과 보안 그룹은 스냅샷에서 복원되지 않으므로 이 단계에서 명시적으로 지정해야 한다.

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-restored-db \
  --db-snapshot-identifier rds:my-production-db-2024-01-15-00-00 \
  --db-instance-class db.t3.medium \
  --db-subnet-group-name my-db-subnet-group \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-parameter-group-name my-custom-parameter-group \
  --no-multi-az \
  --publicly-accessible false

3단계: 복원 완료 대기 및 상태 확인

복원 명령 직후 인스턴스 상태는 creating이다. available 상태가 될 때까지 기다려야 연결이 가능하다. 인스턴스 크기와 스냅샷 크기에 따라 수 분에서 수십 분이 소요될 수 있다.

aws rds wait db-instance-available \
  --db-instance-identifier my-restored-db

4단계: 새 엔드포인트 확인

복원이 완료되면 새 인스턴스의 엔드포인트를 확인한다. 이 값이 애플리케이션 연결 문자열에 업데이트해야 할 주소다.

aws rds describe-db-instances \
  --db-instance-identifier my-restored-db \
  --query 'DBInstances[0].Endpoint.{Address:Address,Port:Port}' \
  --output json

5단계: 파라미터 그룹 변경 사항 적용 확인

커스텀 파라미터 그룹을 지정했더라도 일부 파라미터는 재시작이 필요한 pending-reboot 상태일 수 있다. 복원 직후 파라미터 적용 상태를 반드시 점검한다.

aws rds describe-db-instances \
  --db-instance-identifier my-restored-db \
  --query 'DBInstances[0].DBParameterGroups'

sequenceDiagram participant Eng as 엔지니어 participant CLI as AWS CLI participant RDS as RDS 서비스 participant App as 애플리케이션 Eng->>CLI: restore-db-instance-from-db-snapshot CLI->>RDS: 신규 인스턴스 프로비저닝 요청 RDS-->>CLI: 상태: creating Eng->>CLI: rds wait db-instance-available RDS-->>CLI: 상태: available Eng->>CLI: describe-db-instances (엔드포인트 확인) CLI-->>Eng: 새 엔드포인트 반환 Eng->>App: 연결 문자열 업데이트 (새 엔드포인트) App->>RDS: 새 엔드포인트로 연결 성공

자주 발생하는 실수와 실제 원인 분석

증상: 복원 후 애플리케이션이 DB에 연결되지 않음

잘못된 가정: '복원했으니 기존 엔드포인트로 연결되겠지.'

실제 원인: 복원은 새 인스턴스를 만들고 새 엔드포인트를 생성한다. 기존 인스턴스가 삭제되지 않은 상태라면 애플리케이션은 여전히 구 인스턴스(또는 이미 삭제된 인스턴스)에 연결을 시도한다.

수정 방법: 4단계에서 확인한 새 엔드포인트로 애플리케이션의 DB 연결 문자열을 업데이트한다. Route 53 CNAME이나 AWS Secrets Manager를 활용하면 엔드포인트 교체를 애플리케이션 코드 변경 없이 처리할 수 있다.

증상: 복원된 DB의 성능이 원본과 다름

잘못된 가정: '스냅샷 복원이니까 원본과 동일한 설정이겠지.'

실제 원인: 복원 시 --db-instance-class를 명시하지 않으면 스냅샷 생성 당시의 인스턴스 클래스가 기본값으로 사용된다. 그러나 Multi-AZ, 스토리지 타입, IOPS 설정은 복원 명령에서 명시적으로 지정하지 않으면 기본값으로 초기화된다.

스냅샷 복원을 '사진을 그대로 붙여넣기'로 생각하면 틀린다. 데이터는 사진에서 가져오지만, 액자(인스턴스 설정)는 새로 구매해서 직접 맞춰야 한다.

증상: 복원 후 보안 그룹이 달라 외부에서 접근 불가

스냅샷 복원 시 보안 그룹을 명시하지 않으면 VPC 기본 보안 그룹이 적용된다. 운영 환경에서 커스텀 보안 그룹을 사용하고 있었다면 복원 명령에 --vpc-security-group-ids를 반드시 포함해야 한다.

Point-in-Time Recovery(PITR)와 스냅샷 복원의 차이

스냅샷 복원과 자주 혼동되는 기능이 PITR(Point-in-Time Recovery)다. 두 방식 모두 새 인스턴스를 생성한다는 점은 동일하지만, 복원 가능한 시점의 정밀도가 다르다.

항목	스냅샷 복원	PITR
복원 기준	특정 스냅샷 시점	최근 5분 이내 임의 시점
CLI 명령	restore-db-instance-from-db-snapshot	restore-db-instance-to-point-in-time
새 인스턴스 생성 여부	✅ 항상 새 인스턴스	✅ 항상 새 인스턴스
자동 백업 필요 여부	불필요	자동 백업 활성화 필수

PITR도 마찬가지로 기존 인스턴스를 덮어쓰지 않는다. 엔드포인트 교체 절차는 동일하게 적용된다.

엔드포인트 전환을 최소화하는 운영 패턴

복원 후 엔드포인트가 바뀌는 문제를 운영 레벨에서 완화하는 방법이 있다. 애플리케이션이 DB 엔드포인트를 하드코딩하지 않고 간접 참조를 사용하면 복원 후 연결 전환이 훨씬 단순해진다.

방법 1: Route 53 CNAME 활용

애플리케이션이 RDS 엔드포인트 직접 참조 대신 Route 53 CNAME(db.internal.example.com)을 사용하도록 구성한다. 복원 후 CNAME 레코드만 새 엔드포인트로 업데이트하면 애플리케이션 설정 변경 없이 전환된다.

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDEF \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "db.internal.example.com",
        "Type": "CNAME",
        "TTL": 60,
        "ResourceRecords": [{
          "Value": "my-restored-db.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com"
        }]
      }
    }]
  }'

방법 2: AWS Secrets Manager 활용

DB 연결 정보를 Secrets Manager에 저장하고 애플리케이션이 시크릿을 참조하도록 구성한다. 복원 후 시크릿 값만 업데이트하면 된다.

aws secretsmanager update-secret \
  --secret-id prod/myapp/db-credentials \
  --secret-string '{"host":"my-restored-db.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com","port":5432,"username":"admin","password":"your-password"}'

복원 후 필수 점검 체크리스트

복원 작업 자체는 단순하지만, 복원 후 운영 환경에서 실제로 동작하려면 여러 설정을 수동으로 재확인해야 한다. 아래 항목을 순서대로 점검한다.

✅ 새 엔드포인트 확인 및 애플리케이션 연결 문자열 업데이트
✅ 보안 그룹 — 운영 환경 규칙이 적용되어 있는지 확인
✅ 파라미터 그룹 — 커스텀 그룹 적용 및 pending-reboot 항목 없는지 확인
✅ 옵션 그룹 — 필요한 경우 재적용
✅ Multi-AZ 설정 — 운영 환경이라면 복원 후 활성화 여부 확인
✅ 자동 백업 보존 기간 — 기본값(1일)에서 운영 정책에 맞게 조정
✅ 암호화 설정 — 스냅샷이 암호화된 경우 KMS 키 접근 권한 확인
✅ 기존 인스턴스 처리 — 불필요한 경우 비용 절감을 위해 삭제 또는 중지

RDS 스냅샷 복원에 필요한 최소 IAM 권한

복원 작업을 수행하는 IAM 엔티티에는 다음 권한이 필요하다. 운영 환경에서는 특정 스냅샷 ARN과 인스턴스 ARN으로 범위를 제한하는 것이 권장된다.

🔽 IAM 정책 예시 펼치기

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeSnapshots",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBSnapshots",
        "rds:DescribeDBInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RestoreFromSnapshot",
      "Effect": "Allow",
      "Action": "rds:RestoreDBInstanceFromDBSnapshot",
      "Resource": [
        "arn:aws:rds:us-east-1:123456789012:snapshot:rds:my-production-db-2024-01-15-00-00",
        "arn:aws:rds:us-east-1:123456789012:db:my-restored-db"
      ]
    },
    {
      "Sid": "SubnetAndSecurityGroup",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBSubnetGroups"
      ],
      "Resource": "*"
    }
  ]
}

주의: DescribeDBSnapshots, DescribeDBInstances, DescribeDBSubnetGroups는 리소스 수준 권한을 지원하지 않아 "Resource": "*"가 필요하다. AWS Service Authorization Reference에서 각 액션의 리소스 수준 지원 여부를 반드시 확인한다.

RDS 스냅샷 복원 마무리 및 다음 단계

RDS 스냅샷 복원은 항상 새 인스턴스를 생성하며 기존 인스턴스를 덮어쓰지 않는다. 이 동작 원리를 이해하면 복원 후 엔드포인트 업데이트, 보안 그룹 재적용, 파라미터 그룹 확인이 왜 필수인지 자연스럽게 이해된다. Route 53 CNAME이나 Secrets Manager를 활용한 간접 참조 패턴을 미리 구성해두면 다음 복원 작업에서 다운타임을 크게 줄일 수 있다.

공식 문서에서 추가 파라미터와 제약 사항을 확인하려면 AWS RDS 스냅샷 복원 공식 문서를 참조한다.

핵심 용어 정리

용어	설명
DB 스냅샷	특정 시점의 RDS 인스턴스 스토리지 볼륨 전체를 캡처한 백업. 수동 또는 자동으로 생성된다.
DB 인스턴스 식별자	RDS 인스턴스를 고유하게 식별하는 이름. 엔드포인트 DNS 주소의 일부가 된다.
PITR (Point-in-Time Recovery)	자동 백업과 트랜잭션 로그를 활용해 특정 시각으로 DB를 복원하는 기능.
파라미터 그룹	DB 엔진 설정값 집합. 스냅샷 복원 시 기본 파라미터 그룹으로 초기화되므로 수동 재적용이 필요하다.
DB 서브넷 그룹	RDS 인스턴스가 배치될 VPC 서브넷 집합. 복원 시 명시적으로 지정해야 원하는 VPC에 생성된다.

이 블로그 검색

SW BBANG K