0. 큰 그림 — 서버에서 서비스로

다른 이름: AWS 기초 · Region · Availability Zone · ARN · 관리형 서비스 · 공동 책임 모델내용 검토: 2026. 09. 07.

결론부터

AWS는 서버와 기능을 API로 빌려 쓰는 환경이며, 자원의 위치와 내가 맡을 관리 책임부터 구분하면 서비스 이름이 연결된다.

이 장에서 처음 나오는 말4개

서비스Service: EC2·S3처럼 AWS가 제공하는 기능과 API의 묶음.
리소스Resource: 서비스로 만드는 실제 대상. 인스턴스·볼륨·버킷 등이 있다.
리전Region: AWS 자원을 배치하는 지리적 영역. 서울 리전 코드는 ap-northeast-2다.
AZAvailability Zone: 리전 안에서 장애를 분리하도록 구성한 가용 영역.

사진을 올리고 목록을 조회하는 앱을 만든다고 생각해 보자. 직접 서버를 준비하면 장비·OS·디스크·네트워크와 앱을 모두 돌봐야 한다. AWS에서는 가상 서버를 빌릴 수도 있고, 파일 저장이나 코드 실행 기능을 API로 사용할 수도 있다. 어느 수준까지 맡길지에 따라 내가 설정하고 복구할 부분이 달라진다.

이 장은 뒤에서 만날 서비스들을 놓을 지도다. 읽고 나면 “지금 만든 것은 무엇이고, 어디에 있으며, 누가 관리하는가?”에 답할 수 있어야 한다.

서버를 빌리는 것에서 기능을 사용하는 것으로

직접 장비를 살 때는 CPU·메모리·디스크와 설치 장소를 먼저 준비한다. EC2(Elastic Compute Cloud)는 그중 컴퓨팅 자원을 인스턴스로 제공한다. S3(Simple Storage Service)는 서버에 디스크를 연결하는 절차 대신 객체를 저장하고 읽는 API를 제공한다.

콘솔은 화면으로, CLI(Command Line Interface)는 명령으로, SDK(Software Development Kit)는 코드로 AWS API를 사용하는 수단이다. 접근 수단을 바꿔도 IAM의 신원과 권한을 확인해야 한다.

“쓴 만큼 낸다”에서 쓴 것의 단위는 서비스마다 다르다. 실행 시간·저장 용량·요청·데이터 전송을 따로 읽어야 한다. 아무 요청이 없는 디스크도 저장 공간을 점유한다. 실제 비용 점검은 비용 장에서 이어진다.

서비스와 리소스의 이름을 분리하기

서비스	실제 리소스	운영할 때 붙잡을 식별자
EC2	인스턴스	`i-…`와 리전
EBS (Elastic Block Store)	볼륨	`vol-…`와 AZ
S3	버킷·객체	버킷 이름과 객체 key
Lambda	함수	함수 이름·ARN
IAM	사용자·역할	사용자·역할 ARN

ARN(Amazon Resource Name)은 정책이나 설정에서 AWS 리소스를 가리키는 이름이다. ARN 형식은 서비스에 따라 달라지며, 모든 칸이 항상 채워지는 것은 아니다.

arn:partition:service:region:account-id:resource

arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0123456789abcdef0
arn:aws:iam::123456789012:role/study-app
arn:aws:s3:::study-photos-example

두 번째 ARN은 리전 칸이 비어 있고, 세 번째는 리전·계정 칸이 비어 있다. 이름에 study를 붙였다고 권한이나 비용 범위가 제한되지는 않는다. 오류를 조사할 때는 표시 이름보다 계정·리전·ID/ARN을 기록한다.

리전·AZ·엣지는 서로 다른 자리다

리전은 지리적 영역이고, 각 리전은 여러 AZ로 구성된다. AZ는 하나 이상의 데이터센터로 구성될 수 있으므로 “AZ 하나 = 건물 하나”로 외우지 않는다. (리전과 AZ)

한 리전의 VPC 안에 서로 다른 AZ의 서브넷과 EC2가 배치되는 구조

그림에서는 VPC는 여러 AZ를 아우르지만 서브넷은 AZ 하나에 속한다는 경계만 본다. 실제 VPC 경로와 허용 규칙은 별도로 설정한다. 리전 안에는 VPC 밖에서 서비스 API로 사용하는 자원도 있다. S3 버킷을 EC2처럼 서브넷 안에 넣는 것으로 생각하지 않는다.

범위	대표 대상	헷갈리기 쉬운 점
글로벌	IAM 사용자·역할, CloudFront 배포	콘솔에서 리전을 바꿔도 같은 범위의 자원을 본다
리전	VPC, 일반적인 S3 버킷, Lambda 함수	다른 리전의 같은 이름과 구별한다
AZ	서브넷, EC2 인스턴스, EBS 볼륨	같은 리전이어도 AZ가 다르면 EBS 연결 조건이 달라진다

엣지 로케이션은 사용자 가까이에서 콘텐츠를 전달하는 거점이다. CloudFront는 엣지를 사용하는 CDN(Content Delivery Network)이고, Route 53은 DNS 서비스다. WAF(Web Application Firewall)는 웹 요청 필터링, Shield는 DDoS(분산 서비스 거부) 방어를 맡는다. 이 이름들을 모두 “내가 서버를 배치할 AZ”로 묶지 않는다. CloudFront의 전달 경로는 공식 개요에서 확인한다.

관리형·서버리스는 책임이 이동하는 정도다

선택	AWS에 맡기는 부분	내가 계속 맡는 부분
EC2에 앱·DB 설치	물리 장비·가상화 기반	게스트 OS, 패치, 앱·DB 운영, 백업·복구 구성
RDS (Relational Database Service)	DB 기반 인프라와 관리 기능	엔진·용량 선택, 데이터·권한, 백업·가용성 옵션
Lambda·S3	서버 준비와 기반 인프라 운영	코드 또는 데이터, 접근 정책, 서비스 설정·비용

EC2도 AWS가 기반 인프라를 관리한다. “비관리형”이라는 대비는 앱 운영자가 관리할 부분이 더 많다는 뜻으로 읽는다. Serverless도 물리 서버가 없다는 뜻이 아니라 고객이 서버를 직접 준비·관리하지 않는 사용 방식이다. 데이터와 권한까지 AWS가 대신 결정하지는 않는다. (공동 책임 모델)

가용성·확장성·내구성은 별개의 질문

가용성: 지금 요청을 처리할 수 있는가? 여러 AZ 배치와 장애 전환을 검토한다.
확장성: 요청이 늘어도 처리량을 늘릴 수 있는가? 인스턴스 수·서비스 용량과 병목을 확인한다.
내구성: 저장한 데이터가 사라지지 않는가? 복제와 보존 특성을 확인한다.
내결함성: 구성 요소가 고장 나도 기능을 계속 수행하는가? 장애를 가정해 설계·검증한다.

복제는 실수로 지운 데이터를 되돌리는 백업과 목적이 다르다. 관리형 서비스에서도 어떤 장애를 견딜지, 복구에 얼마나 걸려도 되는지를 정하고 해당 기능을 설정해야 한다.

사진 앱 하나로 뒤의 장을 연결하기

앱에서 필요한 일	읽을 장	답할 질문
운영자가 자원을 만든다	IAM · 비용	어떤 신원으로 만들고 비용을 어떻게 알아차릴까?
코드가 실행될 자리를 고른다	VPC · 컴퓨팅	어디에 두고 어디까지 직접 관리할까?
사진과 목록을 저장한다	저장소와 DB	파일 본문과 조회용 항목을 어떻게 나눌까?
업로드 후 썸네일을 만든다	서버리스와 연결	응답을 기다릴까, 나중에 처리할까?
사용자가 자기 사진만 읽는다	Cognito	로그인 토큰과 AWS 권한을 어떻게 연결할까?
수정하고 장애를 조사한다	배포와 관측	무엇을 배포했고 어느 구간에서 실패했을까?

이 예시는 각 서비스의 자리를 설명하기 위한 지도다. 모든 기능을 한 번에 만들 필요는 없다. 처음에는 사진 업로드·조회 경로 하나를 이해하고, 비동기 처리와 운영 기능을 필요에 따라 붙인다.

1. IAM — 신원과 권한서비스를 호출하는 주체와 그 주체가 할 수 있는 작업을 구분한다.