글로벌 인프라와 서울 리전 (리전, AZ, 공동 책임 모델)
리전, 가용 영역(AZ), Local Zones, 엣지 로케이션이 어떻게 나뉘는지, 서울 리전(ap-northeast-2)을 고를 때 볼 것, AZ 이름과 AZ ID 의 차이, 그리고 AWS 와 고객이 보안을 나눠 맡는 공동 책임 모델을 정리합니다.
글로벌 인프라의 층
AWS 인프라는 크게 네 층으로 나뉩니다. 설계 문서에서 "멀티 AZ", "멀티 리전" 이라고 말할 때 어느 층을 말하는지 먼저 맞춰야 합니다.
| 층 | 무엇인가 | 설계에서 쓰는 곳 |
|---|---|---|
| 리전 (Region) | 지리적으로 떨어진 독립 구역. 서비스 엔드포인트와 데이터가 리전 단위로 나뉨 | 데이터 주권, 지연 시간, 재해 복구(DR) |
| 가용 영역 (AZ) | 리전 안의 하나 이상의 데이터센터 묶음. 전원, 냉방, 네트워크가 따로이고 서로 수 km 이상 떨어짐 | 고가용성. 서브넷, EBS, 대부분의 인스턴스가 AZ 에 묶임 |
| Local Zones, Wavelength, Outposts | 리전을 사용자 가까이로 늘린 확장 구역 | 한 자릿수 ms 지연, 데이터 현지 보관 |
| 엣지 로케이션 | CloudFront, Route 53, Global Accelerator 가 쓰는 접점 | 콘텐츠 전송, DNS, 전역 진입점 |
AWS 공식 인프라 페이지 기준(2026-10)으로 39 개 리전, 124 개 AZ 가 운영 중이고, 사우디아라비아와 칠레 리전이 발표되어 있습니다. 숫자는 계속 바뀌니 제안서에 쓸 때는 그날의 글로벌 인프라 페이지를 다시 확인합니다.
서울 리전 (ap-northeast-2)
서울 리전의 코드는 ap-northeast-2 이고, 2016 년에 열렸습니다. 2020 년 7 월에 네 번째 AZ 가 추가되어 지금은 AZ 가 4 개입니다. 2019 년 3 월 이전에 연 리전이라 계정에서 따로 켜지 않아도(opt-in 없이) 바로 쓸 수 있습니다. 가까운 리전으로는 도쿄(ap-northeast-1)와 오사카(ap-northeast-3)가 있어서 국내 서비스의 DR 리전으로 자주 쓰입니다.
리전을 고를 때 보는 순서
- 규제와 데이터 위치: 개인정보, 금융, 공공 규정이 국내 보관을 요구하면 서울이 먼저입니다.
- 서비스 지원 여부: 새 서비스와 새 인스턴스 유형은 보통 미국 동부(버지니아), 오레곤부터 열립니다. 예를 들어 Graviton5 기반 M9g 는 2026-06 GA 때 미국과 프랑크푸르트 리전에서만 시작했습니다. 서울에 있는지 서비스 엔드포인트 문서와 콘솔의 리전별 기능 목록에서 확인합니다.
- 지연 시간: 국내 사용자가 대상이면 서울이 가장 가깝습니다.
- 가격: 같은 인스턴스도 리전마다 단가가 다릅니다. 서울의 m8g.large Linux 온디맨드는 2026-10 기준 시간당 0.11034 USD 입니다. 비교는 AWS Pricing Calculator로 합니다.
AZ 이름과 AZ ID
ap-northeast-2a 같은 AZ 이름은 계정마다 실제 위치와 짝지어지는 방식이 다를 수 있습니다. 한 계정의 2a 가 다른 계정의 2c 일 수 있다는 뜻입니다. 계정 사이에서 같은 물리 AZ 를 맞춰야 할 때(공유 VPC, PrivateLink 엔드포인트 배치, 지연 시간 테스트)는 apne2-az1 같은 AZ ID 를 기준으로 맞춥니다.
aws ec2 describe-availability-zones --region ap-northeast-2 \
--query "AvailabilityZones[].{Name:ZoneName,Id:ZoneId,State:State}" --output table팁 인스턴스 유형마다 쓸 수 있는 AZ 가 다를 수 있습니다. 특정 유형으로 Auto Scaling 그룹을 만들기 전에
aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=instance-type,Values=m8g.large로 AZ 별 제공 여부를 먼저 봅니다.
멀티 AZ 와 멀티 리전
대부분의 운영 시스템은 멀티 AZ 로 충분합니다. ELB, Auto Scaling, RDS Multi-AZ, Aurora, S3, DynamoDB 가 AZ 장애를 견디도록 만들어져 있기 때문입니다. 멀티 리전은 비용과 복잡도가 크게 늘어서, 리전 전체 장애에도 버텨야 하는 서비스나 해외 사용자 지연을 줄여야 하는 서비스에서만 고릅니다.
| 목표 | 흔한 구성 | 주의 |
|---|---|---|
| AZ 하나가 죽어도 서비스 유지 | ALB + 두 개 이상 AZ 의 Auto Scaling, RDS Multi-AZ | NAT Gateway, 인터페이스 엔드포인트도 AZ 마다 두어야 진짜 멀티 AZ |
| 리전 장애 대비 (RPO 분 단위) | Aurora Global Database, S3 교차 리전 복제, DynamoDB 글로벌 테이블 | 쓰기 리전 전환 절차와 DNS 전환을 미리 연습 |
| 리전 장애에도 쓰기 지속 | DynamoDB 글로벌 테이블(다중 리전 강한 일관성), Aurora DSQL 다중 리전 클러스터 | 지연 시간과 비용, 지원 리전 조합 확인 |
리전 사이 데이터 전송은 유료입니다. 서울에서 다른 AWS 리전으로 보내는 전송은 2026-10 기준 GB 당 0.08 USD 이고, 같은 리전 안에서 AZ 를 넘는 전송도 방향마다 GB 당 0.01 USD 가 붙습니다. 멀티 AZ 로 잘 나눠도 AZ 를 오가는 수다스러운 트래픽이 많으면 청구서에 바로 보입니다.
전역 서비스와 리전 서비스
IAM, Organizations, Route 53, CloudFront 는 전역 서비스처럼 동작하고, 콘솔에서 리전을 골라도 같은 내용을 보여 줍니다. 다만 CloudFront 에 붙이는 ACM 인증서는 us-east-1 에서 발급해야 하고, 전역 서비스의 CloudTrail 이벤트도 대부분 us-east-1 로 기록됩니다. "서울만 쓰는데 왜 버지니아에 리소스가 있지?" 하는 질문의 답이 대개 이것입니다.
공동 책임 모델
보안은 AWS 와 고객이 나눠 맡습니다. AWS 는 클라우드 자체의 보안(데이터센터, 하드웨어, 하이퍼바이저, 관리형 서비스의 기반 소프트웨어)을, 고객은 클라우드 안의 보안(데이터, IAM, 네트워크 설정, OS 패치, 암호화 선택)을 맡습니다. 경계선은 서비스 유형에 따라 움직입니다.
| 서비스 유형 | 예 | 고객이 맡는 것 |
|---|---|---|
| 인프라형 | EC2, EBS, VPC | 게스트 OS 패치, 방화벽(보안 그룹), 애플리케이션, 데이터 암호화 |
| 컨테이너, 관리형 | RDS, ECS on Fargate, EKS | DB 사용자와 파라미터, 태스크 권한, 네트워크 노출, 백업 보존 |
| 추상화형 | S3, DynamoDB, Lambda, Bedrock | 접근 정책, 암호화 키 선택, 데이터 분류, 함수 코드와 의존성 |
주의 공개된 S3 버킷, 0.0.0.0/0 으로 열린 22 번 포트, 액세스 키가 박힌 코드는 모두 고객 쪽 책임입니다. 사고의 대부분이 여기서 납니다. 계정을 만들자마자 S3 퍼블릭 액세스 차단, 루트 MFA, CloudTrail, GuardDuty 를 켭니다.
처음 계정을 열면 하는 일
- 루트 사용자에 MFA 를 걸고, 루트 액세스 키는 만들지 않습니다.
- Organizations 와 IAM Identity Center로 사람의 로그인을 옮깁니다.
- 모든 리전에 CloudTrail 조직 트레일을 켜고 로그 전용 계정으로 보냅니다.
- 쓰지 않는 리전은 SCP 로 막습니다. 예시는 Organizations 와 Control Tower 문서에 있습니다.
- Budgets 로 월 예산 경보를 겁니다. 2025-07-15 이후 새 계정은 최대 200 USD 크레딧과 6 개월짜리 무료 플랜으로 시작할 수 있으니, 무료 플랜이 끝나기 전에 유료 플랜 전환 여부를 정합니다.