AWS Certified Solutions Architect – Associate(SAA-C03) 공부를 시작한다고 글을 썼다.
13년 이상 온프레미스 인프라를 운영해왔기 때문에 AWS도 어느 정도는 알고 있다고 생각했다.
VPC도 들어봤고,
EC2도 알고 있고,
S3도 알고 있었다.
그런데 막상 SAA 공부를 시작하고 보니 조금 달랐다.
서비스 이름을 알고 있는 것과 AWS에서 인프라를 어떻게 설계하는지를 이해하는 것은 다른 문제였다.
그래서 첫날부터 새로운 AWS 서비스를 많이 외우는 대신 AWS의 기본 구조부터 다시 보기로 했다.
오늘 공부한 것은 아주 기본적인 내용이었다.
Region, Availability Zone, VPC, Subnet.
처음 보면 별것 아닌 것처럼 보이는 개념들이다.
그런데 이 네 가지를 이해하지 못하면 뒤에 나오는 네트워크와 고가용성 개념도 제대로 이해하기 어렵다는 생각이 들었다.
AWS의 가장 큰 단위는 Region이었다
먼저 Region부터 다시 봤다.
AWS에는 여러 Region이 있고, 각각 물리적으로 떨어진 지리적 영역에 존재한다.
서울도 있고,
도쿄도 있고,
미국의 여러 지역도 있다.
처음에는 그냥
“AWS 데이터센터가 지역별로 나뉘어 있는 것이구나.”
정도로 생각했다.
그런데 SAA에서는 Region이 단순한 위치 개념이 아니라는 것을 알게 됐다.
서로 다른 Region은 기본적으로 독립적인 환경으로 생각할 수 있다.
예를 들어 서울 Region과 도쿄 Region을 생각하면,
서울에서 문제가 발생했다고 해서 도쿄까지 자동으로 동일한 장애가 발생하는 구조는 아니다.
그러다 보니 자연스럽게 재해복구나 글로벌 서비스에서는 Region을 어떻게 사용할 것인지가 중요해진다는 것도 이해할 수 있었다.
물론 오늘은 DR까지 깊게 들어가지는 않았다.
아직 1일차니까.
Region 안에는 Availability Zone이 있었다
Region을 공부하면서 바로 이어서 나온 개념이 Availability Zone, 줄여서 AZ였다.
처음에는 단순히
“Region 안에 데이터센터가 여러 개 있는 것인가?”
라고 생각했다.
큰 틀에서는 그렇게 이해할 수 있지만 SAA에서는 조금 더 정확하게 봐야 했다.
AZ는 Region 안에서 서로 분리된 가용 영역이다.
예를 들어 하나의 Region에 여러 AZ가 존재할 수 있다.
Region
│
├── AZ-A
├── AZ-B
└── AZ-C여기서 중요한 것은 고가용성이었다.
만약 서버를 하나의 AZ에만 배치한다면 해당 AZ에 장애가 발생했을 때 서비스도 영향을 받을 수 있다.
반대로 여러 AZ에 서버를 분산하면 특정 AZ의 장애에 대한 대응력을 높일 수 있다.
이 부분은 온프레미스에서 생각하면 어렵지 않았다.
서버 두 대를 하나의 물리적인 장애 영역에 몰아넣는 것보다 서로 다른 장애 영역으로 분리하는 것이 안전하다는 것은 기존 인프라에서도 많이 경험했던 내용이다.
AWS에서는 그것을 AZ라는 개념으로 제공하고 있었다.
그렇다면 VPC는 무엇일까?
다음은 VPC였다.
Virtual Private Cloud.
처음 AWS를 접했을 때도 많이 들어봤던 용어다.
그런데 이번에는 단순히 정의를 외우기보다는 내가 알고 있는 네트워크와 연결해서 생각해봤다.
VPC는 AWS 안에서 사용하는 논리적인 네트워크 영역이라고 이해했다.
온프레미스에서 네트워크를 설계할 때도 먼저 IP 대역을 정하고 네트워크를 나누고 라우팅 구조를 만든다.
AWS에서도 비슷한 개념이 필요하다.
다만 구현 방식은 다르다.
VPC
│
├── Subnet
├── Subnet
└── Subnet이렇게 하나의 VPC 안에서 여러 Subnet을 구성할 수 있다.
이 부분에서 온프레미스 경험이 조금 도움이 됐다.
VLAN과 Subnet을 연결해서 생각해봤다
내가 가장 먼저 떠올린 것은 VLAN이었다.
온프레미스에서는 여러 VLAN을 나누고 각각 다른 IP 대역을 사용한다.
예를 들어,
VLAN 10 → 10.10.10.0/24
VLAN 20 → 10.10.20.0/24
VLAN 30 → 10.10.30.0/24처럼 네트워크를 분리한다.
AWS의 Subnet도 비슷하게 IP 주소 범위를 가지고 네트워크를 나누는 역할을 한다.
그래서 처음에는
VLAN ↔ Subnet
으로 연결해서 생각했다.
이렇게 생각하니 VPC와 Subnet의 관계가 훨씬 쉽게 이해됐다.
하지만 공부하면서 한 가지 주의해야 할 점도 알게 됐다.
Subnet과 VLAN이 완전히 같은 개념은 아니다.
온프레미스의 개념을 AWS에 그대로 대입하면 오히려 잘못 이해할 수 있다.
특히 AWS Subnet은 하나의 Availability Zone에 속한다는 점이 중요했다.
Subnet은 여러 AZ에 걸쳐 만들 수 없었다
이 부분은 SAA 문제에서도 중요하다고 했다.
예를 들어,
Region
│
├── AZ-A
│ └── Subnet-A
│
└── AZ-B
└── Subnet-B와 같은 구조다.
Subnet-A가 AZ-A와 AZ-B에 동시에 존재하는 것이 아니다.
각 Subnet은 하나의 AZ에 속한다.
처음에는 굳이 이런 것을 외워야 하나 싶었지만,
곰곰이 생각해보니 고가용성 아키텍처를 이해하려면 당연히 필요한 개념이었다.
여러 AZ에 서비스를 분산하려면 결국 각각의 AZ에 Subnet을 구성하고 리소스를 분산해야 하기 때문이다.
Public Subnet과 Private Subnet
오늘 공부하면서 가장 관심이 갔던 부분은 Public Subnet과 Private Subnet이었다.
온프레미스에서 DMZ와 내부 서버 네트워크를 분리해본 경험이 있기 때문에 이 개념은 비교적 쉽게 연결됐다.
대략 이런 느낌이다.
Internet
│
▼
Public 영역
│
▼
Private 영역AWS에서도 인터넷에 직접 연결되는 영역과 내부 애플리케이션을 위한 영역을 분리해서 설계할 수 있다.
예를 들어 웹 서비스라면,
Internet
│
▼
Public Subnet
│
ALB
│
▼
Private Subnet
│
EC2
│
▼
Private 영역
│
RDS와 같은 구조를 생각할 수 있다.
이런 구조는 내가 과거에 구성했던 DMZ와 내부 서버망을 떠올리게 했다.
물론 AWS의 Public/Private Subnet이 온프레미스의 DMZ와 완전히 같은 것은 아니다.
하지만 인터넷에 노출되는 영역과 내부 영역을 분리한다는 설계 관점에서는 상당히 익숙하게 느껴졌다.
그런데 Public Subnet이라는 이름만 보고 판단하면 안 됐다
여기서 하나 배운 것이 있었다.
Public Subnet이라고 해서 단순히
“여기에 있는 서버는 Public IP를 가지고 있다.”
라고 생각하면 안 된다는 것이다.
핵심은 Route Table이었다.
예를 들어 Route Table에
0.0.0.0/0 → Internet Gateway와 같은 경로가 존재하면 해당 Subnet을 Public Subnet으로 구성할 수 있다.
처음에는 Public/Private을 서버의 IP 주소로 판단하려고 했는데,
AWS에서는 라우팅 구조를 먼저 봐야 한다는 점이 인상적이었다.
결국 네트워크 엔지니어 입장에서는 익숙한 이야기였다.
어떤 네트워크가 어디로 연결되는지를 판단할 때는 결국 Routing을 봐야 하기 때문이다.
AWS에서도 Routing은 중요했다
이 부분에서는 오히려 마음이 편해졌다.
Route Table이라는 개념 자체는 새롭지 않았다.
온프레미스에서도 라우팅 테이블을 보면서 패킷이 어디로 가는지 확인한다.
AWS에서도 마찬가지였다.
Destination Target
10.0.0.0/16 local
0.0.0.0/0 Internet Gateway이런 식으로 목적지에 따라 어디로 보낼지를 정의한다.
그래서 AWS를 공부하면서 계속 느끼는 것이 있다.
완전히 새로운 것을 배우는 것 같지만,
막상 하나씩 뜯어보면 내가 알고 있던 인프라 개념과 연결되는 부분이 상당히 많다는 것이다.
오늘 가장 헷갈렸던 것은 NAT Gateway였다
그리고 오늘 공부하면서 하나 바로잡은 것도 있다.
처음에는 NAT를 알고 있었기 때문에 대략적인 개념은 이해하고 있다고 생각했다.
그런데 AWS에서 NAT Gateway가 어디에 사용되는지를 정확하게 구분해야 했다.
Private Subnet에 있는 서버가 인터넷에 접근해야 하는 경우가 있다.
예를 들어 서버가 외부 저장소에서 패키지를 다운로드하거나 외부 API를 호출해야 할 수 있다.
그렇다고 서버 자체를 Public Subnet에 배치하거나 Public IP를 부여하고 싶지는 않다.
이럴 때 NAT Gateway를 사용할 수 있다.
Private EC2
│
▼
NAT Gateway
│
▼
Internet Gateway
│
▼
Internet여기서 중요한 것은 방향이었다.
NAT Gateway는 Private Subnet의 리소스가 인터넷으로 나가는 데 사용한다.
인터넷 사용자가 NAT Gateway를 통해 Private EC2로 직접 들어오는 구조를 만드는 것이 아니다.
이 부분은 앞으로 VPC를 공부하면서 계속 확인해야 할 것 같다.
Security Group과 NACL도 다시 보게 됐다
보안 업무를 하고 있고 방화벽을 오랫동안 다뤘기 때문에 Security Group과 NACL도 흥미로웠다.
처음에는 둘 다 AWS의 방화벽 정도로 생각했다.
하지만 역할이 달랐다.
Security Group은 리소스 수준에서 접근을 제어하고 Stateful하게 동작한다.
반면 NACL은 Subnet 수준에서 동작하고 Stateless하다.
정리하면,
Security Group
→ 리소스 수준
→ Stateful
NACL
→ Subnet 수준
→ Stateless이다.
온프레미스 방화벽 경험이 있기 때문에 개념 자체가 아주 어렵지는 않았지만,
AWS에서는 보안 기능이 여러 구성요소로 나뉘어 있다는 점을 계속 의식해야 할 것 같다.
첫날부터 느낀 것은 ‘AWS를 새로 배우는 것’만은 아니라는 것
오늘 공부를 하면서 가장 재미있었던 것은 이것이었다.
AWS를 공부한다고 해서 내가 알고 있던 인프라 지식을 버려야 하는 것은 아니었다.
오히려 반대였다.
기존에 알고 있던 지식이 AWS를 이해하는 데 상당히 많은 도움을 줬다.
VLAN / Network
↓
VPC / Subnet
Routing
↓
Route Table
인터넷 연결
↓
Internet Gateway
NAT
↓
NAT Gateway
방화벽
↓
Security Group / NACL
물리적인 장애 영역 분리
↓
Availability Zone물론 각각이 완전히 같은 것은 아니다.
그래서 단순히
“이것과 저것이 같다.”
라고 외우는 것은 위험하다.
대신
“내가 알고 있는 개념과 어떤 부분이 비슷하고, AWS에서는 무엇이 다른가?”
이렇게 접근하는 것이 지금 나에게는 가장 잘 맞는 공부 방법인 것 같다.
1일차 공부를 마치며
SAA 공부 첫날이라 아직 배운 것은 많지 않다.
Region,
Availability Zone,
VPC,
Subnet,
Route Table,
Internet Gateway,
NAT Gateway,
Security Group,
NACL.
이 정도의 기본적인 구조를 살펴봤다.
하지만 처음부터 많은 AWS 서비스를 외우는 것보다는 이런 기본 구조를 먼저 이해하는 것이 맞다는 생각이 들었다.
특히 앞으로 SAA 문제를 풀 때 단순히
“이 서비스는 무엇이다.”
라고 답하는 것이 아니라,
“이 요구사항이라면 왜 이 서비스를 선택해야 하는가?”
를 생각하는 방식으로 공부하려고 한다.
13년 동안 온프레미스 환경에서 네트워크와 서버를 운영하면서 익혔던 경험이 AWS에서는 어떻게 다시 연결되는지 하나씩 확인해보려고 한다.
오늘은 AWS의 전체 지도를 처음 펼쳐본 날이었다.
아직 갈 길은 멀지만,
적어도 한 가지는 알 것 같다.
AWS가 완전히 새로운 세계는 아니었다.
내가 알고 있던 인프라를 다른 방식으로 설계하는 또 하나의 환경이었다.
이제 2일차에는 VPC Networking을 조금 더 깊게 들어가 보려고 한다.
특히 Public Subnet과 Private Subnet,
Internet Gateway와 NAT Gateway,
Security Group과 NACL의 차이를 좀 더 확실하게 이해하는 것이 다음 목표다.