Cert Notes/ 출퇴근 학습 노트
로드맵
KOEN
CLF-C02 · FoundationalCloud Practitioner - Foundational
  • Week 1
    • 1.클라우드 컴퓨팅이란 무엇인가
    • 2.AWS 글로벌 인프라
    • 3.공동 책임 모델
    • 4.Well-Architected Framework 6대 기둥과 클라우드 채택 가치
    • 5.Week 1 종합: 클라우드 개념 복습
  • Week 2
    • 1.컴퓨팅 개요: EC2, Lambda, 그리고 컨테이너(ECS/Fargate)
    • 2.스토리지 개요: S3(객체), EBS(블록), EFS·FSx(파일)
    • 3.네트워킹 기초: VPC, 서브넷, 보안 그룹, 인터넷 게이트웨이
    • 4.콘텐츠 전송과 DNS: CloudFront, Route 53, 엣지 서비스
    • 5.Week 2 종합 — 핵심 서비스 1 복습
  • Week 3
    • 1.데이터베이스 개요: 같은 "DB"라도 쓰임새가 다르다
    • 2.애플리케이션 통합: 시스템을 느슨하게 연결하기
    • 3.관리·모니터링 도구: 시스템을 지켜보고 추적하기
    • 4.배포·자동화·기타: 인프라를 코드로, 그리고 서버 없이
    • 5.Week 3 종합 — 핵심 서비스 2 복습
  • Week 4
    • 1.공동 책임 모델 심화와 IAM의 기본기
    • 2.보안 서비스 한눈에 보기: 어떤 위협을 막는가
    • 3.규정 준수: 증명서, 인증 프로그램, 그리고 데이터의 국적
    • 4.데이터 보호의 기본: 암호화, 키 관리, 비밀 보관
    • 5.Week 4 종합: 보안과 규정 준수 한 번에 정리
  • Week 5
    • 1.요금 모델: 같은 컴퓨팅도 어떻게 사느냐에 따라 가격이 다르다
    • 2.비용 관리 도구: 얼마 썼는지 보고, 새기 전에 막는다
    • 3.지원 플랜: 문제가 생겼을 때 AWS는 어떻게 돕는가
    • 4.청구 구조: 여러 계정을 하나로 결제하고, 미리 비용을 가늠한다
    • 5.Week 5 종합: 청구·요금·지원 한 번에 복습
  • Week 6
    • 1.도메인 복습 1: 클라우드 개념 + 클라우드 기술 및 서비스 핵심 총정리
    • 2.도메인 복습 2: 보안 및 규정 준수 + 청구·요금·지원 핵심 총정리
    • 3.전체 모의고사 페이스: 4개 도메인 종합
    • 4.자주 틀리는 함정·키워드: "키워드→서비스" 번역표
    • 5.D-Day 마무리: 시험 구성, 시간 배분, 마지막 점검 체크리스트
DVA-C02 · AssociateDeveloper - Associate
SAA-C03 · AssociateSolutions Architect - Associate
SOA-C02 · AssociateCloudOps Engineer - Associate
SAP-C02 · ProfessionalSolutions Architect - Professional
DOP-C02 · ProfessionalDevOps Engineer - Professional
SCS-C03 · SpecialtySecurity - Specialty
MLA-C01 · AssociateMachine Learning Engineer - Associate
AIF-C01 · FoundationalAI Practitioner - Foundational
DEA-C01 · AssociateData Engineer - Associate
MLS-C01 · SpecialtyMachine Learning - Specialty
합격 후기
← CLF-C02/Week 1/Day 2
CLF-C02· AssociateWeek 1 · Day 2읽기 약 17분

Day 2 - AWS 글로벌 인프라

📌 핵심 정리

  • 계층은 리전 > 가용 영역(AZ) > 데이터센터 3단. 리전 ≠ 데이터센터 한 곳, AZ ≠ 데이터센터 한 곳이다.
  • 리전은 서로 완전히 독립. 선택 기준 4가지 — 지연 시간, 규정 준수, 서비스 가용성, 비용.
  • AZ는 전력·냉방·네트워크가 독립된 시설. 리전당 보통 3개 이상. 2개 이상 AZ에 나눠 배치 = 고가용성 설계.
  • 엣지 로케이션은 사용자와 가까운 콘텐츠 전달 거점(전 세계 수백 곳). CloudFront·Route 53이 여기서 동작한다.
  • 대부분은 리전 서비스(EC2·RDS·S3), IAM·Route 53·CloudFront는 글로벌 서비스.

먼저, 왜 이런 구조가 필요했나

Day 1에서 "클라우드는 남의 서버를 빌려 쓰는 것"이라고 했다. 그런데 그 서버는 어딘가에 물리적으로 존재한다. 건물이 있고, 전기가 들어오고, 인터넷 회선이 꽂혀 있다. 여기서 세 가지 현실적인 문제가 생긴다.

  1. 거리는 속도다 — 데이터도 빛보다 빠를 수 없다. 서울 사용자가 지구 반대편 서버에 요청을 보내면 왕복하는 데 물리적으로 시간이 걸린다. 화면이 "느리다"고 느껴지는 원인이 대부분 이것이다.
  2. 나라마다 법이 다르다 — "우리나라 국민의 개인정보는 국내에 보관해야 한다" 같은 규정이 있다. 서버가 어느 나라에 있는지가 법적 문제가 된다.
  3. 건물은 사고를 당한다 — 정전, 화재, 홍수, 지진. 서버를 한 건물에 몰아 두면 그 건물 사고가 곧 서비스 전체의 중단이다.

AWS의 글로벌 인프라는 이 세 문제에 대한 답이다. 리전은 1·2번(거리와 법)을, 가용 영역은 3번(사고)을, 엣지 로케이션은 다시 1번(거리)을 더 촘촘하게 푼다. 이 대응 관계만 잡아 두면 오늘 내용은 절반쯤 끝난 셈이다.

문제해결하는 인프라
멀어서 느리다 / 특정 국가에 둬야 한다사용자·법규에 맞는 리전 선택 (+ 엣지 로케이션)
건물 하나가 통째로 죽으면?같은 리전 안 여러 **가용 영역(AZ)**에 분산
도시·국가 전체가 마비되면?여러 리전에 분산(재해 복구)

리전(Region): 세계 곳곳의 거점

  • 리전 = AWS가 데이터센터를 모아 둔 지리적 지역. 서울, 도쿄, 버지니아 북부, 프랑크푸르트처럼 전 세계 여러 곳에 있다.
  • 사용자는 서비스를 만들 때 어느 리전에 둘지 직접 고른다.
  • 리전에는 ap-northeast-2(서울), us-east-1(버지니아 북부) 같은 코드가 붙는다. 콘솔·설정 파일에서 이 코드로 리전을 지정한다.

💡 개념: 리전 코드는 지역-방향-번호 규칙으로 읽으면 쉽다. ap는 아시아 태평양(Asia Pacific), us는 미국, eu는 유럽을 뜻하고, 뒤에 northeast(북동), west(서) 같은 방향과 순번이 붙는다. 즉 ap-northeast-2는 "아시아 태평양 북동쪽 두 번째 리전"이라는 뜻이다. 외울 필요는 없지만, 문항에 코드가 등장했을 때 당황하지 않을 정도로만 익혀 두자.

리전을 고를 때 보통 다음 4가지를 따진다.

고려 요소의미
지연 시간(거리)사용자와 가까운 리전일수록 응답이 빠름
규정 준수"데이터를 국내에 보관" 같은 법적 요구 충족
서비스 가용성모든 서비스가 모든 리전에 있는 것은 아님
비용같은 서비스라도 리전마다 가격이 다를 수 있음

4가지 기준을 실제 상황에 대입하면 이렇게 쓰인다.

기준이런 상황에서 결정적이 된다
규정 준수금융·의료·공공처럼 "데이터는 국내에" 요구가 있는 경우. 다른 기준을 이긴다
지연 시간사용자 대다수가 한 나라에 몰려 있는 서비스. 사용자와 가까운 리전이 정답
서비스 가용성쓰려는 신규 서비스가 아직 그 리전에 없을 수 있다. 미리 확인 필요
비용같은 사양이라도 리전마다 요금이 다르다. 지연 시간이 덜 중요한 배치 작업이라면 저렴한 리전도 선택지

⚠️ 함정: 네 기준 중 규정 준수는 협상 대상이 아니다. "지연 시간이 조금 늘더라도 법을 지켜야 하는가, 법을 어기더라도 빨라야 하는가"를 묻는 문항은 없다. 지문에 "데이터 주권", "국내 보관 의무", "특정 국가를 벗어나면 안 됨" 같은 표현이 나오면 비용·지연 시간 보기는 전부 오답이고 규정 준수가 답이다.

💡 관련 이론: 리전은 서로 완전히 독립적으로 운영된다. 한 리전에서 문제가 생겨도 다른 리전에는 영향을 주지 않도록 격리되어 있다. 그래서 중요한 서비스를 여러 리전에 나누어 두면, 한 지역 전체에 장애가 나도 다른 지역에서 계속 서비스할 수 있다. 이것이 재해 복구(DR) 설계의 기본 아이디어다.

이 독립성에는 중요한 부작용이 하나 있다. 리전이 격리되어 있다는 말은 "자동으로 복사되지 않는다"는 뜻이기도 하다. 서울 리전에 만든 가상 서버나 저장된 파일은 도쿄 리전에서 그냥 보이지 않는다. 다른 리전에서도 쓰고 싶다면 고객이 명시적으로 복제를 설정해야 한다. 이 점이 시험에서 자주 함정으로 쓰인다.

📚 사례: 한국 사용자 대상 서비스라면 보통 서울 리전을 고른다. 그런데 이 회사가 동남아로 넓히면 고민이 시작된다 — 서울 하나로 갈지, 현지 리전을 추가할지. 판단은 앞의 4가지로 한다. 현지 개인정보 규정이 있는가(규정 준수), 체감 속도가 문제 될 만큼 먼가(지연 시간), 쓰던 서비스가 그 리전에 있는가(서비스 가용성), 두 리전 운영 비용을 감당할 수 있는가(비용). 시험도 이런 상황에서 "가장 중요한 고려 사항"을 고르라고 묻는다.

가용 영역(Availability Zone, AZ): 리전 안의 독립된 묶음

  • 하나의 리전은 다시 여러 개의 **가용 영역(AZ)**으로 나뉜다.
  • 각 AZ는 하나 이상의 물리적 데이터센터로 이루어진, 전력·냉방·네트워크가 독립된 시설이다.
  • AWS의 모든 리전은 보통 3개 이상의 AZ를 가진다.
  • 왜 나눠 두었나: 한 데이터센터에 정전이나 화재가 나도 다른 AZ는 멀쩡하도록, 즉 장애가 번지지 않도록 물리적으로 떨어뜨려 둔 것이다.
  • 그러면서도 AZ끼리는 빠른 전용 네트워크로 연결되어 있어 데이터를 거의 실시간으로 주고받는다.
        [ 리전: 서울 (ap-northeast-2) ]
                     |
      +--------+--------+--------+--------+
      |        |        |        |
    AZ-a     AZ-b     AZ-c     AZ-d   ← 각 AZ는 독립된 전력·네트워크
      |        |        |        |
   데이터센터  데이터센터  데이터센터  데이터센터

핵심 활용법은 간단하다. 서비스를 한 AZ에만 두지 말고 2개 이상의 AZ에 나누어 두면, 한 AZ가 통째로 죽어도 서비스가 살아남는다 → 고가용성(High Availability) 설계.

AZ가 하나 죽으면 실제로 무슨 일이 벌어지나

말로만 "고가용성"이라고 하면 잘 와닿지 않는다. 같은 서비스를 두 가지 방식으로 만들어 놓고, 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면 소용없다. 전력·냉방·네트워크를 공유하는 묶음이 통째로 내려가기 때문이다. "서버 대수"가 아니라 **"어디에 흩어 놓았는가"**가 생존을 가른다.
  • 좋은 설계: 트래픽을 나눠 주는 장치(로드 밸런서)가 죽은 AZ를 빼고 살아 있는 쪽으로만 요청을 보낸다. 데이터베이스도 다른 AZ에 대기본을 두면 그쪽이 주 역할을 넘겨받는다.

즉 AZ는 **"장애를 가두는 방화벽"**이다. AWS가 AZ끼리 거리를 두는 이유도 여기 있다 — 같은 홍수·정전에 함께 당하지 않을 만큼은 떨어뜨리되, 데이터를 실시간으로 주고받을 만큼은 가깝게.

⚠️ 함정: "가용 영역을 여러 개 쓰면 재해 복구(DR)까지 된다"는 보기는 틀렸다. AZ 분산은 한 리전 안에서의 고가용성이다. 지진이나 광역 정전으로 그 지역 전체가 영향을 받으면 같은 리전의 AZ들은 함께 위험해질 수 있다. 도시·국가 규모의 재해에 대비하려면 다른 리전에 복제를 두어야 한다. 문항에서 "한 건물·한 시설 장애" → AZ 분산, "지역 전체 재해" → 멀티 리전으로 구분하자.

💡 관련 이론: "리전 ≠ 데이터센터 한 곳"이고 "AZ ≠ 데이터센터 한 곳"이라는 점이 시험 포인트다. 리전은 여러 AZ의 묶음, AZ는 하나 이상의 데이터센터의 묶음이다. 즉 리전 > AZ > 데이터센터 순서의 3단 구조로 기억하면 된다.

엣지 로케이션(Edge Location): 사용자에게 더 가까이

  • 리전·AZ보다 훨씬 많은 수로, 사용자와 더 가까운 곳에 흩어져 있는 콘텐츠 전달용 거점. 전 세계 수백 곳에 있다.
  • 대표 용도는 CloudFront(콘텐츠 전송 네트워크, CDN).
    • 예: 미국 서버의 이미지를 한국 사용자가 볼 때 매번 미국까지 다녀오면 느리다.
    • 한국 근처 엣지 로케이션에 그 이미지를 미리 복사(캐싱)해 두면 사용자는 가까운 곳에서 빠르게 받아 본다.
  • 이 외에 Route 53(DNS) 같은 서비스도 엣지에서 동작한다.

💡 관련 이론: 리전·AZ는 "데이터와 연산을 두는 곳"이고, 엣지 로케이션은 "사용자에게 빠르게 전달하는 곳"이라는 역할 차이를 기억하자. 엣지에 콘텐츠를 캐싱하면 응답 속도가 빨라질 뿐 아니라 원본 서버의 부담도 줄어든다.

엣지 로케이션이 푸는 문제를 생활 비유로 바꾸면 동네 편의점이다. 물류창고(리전)는 전국에 몇 곳뿐이라 물건을 받으려면 오래 걸린다. 그래서 자주 팔리는 물건은 미리 동네 편의점(엣지)에 갖다 놓는다. 손님은 가까운 편의점에서 바로 받아 가고(빠름), 창고는 주문이 줄어 한가해진다(부하 감소).

  • 첫 요청은 캐시가 비어 있으니 원본까지 다녀온다(느림).
  • 그다음 요청부터는 엣지에 남아 있는 사본을 바로 준다(빠름).
  • 그래서 똑같은 콘텐츠를 많은 사람이 반복해서 받는 경우(이미지, 동영상, 정적 파일, 소프트웨어 배포)에 효과가 가장 크다.

📚 사례: 국내에만 서버를 둔 쇼핑몰이 해외 판매를 시작했다고 하자. 해외 고객은 상품 이미지 하나를 볼 때마다 한국까지 왕복해야 해서 페이지가 눈에 띄게 느리다. 리전을 옮기면 이번엔 국내 고객이 느려진다. 이럴 때 답이 CDN이다. 원본은 서울 리전에 그대로 두고, 이미지·CSS·동영상 같은 정적 콘텐츠만 전 세계 엣지에 캐싱하면 양쪽 모두 빨라진다. "서버를 옮기지 않고 해외 사용자 체감 속도를 개선"이라는 지문이 나오면 정답은 거의 CloudFront다.

리전 · AZ · 엣지, 한눈에 구분하기

셋은 이름이 비슷해서 자꾸 섞인다. **"무엇을 위해 존재하는가"**로 나눠 기억하는 게 가장 안전하다.

구분정체존재 이유개수 감각고객이 하는 일
리전데이터센터 묶음이 있는 지리적 지역거리·법규·재해 분산나라·도시 단위로 여럿어느 리전에 만들지 선택
가용 영역(AZ)리전 안의, 전력·냉방·네트워크가 독립된 시설 묶음한 시설 장애가 번지지 않게리전당 보통 3개 이상여러 AZ에 분산 배치
데이터센터실제 건물물리적 실체AZ당 하나 이상직접 다루지 않음
엣지 로케이션사용자 가까운 콘텐츠 전달 거점전송 지연 감소·원본 부하 감소전 세계 수백 곳CDN·DNS 사용

여기에 하나 더, 시험에 이름이 등장할 수 있는 것이 있다.

  • 로컬 존(Local Zone): 리전의 일부를 사용자가 많은 대도시 가까이로 확장해 둔 것. 엣지처럼 "가깝다"는 목적은 같지만, 엣지가 콘텐츠를 캐싱하는 곳이라면 로컬 존은 연산·저장을 실제로 돌리는 곳이라는 점이 다르다. 아주 낮은 지연 시간이 필요한 특수한 경우에 쓴다.

⚠️ 함정: "엣지 로케이션에 애플리케이션을 배포한다"는 보기는 기본적으로 틀렸다고 보면 된다. 엣지의 본래 역할은 콘텐츠 전달과 캐싱이지 서비스 실행 기반이 아니다. 애플리케이션과 데이터베이스는 리전 안의 AZ에서 돌아간다.

글로벌 서비스 vs 리전 서비스

AWS 서비스는 크게 두 종류로 나뉜다. 이 구분은 시험에 자주 나온다.

구분의미예시
리전 서비스특정 리전에 묶여 동작. 리전을 고르고 사용EC2(가상 서버), RDS(데이터베이스), S3 등 대부분의 서비스
글로벌 서비스리전과 무관하게 전 세계 하나로 동작IAM(사용자·권한), Route 53(DNS), CloudFront(CDN)
  • 대부분의 서비스는 "어느 리전에 둘지"를 골라야 하는 리전 서비스다.
  • 반면 IAM(계정·권한 관리), Route 53(도메인 DNS), CloudFront(엣지 캐싱)처럼 본질적으로 전 세계에 걸쳐 동작해야 하는 것들은 글로벌 서비스다.

글로벌인지 리전인지 헷갈릴 때는 **"이게 전 세계에 하나만 있어야 말이 되는가?"**를 자문해 보면 대체로 맞는다.

  • 사용자 계정과 권한(IAM)이 리전마다 따로 있으면? 서울에서는 관리자인데 도쿄에서는 아니라는 뜻이 된다 — 말이 안 된다. → 글로벌
  • 도메인 이름(Route 53)이 리전마다 다르면? 접속하는 위치에 따라 다른 사이트가 뜬다 — 말이 안 된다. → 글로벌
  • 엣지 캐싱(CloudFront)은 애초에 전 세계에 뿌리는 것이 목적이다. → 글로벌
  • 반면 가상 서버(EC2)나 데이터베이스(RDS)는 "어디에 둘지"가 곧 지연 시간과 규정 준수 문제다. → 리전
서비스구분이유
EC2 · RDS · EBS리전(정확히는 AZ에 배치)실제 연산·저장이 특정 위치에서 일어남
S3리전(버킷 이름만 글로벌)데이터는 지정한 리전에 저장
IAM글로벌계정 전체에 하나로 적용되어야 함
Route 53글로벌어디서 접속하든 같은 도메인 이름
CloudFront글로벌(엣지)전 세계 엣지에 콘텐츠를 뿌리는 것이 목적
WAF글로벌 배포와 함께 동작CloudFront 앞단에서 요청을 걸러 줌

💡 관련 이론: S3는 헷갈리기 쉬운 예다. S3 버킷 이름은 전 세계에서 유일해야 하지만(글로벌 네임스페이스), 실제 데이터는 특정 리전에 저장된다. 즉 이름은 글로벌, 데이터는 리전이다. "버킷 이름이 글로벌하다고 데이터까지 전 세계에 복제되는 것은 아니다"라는 점을 꼭 구분하자.

시험에는 이렇게 나온다

글로벌 인프라 문항은 지문에 답의 힌트가 거의 그대로 들어 있다. 아래 대응만 익혀도 대부분 풀린다.

문항에 이런 표현이 보이면답은 이쪽
"데이터를 특정 국가 밖으로 내보낼 수 없다", "데이터 주권"규정 준수 → 해당 국가의 리전 선택
"사용자와 가까워 응답이 빠른", "지연 시간 최소화"사용자 가까운 리전 선택
"한 데이터센터/시설 장애에도 서비스 지속"여러 AZ에 분산(고가용성)
"지역 전체 재해, 광역 장애에 대비"여러 리전에 복제(재해 복구)
"전 세계 사용자에게 이미지·동영상을 빠르게"엣지 로케이션 / CloudFront(CDN)
"원본 서버 부하를 줄이면서 전송 속도 개선"캐싱 / CloudFront
"도메인 이름 등록·DNS 라우팅"Route 53 (글로벌)
"사용자·권한을 계정 전체에 하나로 관리"IAM (글로벌)
"이 리전에서는 아직 그 서비스를 못 쓴다"서비스 가용성(리전 선택 기준)
"같은 사양인데 리전마다 요금이 다르다"비용(리전 선택 기준)
  • 보기에 **"모든 리전에 자동으로 복제된다"**는 표현이 있으면 대개 오답이다. 리전 간 복제는 고객이 설정해야 한다.
  • "AZ는 데이터센터 한 곳", "리전은 데이터센터 한 곳" 같은 보기도 오답이다. 둘 다 묶음이다.

다음 글에서는 이 인프라 위에서 "보안과 운영의 책임이 AWS와 고객 중 누구에게 있는가"를 정하는 공동 책임 모델을 본다.

📖 용어

  • 리전(Region) : AWS가 데이터센터를 모아 둔 지리적 지역. 서울, 도쿄처럼 나라·도시 단위로 있다.
  • 가용 영역(AZ) : 리전 안에 있는, 전력·냉방·네트워크가 서로 독립된 시설 묶음. 하나 이상의 데이터센터로 이루어진다.
  • 엣지 로케이션 : 사용자 가까이에 콘텐츠를 미리 갖다 놓는 작은 거점. 리전보다 훨씬 많다.
  • 캐싱 : 자주 쓰는 데이터를 가까운 곳에 미리 복사해 두고 빠르게 꺼내 쓰는 것.
  • CDN(콘텐츠 전송 네트워크) : 전 세계 엣지에 콘텐츠를 뿌려 사용자에게 빠르게 전달하는 구조. AWS에서는 CloudFront.
  • 고가용성(High Availability) : 일부가 고장 나도 서비스가 멈추지 않도록 만드는 설계. AZ 2개 이상에 나눠 두는 것이 기본.
  • 재해 복구(DR) : 한 지역 전체가 마비돼도 다른 지역에서 서비스를 이어가도록 대비하는 것.
  • 리전 서비스 vs 글로벌 서비스 : 특정 리전에 묶여 동작하는가(EC2·RDS·S3), 리전과 무관하게 전 세계 하나로 동작하는가(IAM·Route 53·CloudFront).
  • 글로벌 네임스페이스 : 이름이 전 세계에서 딱 하나여야 하는 규칙. S3 버킷 이름이 그렇다(데이터 자체는 특정 리전에 저장된다).
  • 지연 시간(Latency) : 요청을 보내고 응답이 올 때까지 걸리는 시간. 거리가 멀수록 커진다.
  • 리전 코드 : ap-northeast-2(서울)처럼 리전을 가리키는 식별자. 지역-방향-번호 형태로 읽는다.
  • 로드 밸런서 : 들어오는 요청을 여러 서버에 나눠 주는 장치. 죽은 AZ를 빼고 살아 있는 쪽으로 보낸다.
  • 로컬 존(Local Zone) : 리전의 일부를 대도시 가까이로 확장한 것. 엣지와 달리 연산·저장을 실제로 수행한다.
  • 데이터 주권 : 데이터가 어느 나라의 법 적용을 받는가의 문제. "국내 보관 의무"가 대표적이다.
  • 멀티 AZ / 멀티 리전 : 여러 AZ에 분산(고가용성) / 여러 리전에 분산(재해 복구). 대비하는 사고의 규모가 다르다.
  • 오리진(Origin) : CDN이 캐싱해 갈 원본이 있는 곳. 보통 리전 안의 서버나 스토리지다.

한 줄 요약

AWS 글로벌 인프라는 "거리·법규·사고"라는 세 가지 물리적 현실에 대한 답이다.

  • 리전 > AZ > 데이터센터 3단 구조. 리전도 AZ도 "데이터센터 한 곳"이 아니라 묶음이다.
  • 리전 선택은 규정 준수 · 지연 시간 · 서비스 가용성 · 비용 4가지로 판단하고, 규정 준수는 다른 기준을 이긴다.
  • 한 시설 장애 → 여러 AZ 분산(고가용성), 지역 전체 재해 → 여러 리전(재해 복구). 이 둘을 섞지 말자.
  • 엣지 로케이션은 실행하는 곳이 아니라 전달하는 곳이다. 반복해서 내려받는 콘텐츠에 효과가 크다.
  • 대부분은 리전 서비스, IAM · Route 53 · CloudFront는 글로벌. S3는 이름만 글로벌, 데이터는 리전.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

AWS 인프라의 구성 단위를 큰 것부터 작은 것 순으로 올바르게 나열한 것은?

문제 2

한 AZ에 장애가 발생해도 서비스가 중단되지 않게 하려면 가장 적절한 방법은?

문제 3

미국 서버의 이미지를 한국 사용자에게 더 빠르게 전달하기 위해 사용자와 가까운 곳에 콘텐츠를 캐싱하는 데 쓰이는 인프라는?

문제 4

다음 중 리전과 무관하게 전 세계 하나로 동작하는 글로벌 서비스는?

문제 5

리전을 선택할 때 고려할 요소로 보기 어려운 것은?

이전클라우드 컴퓨팅이란 무엇인가Week 1 · Day 1다음 공동 책임 모델Week 1 · Day 3

이 페이지

  • 핵심 정리
  • 먼저, 왜 이런 구조가 필요했나
  • 리전(Region): 세계 곳곳의 거점
  • 가용 영역(Availability Zone, AZ): 리전 안의 독립된 묶음
  • AZ가 하나 죽으면 실제로 무슨 일이 벌어지나
  • 엣지 로케이션(Edge Location): 사용자에게 더 가까이
  • 리전 · AZ · 엣지, 한눈에 구분하기
  • 글로벌 서비스 vs 리전 서비스
  • 시험에는 이렇게 나온다
  • 용어
  • 한 줄 요약
  • 연습 문제