들어가며
AWS 서울 리전에서 인프라를 구성하다 보면 한 번쯤 이런 장면을 본다. 회사 표준 아키텍처 문서에도, 검색해서 나오는 블로그에도 서브넷은 늘 ap-northeast-2a와 ap-northeast-2c에 있다.
이유를 물어보면 대개 "a랑 c가 제일 안정적이라서"라는 답이 돌아온다. 그런데 정말 그럴까. AWS가 어디선가 "a존과 c존이 더 튼튼하다"고 말한 적이 있을까. 이 글은 그 질문에서 출발해, 가용 영역(AZ)이 물리적으로 무엇인지, 왜 서울 리전에는 이런 관행이 생겼는지, 그리고 실제 설계에서는 어떻게 해야 하는지를 정리한다.
1. 리전과 가용 영역, 정확히 무엇인가
먼저 용어를 짚고 가자. AWS의 인프라는 리전(Region) 과 가용 영역(Availability Zone, AZ) 이라는 두 층으로 이루어진다.
리전은 지리적으로 독립된 지역이다. 서울(ap-northeast-2), 도쿄(ap-northeast-1), 버지니아(us-east-1)처럼 도시 단위로 존재하며, 리전끼리는 서로 완전히 독립되어 있다. 한 리전이 통째로 장애를 겪어도 다른 리전은 영향을 받지 않는다.
가용 영역은 리전 안에 있는 하나 이상의 독립된 데이터센터 묶음이다. 여기서 "독립"은 전원, 냉각, 물리 보안, 네트워크 회선이 각각 따로 있다는 뜻이다. 같은 리전 안의 AZ들은 서로 수 킬로미터에서 수십 킬로미터 떨어져 있고, AWS 전용 광케이블로 연결되어 있다. AZ 사이의 왕복 지연은 보통 1~2ms 수준이다.
온프레미스(IDC) 경험이 있는 분이라면 이렇게 대응시키면 이해가 빠르다.
이중화 층위 IDC에서 AWS에서
| 같은 랙의 서버 2대 | 가장 흔한 "이중화" | 하나의 AZ 안 |
| 다른 랙, 다른 전원 계통 | 조금 더 신경 쓴 이중화 | 여전히 하나의 AZ 안 |
| 다른 건물 (예: 목동 IDC + 평촌 IDC) | 은행·통신사급 | AZ 두 개 |
| 다른 도시 | DR 센터 (평소엔 대기) | 리전 두 개 |
즉 AZ 두 개에 서브넷을 나누는 것은 "서버를 두 대 두는 것"이 아니라, 서울 시내의 서로 다른 두 데이터센터 건물에 시스템을 동시에 운영하는 것과 같다. IDC에서 이걸 직접 하려면 두 센터 계약, 센터 간 전용선, 양쪽 네트워크 장비, DB 동기 복제 솔루션이 모두 필요하다.
AWS에서는 VPC가 처음부터 여러 AZ에 걸쳐 있으므로 서브넷을 만들 때 AZ만 다르게 고르면 된다. AWS가 판매하는 것은 "다른 건물"이 아니라 "다른 건물을 같은 네트워크처럼 쓰는 경험" 이다.
2. AZ 이름의 정체: a, b, c는 물리 위치가 아니다
여기서 많은 사람이 놓치는 사실이 하나 있다. ap-northeast-2a라는 이름은 물리적인 데이터센터를 가리키지 않는다.
AWS는 AZ 글자를 계정마다 다르게 매핑한다. 내 계정의 us-east-1a가 다른 회사 계정에서는 us-east-1c일 수 있다. 이유는 단순하다. 모든 사용자가 습관적으로 'a'를 고르면 특정 데이터센터에만 부하가 몰리기 때문에, AWS가 의도적으로 글자를 섞어 부하를 분산시킨다.
물리적 위치를 나타내는 진짜 식별자는 AZ ID다. 서울 리전은 apne2-az1부터 apne2-az4까지, 버지니아는 use1-az1부터 use1-az6까지 있다. 다음 명령으로 내 계정의 매핑을 확인할 수 있다.
aws ec2 describe-availability-zones --region ap-northeast-2 \
--query "AvailabilityZones[].[ZoneName, ZoneId, State]" --output table
------------------------------------------------
| DescribeAvailabilityZones |
+-------------------+-------------+------------+
| ap-northeast-2a | apne2-az1 | available |
| ap-northeast-2b | apne2-az2 | available |
| ap-northeast-2c | apne2-az3 | available |
| ap-northeast-2d | apne2-az4 | available |
+-------------------+-------------+------------+
서울 리전은 위처럼 글자와 ID가 순서대로 대응되는 경우가 많다고 알려져 있지만, 이것이 보장되는 것은 아니다. 계정 간 VPC 피어링, AZ 간 데이터 전송 비용, 여러 계정에 걸친 아키텍처를 논의할 때는 반드시 AZ ID를 기준으로 이야기해야 한다.
이 사실만으로도 "a존과 c존이 더 안정적"이라는 명제는 흔들린다. 글자가 계정마다 다른 건물을 가리킨다면, 특정 글자에 안정성이 붙을 수가 없다.
3. 그렇다면 왜 서울에서는 a, c 관행이 생겼나
3-1. 역사: 3년 동안 a와 c밖에 없었다
서울 리전은 2016년 1월에 문을 열었다. 이때 AZ는 두 개였고, 이름은 ap-northeast-2a와 ap-northeast-2c였다. b는 처음부터 비어 있었다.
세 번째 AZ인 ap-northeast-2b는 2019년 5월에, 네 번째 AZ인 ap-northeast-2d는 2020년 7월에 추가되었다. 즉 서울 리전이 열리고 3년 넘는 기간 동안 "이중화 = a, c"는 선택이 아니라 유일한 옵션이었다. 그 시기에 작성된 강의, 블로그, 회사의 테라폼 모듈, 운영 문서가 모두 a/c로 쓰였고, 이후에 들어온 사람들은 그것을 그대로 물려받았다.
왜 처음부터 b를 건너뛰었는지는 AWS가 공식적으로 설명한 적이 없다. 다른 리전에서도 글자를 건너뛴 사례가 있어, 내부 계획상 예약된 자리였을 것이라는 추측만 있다.
3-2. 경험: 나중에 생긴 AZ는 지원 범위가 달랐다
두 번째 이유는 실무자들의 경험이다. 나중에 추가된 2b는 초기에 t2 같은 구형 인스턴스 타입을 지원하지 않았다. t2.micro를 2b에 띄우려다가 "이 AZ에서는 지원되지 않으니 2a 또는 2c를 사용하라"는 오류를 본 사람이 많았다. 2d는 더 제한적으로, 특정 인스턴스 패밀리만 지원했다.
이런 경험이 쌓이면서 "a, c에서는 뭐든 되는데 b, d는 가끔 안 된다"는 인식이 생겼고, 이것이 구전되면서 "a, c가 안정적이다"로 변형되었다. 여기서 '안정'의 실제 의미는 장애가 적다가 아니라 인스턴스 타입과 서비스 커버리지가 넓다에 가깝다.
AZ별 인스턴스 타입 지원 여부는 다음 명령으로 직접 확인할 수 있다.
aws ec2 describe-instance-type-offerings \
--location-type availability-zone \
--filters Name=instance-type,Values=t2.micro \
--region ap-northeast-2 \
--query "InstanceTypeOfferings[].Location"
4. "오래된 AZ가 더 안정적"이라는 가설은 성립하는가
관행의 기원을 알고 나서도 이런 생각이 들 수 있다. "그래도 오래 운영된 a, c가 검증되어 더 안정적이지 않을까?"
이 가설은 근거가 반대 방향으로도 똑같이 성립하기 때문에, 결론은 "알 수 없으며, 설계에 반영해서는 안 된다"이다.
첫째, "오래 썼으니 검증되었다"는 논리는 소프트웨어에는 맞지만 물리 시설에는 맞지 않는다. AZ는 건물과 전력·냉각·네트워크 장비다. 물리 시설은 시간이 지날수록 검증되는 것이 아니라 노후화된다. AWS가 하드웨어를 지속적으로 교체하므로 "낡았다"는 과장이지만, 최소한 "오래되어 더 튼튼하다"는 성립하지 않는다. 오히려 2019~2020년에 지어진 b, d가 더 최신 설계 기준을 따랐을 가능성이 높다.
둘째, 실무에서 실제로 겪는 '불안정'은 시설 장애가 아니라 용량 부족이다. 인스턴스를 띄우려는데 InsufficientInstanceCapacity 오류가 나는 경우다. 이 오류는 사용자가 몰린 AZ에서 더 자주 발생하고, 서울에서 사용자가 몰린 곳은 당연히 a와 c다. 최신 인스턴스 타입이나 GPU 인스턴스는 오히려 b, d에 여유가 있는 경우가 실제로 있다.
셋째, AWS는 AZ별 장애 통계를 공개하지 않으며 SLA도 리전 단위로 제공한다. "a가 b보다 안정적이다"는 누구도 데이터로 증명할 수 없는 명제이고, 이것을 근거로 설계하면 아키텍처 리뷰에서 "근거가 무엇인가"라는 질문에 답할 수 없다.
AWS 아키텍처의 대전제는 "어떤 AZ든 죽을 수 있다" 이다. 따라서 해법은 특정 AZ를 신뢰하는 것이 아니라, 어떤 AZ가 죽어도 서비스가 유지되도록 만드는 것이다.
5. 다른 리전에서도 a, c를 써야 하나
아니다. "a, c 이중화"는 서울 리전의 역사가 만든 지역 관행이다.
흥미롭게도 도쿄 리전(ap-northeast-1)에도 비슷한 관행이 있다. 초창기에 1b가 신규 계정에서 사용할 수 없었고 1d는 2018년에야 추가되어, 오래된 자료가 대부분 1a/1c로 작성되었다. 반면 버지니아(us-east-1)는 a부터 f까지 여섯 개의 AZ가 있어 a/b 또는 a/b/c로 구성하는 것이 일반적이고, 프랑크푸르트(eu-central-1)는 a/b/c 세 개다. 리전마다 사정이 전부 다르다.
AWS가 공식적으로 권장하는 것은 "AZ를 두 개 이상, 가능하면 사용 가능한 AZ 전체에 분산하라"까지이며, 어느 글자를 쓰라는 지침은 어디에도 없다.
6. 실무에서는 어떻게 설계해야 하나
지금까지의 내용을 설계 원칙으로 정리하면 다음과 같다.
분산은 AWS에게 맡긴다.
Auto Scaling 그룹과 로드밸런서에는 여러 AZ의 서브넷을 모두 지정하고, 인스턴스 배치는 AWS가 알아서 하도록 둔다. RDS는 Multi-AZ 옵션을 켜면 대기 인스턴스가 자동으로 다른 AZ에 배치된다.
물리 위치를 말할 때는 AZ ID를 쓴다.
계정 간 통신, AZ 간 데이터 전송 비용, 특정 인스턴스 타입의 재고 문제를 논의할 때는 글자가 아니라 apne2-az1 같은 ID로 소통해야 오해가 없다.
AZ의 한계를 알고 리전으로 보완한다.
같은 리전의 AZ들은 같은 수도권 안에 있다. 광역 정전이나 지진, 그리고 리전 전체에 걸친 서비스(IAM, 리전 API 엔드포인트) 장애에는 함께 영향을 받는다. 이 수준의 재해까지 대비하려면 다른 리전이 필요하다. 다만 리전 간 지연은 수십 ms 이상이므로 동기 복제는 불가능하고, 어느 정도의 데이터 손실(RPO)을 감수하는 비동기 복제가 된다. 정리하면 AZ는 데이터 손실 없이(RPO 0) 건물 장애를 견디는 이중화, 리전은 일부 지연을 감수하며 도시 장애를 견디는 이중화다. 둘은 같은 이중화가 아니라 RPO가 다른 이중화다.
마치며
"서울 리전 이중화는 a, c존"이라는 말은 틀린 것은 아니다. 2016년부터 2019년까지는 그것이 유일한 방법이었고, 지금도 a와 c를 고르면 문제없이 동작한다. 그러나 "a, c가 더 안정적이라서"라는 이유는 근거가 없으며, 이 관행을 다른 리전에 그대로 가져가면 "왜 b를 비워두는가"라는 질문을 받게 된다.
AZ 글자는 계정마다 다른 건물을 가리키는 임의의 이름이고, AWS는 어떤 AZ든 장애가 날 수 있다는 전제 위에서 설계되어 있다. 그러니 특정 AZ를 믿는 대신, 분산 자체를 믿는 설계를 하자. 그것이 AWS가 AZ라는 개념을 만든 이유다.
참고 자료
'AWS > 기초' 카테고리의 다른 글
| EC2 인스턴스 타입과 요금 옵션 — AWS는 왜 서버를 이렇게 잘게 쪼개서 팔까 (0) | 2026.09.11 |
|---|---|
| EC2는 "클라우드에 있는 서버"가 아니다 — 온프레미스 서버와 EC2의 진짜 차이 (0) | 2026.09.10 |
댓글