AWS 클라우드 개념과 글로벌 인프라

AWS 설계를 시작할 때는 서비스 이름보다 먼저 데이터를 어디에 둘지, 장애를 어디까지 격리할지, 사용자에게 어떻게 전달할지를 정해야 한다. 이 세 질문의 기본 단위가 리전, 가용 영역, 엣지 로케이션이다. SAP 시험에서도 서비스 선택의 전제로 자주 등장한다.

1. 클라우드 컴퓨팅이란

AWS는 온디맨드(On-Demand) 방식으로 컴퓨팅 자원을 제공한다. 즉, 서버를 직접 구매하지 않고 필요한 만큼 빌려 쓰고, 사용한 만큼만 돈을 낸다.

클라우드의 핵심 특징은 다음 다섯 가지다.

2. AWS 글로벌 인프라 3계층

AWS 인프라는 크게 세 단계로 나뉜다.

리전 (Region)
  └── 가용 영역 (Availability Zone, AZ)
        └── 데이터 센터 (Physical Data Center)

엣지 로케이션 (Edge Location)  ← 별도 개념

2-1. 리전 (Region)

리전은 지리적으로 분리된 데이터 센터 클러스터다. 예: ap-northeast-2 = 서울 리전, us-east-1 = 버지니아 리전

리전을 선택할 때 고려해야 할 기준 (SAP 시험 자주 출제)

1. 법적 규제 (Compliance) — 가장 먼저 고려. 데이터가 특정 국가를 벗어나면 안 된다면 해당 국가 리전 필수
2. 지연 시간 (Latency) — 사용자와 가까운 리전
3. 서비스 가용성 — 모든 AWS 서비스가 모든 리전에 있지 않음
4. 비용 (Pricing) — 리전별 요금과 데이터 전송 비용이 다르므로 실제 구성으로 비교

선택 근거: 시험에서 "금융 데이터를 한국에서만 보관해야 한다"는 조건이 나오면 리전 선택이 설계의 첫 번째 제약 조건이 된다.

2-2. 가용 영역 (Availability Zone, AZ)

각 리전에는 최소 3개의 AZ가 있으며, 실제로 사용할 수 있는 AZ 수는 리전과 계정에 따라 다를 수 있다.

• 각 AZ는 하나 이상의 데이터 센터로 구성
• AZ끼리는 수 킬로미터 이상 물리적으로 떨어져 있음 (화재, 홍수 등 동시 피해 방지)
• AZ 간 연결은 전용 저지연 광케이블 사용 (인터넷 아님)

서울 리전 (ap-northeast-2)
  ├── AZ-a  (데이터센터 A, B)
  ├── AZ-b  (데이터센터 C)
  ├── AZ-c  (데이터센터 D, E)
  └── AZ-d  (데이터센터 F)

왜 AZ가 중요한가?

SAP에서 "고가용성(High Availability)"을 묻는 문제의 핵심이 여기에 있다.

• 단일 AZ에 서비스를 올리면 → AZ 장애 시 서비스 전체 중단 (Single Point of Failure)
• Multi-AZ 구성 = 최소 2개 AZ에 분산 → AZ 하나가 죽어도 서비스 유지

설계 기준: 장애 허용 시간과 복구 목표가 가용성 구성을 결정한다. Multi-AZ는 한 AZ 장애에 대비하는 대표 선택지이며, 비용 조건이 있으면 대기 자원의 크기와 복구 목표를 함께 비교한다.

2-3. 엣지 로케이션 (Edge Location)

엣지 로케이션은 리전/AZ와 완전히 별개의 개념이다.

• 목적: 사용자와 가장 가까운 위치에서 콘텐츠를 캐싱하여 지연 시간 최소화
• 주요 서비스: CloudFront(CDN), Route 53, AWS Shield, AWS WAF
• 리전과 별도로 여러 지역에 분산되어 사용자 가까이에서 콘텐츠를 전달

사용자 (서울)
   ↓ 가장 가까운 엣지 로케이션에서 응답
엣지 로케이션 (서울 PoP)
   ↓ 캐시 없으면 오리진으로
오리진 서버 (예: us-east-1의 S3)

엣지 관련 추가 개념

3. AWS 글로벌 vs 리전 vs AZ 서비스 구분

SAP에서 자주 헷갈리는 부분이다. 서비스가 어느 범위에 속하는지 알아야 설계가 가능하다.

글로벌 서비스 (리전 선택 없음)

• IAM — 계정 전체에서 공유
• Route 53 — 글로벌 DNS
• CloudFront — 글로벌 CDN
• WAF (CloudFront에 붙을 때)

리전 서비스 (리전 선택 필요)

• S3 (버킷은 리전 단위, 이름은 글로벌 고유)
• DynamoDB
• Lambda
• SQS, SNS

AZ 종속 서비스 (AZ 선택 필요)

• EC2 인스턴스
• EBS 볼륨 (같은 AZ의 EC2에만 붙을 수 있음)
• RDS (단일 AZ 배포 시)
• Subnet

선택 근거: EBS는 AZ 종속이다. EC2를 다른 AZ로 이동하려면 EBS 스냅샷 → 새 AZ에서 볼륨 생성 과정이 필요하다. 시험에 자주 나온다.

4. 공동 책임 모델 (Shared Responsibility Model)

AWS SAP에서 보안 관련 문제에서 반드시 등장하는 개념이다.

┌─────────────────────────────────────────┐
│           고객의 책임                    │
│  데이터, OS 패치, 네트워크 설정, IAM 관리  │
│  애플리케이션 코드, 암호화 설정           │
├─────────────────────────────────────────┤
│           AWS의 책임                     │
│  물리적 데이터센터 보안                   │
│  하이퍼바이저, 네트워크 하드웨어          │
│  관리형 서비스 자체의 보안               │
└─────────────────────────────────────────┘

서비스 유형별 책임 범위

선택 근거: "고객사가 OS 패치를 직접 관리하지 않으려면?" → RDS, Lambda, ECS Fargate 등 관리형 서비스로 전환하는 것이 답이 된다.

5. AWS 클라우드 채택 프레임워크 (CAF)

대규모 기업의 클라우드 전환을 다루는 SAP 시험에서 CAF 개념이 나온다.

CAF는 조직의 클라우드 전환을 6개 관점(Perspective)으로 나눈다.

6. SAP 시험에서 이 내용이 나오는 방식

실제 시험에서는 다음과 같은 형태로 출제된다.

예시 문제 유형 1 — 리전 선택

"글로벌 금융 기업이 한국 고객 데이터를 처리한다. 규제상 데이터가 한국을 벗어나면 안 된다. 동시에 일본, 미국 사용자에게도 빠른 응답이 필요하다. 어떻게 설계하겠는가?"

• 핵심 데이터 처리: ap-northeast-2 (서울) 리전
• 글로벌 빠른 응답: CloudFront 엣지 로케이션으로 정적 콘텐츠 캐싱
• 동적 요청은 서울로 라우팅 (Route 53 지역 기반 라우팅)

예시 문제 유형 2 — 고가용성

"RDS를 운영 중인데 AZ 장애 시 자동으로 복구되어야 한다. 비용은 최소화한다."

• 정답: RDS Multi-AZ 배포 (Primary AZ 장애 시 Standby로 자동 Failover)
• RDS Read Replica는 고가용성이 아닌 읽기 성능 개선이 목적임에 주의

7. 리전과 AZ를 고르는 설계 체크리스트

리전 선택은 “가까운 곳” 하나로 끝나지 않는다. 아래 순서로 제약 조건을 먼저 걸러내면 시험 문제와 실제 설계를 같은 방식으로 풀 수 있다.

예시: 개인 서비스의 현실적인 판단

트래픽이 작고 국내 사용자가 대부분인 개인 서비스라면 처음부터 멀티 리전을 구성하는 것이 항상 정답은 아니다. 먼저 한 리전의 다중 AZ와 백업으로 목표 가용성을 맞추고, 해외 사용자가 늘거나 장애 허용 시간이 짧아질 때 CloudFront·멀티 리전으로 확장하는 식이 운영 복잡도와 비용을 함께 관리하기 쉽다.

핵심은 “AWS 서비스를 많이 쓰는가”가 아니라 장애 범위와 데이터 경계를 요구사항에 맞게 선택했는가다.

8. 공식 문서로 다시 확인하기

• AWS Regions — 리전 선택과 서비스 가용성
• AWS Availability Zones — AZ의 물리적 분리와 계정별 AZ 매핑
• AWS Fault Isolation Boundaries — 장애 격리 경계와 복원력 설계

이 시리즈에서 이어 읽기

• 02. IAM과 권한 경계 — 계정과 리전 경계를 만든 뒤 접근 권한 설계
• 03. VPC와 네트워크 경계 — AZ를 실제 서브넷과 라우팅으로 연결

정리