1 장

AWS 입문 — 계정 · 리전 · AZ

AWS에 무언가를 올리기 전에 머릿속에 있어야 할 지도. 클라우드와 AWS의 등장, 계정과 루트 사용자, 리전과 가용 영역(AZ), 글로벌 서비스와 리전 서비스의 차이, 그리고 가입 직후의 첫 셋업까지 정리합니다.

이 책의 첫 챕터입니다. 2장부터는 콘솔과 CLI로 실제 손이 움직이지만, 본 챕터에서는 그 전에 머릿속에 있어야 할 지도를 먼저 그립니다 — AWS 계정이 무엇이고, 리전과 가용 영역(AZ)이 무엇이며, “글로벌 서비스"와 “리전 서비스"의 차이가 어디서 오는지입니다.

이 책은 콘솔에서 시작해 4부부터 Terraform 코드로 옮겨가고, ECS Fargate 위에 풀스택 앱을 올려 운영하는 데서 끝납니다(6부 풀스택 앱 AWS 배포하기). 그 긴 흐름의 출발선이 본 챕터의 지도입니다. 가입 직후 반드시 거쳐야 하는 첫 셋업 — 2장 IAM · 3장 비용 관리 · 6장 보안 기본 — 도 본 챕터 끝에서 안내합니다.

클라우드와 AWS의 등장 #

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

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

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

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

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

AWS 계정 구조 #

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

루트 사용자 #

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

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

루트로는 가입 직후의 셋업, 결제 정보 확인, 계정 종료 정도만 합니다.
실제 작업은 2장 IAM에서 만든 IAM 사용자로 합니다.
루트에는 반드시 MFA를 겁니다(6장 보안 기본에서 다룹니다).
액세스 키는 만들지 않고, 이미 있다면 즉시 삭제합니다.

계정 ID와 ARN #

계정마다 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 등)는 리전 부분이 비어 있습니다. ARN은 4부 이후 Terraform 코드와 IAM 정책에서 끊임없이 등장하니, 모양만 눈에 익혀 두면 충분합니다.

멀티 어카운트와 AWS Organizations #

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

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

이 계정들을 묶어 청구를 통합하고 정책을 일괄 적용하는 도구가 AWS Organizations입니다. 처음에는 단일 계정으로 시작해도 충분합니다. Organizations는 두 번째 계정이 필요해질 때 자연스럽게 만나게 되며, 29장 보안 거버넌스에서 SCP · Control Tower와 함께 본격적으로 다룹니다.

본 책의 1~4부는 단일 계정을 가정하고 진행합니다. 멀티 어카운트는 5부에서 운영 규모가 커진 뒤의 이야기로 다룹니다.

리전 (Region) #

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

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

2026년 현재 36개가 넘는 리전이 운영 중입니다. 콘솔 우측 상단의 리전 선택기로 전환합니다.

리전을 어떻게 고르는가 #

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

사용자 위치와 지연 (Latency) — 사용자가 일본 / 동남아 / 미국에 분포한다면 가까운 리전을 고릅니다. 글로벌 서비스라면 14장 CloudFront의 Edge 분산으로 해소하기도 합니다.
법규 / 데이터 주권 — 한국의 일부 산업(금융, 의료)은 데이터를 한국 안에 두라는 규제가 있어 서울 리전이 사실상 강제됩니다. 유럽 GDPR도 비슷하게 영향을 줍니다.
서비스 가용성 — 모든 서비스가 모든 리전에 다 있는 것은 아닙니다. 새 서비스 / 기능은 보통 us-east-1에서 먼저 출시되고 다른 리전으로 퍼집니다.
가격 — 같은 서비스도 리전마다 가격이 다릅니다. us-east-1이 일반적으로 가장 쌉니다. 지연이 문제가 안 되는 배치성 작업은 저렴한 리전을 고려합니다.
새 서비스 베타 / 신기능 — 3번의 반대로, 항상 최신 기능을 써보고 싶다면 us-east-1입니다.

리전은 격리되어 있다 #

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

한 리전이 장애가 나도 다른 리전은 멀쩡합니다(재해 복구 설계의 기본이며 30장 재해 복구·백업에서 다룹니다).
리소스 ID와 ARN 안에 리전이 포함됩니다.
콘솔에서 “왜 내 EC2가 안 보이지?” 라면 십중팔구 리전을 잘못 선택한 것입니다.

가용 영역 (Availability Zone, AZ) #

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

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가 부하 분산을 위해 셔플하기 때문입니다. 그래서 협업할 때는 apne2-az1 같은 AZ ID라는 또 다른 식별자를 씁니다.

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에 분산합니다(13장 ALB / NLB와 ACM).
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 Zone	5G 통신사 안에 둔 거점	모바일 5G 사용자 지연 최소화
Outposts	사용자 데이터센터 안에 둔 AWS 하드웨어	온프레미스와 AWS의 일관성

이 책에서는 Edge Location만 14장 CloudFront에서 다시 만납니다. 나머지는 일반적인 백엔드 운영에서는 거의 쓰이지 않습니다.

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

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

글로벌 서비스 #

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

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

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

리전 서비스 #

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

EC2 / RDS / VPC / Lambda / ECS / DynamoDB — 만든 리전 안에서만 보이고 동작합니다.
CloudWatch — 메트릭과 로그가 리전마다 따로입니다(7장 CloudWatch 입문).

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

콘솔 둘러보기와 첫 셋업 #

가입 후 첫 로그인 화면(콘솔 홈)에서 자주 보는 항목은 다음과 같습니다.

상단 검색창 — 서비스 이름으로 바로 이동합니다(예: EC2, S3).
상단 리전 선택기 — 항상 의식합니다. 잘못된 리전에서 작업하는 것이 가장 흔한 실수입니다.
상단 우측 사용자 메뉴 — 계정 ID, 결제 정보, 보안 자격 증명.
CloudShell 아이콘 — 브라우저 안 터미널입니다(5장 CloudShell과 IAM Identity Center).

가입 직후에는 다음 세 챕터를 차례로 진행합니다. 실제 작업을 시작하기 전에 반드시 끝내야 할 단계입니다.

2장 IAM — 일상 작업용 IAM 사용자를 만들고, 루트로 일하지 않습니다.
3장 비용 관리 — 결제 알림과 무료 티어 한도를 설정해 첫 청구서 충격을 막습니다.
6장 보안 기본 — 루트와 IAM 사용자 둘 다 MFA를 겁니다.

자주 만나는 함정 #

“왜 내 리소스가 안 보이지?” — 콘솔에서 분명히 만든 EC2가 안 보인다면 99%는 리전 선택 실수입니다. 우측 상단을 확인합니다.
루트 키 노출 — 가입 직후 루트 사용자의 액세스 키를 만들어 GitHub에 코드와 함께 푸시하면, 몇 분 안에 봇이 발견하고 가상화폐 채굴이 돌아갑니다. 루트 액세스 키는 만들지 않고, 어떤 키도 코드 / git / README / 메신저에 넣지 않습니다(6장 보안 기본).
잘못된 리전의 잠자는 자원 — 서울에서 만들었다고 생각한 EC2가 사실 버지니아에 있어 한 달치 비용이 청구된 뒤 발견되는 경우가 흔합니다. 모든 리전을 정기 점검하거나 3장 비용 관리의 결제 알림으로 조기에 감지합니다.
리전 간 데이터 전송 비용 — 같은 리전 안의 트래픽은 보통 무료지만, 리전 간이나 인터넷으로 나가는 트래픽(Egress)은 GB 당 과금됩니다.
단일 AZ 운영 — 작은 시스템이라도 운영에 들어가면 Multi-AZ를 검토합니다. 비용과 가용성의 트레이드오프를 명확히 합니다.

연습문제 #

본인이 만들려는 서비스의 주 사용자가 어디에 있는지 한 줄로 적고, §“리전을 어떻게 고르는가"의 다섯 기준 중 어느 것이 리전 선택에 가장 크게 작용하는지 메모해 두세요. 25장 Terraform 입문에서 provider "aws" { region = ... }를 적을 때 이 메모가 첫 결정이 됩니다.
가입 직후 반드시 끝내야 할 첫 셋업 세 가지(IAM 사용자 · 결제 알림 · MFA)를 보지 않고 적어 보세요. 각 항목이 본 챕터의 “자주 만나는 함정” 중 어느 것을 막아 주는지 한 줄씩 연결해 두세요.
arn:aws:s3:::my-bucket와 arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0abc 두 ARN에서, 리전 부분이 한쪽은 비어 있고 한쪽은 채워진 이유를 §“글로벌 서비스 vs 리전 서비스"를 근거로 한 단락으로 설명해 보세요.

한 줄 요약: AWS는 사거나 빌리던 인프라를 분 단위로 바꾼 클라우드의 사실상 표준이다. 계정의 루트 사용자는 셋업과 결제에만 쓰고 일상 작업은 IAM 사용자로 하며, 계정 ID는 ARN 안에 들어간다. 리전은 전 세계 36곳이 넘는 격리된 물리 단위로 사용자 위치 · 법규 · 서비스 가용성 · 가격으로 고르고, 그 안의 AZ를 여러 개 쓰는 Multi-AZ가 운영의 기본이다. 서비스는 글로벌(IAM · S3 이름 · Route 53 · CloudFront)과 리전으로 나뉘고, 가장 흔한 실수는 리전 잘못 선택과 루트 키 노출이다.

다음 챕터 #

다음 2장 IAM에서는 루트 사용자에서 벗어나 일상 작업용 IAM 사용자를 만듭니다. IAM의 네 요소(사용자 · 그룹 · 역할 · 정책)를 한 번에 정리하고, 운영에서 통하는 최소 권한 설계 패턴까지 다룹니다.