가용 영역은 전쟁을 가정하지 않았다 — AWS 중동 리전 데이터 손실과 장애 도메인의 재정의

리전 하나가 물리적으로 사라졌을 때, 그것은 클라우드의 실패인가, 아니면 처음부터 고객 몫이던 설계의 공백인가?

도입

2026년 9월 15일(태평양 시간), AWS는 서비스 상태 페이지에 두 개의 공지를 올렸다. 하나는 중동(바레인) 리전 me-south-1에 대한 것이고, 다른 하나는 중동(UAE) 리전 me-central-1에 대한 것이다. 바레인 공지의 핵심 문장은 이렇다. 인프라 손상이 여러 가용 영역(Availability Zone, AZ)에 걸쳐 있었고, 리전 서비스와 멀티 AZ 서비스가 견디도록 설계된 수준을 넘어섰으며, 철저한 평가 끝에 이 리전에만 호스팅된 리소스와 데이터에 대한 접근을 복구할 수 없다고 판단했다는 것이다. UAE 공지는 범위가 좁다. mec1-az2 가용 영역에만 있던 리소스와 데이터의 접근을 복구할 수 없다고 밝혔다.

이 소식은 Wall Street Journal의 「AWS says it can’t restore some data from mideast facilities struck by Iran」라는 기사로 해커뉴스 1면에 올라 530점을 받았다. WSJ 기사 본문은 유료 장벽 때문에 이 글을 쓰면서 확인하지 못했다. 그래서 이 글은 AWS 상태 페이지의 RSS 피드에 남아 있는 공지 원문과, 이를 전한 Techzine과 Developing Telecoms의 보도를 1차 근거로 삼는다. 공격 주체에 대해 AWS 자신은 「중동에서 진행 중인 분쟁」과 「드론 공격」이라고만 적었고, 이란이라는 국가명은 WSJ 제목과 일부 보도에서 나온다는 점을 먼저 밝혀 둔다.

이 사건은 클라우드 엔지니어에게 낯익은 단어들, 즉 가용 영역, 11 나인 내구성, 공동 책임 모델을 전혀 다른 맥락에서 다시 읽게 만든다. 이 글은 공지 원문에서 확인되는 사실을 먼저 정리하고, 그다음 멀티 AZ 설계가 실제로 무엇을 약속했는지, 그리고 고객이 지금 무엇을 바꿔야 하는지를 따져 본다.

현상 분석 — 공지 원문으로 다시 쓴 6개월

AWS 상태 페이지의 me-south-1과 me-central-1 RSS 피드를 시간순으로 읽으면 사건의 윤곽이 꽤 선명하게 드러난다.

시작은 3월 1일이다. UAE 공지에 따르면 mec1-az2는 태평양 시간 3월 1일 오전 4시 무렵 전원이 꺼졌고, 그때까지 S3는 정상적으로 동작했다. 이어 두 번째 영역인 mec1-az3가 손상되면서 S3 오류율이 올라갔다. 같은 날 밤(태평양 시간) 바레인의 mes1-az2에서 API 오류 증가가 보고되었고, 초기 공지는 이를 「국지적 전원 문제」라고 불렀다.

원인이 공개된 것은 3월 2일 오후 공지다. AWS는 두 리전 모두 드론 공격으로 인프라에 물리적 영향을 받았다고 밝혔다. UAE에서는 시설 두 곳이 직접 타격을 받았고, 바레인에서는 시설 한 곳 근처에 떨어진 드론 공격이 인프라에 물리적 영향을 주었다. 그 결과 구조적 손상, 전력 공급 중단, 그리고 일부 경우에는 화재 진압 과정에서 발생한 추가 침수 피해가 있었다고 적었다. 같은 공지는 EC2, S3, DynamoDB, Lambda, Kinesis, CloudWatch, RDS, 관리 콘솔과 CLI에서 오류율 상승과 가용성 저하가 있다고 열거했다.

이 시점의 권고문을 보면 AWS는 꽤 일찍 리전 탈출을 권했다. 3월 2일 공지는 중동에 워크로드를 둔 고객에게 지금 바로 데이터를 백업하고 다른 리전으로 이전하는 것을 고려하라고 했고, 대안 리전으로 미국, 유럽, 아시아 태평양을 지연 시간과 데이터 레지던시 요건에 맞게 고르라고 안내했다. 바레인 리전에 대해서는 S3 데이터와 핵심 데이터를 다른 리전으로 복제하라는 권고가 3월 2일부터 3일까지 반복해서 나온다. RDS 멀티 AZ 데이터베이스는 데이터 보존을 위해 예방적으로 익스포트를 만들라는 권고도 있었다.

4월 30일 공지는 국면 전환이다. 바레인 리전은 중동 분쟁으로 손상을 입어 현재 사용할 수 없으며, 고객은 다른 리전에서 원격 백업으로 리소스를 복구해야 한다고 적었다. UAE 리전은 고객 애플리케이션을 안정적으로 지원할 수 없는 상태라고 했다. 두 리전 모두 관련 과금 처리를 중단했고, 복구에는 수개월이 걸릴 것이라고 했다.

그리고 9월 15일 공지가 나왔다. 바레인 공지에 따르면 첫 번째 AZ가 3월에 손상되었을 때부터 AWS는 다른 리전으로의 이전을 권고했고, 대부분의 고객은 4월에 두 번째 AZ가 중단되어 리전이 사용 불가능해지기 전에 이전을 마쳤다. 남은 고객은 가능한 경우 백업을 써서, 또는 접근할 수 없는 데이터의 영향을 줄이는 대안을 마련해서 다른 리전에서 운영을 재개하도록 지원했다고 한다. 영향을 받은 모든 인프라를 평가하고 이전되지 않은 데이터와 리소스를 복구할 모든 선택지를 소진했다는 문장이 그 뒤에 온다. 다음 업데이트는 2027년 초로 예고되었다.

UAE 공지는 조금 다르다. mec1-az2 전용 데이터는 복구 불가이지만, 리전 리소스와 다른 피해 영역(mec1-az1과 mec1-az3)의 영역 리소스는 계속 복구 중이라고 했다. 대부분의 고객은 백업을 복원하거나 접근 가능한 데이터를 복사해 다른 리전에서 운영을 재개했다고 적었다.

여기서 확인되지 않은 것도 분명히 해 두어야 한다. 몇 명의 고객이, 어떤 서비스의, 얼마만큼의 데이터를 잃었는지는 공개되지 않았다. 두 공지 원문 어디에도 고객 수나 데이터 양에 관한 수치는 없다. Techzine은 Bloomberg가 9월 15일에 아마존이 바레인 데이터센터와 UAE 네트워크 일부에 저장된 데이터에 접근할 수 없다고 보도했다고 전하면서, 이 표현이 바레인은 리전 전체이고 UAE는 한 영역뿐이라는 구분을 흐린다고 지적했다. 해커뉴스에서도 같은 질문이 나왔다. 어떤 제품이 영향을 받았는지 기사가 말하지 않으며, EBS나 단일 AZ S3라면 아마존 입장에서는 설계대로이고, 멀티 AZ S3라면 의미가 크게 달라진다는 지적이었다(@advisedwang, 직접 인용은 아니고, 코멘트의 요지를 요약).

심층 분석 — 멀티 AZ는 무엇을 약속했는가

이 사건을 둘러싼 논쟁의 중심에는 「11 나인」이 있다. 해커뉴스의 첫 번째 질문도 S3를 세 개의 가용 영역에 두었는데도 데이터가 사라졌다는 뜻이냐는 것이었다(@markive, 직접 인용은 아니고, 코멘트의 요지를 요약). 이에 대해 여러 이용자가 정정을 달았다. 11 나인은 보장이 아니라 「설계 목표」이며, S3의 SLA는 내구성이 아니라 가용성을 다룬다는 것(@advisedwang, @ciberado), 그리고 SLA에는 불가항력 면책 조항이 있다는 것(@beejiu, @stackskipton, 직접 인용은 아니고, 코멘트의 요지를 요약)이다. 한 이용자는 AWS 고객 계약의 불가항력 조항을 그대로 붙여 넣었는데, 거기에는 테러 행위와 전쟁이 명시되어 있다(@gilbetron, 직접 인용은 아니고, 코멘트의 요지를 요약).

더 흥미로운 것은 AWS가 이번 공지에서 고른 단어다. 「손상이 여러 가용 영역에 걸쳤고, 리전 서비스와 멀티 AZ 서비스가 견디도록 설계된 수준을 넘어섰다.」 이 문장은 멀티 AZ 설계의 장애 모델을 스스로 드러낸다. 3월 2일 UAE 공지는 이를 더 명시적으로 적었다. S3는 리전 서비스이며 단일 가용 영역의 완전한 손실을 견디면서 내구성과 가용성을 유지하도록 설계되었다는 것이다. 실제로 mec1-az2가 꺼졌을 때 S3는 정상 동작했고, 두 번째 영역이 손상되자 오류율이 올라갔다.

즉 멀티 AZ의 약속은 「동시에 하나의 영역이 사라지는 것」을 견디는 것이다. 영역 사이는 물리적으로 떨어져 있고 전원과 네트워크가 분리되어 있으므로, 화재나 정전, 홍수 같은 사고는 대개 한 영역에 국한된다. 이것은 무작위 장애에 대해서는 매우 합리적인 가정이다. 그런데 의도를 가진 공격은 무작위 장애가 아니다. 상관관계가 있다. 같은 국가, 같은 도시권에 있는 여러 시설이 같은 분쟁의 같은 표적 목록에 오를 수 있다. 장애 독립성의 가정이 깨지면 「세 개 중 두 개가 동시에 망가질 확률」은 곱셈으로 계산되지 않는다.

해커뉴스에서 이를 공학 용어로 정리한 코멘트가 있었다. FMECA(고장 모드, 영향 및 치명도 분석)를 수행하는 엔지니어는 의도적으로 배제한 고장 모드를 처음부터 명시해야 하는데, 데이터센터는 보통 전쟁이나 제국의 붕괴를 견디도록 설계되지 않는다는 것이다. 다만 바레인처럼 국가 자체가 상설 방공 시설을 지을 만큼 전쟁을 우려하는 곳이라면, 전쟁 가능성을 가용성 계산에 넣는 것이 합리적이라고 덧붙였다(@dhx, 직접 인용은 아니고, 코멘트의 요지를 요약).

전직 AWS 직원이라고 밝힌 이용자는 서비스 구조의 차이를 설명했다. AWS에는 단일 영역 제품이 있고, 그런 제품이 피해 영역에 있었다면 데이터는 사라진다. S3나 EFS 같은 멀티 AZ 제품은 한 영역을 장기간 잃으면 데이터 플레인이 샤드를 옮겨 다시 내구성 목표로 돌아간다는 것이다(@harshaw, 직접 인용은 아니고, 코멘트의 요지를 요약). 이 설명을 공지 원문과 겹쳐 보면, 바레인에서 멀티 AZ 서비스까지 손을 쓸 수 없었던 이유가 짐작된다. 재복제가 끝나기 전에 두 번째 영역이 사라지면, 재복제할 원천과 대상이 함께 줄어든다. 다만 이것은 추론이며, AWS가 기술적 사후 분석을 공개한 것은 아니다. 해커뉴스에서도 실제 기술 보고서를 보고 싶다는 요청이 나왔다(@purpleidea, 직접 인용은 아니고, 코멘트의 요지를 요약).

그렇다면 책임은 어디에 있는가. AWS의 공동 책임 모델은 대략 이렇게 요약된다. AWS는 클라우드 「자체」의 보안과 운영을 책임지고, 고객은 클라우드 「안의」 것, 즉 데이터, 구성, 그리고 어떤 리전과 어떤 내구성 옵션을 고를지를 책임진다. 리전 간 복제는 기본값이 아니라 고객이 켜고 비용을 내는 기능이다. 한 이용자는 S3 리전 간 복제나 다른 서비스의 리전 간 재해 복구를 켜 두고 비용을 낸 신중한 고객은 무사했을 것이라고 적었다(@gregw2, 직접 인용은 아니고, 코멘트의 요지를 요약). 다른 이용자는 이것이 정확히 설계대로이며 재해 복구용 백업을 다른 곳에 두는 것은 고객의 책임이라고 했다(@ernsheong, 직접 인용은 아니고, 코멘트의 요지를 요약). 반면 비판적인 쪽은 AWS 간부가 과거 CBS 인터뷰에서 데이터센터 하나가 폭파되어도 고객은 눈치채지 못할 것이라고 답한 장면을 끌어왔다(@cmiles8, 직접 인용은 아니고, 코멘트의 요지를 요약). 마케팅의 어조와 계약서의 문언 사이의 거리가 이번 사건에서 드러났다는 지적이다.

여기에 한 겹이 더 있다. 데이터 레지던시 규제다. 한 이용자는 UAE 의료 분야 고객과 일하면서 정부 요건 때문에 데이터를 UAE 안에만 저장해야 했다고 적었다(@rishikeshs, 직접 인용은 아니고, 코멘트의 요지를 요약). 다른 이용자는 데이터 레지던시 요구의 이면이 바로 이것이라고 했다(@carefree-bob, 직접 인용은 아니고, 코멘트의 요지를 요약). 이에 대한 반론도 있었다. EU의 경우 EDPB는 키가 EU 안에 남아 있고 안전한 이전 수단이 있다면 암호화된 백업을 역외에 두는 것을 명시적으로 인정한다는 것이다(@Barrin92, 직접 인용은 아니고, 코멘트의 요지를 요약). 한 나라에 리전이 하나뿐이고 그 나라의 법이 데이터 반출을 막는다면, 고객이 리전 간 복제를 켜고 싶어도 켤 수 없다. 이 경우 「고객 책임」이라는 말은 기술적으로는 맞지만 실무적으로는 공허해진다.

전망과 시사점 — 장애 도메인을 지도 위에 다시 그리기

이번 사건이 실무자에게 남기는 교훈은 새롭지 않다. 다만 그 교훈의 단위가 바뀌었다.

첫째, 장애 도메인의 단위를 「영역」에서 「지정학적 권역」으로 넓혀야 한다. 지금까지 많은 팀의 재해 복구 설계는 AZ 장애와 리전 장애를 구분했고, 리전 장애는 소프트웨어 버그나 제어 평면 문제로 인한 일시적 사건으로 상정했다. 이번 사건에서 리전은 수개월 단위로 사라졌고, 대안 리전으로 AWS가 권한 것은 이웃 리전이 아니라 미국, 유럽, 아시아 태평양이었다. 같은 분쟁권 안에 있는 두 리전을 서로의 백업으로 삼는 설계는, 이번 경우처럼 두 리전이 같은 날 함께 피해를 입으면 의미를 잃는다.

둘째, 「복제는 백업이 아니다」라는 오래된 경구를 다시 적어 둘 만하다. 해커뉴스의 한 코멘트도 복제는 검증된 백업이 아니라고 상기시켰다(@burnt-resistor, 직접 인용은 아니고, 코멘트의 요지를 요약). 다른 코멘트는 모든 백업이 AWS에 있다면 백업이 없는 것과 같다고까지 말했다(@KingOfCoders, 직접 인용은 아니고, 코멘트의 요지를 요약). 극단적인 표현이지만, 질문 자체는 유효하다. 백업이 원본과 같은 계정, 같은 공급자, 같은 법역에 있다면, 그 백업은 어떤 장애 모드를 막는가.

셋째, 경보에 반응하는 시간이 결과를 갈랐다는 점이다. AWS 공지에 따르면 3월 초부터 리전 이전을 권고했고, 대부분의 고객은 4월의 두 번째 영역 중단 전에 이전을 마쳤다. 즉 데이터를 잃은 쪽은 사전에 다른 리전 백업이 없었고, 약 두 달의 유예 기간 동안에도 데이터를 옮기지 못했거나 옮기지 않은 고객이다. 그 이유가 규제였는지, 비용이었는지, 단순한 관성이었는지는 공개된 자료로는 알 수 없다. 다만 「대규모 장애 공지가 나오면 몇 시간 안에 무엇을 할 것인가」를 런북에 미리 적어 두는 것의 가치는 분명하다.

실무적으로 정리하면 이렇다. 핵심 데이터에 대해 리전 간 복제나 다른 리전으로의 정기 백업을 켜고, 가능하면 별도 계정이나 별도 공급자에 사본을 두며, 복원을 실제로 연습한다. 데이터 레지던시 요건이 있는 경우에는 규제 당국이 암호화된 역외 백업을 어디까지 허용하는지 미리 확인해 둔다. 그리고 어떤 리전을 쓰는지 결정할 때, 지연 시간과 단가 외에 그 리전이 놓인 지정학적 위치를 위험 평가 항목으로 적어 둔다. 한 이용자는 뉴욕 지역 재해 복구 계획에서 리전 전체가 마비되는 사건을 「허리케인 샌디 2」라고 불러 왔는데, 이제 「AWS 바레인 2」를 예시로 추가할지도 모르겠다고 적었다(@alexpotato, 직접 인용은 아니고, 코멘트의 요지를 요약). 사이버 보험 쪽에서도 이런 대규모 데이터 손실 시나리오가 검증된 적이 없을 것이라는 우려가 나왔다(@DeepYogurt, 직접 인용은 아니고, 코멘트의 요지를 요약).

결론

AWS의 9월 15일 공지는 정직한 문서다. 손상이 멀티 AZ 서비스가 견디도록 설계된 수준을 넘어섰다고 스스로 인정했고, 3월부터 이전을 권고했다는 기록도 상태 페이지에 그대로 남아 있다. 계약서상으로는 불가항력 조항이 있고, 공동 책임 모델상으로는 리전 간 백업이 고객 몫이다. 그 점에서 이번 사건은 클라우드의 실패라기보다 설계 가정의 경계가 드러난 사건이다.

다만 그 경계가 어디에 있는지 고객이 미리 알 수 있었느냐는 다른 문제다. 가용 영역은 서로 독립적으로 고장 난다는 가정 위에 서 있고, 의도를 가진 공격은 그 독립성을 깨뜨린다. 데이터를 국경 안에 두라는 규제는 리전이 하나뿐인 나라에서 리전 간 백업이라는 고객의 선택지를 지운다.

당신의 서비스가 쓰는 리전 목록을 지도 위에 찍어 보라. 그 점들이 같은 분쟁, 같은 전력망, 같은 법역에 함께 묶여 있다면, 지금의 재해 복구 설계는 무엇을 막도록 만들어져 있는가.

출처: