[AWS] VPC를 생성할 때 고려할 점.

클라우드 사용하는 목적이 무엇이 됐건 VPC(Virtual Private Cloud)를 생성하는 것이 가장 기본이 아닌가 싶다. VPC를 만들고자 한다면 크게 다음 4가지를 거쳐야 한다. VPC라는 가상의 데이터센터를 생성하기 위해서는 내부적으로 사용할 수 있는 Private IP주소를 결정해야 하고, IP 대역을 작은 단위로 Subnet을 이용해 Boundary를 만들고, 인터넷과 연결될 수 있는 라우팅 테이블을 만들고, 길을 만들어 놨으면 목적에 맞게 방화벽 설정을 거쳐야 한다.

 

 

1. IP 주소 범위 선택 

2. 가용 영역(AZ) 별 서브넷 설정

3. 인터넷으로 향하는 경로(route) 만들기

4. VPC 로부터의 트래픽 설정

 

 

1. IP주소 범위 선택

VPC를 생성할 때 가장 먼저 고려해야 하는 사항이다. 그리고 AWS에서는 IP주소를 표현하는 방식을 흔히 CIDR라고 부른다. AWS는 Classless CIDR 방식을 사용한다. 잠깐 이것에 대해 짚고 넘어가자.

 

10 . 0 . 0 . 0 / 16

 

마스킹 값을 16으로 하는 네트워크 대역이다. Ipv4이며 총 32비트로 주소체계를 가지고 있고 끝에 있는 '/16' 은 앞에 있는 16bit는 언제나 고정이며 나머지 뒤에 있는 16bit는 변경이 가능하다 라는 뜻이다. (총 32bit) 즉, 2의 16승인 65,530개의 IP 주소를 가질 수 있는 네트워크 대역이다. VPC를 생성할 때도 CIDR 대역을 사용하지만 방화벽에도 사용된다.

 

10 . 0 . 0 . 0 / 16

0000 1010 . 0000 0000 . 0000 0000 . 0000 0000

 

 

Classless라고 했으니 마음대로 네트워크 대역을 생성해도 되겠지만 AWS에선 'RFC 1918'에 명시되어 있는 IP주소 대역을 사용할 것을 권장한다고 한다. 이유는 VPC는 외부와도 소통을 해야 하므로 IP주소가 겹치면 문제가 생길 수 있다. 예를 들면, 만약 AWS 사용하는 공인 IP주소와 Private IP 주소가 겹쳐 엉키게 되면, Client 요청이 외부로 나가지 않고 라우팅이 내부적으로 패킷을 계속 돌게 하는 돌아버리는 상황이 연출될 수 있다. 어쨌든 RFC는 내부적인 용도로 사용하는 Private IP주소는 다음 3가지 CIDR를 사용하자...라는 약속이자 IETF가 공포한 표준이라고 보면 된다.

 

10. 0 . 0 . 0  -   10 . 255. 255. 255 (10.0.0.0/8)
172. 16. 0. 0  -  172. 31. 255. 255 (172.16.0.0/12)
192. 168. 0. 0  -  192. 168. 255. 255 (192.168.0.0/16)

 

 

그리고 가능하면 특별한 이유가 없다면 VPC CIDR은 /16과 같이 넉넉한 마스킹 값을 이용하자. 한번 생성하면 더 늘리거나 줄일 수 없기 때문이다. 하지만 더 붙일 수는 있다. 듣기로는 GCP는 생성 후 대역 수정이 가능하다고 한다. 여하튼 VPC 생성은 다음과 같다.

 

콘솔 환경 접속... 서비스 검색... 'VPC' ... 화면 우측 상단 'Create VPC' 클릭

 

일반적으로 VPC 이름과 CIDR 대역을 입력하고 생성하기만하면 끝이다.

 

2. 가용 영역(AZ) 별 서브넷 설정

큰 네트워크 대역을 선정했다면 이제 그것을 Subnet으로 쪼개 주면 된다. VPC는 리전 단위로 만든다면 Subnet은 AZ안에 각각 만들어야 한다. 그리고 각각에 Subnet은 VPC CIDR 대역 내에서 원하는 대로 쪼갤 수 있다. Subnetting이다. 여기서 알아야 할 것이 하나가 더 있다. 원하는 마스킹 값을 넣어 IP주소를 쪼갰다고 해도 내가 사용할 수 있는 IP주소 개수는 본래보다 더 적다. 이게 무슨 말일까.

 

예를 들어 마스킹 값 24의 서브넷을 만들었다 치자. (ex. 10.0.1.0/24) 그렇다면 내가 사용할 수 있는 IP개수는 256개 되어야 하지만 실제로는 251개다. 이유는 IP주소 앞 4개와 마지막 1개는 AWS가 관리의 목적으로 사용하기 때문이다. 정확히 말하자면 맨 앞과 뒤는 네트워크를 나타내는 IP주소와 브로드캐스팅 IP주소이며 나머지 앞 3개를 관리의 목적으로 사용된다. 즉, 다음과 같다.

 

10.0.1.0/24의 Subnet에서 내가 사용할 수 있는 IP 주소는
10.0.1.4~254이다. 

 

여담으로 필자의 경험을 이야기해보자면 VPC와 Subnet을 만들 때 CIDR 대역이 크다고 방심하면 안 된다. 회사 프로젝트로 AWS 클라우드를 생성하는데 DX연동 등을 고려하고, 운영/개발/검증계를 분리하고, 거기에 가용성을 생각해 AZ를 둘로 사용할 수 있는 IP주소 대역이 반으로 갈라지는 상황이었다. "서버 하나당 IP주소 한 개를 담당하니 그래도 넉넉하지 않은가??"라고 생각할 수 있겠지만 생각보다 서버 서비스 이외에도 IP주소를 잡는다.

 

예를 들면 ELB다. 높은 트래픽이 예상되어 ELB를 추가해야 하는 상황이다 ELB는 부하 상황에 따라 Scale-Out 되는 녀석이다. 우리 눈에는 보이지 않지만 이 녀석도 IP주소를 잡아먹는 서버나 마찬가지다. 높은 트래픽을 감당하려면 내부적으로 Scale-Out이 되어야 하는데 그럴 IP주소가 있느냐도 고려를 해야 한다. 이야기가 도중으로 샜지만 참고 정도만 해주자. 

 

콘솔 환경 접속... 서비스 검색... 'VPC'... Subnets ... 화면 우측 상단 'Create subnet' 클릭

원하는 VPC 선택

Subnet 이름과 가용 영역(AZ) 그리고 CIDR를 생성

여담으로 한국 리전의 경우, 비교적 최근에 증설된 b, d존은 특별한 이유가 없다면 당분간 사용을 피하는 것이 좋다. 이유는 비교적 최근에 나온 AZ이며 Instance Type 풀도 다른 AZ에 비해 적고 약간의 제약사항이 있다. 실제로 b존을 이용하는 EC2 인스턴스에 이유도 없이 레이턴시가 증가하는 사건이 있었는데 결국 AZ를 많이 사용하는 a, c로 옮겨 상황을 해결했다. AWS는 다른 계정(사용자)에게 영향을 미치지 않도록 계정당 사용할 수 있는 사용량에 쓰로틀링을 걸어 둔다고 하는데 이런 문제가 원인이 아닐까 지금도 추측 중에 있다. 요약하자면 검증되고 출시된 지 오래된 AZ를 고르도록 하자.

 

 

3. 인터넷으로 향하는 경로(route) 만들기

VPC에 Subnet으로 CIDR을 나눴다. 보안을 포함해 용도가 있으니 나누지 않았겠는가? 그리고 이들에게 서로 역할에 맞는 통신을 위해서 등록해줘야겠다. route talbe 먼저 생성부터 해보자. 아래 예제는 Public Subnet을 만들어 IGW을 route talbe에 등록해 인터넷 통신이 되게끔 하려는 작업이다.

 

i) IGW 생성

subnet의 route talbe 등록 전, 인터넷 게이트웨이를 먼저 생성해준다. 그래야 route table에 등록을 할 수 있으니

 

콘솔 환경 접속... 서비스 검색... 'VPC'... Internet Gateway... 화면 우측 상단 'Create internet gateway' 클릭

생성이 완료되면 해당 IGW의 'Acation'... 'Attach to VPC'... 원하는 VPC 클릭하여 IGW를 VPC 붙여주자

 

ii) Subnet의 route table 등록하기

콘솔 환경 접속... 서비스 검색... 'VPC'... Route tables... 화면 우측 상단 'Create troute table' 클릭

route talbe 이름 입력 및 연결할 VPC 선택

아까 생성한 IGW ID를 참조한다... 생성이 완료되면 해당 Subnet 클릭... Routes... Edit routes 클릭하여 라우팅 등록

Subnet의 Routes를 보면 'Destination'과 'Target'이 있다. 먼저 10.0.0.0/16의 Destination에 Target의 local은 외부로 패킷을 보내지 말고 내 VPC내로 라우팅을 하겠다 라는 뜻이다. 이는 기본적인 라우팅 테이블이면 자기가 속해있는 VPC CIDR 10.0.0.0/16에 있는 모든 리소스와 통신하겠다는 의미다. 0.0.0.0/0은 anywhere를 의미한다. 즉, 10.0.0.0/16 대역이 아닌 다른 네트워크 대역에 패킷을 보내면 igw-0a1987a8ff2c2710f(IGW)로 보내어 인터넷 통신을 하라라는 뜻이다.

 

Private Subnet은 NAT Gateway를 추가 구성하여, Private subnet의 Rotes에 Destination 0.0.0.0/0에 Target을 NAT Gateway로 잡으면 된다. 

 

 

4. VPC 로부터의 트래픽 설정

AWS는 기본적으로 모든 것을 Deny를 하는 정책을 가지고 있다. AWS 방화벽 기능에는 크게 두 가지가 있다. Network ACls (stateless firewalls), Security Groups(stateful firewalls)가 되겠다.

 

i) NACL (stateless firewalls)

 - NACL은 서브넷 단위로 적용 (서브넷 안에 EC가 100개 있으면 모두 해당 NACL의 영향을 받는다)

 - NACL은 여러 Subnet에 적용 가능하며 Subnet은 하나의 NACL만 적용

 - VPC 하나당 최대 200개까지 생성 가능

 - NACL은 Ibound Rule 20개, Outbound Rule 20개 등록 가능

 - Stateless 성질로 요청 정보를 저장하지 않으므로 응답 트래픽 제어 설정을 해야 함. 즉, Client의 요청을 허용했다면 Response 하는 것 또한 허용해야 한다. 하지만 정확히 정해진 포트를 집을 수 없다. 이유는 서버는 흔히들 알려져 있는 포트(80, 443 etc...)를 사용하지만 Client OS에서 사용하는 포트 범위는 굉장히 다양하며 OS마다 또 다르다. 일반적으로 1024번 이하의 포트는 well-known 포트라고 서비스 데몬이 사용하는 포트고 1025~65536 포트를 Client가 사용하기 때문이다.

 

ii) Security Group (stateful firewalls)

 - EC2 인스턴스 단위로 적용

 - 하나의 EC2 인스턴스에 여러 개의 SG 등록 가능

 - VPC 하나당 최대 2500개의 SG 생성 가능

 - SG는 Inboud Rule 60개, Outbound Rule 60개 등록 가능

 - Stateful 성질로 요청 정보를 저장하므로 응답 트래픽 제어 설정이 필요하지 않음. 즉, Client의 요청을 SG는 기억을 하며 Client에게 Response를 보낼 때, 들어올 때는 허용됐기 때문에 나가는 것도 허용한다는 의미다. 

 

iii) 정리 

 - 같은 Subnet에 있으면 SG 만으로 통신

 - 다른 Subnet에 있으면 NACL을 먼저 거친 후, SG으로 통신

 - 현업에선 일반적으로 Security Group 하나만 사용한다. 하지만 추가적인 보안을 원한다면 NACL 설정도 가능하겠다. 아직까지 이렇게 하는 데는 보지 못했다.

 

 

SG를 예제로 추가 설명을 해보겠다. 다음 이미지는 SG에 등록된 Inbound Rule이다. sg-0211a3f36a80e78b5 의 SG을 달고 있는 서비스의 TCP 8080 포트 인바운드 통신을 허용하겠다는 의미다. 즉, 어느 EC2가 해당 SG를 달고 있으면 그 EC2는 8080 포트로 접속이 된다는 의미다. 여기서 우리는 Source로 IP 주소로도 등록이 가능하다.

하지만 별로 추천되지 않는다. 예를 들어 웹서버를 하는 전형적인 3 Tier 구조가 있다. 서버 부하에 따라 Web Tier 쪽 서버가 늘어난다고 치자. 그럼 Web Tier의 요청을 받는 App Tier는 매번 늘어날 서버의 IP 주소를 일일이 SG Inbound Rule에 등록해줘야 하는 상황이 일어난다. 하지만 앞단의 Web Tier가 참조하는 SG를 Source로 등록하면 이런 문제는 해결이 된다.

 

 

5. VPC DNS 호스트 네임 활성화

VPC 생성했으면, 웬만하면 DNS 호스트 이름을 활성화 해주자. 퍼블릭 IP주소가 할당될 때, 그에 상응하는 DNS 주소를 제공하도록 하는 설정이며, 이것을 안 해주면 VPC 내에 생성되는 서버에 도메인이 붙지 않아 당장에 문제는 없을 수 있지만 향후 유연한 호출에 제약이 많아질 수 있다. 활성화가 필요한 예로, Route 53의 프라이빗 호스팅 영역에서 정의된 사용자 지정 DNS 도메인 이름을 사용하거나, 프라이빗 DNS를 인터페이스 VPC Endpoint와 함께 사용하는 경우 이 설정은 반시 활성화돼야 한다. 

 

 

만약 VPC는 생성했고 DNS 호스트 이름이 비활성화된 상태여도 걱정하지 말자. 생성된 이후에 이거 활성화했다고 서비스가 단절 나거나 리소스가 꼬이는 일은 없다.

 

 

본 포스팅은 실습이라기 보단 개념 정리에 가깝습니다. 오류 사항이 있다면 댓글로 부탁드립니다.