AWS의 VPC에 대해서 알아보자

😲 VPC에 대해서 간단히 알아보겠습니다.

깊게 설명하고자 하면 한 없이 내용이 많아질 수 있어서 .. AWS를 시작하기 전 개요를 잡기 좋을 정도로만 VPC의 구조에 대해서 알아보도록 하겠습니다.

VPC를 이해하기에 앞서서 IP 주소에 대한 선행 지식은 꼭 숙지하시고 오시기를 권장합니다 !!
IP 주소에 대한 정리  (1편 : 🔗  2편: 🔗 )

📌 VPC(Virtual Private Cloud)란?

 VPC는 사용자의 AWS에서 사용하는 사용자 전용 가상의 네트워크입니다. 이름의 뜻 그대로 개인이 사용할 수 있는 가상의 클라우드입니다. 사용자는 자기가 원하는 대로 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워크 환경을 구성해 VPC를 생성할 수 있습니다.

 

사실, 뜻만 보고는 정확히 무슨 의미인지 파악하기 힘듭니다. 우선은 인스턴스를 담아두는 용기정도로 생각하시면 됩니다. 인스턴스는 EC2, S3, 그리고 RDS와 같은 것들을 의미합니다.

📌 VPC의 구성요소

• 최종적으로 이 모든 것을 숙지하면 됩니다... 하나하나씩 설명해 드리겠습니다.

✅ VPC와 서브넷

• IP 주소에 대해서 정리할 때 CIDR과 서브넷팅에 대해서 설명했습니다.

VPC에서도 사설 IP대역을 효과적으로 사용하기 위해서 서브넷팅을 합니다. 그 결과 만들어지는 것이 서브넷입니다.

위의 사진을 보게 되면 VPC는 10.0.0.0/16라는 CIDR을 사용하고 있고, 서브넷 두 개를 가지고 있습니다.

앞서서 CIDR에 대한 문서를 참고하셨다면 10.0.0.0/16 이 무엇을 의미하는지 알 수 있습니다!
앞의 옥텟 두 개는 네트워크 영역으로 분류하고 나머지 16개의 비트를 호스트 영역으로 사용하겠다는 뜻입니다.

서브넷은 /24 서브넷을 두 개를 만들었습니다. 10.0.1.0/24을 서브넷을 설정했다면,

8개의 비트를 호스트 영역으로 사용하겠다는 소리이고 이 서브넷 안에서 2^8=256 개의 IP를 부여할 수 있다는 말입니다.
물론 후에도 서브넷을 생성한다면 이 영역에 속하지 않게 크기는 다르게 만들 수 있습니다.

ex)
1. 10.0.1.0/24 (256개 IP)
2. 10.0.2.0/28 (16개 IP)
3. 10.0.2.16/28 (16개 IP)
4. 10.0.2.32/28 (16개 IP)
...

앗 그리고 참고로 원래는 서브넷에서 첫 번째 주소(IP Address)와 마지막 주소(브로드 캐스트 주소) 2개를 쓸 수 없었습니다.
하지만, AWS에서는 총 5개를 이용할 수 없습니다.

🚫 사용할 수 없는 IP 목록 (5개)
10.0.1.0 (첫 번째 주소) → 네트워크 주소 (서브넷 자체를 나타냄)
10.0.1.255 (마지막 주소) → 브로드캐스트 주소 (멀티캐스트에 사용)
10.0.1.1 (두 번째 주소) → VPC 라우터의 주소 (서브넷의 기본 게이트웨이)
10.0.1.2 (세 번째 주소) → AWS에서 예약된 DNS 서버
10.0.1.3 (네 번째 주소) → AWS에서 제공하는 추가 서비스 (예: VPC+DHCP 관련 서비스)

 

여기서 정말 중요한 사실은 subnet끼리 통신이 가능하다는 것입니다.

 

서브넷은 라우터와 라우팅 테이블을 통해서 서로 통신할 수 있도록 연결이 되어 있습니다. (라우터는 말 그대로 길을 찾아주는 연결 역할을 하고 Routing Table이라는 것을 보고 연결을 해줍니다.)

서브넷은 기본적으로 하나의 가용영역만을 가질 수 있으며 외부와 연결해주는 역할을 하는 IG(Internet Gateway)를 통해서 외부와 연결될 수 있습니다. 이렇게 외부와 연결할 수 있는 서브넷은 Public 서브넷이라고 부릅니다.

 

반면에 외부와 연결이 되어있지 않는 서브넷은 Private 서브넷이라고 부르게 됩니다. Private 서브넷은 외부와 연결되지 않지만, 서브넷끼리는 통신이 가능합니다. 예를 들어서 DB 같은 경우에는 외부와 통신할 필요가 없다고 생각된다면 Private 서브넷에 두면 좋겠죠?

 

여기까지 정리하면,

• VPC는 인스턴스를 담는 가상의 클라우드 (용기 같은 느낌)
• VPC의 내부를 효율적으로 사용하기 위해 서브넷으로 나누어 주었다(용기 내의 칸막이 같은 느낌).
• 서브넷은 라우터와 라우팅 테이블을 이용해 서로 통신이 가능하다
• Internet Gateway를 통해 외부와 연결이 가능한 서브넷은 Public 서브넷이다.

위와 같습니다. 실습해 보도록 하겠습니다. 

• AWS 검색창에 VPC를 검색해 주세요.

• 이미 VPC와 서브넷 등등 만들어져 있는 부분이 있습니다. 이는 AWS에서 기본적으로 생성해 주는 것들입니다.
• VPC 메뉴를 눌러주세요.

• VPC 생성을 눌러주세요.

• VPC만을 선택해 주세요
• 이름은 영어로만 띄어쓰기 대신 -(하이폰)을 사용해 주세요
• IP 대역은 10.0.0.0/16을 사용해 줍시다.
• 나머지는 그대로 두시면 됩니다.

• 다음으로는 Public과 Private 서브넷을 만들어보겠습니다.

• 서브넷 생성을 눌러주세요

• VPC는 아까 생성한 VPC를 선택해 주세요
• 서브넷 이름은 자유롭게... 
• VPC의 CIDR도 아까 생성한 VPC의 CIDR 블록을 사용해 주세요
• IPv4 서브넷 CIDR은 10.0.1.0/24로 해주세요
• 가용 영역은 하나만 선택할 수 있습니다.( 자유 )

• private 서브넷용으로 하나 더 만들도록 하겠습니다. 
• 이름은 private을 붙였고
• IPV4 서브넷 CIDR 블록을 10.0.2.0/24로 설정했습니다.
• 완료한 후 나가주세요!

• VPC에서 생성한 VPC를 클릭하고 플로우 로그를 눌러주세요.

• 자동적으로 라우팅 테이블이 하나 생성되어 있습니다. 클릭해주세요.

• 버튼 클릭 후 라우팅 테이블로 들어가 줍니다.

• 보시면 다음과 같이 되어 있습니다.

10.0.0.0/16 이건 저희 VPC의 CIDR이였습니다. 즉, 10.0.0.0/16으로 들어오는 모든 요청은 local로 보내준다는 뜻이고 이는 모든 서브넷끼리 서로 통신이 가능하다는 말입니다.

 

그런데 현재는 두 서브넷 모두 로컬로만 연결되는 하나의 라우팅 테이블에 연결이 되어있습니다. Public과 Private을 분리하기 위해 라우팅 테이블을 하나 더 만들어주고 Gateway에 연결하여 외부와 연결되게 설정하겠습니다.

• 좌측에 있는 메뉴바에서 라우팅테이블을 눌러서 라우팅 테이블 메뉴로 와줍니다.
• 오른쪽 위에 라우팅 테이블 생성을 눌러줍니다.

• 자유롭게 이름을 지어줍니다.
• 이전에 만들었던 VPC로 연결해 주고 생성해 주세요.

• 성공적으로 생성되었다면 local로 연결되는 라우트는 기본으로 생성됩니다.
• 다음으로 인터넷 게이트웨이를 만들고 외부로 연결해 주겠습니다.

• 인터넷 게이트웨이 생성을 눌러줍니다.

• 인터넷 게이트웨이는 이름만 만들어주면 됩니다!!

• 작업 > VPC에 연결을 누르고 기존에 만들었던 VPC에 연결해 줍니다.

• 다시 라우팅 테이블로 가줍니다.

• 뒤에 VPC를 보니 맨 아래 라우팅 테이블이 private VPC용인데 이름이 없으니 불편하네요. - 옆에 마우스를 가져다 대면 펜 모양이 뜨면서 이름을 설정해 줄 수 있습니다.
• pratice-private-route로 해주겠습니다.

• 다음으로 public 라우팅 테이블의 ID를 눌러서 들어가 주세요.

• 라우팅 편집을 눌러주세요.

• 다음과 같이 설정해 주고 아까 만들었던 gateway를 선택해 주세요.

• 외부로 연결할 수 있는 라우팅 테이블과 게이트웨이 설정이 완료되었습니다.

라우팅 테이블은 구체적인 조건을 우선적으로 연결해 줍니다. 여기서 구체적이라는 뜻은...

CIDR 뒤에 숫자가 큰 것을 의미합니다!!!

 

10.0.0.0/16은 우리가 만든 VPC의 CIDR로 사설 IP 범위입니다. 어떤 서브넷의 인스턴스가 다른 서브넷에 존재하는 인스턴스의 사설 IP주소로 접속을 하고자 하는 요청을 보낸다면 라우터는 local로 연결을 해줄 것입니다.

 

하지만, 만약 외부 공인IP로 연결을 요청하게 된다면 ( 당연히 사설 IP 범위에는 속하지 않고 10.0.0.0/16 범위 외의 IP겠죠?), 라우터는 외부로 연결되는 게이트웨이로 연결을 해준다는 뜻입니다!

 

서브넷끼리 접속 요청을 하게 된다면 우선적으로 구체적인 조건인 10.0.0.0/16에 부합하는지 점검을 한 후에 그 이외의 요청이라면 인터넷 게이트웨이로 연결시켜 준다는 뜻입니다.

• 계속해서 설정을 마무리하겠습니다. 서브넷 연결을 눌러주세요.

• 서브넷 연결 편집을 눌러주세요.

• Public 서브넷으로 만들고자 한 서브넷을 추가해 주세요.

• Private 라우팅 테이블에는 Private 서브넷을 추가해 주세요

• 다시 VPC로 돌아가주세요.

• practice vpc의 ID를 눌러서 들어가 줍니다.

• 사진이랑 똑같이 설정을 완료했습니다 ! 😄

✅ NACL, 보안그룹

💠 보안 그룹

보안그룹은 하나의 인스턴스의 방화벽 역할을 하며 들어오고 나갈 수 있는 포트를 설정할 수 있습니다.

들어오는 것을 제어하는 부분을 인 바운드(Inbound) 규칙, 나가는 것을 제어하는 부분을 아웃 바운드(Outbound) 규칙이라고 합니다.

 

• 하나의 인스턴스에 여러 개의 보안그룹을 적용할 수 있습니다.

다음과 같은 상황이라면, 인스턴스는 443 포트와 8080포트를 모두 사용할 수 있습니다.

 

• 보안그룹은 Stateful 하다

다음과 같은 상황을 생각해 봅시다.  클라이언트에서 요청을 보낼 때 목적지는 보통 80 포트와 같은 http로 사용되기로 약속된 잘 알려진 포트를 사용하는 반면에, 출발지는 여유가 남는 임시 포트를 사용하게 됩니다.

 

외부에서 들어온 요청은 인바운드 규칙에 따라서 검사를 받고 나갈 때는 아웃바운드 규칙을 따르지 않습니다.

내부에서 내보내는 요청은 아웃 바운드 규칙에 따라서 검사를 받고 들어올 때는 인바운드 규칙을 따르지 않습니다.

 

이처럼 보안 그룹은 요청에 대해서는 검사를 하고 응답에 대해서는 관여하지 않는 성질을 statefull 하다고 합니다.

 

• Deny는 불가능하다 

특정 IP의 요청에서 들어오는 것을 차단하지는 못합니다. 이 부분은 NACL에서 적용 가능합니다.

• 실습해 보겠습니다 메뉴에 VPC를 검색해 주세요.

• 보안 그룹을 눌러주세요.

• 오른쪽 상단에 보안 그룹 생성을 눌러주세요.

• 이름, 설명은 자유롭게 설정해 주시면 됩니다.
• VPC는 이전에 만들었던 VPC를 선택해 주세요.
• 아웃 바운드 규칙은 기본적으로 모든 트래픽을 허용하고 있습니다.

이 사진에서 설명한 것처럼 임시포트는 랜덤으로 지정되기 때문에 보통 아웃 바운드 규칙을 설정할 때에는 범위로 설정합니다. 지금은 생략하겠습니다.

• 인 바운드 규칙을 위와 같이 80포트를 열어주게 된다면 80포트로 접속할 수 있습니다. 현재는 80 포트로 모든 접속을 열어놓았지만, 소스를 설정하면 더 구체적인 범위로 설정할 수 있습니다.

💠 NACL(네트워크 ACL)

보안 그룹과 같이 서브넷 단위의 방화벽 역할을 합니다.

들어오는 것을 제어하는 부분을 인 바운드(Inbound) 규칙, 나가는 것을 제어하는 부분을 아웃 바운드(Outbound) 규칙이라고 합니다.

 

• 포트 및 IP를 직접 Deny 할 수 있습니다.

만약 112.12.35.4 IP를 차단하고자 한다고 생각해 보겠습니다.

 

다음과 같이 프로토콜, 포트 범위, 그리고 소스를 설정해서 서브넷으로 들어오고 나가는 요청과 응답에 대해서 허용할 것 인지 차단할 것인지 설정할 수 있습니다.

• 순서대로 규칙 평가 (낮은 순서부터)

NACL의 보안 규칙은 낮은 순서부터 적용이 됩니다. 따라서 위의 사진과 같이 적용을 시킨다면 100번 규칙이 먼저 적용이 되어서 결국 112.12.35.4 IP를 차단할 수 없게 됩니다. 따라서, 아래와 같이 설정해주어야 합니다.

이처럼 순서가 중요하기 때문에 AWS에서는 NACL 규칙을 설정할 경우 100 단위로 설정하는 것을 권장하고 있습니다. (중간에 순서를 바꿀일이 생길 수도 있기 때문...)

• Statefull 하다

보안 그룹에서는 요청에 대해서는 방화벽 검사를 하고 응답에 대해서는 관여하지 않았습니다. 하지만, NACL은 외부에서 들어온 요청이 인 바운드 규칙에 대해서 검사를 받고 다시 응답으로 나갈 때에도 아웃 바운드 규칙에 부합하는지 확인합니다. 이런 성질을 statefull 하다고 합니다.

• VPC 메뉴바의 왼쪽에서 설정할 수 있습니다. 크게 실습할 부분이 없어서 생략하겠습니다.

✅ Bation Host , NAT Gateway

Private Subnet은 외부와 연결되지 않으며 보통 RDS와 같은 데이터 베이스를 보관하여 보안을 높일 수 있습니다.

하지만, 이런 Private Subnet의 인스턴스들이 외부와 통신을 해야 하는 경우 사용하는 것들이 NAT Gateway와 BationHost입니다.

 

Private Subnet의 인스턴스가 외부로 요청을 보내고자 할 경우 NAT Gateway를 사용합니다.

반면에 , 외부에서 Private Subnet의 인스턴에 요청을 보내고자 할 경우 Bation Host를 사용합니다.

 

💠NAT Gateway/ NAT Instance

• NAT Instance는 인스턴스이고 NAT Gateway는 서비스입니다. NAT 게이트웨이가 나중에 나왔고 가격적으로 더 비싸기 때문에 NAT Instance를 사용하는 경우도 있습니다. 
• 서브넷 단위이며 외부와 통신이 되어야 하기 때문에 Public 서브넷에 위치해야 합니다.

💠 Bation Host

• 서브넷 단위이며 외부와 통신이 되어야 하기 때문에 Public 서브넷에 위치해야 합니다.
• 실전에서는 관리하기 어렵고 권한적인 문제가 많아 Session Manger를 사용하는 방법이 더 좋을 수 있습니다.

VPC의 기본과 개요만 설명하는 수준에서 NAT Gateway와 Bation Host의 실습은 생략하고 여기까지 설명하겠습니다! 😭 

 

Reference :

AWS 강의실 유튜브 🔗