신입 시절 첫 배포. 동료가 "리전은 서울로 했지?"라고 묻습니다. 알고 보니 기본값인 미국 버지니아(us-east-1)에 서버를 띄워, 한국 사용자의 응답이 200ms씩 느렸습니다. 며칠 뒤엔 "AZ 하나에 다 몰아넣었네?"라는 지적. 데이터센터 한 곳 점검에 서비스 전체가 흔들릴 구조였습니다. 클라우드는 '어디에, 어떤 층위로' 올리느냐가 곧 성능·가용성·비용입니다.
- 1IaaS·PaaS·SaaS를 '관리 책임의 경계'로 구분할 수 있다
- 2각 모델이 어떤 상황에 적합한지 예로 들 수 있다
- 3리전과 가용영역(AZ)의 관계와 차이를 설명할 수 있다
- 4Multi-AZ 배포가 왜 고가용성의 기본인지 안다
- 5엣지/CDN이 리전과 어떻게 역할을 나누는지 안다
어디까지 남에게 맡길 것인가 — IaaS / PaaS / SaaS
클라우드는 "전부 아니면 전무"가 아닙니다. 내가 관리할 층위를 고르는 문제입니다.
피자에 비유하는 세 층위
직접 다 만들면 온프레, 재료만 사서 집에서 굽는 게 IaaS, 배달 피자가 PaaS, 식당에서 먹는 게 SaaS라는 유명한 비유가 있습니다. 핵심은 위로 갈수록 내가 신경 쓸 게 줄지만, 내 마음대로 바꿀 수 있는 폭도 줄어든다는 트레이드오프입니다.
- IaaS(Infrastructure as a Service): 가상 서버·스토리지·네트워크를 빌림. OS부터 위는 전부 내 책임. (예: EC2)
- PaaS(Platform as a Service): OS·런타임·스케일링을 제공자가 관리. 나는 코드만 올림. (예: Elastic Beanstalk, App Engine)
- SaaS(Software as a Service): 완성된 소프트웨어를 그냥 사용. (예: Gmail, Notion, Slack)
위 그림에서 색칠된 영역이 '제공자가 관리', 빈 영역이 '내가 관리' 입니다. 오른쪽으로 갈수록 내 책임이 줄어드는 게 한눈에 보입니다.
어디에 둘 것인가 — 리전과 가용영역
클라우드 데이터센터는 전 세계에 흩어져 있습니다. 이 지리 구조를 모르면 느리거나, 한 번에 다 죽습니다.
리전(Region) ⊃ 가용영역(AZ) ⊃ 데이터센터
리전은 '서울', '도쿄', '버지니아'처럼 지리적으로 멀리 떨어진 단위입니다. 사용자와 가까운 리전을 고르면 지연이 줄고, 데이터 주권(특정 국가에 데이터를 둬야 하는 규제)도 리전으로 통제합니다.
각 리전 안에는 가용영역(AZ) 이 보통 2~3개 이상 있습니다. AZ는 전력·냉각·네트워크가 물리적으로 분리된 데이터센터 묶음입니다. 한 AZ에 정전이 나도 다른 AZ는 멀쩡하도록 떨어뜨려 지어져 있습니다.
Multi-AZ — 단일 데이터센터 장애를 견디는 기본기
인스턴스를 한 AZ에만 두면 그 데이터센터 한 곳의 장애로 서비스 전체가 멈춥니다. 둘 이상의 AZ에 분산하고 앞에 로드밸런서를 두면, 한 AZ가 죽어도 나머지가 트래픽을 받아냅니다. 이것이 클라우드 고가용성의 가장 기본 패턴이고, 관리형 DB의 'Multi-AZ' 옵션도 같은 원리입니다([[managed-database]]).
반면 엣지 로케이션은 리전과 별개로 전 세계에 훨씬 촘촘히 깔린 캐시 거점입니다. 정적 콘텐츠를 사용자 근처에서 응답해 지연을 줄입니다(CDN, [[cloud-dns-cdn]]).
엉뚱한 리전에 자원을 만드는 건 초보의 단골 실수입니다. 현재 CLI 기본 리전을 확인합니다.
aws configure get region
aws ec2 describe-availability-zones --query "AvailabilityZones[].ZoneName" --output text
ap-northeast-2
ap-northeast-2a ap-northeast-2b ap-northeast-2c ap-northeast-2d
aws configure get region서비스 대상 사용자가 가까운 리전을 고를 수 있도록 전체 리전을 확인합니다.
aws ec2 describe-regions \
--query "Regions[].RegionName" --output table
----------------------
| DescribeRegions |
+--------------------+
| ap-northeast-2 | ← 서울
| ap-northeast-1 | ← 도쿄
| us-east-1 | ← 버지니아(기본값, 주의)
| eu-west-1 | ← 아일랜드
+--------------------+
aws ec2 describe-regions- configure get region이 비어 있거나 us-east-1 — 기본값일 가능성. 한국 서비스인데 미국 리전이면 사용자 지연 +100~200ms. 의도한 리전인지 확인
- describe-availability-zones의 ZoneName 개수 — 보통 3개 이상. 이 중 최소 2개에 분산 배치해야 Multi-AZ 고가용성
- 여러 리전에 자원이 흩어져 있는지 — 의도치 않게 여러 리전에 떠 있으면 비용·관리가 분산되고 일부는 잊혀져 과금됨
- 데이터 주권 규제 대상 서비스라면, 데이터가 허용된 리전에만 저장되는지(백업·로그 포함)
상황: 분명히 자원을 생성했는데 콘솔 목록에 없음.
원인: 콘솔/CLI가 다른 리전을 보고 있음. 대부분의 자원은 리전에 묶여 있어, 만든 리전이 아닌 곳에서는 보이지 않습니다. CLI는 us-east-1(기본), 콘솔은 서울을 보고 있으면 서로 다른 세계를 보는 셈.
진단: aws configure get region으로 CLI 리전 확인, 콘솔 우측 상단 리전 선택기 확인.
해결: 리전을 명시(--region ap-northeast-2)하거나 aws configure로 기본 리전을 통일. IAM·Route 53 같은 일부 글로벌 서비스는 리전에 안 묶이는 예외임을 기억.
실무에서 "왜 응답이 느려요?"의 의외로 흔한 원인이 리전 선택 실수입니다. 글로벌 서비스라면 사용자별로 가까운 리전·엣지로 보내는 전략(지연 기반 라우팅)을 [[cloud-dns-cdn]]에서 설계합니다.
또한 SRE 면접에서 "고가용성을 어떻게 확보하나요?"의 1차 답은 거의 항상 "Multi-AZ로 분산하고 앞에 로드밸런서를 둔다" 입니다. 한 단계 더 들어가면 리전 전체 장애에 대비한 Multi-Region 전략(DR)인데, 비용·복잡도가 급증하므로 RTO/RPO 요구에 따라 결정합니다.
다음 모듈에서는 클라우드 작업의 출입문이자 가장 사고가 잦은 영역 — 계정과 IAM(권한 관리), 그리고 '최소 권한 원칙'을 다룹니다.