DMS 핵심 정리 — SAA-C03 DR·마이그레이션 한 번에

이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 12편입니다. 재해복구(DR)와 마이그레이션은 시험 도메인 이름에 따로 박혀 있지 않은데도, 막상 문제를 풀어 보면 운영·아키텍처 시나리오의 1/3 가까이가 이 영역에 걸쳐 있어요. 그 가운데서도 DB 마이그레이션의 본진인 DMS(Database Migration Service)는 거의 매 회차 한 문제 이상은 무조건 꽂힙니다. 거기에 시험 끝물에 우르르 나오는 기타 핵심 서비스들(CloudFormation·SES/Pinpoint·SSM·Cost Explorer·Outposts·AppFlow·Amplify·Batch·Instance Scheduler)까지 — 양은 가장 많은데 단원 이름은 정작 가장 흐릿한, 그런 영역입니다.

왜 이 단원이 처음엔 어렵게 느껴질까

이유는 단순해요. 추상도가 한 번에 두 단계 올라가기 때문입니다. 지금까지 우리는 EC2·RDS·VPC처럼 손에 잡히는 리소스를 다뤘는데, DR 단원은 갑자기 "인프라 전체가 죽었을 때" 라는 가정에서 출발해요. "DB 한 대가 다운"이 아니라 "리전 하나가 통째로 마비"라는 시나리오에서 시작하니까, 처음 들으면 와 닿질 않습니다. 게다가 마이그레이션 도구는 이름이 비슷한 게 너무 많아요 — DMS, SCT, DRS, MGN, Discovery Service, Migration Hub, VM Import/Export, VMware Cloud, DataSync, Transfer Family, Snow Family… 한 페이지에 다 적으면 구분이 안 갑니다.

그래서 이 글은 천천히 갑니다. DR을 "회사가 화재로 사옥을 잃었을 때 어떤 대비를 해 두느냐" 의 비유로 풀고, 마이그레이션 도구들은 "무엇을 옮기느냐(데이터·DB·서버·VM)" 와 "어떻게 옮기느냐(온라인·오프라인·에이전트·물리)" 의 두 축으로 분류해 둘게요. 마지막 기타 서비스는 한 줄짜리 "이름 ↔ 키워드" 매칭으로 끝납니다. 한 번에 다 외우려 하지 말고, 흐름과 "왜 이 서비스가 필요한가" 만 머리에 들어와도 충분합니다. 더 깊이 보려면 AWS 공식 DMS 사용자 가이드가 가장 신뢰할 만한 출발점이에요.

RPO와 RTO — DR의 두 축, "대체 사옥" 비유로

DR 이야기의 모든 시작은 두 단어입니다. 이름이 비슷해서 헷갈리는데, 회사 비유 하나면 평생 안 잊어요.

비유 — 회사 사옥에 화재가 났다고 합시다. 며칠 뒤 임시 사무실을 마련했다고 칠 때, 두 가지 질문이 자연스럽게 따라옵니다.

1. "자료가 어디까지 살아있는가?" — 화재 직전까지의 백업이 어제 거면 하루치 자료가 날아갑니다. 시간 전 거면 한 시간치만 날아가요. 이게 RPO.
2. "언제부터 다시 일할 수 있는가?" — 임시 사무실에 책상·전화·인터넷이 다 갖춰져서 직원이 출근해 일을 시작할 때까지 걸리는 시간. 이게 RTO.

정확히 풀면 이렇게 돼요.

• RPO (Recovery Point Objective) — "데이터 손실"을 얼마나 허용할 것인가. 백업 빈도와 직결됩니다. "1시간 전 시점으로 복구"라면 RPO 1시간.
• RTO (Recovery Time Objective) — "다운타임"을 얼마나 허용할 것인가. 재해 발생 후 시스템이 다시 살아날 때까지 걸리는 시간.

여기서 시험 함정이 하나 있어요. 둘 다 "작을수록 좋은 게 맞지만, 작아질수록 비용이 기하급수적으로 늘어납니다." RPO를 1시간에서 1초로 줄이려면 백업이 거의 실시간 복제로 바뀌어야 하고, RTO를 1시간에서 1분으로 줄이려면 인프라가 항상 켜져 있어야 해요. 그래서 시험에 "RPO·RTO를 무한히 줄이세요" 같은 이상적 보기는 없고, "비용 제약 하에서 가장 적합한 전략은?" 형식이 거의 100%입니다.

DR 4가지 전략 — 비용 ↑ / RTO ↓ 순서로

DR 전략은 정확히 네 가지로 분류됩니다. 비용이 낮을수록 RTO가 길고(느리고), 비용이 높을수록 RTO가 짧아져요(빠름). 한 번에 외우기 좋은 방향성이에요.

1. Backup & Restore — "자료만 챙겨놓기"

가장 단순하고 가장 저렴합니다. 데이터만 S3·Glacier 같은 곳에 백업해 두고, 재해가 나면 그때 인프라를 처음부터 다시 만들어 데이터를 복원하는 방식. EC2도 DB도 평소엔 없습니다. 인프라 자체가 백지 상태예요.

회사 비유로 — 화재 났을 때를 대비해 자료 백업본만 외부 창고에 보관해 두는 정도. 화재가 나면 새 사무실을 빌리고, 책상 들이고, 컴퓨터 사고, 백업본 가져와 깔고… 며칠은 걸려요. 비용은 가장 낮지만 복구에 수 시간~수 일이 걸립니다.

"비용은 정말 낮춰야 하는데 며칠 다운타임은 감수할 수 있다"는 시나리오의 답입니다.

2. Pilot Light — "DB만 항상 켜두기"

핵심 시스템(보통 DB)은 항상 켜둡니다. 하지만 앱 서버(EC2)는 꺼둔 상태예요. 재해가 나면 EC2를 빠르게 프로비저닝해서 이미 살아 있는 DB에 연결합니다.

이름 그대로 — 가스레인지의 파일럿(작은 종불) 만 항상 켜놓고, 큰 불은 필요할 때 빠르게 붙이는 식입니다. 회사 비유로는 임시 사무실에 전화선·인터넷만 미리 깔아 두는 정도. 책상이나 직원은 화재 나면 그때 들이는 거예요.

DB는 켜놓는 비용을 감수하지만, EC2 비용은 평소 안 들어요. RPO/RTO는 Backup & Restore보다 훨씬 낮고 비용은 중간 수준.

3. Warm Standby — "모든 게 다 켜져 있긴 한데 작게"

전체 시스템을 다 띄워는 두는데, 최소 규모로 축소된 상태로 운영합니다. EC2도 DB도 살아 있는데 트래픽을 거의 안 받는 상태죠. 재해 시 Auto Scaling으로 프로덕션 규모로 확장합니다.

회사 비유로 — 임시 사무실에 직원 두세 명이 항상 상주하면서 모든 시스템을 가동만 시켜놓는 식이에요. 화재 시 본진 직원들이 그쪽으로 옮겨오면 즉시 풀가동.

RPO/RTO는 매우 낮지만, 인프라가 줄곧 돌아가니 비용은 높아요.

4. Multi-Site / Hot Site — "양쪽 다 풀가동"

두 곳(또는 두 리전)에서 전체 프로덕션 규모를 동시에 운영합니다. Active-Active. Route 53으로 트래픽을 분산해서 평소에도 양쪽이 다 일을 해요. 재해가 나면 Route 53이 살아 있는 쪽으로만 트래픽을 몰아주는 식.

회사 비유로 — 두 도시에 똑같은 본사 두 개를 운영하는 거예요. 평소에도 절반 직원은 A 도시, 나머지는 B 도시에서 일하다가, 한쪽이 마비되면 다른 쪽이 100% 커버.

RPO/RTO가 거의 0이지만, 인프라가 두 배라 비용도 가장 높습니다.

Pilot Light vs Warm Standby의 결정적 차이

여기서 시험 함정이 하나 있어요. 이 둘이 가장 헷갈리는데, 핵심 구분점은 EC2 상태 단 하나입니다.

전략	EC2	DB
Pilot Light	꺼짐 (재해 시 프로비저닝)	항상 실행
Warm Standby	최소 규모 실행 중	항상 실행

Pilot Light는 EC2가 꺼져 있고, Warm Standby는 EC2도 (작게나마) 켜져 있어요. 이 한 줄로 시험에서 안 헷갈립니다.

DR을 위한 AWS 서비스들

각 전략 뒤에 깔리는 서비스 카탈로그도 시험에 종종 나옵니다. 이름만 한 번씩 본 다음 넘어가도 돼요.

• 백업/스토리지 — EBS·RDS 스냅샷, S3, S3 Glacier, Snowball, Storage Gateway, S3 교차 리전 복제(CRR)
• 고가용성·라우팅 — Route 53 DNS 페일오버, RDS·ElastiCache Multi-AZ
• 네트워크 복구 — Direct Connect 장애 시 Site-to-Site VPN을 백업으로 사용 (비용 효율적)
• DB 복제 — RDS 교차 리전 복제, Aurora Global Database
• 자동화 — CloudFormation·Elastic Beanstalk(빠른 인프라 재생성), CloudWatch 경보(EC2 자동 복구)

특히 "Direct Connect 장애 시 비용 효율적 백업은?" 의 정답이 거의 매번 Site-to-Site VPN입니다. DX를 하나 더 깔면 또 한 달과 큰돈이 들어가니까요.

AWS Elastic Disaster Recovery (DRS) — 블록 단위로 흘려넣기

물리·가상·다른 클라우드 서버를 AWS로 빠르게 복구해 주는 서비스가 AWS Elastic Disaster Recovery(DRS) 입니다(예전 이름 CloudEndure DR).

작동 흐름이 우아해요. 소스 서버에 복제 에이전트를 설치하면, 디스크에 기록되는 모든 데이터가 블록 수준에서 지속적으로 복제됩니다. 평상시에는 저렴한 소형 EC2 + EBS로 구성된 스테이징 환경에 데이터를 유지하다가, 재해가 나면 스테이징을 기반으로 수 분 내에 프로덕션 규모 EC2/EBS를 만들어 페일오버. 온프레미스 복구가 끝나면 다시 페일백도 가능합니다.

비유하자면 — 임시 창고에 모든 원본의 복사본을 항상 흘려보내고, 본가가 불나면 그 창고를 즉시 풀 사이즈 사무실로 변환하는 식이에요.

RPO 초 단위, RTO 분 단위 — 이 숫자만 외워두면 시험 보기에서 즉시 잡힙니다.

AWS Backup — 중앙 집중 백업과 Vault Lock

여러 AWS 서비스의 백업을 한 곳에서 관리하는 서비스가 AWS Backup 입니다. 이전에는 서비스마다 백업 스크립트를 따로 짜야 했는데, AWS Backup이 그걸 한 화면으로 통합해 줘요.

지원 서비스 — EC2·EBS·S3·RDS(모든 엔진)·Aurora·DynamoDB·Neptune·EFS·FSx(Lustre/Windows)·Storage Gateway 볼륨까지 거의 모든 데이터 서비스를 커버합니다.

기능 면에서는 — Cross-Region Backup(DR용 다른 리전 복사), Cross-Account Backup(Organizations 다중 계정), 태그 기반 백업(Environment: Production 태그 붙은 리소스만 자동 백업, 새로 만든 리소스도 태그 있으면 자동 포함), 온디맨드/예약 백업까지.

백업 플랜은 다섯 가지 부품으로 구성돼요.

• Backup Vault — 백업이 저장되는 논리적 컨테이너
• Schedule — 언제·얼마나 (12시간 윈도, 매주, 매월, Cron 표현식)
• Lifecycle — 일정 기간 지나면 콜드 스토리지로 자동 전환해 비용 절감
• Retention — 보존 기간
• Cross-Region Copy — DR용 다른 리전 자동 복사

플랜은 템플릿·새 플랜·JSON 정의(IaC 자동화) 셋 중에 골라서 만듭니다.

여기서 시험 함정이 하나 있어요. "루트도 못 지운다" 가 강조점입니다. 다른 보안 기능은 IAM·SCP·키 정책으로 어떻게든 우회할 여지가 있는데, Vault Lock은 AWS 차원에서 잠가 버리는 거예요. 시험에 "랜섬웨어로 백업까지 같이 삭제되는 위험을 막으려면?" 시나리오의 답은 100% Vault Lock입니다.

키워드 정리:

• "여러 서비스 백업 중앙 관리" → AWS Backup
• "백업 스크립트 없이 자동화" → AWS Backup
• "태그 기반 리소스 백업" → AWS Backup (새 리소스도 자동 포함)
• "루트 사용자도 삭제 불가" → Vault Lock (WORM)
• "DR을 위한 다른 리전 백업" → Cross-Region Copy

DMS + SCT — DB 마이그레이션의 표준 콤비, 시험 단골

DB 마이그레이션 영역에서 DMS는 사실상 디폴트 정답이에요. 거의 모든 시나리오의 출발점이 됩니다.

이제 마이그레이션입니다. DB 영역의 핵심은 두 도구예요. 하나는 데이터를 옮기고(DMS), 하나는 스키마를 변환합니다(SCT). 이 둘의 관계만 잡으면 DB 마이그레이션 시험 문제 절반은 풀려요.

AWS DMS — 데이터를 옮기는 본진

AWS DMS(Database Migration Service) 는 온프레미스 DB를 AWS로 이전하는 서비스입니다. 핵심 강점은 마이그레이션 중에도 소스 DB를 계속 쓸 수 있다는 점이에요. 다운타임 최소화에 결정적입니다.

회사 비유로 — 이사 가는 동안에도 본가에서 일상이 계속 돌아가고, 새 집으로 짐을 옮기는 동안 추가로 생긴 변화도 새 집에 자동으로 반영되는 식이에요.

DMS 자체는 회복력 좋고 자가 치유(Self-healing) 기능도 제공하며, EC2 복제 인스턴스 또는 서버리스(Serverless) 방식으로 실행돼요. Multi-AZ 동기 복제로 다른 AZ에 대기 복제본을 두면 AZ 장애에도 I/O 중단 없이 회복됩니다.

흐름은 단순해요 — 소스/대상 엔드포인트 생성 → 복제 인스턴스 구성 → 마이그레이션 작업(Task) 생성·실행.

동종 vs 이기종 — SCT가 필요한지의 분기점

여기서 시험 함정 핵심 — 마이그레이션 유형이 동종이냐 이기종이냐.

유형	예시	SCT 필요?
동종(Homogeneous)	Oracle → Oracle, PostgreSQL → RDS PostgreSQL	불필요
이기종(Heterogeneous)	Oracle → Aurora PostgreSQL, SQL Server → Aurora	반드시 SCT 먼저

AWS SCT(Schema Conversion Tool) 는 한 DB 엔진의 스키마를 다른 DB 엔진 스키마로 변환합니다. Oracle의 PL/SQL을 PostgreSQL의 PL/pgSQL로, Teradata의 테이블 정의를 Redshift 스키마로 — 이런 변환을 자동화해 줘요.

비유하자면 — 한국어 책을 영어로 번역하는 번역가입니다. 책 내용(데이터)을 옮기기 전에 책의 형식·문법(스키마) 자체를 새 언어로 옮겨야 하니까요. 두 책이 같은 언어면(동종) 번역가가 필요 없고, 다른 언어면(이기종) 반드시 번역가를 먼저 거쳐야 합니다.

SCT는 보통 온프레미스 데이터 센터 서버에 설치하는 게 권장됩니다. 변환 대상 소스 DB와 가까이 두는 게 효율적이거든요.

CDC — 다운타임 0의 비결

DMS의 작업 모드도 셋입니다.

• Full Load — 기존 데이터 한 번만 마이그레이션
• Full Load + CDC — 기존 데이터 + 이후 변경 사항 지속 복제 (다운타임 최소화 필수)
• CDC only — 변경 사항만 복제

CDC(Change Data Capture) 가 마이그레이션 중 발생하는 변경을 잡아 지속 복제해 주는 게 핵심이에요. 제로 다운타임 마이그레이션의 비결입니다.

이걸 한 줄로 풀면 — 이사 가는 동안 본가에서 새 우편물이 쌓여도, CDC가 그 우편물을 새 집으로 자동으로 가져가 준다는 거예요. 그래서 컷오버 직전까지 본가 우편함이 비어 있는 셈이 됩니다.

암기 공식 세 줄로 끝납니다.

• 엔진이 다름 (Oracle → Aurora) = DMS + SCT
• 엔진이 같음 (Postgres → Postgres) = DMS만
• 마이그레이션 중 소스 DB 사용 유지 = DMS CDC

Aurora 마이그레이션 — 상황별 옵션

Aurora 쪽으로 옮기는 경우는 출처가 어디냐에 따라 옵션이 갈립니다. 이게 시험에 정확히 그대로 나와요.

RDS MySQL/PostgreSQL → Aurora

옵션	다운타임
DB 스냅샷 복원	발생
Aurora 읽기 복제본 생성 후 Promote	최소화

스냅샷 복원은 — 스냅샷을 찍는 시점에 DB가 한 번 멈췄다 다시 가야 하니 다운타임이 발생합니다. 다운타임이 허용되는 시나리오면 가장 단순한 방법이에요.

다운타임 최소화 정답은 — RDS에서 Aurora Read Replica를 만든 다음, Lag이 0이 될 때까지 기다리고, 독립 Aurora 클러스터로 승격(Promote) 하는 것. 동기가 다 맞춰진 상태에서 끊어내니까 다운타임이 거의 없어요.

외부(온프레미스) MySQL → Aurora

옵션	특징
Percona XtraBackup + S3	빠름, 권장 (AWS 공식 지원 도구)
mysqldump	느림, 대용량 부적합
AWS DMS	다운타임 없는 실시간 복제

여기서 시험 함정 하나 — 외부 MySQL → Aurora MySQL의 1순위는 mysqldump가 아니라 Percona XtraBackup입니다. mysqldump는 텍스트 기반이라 대용량에서 느려요. Percona는 바이너리 백업을 S3에 올리고 Aurora가 직접 가져가니 훨씬 빠릅니다.

외부 PostgreSQL → Aurora

옵션	방법
aws_s3 확장	S3에 백업 → Aurora 확장 프로그램으로 가져오기
AWS DMS	지속 복제

PostgreSQL 쪽은 Aurora의 aws_s3 확장 프로그램이 핵심 키워드예요. S3에 백업을 올리고 Aurora에서 aws_s3 확장으로 가져오는 흐름.

암기 공식 — 외부 MySQL = Percona XtraBackup, 외부 PostgreSQL = aws_s3 확장, 다운타임 최소화 = DMS CDC 또는 RDS → Aurora면 Read Replica → Promote.

서버 마이그레이션 — MGN, Discovery, Migration Hub

DB가 아니라 서버 자체를 옮길 때 쓰는 도구가 따로 있어요. 이름이 비슷해서 헷갈리는데, 역할이 명확히 다릅니다.

AWS Application Migration Service (MGN) — Lift-and-Shift의 본진

AWS Application Migration Service (MGN) — 구 CloudEndure Migration. 마이그레이션 전략 중 리호스팅(Rehosting) = Lift-and-Shift 의 표준 도구입니다. "앱 코드 손 안 대고 서버를 통째로 옮긴다" 는 시나리오의 답이에요.

DRS와 비슷한 패턴 — 소스 서버에 복제 에이전트 설치 → 저렴한 EC2 + EBS 스테이징 영역으로 디스크 데이터 지속 복제 → 준비 완료 시 컷오버(Cutover) 로 프로덕션 규모 EC2 + 고성능 EBS로 전환. 다양한 OS/DB 플랫폼을 지원하고 가동 중지 시간을 최소화합니다.

DRS와 MGN의 차이가 시험에 자주 헷갈리는데 — MGN은 일회성 마이그레이션, DRS는 지속적 재해 복구입니다. MGN은 컷오버하면 끝, DRS는 페일오버 후에도 페일백을 위해 계속 돌아가요.

AWS Application Discovery Service — 마이그레이션 "계획"

AWS Application Discovery Service — 마이그레이션을 계획하는 도구입니다. 옮기기 전에 어떤 서버가 있는지, 서버끼리 어떻게 의존하는지(종속성 매핑) 파악해요. 두 가지 방식이 있습니다.

방식	설명	제공 정보
Agentless (커넥터)	커넥터로 VM 정보 수집	환경 설정, CPU/메모리/디스크 성능 이력
Agent-based	VM 내부에 에이전트 직접 설치	실행 프로세스, 상세 네트워크 종속성 매핑

"종속성 매핑" 이 시험 키워드예요. "어떤 서버가 다른 어떤 서버와 통신하는가"를 알아야 마이그레이션 순서를 짤 수 있거든요. 이건 Agent-based로만 잡힙니다.

AWS Migration Hub — 진행 상황 대시보드

AWS Migration Hub — 여러 마이그레이션 도구의 진행 상황을 중앙 집중식으로 추적(Track) 하는 곳. Discovery Service의 수집 데이터도 여기서 확인하고, MGN의 진행 상황도 여기서 봐요. 어느 서버가 어디까지 진행됐는지 한 대시보드에서 봅니다.

VM Import/Export, VMware Cloud on AWS

AWS VM Import/Export — 온프레미스 VM 이미지를 EC2로 가져오거나 반대로 내보내요. 기존 VM을 EC2로 옮기거나 DR 리포지토리 구축에 사용.

VMware Cloud on AWS — 키워드가 "기존 VMware 환경 그대로 AWS로 확장" 입니다. 온프레미스의 vSphere·vSAN·NSX 환경을 그대로 AWS로 확장하면서, 기존 VMware 관리 도구를 그대로 유지할 수 있어요. EC2·S3·RDS·FSx·Redshift·Direct Connect 같은 AWS 네이티브 서비스와도 자연스럽게 연동됩니다.

여기서 시험 함정 하나 — VMware Cloud on AWS는 "VMware 도구·기술 스택을 바꾸지 않고 클라우드로 가고 싶다" 는 매우 구체적인 시나리오에 쓰입니다. 일반적인 Lift-and-Shift는 MGN이고, VMware 환경 유지가 강조되면 VMware Cloud on AWS예요.

키워드 매칭:

• "온프레미스 서버 → AWS 리프트앤시프트" → MGN
• "마이그레이션 계획 + 종속성 매핑" → Discovery Service (특히 Agent-based)
• "여러 도구 진행 추적" → Migration Hub
• "VMware 환경 그대로 클라우드 확장" → VMware Cloud on AWS
• "VM 이미지 가져오기/내보내기" → VM Import/Export

데이터 전송 — Snow vs DataSync vs Transfer Family

대용량 데이터를 옮기는 옵션이 또 따로 있어요. DB도 아니고 서버도 아닌, 그냥 파일·블록 데이터를 옮길 때입니다.

200TB 시나리오로 본 속도 차이

방식	200TB 소요	특징
공용 인터넷/VPN (100Mbps)	약 185일	즉시 설정, 소량용
Direct Connect (1Gbps)	약 18.5일	안정적, 초기 설치 ~1개월
Snowball	약 1주일	물리적 디바이스, 대규모 단기 이동

200TB를 100Mbps로 보내면 6개월입니다. 1Gbps DX로 보내도 3주가 걸려요. 물리적 디바이스로 보내는 게 일주일로 가장 빠릅니다. 이게 Snow Family가 존재하는 이유예요.

여기서 시험 함정 — DX 새로 까는 데도 약 1개월 걸려요. 그래서 "당장 데이터를 옮겨야 한다 + DX는 아직 없다"면 DX를 까는 시간 자체가 이미 손해입니다. Snowball이 답.

하이브리드 마이그레이션 전략 (시험 단골)

이 패턴이 정말 자주 나옵니다.

1. Snowball로 초기 대용량 데이터 물리적 전송 (배송 ~1주)
2. 배송 기간 동안 변경된 증분 데이터는 DMS(CDC)로 동기화
3. 컷오버 시 애플리케이션 전환 (다운타임 최소화)

"50TB DB + 다운타임 최소화 + 인터넷 대역폭 제한" 시나리오의 답이 거의 매번 이 조합이에요.

AWS DataSync — 파일 동기화의 표준

AWS DataSync — 온프레미스 ↔ AWS 스토리지 간 지속적이고 자동화된 파일 데이터 동기화입니다. 온프레미스에 DataSync 에이전트를 설치하고, Direct Connect 또는 인터넷을 통해 S3·EFS·FSx로 동기화해요. 스케줄링 지원.

비유하자면 — 파일 서버와 클라우드 사이에 24시간 돌아가는 우편 트럭이에요. 한쪽에 새 파일이 생기면 정해진 일정대로 다른 쪽으로 자동 배송.

"이미 DX 구축된 환경에서 파일 데이터를 S3로 지속 백업/동기화"가 시나리오면 답입니다.

AWS Transfer Family — SFTP를 그대로

AWS Transfer Family — SFTP/FTPS/FTP 프로토콜로 S3 또는 EFS에 파일을 전송하는 완전 관리형 서비스. 기존 SFTP 워크플로를 코드 변경 없이 그대로 AWS로 옮길 때 써요.

"기존 SFTP 클라이언트는 그대로 두고 백엔드만 S3로" 같은 시나리오의 답입니다.

Snow Family — 오프라인 대용량 전송

디바이스	용량	특징
Snowcone	8TB(HDD) / 14TB(SSD)	소형, 엣지 컴퓨팅
Snowball Edge Storage	80TB	표준 대용량
Snowball Edge Compute	42TB	컴퓨팅 집약적
Snowmobile	최대 100PB (트럭!)	데이터 센터 규모

Snowmobile은 정말 트럭에 컨테이너를 싣고 와서 데이터를 옮깁니다. 데이터 센터 통째로 마이그레이션할 때 쓰는 거예요. 시험에 거의 안 나오지만 한 번 등장하면 "100PB" 라는 숫자만 보면 즉시 잡혀요.

선택 기준을 표로 정리해 둡니다.

상황	선택
DB 마이그레이션 + 다운타임 최소화	DMS (Full Load + CDC)
이기종 DB 마이그레이션	SCT + DMS
파일 데이터 지속 동기화 (DX 있음)	DataSync
150TB+, 인터넷 느림, 단기간 이전	Snowball
SaaS → S3/Redshift (Salesforce 등)	AppFlow
DB 초기 대용량 + 이후 증분 복제	Snowball + DMS(CDC)
SFTP 워크플로 그대로	Transfer Family

CloudFormation — IaC의 기본기

이제 마이그레이션 영역 끝나고 기타 핵심 서비스로 갑니다. 첫 주자는 CloudFormation.

IaC와 선언적 방식

AWS CloudFormation 은 인프라를 코드로 관리하는 IaC(Infrastructure as Code) 서비스입니다. 선언적(Declarative) 방식 — 원하는 최종 상태만 명시하면 CloudFormation이 의존성을 알아서 처리해 만들어 줘요.

비유하자면 — 레시피와 요리사의 관계입니다. "이 음식이 완성되면 좋겠다"고 레시피만 적으면, 요리사(CloudFormation)가 어떤 재료를 어떤 순서로 손질하고 익혀야 할지 알아서 처리. 명령형(Imperative)으로 "1단계: 양파 썰기, 2단계: 기름 두르기…"를 일일이 적을 필요가 없어요.

이점:

• 버전 관리·코드 리뷰 가능
• 스택 내 모든 리소스에 동일 태그 일괄 적용 → 비용 추적 용이
• 퇴근 시 스택 삭제·출근 시 재생성 같은 비용 절감 자동화
• 동일 아키텍처를 다른 리전/계정/환경에 반복 배포 가능

핵심 기능 정리

이름이 비슷한데 역할이 다른 기능들이 시험에 자주 나옵니다.

기능	용도
변경 세트 (Change Sets)	스택 업데이트 전 어떤 리소스가 추가/수정/교체되는지 미리 확인
사용자 지정 리소스 (Custom Resources)	CloudFormation이 기본 미지원하는 서비스를 Lambda 연동으로 처리
StackSets	여러 AWS 계정/리전에 스택 일괄 배포
스택 정책 (Stack Policies)	특정 리소스 변경/삭제 방지
드리프트 감지 (Drift Detection)	실제 인프라와 템플릿 간 불일치 감지
Application Composer	템플릿을 시각적 다이어그램으로 표시
서비스 역할 + iam:PassRole	최소 권한 원칙 — 사용자 대신 CloudFormation이 리소스 생성

AMI ID 함정

여기서 시험 함정 하나가 굉장히 자주 나와요. AMI ID는 리전마다 다릅니다. 같은 Amazon Linux 2 AMI여도 서울 리전과 도쿄 리전의 ID가 달라요. 그래서 템플릿에 AMI ID를 하드코딩하면 다른 리전 배포가 실패합니다.

해결책은 두 가지 — 파라미터로 받아 리전마다 다른 값 입력, 또는 SSM Parameter Store의 퍼블릭 파라미터 참조(/aws/service/ami-amazon-linux-latest/... 같은 키로 자동 매핑).

AWS CDK

AWS CDK(Cloud Development Kit) — Python·TypeScript·Java 같은 프로그래밍 언어로 인프라를 정의하면 내부적으로 CloudFormation 템플릿으로 변환해 줍니다. OOP·반복문·조건문을 쓸 수 있어 개발자 친화적이에요.

키워드 — "동일 아키텍처 다른 리전/계정 반복" → CloudFormation, "업데이트 전 영향 미리 확인" → Change Sets, "여러 계정/리전 일괄" → StackSets, "기본 미지원 서비스" → Custom Resources.

SES vs Pinpoint — 이메일과 캠페인의 자리 분리

이름이 비슷해서 헷갈리는데 역할이 명확히 다릅니다.

Amazon SES(Simple Email Service) 는 트랜잭션·마케팅 이메일을 보내는 완전 관리형 이메일 서비스입니다. SMTP 인터페이스를 지원하고, 반송률·평판 대시보드로 평판을 관리하며, DKIM/SPF도 지원해요. 공유 IP·전용 IP·BYOIP 옵션이 있어 IP 평판도 유연하게 다룰 수 있고요.

비유하자면 — 회사의 이메일 발송 인프라입니다. 비밀번호 재설정·결제 완료 같은 트랜잭션 메일이나 대량 발송용 메일 서버 역할.

Amazon Pinpoint 는 양방향 마케팅 커뮤니케이션 서비스입니다. 채널이 다양해요 — 이메일·SMS·푸시 알림·음성·인앱. 핵심은 세분화·개인화·캠페인 관리 — 세그먼트, 템플릿, 일정 예약, 하루 수십억 메시지 처리, SMS 양방향 회신까지. 이벤트는 SNS·Kinesis Data Firehose·CloudWatch Logs로 보낼 수 있어요.

비유하자면 — 마케팅 캠페인 운영 도구입니다. "20대 여성 고객에게 이번 주말 할인 알림을 메일·SMS·앱 푸시로 동시에" 같은 캠페인을 한 화면에서 운영.

구분	SNS / SES	Pinpoint
주요 용도	단순 메시지/이메일 (인프라)	마케팅 캠페인·고객 참여 (비즈니스)
일정 관리	직접	서비스 내장 (세그먼트·템플릿·예약)
타겟팅	단순 브로드캐스트	고도 타겟·개인화

키워드 — "SMTP·반송률·대량 이메일" → SES / "마케팅 캠페인·SMS·세그먼트" → Pinpoint.

SSM — 시스템 관리 풀세트

AWS Systems Manager(SSM) 는 EC2·온프레미스 서버를 통합 관리하는 도구 모음입니다. 한 서비스 안에 여러 기능이 들어있어서 처음에 이름이 헷갈리는데, 다섯 개만 잡으면 시험은 끝나요.

Session Manager — SSH 없는 안전한 접속

EC2·온프레 서버에 안전하게 셸 접속할 때 쓰는 게 Session Manager 인데, 핵심이 강력해요 — 포트 22 개방 불필요, SSH 키 불필요, 베스천 호스트 불필요.

비유하자면 — 회사 빌딩에 외부 출입구 없이도 IAM 출입증으로 직접 들어가는 비밀 통로입니다. 22번 포트라는 일반 출입구를 아예 잠가도 되니까 보안이 훨씬 강해요.

IAM으로 접근 제어하고, 세션 기록을 S3 또는 CloudWatch Logs에 남겨 감사도 가능합니다. 작동 조건은 셋만 맞추면 돼요.

1. SSM Agent 설치 및 실행 (Amazon Linux 2에는 기본 설치)
2. AmazonSSMManagedInstanceCore 정책이 포함된 IAM 역할 연결
3. 아웃바운드 인터넷 또는 VPC 엔드포인트로 SSM 서비스 통신 가능

EC2 접속 방법 비교:

방법	포트 22	SSH 키	감사 로그
전통 SSH	필요	필요	별도 구성
EC2 Instance Connect	필요	불필요 (임시 키)	별도 구성
SSM Session Manager	불필요	불필요	자동 (S3/CloudWatch)

여기서 시험 함정 하나 — "프라이빗 서브넷 EC2 + SSH 포트 금지 + 베스천 불가 + 감사 로그" 시나리오의 답은 무조건 Session Manager입니다. EC2 Instance Connect는 22 포트가 열려 있어야 해서 답이 아니에요.

Run Command, Patch Manager, Maintenance Windows, Automation

나머지 4종은 한 번씩 짚고 갑니다.

Run Command — 다수 인스턴스(EC2 및 온프레미스)에 스크립트/명령을 일괄 실행. SSH 없이 SSM 에이전트로 통신. 결과는 S3 또는 CloudWatch Logs로. EventBridge로 자동화 트리거.

Patch Manager — OS·앱·보안 패치를 자동화. Linux·Mac·Windows 모두 지원하고 Patch Compliance Report로 감사 활용. 즉시 또는 Maintenance Window 스케줄로 실행.

Maintenance Windows — 작업 실행 스케줄(언제·얼마나·어디에·무엇을)을 정의. 패치, 백업 등을 정해진 창에서만 실행해 운영 영향을 줄여요.

SSM Automation — EC2 재시작·AMI 생성·EBS/RDS 스냅샷 같은 유지 관리를 자동화 런북(Runbooks) 으로 자동화. 결정적으로 AWS Config와 연동되는 자동 복구가 가능 — 규정 미준수(Non-compliant) 리소스 발견 시 SSM Automation을 트리거해 자동 수정합니다.

Parameter Store — 설정 데이터·보안 암호 중앙 저장소. CloudFormation의 AMI ID 함정 해결에도 쓰여요.

키워드 — "다수 서버에 일괄 명령" → Run Command / "패치 자동화 + 준수 보고서" → Patch Manager / "Config + 자동 복구" → AWS Config + SSM Automation / "특정 시간 패치 스케줄" → Maintenance Windows.

Cost Explorer vs Cost Anomaly Detection

비용 관리도 시험에 자주 나옵니다. 이 둘은 짝으로 외우는 게 빨라요.

Cost Explorer — 비용·사용량을 시각화하는 도구. 시간별·리소스 수준 분석, 최대 18개월 미래 예측, Savings Plans 추천까지.

비유하자면 — 재무팀의 시각화 대시보드예요. 과거 지출을 그래프로 보고 미래 예측까지 잡아주는 분석가.

Cost Anomaly Detection — 머신러닝 기반으로 비정상 지출을 자동 감지. 결정적 차이는 임계값 설정 불필요(AWS Budgets와의 핵심 차이점). 근본 원인 분석(Root Cause Analysis) 보고서까지 제공해요. 알림은 SNS 연동, 개별/일일/주간 요약 선택.

비유하자면 — 재무팀의 자동 경보 시스템입니다. "이번 주 EC2 비용이 평소보다 3배 튀었다"를 ML이 알아서 잡아 알려줘요.

AWS Budgets — 사용자가 직접 임계값을 정해 알림 받는 단순 예산 관리.

Trusted Advisor — 비용·성능·보안·내결함성·서비스 한도 5개 영역에서 권장 사항 제공. 일부 항목은 Business/Enterprise 플랜 필요.

서비스	핵심 키워드
Cost Explorer	비용 시각화, 18개월 예측, Savings Plans 추천
AWS Budgets	사용자가 직접 임계값 설정, 단순 알림
Cost Anomaly Detection	ML 기반, 임계값 불필요, 근본 원인 분석
Trusted Advisor	5개 영역 모범 사례 점검 (비용·보안·성능·내결함성·서비스 한도)

여기서 시험 함정 — "임계값 없이 비정상 지출을 잡고 싶다" 가 키워드면 무조건 Cost Anomaly Detection 입니다. Budgets는 임계값이 필수라 답이 아니에요.

Lambda vs Batch — 15분의 벽

AWS Batch 는 완전 관리형 배치(일괄 처리) 프로세싱 서비스입니다. 배치 작업이라는 게 — 시작과 끝이 명확한 작업(스트리밍과 반대). 이미지 1만 장을 한 번에 변환한다거나, 야간에 거대 데이터를 분석한다거나.

기반 기술은 Docker 이미지 + Amazon ECS 위에서 실행. 작업량에 따라 EC2 또는 Spot 인스턴스를 자동 프로비저닝해 비용 절감해요.

전형적 아키텍처 — S3 이미지 업로드 → S3 이벤트 → Batch 작업 트리거 → EC2/ECS 처리 → 결과 S3 저장.

여기서 시험 함정 — Lambda와 Batch가 헷갈려 나옵니다. 결정적 차이는 15분의 벽.

구분	AWS Lambda	AWS Batch
실행 시간	최대 15분	무제한
런타임	지원 언어 한정	Docker 이미지로 모든 런타임
스토리지	/tmp 임시	EBS 볼륨/인스턴스 스토어 (대용량)
컴퓨팅 모델	완전 서버리스	EC2 인스턴스 기반 (관리는 AWS)

Batch 선택 기준 — 15분 초과, 대용량 디스크 필요, Docker 사용자 정의 런타임. 셋 중 하나라도 걸리면 Lambda가 아니라 Batch입니다.

Outposts·AppFlow·Amplify·기타

마지막 묶음. 시험에 키워드로만 잡히는 서비스들이에요. 한 줄씩 정리하고 갑니다.

AWS Outposts — 온프레에 설치되는 AWS

AWS 인프라와 서비스를 고객의 온프레미스 데이터 센터에 설치하는 물리 서버 랙입니다. 클라우드와 온프레에서 동일한 AWS API/콘솔/CLI를 쓸 수 있고, 초저지연으로 온프레 시스템과 가깝게 데이터 처리, 데이터 레지던시(데이터가 클라우드로 안 나가게)도 충족돼요. 지원 서비스 — EC2·EBS·S3·ECS·EKS·RDS·EMR.

비유하자면 — AWS가 우리 회사 지하실에 직접 데이터센터를 박아 주는 것입니다. 그래도 콘솔은 똑같이 AWS Console.

여기서 시험 함정이 하나 — 공동 책임 모델 변화입니다. 일반적인 AWS는 "물리적 보안·전원·네트워크는 AWS 책임"이지만, Outposts 랙은 물리적 보안·전원·네트워크가 고객 책임이에요. 우리 회사 지하실에 있는 거니까 당연하죠. 시험에 "Outposts에서 누가 물리적 보안 책임?"이 정확히 그대로 나옵니다.

키워드 — "온프레 + AWS API 동일 + 초저지연 + 데이터 로컬 유지" → Outposts.

Amazon AppFlow — SaaS와 AWS 사이의 다리

SaaS와 AWS 간 데이터를 안전하게 전송하는 완전 관리형 통합 서비스입니다. 소스(SaaS) — Salesforce·SAP·Zendesk·Slack·ServiceNow. 목적지 — S3·Redshift(AWS), Snowflake·Salesforce(외부). 트리거 — 온디맨드·스케줄·이벤트. 내장 필터링·유효성 검사. AWS PrivateLink로 프라이빗 전송도 가능해요.

키워드 — "SaaS(Salesforce·Zendesk) → S3/Redshift, 코드 없이, PrivateLink" → AppFlow.

AWS Amplify — 모바일/프론트 풀스택 원스톱

웹·모바일 개발자를 위한 원스톱 숍(One-stop shop) 입니다. 클라우드 전문 지식 없이도 풀스택 앱을 빠르게 구축할 수 있어요. Amplify Hosting — GitHub/GitLab/Bitbucket 연결 → 자동 CI/CD → CloudFront 글로벌 배포. 내부 통합 서비스 — Cognito(인증)·S3(스토리지)·DynamoDB(DB)·AppSync(GraphQL)·API Gateway(REST)·Lambda(서버리스)·SageMaker/Lex(ML/AI).

키워드 — "모바일 앱·프론트엔드 + 빠른 백엔드 풀스택" → Amplify.

기타 한 줄 정리

이 서비스들은 시험에 한 번씩 등장하는데 깊이 들어가진 않아요. 이름과 키워드만 짝지어 두면 됩니다.

• WorkSpaces — 클라우드 기반 가상 데스크톱(VDI), Windows·Linux. 원격 근무 환경.
• AppStream 2.0 — 데스크톱 애플리케이션을 클라우드에서 실행해 브라우저로 스트리밍. 로컬 설치 없이 사용.
• OpsWorks — Chef 또는 Puppet으로 서버 구성 자동화. 키워드 — "Chef·Puppet·기존 구성 관리 도구".
• AppConfig — 애플리케이션 설정을 안전하게 배포·관리. 점진적 배포·롤백·유효성 검사.
• Instance Scheduler — EC2/RDS를 업무 외 시간 자동 중지/시작해 최대 70% 비용 절감. AWS 솔루션이라 CloudFormation 템플릿으로 배포되고, 내부적으로 DynamoDB(스케줄 저장) + Lambda(시작/중지 실행) 구조. 태그 기반으로 인스턴스 식별, 교차 계정·교차 리전 지원.

자주 나오는 시나리오 패턴

여기까지 서비스 정리가 끝났으니 시나리오 패턴으로 한 번 묶어 봅니다. 시험 직전에 이 부분만 다시 한 번 보면 거의 모든 변형 문제가 풀려요.

패턴 1 — 50TB DB + 다운타임 최소화 + 인터넷 느림

Snowball (초기 대용량 물리 전송, ~1주일)
  + DMS CDC (배송 기간 동안 증분 동기화)
    → 컷오버 시 애플리케이션 전환

대용량 + 인터넷 제한이 키워드면 Snowball + DMS CDC 조합이 거의 매번 정답입니다.

패턴 2 — 이기종 DB 마이그레이션 (Oracle → Aurora PostgreSQL)

SCT (Oracle 스키마 → PostgreSQL 스키마 변환)
  → DMS Full Load + CDC (다운타임 최소화)
    → 마이그레이션 완료 후 애플리케이션 연결 전환

엔진이 다르면 SCT 먼저, DMS 다음이 공식.

패턴 3 — 온프레미스 서버 리프트앤시프트

Application Discovery Service (서버 현황 + 종속성 매핑)
  → AWS MGN (지속 복제)
    → 컷오버 (프로덕션 규모 EC2 전환)
      → Migration Hub (진행 추적)

서버 자체를 옮기는 시나리오는 Discovery → MGN → Migration Hub 순서가 표준.

패턴 4 — Active-Active DR (제로 다운타임)

Multi-Site / Hot Site 전략
  + Aurora Global Database (리전 간 데이터 복제)
  + Route 53 Geolocation/Latency 라우팅

금융·핵심 서비스 시나리오에서 등장하는 패턴.

패턴 5 — 보안 서버 관리 (SSH 금지 + 감사)

SSM Session Manager (포트 22 없이 IAM 기반 접속)
  + SSM Run Command (일괄 명령)
    → S3/CloudWatch Logs (세션·명령 출력 자동 저장)

프라이빗 서브넷 + 베스천 불가 + 감사 로그가 키워드면 답.

패턴 6 — VMware 환경 DR

VMware Cloud on AWS
  → 기존 vSphere/vSAN/NSX 환경 그대로 AWS로 확장
    → 재해 시 동일 VMware 도구로 빠른 페일오버

VMware 도구 유지가 키워드면 답.

시험 직전 한 번 더 — DMS 함정 포함 압축 모음

여기까지가 SAA-C03 DR·마이그레이션·기타 서비스 영역의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요. 이 부분만 시험 전날 한 번 더 읽으면 거의 다 떠오릅니다.

DR 4전략 + AWS Backup·DMS

• RPO = 데이터 손실 / RTO = 다운타임 (백업 빈도 vs 복구 시간)
• DR 4전략 비용 순서 — Backup&Restore < Pilot Light < Warm Standby < Multi-Site
• Pilot Light = EC2 꺼짐 / Warm Standby = EC2 최소 실행 (DB는 둘 다 항상 켬)
• Multi-Site = Active-Active + Route 53 트래픽 분산
• Direct Connect 장애 백업 = Site-to-Site VPN (비용 효율)
• DRS = RPO 초·RTO 분, 블록 수준 지속 복제, 스테이징 환경
• AWS Backup Vault Lock = WORM = 루트도 삭제 불가 (랜섬웨어 방어)
• AWS Backup 태그 기반 = 새 리소스도 태그 있으면 자동 백업
• 이기종 DB = SCT + DMS / 동종 = DMS만
• 다운타임 최소화 = DMS CDC
• 외부 MySQL → Aurora = Percona XtraBackup + S3 (mysqldump는 느림)
• 외부 PostgreSQL → Aurora = aws_s3 확장
• RDS → Aurora 다운타임 최소화 = Read Replica → Promote

서버·데이터 마이그레이션 — Snow·DataSync·MGN

• MGN = Lift-and-Shift (일회성) vs DRS = 지속적 DR
• Discovery Service Agent-based = 종속성 매핑 (Agentless는 환경 정보만)
• Migration Hub = 여러 마이그레이션 도구 중앙 추적
• VMware Cloud on AWS = vSphere/vSAN/NSX 그대로 확장
• Snowball + DMS CDC = 대용량 + 다운타임 최소화 표준 조합
• DataSync = 파일 지속 동기화 (DX 활용)
• Transfer Family = SFTP/FTPS/FTP 그대로
• Snowmobile = 100PB 트럭 (데이터센터 규모)

CloudFormation·SES·SSM

• CloudFormation AMI ID = 리전 종속, 하드코딩 금지 → SSM Parameter Store 활용
• Change Sets = 업데이트 영향 미리 확인 / StackSets = 다중 계정·리전
• Custom Resources = 미지원 서비스를 Lambda 연동
• 드리프트 감지 = 실제 인프라 vs 템플릿 불일치
• CDK = 프로그래밍 언어로 IaC (내부적으로 CloudFormation 변환)
• SES = SMTP·반송률·대량 이메일 (인프라)
• Pinpoint = 마케팅 캠페인·SMS·세그먼트 (비즈니스)
• SSM Session Manager = 포트 22·SSH 키·베스천 모두 불필요 + 감사 자동
• SSM Run Command = 다수 서버 일괄 명령
• SSM Patch Manager = 패치 + Compliance Report
• SSM Automation + AWS Config = 규정 미준수 자동 복구

Cost·운영·기타 서비스

• Cost Explorer = 18개월 예측·Savings Plans 추천
• Cost Anomaly Detection = ML, 임계값 불필요, 근본 원인 분석
• AWS Budgets = 사용자 임계값 기반 알림 (Anomaly Detection과 차이)
• Trusted Advisor = 5개 영역(비용·보안·성능·내결함성·서비스 한도)
• Batch = 15분 초과·Docker·대용량 디스크 (Lambda는 15분 제한)
• Outposts 공동 책임 — 물리적 보안·전원·네트워크는 고객
• AppFlow = SaaS(Salesforce 등) → S3/Redshift, 코드 없이, PrivateLink
• Amplify = 모바일·프론트엔드 빠른 풀스택
• OpsWorks = Chef/Puppet (기존 구성 관리 도구)
• Instance Scheduler = EC2/RDS 업무 외 자동 중지/시작 (DynamoDB + Lambda)

마무리 한 줄

여기까지가 SAA-C03 DR·마이그레이션·기타 영역의 핵심이에요. 양이 많아 보이지만, DR 4전략 + DMS+SCT 분기 + SSM Session Manager + Cost Explorer/Anomaly Detection 분리 이 네 가지 큰 골격만 잡으면 시나리오 절반 이상은 자동으로 풀립니다. 그중에서도 DMS의 동종/이기종 분기 + CDC만 정확히 잡아두면 DB 마이그레이션 시나리오는 거의 다 풀려요. 나머지는 이름 ↔ 키워드 매칭이라 시험 직전 한 번 더 훑어보는 걸로 충분해요.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — IAM
• 2편 — EC2 / Storage
• 3편 — ELB · ASG
• 4편 — S3 (스토리지)
• 5편 — Databases
• 6편 — Networking
• 7편 — Messaging
• 8편 — Containers · Serverless
• 9편 — Monitoring
• 10편 — Analytics · ML
• 11편 — Security
• 12편 — DR · Migration (현재 글)
• 13편 — Architectures
• 14편 — Exam Prep (완)