DR센터 구축 비용 2026, RTO·RPO와 클라우드 DR 예산 기준

DR센터 구축 비용 산정 회의와 재해 복구 센터 운영 검토 장면 — DR센터 예산은 건물보다 RTO, RPO, 복제 데이터, 테스트 페일오버, 네트워크 이중화에서 먼저 결정된다.

DR센터 구축 비용을 묻는 사람은 보통 두 가지 압박을 동시에 받는다.

장애가 나도 서비스를 멈추면 안 된다는 요구와, 평소에는 거의 쓰지 않는 복구 설비에 큰 고정비를 넣기 어렵다는 현실이다.

그래서 예산표의 첫 줄은 랙 수나 서버 수가 아니라 RTO와 RPO여야 한다.

복구 목표가 정해지지 않은 DR센터 견적은 나중에 백업 솔루션 견적, 전용회선 견적, 클라우드 포트 견적이 따로 움직이며 쉽게 부풀어난다.

핵심 요약

DR센터 구축 비용은 보호 서버 수, 복제 스토리지, 대기 컴퓨트, 테스트 페일오버, 전용회선, 보안 운영, 라이선스 비용으로 나눠야 한다.
AWS Elastic Disaster Recovery는 복제 서버당 $0.028/hour를 제시하며, 100대와 30TB 예시는 월 $6,389.03까지 계산된다.
Azure Site Recovery는 첫 31일 무료이며, Korea Central 소매 가격 기준 VM Replicated to Azure는 $25/month per instance다.
전용 물리 DR센터는 공개 단가가 드물기 때문에 코로케이션, 전력, 랙, 회선, 출입통제, 운영 인력을 견적 항목으로 분해해야 한다.

공식 가격표 핵심 숫자부터 본다

아래 표는 2026년 9월 7일 확인한 공식 가격표와 공식 문서의 공개 숫자만 정리한 기준표다.

환율, 약정, 리전, 데이터 전송 방향, 회선 사업자 비용, 코로케이션 계약 조건은 실제 지출액을 바꾼다.

구분	공식 공개 금액	비용 단위	견적 해석
AWS Elastic Disaster Recovery	$0.028 per server per hour	복제 중인 서버 1대의 시간 단가	100대 기준 730시간이면 DRS 사용료만 $2,044로 계산된다
AWS DRS 예시 100대	월 $6,389.03	100 servers, 30TB, daily change rate 3.3%	DRS, EBS staging disk, snapshot, replication server EC2 비용을 합친 공식 예시다
AWS DRS 8시간 drill 예시	$122.94	100대 recovery instance 8시간 실행	평소 대기 비용과 훈련 실행 비용을 분리해야 한다는 근거다
AWS DRS conversion server	대개 recovery instance당 $0.05 미만	복구 인스턴스 시작 시 짧게 실행	작지만 대량 복구 테스트에서는 누락하지 않는다
Azure Site Recovery to Azure	첫 31일 무료, 이후 $25/month	Korea Central VM Replicated to Azure 1대	소매 가격 조회 결과 기준이며 스토리지와 데이터 전송은 별도다
Azure Site Recovery to System Center	첫 31일 무료, 이후 $16/month	Korea Central VM Replicated to System Center 1대	온프레미스 보조 사이트나 System Center 환경을 따질 때 비교한다
Google Cloud Backup and DR, Seoul Cloud SQL	$0.072 per GiB month	저장된 백업 데이터 GiB 월액	데이터베이스 보호 범위가 커지면 관리 비용도 같이 늘어난다
Google Cloud Backup and DR, Seoul AlloyDB	$0.102 per GiB month	저장된 백업 데이터 GiB 월액	고성능 데이터베이스 백업은 RPO보다 보관 정책이 비용을 키울 수 있다
Google Cloud Backup and DR, Seoul Filestore	$0.061 per GiB month	저장된 백업 데이터 GiB 월액	파일 저장소 DR은 변경률과 보존 기간을 먼저 넣어 계산한다

이 표만으로 DR센터 총액을 확정하면 안 된다.

공개 가격표는 보호와 복제의 단가를 보여줄 뿐이고, 실제 구축비는 네트워크 경로와 운영 책임에서 갈린다.

이 글이 필요한 사람

금융, 커머스, 제조, 의료 시스템의 업무 연속성 요구를 예산표로 바꿔야 하는 인프라 책임자.
온프레미스 보조 센터와 클라우드 DR 중 어느 쪽이 싼지 비교해야 하는 구매 담당자.
RTO와 RPO를 정하지 못한 채 DR센터 견적 요청서를 받아야 하는 서비스 오너.
백업 솔루션, 전용회선, 보안관제, 코로케이션 비용을 하나의 복구 구조로 합쳐야 하는 IT 기획자.
감사 대응 때문에 복구 훈련 증적과 비상 운영 절차를 문서화해야 하는 보안 담당자.

DR센터 구축 비용은 네 가지 복구 패턴에서 갈린다

가장 비싼 선택지는 항상 두 번째 센터를 실제 운영 환경처럼 켜 두는 방식이다.

가장 싼 선택지는 백업만 보관하고 장애 때 복구 환경을 만든다는 전제에 가깝다.

문제는 두 선택지가 모두 틀릴 수 있다는 점이다.

결제, 인증, 주문, 생산 제어처럼 멈춤 비용이 큰 업무는 싸게 만들면 장애 때 손실이 더 커진다.

패턴	월 고정비	복구 속도	맞는 업무	비용 함정
Backup and restore	낮음	느림	문서, 로그, 낮은 변경률의 업무 데이터	복구 서버와 네트워크를 장애 때 처음 만들면 RTO가 길어진다
Pilot light	중간 이하	중간	핵심 DB와 최소 인증 체계만 항상 유지하는 서비스	작게 켜 둔 구성이 실제 피크 부하를 버티는지 훈련해야 한다
Warm standby	중간 이상	빠름	주문, 정산, ERP처럼 몇 시간 중단도 부담인 업무	평소 사용률이 낮은 대기 컴퓨트와 라이선스가 고정비로 남는다
Hot standby	높음	가장 빠름	결제, 금융 거래, 실시간 생산 제어	두 센터를 계속 동기화하며 데이터 정합성과 장애 전파를 함께 관리해야 한다

Google Cloud의 DR planning guide도 RTO와 RPO가 작아질수록 비용과 운영 복잡도가 커진다고 설명한다.

따라서 DR센터 구축 비용을 낮추는 일은 단순 절감이 아니라 업무별 복구 등급을 다르게 매기는 일이다.

비용 산정표는 서버보다 업무 단위로 만든다

서버 50대라는 숫자는 출발점으로 부족하다.

같은 50대라도 결제 DB, 내부 위키, 배치 서버, 사내 Git 저장소는 복구 목표가 전혀 다르다.

DR센터 예산 회의에서는 서버 목록보다 업무 목록을 먼저 열어야 한다.

비용 축	계산 입력값	월 비용이 커지는 조건	검증 질문
보호 대상	업무명, VM 수, 물리 서버 수, DB 용량, 변경률	모든 업무를 같은 RTO로 묶을 때	이 업무가 4시간 멈추면 매출이나 규제 리스크가 얼마인가
복제 스토리지	원본 용량, 일 변경률, 보존 기간, snapshot 수	랜섬웨어 대비 장기 보존과 immutable copy를 모두 넣을 때	7일 복구점과 30일 보관을 구분했는가
대기 컴퓨트	평상시 켜 둘 vCPU, 메모리, 라이선스, 오토스케일 기준	warm standby 이상으로 항상 켜 둘 때	훈련 때 실제 피크 트래픽을 몇 퍼센트까지 받는가
네트워크	전용회선, VPN, Direct Connect, ExpressRoute, 방화벽, DNS	물리 경로와 통신사를 이중화할 때	백업 회선이 같은 관로를 쓰지 않는가
보안·운영	IAM, 키 관리, 로그, 모니터링, 출입통제, 야간 대응	센터만 있고 사람과 절차가 없을 때	복구 권한을 누가 언제 승인하고 로그를 어디에 남기는가

실무 시나리오 1: 금융·핀테크의 전자거래 핵심 시스템

이 조건이면 백업 복구형 DR만으로는 부족하다.

결제 승인, 계좌 연동, 본인확인, 거래 원장처럼 중단 손실이 큰 업무는 RTO를 분 단위나 한 자리 시간 단위로 잡는 경우가 많다.

이 경우는 보조 센터나 클라우드 DR 환경에 최소 운영 컴퓨트와 네트워크 경로를 미리 준비해야 한다.

비용표에는 보호 VM 수와 DB 용량뿐 아니라 test failover 횟수, 회선 이중화, 보안관제 연동, 계정 잠금 해제 절차를 넣는다.
Azure Site Recovery를 쓰면 보호 인스턴스 단가와 스토리지, snapshot, 데이터 전송, failover 후 compute 비용을 따로 계산한다.
AWS DRS를 쓰면 서버당 시간 단가와 staging disk, snapshot, replication server, recovery drill 비용을 분리한다.
감사 대응 문서에는 복구 성공 여부보다 복구 시각, 승인자, DNS 전환, 거래 무결성 점검 로그를 함께 남긴다.

이 조건이면 비용 절감의 핵심은 모든 시스템을 hot standby로 올리지 않는 것이다.

정산 배치, 리포트, 내부 관리 화면은 RTO를 늦춰도 되는지 서비스 오너에게 서명받아야 한다.

실무 시나리오 2: 제조사의 해외 공장 ERP와 생산 데이터

제조사는 금융 시스템보다 실시간 거래량이 낮아 보여도 장애 비용이 작지 않다.

공장 ERP, 설비 로그, 품질 데이터, 작업 지시 시스템이 끊기면 생산 라인과 출하 일정이 같이 흔들린다.

이 경우는 중앙 데이터센터 하나를 그대로 복제하기보다 지역별 복구 우선순위를 나누는 편이 낫다.

생산 제어와 작업 지시는 RTO를 짧게 잡고, 분석용 데이터레이크와 장기 로그는 RTO를 길게 둔다.
전용회선 비용이 크면 야간 복제 창과 압축, 변경 블록 복제, 지점별 캐시를 먼저 검토한다.
해외 법인마다 같은 DR센터를 만들기보다 클라우드 리전, 코로케이션, 본사 센터를 삼각형으로 비교한다.
공장 네트워크는 보안 구역이 분리되어 있으므로 DR 복구 때 방화벽 정책과 장비 접근 권한을 별도 runbook으로 둔다.

이 조건이면 가장 위험한 절감안은 백업만 성공했다고 DR센터 준비가 끝났다고 보는 방식이다.

복구 환경에서 MES와 ERP가 실제로 연결되는지, 설비망 이름 해석과 인증서가 맞는지 훈련해야 한다.

클라우드 DR과 물리 DR센터를 같이 비교한다

물리 DR센터는 설비 소유와 통제권이 강하지만 초기 계약과 운영 인력 부담이 크다.

클라우드 DR은 평소 비용을 줄이기 좋지만 데이터 전송, 리전 장애, 계정 권한, failback 절차를 제대로 설계해야 한다.

둘 중 하나만 정답이라고 보면 견적이 흔들린다.

비교 항목	물리 DR센터	클라우드 DR	의사결정 기준
초기 구축	코로케이션, 랙, 전력, 회선, 장비 반입이 필요	계정, 네트워크, 복제 도구, 보안 기준부터 구성	장비 감가상각과 프로젝트 기간을 비교
월 고정비	공간, 전력, 회선, 운영 인력의 고정비가 큼	보호 인스턴스와 스토리지 중심으로 시작 가능	항상 켜 둘 컴퓨트가 많으면 클라우드도 비싸짐
복구 훈련	실제 센터 운영 절차와 출입 권한을 검증	test failover와 격리 네트워크 검증이 쉬움	훈련 횟수를 연 1회로 줄이면 리스크가 숨는다
보안 통제	물리 보안과 내부망 통제가 명확	IAM, 키, 로그, 계정 분리 설계가 핵심	감사 요구가 물리 위치를 요구하는지 확인
확장성	장비 증설과 계약 변경이 느릴 수 있음	복구 시점에 compute를 크게 늘릴 수 있음	복구 후 장기 운영 가능성을 따져야 함

구축 순서: RTO 회의부터 test failover까지

DR센터 구축은 장비 구매로 시작하지 않는다.

아래 순서를 건너뛰면 비용은 커지고 복구 확률은 낮아진다.

업무 영향 분석을 먼저 수행해 서비스별 RTO, RPO, 최대 허용 데이터 손실, 최대 허용 수작업 시간을 정한다.
업무별 등급을 hot, warm, pilot light, backup and restore로 나누고 비용이 큰 등급에는 서비스 오너 승인을 받는다.
보호 대상 서버, DB, 파일 저장소, 객체 저장소, 인증 시스템, 배치 의존성을 CMDB나 스프레드시트로 잠근다.
복제 방식은 애플리케이션 복제, 스토리지 복제, 이미지 기반 복제, 백업 복원 중 하나로 정하고 혼합 기준을 문서화한다.
네트워크는 주 경로, 백업 경로, DNS 전환, 방화벽 정책, NAT, 인증서, 외부 파트너 접속을 별도 항목으로 산정한다.
보안은 관리자 계정, 키 관리, 로그 보존, 취약점 패치, 랜섬웨어 격리, 복구 승인 절차를 DR 환경에도 같은 수준으로 적용한다.
월 1회 또는 분기 1회 test failover를 실행하고 비용, 소요 시간, 실패 지점, 되돌리기 시간을 남긴다.
훈련 결과를 다음 견적에 반영해 보호 대상에서 제외할 업무와 더 빠른 복구가 필요한 업무를 조정한다.

비용을 줄이려면 제외 기준을 먼저 써야 한다

DR센터 비용 절감은 싼 상품을 찾는 일이 아니다.

복구 대상에서 제외할 업무와 복구 등급을 낮출 업무를 명확히 쓰는 일이 먼저다.

예외를 문서화하지 않으면 장애 직후 모든 시스템을 즉시 살려야 한다는 압박이 생긴다.

내부 위키, 개발 테스트 서버, 임시 배치 서버는 업무 영향 분석 결과에 따라 늦은 복구 등급으로 낮춘다.
읽기 전용 보고서와 데이터 마트는 원본 DB 복구 뒤 재생성 가능한지 확인하고 별도 보호에서 제외할 수 있다.
스토리지 변경률이 큰 로그는 원본 전체 복제보다 보관 정책, 샘플링, 압축, archive tier를 먼저 비교한다.
전용회선은 모든 트래픽을 싣기보다 DB 복제, 인증, 핵심 거래 트래픽만 태우고 대용량 배포 파일은 분리한다.
테스트 페일오버는 줄이면 안 되며, 훈련 자동화와 격리 네트워크로 실행 비용을 낮추는 쪽이 안전하다.

보안과 운영 리스크를 비용표에 넣는다

DR 환경은 평소에 조용해서 보안 예외가 쌓이기 쉽다.

복구 순간에는 관리자 권한, 암호화 키, 네트워크 우회, 임시 계정이 한꺼번에 열릴 수 있다.

따라서 보안 비용은 별도 프로젝트가 아니라 DR센터 구축 비용의 한 줄이어야 한다.

리스크	비용 항목	점검 기준	실패 시 영향
권한 과다	IAM 설계, break-glass 계정, 승인 로그	복구 권한이 평소 계정과 분리되어 있는가	장애 대응 중 내부자 오남용이나 계정 탈취가 발생
키와 인증서 누락	KMS, HSM, 인증서 백업, 갱신 절차	복구 리전에 키와 인증서가 준비되어 있는가	서버는 켜졌지만 TLS와 DB 암호화가 풀리지 않음
로그 공백	SIEM 연동, 로그 저장소, 시간 동기화	복구 환경의 로그가 원본과 같은 보존 정책을 따르는가	사후 분석과 감사 대응 자료가 부족해짐
네트워크 우회	방화벽 정책, 세그먼트, VPN, 전용회선	임시 allow rule이 훈련 뒤 제거되는가	복구 후 열린 포트가 장기 취약점으로 남음
라이선스 위반	OS, DB, 보안 솔루션, 백업 에이전트	DR 목적의 대기 인스턴스 라이선스 조건을 확인했는가	복구 성공 뒤 사용권 비용이나 계약 리스크 발생

DR센터 구축 비용 산정 스켈레톤

아래 예시는 실제 계약에 바로 넣는 문서가 아니라 견적 비교 전에 빠진 항목을 찾기 위한 검증용 스켈레톤이다.

# dr_center_cost_plan.yaml
# 목적: DR센터 구축 비용 비교 전에 업무별 RTO/RPO와 과금 항목을 누락 없이 점검한다.
dr_center_cost_plan:
  currency: USD_or_KRW
  review_cycle: quarterly
  workloads:
    - name: payment-core
      owner: service-owner
      rto_minutes: 30
      rpo_minutes: 5
      pattern: warm_standby
      protected_servers: 24
      source_storage_tb: 12
      daily_change_rate_percent: 3.5
      retention_days: 14
      test_failover_hours_per_quarter: 8
      network:
        primary_path: dedicated_line_or_cloud_private_link
        backup_path: separate_carrier_or_vpn
        dns_switch_minutes: 10
      security:
        break_glass_required: true
        kms_key_replicated: true
        siem_connected: true
      monthly_cost_inputs:
        drs_server_hour_usd: 0.028
        azure_asr_instance_month_usd: 25
        storage_gib_month_usd: official_price_before_quote
        replication_network_month_krw: carrier_quote
        operations_hours_month: internal_or_msp_quote
  exclusions:
    - name: dev-sandbox
      reason: rebuild_from_iac_within_24h
  approval:
    business_owner: required
    security_owner: required
    infrastructure_owner: required

스켈레톤의 핵심은 숫자보다 승인 구조다.

업무 오너가 RTO와 RPO를 승인하지 않으면 인프라팀이 임의로 비싼 DR 등급을 떠안게 된다.

# dr_center_monthly_cost_check.py
# 목적: 공식 단가와 내부 견적을 대입해 월 예산의 빠진 축을 찾는 검증용 코드다.
def estimate_aws_drs_monthly(protected_servers, hours, staging_storage_gb, snapshot_gb):
    drs = protected_servers * 0.028 * hours
    gp3_storage = staging_storage_gb * 0.08
    snapshot = snapshot_gb * 0.05
    return {
        "drs_server_hours_usd": round(drs, 2),
        "gp3_storage_usd": round(gp3_storage, 2),
        "snapshot_usd": round(snapshot, 2),
        "subtotal_usd": round(drs + gp3_storage + snapshot, 2),
    }


def estimate_azure_asr_monthly(protected_instances, replica_storage_usd, egress_usd, drill_compute_usd):
    license_fee = protected_instances * 25
    return {
        "asr_license_usd": license_fee,
        "replica_storage_usd": replica_storage_usd,
        "egress_usd": egress_usd,
        "drill_compute_usd": drill_compute_usd,
        "subtotal_usd": round(license_fee + replica_storage_usd + egress_usd + drill_compute_usd, 2),
    }


if __name__ == "__main__":
    print(estimate_aws_drs_monthly(100, 730, 15360, 37708))
    print(estimate_azure_asr_monthly(40, 1800, 350, 260))

이 코드는 의사결정용 검산 예시일 뿐이며, 실제 견적에는 리전별 공식 가격표와 사업자 제안서의 최신 단가를 다시 넣어야 한다.