🌐 AWS 전체 인프라 현황
- AWS는 현재 38개 지리적 리전(Geographic Regions) 을 운영 중입니다.
- Amazon Web Services, Inc.
- +1
- 각 리전은 여러 개의 가용 영역(Availability Zones, AZ)을 포함하며, 글로벌 수준의 120개 AZ 가
운영되고 있습니다.
- Amazon Web Services, Inc.
- +2
- Amazon Web Services, Inc.
- +2
- 또한, 전 세계적으로 700개 이상의 엣지 위치(Edge Locations) 및 여러 로컬존(Local Zones),
Wavelength Zones 등을 통해 저지연(低-latency) 서비스 제공 인프라를 갖추고 있습니다.
⚠️ 리전에 따라 “기본 활성화(enabled by default)” 리전과 “옵트인(opt-in)” 리전이 나뉘므로, 계정 설정 시 리전 활성화 여부를 확인해야 합니다.
📅 최근 — 2025년 추가된 주요 리전들
최근 AWS는 다음 리전들을 새로 추가 또는 발표했습니다:
| 리전 코드 / 이름 | 지역 / 특징 |
| ap-southeast-7 (Asia Pacific — Thailand) | 태국 리전, 2025년 1월 시작 AWS 문서+1 |
| mx-central-1 (Mexico Central) | 멕시코 중부 리전, 2025년 1월 시작 AWS 문서 |
| ap-east-2 (Asia Pacific — Taipei) | 대만 타이베이 리전, 2025년 6월 시작 AWS 문서 |
| ap-southeast-6 (Asia Pacific — New Zealand) | 뉴질랜드 리전, 2025년 9월 시작 AWS 문서+1 |
이 추가로 인해 AWS 글로벌 인프라는 더욱 확대되었고, 특히 아시아 태평양 지역의 커버리지가 강화되었습니다.
🇰🇷 한국 사용자를 위한 참고: 아시아 태평양 리전
한국(서울, 경기 등) 사용자에게 의미 있는 아시아 태평양(APAC) 리전들 예시:
- ap-northeast-2 — Asia Pacific (Seoul) 리전. AZ 다수, 한국 내 서비스 지연(latency) 우수
- AWS 문서
- +1
- 기타 근접 APAC 리전으로는 일본, 도쿄/오사카; 싱가포르; 홍콩; 대만(‘ap-east-2’); 말레이시아; 태국 등이 있으며, 최근 대만·태국 리전 추가로 APAC 커버 확대 중.
- AWS 문서
- +2
- thedeveloperspace.com
- +2
한국에서 AWS 쓰는 경우, 서울 리전을 기본으로 두되, 요구하는 가용성/복원력/글로벌 사용자 분산 등을 위해 근접 APAC 리전을 활용하는 전략이 일반적입니다.
✅ 리전 & AZ 선택 시 고려 사항
- 각 리전은 서로 물리적으로 격리돼 있어, 단일 리전 장애 시 다른 리전으로 복구 전략 설계가 가능.
- AWS 문서
- +1
- 충분한 AZ 수를 가진 리전을 선택하는 것이 고가용성 설계의 기본. 대부분 리전은 최소 3개 이상의 AZ를 제공.
- AWS 문서
- +1
- 사용하려는 서비스가 해당 리전에 지원되는지, 계정에서 활성화(opt-in) 해야 하는지 여부 확인 필요.
- AWS 문서
- +1
필요하시다면 2025년 12월 시점의 “전 세계 AWS 리전 전체 리스트 (리전 코드 + AZ 수 + 출시일 포함)” 표를 드릴 수 있어요 — 한국, 아시아, 북미, 유럽 등 포함. 그렇게 할까요?
나의 말:
전체리스트를 표로 정리해 줘
ChatGPT의 말:
좋습니다 — 2025년 시점에서 공개된 정보를 바탕으로, Amazon Web Services (AWS)의 주요 리전 전체 리스트를 리전 코드, 이름, AZ(가용 영역) 수, 개시(출시) 연도 위주로 정리해 봤습니다. (단, 일부 리전은 “최초 공개 연도”가 공식 문서에만 있고, 매번 갱신되므로 참고용으로 보세요.)
아래 표는 AWS 공식 문서 + 공신력 있는 정리 자료들을 기반으로 구성했습니다.
🌍 AWS 리전 전체 리스트 (리전 코드, 이름, AZ 수, 개시 연도)
| 리전 코드 | 리전 이름 (Region Name) | AZ 수 | 개시 / 시작 연도* |
| us-east-1 | US East (N. Virginia) | 6 | 2006 Amazon Web Services, Inc.+1 |
| us-east-2 | US East (Ohio) | 3 | 2016 AWS 문서+1 |
| us-west-1 | US West (N. California) | 3† | 2009 Amazon Web Services, Inc.+1 |
| us-west-2 | US West (Oregon) | 4 | 2011 Amazon Web Services, Inc.+1 |
| ca-central-1 | Canada (Central) | 3 | 2016 Amazon Web Services, Inc.+1 |
| ca-west-1 | Canada West (Calgary) | 3 | 2023 Amazon Web Services, Inc.+1 |
| mx-central-1 | Mexico (Central) | 3 | 2025 AWS 문서+1 |
| govcloud (US-East / US-West)* | AWS GovCloud (미국 전용) | 3 | US-West: 2011, US-East: 2018 Amazon Web Services, Inc.+1 |
| af-south-1 | Africa (Cape Town) | 3 | 2020 Amazon Web Services, Inc.+1 |
| sa-east-1 | South America (São Paulo) | 3 | 2011 Amazon Web Services, Inc.+1 |
| eu-west-1 | Europe (Ireland) | 3 | 2007 Amazon Web Services, Inc.+1 |
| eu-central-1 | Europe (Frankfurt) | 3 | 2014 Amazon Web Services, Inc.+1 |
| eu-west-2 | Europe (London) | 3 | 2016 Amazon Web Services, Inc.+1 |
| eu-west-3 | Europe (Paris) | 3 | 2017 Amazon Web Services, Inc.+1 |
| eu-north-1 | Europe (Stockholm) | 3 | 2018 Amazon Web Services, Inc.+1 |
| eu-south-1 | Europe (Milan) | 3 | 2020 Amazon Web Services, Inc.+1 |
| eu-central-2 | Europe (Zurich) | 3 | 2022 Amazon Web Services, Inc.+1 |
| eu-south-2 | Europe (Spain) | 3 | 2022 Amazon Web Services, Inc.+1 |
| il-central-1 | Israel (Tel Aviv) | 3 | 2023 Amazon Web Services, Inc.+1 |
| me-south-1 | Middle East (Bahrain) | 3 | 2019 Amazon Web Services, Inc.+1 |
| me-central-1 | Middle East (UAE) | 3 | 2022 Amazon Web Services, Inc.+1 |
| ap-northeast-1 | Asia Pacific (Tokyo) | 4 | 2011 Amazon Web Services, Inc.+1 |
| ap-northeast-2 | Asia Pacific (Seoul) | 4 | 2016 Amazon Web Services, Inc.+1 |
| ap-northeast-3 | Asia Pacific (Osaka) | 3 | 2021 Amazon Web Services, Inc.+1 |
| ap-south-1 | Asia Pacific (Mumbai) | 3 | 2016 Amazon Web Services, Inc.+1 |
| ap-south-2 | Asia Pacific (Hyderabad) | 3 | 2022 Amazon Web Services, Inc.+1 |
| ap-southeast-1 | Asia Pacific (Singapore) | 3 | 2010 Amazon Web Services, Inc.+1 |
| ap-southeast-2 | Asia Pacific (Sydney) | 3 | 2012 Amazon Web Services, Inc.+1 |
| ap-southeast-3 | Asia Pacific (Jakarta) | 3 | 2021 Amazon Web Services, Inc.+1 |
| ap-southeast-4 | Asia Pacific (Melbourne) | 3 | 2023 Amazon Web Services, Inc.+1 |
| ap-southeast-5 | Asia Pacific (Malaysia) | 3 | 2024 Amazon Web Services, Inc.+1 |
| ap-southeast-6 | Asia Pacific (New Zealand) | 3 | 2025 (신규, 9월 기준) AWS 문서+1 |
| ap-east-1 | Asia Pacific (Hong Kong) | 3 | 2019 Amazon Web Services, Inc.+1 |
| ap-east-2 | Asia Pacific (Taipei, Taiwan) | 3 | 2025 (6월 기준) AWS 문서+1 |
* “개시 연도”는 AWS 공식 글로벌 인프라 문서가 제공하는 리전 시작 연도를 기반으로 정리됨. 일부 오래된 리전은 최초 서비스 제공 연도로 기록되어 있음.
† 일부 계정에서는 us-west-1 리전에서 AZ가 2개만 제공될 수 있다는 안내가 있음.
ℹ️ 참고: 전체 규모 & 동작 현황
- AWS는 전 세계에 38개 지리적 리전 (Geographic Regions) 을 보유하며, 총 120개 AZ (Availability Zones) 운영 중입니다.
- Amazon Web Services, Inc.
- +1
- 리전은 물리적으로 서로 분리된 독립 단위이며, AZ는 리전 내에서 서로 격리된 데이터센터 집합체입니다. 이 구조 덕분에, 리전 또는 AZ 단위의 장애가 전체 인프라에 영향을 주지 않도록 설계돼 있습니다.
- AWS 문서
- +1
📥 AWS 리전 전체 리스트 (aws_regions.xlsx)
👉 다운로드
필요하시면 같은 데이터를 CSV, Google Sheets, PDF, 혹은 다른 구조로도 만들어 드릴 수 있어요.
나의 말:
리전을 구분하는 기준은?
ChatGPT의 말:
AWS에서 리전을 구분하는 기준은 단순히 “지역별로 나눈 데이터센터”가 아니라, 보안·지연시간·법규·인프라 독립성을 모두 고려한 구조적 단위입니다. 핵심 기준을 정리하면 다음과 같습니다.
✅ AWS 리전을 구분하는 기준 (핵심 5가지)
1) 지리적 위치 (Geographic Location)
- 물리적으로 완전히 다른 지역에 존재하는 데이터센터 집합.
- 국가 또는 대도시 단위로 구분.
- 대규모 재난·전력 문제·통신 장애가 발생해도 서로 영향을 받지 않도록 수백 km 이상 떨어져 있음.
➡️ 예: 서울(ap-northeast-2) vs 도쿄(ap-northeast-1)
2) 규제·데이터 주권 (Compliance & Data Sovereignty)
나라별로 요구하는 데이터 보관 규정이 다르기 때문에,
AWS는 법률적 요구를 충족할 수 있는 단위를 리전으로 설정합니다.
예시:
- 🇰🇷 한국: 개인정보보호법(PIPA), 금융보안원(FSI) 규정
- 🇪🇺 EU: GDPR
- 🇦🇺 호주: 정부 데이터는 국내 보관 원칙
➡️ 이런 규정을 충족하기 위해 “그 나라” 또는 “그 지역”에 리전이 필요함.
3) 인프라 독립성 (Fault Isolation & Resilience)
각 리전은 독립된 네트워크, 전력, 냉각, 보안 인프라를 갖춘 완전한 단위.
- 한 리전이 장애 나도 다른 리전은 영향 없음
- 각 리전은 여러 AZ(가용 영역) 으로 구성되어 내부에서도 장애 격리 기능 제공
- 리전 간 데이터 replication 기반으로 DR(재해 복구) 설계 가능
4) 지연 시간(Latency) 최적화
AWS는 사용자와 가장 가까운 리전을 선택하도록 설계합니다.
기준:
- 실제 거리(물리적 거리)
- 인터넷 백본 품질
- 지역 ISP 연동 구조
➡️ 한국 사용자는 대부분 서울 리전이 최저 지연
(국내–도쿄 간 지연 약 25~30ms, 국내–싱가포르 약 65~80ms)
5) 시장 규모 및 수요 (Business Demand)
AWS는 클라우드 수요가 높거나 성장 가능성이 높은 지역에 리전을 구축합니다.
요소:
- 기업/정부의 AWS 도입 규모
- 데이터 주권 요구
- 인터넷/전력 인프라 수준
- 경제 규모
➡️ 예: 최근 추가된 태국·대만·뉴질랜드 리전은 지역 수요 증가 때문.
🔍 정리하면…
AWS 리전은 다음 기준을 충족하는 물리·논리적으로 완전히 독립된 클라우드 구역입니다:
지리적 분리 + 규제 준수 + 장애 격리 + 낮은 지연 시간 + 지역 수요
즉, 단순한 “데이터센터 위치”가 아니라
재해 복구, 법적 규정, 성능, 고객 수요를 모두 만족시키기 위한 글로벌 인프라 배치 전략입니다.