[AWS] VPC에 Subnet, NAT Gateway, Internet Gateway를 구성해보자
오늘은 다음과 같은 구조로 VPC를 구성해보려고 합니다.
Region 확인
먼저 Region이 Asia Pacific(Seoul)인지 잘 확인해줍니다.
언제 US East (N. Virginia)로 변할지 모르니 항상 어떤 자원을 생성하기 전에 먼저 체크합니다.
VPC 서비스 창으로 접속
VPC 서비스를 검색해서 접속합니다.
현재 저는 default로 생성해주는 VPC 하나만 있습니다.
VPC를 생성합니다
VPC 생성(Create VPC) 버튼을 눌러줍니다.
VPC 설정하기
VPC Settings은 다음과 같이 했습니다.
첫 번째로 VPC만 만들 것인지 VPC 말고도 다른 것을 한꺼번에 설정한 것인지 묻습니다. 귀찮기 때문에 여기서 다 설정해주도록 하겠습니다. VPC and more를 클릭해줍니다.
그리고 Name tag를 입력하면 알아서 이쁘게 새로 생성하는 자원들의 이름을 붙여줍니다. 만약 지키고 있는 컨벤션이 따로 있다면 Auto-generate를 비활성화하시고 우측의 구성도에서 이름을 수동으로 설정해주셔도 됩니다.
다음으로 IP가 몇개가 필요한지 묻습니다.
공식 문서에 따르면, 내가 IP가 필요한 만큼의 IPv4 CIDR을 수동 입력을 해야 합니다.
* 주의: AWS는 자체적으로 IP 몇 개를 Reserve합니다. 상황에 따라 2~4개 정도는 여유를 두고 서브넷을 만드세요!
아래 문서의 중간부터 읽어 보시면 CIDR 블록별로도 DNS용으로 Reserve도 한다고 나와있습니다.
CIDR 블록의 크기는 /16과 /28 사이여야 합니다. RFC-1918 규격에 따라 프라이빗 IP 주소 범위에 속하는 CIDR 블록을 지정하는 것을 권장합니다. (만약 임의로 Private IP를 할당하신다면 특정 사이트는 접속이 안 될 수도 있겠죠~)
표준 문서에 보다시피 클래스별로 Private Address Space가 지정되어있습니다.
- A 클래스로는 10.0.0.0/8
- B 클래스 용으로는 172.16.0.0/12
- B 클래스는 네트워크용으로 16개 비트를 쓰는데 위의 172.16.0.0/12는 4bit가 남습니다.
- 남는 4bit를 이용하면 16(2의 4승)개의 인접 B 클래스를 만들 수 있습니다.
- C 클래스로는 192.168.0.0/16
- C 클래스는 네트워크용으로 24개 비트를 쓰는데 위의 192.168.0.0/16는 8bit가 남습니다.
- 남는 8bit를 이용하면 192.168.0.0/16는 256(2의 8승)개의 인접 C 클래스를 만들 수 있습니다.
- 여담이지만 주로 Host가 몇 개 없는 가정집에서 192.168.0.0/16을 많이 씁니다.
- 보통 가정집은 한 방에 랜선이 하나가 들어갑니다.
- 각 방의 랜선마다 C클래스로 192.168.XXX.0/24(XXX은 0~255) 서브네팅을 하면 256개의 랜선을 쓰도록 구성할 수 있습니다.
저는 넉넉하게 대역은 10.0.0.0으로 했고 /16(65536개의 IP)이면 충분하고도 남아서 10.0.0.0/16으로 설정했습니다.
Tenancy는 기본으로 설정했습니다.
VPC and more 세부 설정하기
만약 VPC and more를 선택했다면 다음과 같이 자동 생성하는 자원들을 어떻게 몇 개를 생성해줄지 설정할 수 있는 메뉴가 뜰 겁니다.
VPC 생성과 함께 필요한 자원들을 어떻게 설정하냐에 따라 Subnet과 Routing Table과 Internet Gateway와 NAT Gateway의 구성이 바뀝니다.
저는 위에 캡처한 대로 설정했습니다.
- Availablility Zone(줄여서, AZ)은 이중화를 하기 위해 2개로 했습니다. (MultiAZ 구성)
- Public Subnet과 Private Subnet도 이중화하기 위해 2개씩 만들었습니다.
- 혹시 Private Subnet에서 인터넷 연결이 필요할 수도 있기 때문에 NAT를 설정했습니다.
가용성을 높이기 위해 AZ별로 1개를 만들었습니다. - VPC Endpoint도 필요없는 외부 트래픽으로 비용을 낭비하지 않기 위해 S3 Gateway용으로 VPC Endpoint를 설정했습니다.
참고로 여기서는 당연히 Internet Gateway를 하나를 만들어줬지만 수동으로 구성하다면 Internet Gateway는 이중화가 필요 없는지 의문이 들 수 있습니다. Internet Gateway는 알아서 수평 확장이되므로 이중화 구성이 필요 없습니다.
구성을 끝내시고 우측을 살펴보시면 아래와 같은 다이어그램이 나와있을겁니다.
일반적으로 사람들이 자주 쓰는 형태로 자동으로 완성해줬을 겁니다.
어떻게 구성해줬는지 모르니 그래도 확인은 해봐야겠죠. 상세하게 알아봅시다.
먼저 Internet Gateway는 Public Subnet들이랑 Public Routing Table로 엮여있는 것을 볼 수 있습니다.
잘 구성해준 것 같습니다ㅎㅎ
Public Routing Table로 두개의 Public Subnet으로 잘 구성되어 있습니다.
NAT Gateway 기준으로 연결된 Subnet과 Route table입니다.
그런데 저는 우측 그래프에서 모호했던게 있었습니다.
저는 NAT를 Private Subnet에 있는 애들이 외부와 통신할 수 있게 붙여주고 싶었는데 제 의도대로 AWS가 구성해줄지 헷갈리더군요.
보통 NAT Gateway는 Private Subnet에서 통신할 때 쓰기 위해서 만듭니다. 그래서 트래픽이 외부로 나갈 수 있어야 하기 때문에 Public Subnet에 만들어져야 하죠. 그리고 라우팅 규칙을 통해 Private Subnet에 있는 친구들이 쏘는 패킷을 NAT로 보내줘야 합니다.
저도 인터넷 통신을 위해 NAT를 붙여주려고 하기 때문에 NAT도 Internet Gateway를 통해 외부망으로 빠져나갈 수 있게 각각(AZ별로)의 Public Subnet에 생성되어 있어야 되는데 이 부분은 그래프로 확인하기 어려웠습니다.
그래프상에서 Private Subnet과 NAT가 연결되어 있는 것을 보면 Routing Rule은 Private Subnet 애들이 인터넷으로 쏜 패킷을 NAT로 보내도록 잘 설정해준 듯이 보입니다.
VPC를 생성하고 Private Routing Table 설정에서 Private Subnet 상에서 발생한 외부로 나가는 트래픽이 모두 Public에 붙은 NAT로 가도록 해줬는지 확인해봅시다.
마지막 Network connection은 Private Network에서 S3를 사용하기 위한 VPC Endpoint입니다.
아래 메뉴를 활성화시켜주었기 때문에 생겼습니다. 굳이 S3를 인터넷을 통해서 받아올 필요가 없습니다. 비효율적이고 VPC내에서 발생하는 트래픽은 대부분 무료이기 때문에 아래와 같은 설정을 해주면 편합니다. 아니면 S3 오브젝트 권한에 대한 Role을 만들어서 원하는 인스턴스에 지정해줘도 그 인스턴스와 S3간에 통신이 됩니다.
만약 S3를 Private 환경에서 사용할 일이 없어서 필요가 없다면 None을 선택하시면 됩니다.
VPC가 생성될 때까지 기다립니다
원하는 대로 설정을 하셨다면 이제 생성을 눌러봅시다.
기다립니다. 생성하는 것들이 많아서 좀 시간이 걸립니다.
최종 확인
우리가 원하는대로 네트워크 구성이 이루어졌는지 확인해봅시다.
1. NAT Gateway 확인
생성이 완료되었다면 View VPC를 누르고 왼쪽 메뉴에서 NAT gateways를 눌러서 위에서 의문이 들었던 NAT 구성이 잘 되었는지 확인해봅시다.
내가 원한 것 :: 1. NAT의 위치
- 저는 인터넷 통신이 되는 NAT를 원하므로 Public Subnet에 위치해 있어야 합니다.
- NAT도 Subnet에 위치한 장비라 이중화되길 원했습니다. 각각 AZ별로 다른 Public Subnet에 있어야 합니다.
일반적인 구성이라서 AWS가 잘해줬을 것 같지만 확인해봐야겠습니다.
과연 우리가 원한대로 구성되어 있을까요?
AZ별로 구성된 각각의 Public Subnet에 잘 생성되어 있습니다!
내가 원한 것 :: 2. Private Subnet의 Routing Table
- 목적지가 Private 대역(나는 10.0.0.0/16으로 설정했다)이면 인터넷이 아닌 내부(Local) 네트워크로 향해야 합니다.
- 10.0.0.0/16을 제외한 그 외의 목적지들은 NAT를 통해 Internet Gateway를 거쳐서 밖(외부 인터넷)으로 빠져나가야 합니다.
- 각 Subnet의 AZ별로 자신의 AZ에 위치해 있는 NAT를 통해 빠져나가야 합니다.
Private Subnet에 있는 인스턴스도 NAT를 통해 인터넷이 되도록 Route Table이 잘 구성되어 있을까요?
ap-northeast-2c Zone에 생성된 서브넷의 라우팅 테이블을 하나 확인해봅시다.
10.0.0.0/16에 해당하면 local로 가고 그 대역이 아닌 트래픽은 ap-northeast-2c Zone에 위치한 NAT로 가도록 Target이 잘 설정되어 있습니다.
2. Public Subnet의 Route Table 확인
Public Subnet에 위치한 친구들은 자신이 가진 IP로 통신이 되어야 합니다. 그러기 위해서는 AWS는 Internet Gateway를 제공해줍니다. Internet Gateway를 이용하면 자신이 가진 공인 IP로 외부와 통신할 수 있습니다.
그렇기 위해서 AWS는 Public Route Table을 하나 생성해줬습니다.
Public Route Table은 인터넷이 되도록 Internet Gateway를 Target으로 설정해뒀습니다.
Public Subnet은 이 Route Table을 사용하면 인터넷이됩니다. 반대로 Private은 Internet Gateway와의 접점을 피하고 싶으므로 절대로 달면 안 됩니다.
(무조건 NAT로 NAT의 IP로만 통신이 되도록해야 합니다. NAT를 통해 통신하면 외부에서 통신이 시작되는 경우는 차단되고 내부에서 시작해야지만 통신이 되기 때문에 보안적으로 더 안전합니다.)
Public Subnet 2개가 Public Route Table을 사용하고 있는지 확인해봅시다.
이것은 간단하게 Route Table에서도 확인이 가능합니다.
Public Route Table의 Subnet Association을 확인해봅시다. 그럼 어떤 Subnet들이 이 Route Table을 사용하고 있는지 나옵니다.
우리가 원하는 대로 Public Subnet이 잘 설정되어 있습니다.
끝!
썸네일 출처: Cloud server icons created by flatart_icons - Flaticon