1장. 온프레미스와 클라우드의 이해

구분	온프레미스	클라우드
비용 방식	장비 선구매	사용량 기반 과금
초기 비용	높음	낮음
장기 비용	자원 활용률에 따라 유리할 수 있음	설계와 사용량에 따라 크게 변동

확장 방식

구분	온프레미스	클라우드
확장 방법	장비 추가 구매	즉시 서버 생성
확장 속도	느림	빠름
탄력성	제한적	자동 확장 가능

운영 책임

구분	온프레미스	클라우드
하드웨어	내부 책임	클라우드 사업자
OS / 애플리케이션	내부 책임	대부분 내부
물리 보안	내부 책임	사업자 책임

7. 갑자기 사용자가 10배 늘어난다면?

온프레미스

서버 용량이 부족하다
새 장비를 주문한다
배송과 설치를 기다린다
설정을 완료한다

시간이 오래 걸린다.

클라우드

서버를 여러 대 추가 생성한다
자동으로 트래픽을 분산한다

몇 분 안에 확장이 가능하다.

이 차이가 클라우드의 가장 큰 특징이다.

8. 클라우드는 무조건 더 좋은가?

그렇지는 않다.

사용량이 많아지면 비용이 커질 수 있다
설계를 잘못하면 불필요한 자원이 계속 과금된다
자동화와 운영 이해가 필요하다

클라우드는 단순한 서버 임대가 아니라
운영 방식의 변화다.

9. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

서버는 24시간 동작하는 컴퓨터다.
온프레미스는 서버를 직접 소유하고 운영하는 방식이다.
클라우드는 서버를 빌려 사용하는 방식이다.
두 모델의 차이는 위치가 아니라 운영 구조에 있다.

2장. 클라우드는 어떻게 서버를 제공하는가

1. 서버를 몇 분 만에 만드는 것이 가능한 이유

1장에서 우리는 클라우드가 서버를 임대하는 방식이라고 배웠다.

그렇다면 이런 질문이 생긴다.

버튼을 누르면 왜 몇 분 만에 서버가 만들어질까?
실제 물리 서버를 새로 설치하는 것일까?

답은 아니다.

클라우드는 대부분 가상화 기술을 이용해
하나의 물리 서버를 여러 개로 나누어 제공한다.

2. 물리 서버와 가상 서버

물리 서버

실제 하드웨어 장비
CPU, 메모리, 디스크, 네트워크 카드가 물리적으로 존재
데이터센터에 설치되어 있음

가상 서버

물리 서버 위에 소프트웨어적으로 만들어진 서버
독립된 운영체제를 실행
다른 가상 서버와 격리되어 동작

사용자는 가상 서버를 사용하지만,
실제로는 물리 서버의 자원을 나누어 사용하는 구조다.

3. 가상화란 무엇인가

가상화(Virtualization)는

하나의 물리 자원을 여러 개의 논리적 자원으로 나누는 기술

이다.

예를 들어:

CPU 32코어
메모리 256GB

를 가진 물리 서버가 있다면,

이를 나누어

4코어 / 16GB 서버 여러 개
8코어 / 32GB 서버 여러 개

처럼 만들 수 있다.

이렇게 만들어진 각각의 서버는
독립된 컴퓨터처럼 동작한다.

4. 하이퍼바이저의 역할

이 작업을 수행하는 소프트웨어를 하이퍼바이저라고 한다.

하이퍼바이저는 다음을 담당한다.

물리 CPU를 여러 개의 가상 CPU로 분할
메모리를 나누어 각 가상 서버에 할당
디스크를 논리적으로 분리
네트워크를 가상으로 구성

즉, 물리 자원을 관리하고 나누어주는 관리자 역할을 한다.

5. 왜 이것이 클라우드를 가능하게 하는가

클라우드 사업자는 대규모 데이터센터에
수많은 물리 서버를 보유하고 있다.

사용자가 “새 서버를 만들어 달라”고 요청하면,

이미 준비된 물리 서버 위에
하나의 가상 서버를 생성하고
운영체제를 올린 뒤
네트워크를 연결해준다

이 과정이 자동화되어 있기 때문에
몇 분 안에 서버가 생성될 수 있다.

물리 장비를 새로 설치하는 것이 아니라,
이미 존재하는 자원을 분할하여 제공하는 것이다.

6. 가상화의 장점

가상화는 클라우드에 다음과 같은 장점을 제공한다.

1) 빠른 생성

물리 설치 없이 즉시 서버 제공 가능

2) 높은 자원 활용률

하나의 물리 서버를 여러 사용자가 공유

3) 격리

한 가상 서버의 장애가 다른 서버에 직접 영향을 주지 않음

4) 유연한 확장

필요할 때 서버를 추가 생성 가능

7. 가상 서버는 완전히 독립적인가

가상 서버는 논리적으로 독립적이지만
물리 자원을 공유한다는 사실은 변하지 않는다.

따라서 다음과 같은 상황이 발생할 수 있다.

같은 물리 서버의 다른 가상 서버가 과도한 자원을 사용
네트워크 공유로 인한 지연
디스크 I/O 경쟁

이 문제를 줄이기 위해
클라우드 사업자는 자원 격리 기술을 지속적으로 발전시키고 있다.

8. 가상 머신과 컨테이너

가상화에는 두 가지 주요 방식이 있다.

가상 머신(VM)

독립된 운영체제를 포함
격리 수준이 높음
상대적으로 무거움

컨테이너(Container)

운영체제를 공유
가볍고 빠름
마이크로서비스 구조에 적합

현재 대부분의 클라우드 서비스는
가상 머신 기반 구조 위에서 시작되었으며,
최근에는 컨테이너 기술도 널리 활용되고 있다.

9. 클라우드 서비스마다 부르는 이름

각 클라우드 서비스는
이 가상 서버를 서로 다른 이름으로 부른다.

Amazon Web Services → EC2
Google Cloud Platform → Compute Engine
Microsoft Azure → Virtual Machine

이름은 다르지만,
기본 원리는 동일하다.

10. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

클라우드는 물리 서버를 직접 빌려주는 것이 아니다.
가상화 기술을 이용해 물리 자원을 나누어 제공한다.
하이퍼바이저가 자원을 분할하고 관리한다.
이 구조 덕분에 빠른 생성과 확장이 가능하다.

3장. 클라우드 서비스 모델의 이해

1. 같은 서비스를 다른 방식으로 운영한다면

우리가 간단한 웹 서비스를 만든다고 가정해보자.

사용자는 회원가입을 한다.
로그인 후 게시글을 작성한다.
게시글은 데이터베이스에 저장된다.

이 서비스를 운영하려면 다음이 필요하다.

서버
운영체제
웹 서버 프로그램
데이터베이스
네트워크 설정
보안 설정
백업 및 모니터링

이 중에서 누가 어디까지 관리하느냐에 따라
클라우드 서비스 모델이 나뉜다.

2. IaaS란 무엇인가

IaaS는 Infrastructure as a Service의 약자다.
인프라를 서비스 형태로 제공한다는 의미다.

예를 들어 Amazon Web Services 에서는
가상 서버 서비스를 EC2라고 부른다.

게시판 서비스를 IaaS로 운영하면 다음과 같다.

우리가 직접 해야 하는 일

가상 서버 생성
운영체제 설치 및 설정
웹 서버 설치
데이터베이스 설치
보안 패치 적용
백업 구성
확장 설계

클라우드는 서버, 네트워크, 스토리지를 제공하지만
그 위의 대부분은 우리가 책임진다.

IaaS는 온프레미스와 가장 유사한 모델이다.
차이는 물리 장비를 직접 소유하지 않는다는 점이다.

3. PaaS란 무엇인가

PaaS는 Platform as a Service의 약자다.
실행 환경을 서비스로 제공한다는 의미다.

같은 게시판 서비스를 PaaS로 운영하면
우리가 관리해야 할 영역이 줄어든다.

우리가 하는 일

애플리케이션 코드 작성
기능 개발
데이터 구조 설계

클라우드가 대신하는 일

운영체제 관리
런타임 환경 관리
자동 확장
일부 보안 패치
관리형 데이터베이스 운영

즉, 우리는 인프라보다
애플리케이션 개발에 집중하게 된다.

IaaS보다 추상화 수준이 한 단계 높다.

4. SaaS란 무엇인가

SaaS는 Software as a Service다.
완성된 소프트웨어를 서비스 형태로 제공하는 모델이다.

지금까지는 게시판을 “직접 만든다”는 전제였다.
하지만 SaaS에서는 게시판을 직접 개발하지 않는다.

이미 만들어진 서비스를 사용한다.

우리가 하는 일

계정 생성
사용자 관리
기능 설정
요금 결제

우리가 하지 않는 일

서버 관리
운영체제 관리
보안 패치
확장 설계
백업 구성
인프라 모니터링

이 모든 것은 서비스 제공자가 담당한다.

예를 들어
Microsoft 의 Microsoft 365,
Google 의 Google Workspace 등이 이에 해당한다.

SaaS는 개발이나 인프라 운영이 아닌
“서비스 사용”에 가깝다.

5. 한눈에 비교하면

같은 게시판 서비스를 기준으로 정리하면 다음과 같다.

모델	우리가 관리하는 범위
IaaS	운영체제 이상 대부분
PaaS	애플리케이션 중심
SaaS	거의 없음

오른쪽으로 갈수록
직접 관리해야 할 영역은 줄어들고
추상화 수준은 높아진다.

6. 왜 이렇게 나뉘어 있는가

클라우드는 단순히 서버를 빌려주는 산업이 아니다.
운영 부담을 얼마나 줄여줄 것인가에 따라 발전해왔다.

인프라만 제공 → IaaS
실행 환경까지 제공 → PaaS
완성된 소프트웨어 제공 → SaaS

즉, 관리 범위를 단계적으로 줄여가는 구조다.

7. 어떤 모델을 선택해야 할까

정답은 없다.
서비스의 목적과 조직의 역량에 따라 달라진다.

세밀한 제어가 필요하면 IaaS
개발 속도가 중요하면 PaaS
직접 개발할 필요가 없으면 SaaS

실제 환경에서는 이 모델들을 혼합해 사용한다.

예를 들어:

핵심 서비스는 IaaS
데이터베이스는 관리형(PaaS)
협업 도구는 SaaS

이처럼 상황에 맞게 조합하는 것이 일반적이다.

8. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

같은 서비스라도 운영 방식은 달라질 수 있다.
차이는 “누가 어디까지 관리하느냐”이다.
IaaS는 인프라 중심 모델이다.
PaaS는 실행 환경 중심 모델이다.
SaaS는 완성된 소프트웨어 모델이다.

4장. 클라우드 책임 공유 모델의 이해

1. 클라우드를 쓰면 모든 책임이 사라질까

클라우드를 처음 접하면 이런 생각을 할 수 있다.

서버를 빌렸으니, 보안과 장애도 클라우드가 다 책임지는 것 아닐까?

하지만 그렇지 않다.

클라우드는 모든 책임을 대신해주는 서비스가 아니다.
클라우드 사업자와 사용자 사이에 책임이 나뉘어 있다.

이것을 책임 공유 모델(Shared Responsibility Model) 이라고 한다.

2. 책임 공유 모델이란 무엇인가

책임 공유 모델은 다음을 의미한다.

클라우드는 인프라의 일부를 책임지고,
사용자는 그 위에서 동작하는 것에 대해 책임진다.

예를 들어 Amazon Web Services 는
자사 공식 문서에서 이 모델을 명확히 설명하고 있다.

핵심은 다음과 같다.

클라우드는 클라우드 자체의 보안(Security of the Cloud) 을 책임진다.
사용자는 클라우드 위에서 사용하는 것(Security in the Cloud) 을 책임진다.

3. 물리 인프라에 대한 책임

클라우드 사업자가 책임지는 영역은 다음과 같다.

데이터센터 건물 보안
물리 서버 장비
네트워크 장비
전력 및 냉각 시스템
하이퍼바이저 계층

즉, 우리가 직접 접근할 수 없는 물리 영역은
클라우드가 책임진다.

온프레미스라면 우리가 직접 관리해야 할 부분이다.

4. 운영체제와 애플리케이션은 누가 책임질까

여기서부터는 서비스 모델에 따라 달라진다.

IaaS의 경우

물리 서버 → 클라우드 책임
가상 서버 → 클라우드 책임
운영체제 → 사용자 책임
애플리케이션 → 사용자 책임
데이터 → 사용자 책임

즉, OS부터 위는 우리가 관리한다.

PaaS의 경우

운영체제 → 클라우드 책임
런타임 환경 → 클라우드 책임
애플리케이션 코드 → 사용자 책임
데이터 → 사용자 책임

관리 범위가 줄어든다.

SaaS의 경우

인프라 → 클라우드 책임
플랫폼 → 클라우드 책임
애플리케이션 운영 → 클라우드 책임
데이터 입력 및 접근 권한 관리 → 사용자 책임

SaaS에서도 데이터 보호와 접근 제어는
사용자의 책임이다.

5. 실제 사고 사례를 생각해보자

예를 들어 이런 상황을 가정해보자.

서버에 보안 패치를 적용하지 않았다.
관리자 비밀번호를 단순하게 설정했다.
데이터베이스를 외부에 공개했다.

이 경우 책임은 누구에게 있을까?

클라우드가 아니라
사용자에게 있다.

클라우드는 “환경”을 제공하지만,
그 위의 설정 실수까지 대신 책임지지는 않는다.

6. 책임 공유 모델이 중요한 이유

클라우드 전환을 고려할 때
가장 흔한 오해 중 하나는 다음이다.

클라우드로 가면 보안이 자동으로 해결된다.

하지만 실제로는

잘못된 권한 설정
과도하게 열린 네트워크
암호화 미적용
백업 미구성

등은 여전히 사용자의 책임이다.

따라서 클라우드는 보안을 없애는 기술이 아니라,
보안의 경계를 바꾸는 모델이다.

7. 책임 공유 모델을 한눈에 정리하면

영역	IaaS	PaaS	SaaS
데이터센터	클라우드	클라우드	클라우드
물리 서버	클라우드	클라우드	클라우드
운영체제	사용자	클라우드	클라우드
애플리케이션	사용자	사용자	클라우드
데이터	사용자	사용자	사용자

오른쪽으로 갈수록
사용자의 관리 범위는 줄어든다.
하지만 데이터 책임은 항상 사용자에게 있다.

8. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

클라우드는 모든 책임을 대신해주지 않는다.
물리 인프라는 클라우드가 책임진다.
운영체제와 애플리케이션은 모델에 따라 달라진다.
데이터 보호 책임은 항상 사용자에게 있다.
보안은 사라지는 것이 아니라 경계가 이동하는 것이다.

5장. 클라우드의 과금 구조 이해하기

1. 왜 클라우드 비용은 체감이 다를까

온프레미스에서는 비용 구조가 비교적 단순하다.

서버 구매 비용
랙 비용
회선 비용
유지보수 비용

대부분 고정 비용이다.

하지만 클라우드는 다르다.

자원을 “소유”하지 않고 “사용”하기 때문에
비용이 사용량에 따라 계속 변한다.

이 차이 때문에 클라우드 비용은
예측이 어렵게 느껴질 수 있다.

2. 클라우드 과금의 기본 원리

클라우드 과금의 핵심은 단순하다.

사용한 만큼 지불한다.

대표적인 클라우드 사업자인
Amazon Web Services 역시
대부분의 서비스가 사용량 기반 과금이다.

과금 단위는 다음과 같이 나뉜다.

서버 사용 시간
CPU / 메모리 크기
스토리지 용량
네트워크 트래픽
요청 횟수

즉, 자원을 여러 단위로 나누어 계산한다.

3. 서버 과금은 어떻게 계산될까

가상 서버(IaaS)의 경우 보통 다음 요소로 계산된다.

인스턴스 유형 (CPU, 메모리 크기)
실행 시간 (시간 또는 초 단위)
추가 스토리지
네트워크 아웃바운드 트래픽

예를 들어,

24시간 계속 실행
고사양 인스턴스
트래픽이 많음

이면 비용이 크게 증가한다.

반대로,

필요할 때만 실행
자동 종료
소형 인스턴스 사용

이면 비용을 줄일 수 있다.

4. 스토리지와 네트워크 비용

초보자가 가장 자주 놓치는 부분이
네트워크 비용이다.

스토리지 과금

저장 용량 기준
I/O 요청 횟수 기준
백업 및 스냅샷 용량 기준

네트워크 과금

클라우드 내부 트래픽
리전 간 트래픽
인터넷으로 나가는 트래픽

특히 인터넷으로 나가는 트래픽(아웃바운드)은
비용이 빠르게 증가할 수 있다.

스트리밍, 이미지 서비스, 대용량 다운로드 서비스는
이 부분이 매우 중요하다.

5. 고정 비용과 변동 비용의 차이

온프레미스는 고정 비용 중심이다.

서버를 구매하면 비용은 이미 발생
사용률이 높을수록 효율이 좋아짐

클라우드는 변동 비용 중심이다.

사용량이 적으면 비용도 적음
사용량이 많으면 비용도 증가

즉, 클라우드는 유연성을 제공하는 대신
비용이 예측하기 어려울 수 있다.

6. 언제 클라우드가 비싸게 느껴질까

다음과 같은 환경에서는
클라우드가 오히려 더 비싸게 느껴질 수 있다.

24시간 고부하가 지속되는 서비스
자원을 거의 100% 사용 중인 환경
이미 감가상각이 끝난 장비 운영 중인 경우

이 경우 온프레미스가 비용 효율이 더 높을 수 있다.

7. 언제 클라우드가 유리할까

다음과 같은 경우에는 클라우드가 유리하다.

트래픽 변동이 큰 서비스
특정 시간대만 고부하
빠른 실험과 확장이 필요한 환경
초기 투자 비용을 줄이고 싶은 경우

클라우드는 “항상 싸다”가 아니라
“필요한 만큼만 쓴다”는 점이 핵심이다.

8. 비용을 이해하는 사고 방식

클라우드를 사용할 때는
다음 질문을 항상 해야 한다.

이 서버는 24시간 필요할까?
자동으로 줄일 수 있는 구조인가?
트래픽을 줄일 방법은 없는가?
관리형 서비스가 오히려 효율적인가?

클라우드에서는
아키텍처 설계가 곧 비용 설계다.

9. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

클라우드는 사용량 기반 과금이다.
서버, 스토리지, 네트워크가 주요 비용 요소다.
네트워크 아웃바운드는 특히 주의해야 한다.
고정 부하 서비스는 온프레미스가 유리할 수 있다.
비용은 설계에 따라 크게 달라진다.

6장. 확장성과 가용성의 이해

1. 서버는 반드시 멈추지 않아야 할까

온프레미스 환경에서는 이런 생각이 자연스럽다.

서버는 절대 죽으면 안 된다.
가장 좋은 장비를 써야 한다.
장애는 최대한 막아야 한다.

하지만 현실에서는 어떤 시스템도
영원히 멈추지 않을 수는 없다.

하드웨어 고장
네트워크 장애
갑작스러운 트래픽 폭증
소프트웨어 오류

클라우드는 이 현실을 전제로 설계된다.

서버는 죽을 수 있다.
중요한 것은 “죽지 않게 만드는 것”이 아니라
“죽어도 서비스가 유지되게 만드는 것”이다.

2. 확장성이란 무엇인가

확장성(Scalability)은
부하가 증가해도 서비스를 유지할 수 있는 능력이다.

예를 들어:

사용자가 100명일 때는 서버 1대로 충분
사용자가 10,000명으로 늘어나면 서버가 더 필요

이때 어떻게 대응할 것인가가 확장성의 핵심이다.

3. 두 가지 확장 방식

수직 확장

기존 서버의 성능을 높인다.
CPU, 메모리를 더 큰 사양으로 변경한다.

한계가 명확하다.
장비 교체가 필요하고, 물리적 제한이 존재한다.

수평 확장

서버 수를 늘린다.
여러 대가 동시에 요청을 처리한다.

이 방식은 이론상 확장 한계가 낮다.
클라우드는 이 수평 확장에 매우 유리하다.

대표적인 클라우드 서비스 제공자인
Amazon Web Services 는
자동 확장 기능을 제공한다.

부하가 증가하면 서버를 자동으로 늘리고,
부하가 줄어들면 자동으로 줄인다.

4. 가용성이란 무엇인가

가용성(Availability)은
서비스가 얼마나 지속적으로 이용 가능한지를 의미한다.

예를 들어:

99% 가용성
99.9% 가용성
99.99% 가용성

숫자가 높을수록 장애 허용 시간이 줄어든다.

하지만 가용성은 단순히
“서버가 켜져 있는가”의 문제가 아니다.

하나의 서버가 꺼져도
전체 서비스는 계속 동작하는가?

이 질문이 핵심이다.

5. 단일 장애 지점

단일 장애 지점(Single Point of Failure)은
한 지점의 장애가 전체 서비스 중단으로 이어지는 구조다.

예:

서버 1대만 운영
데이터베이스 1대만 운영
로드 밸런서 없음

이 구조에서는 작은 장애도
전체 중단으로 이어진다.

클라우드는 이러한 단일 장애 지점을 제거하기 쉽게 만든다.

6. 다중 영역 구성

클라우드 환경에서는
서버를 서로 다른 물리적 영역에 배치할 수 있다.

Amazon Web Services 는
이를 리전과 가용 영역이라는 구조로 제공한다.

가용 영역은 서로 물리적으로 분리된 데이터센터
전력과 네트워크가 독립적
동시에 장애가 발생할 확률이 낮음

여러 영역에 서버를 배치하면
하나의 데이터센터가 장애가 나도
서비스는 유지된다.

7. 클라우드의 설계 철학

온프레미스 사고:

강력한 한 대의 서버
장애를 막는 구조

클라우드 사고:

여러 대의 비교적 작은 서버
장애를 전제로 한 구조
자동 확장
자동 복구

이 차이가 가장 중요하다.

클라우드는 완벽한 서버를 제공하는 것이 아니라
유연하게 복구 가능한 환경을 제공한다.

8. 확장성과 가용성은 비용과 연결된다

서버를 여러 대 운영하면 비용 증가
다중 영역 구성하면 비용 증가
데이터 복제하면 비용 증가

따라서 다음 질문이 중요하다.

우리 서비스는 어느 수준의 가용성이 필요한가?
장애 허용 범위는 어디까지인가?
비용 대비 적절한 설계는 무엇인가?

클라우드에서는
아키텍처 설계가 곧 비용 설계다.

9. 이 장의 핵심 정리

서버는 언제든지 장애가 날 수 있다.
클라우드는 장애를 전제로 설계한다.
수평 확장은 클라우드의 핵심 강점이다.
단일 장애 지점을 제거하는 것이 중요하다.
가용성 수준은 설계와 비용의 균형이다.

7장. 리전과 가용 영역의 이해

1. 서버를 여러 대 두면 충분할까

6장에서 우리는 단일 장애 지점을 제거해야 한다고 배웠다.

그렇다면 서버를 2대 이상 두면 충분할까?

만약 두 서버가 같은 건물,
같은 전력 설비, 같은 네트워크 장비를 사용한다면
건물 단위의 사고가 발생했을 때 둘 다 동시에 멈출 수 있다.

정전
화재
네트워크 장비 고장
자연 재해

따라서 고가용성을 위해서는
서버를 단순히 여러 대 두는 것이 아니라
물리적으로 분리된 위치에 배치해야 한다.

이 구조를 가능하게 하는 개념이
리전과 가용 영역이다.

2. 리전이란 무엇인가

리전(Region)은
클라우드 사업자가 특정 지리적 위치에 구축한
하나의 독립된 인프라 단위다.

예를 들어
Amazon Web Services 는
서울, 도쿄, 프랑크푸르트, 버지니아 등
전 세계 여러 리전을 운영하고 있다.

각 리전은 다음과 같은 특징을 가진다.

독립된 전력 인프라
독립된 네트워크 인프라
독립된 데이터센터 그룹
다른 리전과 물리적으로 분리

하나의 리전이 장애가 나더라도
다른 리전에는 영향을 주지 않도록 설계되어 있다.

리전은 재해 복구 단위라고 이해하면 쉽다.

3. 가용 영역이란 무엇인가

이제 중요한 개념이다.

가용 영역(Availability Zone, AZ)은
하나의 리전 안에 존재하는
서로 다른 물리적 데이터센터다.

여기서 중요한 점은 다음이다.

가용 영역은 데이터센터 내부의 구역이 아니다.
같은 건물 안의 다른 방이 아니다.

서로 완전히 분리된 독립 데이터센터다.

4. 가용 영역에 대한 흔한 오해

많은 사람들이 처음에 이렇게 생각한다.

하나의 데이터센터 건물 안에 여러 구역이 있는 것인가?
서버실을 나눈 개념인가?

아니다.

가용 영역은 다음과 같은 구조다.

예를 들어 서울 리전에 3개의 가용 영역이 있다면:

서울 내 서로 다른 위치의 3개 독립 데이터센터
전력 설비가 서로 다름
네트워크 인입 경로가 다름
동시에 장애가 날 확률이 매우 낮음

즉,

서울 강남의 데이터센터 하나
서울 마포의 데이터센터 하나
서울 성수의 데이터센터 하나

이런 개념에 가깝다.

(정확한 위치는 보안상 공개되지 않는다.)

5. 서울과 부산은 같은 리전일까

이론적으로는 하나의 리전에
서울과 부산이 포함될 수도 있다.

하지만 일반적으로는 다음 원칙이 있다.

같은 리전 안의 가용 영역은
지연 시간이 매우 낮아야 한다.
수 밀리초(ms) 수준의 빠른 통신이 가능해야 한다.

서울-부산처럼 거리가 먼 경우에는
보통 다른 리전으로 구분된다.

왜냐하면:

리전 간은 재해 복구 단위
가용 영역은 고가용성 단위
지연 시간 차이가 크기 때문

즉,

가용 영역은 “같은 도시권 내의 분리된 데이터센터”
정도로 이해하는 것이 가장 정확하다.

6. 왜 가용 영역이 중요한가

고가용성의 핵심은
단일 장애 지점을 제거하는 것이다.

예를 들어:

서버 1대 → 장애 시 서비스 중단
서버 2대를 서로 다른 가용 영역에 배치 → 한 영역 장애 시에도 서비스 유지

이를 다중 AZ 구성이라고 한다.

이 구조에서는:

한 데이터센터가 정전되어도
네트워크가 끊겨도
특정 건물에 사고가 발생해도

서비스는 계속 동작할 수 있다.

7. 리전과 가용 영역의 차이 정리

구분	리전	가용 영역
단위	지리적 지역	독립된 데이터센터
목적	재해 복구	고가용성
거리	도시/국가 단위	같은 도시권 내
지연 시간	비교적 있음	매우 낮음
장애 범위	대규모	부분적

리전은 “대규모 재해 대비”
가용 영역은 “일반적인 장애 대비”

라고 이해하면 쉽다.

8. 설계 철학과의 연결

6장에서 배운 내용을 다시 생각해보자.

서버는 죽을 수 있다.
데이터센터도 장애가 날 수 있다.
하나의 도시도 재해를 겪을 수 있다.

클라우드는 이를 전제로
리전과 가용 영역이라는 구조를 제공한다.

즉,

클라우드는 물리적 분리를 기본 설계로 제공한다.

이 점이 온프레미스와의 중요한 차이 중 하나다.

9. 이 장의 핵심 정리

서버 여러 대만으로는 충분하지 않다.
물리적 분리가 고가용성의 핵심이다.
리전은 지리적 단위다.
가용 영역은 서로 다른 물리적 데이터센터다.
가용 영역은 같은 건물 안의 구역이 아니다.
다중 AZ 구성은 기본 설계 전략이다.

8장. 서버 아키텍처의 기초 이해

이 장에서 말하고자 하는 것

클라우드는 새로운 개념처럼 보이지만,
결국 그 위에서 동작하는 것은 “서버”다.

클라우드를 이해하려면
먼저 서버가 무엇이고,
웹 서비스가 어떻게 구성되는지 이해해야 한다.

이 장의 목적은 다음 세 가지다.

서버의 기본 개념 이해
웹 서비스의 구성 요소 이해
클라우드 위에 올라가는 구조를 머릿속에 그릴 수 있게 만들기

1. 서버란 무엇인가

서버(Server)는 특별한 장비가 아니다.

다른 컴퓨터의 요청을 받아 처리하는 컴퓨터

이다.

웹 브라우저로 어떤 사이트에 접속하면
브라우저는 서버에 요청(Request)을 보내고,
서버는 처리 결과를 응답(Response)으로 반환한다.

이 구조를 클라이언트-서버 구조라고 한다.

클라이언트 → 요청을 보내는 쪽
서버 → 요청을 처리하는 쪽

2. 웹 서비스는 어떻게 동작하는가

게시판 서비스를 예로 들어보자.

사용자가 브라우저에서 글 작성 버튼 클릭
브라우저가 서버에 HTTP 요청 전송
서버가 요청을 처리
데이터베이스에 저장
결과를 다시 사용자에게 응답

이 과정은 하나의 서버가 아니라
여러 역할의 서버가 나누어 수행한다.

3. 서버의 역할 분리

서비스가 커질수록 서버의 역할을 나누게 된다.

1) 웹 서버

HTTP 요청을 받아 처리
정적 파일 제공 (이미지, CSS, JS)
애플리케이션 서버로 요청 전달

대표적인 웹 서버 소프트웨어:

Nginx
Apache

2) 애플리케이션 서버

실제 비즈니스 로직 처리
로그인 검증
게시글 저장 처리
API 응답 생성

예:

Node.js
Java (Spring)
PHP
Python (Django)

3) 데이터베이스 서버

데이터 저장
조회, 수정, 삭제 수행

대표적인 DB:

MySQL
PostgreSQL
MariaDB

4) 캐시 서버

자주 사용하는 데이터를 메모리에 저장
응답 속도 향상

예:

Redis
Memcached

왜 역할을 나누는가

성능 향상
부하 분산
보안 분리
확장성 확보
장애 영향 최소화

4. 서버 운영체제(OS)

서버도 운영체제가 필요하다.

대표적인 서버 OS는 다음과 같다.

1) Linux 계열

Ubuntu
Rocky Linux
Debian
CentOS (구버전)

특징:

오픈소스
라이선스 비용 없음
서버에 최적화
클라우드에서 가장 많이 사용

2) Windows Server

Microsoft 환경에 적합
.NET 기반 서비스와 궁합이 좋음
라이선스 비용 존재

클라우드에서 Linux가 많은 이유

비용 절감
자동화 도구와의 호환성
컨테이너 생태계
안정성

5. 서버는 항상 한 대로 운영할까 (Tier 구조)

초기에는 한 대로 시작할 수 있다.
하지만 확장성과 안정성을 위해 구조를 분리한다.

1) 단일 서버 구조 (All-in-One)

웹 + 앱 + DB 모두 한 서버

flowchart LR
    U["사용자/브라우저"] --> S["단일 서버 - Web + App + DB"]

장점:

간단
초기 구축 빠름

단점:

장애 시 전체 중단
확장 어려움

2) 2-Tier 구조

애플리케이션 서버와 DB 서버 분리

flowchart LR
    U["사용자/브라우저"] --> A["App 서버 - Web + App"]
    A --> DB["DB 서버"]

장점:

DB 보호 가능
앱 서버 확장 가능

3) 3-Tier 구조

웹 서버 / 애플리케이션 서버 / DB 서버 분리

flowchart LR
    U["사용자/브라우저"] --> W["Web 서버"]
    W --> A["App 서버"]
    A --> DB["DB 서버"]

장점:

역할 명확
확장 유연
보안 분리 가능

실무 확장 예시

flowchart LR
    U["사용자"] --> LB["로드밸런서"]
    LB --> W["Web 서버"]
    W --> A1["App 서버 1"]
    W --> A2["App 서버 2"]
    A1 --> DB["DB 서버"]
    A2 --> DB

이 구조가 클라우드에서 가장 흔한 형태다.

6. 클라우드와 서버의 연결

클라우드는 서버 구조를 바꾸는 것이 아니다.

웹 서버
앱 서버
DB 서버
캐시 서버

이 구성은 그대로 유지된다.

차이점은:

물리 장비를 직접 소유하지 않음
서버를 빠르게 생성 가능
자동 확장 가능
관리형 DB 사용 가능

즉,

클라우드는 기존 서버 아키텍처를
더 유연하게 운영할 수 있게 만든 환경이다.

7. 이 장의 핵심 정리

서버는 요청을 처리하는 컴퓨터다.
웹 서비스는 여러 역할의 서버로 구성된다.
Tier 구조는 확장성과 보안을 위한 설계 방식이다.
Linux는 클라우드에서 가장 많이 사용되는 서버 OS다.
클라우드는 서버 구조 위에서 동작한다.

9장. 상태와 무상태의 이해

1. 상태란 무엇인가

상태(State)란
어떤 시스템이 이전 요청의 정보를 기억하고 있는 것을 의미한다.

예를 들어:

로그인 후 세션 정보가 서버 메모리에 저장됨
장바구니 정보가 특정 서버에 저장됨
사용자의 임시 데이터가 서버 내부에 보관됨

이 경우, 서버는 이전 요청의 정보를 “기억”하고 있다.

이를 상태가 있는 서버라고 한다.

2. 상태가 있는 서버의 문제점

상태가 있는 서버는 처음에는 단순해 보인다.
하지만 확장성과 연결되면 문제가 발생한다.

1) 로드밸런싱 문제

사용자가 로그인 후
서버 A에 세션이 저장되었다고 가정하자.

이후 요청이 서버 B로 전달되면
B는 로그인 정보를 알지 못한다.

즉, 특정 사용자가 특정 서버에 묶이게 된다.

이를 세션 종속성(Session Affinity) 문제라고 한다.

2) 서버 장애 시 데이터 손실

서버 A가 장애로 종료되면
그 서버 메모리에 있던 세션 정보도 사라진다.

사용자는 다시 로그인해야 할 수 있다.

3) 수평 확장의 제약

클라우드에서는 서버를 여러 대로 늘리는 것이 일반적이다.

하지만 상태가 서버 내부에 있다면
서버를 자유롭게 늘리고 줄이기 어렵다.

Auto Scaling이 제대로 동작하기 힘들다.

3. 무상태란 무엇인가

무상태(Stateless)는
각 요청이 독립적으로 처리되는 구조를 의미한다.

즉,

어떤 서버가 요청을 받아도 동일한 결과를 낼 수 있어야 한다.
이전 요청 정보에 의존하지 않는다.

서버는 단순히 요청을 처리하는 역할만 한다.

4. 왜 클라우드에서는 무상태가 중요한가

클라우드는 다음을 전제로 설계된다.

서버는 언제든지 종료될 수 있다.
Auto Scaling으로 서버 수가 변한다.
다중 AZ 환경에서 서버가 분산된다.

이 환경에서 상태를 서버 내부에 저장하면
구조가 복잡해진다.

따라서 클라우드에서는
무상태 설계를 기본 전략으로 사용한다.

5. 무상태 설계는 어떻게 구현하는가

무상태가 되기 위해서는 상태를 서버 외부로 분리해야 한다.

1) 세션을 데이터베이스에 저장

로그인 정보
사용자 설정 정보

모든 서버가 같은 DB를 참조한다.

2) 캐시 서버 사용

Redis 같은 외부 캐시에 세션 저장.

장점:

빠른 속도
서버 간 공유 가능

3) JWT 방식 사용

로그인 정보를 토큰 형태로 사용자에게 전달하고
서버는 토큰을 검증만 수행.

서버가 세션을 저장하지 않아도 된다.

6. 상태와 무상태 비교

구분	상태 있음	무상태
세션 저장 위치	서버 내부	외부 저장소
확장성	제한적	매우 유리
장애 대응	취약	유리
로드밸런싱	복잡	단순

7. 현실적인 접근

완전한 무상태가 항상 가능한 것은 아니다.

예를 들어:

파일 업로드 중 임시 저장
대용량 처리 작업
트랜잭션 처리

이 경우에도
핵심 원칙은 같다.

서버 내부가 아니라 외부 저장소에 상태를 둔다.

8. 설계 철학으로서의 무상태

온프레미스 사고:

서버는 오래 살아있다.
메모리에 저장해도 괜찮다.

클라우드 사고:

서버는 언제든지 교체될 수 있다.
서버는 일시적인 존재다.
상태는 외부에 둔다.

이 사고 전환이
클라우드 네이티브 설계의 핵심이다.

9. 이 장의 핵심 정리

상태는 이전 요청 정보를 기억하는 것이다.
상태가 서버 내부에 있으면 확장이 어렵다.
무상태는 요청이 독립적인 구조다.
클라우드에서는 무상태 설계를 권장한다.
상태는 외부 저장소에 분리하는 것이 원칙이다.

10장. 서버와 네트워크의 연결 이해

이 장에서 말하고자 하는 것

우리는 서버가 무엇인지 배웠다.
그렇다면 이제 질문이 생긴다.

사용자의 요청은 어떻게 그 서버까지 도달하는가?

이 장은
서버와 사용자를 연결하는 네트워크의 기본 원리를 이해하는 장이다.

1. 우리는 어떻게 서버에 접속하는가

사용자가 브라우저를 열고
어떤 웹사이트에 접속한다고 가정해보자.

우리는 보통 이렇게 입력한다.

www.example.com

엔터를 누르면 화면이 나타난다.

하지만 실제로는 다음과 같은 과정이 발생한다.

내 컴퓨터가 서버의 위치를 알아낸다.
그 위치로 데이터를 보낸다.
서버가 응답을 다시 보낸다.

이 과정을 가능하게 하는 것이 네트워크다.

2. 네트워크란 무엇인가

네트워크는

컴퓨터와 컴퓨터를 연결하는 구조

다.

인터넷은 전 세계의 수많은 네트워크가 연결된 거대한 구조다.

우리가 웹사이트에 접속한다는 것은
내 컴퓨터가 인터넷을 통해
어딘가에 있는 서버와 통신한다는 의미다.

3. 서버의 위치는 어떻게 알까 — IP 주소

서버와 통신하려면
서버의 “위치”를 알아야 한다.

이 위치 정보가 IP 주소다.

IP 주소는

네트워크 안에서 장치를 구분하는 주소

다.

예:

203.0.113.10
142.250.206.78

택배를 보내려면 주소가 필요하듯,
데이터를 보내려면 IP 주소가 필요하다.

4. 그런데 우리는 왜 IP를 입력하지 않을까 — DNS

우리는 숫자(IP) 대신 도메인을 입력한다.

www.google.com

DNS(Domain Name System)는

사람이 기억하기 쉬운 도메인 이름을
컴퓨터가 통신 가능한 IP 주소로 변환해주는 시스템

이다.

DNS 흐름 다이어그램

sequenceDiagram
    participant B as 브라우저
    participant DNS as DNS 서버
    participant S as 웹 서버

    B->>DNS: www.example.com 의 IP는?
    DNS-->>B: 203.0.113.10

    B->>S: 203.0.113.10:443 으로 요청
    S-->>B: HTML/데이터 응답

요약하면:

도메인 입력 → DNS 조회 → IP 확인 → 서버 연결

5. 모든 IP가 인터넷에 공개되어 있을까

IP에는 두 종류가 있다.

이걸 이해하기 위해 전화번호로 비유해보자.

공인 IP → 일반 전화번호. 누구든 그 번호로 전화를 걸 수 있다.
사설 IP → 회사 내선번호. 회사 안에서만 통하고, 외부에서는 그 번호로 전화할 수 없다.

1) 공인 IP

인터넷 전체에서 유일한 주소다.

외부 어디서든 이 IP로 직접 접근할 수 있기 때문에
웹 서버처럼 외부에 공개해야 하는 서버에 사용한다.

예: 1.2.3.4

2) 사설 IP

내부 네트워크 안에서만 쓰이는 주소다.

외부에서는 이 IP로 직접 접근할 수 없기 때문에
DB 서버처럼 외부에 노출되면 안 되는 시스템에 사용한다.

예: 192.168.0.10

그러면 같은 IP를 공인으로도 쓰고 사설로도 쓰는 건가?

아니다.

사설 IP로 쓸 수 있는 범위는 처음부터 정해져 있다.
아래 범위에 해당하면 무조건 사설 IP다.

10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

집에서 공유기에 연결했을 때
192.168.0.x 같은 IP를 본 적이 있을 거다.

그게 바로 사설 IP다. 이 범위의 IP는 인터넷에서 직접 사용할 수 없다.

즉,

공인과 사설은 내가 고르는 게 아니라
IP 주소 자체가 어느 범위에 속하느냐로 이미 정해져 있는 것이다.

6. 사설 IP 서버가 외부와 통신해야 하는 경우 — NAT

앞에서 사설 IP는 외부에서 직접 접근할 수 없다고 했다.

그러면 이런 의문이 든다.

사설 IP를 쓰는 서버는 인터넷이 아예 안 되는 건가?

결론부터 말하면, 그렇지 않다.

사설 IP 서버도 외부와 통신이 필요한 순간이 있다

생각보다 흔한 상황이다.

결제/문자/인증 같은 외부 API를 호출해야 할 때
서버의 OS나 패키지를 업데이트해야 할 때
도커 이미지 같은 것을 외부에서 내려받아야 할 때

이런 경우, 사설 IP 그대로는 인터넷에 요청을 보낼 수 없다.

그래서 등장하는 것이 NAT(Network Address Translation) 다.

NAT는 뭘 하는 건가

쉽게 말하면,

내부 사설 IP를 외부 공인 IP로 바꿔치기해서
인터넷과 통신할 수 있게 해주는 기술이다.

회사 내선번호로는 외부에 전화를 걸 수 없지만,
회사 대표번호를 통해 나가면 외부 통화가 가능한 것과 같다.

예를 들어:

내부 서버 IP: 10.0.0.5 (사설)
외부로 나갈 때: 1.2.3.4 (공인)로 변환되어 통신

그래서 NAT가 주는 이점은?

내부 서버는 필요할 때 인터넷을 사용할 수 있으면서도,
외부에서 직접 들어오는 접근은 기본적으로 차단된다.

즉, 나가는 건 되지만 들어오는 건 안 되는 구조다.

이게 바로 사설 IP + NAT 조합이
보안 측면에서 많이 쓰이는 이유다.

7. IP만 알면 서버에 접속할 수 있을까?

서버의 IP를 알면 그 서버까지는 찾아갈 수 있다.

하지만 한 가지 문제가 있다.

서버 안에는 여러 서비스가 동시에 돌아갈 수 있다

예를 들어 하나의 서버에서 이런 것들이 동시에 실행되고 있다고 해보자.

웹사이트를 보여주는 서비스
관리자가 원격으로 접속하는 서비스
데이터를 저장하고 꺼내는 데이터베이스

IP는 하나인데, 서비스는 여러 개다.

그러면 자연스럽게 이런 의문이 든다.

같은 IP로 들어왔는데,
이 요청이 웹사이트를 보려는 건지,
원격 접속을 하려는 건지,
데이터베이스에 접근하려는 건지
서버는 어떻게 구분할까?

그래서 포트(Port)가 존재한다

앞에서 IP를 택배 주소에 비유했다.

택배 주소로 건물까지는 찾을 수 있지만,
그 건물 안에 카페도 있고 사무실도 있고 병원도 있다면
몇 호로 가야 하는지도 알아야 한다.

IP = 건물까지의 주소
포트 = 건물 안의 호수

서버도 마찬가지다.
같은 IP라도 포트 번호에 따라 다른 서비스로 연결된다.

대표적인 포트 번호:

포트 번호	서비스	쉽게 말하면
80	HTTP	일반 웹사이트
443	HTTPS	보안 웹사이트
22	SSH	원격 접속
3306	MySQL	데이터베이스

그래서 실제로 브라우저가 웹사이트에 접속할 때는
IP만 쓰는 게 아니라 포트까지 포함해서 요청을 보낸다.

예: 1.2.3.4:443 → 이 서버의 보안 웹사이트 서비스로 연결해줘

다만 브라우저가 443 같은 기본 포트는 자동으로 붙여주기 때문에
우리가 직접 입력할 일은 거의 없다.

8. 전체 흐름 다시 정리

웹사이트 접속 과정은 다음과 같다.

도메인 입력
DNS가 IP 반환
브라우저가 IP의 특정 포트로 요청 전송
서버가 응답 반환

이 모든 과정은 네트워크 규칙 위에서 동작한다.

9. 이 장의 핵심 정리

서버와 사용자는 네트워크로 연결된다.
서버의 위치는 IP 주소로 식별된다.
우리는 도메인을 입력하지만 실제 통신은 IP로 이루어진다.
공인 IP와 사설 IP는 이미 정해진 주소 대역이다.
NAT는 내부 IP를 외부 IP로 변환한다.
포트는 하나의 서버 안에서 서비스를 구분하는 번호다.

다음 장에서는 이 개념을 바탕으로 클라우드 안에서 나만의 네트워크를 만드는 방법, VPC와 서브넷 구조를 살펴본다.

11장. 트래픽과 접근 제어의 이해

이 장에서 말하고자 하는 것

10장에서 우리는 다음을 배웠다.

도메인은 DNS를 통해 IP로 변환된다.
서버는 IP와 포트로 식별된다.
사설 IP와 공인 IP는 용도가 다르다.
포트는 서버 안의 서비스를 구분한다.

그렇다면 이제 질문이 생긴다.

서버는 아무나 언제든지 접근할 수 있을까?

답은 아니다.

1. 서버는 기본적으로 열려 있지 않다

보안을 생각해보자.

데이터베이스가 인터넷에 그대로 공개되어 있다면?
관리자 접속 포트가 모든 사람에게 열려 있다면?

매우 위험하다.

그래서 서버는 기본적으로
모든 접근을 허용하는 것이 아니라 차단하는 것이 원칙이다.

필요한 것만 열어준다.

이것이 접근 제어(Access Control)다.

2. 트래픽이란 무엇인가

네트워크에서 오가는 데이터를 트래픽(Traffic)이라고 한다.

서버 기준으로 보면
트래픽은 두 방향이 있다.

들어오는 트래픽
나가는 트래픽

이를 인바운드와 아웃바운드라고 부른다.

3. 인바운드와 아웃바운드

인바운드(Inbound)

외부 → 서버로 들어오는 트래픽

예:

사용자가 웹사이트 접속
개발자가 원격 접속

아웃바운드(Outbound)

서버 → 외부로 나가는 트래픽

예:

외부 API 호출
패키지 다운로드
운영체제 업데이트

4. 포트를 연다는 의미

10장에서 포트를 배웠다.

80 → HTTP
443 → HTTPS
22 → SSH
3306 → MySQL

이제 중요한 질문이 있다.

“포트를 연다”는 것은 무엇을 의미할까?

그 의미는 다음과 같다.

특정 포트로 들어오는 인바운드 트래픽을 허용한다는 것

예를 들어:

443번 포트 인바운드 허용 → 웹 접속 가능
22번 포트 특정 IP만 허용 → 관리자만 접속 가능
3306번 포트 외부 차단 → 데이터베이스 보호

포트와 접근 제어는 항상 함께 작동한다.

5. 접근 제어의 실제 예시

웹 서버의 경우

인바운드 443 허용 (모든 사용자)
인바운드 22는 관리자 IP만 허용
아웃바운드는 외부 API 호출 가능

데이터베이스 서버의 경우

인바운드 외부 전면 차단
내부 서버 IP만 허용
아웃바운드는 필요 시 허용

이렇게 하면
외부에서 DB에 직접 접근하는 위험을 막을 수 있다.

6. 왜 기본은 차단인가

보안의 기본 원칙은 다음과 같다.

필요한 것만 허용하고, 나머지는 차단한다.

이를 최소 권한 원칙(Principle of Least Privilege)이라고 한다.

인터넷에 연결된 서버는
항상 외부의 접근 시도를 받을 수 있다.

따라서 “기본 허용”은 매우 위험하다.

7. 이 장의 핵심 정리

서버는 기본적으로 열려 있지 않다.
트래픽은 인바운드와 아웃바운드로 나뉜다.
포트를 연다는 것은 해당 서비스 접근을 허용한다는 의미다.
접근 제어는 보안을 위한 기본 장치다.
최소 권한 원칙은 서버 설계의 기본이다.

12장. EC2란 무엇인가

이 장에서 말하고자 하는 것

우리는 이제 알고 있다.

서버란 무엇인가
네트워크가 어떻게 연결되는가
접근은 어떻게 통제되는가
클라우드 서버는 가상 서버라는 것

그렇다면 이제 질문이 생긴다.

AWS에서는 이 가상 서버를 무엇이라고 부를까?

그 이름이 바로 EC2다.

1. EC2의 의미

EC2는 Elastic Compute Cloud의 약자다.

이 이름에는 세 가지 의미가 담겨 있다.

Elastic → 필요에 따라 늘어나고 줄어드는
Compute → 연산 자원 (CPU, 메모리)
Cloud → 클라우드 환경

즉,

EC2는 클라우드에서 제공하는 탄력적인 가상 서버다.

2. EC2는 무엇을 제공하는가

EC2는 우리가 직접 서버를 구매하지 않고도
다음 자원을 사용할 수 있게 해준다.

CPU
메모리
네트워크
디스크

우리는 필요한 사양을 선택하고
몇 분 안에 서버를 생성할 수 있다.

3. EC2는 물리 서버인가?

아니다.

EC2는 실제 장비가 아니라
AWS의 물리 서버 위에 만들어진 가상 서버다.

사용자 입장에서는
일반 서버와 동일하게 동작한다.

운영체제를 설치할 수 있고
프로그램을 실행할 수 있으며
웹 서비스를 운영할 수 있다.

하지만 실제 장비 관리(전원, 교체, 하드웨어 장애 등)는
AWS가 담당한다.

4. EC2에서 “인스턴스”란 무엇인가

EC2에서는 서버를 인스턴스(Instance) 라고 부른다.

이 말은

하나의 실행 중인 가상 서버

를 의미한다.

즉,

EC2 서비스 = 서버를 제공하는 시스템
EC2 인스턴스 = 우리가 만든 실제 가상 서버

라고 이해하면 된다.

5. 인스턴스 타입이란 무엇인가

EC2를 만들 때는 사양을 선택해야 한다.

예를 들어:

작은 서버
메모리가 많은 서버
CPU가 많은 서버

이 사양 묶음을 인스턴스 타입이라고 한다.

쉽게 말해:

어떤 크기의 서버를 빌릴 것인가

를 선택하는 단계다.

작게 시작할 수도 있고,
더 큰 사양으로 변경할 수도 있다.

6. EC2는 어떻게 생성되는가

EC2를 생성하는 과정은 다음과 같다.

운영체제 선택
서버 사양 선택
네트워크 설정
접근 규칙 설정
서버 생성

지금은 이 흐름만 이해하면 충분하다.

각 단계에서 등장하는 개념은
다음 장에서 하나씩 살펴본다.

7. 온프레미스 서버와 EC2의 차이

구분	온프레미스	EC2
서버 확보 방식	장비 구매	클릭으로 생성
준비 시간	수일 ~ 수주	몇 분
확장	장비 추가 필요	즉시 생성 가능
하드웨어 관리	직접 관리	AWS가 관리

즉,

EC2는 서버를 “소유”하는 것이 아니라
필요할 때 “사용”하는 방식이다.

8. 왜 EC2가 중요한가

클라우드 환경에서 대부분의 서비스는 이 EC2 위에서 시작된다.

웹 서버
API 서버
배치 서버
테스트 서버

모두 EC2 위에서 동작할 수 있다.

EC2를 이해하면
클라우드 인프라의 중심을 이해한 것이다.

9. 이 장의 핵심 정리

EC2는 AWS가 제공하는 가상 서버 서비스다.
EC2 인스턴스는 하나의 실행 중인 가상 서버다.
우리는 서버 사양(인스턴스 타입)을 선택해 생성한다.
서버 생성과 관리는 소프트웨어적으로 이루어진다.
물리 장비 관리는 AWS가 담당한다.

13장. 인스턴스 타입 이해하기

이 장에서 말하고자 하는 것

EC2는 가상 서버다.
그렇다면 이제 중요한 질문이 생긴다.

어떤 서버를 선택해야 할까?

무조건 가장 큰 서버를 쓰면 될까?

그렇지 않다.
클라우드는 사용한 만큼 비용이 발생한다.

따라서 인스턴스 선택은
성능과 비용을 동시에 고려하는 결정이다.

1. 인스턴스 타입은 실제로 어떻게 생겼을까?

AWS 콘솔에서 인스턴스 타입은 보통 이렇게 보인다.

t3.micro
m6i.large
c7g.xlarge
r6g.2xlarge
p4d.24xlarge
i4i.large

처음 보면 복잡해 보이지만 구조를 알면 어렵지 않다.

형식은 다음과 같다.

[패밀리][세대][옵션].[크기]

예:

m6i.large

2. 이름을 읽는 법

1️⃣ 패밀리 (m, t, c, r, p, i 등)

서버의 “성격”을 의미한다.

T → 버스트형
M → 균형형
C → CPU 중심
R → 메모리 중심
I → 스토리지 중심
P → GPU

2️⃣ 세대 숫자

숫자가 높을수록 최신 세대다.

일반적으로:

성능 개선
전력 효율 개선
내부 하드웨어 개선

이 이루어진다.

3️⃣ 옵션 문자 (i, g 등)

i → Intel 기반
g → ARM(Graviton) 기반

즉, CPU 아키텍처를 나타낸다.

4️⃣ 크기 (size)

nano
micro
small
medium
large
xlarge
2xlarge …

클수록 vCPU와 메모리가 증가한다.

3. 인스턴스를 구성하는 핵심 요소

1️⃣ vCPU

가상 CPU 개수.

동시 처리 능력과 관련
요청이 많을수록 중요

2️⃣ 메모리 (RAM)

캐시
세션
DB 처리
대용량 데이터 분석

3️⃣ 스토리지

네트워크 기반 디스크(EBS)
로컬 고속 디스크(Instance Store)

I/O 성능은 DB, 로그 분석 등에 큰 영향을 준다.

4️⃣ 네트워크 성능

대역폭
패킷 처리 능력

트래픽이 많은 서비스에서는 매우 중요하다.

4. 같은 vCPU라도 성능은 다를 수 있다

많은 초보자가 이렇게 생각한다.

vCPU 2개면 다 같은 성능 아닌가?

그렇지 않다.

이유 1️⃣ CPU 아키텍처 차이

예:

m6i → Intel 기반
m6g → ARM 기반

같은 2 vCPU라도 내부 CPU 구조가 다르다.

ARM은 전력 효율이 좋고 비용 대비 성능이 뛰어난 경우가 많다.
Intel/AMD는 기존 소프트웨어 호환성이 넓다.

이유 2️⃣ CPU 세대 차이

예:

m5.large (이전 세대)
m6i.large (신형 세대)

같은 2 vCPU라도:

클럭 속도
IPC(한 클럭당 처리 명령 수)
캐시 구조

가 다르다.

최신 세대는
같은 vCPU 수라도 더 많은 작업을 처리할 수 있다.

이유 3️⃣ vCPU는 물리 코어가 아닐 수 있다

vCPU는 실제 물리 코어와 1:1이 아닐 수 있다.

많은 경우:

1 물리 코어 = 2 vCPU (하이퍼스레딩)

즉,

vCPU 숫자는 성능의 절대 기준이 아니다.

확인 팁

AWS 공식 EC2 인스턴스 문서에서 각 인스턴스에 어떤 CPU가 장착되어 있는지 확인할 수 있습니다.

5. 메모리도 세대에 따라 차이가 있다

물리 서버에서는:

DDR4
DDR5

같은 메모리 세대 차이가 존재한다.

AWS에서는 메모리 규격을 직접 선택하지는 않지만,
세대가 올라갈수록:

메모리 대역폭 향상
지연 시간 감소

같은 개선이 반영된다.

즉,

최신 세대 인스턴스는 CPU뿐 아니라 메모리 성능도 함께 개선되는 경우가 많다.

6. 주요 패밀리 요약

T 계열 (Burstable)

저렴
순간 성능 상승 가능
개발/소규모 서비스

M 계열 (General Purpose)

CPU/메모리 균형
일반 웹 서비스

C 계열 (Compute Optimized)

CPU 중심
연산 작업, 고트래픽 API

R 계열 (Memory Optimized)

메모리 중심
데이터베이스, 캐시 서버

I 계열 (Storage Optimized)

고성능 디스크
로그 분석, 고성능 DB

P 계열 (GPU)

머신러닝, AI
비용 매우 높음

7. 무조건 큰 서버가 답일까?

클라우드는 시간 단위 과금이다.

과도한 사양 선택은
매월 불필요한 비용을 발생시킨다.

따라서 전략은 다음과 같다.

작은 사양으로 시작
모니터링
부족하면 확장
과하면 축소

8. 서비스 특성에 따라 선택하기

서비스 유형	추천 방향
일반 웹 서버	M 또는 T
고트래픽 API	C
데이터베이스	R
로그 분석	I
머신러닝	P

9. 이 장의 핵심 정리

인스턴스 타입은 이름 구조를 이해하면 읽을 수 있다.
패밀리는 서버의 성격을 의미한다.
같은 vCPU라도 CPU 아키텍처와 세대에 따라 성능이 다를 수 있다.
최신 세대 인스턴스는 성능과 효율이 개선되는 경우가 많다.
무조건 큰 사양이 정답은 아니다.
서비스 특성과 비용을 함께 고려해야 한다.

14장. EC2 스토리지 구성 이해하기

이 장에서 말하고자 하는 것

EC2 인스턴스를 생성할 때 우리는 다음을 선택한다.

인스턴스 타입 (CPU, 메모리)
스토리지

많은 경우 CPU와 메모리에 집중하지만,
실제 운영 환경에서는 디스크 성능이 병목이 되는 경우가 많다.

스토리지를 이해하는 것은
안정적인 서비스 운영을 위한 중요한 요소다.

1. 서버에서 스토리지는 어떤 역할을 하는가

서버의 디스크에는 다음이 저장된다.

운영체제
애플리케이션 코드
로그 파일
업로드 파일
데이터베이스 데이터

즉, 서버의 모든 데이터는 결국 디스크에 기록된다.

CPU가 빠르더라도
디스크에서 데이터를 읽고 쓰는 속도가 느리면
전체 응답 속도가 느려질 수 있다.

2. 디스크 성능을 판단하는 두 가지 기준

스토리지 성능은 주로 두 가지 수치로 표현된다.

① IOPS

IOPS는

초당 처리 가능한 읽기/쓰기 작업 횟수

를 의미한다.

예:

IOPS 3,000 → 1초에 3,000번 입출력 작업 가능
IOPS 16,000 → 더 많은 요청을 처리 가능

작은 데이터를 자주 읽고 쓰는 환경에서 중요하다.

예:

사용자 정보 조회
게시글 조회
주문 처리

② Throughput

Throughput은

초당 전송 가능한 데이터 양 (MiB/s)

을 의미한다.

예:

250 MiB/s
1,000 MiB/s

큰 파일을 다루는 환경에서 중요하다.

예:

대용량 파일 업로드
백업 작업
로그 파일 처리

IOPS와 Throughput의 차이

IOPS → 작업 “횟수”
Throughput → 데이터 “양”

서비스 특성에 따라
어떤 수치가 더 중요한지 달라진다.

3. EC2에서 사용하는 스토리지 종류

EC2에서 주로 사용하는 스토리지는 두 가지다.

① EBS (Elastic Block Store)

네트워크 기반 블록 스토리지
인스턴스와 분리 가능
스냅샷 지원
가장 일반적으로 사용됨

대부분의 운영 서버는 EBS를 사용한다.

② Instance Store

물리 서버에 직접 연결된 로컬 디스크
매우 빠른 I/O 성능
인스턴스 종료 시 데이터 삭제

임시 데이터나 캐시 용도로 사용된다.

4. EBS 볼륨 타입별 성능 비교

주요 EBS 타입의 공식 최대 성능은 다음과 같다.

EBS 볼륨 타입	IOPS (최대)	Throughput (최대)	특징
gp3	최대 16,000	최대 1,000 MiB/s	범용 SSD, 기본 선택
io2	최대 256,000	최대 4,000 MiB/s	고성능 SSD
st1	최대 500	최대 500 MiB/s	HDD, 대용량 순차 작업
sc1	최대 250	최대 250 MiB/s	저렴한 HDD, 장기 보관

공식 성능 수치는 AWS 문서에서 확인 가능합니다: EBS 볼륨 성능 비교 표 (AWS)

5. 각 볼륨 타입의 특징

gp3 (범용 SSD)

기본 IOPS 3,000
IOPS와 Throughput을 독립적으로 조정 가능
비용 대비 성능 우수

일반적인 웹 서비스나 API 서버에 적합하다.

io2 (Provisioned IOPS SSD)

매우 높은 IOPS 지원
지연 시간이 낮음
비용이 높음

대규모 데이터베이스나
고성능이 필수인 환경에 적합하다.

st1

HDD 기반
순차 읽기/쓰기에 적합
IOPS는 낮음

대용량 로그 처리나 분석용 저장소에 적합하다.

sc1

가장 저렴한 HDD
접근 빈도가 낮은 데이터에 적합

백업이나 장기 보관용 데이터에 사용된다.

6. 스토리지 때문에 발생하는 성능 차이

다음과 같은 상황이 있을 수 있다.

CPU 사용률은 낮다.
메모리도 충분하다.
그런데 서비스 응답이 느리다.

이 경우 디스크 성능이 부족할 가능성이 있다.

특히 데이터베이스는
디스크 성능에 직접적인 영향을 받는다.

7. 운영체제 디스크와 데이터 디스크 분리

EC2 인스턴스를 생성하면
운영체제가 설치되는 기본 디스크가 생성된다.

이 디스크에는:

운영체제
애플리케이션
데이터

를 모두 저장할 수 있다.

그러나 운영 환경에서는 보통 분리한다.

디스크 1 → 운영체제 전용
디스크 2 → 데이터 전용

이렇게 분리하면:

운영체제 문제 발생 시 데이터 보호 가능
데이터 디스크만 확장 가능
백업 및 복구 전략 수립이 용이

8. 스토리지와 인스턴스의 관계

EBS는 네트워크를 통해 인스턴스와 연결된다.

따라서 인스턴스 타입에 따라:

최대 EBS 대역폭
처리 가능한 I/O 한계

가 존재한다.

즉,

스토리지 성능은 디스크 타입뿐 아니라
인스턴스 사양과도 연결되어 있다.

서버 설계는 항상 전체 균형을 고려해야 한다.

9. 스토리지 선택 전략

일반적인 서비스는 gp3로 시작한다.
실제 모니터링을 통해 디스크 사용량과 I/O를 확인한다.
필요 시 IOPS를 조정한다.
고성능이 필요한 경우에만 io2를 고려한다.

클라우드는
초기에 과도한 사양을 선택할 필요가 없다.

10. 이 장의 핵심 정리

디스크는 서버 성능에 큰 영향을 준다.
IOPS는 작업 횟수, Throughput은 데이터 전송량이다.
gp3는 대부분의 환경에서 적합하다.
io2는 고성능이 필요한 경우에 사용한다.
운영체제와 데이터 디스크를 분리하면 관리가 용이하다.
스토리지 성능은 인스턴스 사양과도 연결되어 있다.

15장. 서버는 어디에 연결되는가

이 장에서 말하고자 하는 것

앞 장에서 우리는 EC2 인스턴스를 생성했다.

이제 서버는 준비되었다.

그렇다면 다음 질문이 생긴다.

이 서버는 인터넷 어디에 존재하는 걸까?

서버는 단순히
“클라우드 어딘가에 떠 있는 컴퓨터” 가 아니다.

모든 서버는 반드시
어떤 네트워크 안에 연결되어 있어야 한다.

이 장에서는

서버가 네트워크 안에서 어떻게 배치되는지
AWS에서 이 네트워크가 어떻게 구성되는지

를 이해한다.

1. 서버는 반드시 네트워크 안에 있어야 한다

서버는 혼자 존재할 수 없다.

왜냐하면 서버의 목적은
다른 시스템과 통신하는 것이기 때문이다.

예를 들어 웹 서비스는 보통 다음과 같이 동작한다.

flowchart LR
User[사용자] --> Server[웹 서버]
Server --> DB[데이터베이스]

사용자가 서버에 요청을 보낸다
서버는 데이터베이스에 데이터를 요청한다
결과를 사용자에게 전달한다

이 모든 과정은
네트워크 연결이 있어야만 가능하다.

즉,

모든 서버는 반드시 어떤 네트워크 안에 존재한다.

2. 온프레미스에서는 어떻게 네트워크를 만들까

먼저 우리가 익숙한 온프레미스 환경을 생각해보자.

보통 회사 내부 네트워크는 다음과 같은 구조를 가진다.

flowchart TB
Internet[인터넷]
Router[라우터 / 방화벽]
Switch[스위치]
Server1[웹 서버]
Server2[애플리케이션 서버]
Server3[DB 서버]

Internet --> Router
Router --> Switch
Switch --> Server1
Switch --> Server2
Switch --> Server3

이 구조의 특징은 다음과 같다.

회사 내부에 하나의 네트워크 공간이 존재한다
서버들은 이 네트워크 안에 배치된다
일부 서버만 외부 인터넷과 연결된다

즉 서버는 항상

특정 네트워크 공간 안에 배치된다.

3. 클라우드에서도 같은 문제가 발생한다

이제 클라우드 환경을 생각해보자.

AWS에는 수많은 회사들이 서버를 운영하고 있다.

만약 AWS가 모든 서버를
같은 네트워크에 연결한다면 어떤 일이 발생할까?

다른 회사 서버와 충돌
IP 주소 충돌
보안 문제

이 문제를 해결하기 위해 AWS는

고객마다 독립된 네트워크 공간을 제공한다.

이 네트워크가 바로 VPC다.

4. VPC란 무엇인가

VPC는 Virtual Private Cloud의 약자다.

간단히 말하면

클라우드 안에서 고객이 사용하는
독립된 네트워크 공간

이다.

개념적으로 보면 다음과 같다.

flowchart TB
Internet[인터넷]

subgraph VPC
Server1[EC2 서버]
Server2[EC2 서버]
Server3[EC2 서버]
end

Internet --> VPC

VPC 안에는 여러 서버를 배치할 수 있고
이 서버들은 서로 통신할 수 있다.

그리고 중요한 점이 하나 있다.

EC2 인스턴스는 반드시 하나의 VPC 안에서 생성된다.

즉 AWS에서 서버를 만들면
항상 어떤 네트워크 공간(VPC) 안에 위치하게 된다.

5. VPC 안의 서버는 IP 주소를 가진다

네트워크에서는
각 장비를 구별하기 위해 IP 주소를 사용한다.

예를 들어 다음과 같은 주소가 있다.

10.0.1.10
10.0.2.15
10.0.3.20

VPC 안에서 생성된 서버는
이처럼 하나의 IP 주소를 할당받는다.

이 IP 주소를 이용해
서버들은 서로 통신한다.

예를 들어

flowchart LR
Web[웹 서버]
App[애플리케이션 서버]
DB[DB 서버]

Web --> App
App --> DB

웹 서버 → 애플리케이션 서버
애플리케이션 서버 → 데이터베이스

이 모든 통신은
IP 주소를 기반으로 이루어진다.

6. 모든 서버가 인터넷에 노출될 필요는 없다

대부분의 서비스는
모든 서버가 인터넷에 연결될 필요가 없다.

예를 들어 다음 구조를 생각해보자.

flowchart TB
Internet[인터넷]

subgraph VPC
Web[웹 서버]
App[애플리케이션 서버]
DB[DB 서버]
end

Internet --> Web
Web --> App
App --> DB

이 구조에서

웹 서버 → 외부에서 접근 가능
애플리케이션 서버 → 내부 통신만 수행
DB 서버 → 외부 접근 차단

이 방식은 대부분의 서비스에서 사용하는 구조다.

이렇게 하면

보안 강화
네트워크 분리
내부 시스템 보호

가 가능하다.

7. VPC는 사용할 IP 주소 범위를 가진다

VPC는 하나의 네트워크 공간이기 때문에
사용할 수 있는 IP 주소 범위가 필요하다.

그래서 VPC를 생성할 때
다음과 같은 범위를 지정한다.

10.0.0.0/16

이 범위 안에서
각 서버에 IP 주소가 할당된다.

이 표기법을 CIDR이라고 부른다.

CIDR은 간단히 말하면

네트워크에서 사용할 IP 주소 범위를 표현하는 방법

이다.

이 개념은 다음 장에서
조금 더 자세히 살펴본다.

8. 이 장의 핵심 정리

모든 서버는 네트워크 안에서 동작한다.
온프레미스에서는 회사 내부 네트워크를 사용한다.
AWS에서는 이 네트워크 역할을 VPC가 담당한다.
EC2는 반드시 VPC 안에서 생성된다.
VPC 안의 서버는 IP 주소를 가진다.
일부 서버만 인터넷과 연결된다.
VPC는 사용할 IP 주소 범위(CIDR) 를 가진다.

16장. IP 주소 범위와 CIDR 이해하기

이 장에서 말하고자 하는 것

앞 장에서 우리는 VPC를 만들 때
다음과 같은 값을 지정하는 것을 보았다.

10.0.0.0/16

이 숫자는 단순한 설정값이 아니다.

이 값은

이 네트워크에서 어떤 IP 주소들을 사용할 수 있는지

를 정의한다.

이 장에서는

네트워크에서 IP 주소 범위가 왜 필요한지
CIDR 표기법이 무엇인지

를 이해한다.

1. 네트워크에서는 IP 주소가 필요하다

네트워크에 연결된 모든 장비는
자신을 식별할 수 있는 주소를 가져야 한다.

이 주소가 바로 IP 주소다.

예를 들어 다음과 같다.

10.0.1.10
10.0.1.20
10.0.2.15

이 IP 주소 덕분에

어떤 서버에 요청을 보내는지
어떤 서버가 응답을 보내는지

를 정확하게 구분할 수 있다.

2. 하지만 IP를 무작정 사용할 수는 없다

IP 주소는 마음대로 사용할 수 있는 것이 아니다.

네트워크에는

사용할 수 있는 IP 주소 범위

가 존재한다.

예를 들어 회사 내부 네트워크가 다음 범위를 사용한다고 가정해보자.

10.0.0.0 ~ 10.0.255.255

이 범위 안에서만
서버나 장비에 IP 주소를 할당할 수 있다.

즉 네트워크는 항상

IP 주소 범위를 기준으로 구성된다

3. AWS에서도 IP 주소 범위를 먼저 정한다

AWS에서도 동일하다.

VPC를 만들 때
다음과 같은 값을 설정한다.

10.0.0.0/16

이 값은

이 VPC가 사용할 IP 주소 범위

를 의미한다.

이 범위 안에서

EC2
데이터베이스
로드밸런서

같은 리소스들이
각자의 IP 주소를 할당받는다.

4. CIDR 표기법이란 무엇인가

여기서 등장하는 것이 바로 CIDR 표기법이다.

CIDR은

네트워크에서 사용할 IP 주소 범위를 표현하는 방식

이다.

예를 들어 다음과 같은 표기가 있다.

10.0.0.0/16

이 표기는 두 부분으로 구성된다.

10.0.0.0 → 네트워크 시작 주소
/16      → 네트워크 크기

즉

10.0.0.0/16

은 다음 범위를 의미한다.

10.0.0.0 ~ 10.0.255.255

이 범위 안에서 IP 주소를 사용할 수 있다.

5. CIDR 뒤의 숫자는 무엇을 의미할까

CIDR 뒤의 숫자는
네트워크 크기를 의미한다.

예를 들어 다음과 같은 CIDR이 있다.

10.0.0.0/16
10.0.0.0/24

이 둘은 네트워크 크기가 다르다.

CIDR	사용할 수 있는 IP 범위
10.0.0.0/16	10.0.0.0 ~ 10.0.255.255
10.0.0.0/24	10.0.0.0 ~ 10.0.0.255

즉

/16 → 매우 큰 네트워크
/24 → 더 작은 네트워크

이렇게 이해할 수 있다.

6. 왜 네트워크를 여러 개로 나눌까

하나의 큰 네트워크만 사용해도
서버를 운영할 수 있다.

하지만 실제 서비스에서는
네트워크를 여러 개로 나누는 경우가 많다.

예를 들어 다음과 같은 구조다.

10.0.1.x → 웹 서버
10.0.2.x → 애플리케이션 서버
10.0.3.x → 데이터베이스

이렇게 나누면

보안 관리가 쉬워지고
네트워크 구조가 명확해지고
서비스 구조를 분리할 수 있다.

이처럼 큰 네트워크를
작은 네트워크로 나누는 것을

서브넷 (Subnet)

이라고 한다.

8. 이 장의 핵심 정리

네트워크에서는 모든 장비가 IP 주소를 가진다.
네트워크는 항상 IP 주소 범위를 기준으로 구성된다.
AWS에서도 VPC를 만들 때 IP 범위를 지정한다.
이 범위를 표현하는 방식이 CIDR이다.
CIDR 뒤의 숫자는 네트워크 크기를 의미한다.
큰 네트워크는 여러 개의 서브넷으로 나눌 수 있다.

17장. 서브넷 (Subnet)

이 장에서 말하고자 하는 것

앞 장에서 우리는 VPC를 만들 때
다음과 같은 IP 주소 범위를 지정하는 것을 보았다.

10.0.0.0/16

이 범위는 하나의 큰 네트워크 공간이다.

하지만 실제 서비스에서는
이 네트워크를 그대로 사용하는 경우는 거의 없다.

보통 이 큰 네트워크를
여러 개의 작은 네트워크로 나누어 사용한다.

이 장에서는

네트워크를 왜 나누는지
그리고 그 구조가 무엇인지

를 이해한다.

1. 왜 네트워크를 나눌까

웹 서비스는 보통 여러 종류의 서버로 구성된다.

flowchart LR
    User[사용자] --> Web[웹 서버]
    Web --> App[애플리케이션 서버]
    App --> DB[데이터베이스]

예를 들어 다음과 같은 서버들이 있다.

웹 서버
애플리케이션 서버
데이터베이스 서버

만약 이 모든 서버가
같은 네트워크에 존재한다면

10.0.0.0/16

이 네트워크 안에 모든 서버가 섞이게 된다.

이렇게 되면

서버 역할을 구분하기 어렵고
네트워크 정책을 나누기 어렵고
관리가 복잡해진다.

그래서 보통 서버 역할에 따라
네트워크를 여러 개로 나누어 사용한다.

2. 이렇게 나눈 네트워크를 서브넷이라고 한다

앞에서 살펴본 것처럼
하나의 네트워크를 여러 개로 나누면
구조를 훨씬 쉽게 관리할 수 있다.

이처럼

하나의 큰 네트워크를
여러 개의 작은 네트워크로 나누는 것을

서브넷 (Subnet) 이라고 한다.

여기서 중요한 점은 다음이다.

서브넷은 서버 한 대를 위한 공간이 아니다
여러 서버를 배치하기 위한 네트워크 공간이다

예를 들어

웹 서버들이 모여 있는 네트워크
애플리케이션 서버들이 모여 있는 네트워크
데이터베이스 서버들이 있는 네트워크

이 각각이 하나의 서브넷이 될 수 있다.

3. 서브넷 구조 예시

예를 들어 다음과 같은 VPC가 있다고 하자.

10.0.0.0/16

이 네트워크를 다음처럼 나눌 수 있다.

10.0.1.0/24
10.0.2.0/24
10.0.3.0/24

각 네트워크는 서로 다른 서버 그룹을 담을 수 있다.

flowchart LR
    subgraph Region["Region"]
        subgraph VPC["VPC  10.0.0.0/16"]
            subgraph WebSubnet["Web Subnet  10.0.1.0/24"]
                Web1["웹서버"]
                Web2["웹서버"]
            end
            subgraph AppSubnet["App Subnet  10.0.2.0/24"]
                App1["애플리케이션 서버"]
                App2["애플리케이션 서버"]
            end
            subgraph DBSubnet["DB Subnet  10.0.3.0/24"]
                DB1[("DB 서버")]
                DB2[("DB 서버")]
            end
        end
    end

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style WebSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style AppSubnet fill:#e3f2fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:4
    style DBSubnet fill:#fce4ec,stroke:#e91e63,stroke-width:1px,stroke-dasharray:4
    style Web1 fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style Web2 fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style App1 fill:#e3f2fd,stroke:#1565c0,stroke-width:1px
    style App2 fill:#e3f2fd,stroke:#1565c0,stroke-width:1px
    style DB1 fill:#fce4ec,stroke:#c62828,stroke-width:1px
    style DB2 fill:#fce4ec,stroke:#c62828,stroke-width:1px

이 구조에서 중요한 점은 다음이다.

서브넷 안에는 여러 서버가 존재할 수 있다
서버 역할에 따라 네트워크를 나눌 수 있다

4. AWS에서 서브넷과 AZ의 관계

AWS에서는 서브넷을 생성할 때
어느 AZ에 속할지 함께 선택한다.

즉

서브넷 생성
→ AZ 선택

이 함께 이루어진다.

예를 들어 다음과 같은 구조가 가능하다.

flowchart LR
    subgraph AWSRegion["AWS Region"]

        subgraph AZa["Availability Zone A"]
            subgraph WebSubnet["Web Subnet"]
                Web1["웹 서버"]
                Web2["웹 서버"]
            end
        end

        subgraph AZb["Availability Zone B"]
            subgraph AppSubnet["App Subnet"]
                App1["애플리케이션 서버"]
                App2["애플리케이션 서버"]
            end
        end

        subgraph AZc["Availability Zone C"]
            subgraph DBSubnet["DB Subnet"]
                DB1[("DB 서버")]
            end
        end

    end

    style AWSRegion fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style AZa fill:#e6f4ea,stroke:#2e7d32,stroke-width:1px
    style AZb fill:#e3f2fd,stroke:#1565c0,stroke-width:1px
    style AZc fill:#fce4ec,stroke:#c62828,stroke-width:1px
    style WebSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style AppSubnet fill:#e8f0fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:4
    style DBSubnet fill:#fdecea,stroke:#e91e63,stroke-width:1px,stroke-dasharray:4
    style Web1 fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style Web2 fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style App1 fill:#e3f2fd,stroke:#1565c0,stroke-width:1px
    style App2 fill:#e3f2fd,stroke:#1565c0,stroke-width:1px
    style DB1 fill:#fce4ec,stroke:#c62828,stroke-width:1px

이처럼 서로 다른 AZ에
서브넷을 배치하면

장애 대응
서비스 안정성 향상

과 같은 효과를 얻을 수 있다.

5. 실무에서 많이 사용하는 서브넷 구조

실제 AWS 환경에서는
다음과 같은 구조가 많이 사용된다.

10.0.0.0/16  ← VPC

이 네트워크를 다음과 같이 나눈다.

10.0.1.0/24  ← Web Subnet
10.0.2.0/24  ← App Subnet
10.0.3.0/24  ← DB Subnet

즉 대부분의 환경에서는

VPC는 크게 만들고 (/16)
서브넷을 /24 단위로 나누어 사용한다.

이렇게 하면

네트워크 확장성이 좋아지고
구조를 이해하기 쉬워지고
관리가 쉬워진다.

6. 이 장의 핵심 정리

VPC는 하나의 큰 네트워크 공간이다.
큰 네트워크는 여러 개의 작은 네트워크로 나눌 수 있다.
이 작은 네트워크를 서브넷(Subnet) 이라고 한다.
서브넷 안에는 여러 서버가 배치될 수 있다.
AWS에서는 서브넷 생성 시 AZ를 선택한다.
보통 /16 VPC → /24 서브넷 구조를 많이 사용한다.

18장. 퍼블릭 서브넷과 프라이빗 서브넷

이 장에서 말하고자 하는 것

앞 장에서 우리는
VPC 안의 네트워크를 서브넷으로 나누는 방법을 살펴보았다.

예를 들어 다음과 같은 구조였다.

10.0.0.0/16  ← VPC

10.0.1.0/24
10.0.2.0/24
10.0.3.0/24

이렇게 네트워크를 나누면
서버 역할에 따라 구조를 분리할 수 있다.

하지만 여기서 한 가지 질문이 생긴다.

모든 서브넷이 인터넷과 연결되어야 할까?

실제 서비스에서는
모든 서버가 인터넷에 노출될 필요는 없다.

그래서 AWS에서는 서브넷을 보통 두 가지로 나눈다.

퍼블릭 서브넷 (Public Subnet)
프라이빗 서브넷 (Private Subnet)

1. 모든 서버가 인터넷에 연결될 필요는 없다

웹 서비스를 다시 생각해보자.

flowchart LR
    User[사용자] --> Web[웹 서버]
    Web --> App[애플리케이션 서버]
    App --> DB[데이터베이스]

이 구조에서

사용자는 웹 서버에만 접근한다
애플리케이션 서버는 웹 서버와만 통신한다
데이터베이스는 외부에서 접근할 필요가 없다

즉

인터넷 ↔ 웹 서버
웹 서버 ↔ 애플리케이션 서버
애플리케이션 서버 ↔ 데이터베이스

이런 구조가 된다.

그래서 서버의 역할에 따라
인터넷 접근 여부를 나누게 된다.

2. 퍼블릭 서브넷 (Public Subnet)

퍼블릭 서브넷은
인터넷과 직접 연결된 서브넷이다.

즉 외부 사용자가 접근할 수 있는 서버가 위치한다.

예를 들어

웹 서버
로드밸런서
Bastion 서버

같은 서버들이 여기에 위치한다.

예시 구조는 다음과 같다.

flowchart LR
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC"]
            subgraph PublicSubnet["Public Subnet"]
                Web1["웹 서버"]
                Web2["웹 서버"]
            end
        end
    end

    Internet --> Web1
    Internet --> Web2

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style Internet fill:#fff,stroke:#888,stroke-width:1px
    style Web1 fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style Web2 fill:#fff8e1,stroke:#f9a825,stroke-width:1px

퍼블릭 서브넷의 특징은 다음과 같다.

인터넷에서 접근 가능
외부 트래픽이 들어오는 서버 위치
보통 웹 계층이 위치

3. 프라이빗 서브넷 (Private Subnet)

프라이빗 서브넷은
인터넷에서 직접 접근할 수 없는 서브넷이다.

외부에서는 접근할 수 없고
VPC 내부 서버만 접근할 수 있다.

예를 들어 다음 서버들이 위치한다.

애플리케이션 서버
데이터베이스
내부 서비스 서버

예시 구조는 다음과 같다.

flowchart LR
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC"]
            subgraph PublicSubnet["Public Subnet"]
                Web["웹 서버"]
            end

            subgraph PrivateSubnet["Private Subnet"]
                App["애플리케이션 서버"]
                DB["데이터베이스"]
            end
        end
    end

    Internet -->|"인바운드 트래픽"| Web
    Web -->|"내부 호출"| App
    App -->|"쿼리"| DB

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style PrivateSubnet fill:#e3f2fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:4
    style Internet fill:#fff,stroke:#888,stroke-width:1px
    style Web fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style App fill:#e3f2fd,stroke:#1565c0,stroke-width:1px
    style DB fill:#fce4ec,stroke:#c62828,stroke-width:1px

이 구조에서는

사용자는 웹 서버에만 접근
내부 서버는 외부에서 직접 접근 불가

이렇게 되어
보안이 훨씬 강해진다.

4. 왜 퍼블릭과 프라이빗을 나눌까

이렇게 네트워크를 나누면
다음과 같은 장점이 있다.

보안 강화

데이터베이스 같은 서버는
외부에서 직접 접근할 필요가 없다.

그래서 프라이빗 서브넷에 배치한다.

네트워크 구조 명확화

서버 역할이 명확하게 나뉜다.

Public Subnet  → 웹 서버
Private Subnet → 애플리케이션 서버
Private Subnet → 데이터베이스

공격 범위 축소

외부에서 접근 가능한 서버가
최소화된다.

5. 실제 서비스에서의 구조

실제 AWS 환경에서는
다음과 같은 구조가 매우 일반적이다.

flowchart LR
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC  10.0.0.0/16"]

            subgraph PublicSubnet["Public Subnet"]
                Web1["웹 서버"]
                Web2["웹 서버"]
            end

            subgraph PrivateSubnet["Private Subnet"]
                App1["애플리케이션 서버"]
                App2["애플리케이션 서버"]
                DB[("데이터베이스")]
            end

        end
    end

    Internet -->|"인바운드 트래픽"| Web1
    Internet -->|"인바운드 트래픽"| Web2
    Web1 -->|"내부 호출"| App1
    Web2 -->|"내부 호출"| App2
    App1 -->|"쿼리"| DB
    App2 -->|"쿼리"| DB

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style PrivateSubnet fill:#e3f2fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:4
    style Internet fill:#fff,stroke:#888,stroke-width:1px
    style Web1 fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style Web2 fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style App1 fill:#e3f2fd,stroke:#1565c0,stroke-width:1px
    style App2 fill:#e3f2fd,stroke:#1565c0,stroke-width:1px
    style DB fill:#fce4ec,stroke:#c62828,stroke-width:1px

이 구조는 대부분의 웹 서비스에서
기본적으로 사용되는 아키텍처다.

6. 이 장의 핵심 정리

모든 서브넷이 인터넷과 연결될 필요는 없다.
인터넷과 연결된 서브넷을 퍼블릭 서브넷이라고 한다.
인터넷에서 직접 접근할 수 없는 서브넷을 프라이빗 서브넷이라고 한다.
보통 웹 서버는 퍼블릭 서브넷에 배치한다.
애플리케이션 서버와 데이터베이스는 프라이빗 서브넷에 배치한다.

19장. 인터넷 게이트웨이 (Internet Gateway)

이 장에서 말하고자 하는 것

앞 장에서 우리는 서브넷을 다음과 같이 나누는 구조를 살펴보았다.

퍼블릭 서브넷 (Public Subnet)
프라이빗 서브넷 (Private Subnet)

퍼블릭 서브넷에는
외부 사용자가 접근해야 하는 서버가 위치한다.

예를 들어

웹 서버
로드밸런서

같은 서버들이다.

그렇다면 여기서 한 가지 질문이 생긴다.

퍼블릭 서브넷에 있는 서버는
어떻게 인터넷과 연결될까?

이 연결을 담당하는 것이

인터넷 게이트웨이 (Internet Gateway)

이다.

1. VPC는 기본적으로 인터넷과 연결되어 있지 않다

AWS에서 VPC를 생성하면
그 네트워크는 기본적으로 인터넷과 연결되어 있지 않다.

즉 다음과 같은 상태다.

flowchart LR
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC"]
            Server["EC2 서버"]
        end
    end

    Internet x--x|"연결 없음"| VPC

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style Internet fill:#fff,stroke:#888,stroke-width:1px
    style Server fill:#fff8e1,stroke:#f9a825,stroke-width:1px

이 상태에서는

인터넷에서 서버에 접근할 수 없고
서버도 인터넷으로 나갈 수 없다.

즉 VPC는 기본적으로
외부와 분리된 네트워크다.

2. 인터넷 게이트웨이란 무엇인가

VPC를 하나의 회사 내부 네트워크라고 생각해보자.

회사 내부 네트워크도
외부 인터넷과 통신하려면
출입구가 필요하다.

AWS에서 이 역할을 하는 것이

인터넷 게이트웨이 (Internet Gateway)

이다.

인터넷 게이트웨이는

VPC와 인터넷을 연결하는 장치

라고 이해하면 된다.

3. 퍼블릭 서브넷과 인터넷 게이트웨이

퍼블릭 서브넷에는
인터넷과 통신해야 하는 서버가 위치한다.

예를 들어 웹 서버가 여기에 배치된다.

인터넷에서 들어오는 트래픽은
먼저 인터넷 게이트웨이를 통과한 뒤
VPC 내부 서버로 전달된다.

구조를 보면 다음과 같다.

flowchart LR
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC"]
            IGW["Internet\nGateway"]

            subgraph PublicSubnet["Public Subnet"]
                Web1["웹 서버"]
                Web2["웹 서버"]
            end
        end
    end

    Internet <-->|"트래픽"| IGW
    IGW --> Web1
    IGW --> Web2

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style Internet fill:#fff,stroke:#888,stroke-width:1px
    style IGW fill:#f3e5f5,stroke:#9c27b0,stroke-width:1px
    style Web1 fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style Web2 fill:#fff8e1,stroke:#f9a825,stroke-width:1px

이 구조에서 네트워크 흐름은 다음과 같다.

Internet
↓
Internet Gateway
↓
Public Subnet
↓
Web Server

즉 퍼블릭 서브넷의 서버들은
인터넷 게이트웨이를 통해
인터넷과 통신할 수 있다.

4. 하지만 이것만으로는 충분하지 않다

인터넷 게이트웨이를 연결했다고 해서
모든 서버가 자동으로 인터넷과 통신하는 것은 아니다.

왜냐하면 네트워크에는

트래픽이 어디로 이동할지 결정하는 규칙

이 필요하기 때문이다.

이 역할을 하는 것이

라우팅 테이블 (Route Table)

이다.

6. 이 장의 핵심 정리

VPC는 기본적으로 인터넷과 연결되어 있지 않다.
인터넷과 통신하려면 인터넷 게이트웨이가 필요하다.
인터넷 게이트웨이는 VPC와 인터넷을 연결하는 장치다.
퍼블릭 서브넷의 서버는 인터넷 게이트웨이를 통해 인터넷과 통신한다.
실제 네트워크 경로는 라우팅 테이블을 통해 결정된다.

20장. 라우팅 테이블 (Route Table)

이 장에서 말하고자 하는 것

앞 장에서 우리는
인터넷 게이트웨이 (Internet Gateway) 를 통해
VPC가 인터넷과 연결되는 구조를 살펴보았다.

하지만 여기서 한 가지 질문이 생긴다.

인터넷에서 들어온 트래픽은
어느 서버로 전달될까?

또는

서버가 인터넷으로 요청을 보내면
어디로 나가야 할까?

이처럼 네트워크에서는 항상
트래픽을 어디로 보낼지 결정하는 규칙이 필요하다.

이 역할을 하는 것이

라우팅 테이블 (Route Table)

이다.

1. 라우팅이란 무엇인가

네트워크에서 라우팅(Routing) 은

트래픽을 어디로 보낼지 결정하는 과정

을 의미한다.

예를 들어 서버가 외부 주소로 요청을 보내면

8.8.8.8

이 트래픽을

인터넷으로 보낼지
내부 네트워크로 보낼지

결정해야 한다.

이러한 규칙을 모아 놓은 것이
라우팅 테이블이다.

2. 라우팅 테이블의 구조

라우팅 테이블은 보통 다음과 같은 형태로 구성된다.

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	Internet Gateway

각 항목의 의미는 다음과 같다.

Destination

→ 목적지 네트워크

Target

→ 트래픽을 보낼 위치

즉 라우팅 테이블은

특정 주소로 가는 트래픽을 어디로 보낼지 정의한 규칙 목록

이다.

3. 라우팅 규칙의 두 가지 유형

라우팅 규칙은 크게 두 가지 역할을 한다.

① 내부 통신

다음 규칙을 보자.

Destination	Target
10.0.0.0/16	local

이 규칙의 의미는 다음과 같다.

VPC 내부 네트워크로 가는 트래픽은 VPC 내부로 전달한다

그래서

Web → App
App → DB

같은 내부 통신이 가능하다.

② 인터넷 통신

다음 규칙을 보자.

Destination	Target
0.0.0.0/0	Internet Gateway

이 규칙의 의미는 다음과 같다.

인터넷으로 가는 모든 트래픽은
Internet Gateway로 보낸다

그래서 서버가 외부 주소로 요청을 보내면
인터넷 게이트웨이를 통해 인터넷으로 나가게 된다.

4. 여러 규칙이 일치할 때

하나의 IP 주소가
여러 라우팅 규칙과 동시에 일치할 수도 있다.

예를 들어 다음 라우팅 테이블이 있다고 하자.

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	Internet Gateway

그리고 목적지가

10.0.0.20

이라면

10.0.0.0/16
0.0.0.0/0

두 규칙 모두와 일치한다.

이 경우 라우팅 테이블은

더 구체적인 네트워크 규칙을 선택한다

예를 들어

10.0.0.0/16

은

0.0.0.0/0

보다 더 좁은 범위의 네트워크다.

그래서 목적지가

10.0.0.20

이면

10.0.0.0/16 → local

규칙이 선택된다.

이 방식을 네트워크에서는

Longest Prefix Match

라고 부른다.

5. 서브넷과 라우팅 테이블

AWS에서는

서브넷이 라우팅 테이블을 사용한다

즉 어떤 서브넷이 어떤 라우팅 테이블을 사용하는지에 따라

인터넷 연결 여부

가 결정된다.

예를 들어 라우팅 테이블에 다음 규칙이 있으면

Destination	Target
0.0.0.0/0	Internet Gateway

그 서브넷은

인터넷과 연결된 서브넷

이 된다.

즉 이것이

퍼블릭 서브넷이다.

6. 프라이빗 서브넷

반대로 어떤 서브넷의 라우팅 테이블에

0.0.0.0/0 → Internet Gateway

규칙이 없다면

그 서브넷은

인터넷에서 직접 접근할 수 없는 네트워크

가 된다.

이것이 프라이빗 서브넷이다.

7. 이 장의 핵심 정리

라우팅은 트래픽을 어디로 보낼지 결정하는 과정이다.
라우팅 규칙을 모아 놓은 것이 라우팅 테이블이다.
라우팅 테이블은 Destination → Target 구조로 이루어진다.
하나의 주소가 여러 규칙과 일치하면 더 구체적인 규칙이 선택된다.
서브넷이 어떤 라우팅 테이블을 사용하는지에 따라 퍼블릭 / 프라이빗 서브넷이 결정된다.

21장. NAT Gateway

이 장에서 말하고자 하는 것

앞 장에서 우리는
라우팅 테이블(Route Table) 을 통해
트래픽이 어디로 이동하는지 결정된다는 것을 살펴보았다.

또한 다음과 같은 사실도 알게 되었다.

퍼블릭 서브넷 → 인터넷 게이트웨이로 연결 가능
프라이빗 서브넷 → 인터넷 게이트웨이로 직접 연결되지 않음

여기서 한 가지 질문이 생긴다.

프라이빗 서브넷의 서버는
인터넷으로 나갈 수 없을까?

예를 들어 서버가 다음 작업을 해야 할 수도 있다.

패키지 다운로드
외부 API 호출
OS 업데이트

이처럼 인터넷으로 나가는 통신이 필요한 경우가 있다.

이 문제를 해결하는 것이

NAT Gateway

이다.

1. 프라이빗 서브넷의 문제

프라이빗 서브넷의 서버는
인터넷에서 직접 접근할 수 없다.

예를 들어 다음과 같은 구조가 있다고 하자.

flowchart LR
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC"]
            subgraph PublicSubnet["Public Subnet"]
                Web["웹 서버"]
            end

            subgraph PrivateSubnet["Private Subnet"]
                App["애플리케이션 서버"]
                DB[("데이터베이스")]
            end
        end
    end

    Internet -->|"인바운드 트래픽"| Web
    Web -->|"내부 호출"| App
    App -->|"쿼리"| DB

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style PrivateSubnet fill:#e3f2fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:4
    style Internet fill:#fff,stroke:#888,stroke-width:1px
    style Web fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style App fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style DB fill:#fce4ec,stroke:#e91e63,stroke-width:1px

이 구조에서

App → Internet

같은 요청은
인터넷 게이트웨이를 직접 사용할 수 없다.

2. NAT란 무엇인가

NAT는

Network Address Translation

의 약자다.

간단히 말하면

내부 IP 주소를
외부 IP 주소로 변환하는 기술

이다.

예를 들어 다음과 같은 상황을 생각해보자.

App Server
10.0.2.10

이 서버가 인터넷으로 요청을 보내면
외부에서는 이 주소를 알 수 없다.

그래서 NAT는

10.0.2.10
→ 공인 IP

으로 변환하여
인터넷과 통신하게 만든다.

3. NAT Gateway의 역할

AWS에서는 이 NAT 기능을

NAT Gateway

가 수행한다.

NAT Gateway는 보통
퍼블릭 서브넷에 위치한다.

그리고 구조는 다음과 같다.

flowchart RL
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC"]
            IGW["Internet\nGateway"]

            subgraph PublicSubnet["Public Subnet"]
                NAT["NAT\nGateway"]
            end

            subgraph PrivateSubnet["Private Subnet"]
                App["애플리케이션 서버"]
            end
        end
    end

    App -->|"아웃바운드 요청"| NAT
    NAT -->|"외부 요청"| IGW
    IGW <-->|"트래픽"| Internet

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style PrivateSubnet fill:#e3f2fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:4
    style Internet fill:#fff,stroke:#888,stroke-width:1px
    style IGW fill:#f3e5f5,stroke:#9c27b0,stroke-width:1px
    style NAT fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style App fill:#fff8e1,stroke:#f9a825,stroke-width:1px

이 구조에서

Private Subnet → Internet

통신이 가능해진다.

4. 중요한 특징

NAT Gateway는 다음 특징을 가진다.

내부 → 외부 가능

프라이빗 서브넷의 서버는
인터넷으로 요청을 보낼 수 있다.

예

App → Internet

외부 → 내부 불가능

인터넷에서는
프라이빗 서브넷의 서버에
직접 접근할 수 없다.

즉

Internet → App

은 불가능하다.

5. 라우팅 테이블과 NAT Gateway

프라이빗 서브넷의 라우팅 테이블에는
보통 다음 규칙이 추가된다.

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	NAT Gateway

이 규칙의 의미는 다음과 같다.

인터넷으로 가는 트래픽은
NAT Gateway로 보낸다

그래서 프라이빗 서브넷의 서버는

App → NAT Gateway → Internet

경로로 인터넷과 통신하게 된다.

6. 전체 네트워크 구조 정리

지금까지 살펴본 AWS 네트워크 구조를
전체적으로 보면 다음과 같다.

flowchart LR
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC"]
            IGW["Internet\nGateway"]

            subgraph PublicSubnet["Public Subnet"]
                Web["EC2\n(Web Server)"]
                NAT["NAT\nGateway"]
            end

            subgraph PrivateSubnet["Private Subnet"]
                App["애플리케이션 서버"]
                DB[("데이터베이스")]
            end
        end
    end

    Internet <--> IGW
    IGW <--> Web
    IGW <--> NAT
    NAT <--> App
    Web --> App
    App --> DB

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:4
    style PrivateSubnet fill:#e3f2fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:4
    style Internet fill:#fff,stroke:#888,stroke-width:1px
    style IGW fill:#f3e5f5,stroke:#9c27b0,stroke-width:1px
    style Web fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style NAT fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style App fill:#fff8e1,stroke:#f9a825,stroke-width:1px
    style DB fill:#fce4ec,stroke:#e91e63,stroke-width:1px

이 구조에서

외부 사용자는 웹 서버에 접근
내부 서버는 인터넷으로 요청 가능
데이터베이스는 외부에서 접근 불가

가 된다.

7. 이 장의 핵심 정리

프라이빗 서브넷의 서버는 인터넷 게이트웨이를 직접 사용할 수 없다.
NAT는 내부 IP를 외부 IP로 변환하는 기술이다.
AWS에서는 NAT Gateway가 이 역할을 수행한다.
NAT Gateway는 보통 퍼블릭 서브넷에 위치한다.
프라이빗 서브넷은 0.0.0.0/0 → NAT Gateway 라우팅을 사용한다.
NAT Gateway를 통해 프라이빗 서브넷 → 인터넷 통신이 가능해진다.

22장. 보안 그룹 (Security Group)

이 장에서 말하고자 하는 것

앞 장에서 우리는
서버들이 서로 통신할 수 있는 구조를 만들었다.

이제 서버는 연결되어 있다.

하지만 여기서 중요한 문제가 하나 있다.

이 서버에 누가 접근할 수 있는가?

이걸 제어하는 것이

보안 그룹(Security Group)

이다.

1. EC2를 만들면 반드시 설정해야 하는 것

AWS에서 EC2를 생성할 때
반드시 설정해야 하는 것이 있다.

보안 그룹

서버는 생성되는 순간부터
외부 접근을 제어해야 하기 때문이다.

2. 보안 그룹은 무엇을 기준으로 동작할까

보안 그룹은 다음 3가지 기준으로 동작한다.

IP 또는 보안그룹 ID
포트
프로토콜

예시

IP: 0.0.0.0/0
포트: 80, 443
프로토콜: TCP

👉 의미

모든 IP에서 웹 서버 접근 허용

💡 참고 (중요)

보안 그룹은 IP뿐만 아니라

다른 보안 그룹을 허용 대상으로 설정할 수 있다

예

허용 대상: sg-web

👉 의미

웹 서버만 접근 가능

보통은 IP로 설정하기보다

보안 그룹 ID로 설정하는 것이 더 안전하다

이유:

IP는 변경될 수 있음
보안 그룹은 변경되지 않음

3. 기본 동작 방식

보안 그룹은 기본적으로

❌ 아무도 접근 못함 (기본 차단)

상태에서 시작한다.

그리고

✅ 필요한 것만 열어준다

이걸

화이트리스트 방식

이라고 한다.

4. 인바운드 / 아웃바운드

보안 그룹은 두 가지 방향을 가진다.

인바운드 (Inbound)

외부 → 서버로 들어오는 트래픽

아웃바운드 (Outbound)

서버 → 외부로 나가는 트래픽

5. 실제 보안 그룹 설정

이제 우리가 만든 구조에
보안 그룹을 적용해보자.

flowchart LR
    Internet["Internet"]
 
    subgraph Region["Region"]
        subgraph VPC["VPC"]
            IGW["Internet<br/>Gateway"]
 
            subgraph PublicSubnet["Public Subnet"]
                subgraph sgWeb["🔒 sg-web"]
                    Web["Web Server"]
                end
            end
 
            subgraph PrivateSubnet["Private Subnet"]
                subgraph sgApp["🔒 sg-app"]
                    App["App Server"]
                end
                subgraph sgDb["🔒 sg-db"]
                    DB[("Database")]
                end
            end
        end
    end
 
    Internet <-->|"HTTP / HTTPS"| IGW
    IGW <--> sgWeb
    sgWeb -->|"8080 허용"| sgApp
    sgApp -->|"3306 허용"| sgDb
 
    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px,color:#1a2a5e
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px,color:#1b5e20
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:5 4,color:#2e7d32
    style PrivateSubnet fill:#e3f2fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:5 4,color:#0d47a1
    style sgWeb fill:#fff3e0,stroke:#e65100,stroke-width:2px,stroke-dasharray:6 3,color:#bf360c
    style sgApp fill:#ede7f6,stroke:#4527a0,stroke-width:2px,stroke-dasharray:6 3,color:#311b92
    style sgDb fill:#fce4ec,stroke:#880e4f,stroke-width:2px,stroke-dasharray:6 3,color:#880e4f
    style Internet fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px,color:#424242
    style IGW fill:#f3e5f5,stroke:#9c27b0,stroke-width:1px,color:#4a148c
    style Web fill:#fffde7,stroke:#f9a825,stroke-width:1px,color:#795548
    style App fill:#e8f5e9,stroke:#43a047,stroke-width:1px,color:#1b5e20
    style DB fill:#fce4ec,stroke:#e91e63,stroke-width:1px,color:#880e4f

① 웹 서버 (sg-web)

웹 서버는 외부 사용자들이 접근해야 한다.

그래서 다음을 허용한다.

허용 대상: 0.0.0.0/0 (모든 IP)
포트: 80 (HTTP), 443 (HTTPS)
프로토콜: TCP

👉 의미

누구든지 웹 서버에 접속 가능

② 앱 서버 (sg-app)

앱 서버는 외부에서 접근하면 안 된다.

그래서 이렇게 설정한다.

허용 대상: sg-web (웹 서버)
포트: 8080
프로토콜: TCP

👉 의미

웹 서버만 앱 서버에 접근 가능

③ DB 서버 (sg-db)

DB는 가장 중요한 데이터가 있기 때문에
더 강하게 제한해야 한다.

허용 대상: sg-app (앱 서버)
포트: 3306 (MySQL)
프로토콜: TCP

👉 의미

앱 서버만 DB 접근 가능

6. 흐름으로 이해하기

이 설정을 적용하면

가능한 흐름

사용자 → 웹 서버 (80, 443)
웹 서버 → 앱 서버 (8080)
앱 서버 → DB (3306)

불가능한 흐름

인터넷 → 앱 서버 ❌
인터넷 → DB ❌
웹 서버 → DB ❌

7. 이 장의 핵심 정리

보안 그룹은 EC2 생성 시 반드시 설정해야 한다.
보안 그룹은 IP(또는 보안그룹), 포트, 프로토콜 기준으로 동작한다.
기본은 차단이며 허용만 가능하다.
IP 대신 보안 그룹을 허용 대상으로 설정할 수 있다.
보안 그룹을 사용하면 더 안전하고 관리가 쉽다.

💡 추가로 알아두기

지금까지는 EC2 기준으로 설명했지만

네트워크 통신이 필요한 AWS 리소스는
대부분 보안 그룹을 동일하게 사용한다

예를 들어

RDS (데이터베이스)
ElastiCache (Redis)
Load Balancer
일부 컨테이너 서비스 (ECS 등)

👉 이런 리소스들도 모두

누가(IP 또는 보안그룹)
어느 포트로 접근할 수 있는지

를 보안 그룹으로 제어한다.

보안 그룹은 EC2만의 기능이 아니라
AWS 네트워크 접근 제어의 기본 개념이다

23장. NACL (Network ACL)

이 장에서 말하고자 하는 것

앞 장에서 우리는 보안 그룹을 통해
서버 단위로 접근을 제어하는 방법을 배웠다.

이제 각 서버는
누가, 어떤 포트로 접근할 수 있는지 제어할 수 있다.

그런데 한 가지 더 생각해볼 수 있다.

서버 단위가 아니라
네트워크 자체를 한 번에 제어할 수는 없을까?

예를 들어 특정 IP나 대역을
서버마다 막는 것이 아니라
아예 네트워크 입구에서 막고 싶은 경우다.

이럴 때 사용하는 것이

NACL (Network ACL)

이다.

1. NACL이란 무엇인가

NACL은

서브넷 단위에서 동작하는 접근 제어 기능

이다.

보안 그룹이 서버 앞에서 동작한다면
NACL은

서브넷 입구에서 먼저 필터링

한다고 보면 된다.

2. 흐름으로 이해하기

트래픽이 서버까지 도달하는 과정은 다음과 같다.

Internet → NACL → 보안 그룹 → 서버

즉

NACL에서 먼저 검사
보안 그룹에서 한 번 더 검사

이렇게 두 단계로 제어된다.

3. 동작 방식

NACL은 보안 그룹과 다르게
규칙을 처리하는 방식이 있다.

✔ 번호 순서대로 검사

NACL은

낮은 번호부터 순서대로 규칙을 확인한다

예시

번호	설정
100	모든 트래픽 차단
200	80 포트 허용

이 경우 결과는 다음과 같다.

100번에서 이미 차단됨 → 80도 접근 불가

👉 핵심

먼저 매칭되는 규칙이 적용된다

4. 보안 그룹과의 차이

보안 그룹과 NACL은 비슷해 보이지만
동작 방식이 다르다.

구분	보안 그룹	NACL
적용 대상	EC2 (서버)	Subnet
규칙 방식	허용만 가능	허용 + 차단
상태	Stateful	Stateless

여기서 특히 중요한 것은 두 가지다.

허용 + 차단

보안 그룹은 허용만 설정하면 되지만 NACL은

허용과 차단을 모두 직접 설정할 수 있다

Stateless

보안 그룹은 응답 트래픽이 자동 허용되지만 NACL은

인바운드와 아웃바운드를 각각 따로 설정해야 한다

5. 어떻게 사용하는가

NACL은 보통
서브넷 단위에서 전체를 제어할 때 사용한다.

예를 들어

특정 IP 대역 차단
외부 공격 차단

이런 경우

네트워크 입구에서 한 번에 막는다

6. 구조로 이해하기

flowchart LR
    Internet["Internet"]

    subgraph Region["Region"]
        subgraph VPC["VPC"]
            IGW["Internet<br/>Gateway"]

            subgraph PublicNACL["🛡️ NACL (Public)"]
                subgraph PublicSubnet["Public Subnet"]
                    subgraph sgWeb["🔒 sg-web"]
                        Web["Web Server"]
                    end
                end
            end

            subgraph PrivateNACL["🛡️ NACL (Private)"]
                subgraph PrivateSubnet["Private Subnet"]
                    subgraph sgApp["🔒 sg-app"]
                        App["App Server"]
                    end
                    subgraph sgDb["🔒 sg-db"]
                        DB[("Database")]
                    end
                end
            end
        end
    end

    Internet <-->|"HTTP / HTTPS"| IGW
    IGW <--> sgWeb
    sgWeb -->|"8080 허용"| sgApp
    sgApp -->|"3306 허용"| sgDb

    style Region fill:#f0f4ff,stroke:#4a6fa5,stroke-width:2px,color:#1a2a5e
    style VPC fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px,color:#1b5e20
    style PublicNACL fill:#fff8e1,stroke:#c62828,stroke-width:2px,stroke-dasharray:8 4,color:#b71c1c
    style PrivateNACL fill:#fff8e1,stroke:#c62828,stroke-width:2px,stroke-dasharray:8 4,color:#b71c1c
    style PublicSubnet fill:#e8f5e9,stroke:#66bb6a,stroke-width:1px,stroke-dasharray:5 4,color:#2e7d32
    style PrivateSubnet fill:#e3f2fd,stroke:#64b5f6,stroke-width:1px,stroke-dasharray:5 4,color:#0d47a1
    style sgWeb fill:#fff3e0,stroke:#e65100,stroke-width:2px,stroke-dasharray:6 3,color:#bf360c
    style sgApp fill:#ede7f6,stroke:#4527a0,stroke-width:2px,stroke-dasharray:6 3,color:#311b92
    style sgDb fill:#fce4ec,stroke:#880e4f,stroke-width:2px,stroke-dasharray:6 3,color:#880e4f
    style Internet fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px,color:#424242
    style IGW fill:#f3e5f5,stroke:#9c27b0,stroke-width:1px,color:#4a148c
    style Web fill:#fffde7,stroke:#f9a825,stroke-width:1px,color:#795548
    style App fill:#e8f5e9,stroke:#43a047,stroke-width:1px,color:#1b5e20
    style DB fill:#fce4ec,stroke:#e91e63,stroke-width:1px,color:#880e4f

7. 정리하면서 이해하기

보안 그룹 → 서버 접근 제어
NACL → 네트워크 접근 제어

즉

보안 그룹은 “이 서버에 접근 가능?”
NACL은 “이 네트워크에 들어올 수 있음?”

8. 이 장의 핵심 정리

NACL은 서브넷 단위에서 동작하는 접근 제어 기능이다.
트래픽은 NACL → 보안 그룹 순서로 검사된다.
NACL은 규칙을 번호 순서대로 검사한다.
허용과 차단을 모두 설정할 수 있다.
Stateless 구조라서 인바운드/아웃바운드를 각각 설정해야 한다.

24장. 운영 환경을 위한 VPC 디자인

이 장에서 말하고자 하는 것

지금까지 우리는 VPC, 서브넷, 라우팅, NAT Gateway, 보안 그룹, NACL을 각각 배웠다.

이제는 이 요소들을 단순히 이해하는 것을 넘어서

운영 환경에서 어떻게 설계해야 하는지

를 이해해야 한다.

운영 환경에서는

장애가 발생해도 서비스가 유지되어야 하고
보안이 유지되어야 하며
확장에도 대응할 수 있어야 한다

1. 운영 환경을 머리로 그려보기

사용자가 서비스를 이용하는 흐름을 생각해보자.

사용자 → 웹 서버 → 애플리케이션 서버 → 데이터베이스

이 구조는 단순하지만
운영 환경에서는 그대로 사용할 수 없다.

여기에는 몇 가지 문제가 있다.

2. 가용성 문제

서버가 하나만 있으면

서버 장애 → 서비스 중단

이 된다.

그래서 서버를 여러 개로 늘리고
서로 다른 위치에 배치한다.

AWS에서는 이를 위해

가용 영역(AZ)

을 제공한다.

운영 환경에서는

최소 2개 이상의 AZ를 사용한다

이렇게 하면

한 AZ 장애 → 다른 AZ가 서비스 유지

가 가능해진다.

3. 네트워크 구조 설계

운영 환경에서는 네트워크를 다음과 같이 나눈다.

퍼블릭 서브넷 → 외부와 통신
프라이빗 서브넷 → 내부 전용

그리고 이 구조를

각 AZ마다 동일하게 구성한다

즉

AZ-A → Public + Private
AZ-B → Public + Private

형태로 만든다.

이렇게 해야

어느 AZ가 장애가 나도 동일한 구조로 서비스 유지가 가능하다

4. 보안 설계

모든 서버를 외부에 열어두면 위험하다.

그래서 역할에 따라 접근을 제한한다.

웹 서버 → 외부 접근 허용
앱 서버 → 웹 서버만 접근 가능
DB → 앱 서버만 접근 가능

또한 인터넷 통신이 필요 없는 자원은

프라이빗 서브넷에 배치한다

이렇게 하면

외부에서 직접 접근할 수 없는 구조가 된다

5. NAT Gateway의 역할

프라이빗 서버는 외부에서 접근하면 안 되지만
외부로 나가는 통신은 필요하다.

그래서 사용하는 것이

NAT Gateway

이다.

이 구조는 다음과 같이 동작한다.

프라이빗 → 인터넷 가능
인터넷 → 프라이빗 불가

6. 트래픽 처리 구조

사용자가 특정 서버에 직접 접근하면
서버 장애나 과부하에 취약하다.

그래서 중간에

Load Balancer

를 둔다.

사용자 → Load Balancer → 여러 웹 서버

이 구조는

트래픽 분산
장애 자동 대응

을 가능하게 한다.

7. IP 대역 설계

운영 환경에서는 VPC를 만들 때

충분히 큰 IP 대역을 확보해야 한다

예:

10.0.0.0/16

이유는 다음과 같다.

AZ 추가 가능성
서브넷 분리
서비스 확장

즉

처음부터 여유 있는 설계를 해야 한다

8. Custom VPC를 사용하는 이유

기본(Default) VPC를 사용할 수도 있지만
운영 환경에서는

Custom VPC를 사용하는 것이 일반적이다

이유는 다음과 같다.

원하는 구조로 설계 가능
IP 대역 충돌 방지
확장 고려 가능

9. 전체 설계 관점 정리

운영 환경 설계는 다음 기준으로 이루어진다.

1. 최소 2개 이상의 AZ 사용 (가용성)
2. 퍼블릭 / 프라이빗 분리 (보안)
3. NAT Gateway 활용 (내부 통신)
4. Load Balancer 사용 (트래픽 분산)
5. 충분한 IP 대역 확보 (확장성)
6. Custom VPC 사용 (유연성)

10. 이 장의 핵심 정리

운영 환경에서는 가용성, 보안, 확장성을 함께 고려해야 한다.
최소 2개 이상의 AZ로 구조를 구성해야 한다.
퍼블릭과 프라이빗 서브넷을 나누고 동일한 구조를 반복한다.
NAT Gateway와 Load Balancer를 통해 안정적인 구조를 만든다.
VPC는 충분한 IP 대역으로 설계해야 한다.
운영 환경에서는 Custom VPC 사용이 일반적이다.

25장. VPC Peering

이 장에서 말하고자 하는 것

VPC는 기본적으로 서로 격리된 네트워크다.

즉, 아무 설정도 하지 않으면

VPC A (10.0.0.0/16)
VPC B (192.168.0.0/16)

→ 서로 통신 불가

하지만 실제 환경에서는

서비스 간 통신
계정 간 연결
네트워크 분리 후 연동

이 필요하다.

그래서 가장 먼저 사용하는 방식이

VPC Peering

이다.

1. VPC Peering이란 무엇인가

VPC Peering은

두 개의 VPC를 직접 연결하는 기능

이다.

이 연결은 인터넷을 거치지 않고 AWS 내부 네트워크를 통해 통신한다.

2. 구조로 이해하기

flowchart LR
    VPC1["VPC A<br />10.0.0.0/16"]
    PCX["Peering Connection<br />pcx-123"]
    VPC2["VPC B<br />192.168.0.0/16"]

    VPC1 <--> PCX <--> VPC2

이 구조는 단순하다.

VPC A와 VPC B 사이에
Peering이라는 “전용 통로”가 하나 생긴다

3. 왜 사용하는가

인터넷을 통해 연결할 수도 있지만 그 방식은 문제가 많다.

VPC → Internet → VPC

이 경우

외부 네트워크를 거침
보안 취약
지연 발생

반면 VPC Peering은

VPC → AWS 내부망 → VPC

이기 때문에

빠르고
안전하고
안정적이다

4. 중요한 개념: 라우팅

여기서 가장 중요한 포인트가 있다.

Peering을 만들었다고 바로 통신되는 것이 아니다

왜냐하면

네트워크는 “어디로 보내야 할지” 알아야 하기 때문이다

라우팅 테이블 설정

VPC A

Destination        Target
10.0.0.0/16        local
192.168.0.0/16     pcx-123

VPC B

Destination        Target
192.168.0.0/16     local
10.0.0.0/16        pcx-123

의미

192.168.0.0/16 → Peering으로 보내라

즉

상대 VPC의 IP 대역을 Peering 연결로 전달

👉 핵심

Peering은 “통로”, 라우팅은 “방향 지정”

5. 동작 흐름

실제로 트래픽이 이동하는 흐름은 다음과 같다.

VPC A (10.0.0.10)
→ 라우팅 테이블 확인
→ 192.168.0.0/16 발견
→ pcx-123으로 전달
→ VPC B로 도착

즉

라우팅 테이블이 없으면 Peering이 있어도 통신 불가

6. 반드시 알아야 할 제약

VPC Peering은 간단하지만 중요한 제한이 있다.

1) CIDR 대역이 겹치면 안 된다

VPC A: 10.0.0.0/16
VPC B: 10.0.0.0/16 ❌

이 경우 AWS는 어디로 보내야 할지 구분할 수 없다.

2) 전이적 라우팅 불가

flowchart LR
    VPC1["10.0.0.0/16"]
    VPC2["192.168.0.0/16"]
    VPC3["172.31.0.0/16"]

    VPC1 <--> VPC2
    VPC2 <--> VPC3

이 구조에서

VPC1 → VPC3 ❌

이유

Peering은 직접 연결된 VPC끼리만 통신 가능

3) 연결 수 증가 문제

VPC가 많아지면

n(n-1)/2

만큼 연결 필요

예:

VPC 4개 → 6개 연결

👉 관리 복잡

7. 언제 사용하는가

VPC Peering은 다음 상황에서 적합하다.

VPC 2~3개 정도
단순한 구조
직접 통신 필요

예:

서비스 A ↔ 서비스 B
개발 ↔ 운영 환경
계정 간 간단 연결

8. 한 줄로 정리

VPC Peering은 두 VPC를 직접 연결하는 가장 간단한 방식이지만
규모가 커지면 한계가 있다

9. 이 장의 핵심 정리

VPC는 기본적으로 서로 통신할 수 없다
VPC Peering은 두 VPC를 직접 연결하는 기능이다
인터넷을 거치지 않고 AWS 내부망으로 통신한다
반드시 라우팅 테이블 설정이 필요하다
CIDR이 겹치면 사용할 수 없다
전이적 라우팅이 불가능하다
소규모 VPC 연결에 적합하다

26장. Transit Gateway

이 장에서 말하고자 하는 것

앞 장에서 우리는 VPC Peering을 통해
두 개의 VPC를 연결하는 방법을 배웠다.

Peering은 단순하고 빠르지만
VPC가 많아지면 문제가 발생한다.

연결 수가 급격히 증가하고
서로 직접 연결되지 않은 VPC는 통신할 수 없다

이 문제를 해결하기 위해 등장한 것이

Transit Gateway (TGW)

이다.

1. Transit Gateway란 무엇인가

Transit Gateway는

여러 네트워크를 하나의 중앙에서 연결하는 서비스

다.

쉽게 말하면

AWS에서 제공하는 중앙 라우터

라고 보면 된다.

2. 왜 필요한가

VPC Peering 구조를 다시 생각해보자.

flowchart LR
    VPC1["VPC A<br>10.0.0.0/16"]
    VPC2["VPC B<br>192.168.0.0/16"]
    VPC3["VPC C<br>172.31.0.0/16"]

    VPC1 <--> VPC2
    VPC2 <--> VPC3

이 구조에서 많은 사람들이 이렇게 생각한다.

VPC A → VPC C 가능할 것 같지만 ❌

이유는 단순하다.

중간 VPC를 통해 전달할 수 없기 때문이다

또한 VPC가 많아질수록 연결 수는 계속 증가한다.

n(n-1)/2

즉, Peering은 규모가 커질수록 관리가 어려워진다.

3. Transit Gateway 구조

이 문제를 해결하기 위해 구조를 바꾼다.

flowchart TB
    TGW["Transit Gateway"]

    VPC1["VPC A<br>10.0.0.0/16"]
    VPC2["VPC B<br>192.168.0.0/16"]
    VPC3["VPC C<br>172.31.0.0/16"]

    VPC1 --> TGW
    VPC2 --> TGW
    VPC3 --> TGW

이 구조의 핵심은

VPC → TGW → VPC

이다.

각 VPC가 서로 직접 연결되는 것이 아니라
모두 TGW라는 중앙 지점을 통해 연결된다.

4. 어떻게 동작하는가

Transit Gateway를 이해할 때 가장 중요한 것은 라우팅이다.

각 VPC는 목적지를 TGW로 보내고
TGW가 최종 목적지를 결정한다.

VPC A 라우팅 테이블

Destination        Target
192.168.0.0/16     tgw-123
172.31.0.0/16      tgw-123

Transit Gateway 라우팅

Destination        Target
10.0.0.0/16        VPC A
192.168.0.0/16     VPC B
172.31.0.0/16      VPC C

흐름

VPC A → TGW → VPC C

즉,

VPC는 TGW로 보내고, TGW가 목적지를 찾아준다

5. Peering과의 차이

구조 차이가 핵심이다.

Peering → VPC ↔ VPC 직접 연결
TGW → VPC → TGW → VPC

Peering은 단순한 연결이고
TGW는 실제로 라우팅을 수행하는 장비다.

6. 어떤 장점이 있는가

Transit Gateway를 사용하면 구조가 크게 바뀐다.

먼저, 전이적 라우팅이 가능해진다.

VPC A → TGW → VPC C 가능

그리고 연결 구조가 단순해진다.

VPC 10개 → TGW 하나만 연결

또한 모든 라우팅을 중앙에서 관리할 수 있다.

결과적으로 네트워크가 커질수록
오히려 관리가 쉬워진다.

7. 언제 사용하는가

Transit Gateway는 다음과 같은 상황에서 사용한다.

VPC가 여러 개
네트워크가 복잡함
중앙 관리가 필요함

예를 들어

서비스별 VPC 분리
계정 단위 분리
대규모 시스템

8. 한 줄로 정리

Transit Gateway는 여러 VPC를 하나로 묶는 중앙 라우터다

9. 이 장의 핵심 정리

VPC Peering은 규모가 커지면 한계가 있다
Transit Gateway는 중앙 허브 역할을 한다
모든 VPC는 TGW를 통해 연결된다
VPC는 목적지를 TGW로 보내고 TGW가 라우팅한다
전이적 라우팅이 가능하다
대규모 네트워크에 적합하다

27장. AWS Site-to-Site VPN

이 장에서 말하고자 하는 것

지금까지 우리는 AWS 내부에서 VPC 간 연결을 다뤘다.
하지만 실제 환경에서는 AWS만 사용하는 경우는 드물다.

회사 내부 데이터센터(IDC)나 기존 시스템과
AWS를 함께 사용하는 경우가 많다.

그래서 이런 요구가 생긴다.

회사 내부망 ↔ AWS VPC 연결

이걸 해결하는 가장 기본적인 방법이

AWS Site-to-Site VPN

이다.

1. VPN이란 무엇인가

VPN은

인터넷 위에 암호화된 통신 경로를 만들어
두 네트워크를 안전하게 연결하는 방식

이다.

즉, 물리적으로는 인터넷을 사용하지만
논리적으로는 내부망처럼 동작한다.

2. 구조로 이해하기

%%{init: {'flowchart': {'subGraphTitleMargin': {'top': 10, 'bottom': 20}}}}%%
flowchart LR
    subgraph OnPrem["On-prem Data Center<br/>(172.16.0.0/16)"]
        CGW["Customer Gateway<br/>(고객 라우터)"]
    end

    subgraph VPC["VPC (10.0.0.0/16)"]
        VGW["Virtual Private Gateway<br/>VGW-123"]
        RT["라우팅 테이블"]
    end

    CGW <==>|"IPSec 터널 (암호화)"| VGW

이 구조는 다음과 같이 이해하면 된다.

회사 네트워크에서 라우터를 통해 인터넷으로 나가고
그 트래픽이 AWS의 VPN 장비(VGW)에 도착한 뒤
VPC 내부로 전달된다.

3. 구성 요소

VPN 연결에서 중요한 구성은 두 가지다.

Customer Gateway는 회사 쪽 장비다.
실제 VPN 터널을 생성하는 라우터나 방화벽이 여기에 해당한다.

Virtual Private Gateway는 AWS 쪽 장비다.
VPC에 붙어 있는 VPN의 진입 지점이다.

즉, 이 둘이 연결되어 하나의 터널을 만든다.

회사 장비 ↔ AWS 장비

4. 어떻게 동작하는가

VPN 연결은 단순 연결이 아니라
암호화된 터널을 생성한다.

CGW → Internet → VGW

이 구간 전체가 IPSec으로 보호된다.

그래서 외부 인터넷을 지나가더라도
데이터는 안전하게 보호된다.

결과적으로

AWS를 회사 내부망처럼 사용할 수 있게 된다

5. 라우팅 구조

VPN에서도 핵심은 라우팅이다.

회사와 AWS 양쪽 모두
상대 네트워크를 VPN으로 보내도록 설정해야 한다.

VPC 쪽 라우팅은 다음과 같다.

Destination        Target
172.16.0.0/16      vgw-123

이 의미는

회사 네트워크로 가는 트래픽은 VPN으로 보내라

회사 쪽 라우팅은 다음과 같다.

Destination        Target
10.0.0.0/16        VPN 터널

이 의미는

AWS 네트워크는 VPN으로 보내라

그래서 실제 흐름은 이렇게 된다.

회사 서버 → 라우팅 확인 → VPN 터널 → AWS VPC

6. 왜 VPN을 사용하는가

단순히 인터넷으로 통신할 수도 있지만
VPN을 사용하는 이유는 명확하다.

인터넷 방식은 공용 IP 기반이라 외부에 노출되고
보안 측면에서 취약하다.

반면 VPN은 사설 IP 기반으로 통신하고
암호화가 적용되기 때문에 훨씬 안전하다.

즉

인터넷 → 공개된 통신
VPN → 내부망처럼 동작

7. 중요한 특징

AWS VPN은 기본적으로 두 개의 터널을 제공한다.

터널 2개 (Active / Standby)

하나의 터널에 문제가 생기면
자동으로 다른 터널을 사용한다.

그래서 기본적인 고가용성이 확보된다.

하지만 VPN은 인터넷 기반이기 때문에

지연 시간이 일정하지 않을 수 있고
대역폭에 한계가 있다

8. 언제 사용하는가

VPN은 다음과 같은 상황에서 적합하다.

빠르게 연결이 필요할 때
비용을 최소화해야 할 때
온프레미스와 기본 연결이 필요할 때

예를 들어

AWS 초기 도입
개발 환경 연결
백업 네트워크

9. 한 줄로 정리

Site-to-Site VPN은 인터넷 위에 암호화된 터널을 만들어
온프레미스와 AWS를 연결하는 방식이다

10. 이 장의 핵심 정리

온프레미스와 AWS를 연결해야 하는 상황이 존재한다
VPN은 인터넷 위에 암호화된 터널을 만드는 방식이다
Customer Gateway와 Virtual Private Gateway가 연결된다
라우팅을 통해 트래픽이 VPN으로 전달된다
사설 네트워크처럼 안전하게 통신할 수 있다
기본적으로 이중 터널로 고가용성을 제공한다
인터넷 기반이기 때문에 성능 제한이 존재한다

28장. AWS Direct Connect

이 장에서 말하고자 하는 것

앞 장에서 우리는 Site-to-Site VPN을 통해
온프레미스와 AWS를 연결하는 방법을 배웠다.

VPN은 빠르게 구축할 수 있고 편리하지만
인터넷을 기반으로 하기 때문에 성능과 안정성에 한계가 있다.

그래서 실제 운영 환경에서는 이런 요구가 생긴다.

인터넷을 거치지 않고 AWS와 안정적으로 연결하고 싶다

이 요구를 해결하는 방법이

AWS Direct Connect

이다.

1. Direct Connect란 무엇인가

Direct Connect는

AWS와 고객 네트워크를 전용 회선으로 연결하는 서비스

다.

VPN이 인터넷 위에 암호화된 터널을 만드는 방식이라면
Direct Connect는

AWS까지 이어지는 전용 네트워크 경로를 구성하는 방식

이다.

즉, 통신 경로 자체를 바꾼다.

2. 왜 Direct Connect가 필요한가

VPN에서는 트래픽이 반드시 인터넷을 지나간다.

회사 → 인터넷 → AWS

이 구조에서는

네트워크 품질이 인터넷 상태에 영향을 받고
지연 시간이 일정하지 않으며
대역폭에도 한계가 생긴다

Direct Connect는 이 구조를 다음과 같이 바꾼다.

회사 → 전용 회선 → AWS 네트워크

이 차이로 인해

더 안정적이고, 더 예측 가능한 네트워크를 만들 수 있다

3. 구조로 이해하기

flowchart LR
    subgraph CustomerDC["🏢 &nbsp;고객 데이터 센터&nbsp;"]
        direction TB
        PC["💻 💻 💻<br/>사용자 PC"]
        CR(["🔐 Customer Router"])
        PC --- CR
    end

    subgraph DXLocation["🏢 &nbsp;Direct Connect 로케이션 — Equinix DA1&nbsp;"]
        direction TB
        subgraph PCage["&nbsp;고객 / 파트너 케이지&nbsp;"]
            PR(["🔐 Customer or<br/>Partner Router"])
        end
        subgraph ACage["&nbsp;AWS 케이지&nbsp;"]
            DXE(["🔐 AWS Direct Connect<br/>Endpoint"])
        end
    end

    subgraph AWSCloud["☁️ &nbsp;AWS Cloud&nbsp;"]
        direction TB
        subgraph Region["&nbsp;서울 리전 (ap-northeast-2)&nbsp;"]
            direction TB
            subgraph VPCBox["&nbsp;VPC&nbsp;"]
                direction LR
                VGW["🔒<br/>VGW"]
                EC2["🖥️<br/>EC2"]
            end
            S3["🪣<br/>Amazon S3"]
            DDB["⚡<br/>DynamoDB"]
        end
    end

    CR ==>|"전용 회선"| PR
    PR ==> DXE
    DXE ==>|"🟢 Private VIF"| VGW
    DXE -->|"🔵 Public VIF"| S3
    DXE -->|"🔵 Public VIF"| DDB

    classDef customerStyle fill:#1a3a52,stroke:#4a9eff,stroke-width:2px,color:#fff
    classDef dxStyle fill:#2a1f4a,stroke:#a78bfa,stroke-width:2px,color:#fff
    classDef awsStyle fill:#1a3d2e,stroke:#00d084,stroke-width:2px,color:#fff
    classDef regionStyle fill:#0f2e1f,stroke:#4a9eff,stroke-width:1.5px,color:#fff,stroke-dasharray: 4 3
    classDef vpcStyle fill:#0a1f14,stroke:#00d084,stroke-width:1.5px,color:#fff
    classDef cageStyle fill:#1a1533,stroke:#a78bfa,stroke-width:1px,color:#fff,stroke-dasharray: 5 3
    classDef node fill:#2d4a6b,stroke:#4a9eff,stroke-width:1.5px,color:#fff
    classDef awsNode fill:#1e4a3a,stroke:#00d084,stroke-width:1.5px,color:#fff
    classDef router fill:#3d2a5c,stroke:#a78bfa,stroke-width:2px,color:#fff

    class CustomerDC customerStyle
    class DXLocation dxStyle
    class AWSCloud awsStyle
    class Region regionStyle
    class VPCBox vpcStyle
    class PCage,ACage cageStyle
    class PC node
    class CR,PR,DXE router
    class VGW,EC2,S3,DDB awsNode

    linkStyle 0 stroke:#4a9eff,stroke-width:2px
    linkStyle 1 stroke:#a78bfa,stroke-width:2.5px
    linkStyle 2 stroke:#a78bfa,stroke-width:2.5px
    linkStyle 3 stroke:#00d084,stroke-width:2.5px
    linkStyle 4 stroke:#4a9eff,stroke-width:2px,stroke-dasharray: 5 5
    linkStyle 5 stroke:#4a9eff,stroke-width:2px,stroke-dasharray: 5 5

4. 구조의 핵심 이해

이 구조에서 가장 중요한 것은
Direct Connect Location이다.

많이 헷갈리는 부분이 바로 여기다.

왜 AWS에 직접 연결하지 않고 중간 지점을 거칠까?

AWS는 리전 단위는 공개하지만
실제 내부 데이터센터의 물리 위치나
고객이 직접 연결할 수 있는 지점은 공개하지 않는다.

또한 모든 고객이 임의로 AWS 내부에 직접 연결하는 구조는
보안과 운영 측면에서 관리가 어렵다.

그래서 AWS는

공식적으로 연결 가능한 접속 지점(DX Location)

을 제공한다.

이걸 흐름으로 보면

회사 → DX Location → AWS 내부망 → VPC

이 된다.

즉

DX Location은 AWS 네트워크로 들어가는 공식 입구다

5. 어떻게 동작하는가

전체 흐름을 보면 단순하다.

회사 → 라우터 → 전용선 → DX Location → AWS → VPC

라우팅 방식은 VPN과 동일하다.

차이는 “경로”뿐이다.

VPC 라우팅

172.16.0.0/16 → VGW 또는 TGW

온프레미스 라우팅

10.0.0.0/16 → Direct Connect

즉

트래픽을 어디로 보낼지는 라우팅이 결정하고
Direct Connect는 그 경로를 전용선으로 제공한다

6. Virtual Interface (VIF)

Direct Connect에서는 하나의 물리 회선을
여러 네트워크로 나누어 사용할 수 있다.

이 개념이 VIF다.

예를 들어

Private VIF → VPC 연결
Public VIF → AWS 퍼블릭 서비스
Transit VIF → Transit Gateway 연결

즉

하나의 물리 연결 위에 여러 논리 네트워크를 구성할 수 있다

7. 언제 사용하는가

Direct Connect는 단순 연결보다는
다음과 같은 요구가 있을 때 사용한다.

대용량 데이터 전송
지연 시간 민감 서비스
안정적인 네트워크 필요

예를 들어

금융 시스템
대규모 데이터 처리
하이브리드 클라우드 환경

8. VPN과 함께 사용하는 이유

Direct Connect는 안정적이지만
물리 회선이기 때문에 장애 가능성이 존재한다.

그래서 실무에서는

기본 경로 → Direct Connect
백업 경로 → VPN

구조를 많이 사용한다.

즉

성능은 Direct Connect, 장애 대비는 VPN

9. 한 줄로 정리

Direct Connect는 AWS까지 이어지는 전용 네트워크 경로를 만드는 서비스다

10. 이 장의 핵심 정리

VPN은 인터넷 기반이라 성능 한계가 있다
Direct Connect는 전용 회선으로 AWS와 연결한다
Direct Connect Location을 통해 AWS 네트워크에 접속한다
라우팅 방식은 VPN과 동일하다
VIF를 통해 하나의 회선을 여러 용도로 사용할 수 있다
고성능과 안정성이 필요한 환경에서 사용된다
VPN과 함께 사용해 안정성을 확보한다

Keyboard shortcuts

AWS로 이해하는 클라우드 컴퓨팅 기초