AWS 14-2 옮기기와 장애 대비 — DMS·DataSync·Direct Connect·Elastic Disaster Recovery·FIS·MWAA
고친 사람 github-actions[bot]
사내 전산실에서 돌던 주문 시스템을 AWS 로 옮기기로 했다고 해 봅니다. MySQL DB 가 500 GB 있고, 사내 파일 서버에 상품 이미지가 몇 TB 쌓여 있습니다. 거래처는 매일 밤 정산 파일을 SFTP 로 보내오고, 회계 시스템은 당분간 사내에 남습니다. 옮기는 동안에도 주문은 계속 들어옵니다.
이 일을 하다 보면 질문이 차례로 생깁니다. 주문이 들어오는 DB 는 어떻게 멈추지 않고 옮길까요? 파일 몇 TB 는 무엇으로 올릴까요? VPC 안의 서버가 사내 회계 시스템을 사설 IP 로 부르려면 두 망을 어떻게 이을까요? 옮긴 뒤 리전이나 전산실이 멈추면 어디서 다시 띄울까요? 사내에서 쓰던 Prometheus·Grafana·Airflow 서버는 AWS 에서 다시 깔아야 할까요? 이 편은 이 길에서 만나는 열한 서비스를 하나씩 짧게 봅니다. 「그 외」로 묶인 편이라 서비스마다 무엇을 하고 언제 맞는지까지만 다룹니다. 요금은 전부 2026-11-13 서울(ap-northeast-2) 기준이고, 요금 페이지에 서울 값이 안 나오는 것은 AWS 가 공개하는 서울 가격 목록(Price List)에서 읽었습니다.
지도
flowchart TD
START["사내 시스템을<br/>AWS 로 옮긴다"] --> Q1{"지금 할 일은"}
Q1 -- "데이터를 옮긴다" --> Q2{"무엇을"}
Q2 -- "DB" --> DMS["DMS"]
Q2 -- "파일·객체" --> DS["DataSync"]
Q2 -- "거래처가<br/>SFTP 로 보낸다" --> TF["Transfer Family"]
Q1 -- "사내망과 잇는다" --> Q3{"오가는 양과<br/>기다릴 여유"}
Q3 -- "적다 · 오늘 당장" --> VPN["Site-to-Site VPN"]
Q3 -- "많다 · 일정해야" --> DX["Direct Connect"]
Q1 -- "AWS 를<br/>사내에 들인다" --> OP["Outposts"]
Q1 -- "장애에 대비한다" --> Q4{"무엇을"}
Q4 -- "서버를<br/>다른 곳에 다시 띄운다" --> DRS["Elastic Disaster Recovery"]
Q4 -- "장애를<br/>미리 일으켜 본다" --> FIS["FIS"]
Q1 -- "쓰던 운영 도구를<br/>맡긴다" --> OSS["Managed Service for Prometheus<br/>Managed Grafana · MWAA"]
처음 갈림길은 지금 하는 일이 데이터를 옮기는 것인지, 망을 잇는 것인지, 장애에 대비하는 것인지입니다. 데이터는 DB 냐 파일이냐로 갈리고, 망은 오가는 양과 개통을 기다릴 여유로 갈립니다. 망을 잇지 않고 AWS 장비를 아예 사내에 들이는 갈래도 따로 있습니다. 마지막 갈래의 셋은 성격이 조금 다릅니다. 옮겨 올 때 데이터만 따라오는 것이 아니라 사내에서 쓰던 오픈소스 운영 도구도 따라오는데, 그 서버를 직접 띄우지 않고 맡기는 서비스들입니다. 끝에서는 사내망을 잇는 두 방법의 한 달 값을 셈합니다.
1. 데이터를 옮긴다
DMS — 주문이 들어오는 DB 를 옮긴다
DB 를 옮길 때 가장 곤란한 것은 옮기는 동안에도 쓰기가 들어온다는 점입니다. 덤프를 떠서 새 DB 에 올리는 몇 시간 동안 쌓인 주문은 어떻게 할까요? DMS(Database Migration Service)는 AWS 안에 복제 서버를 두고, 원본 DB 에서 읽어 대상 DB 에 쓰는 일을 맡깁니다. 먼저 지금 있는 데이터를 한 번 전부 옮기고(전체 적재, full load), 그 뒤로는 원본에서 일어난 변경을 따라가며 대상에 계속 반영합니다. 이 뒷부분을 변경 데이터 캡처(CDC, change data capture)라고 합니다.
변경을 따라가려면 DMS 가 원본 엔진의 트랜잭션 로그를 읽을 수 있어야 합니다. MySQL 이면 행 기반 binlog 를, PostgreSQL 이면 논리 복제 슬롯을 읽습니다. Oracle 이면 보충 로깅(supplemental logging)을 켜서 바뀐 행을 찾을 값까지 로그에 남기게 합니다. 그래서 옮기기 전에 원본 쪽에서 이런 로그 설정부터 켜 둬야 합니다(Creating tasks for ongoing replication using AWS DMS).
전체 적재 뒤에 CDC 가 따라붙어 두 DB 가 거의 같아지면, 애플리케이션의 접속 주소를 새 DB 로 바꾸는 순간에만 쓰기를 멈추면 됩니다. 다만 AWS 는 CDC 가 실시간 복제가 아니라고 못 박습니다. 지연에 SLA(Service Level Agreement, 서비스 수준 약정)가 없고 원본 부하나 네트워크에 따라 몇 분 넘게 벌어질 수 있습니다. 또 DMS 가 대상에 스스로 만드는 것은 표와 기본 키뿐입니다. 보조 인덱스·뷰·트리거는 직접 만들거나 DMS Schema Conversion 으로 만듭니다. Schema Conversion 은 Oracle 에서 PostgreSQL 로처럼 엔진을 바꿀 때 스키마와 저장 프로시저 같은 코드를 대상 엔진에 맞게 바꿔 주는 기능이고, 쓰는 값은 무료입니다(What is AWS Database Migration Service?).
복제 서버는 인스턴스 크기를 골라 띄우거나, DMS Serverless 로 두어 DMS 가 원본을 보고 용량을 알아서 잡게 할 수 있습니다. Serverless 의 용량 단위는 DCU(DMS Capacity Unit, 메모리 2 GB)입니다(Working with AWS DMS Serverless). 복제 서버는 떠 있는 시간만큼 요금이 쌓입니다.
DMS · 서울 · 2026-11-13
복제 인스턴스 (단일 AZ, 730시간)
dms.t3.medium 시간당 $0.112 → $81.76
dms.r6i.large 시간당 $0.24 → $175.20
다중 AZ 단일 AZ 의 약 두 배 (r6i.large 시간당 $0.47)
Serverless 1 DCU 시간당 $0.1036
저장(gp2) GB-월 $0.131 (T3 는 50 GB 포함)
Schema Conversion 무료 (S3 저장 요금만)
전송 DMS 로 들어오는 것, 같은 AZ 의
RDS·EC2 와 오가는 것은 무료
- AWS Database Migration Service pricing · 서울 가격 목록
APN2-InstanceUsg:dms.*,APN2-Multi-AZUsg:dms.*
옮기는 한두 달만 복제 서버를 켜 두는 것이라 값보다는 무엇을 옮겨 주고 무엇을 안 옮겨 주는지가 판단을 가릅니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 쓰기가 계속 들어오는 DB 를 짧은 멈춤으로 옮긴다 | 몇 시간 멈춰도 되는 작은 DB(→ 덤프·복원이 간단하다) | 원본에 binlog·보충 로깅 같은 로그 설정을 먼저 켜야 한다 |
| 엔진을 바꿔 옮긴다(Oracle → PostgreSQL) | 인덱스·뷰·트리거까지 DMS 가 옮겨 줄 거라 기대한다 | 표·기본 키 밖은 Schema Conversion 이나 손으로 만든다 |
| 옮긴 뒤 한동안 두 DB 를 맞춰 둔다 | 몇 초 안의 지연을 늘 보장해야 하는 상시 복제 | CDC 지연에 SLA 가 없다 |
옮길 것이 DB 가 아니라 파일이면 DataSync 로 넘어갑니다.
DataSync — 파일과 객체를 옮긴다
첫머리의 상품 이미지 몇 TB 를 S3 로 올릴 차례입니다. 복사 명령을 직접 돌리면 중간에 끊겼을 때 어디까지 갔는지, 옮긴 파일이 원본과 같은지를 내가 챙겨야 합니다. DataSync 는 이 전송을 맡는 서비스입니다. 사내의 NFS·SMB 공유 폴더, HDFS(Hadoop Distributed File System), 객체 저장소와 다른 클라우드의 저장소에서 S3·EFS·FSx 로(또는 반대로) 옮기고, 전송 중 암호화와 무결성 검증을 해 줍니다(What is AWS DataSync?).
사내 저장소에서 옮길 때는 에이전트가 필요합니다. 내 저장소 옆에 띄우는 가상 머신이고, 이것이 사내 파일을 읽어 AWS 로 보냅니다. 같은 계정 안의 AWS 저장소끼리 옮기거나, S3 와 다른 클라우드의 객체 저장소 사이를 옮길 때는 에이전트가 없어도 됩니다(Do I need an AWS DataSync agent?). 작업은 두 모드 가운데 하나로 만들고, 만든 뒤에는 바꿀 수 없습니다. Basic 모드는 목록 만들기·전송·검증을 차례로 하고 한 번에 다룰 파일 수에 한도가 있습니다. Enhanced 모드는 이 단계를 병렬로 돌려 대개 더 빠르고, 파일 수에 사실상 한도가 없습니다(Choosing a task mode for your data transfer).
DataSync 는 옮긴 GB 만큼 냅니다. Enhanced 모드는 실행 한 번마다 요금이 하나 더 붙습니다.
DataSync · 서울 · 2026-11-13
Basic 모드 옮긴 GB 당 $0.0125
Enhanced 모드 옮긴 GB 당 $0.015 + 실행 1회 $0.55
10 TB 를 Enhanced 로 한 번
10,240 × $0.015 + $0.55 = $154.15
+ S3 요청·저장 요금, AZ·리전을 넘는 전송 요금
한 번 옮기고 끝나는 일인지, 옮긴 뒤에도 사내에서 그 파일을 계속 읽는지가 DataSync 와 Storage Gateway 를 가릅니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 사내 NFS·SMB 의 몇 TB 를 S3·EFS·FSx 로 옮기고 끝낸다 | 사내 애플리케이션이 옮긴 뒤에도 그 파일을 계속 읽고 쓴다(→ Storage Gateway, 02-2편) | 사내에 에이전트 VM 을 띄워야 한다 |
| 파일이 수천만 개라 목록 만들기부터 오래 걸린다(Enhanced) | 몇 GB 를 한 번 올리면 끝이다(→ AWS CLI 로 올린다) | Enhanced 는 실행마다 $0.55 가 붙는다 |
사내에서 계속 쓰는 공유 폴더를 AWS 에 잇는 Storage Gateway 는 저장소 편(02-2)이 다룹니다.
Transfer Family — 거래처가 보내는 SFTP 를 받는다
거래처가 매일 밤 SFTP 로 정산 파일을 올리고 있다면, AWS 로 옮긴 뒤에도 거래처에게 방식을 바꿔 달라고 하기는 어렵습니다. Transfer Family 는 SFTP·FTPS·FTP·AS2(Applicability Statement 2, 기업 간 문서 교환에 쓰는 전송 규약) 서버를 관리형으로 띄우고, 받은 파일을 S3 나 EFS 에 바로 넣습니다. 거래처는 쓰던 클라이언트와 인증 설정을 바꾸지 않고 붙습니다. 서버는 최대 세 가용 영역에 걸쳐 돌고, 업로드가 끝난 파일을 복사·태그·복호화하는 후처리 흐름도 붙일 수 있습니다(What is AWS Transfer Family?).
같은 서비스에 딸린 기능이 둘 더 있습니다. 브라우저로 S3 에 올리고 내려받는 웹 앱이 있고, 반대로 내 쪽에서 거래처의 SFTP 서버로 파일을 보내거나 가져오는 SFTP 커넥터가 있습니다.
켜 둔 프로토콜마다 시간 요금이 나갑니다. 오간 GB 에는 요금이 따로 붙습니다.
Transfer Family · 서울 · 2026-11-13
프로토콜마다 시간당 $0.30 → 730시간 $219.00
올리기·내려받기 GB 당 $0.04 (SFTP·FTPS·FTP)
웹 앱 단위당 시간당 $0.50
SFTP 커넥터 바깥 SFTP 서버로 보내고 받는 GB 당 $0.40
+ S3·EFS 요청과 저장 요금
파일이 오든 안 오든 프로토콜 하나에 월 $219 가 나가므로, 거래처가 SFTP 를 고집할 때만 고를 만합니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 거래처가 SFTP·AS2 로 보내는 방식을 바꿀 수 없다 | 내가 만든 애플리케이션끼리 파일을 주고받는다(→ S3 API 로 직접 올린다) | 프로토콜 하나에 월 $219.00 고정 |
| 받는 파일이 매일 꾸준히 많고 S3 에서 Lambda·Athena 로 이어 처리한다 | 하루 몇 개뿐이라 월 $219 가 아깝다(→ 거래처에 S3 사전 서명 URL 을 준다) | 올리고 내려받는 GB 마다 $0.04 가 더 붙는다 |
2. 사내망과 잇는다
옮기는 동안, 그리고 옮긴 뒤에도 사내에 남는 시스템이 있습니다. VPC 안의 서버가 사내 회계 시스템을 사설 IP 로 부르려면 두 망을 이어야 합니다. 두 망을 잇는 방법은 인터넷 위에 암호화된 터널을 뚫는 것과 전용 회선을 까는 것입니다. 망을 잇지 않고 AWS 의 장비를 사내에 들여놓는 길도 있습니다.
Site-to-Site VPN — 인터넷 위에 터널을 뚫는다
가장 빨리 두 망을 잇는 길은 이미 있는 인터넷을 쓰는 것입니다. Site-to-Site VPN 은 사내 라우터나 방화벽과 AWS 사이에 IPsec 터널을 맺습니다. 연결 하나에 터널이 둘 들어 있어 하나가 끊겨도 다른 쪽으로 오갑니다. AWS 쪽 끝은 주로 VPC 하나에 붙는 가상 사설 게이트웨이이거나, 여러 VPC 를 잇는 Transit Gateway 입니다. 사내 쪽 끝의 장비를 고객 게이트웨이 장치라고 부릅니다(What is AWS Site-to-Site VPN?). VPN 하나를 여러 VPC 가 나눠 쓰는 구성은 VPC 편(04-1)의 Transit Gateway 절에 있습니다.
터널 하나는 최대 1.25 Gbps 입니다. Transit Gateway 나, 여러 리전의 망을 한 번에 묶는 Cloud WAN 에 붙인 연결은 터널당 5 Gbps 까지 쓰는 대역폭 큰 터널을 고를 수 있습니다. 인터넷을 지나므로 실제 속도는 패킷 크기와 그날의 인터넷 사정에 따라 달라집니다(AWS Site-to-Site VPN quotas).
청구는 두 갈래입니다. 연결을 켜 둔 시간, 그리고 AWS 에서 사내로 나간 양입니다.
Site-to-Site VPN · 서울 · 2026-11-13
연결 시간당 $0.05 → 730시간 $36.50
5 Gbps 연결 시간당 $0.60
+ Transit Gateway VPN 첨부 시간당 $0.07,
처리 GB 당 $0.02
AWS → 사내 인터넷 전송 요금 (첫 10 TB GB 당 $0.126)
사내 → AWS 0원
한 달 청구서는 연결 값보다 AWS 에서 사내로 내려보낸 GB 수를 따라 움직입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 오늘 바로 사내망과 이어야 한다 | 대역폭과 지연이 늘 일정해야 한다(→ Direct Connect) | 속도가 그날의 인터넷 사정을 따른다 |
| AWS 에서 사내로 내려보내는 양이 적다 | 한 달에 몇 TB 씩 내려받는다(→ 5절에서 셈한다) | 나가는 GB 마다 인터넷 전송 요금 |
| 터널 하나에 1.25 Gbps 면 충분하다 | 그보다 큰 대역폭을 VPC 하나에 바로 붙이고 싶다 | 5 Gbps 터널은 Transit Gateway 에 붙여야 하고, 그 첨부 요금이 더 붙는다 |
Direct Connect — 전용 회선을 깐다
인터넷 사정에 따라 속도가 흔들리는 것이 문제라면, 인터넷을 아예 거치지 않으면 됩니다. Direct Connect 는 사내 라우터에서 Direct Connect 위치(AWS 장비가 들어 있는 데이터센터)까지 광케이블로 잇는 서비스입니다. 서울 리전과 이어진 위치가 서울 안에 셋 있습니다. 회선 위에는 가상 인터페이스를 만들어 VPC 로 갈지, S3 같은 AWS 공용 서비스로 갈지, Transit Gateway 로 갈지를 고릅니다(What is Direct Connect?).
연결을 받는 길은 둘입니다. 전용 연결은 큰 포트를 직접 받는 대신 개통이 길고, 호스팅 연결은 파트너가 나눠 주는 작은 대역폭이라 빨리 받습니다.
전용 연결은 1·10·100·400 Gbps 포트를 콘솔에서 요청해 받습니다. AWS 가 요청을 검토하는 데 최대 72 영업시간이 걸립니다. 승인되면 받은 승인서(LOA-CFA, Letter of Authorization and Connecting Facility Assignment)를 들고 위치 안에서 내 장비와 AWS 장비를 잇는 교차 연결을 주문합니다. 그 위치에 내 장비가 없으면 파트너를 거쳐야 합니다. 요금은 포트가 켜지거나 승인서를 받은 지 90일이 지나면 붙기 시작합니다(Dedicated Direct Connect connections). 회선 구간 암호화인 MACsec(Media Access Control Security)도 일부 위치의 전용 연결에서만 됩니다(MAC Security in Direct Connect).
호스팅 연결은 Direct Connect 파트너가 자기 회선을 50 Mbps 부터 25 Gbps 까지 나눠 내주는 것입니다. 정한 속도를 넘는 트래픽은 버려집니다(Hosted Direct Connect connections).
회선 하나는 그 자체로 단일 장애점입니다. AWS 는 두 가용성 모델에 SLA 를 겁니다. 둘 이상의 위치에 따로 연결을 두면 99.9%, 그 위에 위치마다 서로 다른 장비로 연결을 이중으로 두면 99.99% 입니다. 한 위치 안에서 장비만 나눈 구성은 개발·시험용으로 봅니다(AWS Direct Connect Resiliency Toolkit).
Direct Connect 의 청구도 포트 시간과 내려받은 양 두 갈래지만, 위치까지 가는 회선 값은 AWS 가 아니라 파트너에게 따로 냅니다.
Direct Connect · 서울 위치 · 2026-11-13 · 730시간
전용 1 Gbps 시간당 $0.30 → $219.00
전용 10 Gbps 시간당 $2.25 → $1,642.50
호스팅 50 Mbps 시간당 $0.03 → $21.90
호스팅 1 Gbps 시간당 $0.33 → $240.90
AWS → 사내 GB 당 $0.041 (서울 리전 → 서울 위치)
사내 → AWS 0원
+ 위치까지의 회선·교차 연결 값 (파트너에게 따로)
- 포트 요금은 트래픽이 없어도 나갑니다(AWS Direct Connect pricing)
- 2026-09 부터 10·100 Gbps 전용 연결에는, 고른 등급의 리전에서 나가는 전송 요금을 시간 요금에 넣은 정액제도 있습니다. 호스팅 연결은 해당하지 않습니다(Flat-rate pricing for AWS Direct Connect)
포트 값이 매달 고정으로 나가는 대신 내려받는 GB 값이 VPN 의 3분의 1 아래로 떨어지므로, 오가는 양이 많을수록 유리해집니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| AWS 에서 사내로 한 달 몇 TB 넘게 내려받는다 | 오가는 양이 적다(→ VPN) | 포트 요금과 회선 값이 매달 고정으로 나간다 |
| 대역폭과 지연이 늘 일정해야 한다 | 요청 검토·승인서·교차 연결을 기다릴 수 없다 | 개통 절차를 파트너·통신사와 맞춰야 한다 |
| 회선이 끊겨도 버텨야 한다 | 한 위치의 회선 하나에 운영을 건다 | 99.99% SLA 는 두 위치에 이중 연결을 요구한다 |
Outposts — AWS 를 사내에 들여놓는다
데이터가 건물 밖으로 나가면 안 되거나, 리전까지 왕복하는 지연을 못 견디는 시스템은 어떻게 할까요? 망을 잇는 대신 AWS 를 사내로 들여오는 길이 있습니다. Outposts 는 AWS 가 소유하고 관리하는 장비를 내 건물에 설치해, 그 위에서 리전과 같은 API 로 EC2·ECS 등을 띄우게 하는 서비스입니다. 장비는 42U 랙과 1U·2U 서버 두 형태입니다. Outpost 는 리전의 한 가용 영역을 사내로 늘린 것으로 취급되어, 거기 만든 서브넷의 인스턴스가 같은 VPC 안의 리전 인스턴스와 사설 IP 로 오갑니다. 리전과는 서비스 링크라는 경로로 이어집니다. 랙에서는 EC2·EBS·ECS·EKS·RDS·S3 를 쓸 수 있고, 서버에서는 컴퓨팅이 EC2·ECS 뿐이고 EBS·S3·RDS·EKS 는 안 됩니다(What is AWS Outposts?).
계약은 3년 약정입니다. 랙은 대표 구성의 요금표가 공개돼 있고, 맞춤 구성은 견적을 받습니다. 선결제 전부·일부·없음 가운데 고릅니다. 주문하려면 랙은 Enterprise Support 에, 서버는 Enterprise Support 나 Enterprise On-Ramp 에 가입해 있어야 합니다(AWS Outposts rack pricing · AWS Outposts servers pricing). Enterprise Support 는 AWS 의 유료 기술 지원 등급 가운데 하나로, 월 최소 $5,000 부터입니다(AWS Support plan pricing).
약정 3년에 지원 등급 가입까지 따라오니, 리전으로는 안 되는 이유가 분명할 때만 고릅니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 공장·병원처럼 데이터를 현장에서 짧은 지연으로 처리해야 한다 | 리전으로 옮겨도 아무 문제가 없는 시스템 | 3년 약정과 Enterprise Support(서버는 On-Ramp 도 됨) 가입 |
| 사내에 두어야 하는 데이터를 리전과 같은 API 로 다룬다 | RDS·S3 를 작은 서버 한 대에서 쓰고 싶다 | 서버 형태는 컴퓨팅이 EC2·ECS 뿐이고, EBS·S3·RDS·EKS 는 랙에서만 된다 |
3. 장애에 대비한다
옮겨 온 서버가 도는 리전이나, 아직 남아 있는 사내 전산실이 통째로 멈추면 어디서 다시 띄울까요? 그리고 그 대비가 정말 도는지는 어떻게 알까요? 장애 대비는 두 숫자로 말합니다. 장애 때 잃어도 되는 데이터가 몇 분어치인지가 RPO(Recovery Point Objective)이고, 다시 서비스하기까지 걸려도 되는 시간이 RTO(Recovery Time Objective)입니다.
Elastic Disaster Recovery — 서버를 다른 곳에서 다시 띄운다
사내 서버가 멈췄을 때 몇 분 안에 AWS 에서 같은 서버를 띄우려면, 그 서버의 디스크가 미리 AWS 에 와 있어야 합니다. Elastic Disaster Recovery(줄여서 DRS)는 사내 서버나 다른 리전의 서버에 에이전트를 깔아, 그 서버의 디스크를 내가 고른 리전으로 계속 복제해 둡니다. 복제본은 준비 영역(staging area) 서브넷에 싼 디스크와 작은 복제 서버(기본 t3.small)로 유지합니다. 장애가 나거나 훈련할 때는 복구 인스턴스를 몇 분 안에 띄우는데, 이때 원래 서버를 AWS 에서 부팅되는 모양으로 바꿔 줍니다. 가장 최근 상태로 띄울 수도 있고, 문제가 생기기 전의 시점을 골라 띄울 수도 있습니다. 원래 쪽이 살아나면 그쪽으로 다시 복제해 되돌아갈 수 있습니다(What is Elastic Disaster Recovery?). AWS 는 RPO 를 초 단위, RTO 를 분 단위로 내세웁니다(AWS Elastic Disaster Recovery FAQs).
밤마다 백업을 떠 두는 것과 다른 점이 여기 있습니다. 백업에서 복원하면 마지막 백업 뒤의 데이터를 잃고 복원 시간도 길지만, DRS 는 복제가 계속 돌고 있어 그 둘을 줄입니다. 대신 그 복제를 돌리는 값이 늘 나갑니다.
Elastic Disaster Recovery · 서울 · 2026-11-13
원본 서버마다 시간당 $0.028 → 730시간 $20.44
따로 붙는 것 디스크마다 같은 크기의 EBS 준비 볼륨
시점 복구용 스냅샷 (기본 7일 보관)
복제 서버 EC2 (기본 t3.small)
훈련·복구로 띄운 인스턴스의 EC2·EBS
- 같은 요금 페이지의 100대 예시에서 DRS 요금은 월 전체의 3분의 1쯤이고 나머지는 EBS·스냅샷·복제 서버입니다(AWS Elastic Disaster Recovery pricing)
복제를 늘 돌리는 값이 서버 수에 비례하므로, 대피시킬 서버가 몇 대인지가 먼저입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 서버 단위로, 애플리케이션을 고치지 않고 다른 리전이나 AWS 로 대피한다 | 관리형 DB·서버리스 위주라 대피시킬 서버가 거의 없다 | 서버당 시간 요금에 디스크 크기만큼의 EBS·스냅샷이 늘 붙는다 |
| 사내 전산실의 대피처로 AWS 를 쓴다 | 하루 전 백업에서 복원해도 되는 시스템(→ AWS Backup, 02-2편) | 복구 훈련도 띄운 인스턴스 시간만큼 돈이 든다 |
FIS — 장애를 일부러 일으켜 본다
다중 AZ 로 짰고 복구 계획도 세웠는데, 가용 영역 하나가 정말 멈추면 서비스가 버틸지는 일어나 봐야 압니다. FIS(Fault Injection Service)는 그 장애를 일부러 일으켜 보는 서비스입니다. 이런 방식을 카오스 엔지니어링이라고 부릅니다. 실험 템플릿에 무엇을 할지(액션), 어느 리소스에 할지(대상), 언제 멈출지(중지 조건)를 적어 실험을 돌립니다. 중지 조건은 비워 둘 수도 있지만, 걸 때는 CloudWatch 알람으로 걸고 알람이 울리면 FIS 가 실험을 멈춥니다(Stop conditions for AWS FIS). FIS 는 실제 리소스에 실제 동작을 하므로, AWS 는 운영 환경에 돌리기 전에 계획을 세우고 운영 전 환경에서 먼저 돌려 보라고 강하게 권합니다(What is AWS Fault Injection Service?).
처음부터 액션을 조합하지 않아도 되도록 시나리오 라이브러리가 있습니다. EC2 인스턴스를 멈추거나 CPU·메모리·디스크에 부하를 겁니다. 네트워크에 지연을 넣거나 EKS 파드를 지울 수도 있습니다. 가용 영역 하나의 전원이 나갔을 때 나타나는 증상(「AZ Availability: Power Interruption」)이나 리전 사이 연결이 끊긴 상황도 흉내 냅니다(Scenarios reference).
FIS 는 액션이 돈 시간을 분 단위로 셉니다.
FIS · 서울 · 2026-11-13
액션 1분 $0.10 (대상 계정이 하나 늘 때마다 $0.10 더)
실험 보고서 1건 $5
예: 20분 액션 둘을 동시에 + 10분 액션 하나
= 50 액션-분 × $0.10 = $5.00
실험이 의미가 있으려면 견딜 구성과 멈출 기준이 먼저 서 있어야 합니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 다중 AZ 구성이 AZ 하나를 잃어도 버티는지 확인한다 | 장애 대비 구성이 아직 없다(먼저 다중 AZ·복구 계획부터) | 실제 리소스를 실제로 멈추므로 운영 전 환경에서 먼저 돌려야 한다 |
| 알람을 중지 조건으로 걸고 조심스럽게 운영 환경에서 돌린다 | 알람 없이 운영 환경에서 돌리려 한다 | 중지 조건은 선택이지만 운영 환경이라면 알람부터 세우는 것이 안전하고, 액션 1분마다 값이 붙는다 |
4. 쓰던 오픈소스 운영 도구를 맡긴다
사내에서 Prometheus 로 지표를 모으고 Grafana 로 보고 Airflow 로 배치를 돌리던 팀이 AWS 로 오면, 그 서버들도 EC2 에 다시 깔아야 할까요? 세 도구 모두 AWS 가 관리형으로 띄워 주는 판이 있습니다. 지표와 로그를 AWS 안에서 처음부터 모은다면 관측 편(06)의 CloudWatch 가 기본이고, 이 셋은 이미 그 도구로 짠 대시보드·쿼리·작업 흐름이 있을 때 고릅니다.
Managed Service for Prometheus — 지표 저장소를 맡긴다
Prometheus 서버를 직접 돌리면 디스크가 차고, 한 대가 죽으면 그동안의 지표가 빕니다. 그 저장을 맡길 수는 없을까요? Prometheus 는 서버들이 내놓는 지표를 주기적으로 긁어 와 시계열(시간 순으로 쌓인 숫자의 줄)로 저장하는 오픈소스 모니터링 도구입니다. Managed Service for Prometheus(AMP)는 이 저장과 조회를 서버 없이 맡습니다. 데이터 모델과 쿼리 언어 PromQL 이 같아 기존 쿼리를 고치지 않고 씁니다. 저장과 조회는 양에 맞춰 늘고, 들어온 지표는 같은 리전의 세 가용 영역에 복제됩니다. 기본 150일 보관하고 최대 1,095일(3년)까지 늘릴 수 있습니다. EKS 와 직접 운영하는 Kubernetes 클러스터에서 씁니다(What is Amazon Managed Service for Prometheus?).
긁어 오는 일은 AMP 가 하지 않습니다. 내가 띄운 Prometheus 나 수집 에이전트가 지표를 긁어 AMP 로 밀어 넣고, EKS 라면 AWS 가 띄워 주는 관리형 수집기를 쓸 수도 있습니다.
AMP 는 들어온 샘플(시계열 하나의 점 하나) 수, 저장량, 조회가 훑은 샘플 수 셋에 요금을 매깁니다. 아래 예는 시계열 1만 개를 30초마다 한 달 동안 긁는 경우입니다.
Managed Service for Prometheus · 서울 · 2026-11-13
수집 첫 4,000만 샘플 무료,
그 뒤 20억 샘플까지 1,000만 샘플당 $0.90
저장 첫 10 GB 무료, 그 뒤 GB-월 $0.03
조회 훑은 샘플 10억 개당 $0.10 (첫 2,000억 개 무료)
관리형 수집기 수집기 1시간 $0.04 + 1,000만 샘플당 $0.03
시계열 1만 개 × 30초 간격 × 30일
샘플 10,000 × 86,400 = 8억 6,400만
수집 (864 − 40)백만 → 82.4 × $0.90 = $74.16
요금은 시계열 수와 긁는 간격을 곧바로 따라갑니다. 간격을 30초에서 60초로 늘리면 수집 요금이 $74.16 에서 $35.28 로 절반 남짓 줄어듭니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 이미 Prometheus·PromQL 로 짠 대시보드와 쿼리가 있다 | 지표를 처음 모으고 AWS 서비스 지표가 대부분이다(→ CloudWatch) | 시계열 수 × 긁는 간격에 비례해 수집 요금이 붙는다 |
| 쿠버네티스 지표를 오래 보관하고 여러 클러스터에서 모은다 | 지표가 적어 Prometheus 한 대로 충분하다 | 저장은 맡기지만 긁어 오는 쪽(Prometheus·에이전트·관리형 수집기)은 내가 띄우고 정한다 |
Managed Grafana — 대시보드를 맡긴다
지표는 AMP 에, 로그는 CloudWatch 에, 업무 데이터는 사내 DB 에 흩어져 있으면 화면을 오가며 봐야 합니다. Grafana 는 여러 곳의 지표·로그·추적을 한 화면에 그려 주는 오픈소스 시각화 도구입니다. Managed Grafana 는 워크스페이스라는 서로 떨어진 Grafana 서버를 띄워 주고 설치·패치·확장을 맡습니다. CloudWatch·OpenSearch Service·X-Ray·Timestream·AMP 같은 AWS 데이터 원본을 권한 설정과 함께 붙여 주고, 로그인은 SAML(Security Assertion Markup Language) 2.0 을 지원하는 사내 계정 시스템이나 IAM Identity Center 로 합니다(What is Amazon Managed Grafana?).
Managed Grafana 는 그달 로그인한 사람 수만큼 냅니다.
Managed Grafana · 서울 · 2026-11-13 · 워크스페이스마다
편집자·관리자 활성 사용자 1명 월 $9
보기 전용 활성 사용자 1명 월 $5
엔터프라이즈 플러그인 사용자 1명 월 $45 더
예: 편집자 3명 + 보기 20명 = $27 + $100 = $127
- 「활성」은 그달 로그인했거나 API 를 부른 사용자이고, 워크스페이스마다 편집자 라이선스가 적어도 하나 있어야 합니다. 처음 90일은 5명까지 무료로 써 볼 수 있습니다(Amazon Managed Grafana pricing)
보는 사람 수에 값이 붙으니, 대시보드를 몇 명이 보는지부터 셉니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 여러 원본(CloudWatch·AMP·사내 DB)을 한 대시보드에 모은다 | 보는 사람이 많고 CloudWatch 대시보드로 충분하다 | 보는 사람마다 월 $5 씩 늘어난다 |
| 사내 계정 시스템으로 로그인을 묶고 Grafana 서버는 관리하기 싫다 | SAML 이나 Identity Center 를 둘 수 없다 | 로그인을 SAML·Identity Center 로만 붙인다 |
MWAA — Airflow 를 맡긴다
밤마다 도는 배치가 수십 개이고 서로 순서가 얽혀 있다면, cron 만으로는 무엇이 실패해 무엇이 밀렸는지 보기 어렵습니다. Apache Airflow 는 작업 흐름을 파이썬 코드로 적고, 정한 때 돌리고, 지켜보는 오픈소스 도구입니다. 작업 사이의 순서를 DAG(Directed Acyclic Graph, 방향이 있고 되돌아오는 길이 없는 그래프)로 적습니다. MWAA(Managed Workflows for Apache Airflow)는 Airflow 환경을 띄워 줍니다. 스케줄러와 워커는 내 VPC 의 사설 서브넷에 붙은 Fargate 컨테이너로 돌고, Airflow 가 상태를 적는 메타데이터 DB 는 AWS 가 관리합니다. 워커는 정한 최소·최대 사이에서 알아서 늘고 줄고, 웹 화면은 인터넷에 열거나 VPC 안에서만 열 수 있습니다(What Is Amazon Managed Workflows for Apache Airflow?).
환경은 켜 둔 시간만큼 값이 나갑니다. 그래서 2025-11-17 에 상시 환경 없이 작업이 도는 시간만 받는 MWAA Serverless 가 나왔고 서울에서도 됩니다. Serverless 는 워크플로를 파이썬 파일이 아니라 YAML 정의 파일로 올립니다. 쓰던 파이썬 DAG 는 AWS 가 내놓은 변환기로 YAML 로 바꿔야 하고, YAML 로 표현할 수 없는 동적·복잡한 로직의 DAG 는 AWS 도 상시 환경을 권합니다(What is Amazon MWAA Serverless? · Workflows).
Airflow 에서 작업 하나를 이루는 단위를 연산자(Operator)라고 합니다. Serverless 는 Airflow 3 기준이고, 처음에는 AWS 서비스를 부르는 연산자 80여 개만 됐습니다. 임의의 파이썬 함수나 셸 명령을 돌리는 연산자는 2026-08 에야 더해졌습니다(Amazon MWAA Introduces Serverless Deployment Option · PythonOperator and BashOperator 지원). Airflow 웹 화면은 AWS 가 띄워 주지만 흐름을 보고 실행을 시작하는 데까지입니다. 일시 정지·실행 멈춤·연결 관리 같은 조작은 화면에서 안 되고 API 로 합니다(Access the Airflow UI).
MWAA · 서울 · 2026-11-13 · 730시간
환경 mw1.micro 시간당 $0.3336 → $243.50
환경 mw1.small 시간당 $0.5636 → $411.43
환경 mw1.medium 시간당 $0.8511 → $621.34
늘어난 워커 small 시간당 $0.0633 (늘어난 동안만)
메타데이터 DB GB-월 $0.12
Serverless 작업 1시간 $0.104 (초 단위, 최소 1분)
예: 10분짜리 작업 하루 50개 × 30일 = 250시간
250 × $0.104 = $26.00
- 환경이 켜져 있는 시간에 더해 자동으로 늘어난 워커 시간이 따로 붙습니다(Amazon MWAA pricing)
위 예처럼 작업이 띄엄띄엄 돈다면 Serverless($26.00)가 가장 작은 상시 환경($243.50)의 9분의 1쯤입니다. 작업이 쉬지 않고 여럿 겹쳐 돌수록 이 차이는 줄어듭니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 이미 Airflow DAG 가 수십 개 있고 그 코드를 옮긴다 | Airflow 코드가 없고 AWS 서비스 몇 개를 순서대로 부른다(→ Step Functions, 07-2편) | 환경은 작업이 없어도 월 $243.50 부터 나간다 |
| 작업이 띄엄띄엄 돌고 DAG 를 YAML 로 옮길 수 있다(Serverless) | DAG 를 코드로 동적으로 만들거나, 작업이 쉬지 않고 겹쳐 돌아 상시 환경이 더 싸다 | Serverless 는 파이썬 DAG 를 그대로 못 올리고 YAML 정의로 바꿔야 한다(변환기 제공). 웹 화면에서는 보기와 실행 시작까지만 된다 |
Airflow 없이 AWS 서비스를 순서대로 부르는 흐름은 이벤트 편(07-2)의 Step Functions 와 EventBridge Scheduler 가 맡습니다.
5. 한 달 10 TB 를 내려받으면 VPN 과 Direct Connect 중 무엇이 싼가
옮긴 뒤 AWS 의 분석 결과를 사내 시스템이 매일 받아 가서, 한 달에 10 TB(10,240 GB)를 내려받는 경우를 셉니다. 사내에서 AWS 로 올리는 양은 두 방법 모두 0원이라 셈에서 뺍니다. Direct Connect 는 서울 위치의 호스팅 1 Gbps 를 쓴다고 둡니다. 호스팅 연결이라 정액제는 해당하지 않습니다.
AWS → 사내 10 TB · 서울 · 2026-11-13 · 730시간
Site-to-Site VPN
연결 $0.05 × 730 = $36.50
전송 10,240 × $0.126 = $1,290.24
합계 $1,326.74
Direct Connect 호스팅 1 Gbps
포트 $0.33 × 730 = $240.90
전송 10,240 × $0.041 = $419.84
합계 $660.74
+ 파트너 회선 값
두 값이 같아지는 양 (회선 값 빼고)
($240.90 − $36.50) ÷ ($0.126 − $0.041)
= 약 2,405 GB / 월
- 인터넷 전송의 전역 무료 100 GB 는 계정의 다른 서비스와 나눠 쓰므로 셈에서 뺐습니다
AWS 요금만 보면 한 달 약 2,405 GB 를 넘게 내려받을 때부터 Direct Connect 가 쌉니다. 10 TB 면 VPN 이 두 배쯤 비쌉니다. 다만 Direct Connect 쪽에는 사내에서 위치까지 가는 회선 값이 더 붙으므로, 실제로 갈리는 양은 그 회선 값만큼 더 위에 있습니다. 회선 견적을 받아 $240.90 쪽 고정비에 더한 뒤 다시 나눠 보면 됩니다.
이럴 땐 무엇
| 상황 | 서비스 | 이유 |
|---|---|---|
| 주문이 계속 들어오는 MySQL 을 RDS 로 옮긴다 | DMS(전체 적재 + CDC) | 옮기는 동안의 변경을 따라가 전환 때만 잠깐 멈춘다 |
| Oracle 을 Aurora PostgreSQL 로 바꿔 옮긴다 | DMS + Schema Conversion | 스키마·코드 변환은 무료, 데이터는 DMS 가 옮긴다 |
| 사내 파일 서버의 몇 TB 를 S3 로 옮기고 끝낸다 | DataSync | 무결성 검증까지 하고 10 TB 에 $154 남짓 |
| 거래처의 매일 밤 SFTP 업로드를 S3 로 받는다 | Transfer Family | 거래처 설정은 그대로, 프로토콜 하나 월 $219 |
| 오늘 바로 VPC 와 사내망을 잇는다 | Site-to-Site VPN | 연결 월 $36.50, 터널 둘로 이중화 |
| 한 달 수 TB 를 내려받고 지연이 일정해야 한다 | Direct Connect | 약 2,405 GB 부터 VPN 보다 싸다(회선 값 빼고) |
| 현장 데이터를 지연 짧게 처리하되 AWS API 로 다룬다 | Outposts | AWS 장비를 사내에 두고 리전처럼 쓴다 |
| 사내 전산실이 멈추면 AWS 에서 몇 분 안에 다시 띄운다 | Elastic Disaster Recovery | 서버당 월 $20.44 에 RPO 초 단위 |
| 다중 AZ 구성이 AZ 장애를 버티는지 확인한다 | FIS(AZ 전원 중단 시나리오) | 알람을 중지 조건으로 건다 |
| Prometheus 지표 저장소를 직접 운영하기 싫다 | Managed Service for Prometheus | PromQL 그대로, 세 AZ 복제 |
| CloudWatch·AMP 를 한 Grafana 화면에서 본다 | Managed Grafana | 활성 사용자 수로만 낸다 |
| 쓰던 Airflow DAG 를 옮긴다 | MWAA(띄엄띄엄 돌고 YAML 로 옮길 수 있으면 Serverless) | 상시 환경 월 $243.50 부터, Serverless 는 돈 시간만 내지만 YAML 로 옮길 수 있는 DAG 만 |
자주 붙는 서비스는 Transit Gateway(04-1편, VPN·Direct Connect 를 여러 VPC 가 나눠 쓴다), S3·EFS(옮긴 파일이 닿는 곳), RDS·Aurora(DMS 의 대상), CloudWatch(FIS 중지 조건·각 서비스 지표), AWS Backup(02-2편, DRS 와 짝을 이루는 정기 백업), IAM Identity Center(05-1편, Grafana 로그인)입니다.
한 장 요약
이 열한 서비스는 옮기는 몇 달만 켜 두는 것(DMS·DataSync)과 다 옮긴 뒤에도 매달 고정비가 나가는 것(Transfer Family·Direct Connect·Outposts·MWAA 상시 환경)으로 갈립니다. 뒤쪽은 쓰는 양이 고정비를 넘는지부터 셈해야 하고, 사내망이라면 그 경계가 회선 값을 빼고 한 달 약 2,405 GB 였습니다. 장애 대비 둘은 짝입니다. DRS 가 대피처를 만들고, FIS 가 그 대비가 정말 버티는지 확인합니다. 관리형 운영 도구 셋은 이미 그 도구로 짠 것이 있을 때의 선택이고, 처음이라면 CloudWatch·Step Functions 가 먼저입니다.
관련 항목
데이터를 옮기는 서비스
AWS DMS · DMS Schema Conversion · DMS Serverless · AWS DataSync · AWS Transfer Family · AWS Storage Gateway · AWS Snowball
DB 를 멈추지 않고 옮기는 장치
변경 데이터 캡처 · 전체 적재 · binlog · 논리 복제 · WAL · MySQL · PostgreSQL
파일을 주고받는 규약
SFTP · FTPS · AS2 · NFS · SMB · HDFS
사내망과 AWS 를 잇는 길
AWS Site-to-Site VPN · AWS Direct Connect · IPsec · BGP · MACsec · 고객 게이트웨이 · 가상 사설 게이트웨이 · AWS Transit Gateway · Direct Connect 게이트웨이
AWS 를 사내로 늘리는 방식
AWS Outposts · 하이브리드 클라우드 · 온프레미스 · 가용 영역 · 서브넷
장애에 대비하는 말과 도구
AWS Elastic Disaster Recovery · AWS Fault Injection Service · 재해 복구 · RPO · RTO · 카오스 엔지니어링 · AWS Backup · CloudWatch
관리형으로 맡기는 오픈소스 운영 도구
Amazon Managed Service for Prometheus · Amazon Managed Grafana · Amazon MWAA · Prometheus · PromQL · Grafana · Apache Airflow · DAG · Kubernetes
이 서비스들의 값을 이루는 단위
데이터 전송 요금 · AWS Price List API · AWS Enterprise Support · IAM Identity Center · AWS Step Functions