신입 시절 첫 배포. 동료가 "리전은 서울로 했지?"라고 묻습니다. 알고 보니 기본값인 미국 버지니아(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)
확대
위 그림에서 색칠된 영역이 '제공자가 관리', 빈 영역이 '내가 관리' 입니다. 오른쪽으로 갈수록 내 책임이 줄어드는 게 한눈에 보입니다.
패치·설정 책임이 어디서 갈리나 — 스택을 아래에서 위로 짚기
"SaaS니까 보안은 벤더가 알아서 하겠지"라고 믿었다가 공유 설정 하나로 데이터가 통째로 새는 사고가 클라우드 유출의 큰 몫입니다. IaaS·PaaS·SaaS의 차이는 결국 스택의 어느 높이에서 '제공자 책임'과 '내 책임'의 경계선이 그어지느냐입니다. 하드웨어부터 데이터까지 계층을 아래에서 위로 짚어 올라가며 모델마다 그 경계가 어디에 오는지를 보면, '무엇이 내 몫인지'가 분명해집니다.
[스택 아래] 물리 하드웨어·시설 ← 세 모델 모두 제공자 책임
▲
│ 가상화·호스트(하이퍼바이저) ← 제공자
│
│ 게스트 OS·커널 패치 ── IaaS 경계: 여기부터 위는 내 책임
│
│ 런타임·미들웨어·라이브러리 ── PaaS 경계: 여기부터 위는 내 책임
│
│ 애플리케이션 코드·설정 ── SaaS 경계: 여기부터 위는 제공자 책임(사용자 설정은 별도 확인)
│
[스택 위] 데이터·접근제어(IAM)·키 ← 사용자와 제공자의 책임을 서비스별로 확인
계층별로 누가 책임지고, 경계를 오해하면 무슨 사고가 나나:
| 스택 계층 | 모델별 관리 주체 | 이 경계를 오해하면 |
|---|---|---|
| 물리·가상화·호스트 | 세 모델 모두 제공자 | (공유 책임 밖 — 내가 신경 쓸 일 없음) |
| 게스트 OS·커널 패치 | IaaS=사용자 / PaaS·SaaS=제공자 | IaaS인데 OS 패치를 제공자가 할 거라 오해 → 취약 커널 방치, 원격 익스플로잇 |
| 런타임·미들웨어·라이브러리 | IaaS=사용자 / PaaS·SaaS=제공자 | 런타임 CVE 패치 주체 혼동 → 취약 라이브러리 방치 |
| 앱 코드·설정 | IaaS·PaaS=사용자 / SaaS=제공자 | 인증·권한 설정 오류를 '기본값이 안전하겠지'로 방치 |
| 데이터·접근제어·키 | 사용자 중심이지만 서비스 기능·암호화·가용성은 제공자와 공동 확인 | 'SaaS면 벤더 몫' 또는 '전부 내 몫'으로 단정 → 공유 설정·키 관리 책임을 놓침 |
핵심은 위로 올라갈수록 내 관리 범위가 줄고, 경계선의 높이만 모델이 정한다는 것입니다. 데이터 분류·접근 권한·키 관리처럼 고객이 직접 설정하는 항목이 많지만, 암호화·보존·가용성 기능과 기본 설정은 서비스별로 제공자와 책임을 나눕니다. 대부분의 클라우드 유출은 이 경계를 오해해 SaaS의 공유 설정을 방치하거나, IaaS 서버의 OS·미들웨어 패치를 제공자가 할 거라 믿는 데서 나옵니다. 새 서비스를 도입할 때는 이 모델에서 경계선이 어디에 그어지고, 내가 확인할 항목이 무엇인가를 제공자의 책임 모델과 함께 먼저 그려야 합니다.
어디에 둘 것인가 — 리전과 가용영역
클라우드 데이터센터는 전 세계에 흩어져 있습니다. 이 지리 구조를 모르면 느리거나, 한 번에 다 죽습니다.
리전(Region) ⊃ 가용영역(AZ) ⊃ 데이터센터
리전은 '서울', '도쿄', '버지니아'처럼 지리적으로 멀리 떨어진 단위입니다. 사용자와 가까운 리전을 고르면 지연이 줄고, 데이터 주권(특정 국가에 데이터를 둬야 하는 규제)도 리전으로 통제합니다.
각 리전 안에는 가용영역(AZ) 이 보통 2~3개 이상 있습니다. AZ는 전력·냉각·네트워크가 물리적으로 분리된 데이터센터 묶음입니다. 한 AZ에 정전이 나도 다른 AZ는 멀쩡하도록 떨어뜨려 지어져 있습니다.
확대
확대
위 그림처럼 PaaS는 앱 전체를 항상 켜두는 방식이고, FaaS는 이벤트가 올 때만 함수 단위로 실행합니다. 상시 응답이 필요하면 PaaS, 간헐적 이벤트라면 FaaS가 적합합니다.
Multi-AZ — 단일 데이터센터 장애를 견디는 기본기
인스턴스를 한 AZ에만 두면 그 데이터센터 한 곳의 장애로 서비스 전체가 멈춥니다. 둘 이상의 AZ에 분산하고 앞에 로드밸런서를 두면, 한 AZ가 죽어도 나머지가 트래픽을 받아냅니다. 이것이 클라우드 고가용성의 가장 기본 패턴이고, 관리형 DB의 'Multi-AZ' 옵션도 같은 원리입니다(관리형 데이터베이스(RDS)).
반면 엣지 로케이션은 리전과 별개로 전 세계에 훨씬 촘촘히 깔린 캐시 거점입니다. 정적 콘텐츠를 사용자 근처에서 응답해 지연을 줄입니다(CDN, 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 같은 일부 글로벌 서비스는 리전에 안 묶이는 예외임을 기억.
심화 — 리전은 지연만이 아니라 장애·비용의 단위다
심화: 컨트롤 플레인 vs 데이터 플레인 — 리전 장애 때 무엇이 살아남는가
Multi-AZ는 데이터센터 한 곳의 장애를 견딥니다. 다음 질문은 "리전 전체가 흔들리면?"입니다. 대형 리전 장애는 실제로 몇 년에 한 번씩 일어나며, 그때 무엇이 되고 안 되는지는 컨트롤 플레인과 데이터 플레인의 구분이 가릅니다.
- 데이터 플레인 — 이미 떠 있는 자원이 일하는 경로입니다. 실행 중인 인스턴스가 요청을 처리하고 LB가 트래픽을 나누는 것. 구조가 단순하고 분산돼 있어 장애에 상대적으로 강합니다.
- 컨트롤 플레인 — 자원을 만들고 바꾸는 경로입니다. 인스턴스 생성, 설정 변경, 오토스케일링의 신규 기동. 리전 장애 때 먼저 무너지는 쪽이 보통 여기입니다.
- 그래서 대형 장애의 흔한 풍경은 "떠 있는 것은 도는데 새로 못 띄우는" 상태입니다. "장애 나면 스케일아웃·재배포로 대응하지"라는 계획은 컨트롤 플레인과 함께 멈춥니다. 이를 견디는 원칙이 정적 안정성(static stability) — 장애 순간의 자원 생성·설정 변경에 의존하지 않도록, 평시에 여유 용량을 확보하고 페일오버 경로를 미리 만들어 두는 설계입니다.
- 함정 하나 더: IAM 같은 글로벌 서비스도 변경(쓰기) 작업의 컨트롤 플레인은 특정 리전(us-east-1)에 있습니다. 서울에서만 서비스해도 그 리전의 장애 때 권한 변경 같은 작업이 안 될 수 있습니다. 조회·검증(데이터 플레인)은 전 리전에 복제돼 계속 동작합니다.
상황: 서울 EC2에서 도는 앱이 S3의 이미지를 읽는데 객체 하나에 200ms씩 걸립니다. 코드도 인스턴스 타입도 문제가 없어 보이는데, 청구서에는 낯선 데이터 전송 항목까지 등장했습니다.
원인: 버킷이 버지니아(us-east-1) 에 있었습니다. 초기 세팅 때 CLI 기본 리전이 버지니아인 상태로 버킷을 만든 것. 앱은 요청마다 태평양을 왕복하고 있었고, 리전을 건너는 트래픽은 지연(+100~200ms)과 리전 간 전송 과금을 동시에 만듭니다. 같은 리전의 EC2↔S3 전송이었다면 무료였을 비용입니다.
진단: aws s3api get-bucket-location --bucket my-bucket으로 버킷의 실제 리전 확인 → 앱 인스턴스의 리전과 대조 → 비용 내역에서 리전 간 전송 항목이 커지기 시작한 시점 확인.
해결: 서울 리전에 버킷을 새로 만들어 데이터를 옮기고, 자원 생성 시 리전을 항상 명시하는 것을 팀 규칙으로 만듭니다. 글로벌 사용자에게 같은 콘텐츠를 빠르게 줘야 한다면 리전마다 복제하는 대신 CDN(DNS와 CDN)을 앞에 세우는 것이 정석입니다.
실무에서 "왜 응답이 느려요?"의 의외로 흔한 원인이 리전 선택 실수입니다. 글로벌 서비스라면 사용자별로 가까운 리전·엣지로 보내는 전략(지연 기반 라우팅)을 DNS와 CDN에서 설계합니다.
또한 SRE 면접에서 "고가용성을 어떻게 확보하나요?"의 1차 답은 거의 항상 "Multi-AZ로 분산하고 앞에 로드밸런서를 둔다" 입니다. 한 단계 더 들어가면 리전 전체 장애에 대비한 Multi-Region 전략(DR)인데, 비용·복잡도가 급증하므로 RTO/RPO 요구에 따라 결정합니다.
관련 모듈로 더 깊이:
- 왜 클라우드인가 — 왜 클라우드로 가는가, 온프레미스와의 근본 차이
- 계정과 IAM — 책임 공유 모델에서 '내 책임'의 출입문인 계정·권한 관리
- 서버리스(Lambda) — 관리 책임을 가장 많이 위임하는 FaaS(서버리스)의 실제
다음 모듈에서는 클라우드 작업의 출입문이자 가장 사고가 잦은 영역 — 계정과 IAM(권한 관리), 그리고 '최소 권한 원칙'을 다룹니다.