오늘은 AWS RDS를 다른 계정으로 이전하는 작업을 했다.
기존에 팀에서 쓰던 동아리 홈페이지 AWS 계정의 설정을, 학교와 연결된 회사의 계정으로 옮겨야 하는 상황이라
백엔드 팀원들과 역할을 나누어서 하나씩 회사 계정으로 마이그레이션을 해보기로 했다.
우선 마이그레이션이란 무엇일까?
말 그대로 '이주', '이동'을 뜻한다.
조금 더 설명을 보충하기 위해 레드햇에서 정의를 찾아왔다.
IT 마이그레이션은 데이터나 소프트웨어를 한 시스템에서 다른 시스템으로 이동하는 것입니다. IT 마이그레이션은 프로젝트에 따라 데이터 마이그레이션, 애플리케이션 마이그레이션, 운영 체제 마이그레이션, 클라우드 마이그레이션 등 한 가지 이상의 이동이 진행될 수 있습니다.
IT 마이그레이션의 일반적인 몇 가지 예시는 다음과 같습니다.
- 애플리케이션 또는 운영 체제(OS) 업그레이드
- 데이터를 한 종류의 데이터베이스에서 다른 종류의 데이터베이스로 이동
- 하나의 데이터 스토리지 시스템을 다른 데이터 스토리지 시스템으로 교체
- 온프레미스 인프라에서 클라우드 인프라로 이동모놀리식 애플리케이션을 컨테이너화된 서비스로 교체
- 일반적으로 IT 마이그레이션 프로젝트에는 조직의 요구 사항에 고도로 특화된 구동 부품 및 요구 사항이 다수 포함되어 있습니다.
인프라 자동화 전략을 반영해 면밀하게 계획을 세우면 IT 마이그레이션이 더 수월해질 수 있습니다.
출처: RedHat
생각보다 마이그레이션의 범위가 넓어서 놀랐고, (특히 OS 업그레이드도 마이그레이션에 속한다는 점!)
우리 팀은 AWS에 모든 인프라가 있어서 이것들을 들어서 다른 AWS로 모두 옮겨야 하는 상황!
📝 TO-DO : 옮겨야 할 것
- RDS
- EC2 (2개)
- S3
- ALB
- Route53
- ACM
RDS, EC2, S3는 백엔드 팀원 셋이 나눠서 하기로 했고, 나머지 설정은 중요할 것 같아서 다같이 모여서 해보기로 했다. 🥺
백엔드 팀원이 있어서 정말 정말 다행이고 행복하다...
🎯 이전 목표
소스 계정 (A): 현재 운영 중인 암호화된 RDS 인스턴스가 있음.대상 계정 (B): 아무 설정이 없는 초기 상태의 AWS 계정.
최종 목표: 소스 계정(A)의 RDS 데이터를 대상 계정(B)으로 안전하게 이전(복제)한다.
지금부터 소스 계정 (A, 기존에 팀에서 사용하던 계정), 대상계정 (B, 아무 설정이 없는 초기 상태의 계정)이라고 설명하겠다.
원래는 단순히 스냅샷을 만들고, 대상 계정에 공유하고, 복원을 하면 된다.
하지만 RDS가 aws/rds(AWS 관리형 키)로 암호화되어 있었고,
마이그레이션을 진행하는 특수한 경우가 아니라면 학생 입장에서 이런 부분까지 알기는 어려웠을 것 같다.
AWS 관리형 키는 아무리 소스 계정(A)이더라도 직접 정책을 편집할 수가 없다.
정책 편집이 불가능하기 때문에 대상 계정(B)로 키를 사용하도록 공유할 방법이 없다.
따라서 B 계정은 A의 aws/rds로 잠긴 스냅샷을 복호화할 수 없기 때문에
`Restoring... cross account... encrypted snapshot is not supported`라는 오류를 마주하게 된다.
하지만 방법이 없는 것은 아니다.
RDS가 암호화된 경우에서, 새로운 AWS 계정으로 마이그레이션하는 방법을 설명해보겠다!
1단계: 대상계정(B) 에 새 집 준비하기 (VPC)
1. VPC 생성: RDS가 위치할 격리된 네트워크 (VPC)를 생성한다.
2. 서브넷 생성: ⚠️고가용성을 위해 최소 2개의 다른 가용 영역 (AZ)에 프라이빗 서브넷을 생성해야 한다.
위에서 'VPC 등'을 선택하면, 라우팅 테이블 등을 자동으로 생성해줘서 편리하다. 만약에 커스텀 설정이 필요하다면 우선 'VPC만'을 선택하면 된다.
완료가 되면 다음으로 넘어간다.
3. DB 서브넷 그룹 생성: 위에서 만든 2개의 서브넷을 묶어 RDS가 사용할 'DB 서브넷 그룹'을 생성한다.
RDS -> 왼쪽 메뉴의 '서브넷 그룹' > DB 서브넷 그룹 생성으로 접속한다.
서브넷 그룹의 이름을 입력하고, 방금 생성한 새 VPC를 선택해준다.
그리고 서브넷 추가 섹션에서는 위에서 생성했던 2개 이상의 서브넷을 모두 선택해 추가한다.
2단계: 소스 계정 (A) 데이터 포장 및 키 공유
이제 원본 RDS가 있는 A로 돌아오자.
데이터를 📦 이삿짐으로 만들어줄 것이다.
1. 🔐 고객 관리형 키 (CMK) 생성
KMS(Key MagementService)를 검색하고 이동한다. 그리고 CMK를 새로 생성해준다.
이때, '키 사용 권한' 단계에서 B의 ID를 추가해야 한다.
계정 ID는 프로필 오른쪽 위에서 확인할 수 있다.
여기에서 KMS에 대해 잠깐 짚고 가자면 아래와 같이 3가지 유형이 있다.
출처: AWS
위와 같이 AWS 관리형 키는 사용자가 관리를 할 수가 없다.
고객 관리형 키는 제어는 가능하지만 월별 요금이 나가기 때문에 마지막에 꼭 삭제해주는 것이 좋다.
2. 수동 스냅샷 생성
이전할 DB의 '수동 스냅샷'을 생성해야 한다.
그리고 이 스냅샷은 원본 DB의 키인 aws/rds로 자동 암호화된다.
3. 스탭샷 복사
원본 스냅샷이 생성되면, 선택하고 작업 > 스냅샷 복사
'암호화 활성화'를 체크하고, 위에서 생성했던 KMS 키를 선택한다.
여기에서는 aws/rds 키로 잠긴 데이터를 풀어서, 우리가 만든 CMK로 다시 잠그는 재암호화 작업이다.
4. 스냅샷 공유
방금 만든 새 스냅샷 > 작업 > 스냅샷 공유
이전에 했던대로 B의 ID를 추가해준다.
3단계: 대상 계정 (B) - 데이터 설치 (복사 후 복원)
1. 공유 스냅샷 복사
B에서 RDS > 스냅샷 > 공유된 스냅샷 탭으로 이동한다.
'복원'이 아닌 '작업' > 스냅샷 복사를 클릭한다.
암호화 활성화를 체크하고, KMS는 B키 아무거나 선택해도 된다.
즉 위에서 만들어준 것처럼 내 키를 만들어도 된다는 뜻이다.
하지만 AWS 관리형 키는 비용이 나가지 않기 때문에 aws/rds키를 선택하는 것을 추천!!
여기에서는 A의 CMK로 잠긴 데이터를 풀어서 다시 B로 잠그는 작업을 한다.
2. 로컬 스냅샷 복원
복사가 완료되면 이 스냅샷을 선택하고, 작업 > 스냅샷 복원을 클릭한다.
여기에서는 처음에 만들었던 vpc와 subnet group을 선택해준다.
데이터베이스 생성을 클릭하여 복원을 완료하면 끝!
😎 그럼 이게 어떻게 가능한 것이고, 왜 문제가 생겼던 걸까?
암호화된 스냅샷 = 잠긴 금고
KMS 키 = 금고 열쇠가 된다.
처음에는 금고가 aws/rds라는 키로 잠겨있었다.
이 키는 AWS가 직접 관리하는 건물 마스터키이기 때문에,
A 계정의 주인이더라도 B 한테 함부로 넘길 수 없다.
그래서 공유 가능한 나만의 개인 열쇠(CMK)를 A 계정에 만든다.
aws/rds로 잠긴 금고에서 데이터를 꺼내, 우리가 만든 CMK로 새 금고를 만든다.
이것이 '스냅샷 복사'작업이다.
CMK는 A의 소유이므로 B에게 열쇠를 쓸 수 있게 허락할 수 있다.
하지만 B가 이 금고를 복원하더라도, 여전히 A계정 소유의 열쇠로 잠겨있다.
즉, 사용허가만 받았을 뿐이지 소유권을 가진 건 아니다.
그래서 B 계정 소유의 열쇠로 암호화를 해준 것이다.
이것이 B 계정에서 했던 두 번째 '스냅샷 복사'작업이다.
이제 완전히 B가 소유한 금고를 가지게 된다.
마지막으로.. 만들었던 KMS를 꼭 !! 삭제하자.
매월 1달러정도 요금이 부과된다.
최소 7일의 유예 기간 후에 영구히 삭제되니 돈 없는 학생은 미리미리 지워서 과금을 방지하자.
내가 마이그레이션을 하는 동안,
다른 백엔드 팀원들이 S3, EC2를 마이그레이션 해주었다.
다음에는 다같이 보여서 Route53과 ALB를 마이그레이션하고,
남은 세세한 작업들(제일 귀찮음)을 해보려고 한다!
'인프라 > AWS' 카테고리의 다른 글
| 2주안에 AWS SAA + DVA 뽀개기 (0) | 2026.03.27 |
|---|---|
| [RDBMS와 NoSQL의 추구미] 돌고 도는 트레이드 오프 (0) | 2026.03.24 |
| AWS Athena 쿼리 성능 최적화하기 (1) | 2026.03.16 |
| Auto Scaling with NLB (Network Load Balancer) (0) | 2025.06.03 |