[fundamentals] AWS 기초 용어 — 리전·AZ·고가용성부터

이 노트는 가장 먼저 읽는 토대다. 다른 모든 concept-note는 여기 나오는 용어(리전·AZ·고가용성·내구성·수평 확장 등)를 이미 안다고 전제하고 쓰여 있다. 여기서 그 전제를 채운다.

One-Line Summary

AWS 문제를 풀려면 서비스 이름보다 먼저 "어디서 돌아가고(글로벌 인프라), 죽어도 버티는가(안정성), 늘어나면 어떻게 감당하고(확장성), 누가 관리하며(운영 모델), 빠른가(성능)" 라는 다섯 축의 기본 개념을 알아야 한다. 시험 지문의 대부분이 이 다섯 축의 요구를 돌려 말한 것이다.

1. 글로벌 인프라 — 어디서 돌아가나

AWS는 전 세계에 물리 인프라를 계층적으로 두고 있다. 이 3층을 구분하는 게 시작이다.

┌─ Region: Seoul ap-northeast-2 ──────────────────────────┐   ┌─ Region: Tokyo ──┐
│ ┌─ AZ-a ────────┐  ┌─ AZ-b ────────┐  ┌─ AZ-c ────────┐ │   │   ...            │
│ │ datacenter(s) │  │ datacenter(s) │  │ datacenter(s) │ │   └──────────────────┘
│ └───────────────┘  └───────────────┘  └───────────────┘ │
└─────────────────────────────────────────────────────────┘
리전끼리는 물리적으로 멀리 떨어져 완전 격리 · AZ끼리는 같은 리전 안에서 저지연 연결

왜 여러 AZ에 나눠 배치하나? — 데이터센터도 정전·화재·네트워크 장애가 난다. 한 AZ에만 두면 그게 죽을 때 서비스 전체가 멈춘다. 여러 AZ에 나눠 두면 하나가 죽어도 나머지가 버틴다. 이게 고가용성의 출발점이다. (실제 배치 예: network/vpc-and-subnets)

시험 감각: "여러 리전" 키워드 = 글로벌 서비스·리전 DR·데이터 주권. "여러 AZ" 키워드 = 고가용성(HA).

2. 안정성 — 죽어도 버티는가 (가장 중요)

시험의 절반은 "장애가 나도 서비스가 유지되는가"를 묻는다. 아래 용어들이 미묘하게 다르니 정확히 구분한다.

[ SPOF ]  한 대 / 한 AZ만 → 그게 죽으면 서비스 전체 중단
┌─ SPOF ───────────────┐
│ Web EC2  (AZ-a only) │
└──────────────────────┘

[ Redundant ]  여러 AZ에 복제 → 하나 죽어도 나머지가 계속
┌─ Redundant (HA) ─────────┐
│ ┌─────────┐  ┌─────────┐ │
│ │ Web EC2 │  │ Web EC2 │ │
│ │ (AZ-a)  │  │ (AZ-c)  │ │
│ └─────────┘  └─────────┘ │
└──────────────────────────┘

내구성 vs 가용성(자주 혼동): 내구성 = 데이터를 잃지 않음, 가용성 = 지금 접근 가능함. S3는 내구성이 극도로 높지만(11 9s), 그렇다고 "항상 100% 접근 가능"이라는 뜻은 아니다(가용성은 별개 수치).

재해 복구 (DR) — RTO / RPO

리전급 재해에 대비해 얼마나 빨리 복구하고(RTO), 얼마만큼의 데이터 손실을 감수하나(RPO) 로 목표를 잡는다.

RTO·RPO가 작을수록(0에 가까울수록) 더 빠른 복구·더 적은 손실 → 더 비싼 구성(예: 다중 리전 액티브). 관련: database/aurora(Global Database), network/route-53(Failover).

3. 확장성 — 늘어나면 어떻게 감당하나

부하가 커질 때 키우는 방향이 두 가지다. 시험은 거의 항상 "수평 확장(scale out)"을 선호한다(더 탄력적·고가용).

시험 감각: "트래픽이 예측 불가·급증한다 / 부하에 따라 자동으로" = 수평 확장 + Auto Scaling/Elasticity. "한 대를 더 키운다"만 답이면 대개 오답 유도.

4. 운영 모델 — 누가 관리하나

AWS를 쓴다고 모든 책임이 사라지는 게 아니다. 경계선을 아는 게 핵심이다.

공동 책임 모델 (Shared Responsibility Model)

AWS 책임  ── "클라우드 자체(OF the cloud)"  : 물리 하드웨어·데이터센터·네트워크·기반 소프트웨어
─────────────────────────────────────────────
고객 책임 ── "클라우드 안(IN the cloud)"    : 내 데이터·접근 권한(IAM)·암호화 설정·보안 그룹·OS 패치(해당 시)

예: AWS가 물리 서버 보안은 책임지지만, 내 S3 버킷을 퍼블릭으로 열어 유출되면 그건 고객 책임이다.

관리형(Managed) vs 비관리형, 서버리스

시험 감각: "운영 부담 최소화 / 서버 관리 없이" = 관리형·서버리스 쪽으로. "직접 세밀 제어 필요" = 비관리형(EC2 등).

5. 성능·설계 — 빠른가, 잘 나뉘어 있나

시험 감각: "컴포넌트 간 결합을 줄여 장애 전파 방지 / 트래픽 급증 완충" = 디커플링(SQS/SNS/EventBridge). "전 세계 사용자 지연 감소" = 엣지(CloudFront).

용어 빠른 정리 (Glossary)

Memory Sentence

AWS는 Region(격리된 지역) 안에 여러 AZ(독립 데이터센터)를 두고, 여러 AZ에 나눠 배치하면 고가용성(HA)이 된다. 안정성은 SPOF 제거·이중화로 만들고, 내구성(데이터 안 잃음)과 가용성(지금 접근 가능)은 다른 축이며 DR은 RTO·RPO로 잰다. 확장은 수평(scale out)+Elasticity가 정석, 운영은 관리형·서버리스로 부담을 줄이고 책임은 공동 책임 모델로 나눈다. 성능은 지연·처리량으로 보고, 컴포넌트는 디커플링(SQS/SNS)으로 느슨하게 묶는다.

여기서 이어지는 노트

• 실제 VPC·AZ 배치: network/vpc-and-subnets · network/network-overview
• 고가용성 DB: database/rds(Multi-AZ) · database/aurora
• 확장·서버리스: compute/ec2(Auto Scaling) · compute/lambda
• 디커플링: compute/sqs · compute/sns · compute/eventbridge
• 내구성·스토리지: storage/s3 · storage/storage-comparison

References

• AWS Global Infrastructure
• Regions and Availability Zones
• Shared Responsibility Model
• AWS Well-Architected Framework