VPC에 대해 알아봅시다!
AWS를 처음 시작하시면 주로 EC2 콘솔에서 인스턴스에 간단한 웹 앱을 올리는 것을 시도해봅니다. 가장 간단하기도 하고 뭔가 만들어지는 것을 직관적으로 빠른 시간안에 볼 수 있기 때문이죠. EC2에서 작은 성취감을 얻은 후에는 그것들이 어떻게 어떤 원리로 작동되는지 궁금하게 되실겁니다. 그러면서 학습에 흥미가 생기죠.
지난 업로드 이후 많은 시간이 지났습니다. 다들 한번씩 봐주셨을지요 >.< 직접 따라해보시지 않으셨더라도 대충 이렇게 흘러가는구나~ 정도는 다들 알게되셨으리라 생각됩니다. 그렇다면 그 EC2에서 직접 올린 인스턴스는 AWS의 네트워크 내부 어디에 배치가 되고 어떤 경로로 외부로 트래픽이 전달되게 되는지 설명을 드려볼까 합니다!
1. VPC란
AWS VPC(Virtual Private Cloud)는 말 그대로 AWS에서 제공하는 가상 사설 네트워크 서비스입니다. VPC는 사용자가 지정한 IP 주소 범위에서 인스턴스와 같은 사용자의 AWS 리소스를 배치할 수 있는 서브넷과 라우팅 테이블 등을 제공합니다. 가상 사설 망이기 때문에 내부는 모두 Private IP로 통신합니다.
2. 서브넷
2-1 서브넷과 AZ
클라우드 환경에서는 여러 on-premise site가 클러스터링 되지 않는 한, on-premise 환경보다 한 가지만 더 생각하면 간단합니다. 바로 AZ 인데요, 기존의 네트워크는 L2와 L3에서는 아키텍쳐만 보면 단순하게 서브넷 영역을 나눠주고 서로 다른 서브넷의 존재를 라우터에 입력해놓으면 통신이 되는데, 여기서도 마찬가지이지만 AZ 때문에 조금 더 고민을 해야합니다.
세가지 이유가 있는데요, 첫째로는 가용성 구성, 둘째로는 응답 속도 그리고 셋째로는 비용 때문입니다. 가용성을 위해서는 AZ를 분리하여 서브넷을 배치하는 것이 좋고, 응답 속도에 민감하다면 같은 AZ 내에 있는 것이 좋겠죠. 그리고 마지막으로 AWS는 데이터 센터 단위로 트래픽에 대해 요금을 과금하기 때문에 같은 AZ에 배치하는 것을 고민하게 됩니다. 즉, 같은 VPC 내에 있더라도 서로 다른 AZ 간의 통신이 있다면 트래픽 요금이 발생합니다.
서울 리전을 기준으로 AZ는 4개(5g를 통신을 위한 Wavelength Zone을 활성화 한다면 총 6개)가 있습니다. VPC 내부 서브넷 영역을 구성할 때 AZ를 하나만 사용할 수도 있고 4개 모두 사용할 수도 있습니다. 하나의 서브넷은 하나의 AZ에만 생성될 수 있습니다. 따라서 4개 AZ를 모두 사용하려면 최소한 서브넷이 4개는 필요하겠죠.
2-2 프라이빗 서브넷과 퍼블릭 서브넷
프라이빗과 퍼블릭의 차이는 외부에서 접근할 수 있느냐 입니다. 외부로 나갈 수 있느냐를 기준으로 한다면 프라이빗 서브넷에서도 *NAT 게이트웨이(Network Address Translation Gateway)를 통하면 나갈 수 있기 때문에 기준으로 하지 않습니다.
*NAT GW는 외부로 나가는 트래픽에 대해 해당 GW의 IP주소를 할당하여 보내는 것인데요, 퍼블릭 IP주소의 수가 모자라거나 실제 IP주소를 숨기기 위해서도 사용합니다. 외부에서는 NAT GW의 IP주소만 알 수 있기 때문에 실제 작업자의 서버의 정보를 알 수 없어 보안상 유리합니다.
- NAT Gateway가 동작하는 과정은 다음과 같습니다
①프라이빗 서브넷의 인스턴스가 외부 인터넷에 액세스하려고 할 때, 패킷이 NAT Gateway로 전달됩니다.
②NAT Gateway는 패킷의 소스 IP 주소를 변경하여 자신의 공인 IP 주소로 바꾸고, 고유한 소스 포트 번호를 할당합니다. 이 정보를 NAT Gateway의 변환 테이블에 기록합니다.
③NAT Gateway는 변경된 패킷을 인터넷으로 전송합니다.
④인터넷에서 응답이 돌아오면, NAT Gateway는 변환 테이블을 참조하여 원래의 내부 IP 주소와 포트 번호로 패킷의 정보를 변경합니다.
⑤NAT Gateway는 변경된 패킷을 원래의 인스턴스로 전달합니다.
NAT GW도 매우 중요한 기능이라 조금 길게 말씀드렸습니다😀
인스턴스가 외부와 통신하려면 기본적으로 3가지 조건을 충족해야 하는데요, 그것은 1 퍼블릭 IP주소를 갖고 있어야하고 2 인터넷 게이트웨이에 연결될 수 있어야 합니다. 마지막으로 3 보안 그룹 그리고 NACL(Network Access Control List)에서 포트와 IP주소가 개방되어 있어야 합니다. 따라서 종종 헷갈리시곤 합니다. 내 인스턴스는 퍼블릭 IP주소가 있는데 왜 통신이 안되냐! 하면 대체로 그 인스턴스가 있는 서브넷에 인터넷 게이트웨이로 연결되는 라우팅 설정이 안되어있거나 보안 그룹에서 해당 통신이 허용되고 있지 않기 때문입니다. 보안 그룹과 NACL은 잠시 후 알아보겠습니다.
3. 라우팅(라우트 테이블)
라우팅은 말 그대로 길을 잡는 것인데요, 여러 서브넷이 서로 통신을 하려면 각 서브넷이 서로의 주소 정보를 알아야겠죠. 그 주소를 관리하는 것이 라우트 테이블입니다. 라우팅 테이블은 아래 사진처럼 경로를 명시합니다. 0.0.0.0은 인터넷 게이트웨이를 향하고 있는데요, 이것은 외부로 트래픽이 전달될 수 있다는 것을 말하며 퍼블릭 서브넷을 위한 라우트 테이블이라는 것을 알 수 있습니다.

프라이빗 서브넷에 할당한 라우트 테이블은 아래 사진과 같습니다.

여기서는 0.0.0.0이 NAT GW로 전달되고 있습니다. 외부로 통신하기 위해 NAT GW를 거치도록 설정한 것이죠. 그리고 두 서브넷은 서로 다른 local 대역을 가지고 있는 것으로 알 수 있는 것은 서로 다른 VPC라는 것 입니다!
그럼 저 NAT GW는 어떻게 외부로 트래픽을 전달할까요? NAT 또한 퍼블릭 서브넷에 위치하며 해당 퍼블릭 서브넷이 바라보는 라우트 테이블에 연결된 IGW(Internet GateWay)로 트래픽을 전달합니다. 아래 사진을 참고해주세요.

NAT GW의 정보입니다.

NAT GW가 속한 서브넷의 라우트 테이블 정보입니다.
그러니까 IGW는 1개의 VPC에 하나만 존재하면 충분합니다. IGW는 NAT 역할을 하지 않으므로 해당 인스턴스 또는 NAT가 보유한 IP주소를 그대로 외부로 보냅니다.
4. 보안 그룹과 NACL
보안 그룹에 대해서는 한번 설명드린 바 있습니다만, 뒤로 가서 다시 보면 귀찮지요. 가장 큰 차이점부터 말씀드리면, 보안 그룹은 인스턴스에 대해 동작하고, NACL은 서브넷에 대해 동작합니다.
보안 그룹은 white list 방식(allow rule)으로 허용할 대역에 대해서만 지정합니다. 반면 NACL은 white list 방식과 black list(deny rule) 방식을 모두 사용할 수 있습니다.
그리고.. 제가 처음에 이해하기 어려웟던 stateful과 stateless에 대해 설명드리겠습니다.. stateful은 보안 그룹의 동작 방식이며 stateless는 NACL의 동작 방식입니다.
Stateful 방식은 특정 통신 세션의 상태를 추적하고 이를 기반으로 허용되거나 거부되는 패킷을 결정하는 방식을 말합니다.
예를 들어, A인스턴스에서 데이터베이스 서버로 TCP 포트 3306을 통해 데이터 요청이 발생할 경우 보안 그룹은 이 세션의 상태를 추적하게 됩니다. 추적된 상태에 따라, 데이터베이스 서버에서 A인스턴스로 응답 트래픽이 자동으로 허용됩니다.
Stateless의 경우 A인스턴스에서 데이터베이스 서버로 요청이 있으면 NACL의 아웃바운드 규칙에 따라 해당 트래픽을 허용하거나 거부합니다. 이 경우, TCP 포트 3306에 대한 아웃바운드 규칙이 허용되어 있어야 합니다.
데이터베이스 서버에서 A인스턴스로 응답이 갈 때에는 NACL의 인바운드 규칙에 따라 해당 트래픽을 허용하거나 거부합니다. 상태 비저장 방식이기 때문에 응답 트래픽에 대한 별도의 인바운드 규칙이 필요합니다. 이 경우, TCP 포트 3306에 대한 인바운드 규칙도 허용되어 있어야 합니다.
마지막으로 NACL은 룰의 적용 순서가 있고 보안 그룹은 없습니다. 보안 그룹은 동등하게 적용되나, NACL은 넘버링한 순서에 따라 적용됩니다. 기본값은 100번으로 0.0.0.0/0 Allow 되어 있고 *번으로 0.0.0.0/0 Deny되어 있습니다. 이 경우 100번이 우선하므로 모든 트래픽을 허용합니다.

위 사진처럼 설정되면 10.0.0.0/16 대역의 30000-32767 포트로 들어오는 트래픽은 Deny됩니다. 그 외의 트래픽은 100번 룰에 의해 모두 허용됩니다.
쓰다보니 또 너무 길어졌네요😅 어느정도 VPC의 기본적인 서브넷과 라우팅에 대해 이해가 되셨을까요? 언제나 말씀드리지만 이해가 잘 안되는 부분이 있다면 편히 댓글 남겨주세요!!
아직 VPC에 대해 못한 이야기들이 너무 많은데, 다음에도 VPC에 대해 계속해서 설명드리도록 하겠습니다!
'AWS' 카테고리의 다른 글
VPC Peering에 대해 알아봅시다 (2) | 2023.04.11 |
---|---|
AWS Solutions Architect Professional, SAP-C02 후기 (2) | 2023.04.03 |
[2-2] AWS에 간단한 어플리케이션을 올려봅시다 (0) | 2023.02.27 |
[2-1] AWS에 간단한 어플리케이션을 올려봅시다 (0) | 2023.02.26 |
[네전따] 칼럼 기고를 시작하며, [1] AWS를 시작할 때 필요한 기초 키워드 (2) | 2023.02.19 |