Hook

서버 한 대를 구하려면 예전엔 몇 주가 걸렸습니다. 견적 받고, 발주 넣고, 랙에 올리고, OS 설치하고. AWS에서는 클릭 몇 번으로 60초면 됩니다. 이 차이가 클라우드입니다.

하지만 “클라우드”라는 단어 하나로 이 모든 걸 설명하기엔 갭이 큽니다. 리전, 가용 영역, 엣지 로케이션부터 탄력성, 내결함성, CDN까지 — 개념 없이 콘솔에 들어가면 길을 잃기 쉽습니다. 이 글에서는 AWS를 처음 접하는 분도 아키텍처 설계 시 참고할 수 있도록, 핵심 개념과 글로벌 인프라, 서비스 분류, 요금 모델까지 한 번에 정리합니다.

TL;DR

• 서비스 모델 3가지 — IaaS(인프라), PaaS(플랫폼), SaaS(완성 소프트웨어), 관리 책임 범위로 구분
• 글로벌 인프라 4계층 — Region → AZ → Edge Location → Local Zone/Wavelength
• 핵심 개념 4쌍 — 탄력성 vs 확장성, 내결함성 vs 고가용성, CDN, VPC
• 서비스 분류 12개 — 컴퓨팅/스토리지/네트워킹/DB/보안/분석/AI·ML/서버리스 등
• 요금 모델 — 온디맨드, 예약, 스팟, 사용량 기반 종량제

클라우드 컴퓨팅이란

클라우드 컴퓨팅은 인터넷을 통해 서버, 스토리지, 데이터베이스, 네트워킹 등의 컴퓨팅 리소스를 온디맨드로 제공받는 기술입니다. AWS는 2006년에 서비스를 시작하여 2026년 현재 200개 이상의 서비스를 전 세계 30개 이상의 리전에서 운영하고 있습니다.

핵심 특징은 다섯 가지입니다. 온디맨드 셀프 서비스(관리자 없이 자동 프로비저닝), 광범위한 네트워크 접근(다양한 기기에서 접근), 리소스 풀링(다중 테넌트 모델), 신속한 탄력성(빠른 확장·축소), 측정 가능한 서비스(사용량 기반 과금)입니다.

IaaS, PaaS, SaaS 구분

클라우드 서비스는 관리 책임의 범위에 따라 세 가지로 구분합니다.

• IaaS (Infrastructure as a Service) — 가상화된 컴퓨팅 인프라 제공. OS, 앱, 데이터를 고객이 관리. 예: EC2, VPC, EBS
• PaaS (Platform as a Service) — 개발/배포 플랫폼 제공. 앱과 데이터만 관리. 예: Elastic Beanstalk, Lambda, RDS
• SaaS (Software as a Service) — 완성된 소프트웨어 제공. 공급자가 거의 모든 것을 관리. 예: WorkSpaces

온프레미스에서 SaaS로 갈수록 고객의 관리 부담은 줄고 공급자의 책임은 커집니다.

On-Premise vs Cloud

전통적인 온프레미스 환경과 클라우드를 비교하면, 클라우드가 왜 빠르게 도입되는지 명확해집니다.

가장 큰 차이는 초기 투자비(CAPEX)와 확장 소요시간입니다. 온프레미스는 서버 구매에 주~개월이 걸리지만, 클라우드는 초~분 단위로 리소스를 늘리거나 줄일 수 있습니다. 용량 계획도 “최대 트래픽 기준”에서 “실시간 조정”으로 바뀝니다.

글로벌 인프라스트럭처

AWS는 전 세계에 분산된 인프라를 운영하여 사용자에게 낮은 지연시간과 고가용성을 제공합니다. 인프라는 계층 구조로 이해하면 깔끔합니다.

Region (리전)

리전은 전 세계 주요 대도시에 분포된 물리적 데이터센터 클러스터입니다. 2026년 현재 30개 이상의 리전이 운영되고 있으며, 각 리전은 독립적인 지리적 영역에 위치합니다.

리전 선택 기준은 네 가지입니다. 지연시간(사용자와 가까운 리전), 규정준수(데이터 주권, 법적 요구사항), 서비스 가용성(모든 리전이 모든 서비스를 제공하지는 않음), 비용(리전별 요금 차이)입니다. 주요 리전 코드로는 us-east-1(버지니아 북부), ap-northeast-2(서울), eu-west-1(아일랜드)이 있습니다.

Availability Zone (가용 영역)

가용 영역(AZ)은 리전 내에서 물리적으로 분리된 하나 이상의 데이터센터입니다. 각 AZ는 별도의 전력, 냉각, 네트워킹 인프라를 갖추고 있습니다.

일반적으로 하나의 리전은 3~6개의 AZ로 구성됩니다. AZ 간 지연시간은 1ms 이하이며, AZ 간 데이터 복제로 고가용성을 확보합니다. 단일 AZ 장애가 전체 리전에 영향을 주지 않는 것이 핵심입니다.

Edge Location 및 특수 인프라

AWS는 리전/AZ 외에도 다양한 엣지 인프라를 운영합니다. Edge Location은 CloudFront CDN의 캐시 서버로, 전 세계 600개 이상 운영됩니다. Local Zones는 대도시 중심의 엣지 인프라로 1자리 수 ms 지연시간을 제공합니다. Wavelength는 5G 통신사 네트워크 엣지에 배치된 인프라이고, Outposts는 고객 온프레미스 데이터센터에 구축하는 하이브리드 클라우드 솔루션입니다.

핵심 개념

탄력성 vs 확장성

탄력성(Elasticity)과 확장성(Scalability)은 자주 혼동되지만 명확히 다릅니다.

• 탄력성 — 수요 변화에 따라 리소스를 자동으로 추가/제거하는 능력. Scale Out(늘리기)과 Scale In(줄이기)을 반복. 예: Auto Scaling
• 확장성 — 시스템이 증가하는 부하를 처리할 수 있는 능력. 수직 확장(Scale Up, 사양 업그레이드)과 수평 확장(Scale Out, 서버 대수 증설)으로 구분

탄력성은 “수요에 맞춰 유연하게 변하는 것”이고, 확장성은 “더 큰 부하를 감당할 수 있는 능력”입니다.

내결함성 vs 고가용성

이 둘도 자주 섞이지만 대상이 다릅니다.

• 내결함성 — 장애가 발생해도 시스템이 중단 없이 계속 동작합니다. 예: Multi-AZ RDS의 자동 장애조치(Failover). Primary가 죽어도 Standby가 즉시 승격되어 무중단을 유지합니다
• 고가용성 — 장애 발생 시 최소한의 중단으로 빠르게 복구합니다. 보통 99.99% 이상의 가용성을 목표로 합니다. 예: ELB + 다중 AZ EC2. 한 AZ가 죽으면 ELB가 다른 AZ로 라우팅합니다

내결함성은 “장애를 견디는 것”, 고가용성은 “장애 후 빠르게 복구하는 것”입니다.

CDN (Content Delivery Network)

CDN은 전 세계에 분산된 서버 네트워크를 통해 사용자에게 콘텐츠를 빠르게 전달하는 시스템입니다. AWS의 CDN 서비스는 Amazon CloudFront입니다.

오리진(S3, EC2, ALB 등 원본 서버)의 콘텐츠를 엣지 로케이션에 캐싱합니다. 서울 사용자는 서울 엣지에서, 런던 사용자는 런던 엣지에서 응답을 받습니다. 캐시에 없으면 원본에 요청하고, 응답을 캐싱한 뒤 전달합니다. DDoS 방어(AWS Shield 통합)와 HTTPS termination 기능도 제공합니다.

VPC (Virtual Private Cloud)

VPC는 AWS 클라우드 내에 논리적으로 격리된 가상 네트워크입니다. 사용자가 IP 주소 범위(CIDR), 서브넷, 라우팅 테이블, 인터넷 게이트웨이를 직접 구성할 수 있습니다. 리전 단위로 생성되며 모든 AZ에 걸쳐 존재하고, 퍼블릭 서브넷과 프라이빗 서브넷으로 네트워크를 분리합니다. 보안 그룹과 네트워크 ACL로 접근을 제어합니다.

AWS 서비스 분류

AWS의 200개 이상의 서비스는 아키텍처 관점에서 카테고리로 분류할 수 있습니다.

초보자가 먼저 알아야 할 핵심 카테고리를 정리합니다.

위 분류는 학습 로드맵으로도 활용할 수 있습니다. 컴퓨팅 → 스토리지 → 네트워킹 → 데이터베이스 순으로 익히고, 보안은 모든 단계에서 병행하는 것이 좋습니다.

요금 모델

AWS는 종량제(Pay-as-you-go)를 기본으로 하되, 사용 패턴에 따라 최적화할 수 있는 4가지 요금 모델을 제공합니다.

온디맨드로 시작해 사용 패턴을 파악한 뒤, 안정적인 워크로드는 예약이나 Savings Plan으로 전환하는 것이 비용 최적화의 기본 전략입니다.

Well-Architected Framework 6원칙

AWS는 모든 아키텍처 설계 시 6가지 원칙을 권장합니다.

1. 운영 우수성 — 실행, 모니터링, 지속적 개선
2. 보안 — 데이터 보호, 위험 관리, 최소 권한
3. 안정성 — 장애 복구, 자동 복구, 확장
4. 성능 효율성 — 워크로드에 맞는 리소스 선택
5. 비용 최적화 — 불필요한 비용 제거
6. 지속 가능성 — 환경 영향 최소화 (2021년 추가)

이 원칙들은 서비스를 선택하고 아키텍처를 설계할 때 체크리스트로 활용할 수 있습니다.

Takeaway

1. 인프라는 계층으로 이해하세요 — Region → AZ → Edge Location의 계층 구조를 알면 지연시간과 가용성 설계가 명확해집니다. 어디에 배포하느냐가 아키텍처의 출발점입니다
2. 개념을 구분하면 서비스 선택이 쉬워집니다 — 탄력성 vs 확장성, 내결함성 vs 고가용성을 정확히 구분하면 Auto Scaling, ELB, Multi-AZ RDS를 언제 써야 하는지 바로 보입니다
3. 온디맨드로 시작하고, 약정으로 최적화하세요 — 처음엔 온디맨드로 사용 패턴을 관찰하고, 안정적인 워크로드는 예약/스팟/Savings Plan으로 전환해 비용을 절감합니다

AWS 시리즈 1/16

	첫 글입니다
	EC2 & EBS — AWS 컴퓨팅 완전 정복 →