Day 1에서 "클라우드는 남의 서버를 빌려 쓰는 것"이라고 했다. 그런데 그 서버는 어딘가에 물리적으로 존재한다. 건물이 있고, 전기가 들어오고, 인터넷 회선이 꽂혀 있다. 여기서 세 가지 현실적인 문제가 생긴다.
AWS의 글로벌 인프라는 이 세 문제에 대한 답이다. 리전은 1·2번(거리와 법)을, 가용 영역은 3번(사고)을, 엣지 로케이션은 다시 1번(거리)을 더 촘촘하게 푼다. 이 대응 관계만 잡아 두면 오늘 내용은 절반쯤 끝난 셈이다.
| 문제 | 해결하는 인프라 |
|---|---|
| 멀어서 느리다 / 특정 국가에 둬야 한다 | 사용자·법규에 맞는 리전 선택 (+ 엣지 로케이션) |
| 건물 하나가 통째로 죽으면? | 같은 리전 안 여러 **가용 영역(AZ)**에 분산 |
| 도시·국가 전체가 마비되면? | 여러 리전에 분산(재해 복구) |
ap-northeast-2(서울), us-east-1(버지니아 북부) 같은 코드가 붙는다. 콘솔·설정 파일에서 이 코드로 리전을 지정한다.💡 개념: 리전 코드는
지역-방향-번호규칙으로 읽으면 쉽다.ap는 아시아 태평양(Asia Pacific),us는 미국,eu는 유럽을 뜻하고, 뒤에northeast(북동),west(서) 같은 방향과 순번이 붙는다. 즉ap-northeast-2는 "아시아 태평양 북동쪽 두 번째 리전"이라는 뜻이다. 외울 필요는 없지만, 문항에 코드가 등장했을 때 당황하지 않을 정도로만 익혀 두자.
리전을 고를 때 보통 다음 4가지를 따진다.
| 고려 요소 | 의미 |
|---|---|
| 지연 시간(거리) | 사용자와 가까운 리전일수록 응답이 빠름 |
| 규정 준수 | "데이터를 국내에 보관" 같은 법적 요구 충족 |
| 서비스 가용성 | 모든 서비스가 모든 리전에 있는 것은 아님 |
| 비용 | 같은 서비스라도 리전마다 가격이 다를 수 있음 |
4가지 기준을 실제 상황에 대입하면 이렇게 쓰인다.
| 기준 | 이런 상황에서 결정적이 된다 |
|---|---|
| 규정 준수 | 금융·의료·공공처럼 "데이터는 국내에" 요구가 있는 경우. 다른 기준을 이긴다 |
| 지연 시간 | 사용자 대다수가 한 나라에 몰려 있는 서비스. 사용자와 가까운 리전이 정답 |
| 서비스 가용성 | 쓰려는 신규 서비스가 아직 그 리전에 없을 수 있다. 미리 확인 필요 |
| 비용 | 같은 사양이라도 리전마다 요금이 다르다. 지연 시간이 덜 중요한 배치 작업이라면 저렴한 리전도 선택지 |
⚠️ 함정: 네 기준 중 규정 준수는 협상 대상이 아니다. "지연 시간이 조금 늘더라도 법을 지켜야 하는가, 법을 어기더라도 빨라야 하는가"를 묻는 문항은 없다. 지문에 "데이터 주권", "국내 보관 의무", "특정 국가를 벗어나면 안 됨" 같은 표현이 나오면 비용·지연 시간 보기는 전부 오답이고 규정 준수가 답이다.
💡 관련 이론: 리전은 서로 완전히 독립적으로 운영된다. 한 리전에서 문제가 생겨도 다른 리전에는 영향을 주지 않도록 격리되어 있다. 그래서 중요한 서비스를 여러 리전에 나누어 두면, 한 지역 전체에 장애가 나도 다른 지역에서 계속 서비스할 수 있다. 이것이 재해 복구(DR) 설계의 기본 아이디어다.
이 독립성에는 중요한 부작용이 하나 있다. 리전이 격리되어 있다는 말은 "자동으로 복사되지 않는다"는 뜻이기도 하다. 서울 리전에 만든 가상 서버나 저장된 파일은 도쿄 리전에서 그냥 보이지 않는다. 다른 리전에서도 쓰고 싶다면 고객이 명시적으로 복제를 설정해야 한다. 이 점이 시험에서 자주 함정으로 쓰인다.
📚 사례: 한국 사용자 대상 서비스라면 보통 서울 리전을 고른다. 그런데 이 회사가 동남아로 넓히면 고민이 시작된다 — 서울 하나로 갈지, 현지 리전을 추가할지. 판단은 앞의 4가지로 한다. 현지 개인정보 규정이 있는가(규정 준수), 체감 속도가 문제 될 만큼 먼가(지연 시간), 쓰던 서비스가 그 리전에 있는가(서비스 가용성), 두 리전 운영 비용을 감당할 수 있는가(비용). 시험도 이런 상황에서 "가장 중요한 고려 사항"을 고르라고 묻는다.
[ 리전: 서울 (ap-northeast-2) ]
|
+--------+--------+--------+--------+
| | | |
AZ-a AZ-b AZ-c AZ-d ← 각 AZ는 독립된 전력·네트워크
| | | |
데이터센터 데이터센터 데이터센터 데이터센터
핵심 활용법은 간단하다. 서비스를 한 AZ에만 두지 말고 2개 이상의 AZ에 나누어 두면, 한 AZ가 통째로 죽어도 서비스가 살아남는다 → 고가용성(High Availability) 설계.
말로만 "고가용성"이라고 하면 잘 와닿지 않는다. 같은 서비스를 두 가지 방식으로 만들어 놓고, AZ-a에 정전이 났다고 해 보자.
[ 나쁜 설계 ] 모두 AZ-a에 [ 좋은 설계 ] AZ-a / AZ-b 분산
웹서버 2대 ─┐ 웹서버 1대 ──┐ ┌── 웹서버 1대
DB 1대 ─┤ AZ-a ← 정전 DB(주) ──────┤ AZ-a │ AZ-b DB(대기)
─┘ └────────┘
→ 전부 동시에 중단. 복구 = AZ 복구 대기 → 살아 있는 AZ-b로 트래픽 이동, 서비스 지속
즉 AZ는 **"장애를 가두는 방화벽"**이다. AWS가 AZ끼리 거리를 두는 이유도 여기 있다 — 같은 홍수·정전에 함께 당하지 않을 만큼은 떨어뜨리되, 데이터를 실시간으로 주고받을 만큼은 가깝게.
⚠️ 함정: "가용 영역을 여러 개 쓰면 재해 복구(DR)까지 된다"는 보기는 틀렸다. AZ 분산은 한 리전 안에서의 고가용성이다. 지진이나 광역 정전으로 그 지역 전체가 영향을 받으면 같은 리전의 AZ들은 함께 위험해질 수 있다. 도시·국가 규모의 재해에 대비하려면 다른 리전에 복제를 두어야 한다. 문항에서 "한 건물·한 시설 장애" → AZ 분산, "지역 전체 재해" → 멀티 리전으로 구분하자.
💡 관련 이론: "리전 ≠ 데이터센터 한 곳"이고 "AZ ≠ 데이터센터 한 곳"이라는 점이 시험 포인트다. 리전은 여러 AZ의 묶음, AZ는 하나 이상의 데이터센터의 묶음이다. 즉 리전 > AZ > 데이터센터 순서의 3단 구조로 기억하면 된다.
💡 관련 이론: 리전·AZ는 "데이터와 연산을 두는 곳"이고, 엣지 로케이션은 "사용자에게 빠르게 전달하는 곳"이라는 역할 차이를 기억하자. 엣지에 콘텐츠를 캐싱하면 응답 속도가 빨라질 뿐 아니라 원본 서버의 부담도 줄어든다.
엣지 로케이션이 푸는 문제를 생활 비유로 바꾸면 동네 편의점이다. 물류창고(리전)는 전국에 몇 곳뿐이라 물건을 받으려면 오래 걸린다. 그래서 자주 팔리는 물건은 미리 동네 편의점(엣지)에 갖다 놓는다. 손님은 가까운 편의점에서 바로 받아 가고(빠름), 창고는 주문이 줄어 한가해진다(부하 감소).
📚 사례: 국내에만 서버를 둔 쇼핑몰이 해외 판매를 시작했다고 하자. 해외 고객은 상품 이미지 하나를 볼 때마다 한국까지 왕복해야 해서 페이지가 눈에 띄게 느리다. 리전을 옮기면 이번엔 국내 고객이 느려진다. 이럴 때 답이 CDN이다. 원본은 서울 리전에 그대로 두고, 이미지·CSS·동영상 같은 정적 콘텐츠만 전 세계 엣지에 캐싱하면 양쪽 모두 빨라진다. "서버를 옮기지 않고 해외 사용자 체감 속도를 개선"이라는 지문이 나오면 정답은 거의 CloudFront다.
셋은 이름이 비슷해서 자꾸 섞인다. **"무엇을 위해 존재하는가"**로 나눠 기억하는 게 가장 안전하다.
| 구분 | 정체 | 존재 이유 | 개수 감각 | 고객이 하는 일 |
|---|---|---|---|---|
| 리전 | 데이터센터 묶음이 있는 지리적 지역 | 거리·법규·재해 분산 | 나라·도시 단위로 여럿 | 어느 리전에 만들지 선택 |
| 가용 영역(AZ) | 리전 안의, 전력·냉방·네트워크가 독립된 시설 묶음 | 한 시설 장애가 번지지 않게 | 리전당 보통 3개 이상 | 여러 AZ에 분산 배치 |
| 데이터센터 | 실제 건물 | 물리적 실체 | AZ당 하나 이상 | 직접 다루지 않음 |
| 엣지 로케이션 | 사용자 가까운 콘텐츠 전달 거점 | 전송 지연 감소·원본 부하 감소 | 전 세계 수백 곳 | CDN·DNS 사용 |
여기에 하나 더, 시험에 이름이 등장할 수 있는 것이 있다.
⚠️ 함정: "엣지 로케이션에 애플리케이션을 배포한다"는 보기는 기본적으로 틀렸다고 보면 된다. 엣지의 본래 역할은 콘텐츠 전달과 캐싱이지 서비스 실행 기반이 아니다. 애플리케이션과 데이터베이스는 리전 안의 AZ에서 돌아간다.
AWS 서비스는 크게 두 종류로 나뉜다. 이 구분은 시험에 자주 나온다.
| 구분 | 의미 | 예시 |
|---|---|---|
| 리전 서비스 | 특정 리전에 묶여 동작. 리전을 고르고 사용 | EC2(가상 서버), RDS(데이터베이스), S3 등 대부분의 서비스 |
| 글로벌 서비스 | 리전과 무관하게 전 세계 하나로 동작 | IAM(사용자·권한), Route 53(DNS), CloudFront(CDN) |
글로벌인지 리전인지 헷갈릴 때는 **"이게 전 세계에 하나만 있어야 말이 되는가?"**를 자문해 보면 대체로 맞는다.
| 서비스 | 구분 | 이유 |
|---|---|---|
| EC2 · RDS · EBS | 리전(정확히는 AZ에 배치) | 실제 연산·저장이 특정 위치에서 일어남 |
| S3 | 리전(버킷 이름만 글로벌) | 데이터는 지정한 리전에 저장 |
| IAM | 글로벌 | 계정 전체에 하나로 적용되어야 함 |
| Route 53 | 글로벌 | 어디서 접속하든 같은 도메인 이름 |
| CloudFront | 글로벌(엣지) | 전 세계 엣지에 콘텐츠를 뿌리는 것이 목적 |
| WAF | 글로벌 배포와 함께 동작 | CloudFront 앞단에서 요청을 걸러 줌 |
💡 관련 이론: S3는 헷갈리기 쉬운 예다. S3 버킷 이름은 전 세계에서 유일해야 하지만(글로벌 네임스페이스), 실제 데이터는 특정 리전에 저장된다. 즉 이름은 글로벌, 데이터는 리전이다. "버킷 이름이 글로벌하다고 데이터까지 전 세계에 복제되는 것은 아니다"라는 점을 꼭 구분하자.
글로벌 인프라 문항은 지문에 답의 힌트가 거의 그대로 들어 있다. 아래 대응만 익혀도 대부분 풀린다.
| 문항에 이런 표현이 보이면 | 답은 이쪽 |
|---|---|
| "데이터를 특정 국가 밖으로 내보낼 수 없다", "데이터 주권" | 규정 준수 → 해당 국가의 리전 선택 |
| "사용자와 가까워 응답이 빠른", "지연 시간 최소화" | 사용자 가까운 리전 선택 |
| "한 데이터센터/시설 장애에도 서비스 지속" | 여러 AZ에 분산(고가용성) |
| "지역 전체 재해, 광역 장애에 대비" | 여러 리전에 복제(재해 복구) |
| "전 세계 사용자에게 이미지·동영상을 빠르게" | 엣지 로케이션 / CloudFront(CDN) |
| "원본 서버 부하를 줄이면서 전송 속도 개선" | 캐싱 / CloudFront |
| "도메인 이름 등록·DNS 라우팅" | Route 53 (글로벌) |
| "사용자·권한을 계정 전체에 하나로 관리" | IAM (글로벌) |
| "이 리전에서는 아직 그 서비스를 못 쓴다" | 서비스 가용성(리전 선택 기준) |
| "같은 사양인데 리전마다 요금이 다르다" | 비용(리전 선택 기준) |
다음 글에서는 이 인프라 위에서 "보안과 운영의 책임이 AWS와 고객 중 누구에게 있는가"를 정하는 공동 책임 모델을 본다.
ap-northeast-2(서울)처럼 리전을 가리키는 식별자. 지역-방향-번호 형태로 읽는다.AWS 글로벌 인프라는 "거리·법규·사고"라는 세 가지 물리적 현실에 대한 답이다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
AWS 인프라의 구성 단위를 큰 것부터 작은 것 순으로 올바르게 나열한 것은?
문제 2
한 AZ에 장애가 발생해도 서비스가 중단되지 않게 하려면 가장 적절한 방법은?
문제 3
미국 서버의 이미지를 한국 사용자에게 더 빠르게 전달하기 위해 사용자와 가까운 곳에 콘텐츠를 캐싱하는 데 쓰이는 인프라는?
문제 4
다음 중 리전과 무관하게 전 세계 하나로 동작하는 글로벌 서비스는?
문제 5
리전을 선택할 때 고려할 요소로 보기 어려운 것은?