AWS "일부 데이터는 복구 불가" — 바레인·UAE 가용영역 사태가 남긴 DR 교훈 | 뉴스

AWS가 2026년 3월 드론 공격으로 피해를 입은 중동 데이터센터에 대해, 특정 가용영역(AZ)에만 존재하던 데이터의 복구가 불가능하다고 확인했다. 해당 AZ는 바레인 리전의 mec1-az2와 UAE 쪽 한 개 영역으로 알려졌다.

AWS 설명의 핵심은 피해 범위가 리전·멀티 AZ 서비스가 견디도록 설계된 수준을 넘어섰다는 것이다. 구조적 손상에 더해 전력 중단과 소화 과정에서의 수침 피해가 겹쳤다. 대부분의 고객은 백업 복원이나 다른 리전 복사로 운영을 재개했지만, 해당 AZ에만 있던 데이터는 남지 않았다.

클라우드를 쓰는 사람들 사이에서 "AZ가 통째로 사라진다"는 시나리오는 오랫동안 이론 연습에 가까웠다. 설계 문서에는 쓰지만 실제로 일어나리라 믿고 예산을 쓰는 팀은 드물었다. 이번 사건은 그 가정을 바꾼다. 물리적 인프라는 물리 세계의 사건에 노출돼 있고, 클라우드 사업자의 SLA는 그 사건을 되돌려 주지 못한다.

사실관계 정리

2026년 3월 초

바레인·UAE 소재 AWS 시설이 드론 공격으로 피해. 이란 혁명수비대가 공격을 주장한 것으로 보도됐다.

피해 직후

구조적 손상, 전력 중단, 소화 작업으로 인한 수침 피해가 복수의 가용영역에 걸침.

이후 6개월

대부분 고객은 백업 복원·타 리전 복사로 운영 재개. 두 곳의 서비스는 재개되지 않음.

2026-09 중순

AWS가 해당 AZ에만 존재하던 데이터·리소스의 복구가 불가능하다고 공식 안내. 재개 시점은 제시하지 않고 내년 초 추가 공지 예정이라고 밝힘.

용어 정리 가용영역(AZ)은 리전 안에서 전력·냉각·네트워크가 물리적으로 분리된 데이터센터 묶음이다. 멀티 AZ 구성은 한 AZ의 장애를 견디도록 설계된 것이지, 복수 AZ가 동시에 물리적으로 파괴되는 상황을 상정하지 않는다. 그 경계가 이번에 드러났다.

멀티 AZ는 백업이 아니다 — 가장 흔한 오해

실무에서 자주 보는 착각이 있다. RDS를 멀티 AZ로 켜 뒀으니 백업은 됐다는 생각, S3는 내구성 11 나인이니 안전하다는 생각. 둘 다 반은 맞고 반은 틀리다. 복제는 가용성을 위한 장치이고, 백업은 복구를 위한 장치다. 복제는 잘못된 삭제도 그대로 복제하고, 리전 경계를 넘지 않으면 리전 단위 사건에 함께 사라진다.

장치	막아 주는 것	막지 못하는 것
멀티 AZ 복제	단일 AZ 하드웨어·전력 장애	복수 AZ 동시 피해, 논리적 삭제·손상
동일 리전 스냅샷	인스턴스 손실, 실수 삭제	리전 전체에 영향을 주는 사건
크로스 리전 복제	리전 단위 사건	계정 탈취 후의 삭제, 복제 지연 구간의 데이터
오프라인·불변 백업	랜섬웨어, 계정 탈취, 광범위 물리 피해	복원 절차를 아무도 모를 때

지금 당장 확인할 수 있는 것들

DR 자가 점검

✓가장 중요한 데이터가 물리적으로 몇 개의 리전에 존재하는지 답할 수 있는가

✓마지막으로 "복원"을 실제로 해 본 것이 언제인가 — 백업 성공 로그가 아니라 복원 성공 기록

✓RPO(얼마까지 잃어도 되나)와 RTO(얼마 만에 복구해야 하나)를 숫자로 합의했는가

✓복제본이 원본과 같은 권한 경계 안에 있지는 않은가 (계정 탈취 시 함께 삭제되는 구조)

✓IaC·시크릿·DNS 설정까지 복구 대상에 포함돼 있는가 — 데이터만 살아나도 서비스는 못 뜬다

✓복구 절차서가 담당자 한 명의 머릿속에만 있지 않은가

# 크로스 리전 백업의 최소 형태 (예시)
# 1) S3 복제 규칙 — 다른 리전 + 별도 계정 버킷으로
aws s3api put-bucket-replication --bucket prod-data \
  --replication-configuration file://replication.json

# 2) RDS 스냅샷을 타 리전으로 복사 (자동화 스케줄)
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier arn:aws:rds:ap-northeast-2:...:snapshot:prod-2026-09-16 \
  --target-db-snapshot-identifier prod-2026-09-16-dr \
  --source-region ap-northeast-2 --region ap-southeast-1

# 3) 핵심은 여기 — 분기에 한 번, 복원 리허설
#    "스냅샷에서 새 인스턴스를 띄우고 애플리케이션을 붙여 쿼리가 되는지"까지가 리허설이다.

비용 이야기를 피하지 말자

크로스 리전 백업은 공짜가 아니다. 스토리지 비용이 이중으로 들고, 리전 간 전송료가 붙는다. 그래서 대부분의 팀이 "중요한 것만"이라는 애매한 기준으로 타협한다. 그 타협 자체는 합리적이다. 다만 타협의 결과를 문서로 남기는 것이 중요하다. 어떤 데이터가 리전 단위 사건에서 소실 대상인지 경영진이 알고 승인했는가. 이번 사건에서 가장 아픈 대화는 기술적 대화가 아니라 그 대화였을 것이다.

분리해서 얻는 것

리전 단위 사건에서의 생존
규제·감사 대응 근거
인수합병·계약 협상에서의 신뢰

치르는 비용

스토리지 이중화 비용
리전 간 전송 요금
복제 파이프라인 운영 부담
정합성 관리 복잡도 증가

교훈 — 클라우드는 위험을 없애지 않고 옮긴다

클라우드 도입의 초기 서사는 "데이터센터 운영 리스크를 사업자에게 넘긴다"였다. 이번 사건이 보여 주는 건 그 리스크가 사라진 게 아니라 다른 모양으로 남는다는 사실이다. 내가 통제할 수 없는 곳에서 발생하고, 내 복구 계획으로만 방어할 수 있는 형태로. 사업자의 책임 공유 모델은 언제나 같은 말을 해 왔다. 인프라는 우리가, 데이터는 당신이.

출처

CNBC, "AWS can't restore service to Bahrain, UAE 6 months after Iran strikes" (2026-09-15) — https://www.cnbc.com/2026/09/15/aws-cant-restore-service-to-bahrain-uae-6-months-after-iran-strikes.html
Help Net Security, "Iranian strikes on AWS facilities left customer data beyond recovery" — https://www.helpnetsecurity.com/2026/09/17/aws-middle-east-outage-permanent-data-loss-bahrain-uae/
The Register, "AWS says wartime damage means some Middle East cloud resources are gone for good" — https://www.theregister.com/off-prem/2026/09/16/aws-says-wartime-damage-means-some-middle-east-cloud-resources-are-gone-for-good/

자주 묻는 질문

멀티 AZ로 구성하면 데이터가 안전한가요?

단일 AZ 장애에는 안전하지만 리전 전체나 복수 AZ에 영향을 주는 사건에는 취약합니다. 멀티 AZ는 가용성 장치이고 백업은 복구 장치라는 점을 구분해야 합니다. 이번 사례에서 피해 범위는 멀티 AZ 서비스가 견디도록 설계된 수준을 넘어섰습니다.

어떤 데이터를 크로스 리전으로 백업해야 하나요?

잃으면 사업이 중단되거나 법적 의무를 위반하는 데이터가 1순위입니다. 결제·계약·회원 원장, 그리고 서비스 재구축에 필요한 IaC와 시크릿입니다. 반대로 재생성 가능한 캐시·파생 데이터는 우선순위를 낮춰 비용을 아끼되, 그 결정을 문서로 남겨 승인받아 두세요.

복원 리허설은 얼마나 자주 해야 하나요?

핵심 시스템은 분기 1회를 권합니다. 백업 작업 성공 로그는 복원 가능성을 보장하지 않습니다. 스냅샷에서 실제 인스턴스를 띄우고 애플리케이션을 연결해 쿼리가 되는 지점까지 확인해야 리허설입니다. 소요 시간을 측정해 RTO 수치를 갱신하세요.

클라우드 사업자가 보상해 주지 않나요?

서비스 약관상 배상은 일반적으로 이용료 크레딧 수준으로 제한되며, 소실된 데이터의 사업적 가치를 보전하지 않습니다. 책임 공유 모델에서 데이터 백업은 고객 책임으로 규정돼 있습니다. 보험이나 계약 조건으로 별도 대비가 필요합니다.

온프레미스로 돌아가는 게 답인가요?

일반화하기 어렵습니다. 자체 데이터센터도 물리적 사건에 노출되며 이중화 비용은 더 큽니다. 요점은 위치가 아니라 설계입니다. 데이터가 물리적으로 분리된 두 곳 이상에 존재하고, 그 복사본에서 실제로 복구해 본 적이 있는가가 핵심 질문입니다.