AWS 기초 #1 AWS 입문: 계정 / 리전 / AZ

인프라 AWS 클라우드
11 분 소요

리눅스나 도커 같은 인프라 기술을 익혔다면, 이제는 그것들을 어디에서 운영할지 고민해야 합니다. 직접 서버를 구축하고 운영할 수도 있지만, 하드웨어 구매 비용뿐 아니라 네트워크, 전원, 장애 대응, 백업 같은 관리 부담도 함께 따라옵니다. 반면 클라우드는 필요한 만큼만 자원을 사용하고, 인프라 운영의 상당 부분을 서비스 형태로 맡길 수 있어 초기 비용과 운영 부담을 크게 줄일 수 있습니다. 그래서 오늘날 대부분의 서비스는 클라우드를 기본 선택지로 사용합니다. 이 시리즈에서는 클라우드의 표준이라 할 수 있는 AWS를 중심으로, 기본 개념부터 실제 운영 방식까지 차근차근 정리하겠습니다.

총 4개 시리즈, 27편으로 묶었습니다.

  • AWS 기초 7편 ← 지금 시리즈
  • AWS 중급 7편. EC2 / VPC / S3 / RDS / Route 53 / ALB / CloudFront
  • AWS 고급 7편. ECS / ECR / Lambda / API Gateway / EventBridge / Secrets Manager / Step Functions
  • AWS 실전 6편. 진짜 백엔드를 ECS Fargate에 올려 운영

이 글은 시리즈의 출발점입니다. 콘솔에 들어가기 전 머릿속에 있어야 할 그림을 정리하겠습니다. 계정이 무엇이고, 리전과 AZ가 무엇이며, “글로벌 서비스"와 “리전 서비스"의 차이가 어디서 오는지를 짚습니다.

클라우드와 AWS의 등장 #

예전에는 서비스를 운영하려면 회사가 직접 서버를 구매하거나 임대해 데이터센터에 설치해야 했습니다. 그리고 그 위에 운영체제를 구성하고 애플리케이션을 배포하는 방식이 일반적이었습니다. 서버 한 대를 추가하는 일도 간단하지 않았습니다. 견적을 받고, 발주하고, 장비를 배송받은 뒤 설치와 네트워크 구성, 모니터링 설정까지 마쳐야 했기 때문에, 아무리 빨라도 며칠, 보통은 몇 주가 걸리곤 했습니다.

클라우드는 이 과정을 완전히 바꿨습니다. 이제는 필요한 서버와 데이터베이스, 네트워크를 몇 번의 클릭만으로 바로 생성할 수 있습니다. 물리 장비를 직접 관리하지 않아도 되고, 사용한 만큼만 비용을 내면 됩니다. 과거에는 “인프라를 준비하는 일” 자체가 큰 프로젝트였다면, 클라우드 시대에는 필요한 순간에 즉시 인프라를 사용할 수 있게 된 것입니다.

그리고 그 흐름의 중심에 있는 대표적인 플랫폼이 AWS입니다.

항목예전 방식클라우드 방식
서버 한 대 추가견적 → 발주 → 배송 → 설치까지 수 주 소요콘솔이나 API로 수 분 만에 생성
스토리지 1TB 확보디스크 구매, RAID 구성, 백업 설계 필요S3 버킷 생성으로 바로 사용
글로벌 서비스 배포해외 IDC 계약 및 인프라 구축 필요리전 선택만으로 즉시 확장
실패한 실험 정리장비와 구축 비용이 그대로 남음리소스 삭제 후 비용 종료

AWS (Amazon Web Services)는 이 흐름의 첫 주자이자 사실상 표준입니다. 2006년에 S3와 EC2로 시작해 지금은 200가지 넘는 서비스가 한 콘솔 안에 있습니다. Azure (Microsoft) / GCP (Google)도 같은 시장에서 경쟁하지만, 시장 점유율과 자료의 양에서 AWS가 앞섭니다. 한 번 익혀두면 다른 클라우드로 옮겨가기도 쉽습니다.

이 시리즈는 AWS 위에 작은 백엔드를 운영하는 데 필요한 도구상자만 추립니다. AWS의 200개 서비스를 다 다루지는 않습니다. 대신 용도에 맞는 도구를 어떻게 고르는지가 더 중요합니다.

AWS 계정 구조 #

AWS를 시작하려면 AWS 계정 (Account) 하나가 필요합니다. 이메일과 결제 수단 (보통 신용카드), 전화번호로 가입합니다.

루트 사용자 #

가입 직후 받는 계정에는 루트 사용자 (Root User) 한 명이 있습니다. 가입한 이메일이 바로 그 사용자입니다.

루트 사용자는 결제, 계정 종료, 다른 사용자 만들기, 모든 리소스 접근까지 모든 권한을 가집니다. 강력한 만큼 위험합니다. AWS의 첫 번째 권고는 루트 사용자로 일상 작업 하지 마라입니다. 기억하세요:

  • 루트로는 가입 직후의 셋업, 결제 정보 확인, 계정 종료 정도만
  • 실제 작업은 #2 IAM에서 만든 IAM 사용자로
  • 루트에는 반드시 MFA (#6에서 다룸)
  • 액세스 키는 만들지 말고, 이미 있다면 즉시 삭제

계정 ID #

계정마다 12자리 숫자 ID (예: 123456789012)가 붙습니다. 이 ID는 IAM 정책, ARN (리소스 식별자) 같은 역할에서 자주 등장합니다. 콘솔 우측 상단의 사용자 메뉴에서 확인할 수 있습니다.

ARN의 모양 
arn:aws:s3:::my-bucket/path/to/object
arn:aws:iam::123456789012:role/MyRole
arn:aws:lambda:ap-northeast-2:123456789012:function:my-fn

arn:aws:<서비스>:<리전>:<계정ID>:<리소스>의 형태입니다. 글로벌 서비스 (S3, IAM 등)는 리전 칸이 비어 있습니다.

멀티 어카운트와 AWS Organizations #

규모가 조금 커지면 계정을 하나만 쓰지 않습니다. 일반적인 분리:

계정용도
root (관리)청구 통합, Organizations, 보안 감사
prod운영 환경. 가장 보호되는 환경
staging운영 직전 검증
dev개발자용 자유도가 높은 환경
sandbox실험 / 학습. 자동 정리

이 계정들을 묶어 청구를 통합하고 정책을 일괄 적용하는 도구가 AWS Organizations입니다. 처음엔 단일 계정으로 시작해도 충분합니다. Organizations는 두 번째 계정이 필요해질 때 자연스럽게 만나게 됩니다.

참고로 이 시리즈는 단일 계정 가정으로 진행합니다. Organizations는 운영 규모가 커진 뒤의 이야기입니다.

리전 (Region) #

리전은 AWS의 물리적 배치 단위입니다. 전 세계 곳곳에 데이터센터 클러스터가 있고, 각 클러스터가 하나의 리전입니다.

리전마다 짧은 코드가 붙습니다. 자주 보는 것들:

리전코드한국에서의 거리
서울ap-northeast-2가장 가까움 (10~30ms)
도쿄ap-northeast-150~70ms
오사카ap-northeast-350~80ms
싱가포르ap-southeast-180~120ms
미국 동부 (버지니아)us-east-1180~230ms
미국 서부 (오레곤)us-west-2130~170ms
유럽 (프랑크푸르트)eu-central-1250~300ms

2026년 현재 33개 이상의 리전이 운영 중입니다. 콘솔 우측 상단의 리전 선택기로 전환할 수 있습니다.

리전을 어떻게 고르는가 #

대부분의 사용자가 한국에 있다면 **서울 (ap-northeast-2)**이 첫 후보입니다. 하지만 다음 기준에서는 다른 답이 나올 수 있습니다.

1) 사용자 위치와 지연 (Latency). 사용자가 일본 / 동남아 / 미국에 분포한다면 가까운 리전이 유리합니다. 글로벌 서비스라면 CloudFront (Edge 분산)로 분산하기도 합니다.

2) 법규 / 데이터 주권. 한국의 일부 산업 (금융, 의료)은 데이터를 한국 안에 두라는 규제가 있어 서울 리전이 사실상 강제됩니다. 유럽 GDPR도 비슷한 방식으로 영향을 줍니다.

3) 서비스 가용성. 모든 서비스가 모든 리전에 다 있는 건 아닙니다. 새로운 서비스 / 기능은 보통 us-east-1에서 먼저 출시되고 다른 리전으로 퍼집니다. 리전 선택 전에 AWS Regional Services List에서 확인하세요.

4) 가격. 같은 서비스도 리전마다 가격이 다릅니다. us-east-1이 일반적으로 가장 쌉니다. 지연이 문제가 안 되는 배치성 작업은 저렴한 리전을 고려해 볼 만합니다.

5) 새 서비스 베타 / 신기능. 위 3)의 반대로, 항상 최신 기능을 써보고 싶다면 us-east-1이 답입니다.

리전은 격리되어 있다 #

리전 사이는 물리적,논리적으로 격리되어 있습니다. 서울 리전에서 만든 EC2 / S3 / RDS는 도쿄 리전 콘솔에서 보이지 않습니다. 리전 간 통신은 명시적으로 설정해야 합니다 (VPC peering, S3 cross-region replication 등).

이게 중요한 이유:

  • 한 리전이 장애가 나도 다른 리전은 멀쩡 (재해 복구 설계의 기본)
  • 리소스 ID / ARN 안에 리전이 포함되어 있음
  • IAM 콘솔에서 “왜 내 EC2가 안 보이지?” → 십중팔구 리전 잘못 선택

가용 영역 (Availability Zone, AZ) #

리전 안을 한 단계 더 들어가면 **가용 영역 (AZ)**이 있습니다. 한 리전 안에 3~6개의 AZ가 있습니다. 각 AZ는 물리적으로 떨어진 데이터센터입니다. 보통 수십 km 떨어져 있어 전력과 네트워크가 독립적입니다.

서울 리전 (ap-northeast-2)의 AZ:

ap-northeast-2의 AZ 
ap-northeast-2a
ap-northeast-2b
ap-northeast-2c
ap-northeast-2d

AZ 코드의 a/b/c/d는 계정마다 다르게 매핑됩니다. 내 계정의 ap-northeast-2a와 다른 사람의 ap-northeast-2a가 같은 물리 AZ가 아닐 수 있습니다. AWS가 부하 분산을 위해 셔플하기 때문입니다. 그래서 협업할 땐 AZ ID (apne2-az1 같은)라는 또 다른 식별자를 씁니다. 콘솔 EC2 → 가용 영역 페이지에서 확인할 수 있습니다.

Multi-AZ의 의미 #

한 AZ가 다운되면 그 AZ의 모든 EC2 / RDS는 같이 다운됩니다. 운영 시스템은 Multi-AZ로 설계해 한 AZ 장애를 견뎌야 합니다.

전형적인 패턴:

Multi-AZ 설계 예시 
                  Route 53
                     │
                     ▼
              Application Load Balancer
                  ╱        ╲
                 ╱          ╲
        ┌───────▼──┐    ┌──▼──────┐
        │   AZ a   │    │   AZ b  │
        │  EC2 #1  │    │ EC2 #2  │
        │  EC2 #2  │    │ EC2 #3  │
        └─────┬────┘    └────┬────┘
              ╲              ╱
               ╲            ╱
                ▼          ▼
            RDS Primary  RDS Standby
              (AZ a)       (AZ b)
  • ALB는 자동으로 여러 AZ에 분산 (중급 #6)
  • EC2는 ASG (Auto Scaling Group)로 여러 AZ에 배포
  • RDS Multi-AZ 옵션을 켜면 standby가 다른 AZ에 자동 생성, 장애 시 페일오버

Multi-AZ는 비용이 듭니다. 학습 / 사이드 프로젝트는 단일 AZ도 충분합니다. 운영 트래픽이 실제로 흐르는 서비스에서만 켭니다.

Edge Location과 주변 인프라 #

리전 / AZ 외에도 AWS의 글로벌 인프라 거점이 더 있습니다.

거점설명용도
Edge Location전 세계 600+ 곳의 작은 거점CloudFront / Route 53가 사용자에 가깝게 응답
Local Zone대도시 안에 둔 작은 리전 확장수 ms 지연이 필요한 워크로드 (게이밍, 미디어)
Wavelength Zone5G 통신사 안에 둔 거점모바일 5G 사용자 지연 최소화
Outposts사용자 데이터센터 안에 둔 AWS 하드웨어온프레미스 + AWS 일관성

이 시리즈에서는 Edge Location만 중급 #7 CloudFront에서 다시 만납니다. 나머지는 일반적인 백엔드 운영에선 거의 쓰이지 않습니다.

글로벌 서비스 vs 리전 서비스 #

AWS의 200개 서비스는 두 종류로 나뉩니다.

글로벌 서비스 #

리전을 고르지 않고, 콘솔 어느 리전에서 봐도 같은 데이터를 보여주는 서비스입니다.

서비스특성
IAM사용자 / 역할 / 정책. 계정 단위
S3버킷 이름은 글로벌 유일 (리전은 버킷 단위)
Route 53DNS. 인터넷 자체가 글로벌
CloudFrontEdge 분산. 본질적으로 전 세계
WAF (CloudFront 용)CloudFront와 같이 글로벌
Organizations계정 묶음

콘솔에서 글로벌 서비스를 열면 우측 상단 리전 선택기가 **“Global”**로 자동 전환됩니다.

리전 서비스 #

리전마다 따로따로 존재하는 서비스입니다. 대부분이 여기 속합니다.

  • EC2 / RDS / VPC / Lambda / ECS / DynamoDB. 만든 리전 안에서만 보이고 동작
  • CloudWatch. 메트릭 / 로그가 리전마다 따로 (글로벌 대시보드는 별도)

S3는 살짝 헷갈리는 부분입니다. 버킷 자체는 한 리전에 살지만 이름은 전 세계에서 유일해야 합니다. 그래서 S3 콘솔이 글로벌처럼 보이면서도 데이터는 리전 단위로 저장됩니다.

시작하기: 콘솔 둘러보기 #

가입 후 첫 로그인 화면 (콘솔 홈)에서 자주 보는 항목:

  • 상단 검색창. 서비스 이름으로 바로 이동 (예: EC2, S3)
  • 상단 리전 선택기. 항상 의식하기. 잘못된 리전에서 작업하는 게 가장 흔한 실수
  • 상단 우측 사용자 메뉴. 계정 ID, 결제 정보, 보안 자격 증명
  • 즐겨찾기 (별 아이콘). 자주 쓰는 서비스 핀
  • CloudShell 아이콘. 브라우저 안 터미널 (#5)

첫 셋업 체크리스트 #

가입 직후 다음 글들을 차례로 진행합니다.

  1. #2 IAM. 일상 작업용 IAM 사용자 만들기. 루트로 일하지 않기.
  2. #3 비용 관리. 결제 알림 / 무료 티어 한도 설정. 첫 청구서 충격 방지.
  3. #6 보안 기본. 루트 + IAM 사용자 둘 다 MFA.

이 셋이 실제 작업을 시작하기 전에 반드시 끝내야 할 단계입니다.

자주 만나는 함정 #

1) “왜 내 리소스가 안 보이지?” #

콘솔에서 분명히 만든 EC2가 안 보입니다. 99%는 리전 선택 실수입니다. 우측 상단을 확인하세요.

2) 루트 키 노출 #

가입 직후 “API를 써보자"며 루트 사용자의 액세스 키를 만들고 GitHub에 코드와 함께 푸시합니다. 몇 분 안에 봇이 발견해 가상화폐 채굴이 돌아갑니다. 다음 날 청구서에 수만 달러가 찍힙니다.

절대 하면 안 되는 것:

  • 루트 액세스 키 만들기
  • 액세스 키를 코드 / git에 넣기
  • 액세스 키를 README, 슬랙, 이메일에 붙이기

#6에서 자세히 다루겠습니다.

3) 잘못된 리전에서 이전 작업 흔적 #

서울에서 만들었다고 생각하는 EC2가 사실은 버지니아에 있었습니다. 청구서에 잡힌 뒤에야 발견합니다. 이미 한 달치 비용이 나간 뒤입니다. 모든 리전에 대해 자원을 정기적으로 점검하거나, #3의 결제 알림으로 조기에 감지하세요.

4) 리전 간 데이터 전송 비용 #

같은 리전 안의 트래픽은 보통 무료지만 리전 간 / 인터넷으로 나가는 트래픽 (Egress)은 GB당 과금됩니다. Multi-region 설계할 땐 이 비용이 의외로 크게 나옵니다.

5) 단일 AZ 운영 #

작은 시스템이라도 운영에 들어가면 Multi-AZ 검토. EC2 한 대 + RDS 단일 AZ → 한 AZ 장애 시 전면 다운. 비용 ↔ 가용성의 트레이드오프를 명확히.

정리 #

이번 글에서 잡은 것:

  • 클라우드와 AWS의 등장. 사거나 빌리던 인프라가 분 단위로 바뀝니다. AWS는 그 흐름의 사실상 표준입니다.
  • 계정. 루트 사용자는 셋업과 결제에만 쓰고, 일상 작업은 IAM 사용자로 합니다 (#2).
  • 계정 ID. ARN 안에 포함됩니다. 멀티 어카운트는 Organizations로 묶습니다.
  • 리전. 전 세계 33곳 이상입니다. 사용자 위치 / 법규 / 서비스 가용성 / 가격 / 신기능으로 선택합니다.
  • AZ. 리전 안의 데이터센터 단위입니다. Multi-AZ가 운영의 기본 패턴입니다.
  • Edge Location. CloudFront가 사용하는 거점입니다 (중급 #7).
  • 글로벌 vs 리전 서비스. IAM / S3 (이름) / Route 53 / CloudFront만 글로벌입니다.
  • 함정. 리전 잘못 선택, 루트 키 노출, 잠자고 있는 다른 리전 자원, Egress 비용, 단일 AZ 운영입니다.

다음: IAM #

콘솔 둘러보기는 끝났습니다. 이제 루트 사용자에서 벗어나 일상 작업용 IAM 사용자를 만들 차례입니다.

#2 IAM: 사용자, 그룹, 역할, 정책에서는 IAM의 4가지 요소 (사용자 / 그룹 / 역할 / 정책)를 한 번에 정리하고, 운영에서 통하는 권한 설계 패턴까지 다루겠습니다.

X