AWS SAA 공부를 시작하고 첫날에는 Region, Availability Zone, VPC, Subnet을 중심으로 AWS 네트워크의 기본 구조를 살펴봤다.
온프레미스에서 오랫동안 네트워크와 서버를 운영해왔기 때문에 익숙하게 느껴지는 개념도 많았다.
하지만 AWS의 개념을 기존 인프라 지식과 연결하는 것만으로는 충분하지 않았다.
중요한 것은 각 구성요소가 어떤 역할을 하고, 실제 통신에서는 어떻게 연결되는지 이해하는 것이었다.
그래서 2일차에는 새로운 서비스를 많이 외우기보다는 첫날 배운 내용을 조금 더 구체적으로 살펴보기로 했다.
오늘 공부한 핵심은 다음과 같다.
- Route Table과 네트워크 경로
- Public Subnet과 Private Subnet의 차이
- Internet Gateway와 NAT Gateway의 역할
- Security Group과 NACL의 차이
- 여러 네트워크 구성요소가 함께 동작하는 방식
첫날이 AWS 네트워크의 전체 지도를 펼쳐본 날이었다면, 오늘은 그 지도에서 실제 통신 경로를 따라가 본 날이었다.
네트워크는 결국 패킷이 어디로 가는지 이해하는 것부터 시작한다
온프레미스 환경에서 네트워크 장애를 확인할 때 가장 먼저 살펴보는 것 중 하나가 라우팅이다.
IP 주소가 정상적으로 설정되어 있더라도 목적지로 향하는 경로가 없거나 잘못되어 있다면 통신이 되지 않을 수 있다.
AWS도 다르지 않았다.
AWS에서 Route Table은 목적지에 따라 트래픽을 어디로 전달할지 결정하는 역할을 한다.
예를 들어 다음과 같은 경로를 생각할 수 있다.
Destination Target
10.0.0.0/16 local
0.0.0.0/0 Internet Gateway여기서 10.0.0.0/16은 VPC 내부 통신에 사용되는 경로이고, 0.0.0.0/0은 다른 경로에 해당하지 않는 IPv4 트래픽을 의미하는 기본 경로다.
기본 경로의 Target이 Internet Gateway라면 해당 라우팅 테이블을 사용하는 Subnet은 인터넷 연결을 위한 경로를 갖게 된다.
물론 경로가 존재한다고 해서 모든 리소스가 자동으로 인터넷과 통신할 수 있는 것은 아니다. 실제 통신에는 IP 주소 설정과 보안 규칙 등 다른 조건도 맞아야 한다.
첫날에는 Route Table이 무엇인지 이해하는 데 집중했다면, 오늘은 라우팅 경로가 있다는 것과 실제 통신이 가능하다는 것은 구분해야 한다는 점을 다시 확인했다.
네트워크 엔지니어에게는 익숙한 원칙이지만 AWS에서도 그대로 중요한 기준이었다.
Public Subnet과 Private Subnet은 이름보다 라우팅을 봐야 했다
첫날 Public Subnet과 Private Subnet을 공부하면서 온프레미스의 DMZ와 내부 서버망을 떠올렸다.
인터넷에 노출되는 영역과 내부 애플리케이션 영역을 분리한다는 설계 관점에서 비슷한 부분이 있었기 때문이다.
다만 AWS에서는 Subnet의 성격을 판단할 때 라우팅 구성을 먼저 확인해야 한다.
일반적으로 Internet Gateway로 향하는 인터넷 경로가 있는 Subnet을 Public Subnet이라고 한다. 반대로 직접적인 Internet Gateway 경로가 없는 Subnet은 Private Subnet으로 구성할 수 있다.
여기서 주의할 점이 있다.
Public Subnet에 EC2를 배치했다고 해서 그 EC2가 자동으로 인터넷에 공개되는 것은 아니다.
인터넷에서 직접 통신하려면 적절한 IP 주소와 보안 설정 등 추가 조건이 필요하다.
이 부분을 생각하면서 AWS에서는 단순히 서버의 IP 주소만 보는 것이 아니라 다음 항목을 함께 확인해야 한다는 점을 정리했다.
- Subnet에 연결된 Route Table
- 목적지로 향하는 경로와 Target
- 리소스의 IP 주소 설정
- Security Group과 NACL의 규칙
결국 네트워크 통신은 하나의 설정만으로 결정되지 않는다. 여러 조건이 함께 맞아야 한다.
Internet Gateway와 NAT Gateway는 어떻게 다를까?
오늘 가장 집중해서 정리한 부분은 Internet Gateway와 NAT Gateway의 차이였다.
두 서비스 모두 인터넷 연결과 관련이 있지만, 역할을 같은 것으로 이해하면 안 된다.
Internet Gateway
Internet Gateway(IGW)는 VPC와 인터넷 사이의 통신을 가능하게 하는 구성요소다.
Public Subnet에서 인터넷으로 통신하려면 일반적으로 Route Table에 Internet Gateway를 향하는 경로가 필요하다.
인터넷에서 공개 웹 서비스를 이용할 수 있도록 구성하는 경우에도 IGW가 관련된다.
다만 IGW를 VPC에 연결하고 경로를 설정했다고 해서 모든 리소스가 자동으로 외부에 노출되는 것은 아니다. 리소스의 IP 주소와 보안 규칙을 함께 고려해야 한다.
NAT Gateway
NAT Gateway는 Private Subnet의 리소스가 자신의 Public IPv4 주소를 갖지 않은 상태에서 인터넷으로 나갈 수 있도록 구성할 때 사용한다.
예를 들어 Private Subnet의 EC2가 다음 작업을 수행한다고 생각해 보자.
- 운영체제 패키지 업데이트
- 외부 저장소에서 필요한 파일 다운로드
- 외부 API 호출
이러한 작업을 위해 인터넷으로 나갈 필요는 있지만, EC2 자체를 인터넷에서 직접 접근할 수 있도록 공개하고 싶지는 않을 수 있다.
이때 일반적인 IPv4 구성에서는 Public Subnet에 NAT Gateway를 배치하고, Private Subnet의 Route Table에서 인터넷으로 향하는 트래픽을 NAT Gateway로 전달하도록 설정할 수 있다.
구조를 단순하게 표현하면 다음과 같다.
Private Subnet
│
▼
EC2
│
▼
Route Table
│
▼
NAT Gateway
(Public Subnet)
│
▼
Internet Gateway
│
▼
Internet여기서 핵심은 NAT Gateway가 Private Subnet의 리소스가 인터넷으로 나가는 통신을 지원한다는 점이다.
인터넷 사용자가 NAT Gateway를 통해 Private EC2로 새로운 연결을 직접 시작하도록 만드는 용도는 아니다.
이 차이를 이해하고 나니 두 서비스의 역할을 조금 더 명확하게 구분할 수 있었다.
IGW는 VPC와 인터넷 사이의 연결을 담당하고, NAT Gateway는 Private Subnet 리소스의 아웃바운드 인터넷 통신을 지원한다.
첫날에는 NAT Gateway의 개념을 간단히 살펴봤다면, 오늘은 어떤 상황에서 필요한지까지 연결해서 이해할 수 있었다.
Security Group과 NACL은 둘 다 보안 기능이지만 동작 방식이 달랐다
보안과 방화벽을 다뤄온 경험이 있어서 Security Group과 NACL은 처음부터 관심이 가는 부분이었다.
둘 다 네트워크 트래픽을 제어하지만, 적용 범위와 동작 방식이 다르다.
| 구분 | Security Group | Network ACL |
|---|---|---|
| 적용 범위 | 리소스의 네트워크 인터페이스 수준 | Subnet 수준 |
| 상태 관리 | Stateful | Stateless |
| 규칙 | 허용 규칙 | 허용 및 거부 규칙 |
| 응답 트래픽 | 기존 연결의 응답을 자동으로 허용 | 응답 방향의 규칙도 확인 필요 |
가장 중요한 차이는 Stateful과 Stateless였다.
Security Group은 Stateful 방식으로 동작한다. 허용된 연결의 응답 트래픽은 별도의 반대 방향 허용 규칙을 추가하지 않아도 통과할 수 있다.
반면 NACL은 Stateless 방식이다. 요청 트래픽이 허용되더라도 응답 트래픽이 돌아오는 방향의 규칙도 확인해야 한다.
이 차이를 단순히 외우기보다 실제 웹 서비스 구성에 적용해 봤다.
웹 서비스에서는 보안 규칙을 어떻게 구성할까?
인터넷 사용자가 웹 서비스를 이용하고, 웹 서버가 데이터베이스에 접근하는 구조를 생각해 봤다.
Internet
│
▼
Public ALB
│
▼
Private EC2
│
▼
Private RDS이때 모든 리소스에 인터넷에서 접근할 수 있는 규칙을 설정할 필요는 없다.
예를 들어 다음과 같이 접근 범위를 나눌 수 있다.
1. ALB의 Security Group
인터넷 사용자가 HTTPS로 웹 서비스에 접근할 수 있도록 인바운드 443 포트를 허용한다.
2. EC2의 Security Group
인터넷 전체에서 직접 접근하도록 허용하는 대신, ALB의 Security Group을 출발지로 지정해 애플리케이션에 필요한 포트만 허용한다.
3. RDS의 Security Group
데이터베이스에 필요한 포트만 허용하고, 출발지는 애플리케이션 EC2의 Security Group으로 제한한다.
이렇게 구성하면 각 계층에서 필요한 통신만 허용할 수 있다.
온프레미스에서 방화벽 정책을 설계할 때도 출발지와 목적지, 서비스 포트를 기준으로 접근을 제한한다. AWS에서도 같은 보안 원칙이 중요했다.
다만 AWS에서는 Security Group을 다른 Security Group의 참조 대상으로 사용할 수 있다는 점이 유용했다. 서버의 IP 주소를 일일이 나열하는 대신 어떤 리소스 그룹에서 접근할 수 있는지를 기준으로 정책을 구성할 수 있기 때문이다.
그렇다고 Security Group만 이해하면 모든 보안 구성이 끝나는 것은 아니다. NACL이 별도로 적용되어 있다면 해당 규칙도 함께 확인해야 한다.
NACL은 언제 필요할까?
Security Group과 NACL을 비교하면서 처음에는 두 기능이 중복되는 것처럼 느껴졌다.
하지만 적용 범위와 규칙의 특성을 생각하면 차이를 이해할 수 있었다.
Security Group은 개별 리소스의 통신을 제어하는 데 사용하고, NACL은 Subnet 수준에서 트래픽을 제어하는 데 사용할 수 있다.
특히 NACL은 특정 IP 주소나 대역을 명시적으로 거부하는 규칙을 구성할 수 있다.
예를 들어 특정 IP 대역에서 들어오는 트래픽을 Subnet 수준에서 차단해야 한다면 NACL의 거부 규칙을 활용할 수 있다.
다만 NACL은 Stateless이기 때문에 요청과 응답 방향을 모두 고려해야 한다. 규칙 번호에 따른 평가 순서도 확인해야 한다.
시험에서는 단순히 둘 다 방화벽 역할을 한다는 점보다 다음 차이를 정확하게 구분하는 것이 중요하다고 느꼈다.
- 리소스 수준인가, Subnet 수준인가?
- Stateful인가, Stateless인가?
- 허용 규칙만 있는가, 거부 규칙도 지원하는가?
- 응답 트래픽을 별도로 고려해야 하는가?
이 기준으로 생각하면 문제에서 어떤 기능을 요구하는지 판단하기가 조금 더 쉬워진다.
배운 내용을 문제에 적용해 봤다
오늘은 VPC Networking의 핵심 개념을 정리한 뒤, 실제 시험에서 어떤 식으로 구분해야 하는지 확인하기 위해 6문제를 풀었다.
결과는 6문제 모두 정답이었다.
단순히 정답 개수만으로 모든 내용을 완벽하게 이해했다고 말할 수는 없지만, 적어도 기본적인 네트워크 구성과 보안 규칙의 차이를 구분하는 데는 문제가 없었다.
특히 다음과 같은 기준을 확인할 수 있었다.
- Public Subnet 여부는 Route Table의 인터넷 경로를 기준으로 판단한다.
- Private Subnet의 EC2가 Public IP 없이 인터넷으로 나가야 한다면 NAT Gateway를 고려한다.
- ALB를 통해 EC2에 접근하도록 구성할 때는 EC2의 Security Group에서 ALB의 Security Group을 출발지로 제한할 수 있다.
- 특정 IP 대역을 Subnet 수준에서 명시적으로 차단해야 한다면 NACL을 고려할 수 있다.
- Security Group은 Stateful이고 NACL은 Stateless라는 차이를 구분한다.
- 여러 AZ에 걸친 서비스 구성에서도 Subnet과 라우팅, 보안 설정을 함께 고려해야 한다.
이번에는 용어를 보고 답을 고르는 것보다 문제에서 요구하는 통신 방향과 보안 조건이 무엇인지 먼저 확인하는 것에 집중했다.
앞으로 문제 난도가 높아지면 단순한 개념 확인만으로는 부족하겠지만, 지금 단계에서는 이 기준을 확실히 잡는 것이 우선이라고 생각한다.
2일차 공부를 마치며
첫날에는 AWS 네트워크의 기본 구조를 살펴봤다.
Region과 AZ의 관계를 이해하고, VPC 안에 Subnet을 구성하며, Route Table과 보안 기능이 있다는 것을 정리했다.
오늘은 그 개념을 조금 더 구체적으로 연결해 봤다.
라우팅 테이블에 어떤 경로가 있어야 하는지, IGW와 NAT Gateway는 어떤 상황에서 사용하는지, Security Group과 NACL은 어떻게 다른지 살펴봤다.
공부하면서 다시 느낀 것은 온프레미스에서 쌓은 경험이 AWS를 이해하는 데 도움이 된다는 점이다.
하지만 기존 기술과 비슷하다는 이유만으로 같은 방식으로 생각해서는 안 된다.
AWS에서는 서비스별 역할과 적용 범위를 정확하게 이해하고, 여러 구성요소가 함께 동작하는 방식을 알아야 한다.
앞으로 SAA 문제를 풀 때도 서비스 이름만 기억하는 공부는 피하려고 한다.
대신 다음과 같이 생각해 보려고 한다.
어떤 통신이 필요한가?
현재 어떤 경로로 트래픽이 이동하는가?
접근을 허용하거나 차단하는 규칙은 어디에 적용되는가?
요구사항을 만족하면서 불필요한 노출을 줄이려면 어떻게 구성해야 하는가?
이런 질문을 통해 문제를 바라보는 연습을 계속할 생각이다.
오늘은 기본적인 VPC Networking 문제 6개를 모두 맞혔다. 기분 좋은 출발이지만, 아직은 기초 개념을 확인한 단계라는 점도 잊지 않으려고 한다.
다음 3일차에는 IAM과 AWS 보안의 기본 개념을 공부할 예정이다.
특히 IAM User, Group, Role의 차이와 EC2 IAM Role, IAM Policy, S3 Bucket Policy를 중심으로 살펴보려고 한다.
네트워크에서 트래픽이 어디로 이동하는지를 배웠다면, 이제는 누가 어떤 AWS 리소스에 접근할 수 있는지를 결정하는 방식을 이해해 볼 차례다.