VPC
VPC가 뭔데!!
가상 사설 클라우드(VPC)
VPC는 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사한 가상 네트워크입니다. VPC를 만든 후 서브넷을 추가할 수 있습니다.
-aws document-
AWS에서 사용하는 나를 제외한 다른 사람들과 논리적으로 구분되고 격리되어 있는 환경을 만들기 위해 사용을 한다.
기본적으로 VPC내부에 서브넷 혹은 EC2 등이 위치하기 위해 필수적으로 필요하다
구글에 aws architecture를 검색해서 아키텍처들을 살펴보면 VPC로 감싸져 있는 걸 흔하게 볼 수 있다.
VPC 생성
VPC의 IPv4 CIDR
10.0.0.0/16 CIDR 주소
VPC를 집이라고 생각을 해보자, 집 주소는 통상 부천시 중동로 122번 길 이런 식으로 돼있으나. VPC관점에서 집주소는 10.0.0.0 인 것이다.
VPC의 네트워크 아이피는 10.0.0.0이다.
그럼 VPC내부에서 사용할 수 있는 호스트 아이피 대역은 VPC의
- 네트워크 아이피와
- 브로드 케스트 아이피
를 제외하고
10.0.0.1 ~ 10.0.255.254
근데 지금 집을 보면 원룸이다. 어디가 화장실이고 안방이고 누나방이고 내방인지 모르게 사생활이 없는 구조이다.
이제 방 또는 화장실을 나눠야 하는데 나눌 수 있는 대역은
10,0,0,1 ~ 10.0.255.254 사이에서 나누면 되는 것이다.
하지만!! 이 사이에서도 쓰지 못하는 대역은 아래와 같다.
- 10.0.0.0: 네트워크 주소
- 10.0.0.1: VPC 라우터용으로 예약한 주소
- 10.0.0.2: DNS 서버의 IP 주소로 예약된 주소
- 10.0.0.3: 향후 사용을 위해 예약한 주소
- 10.0.255.255: 브로드캐스트 주소
서브넷
서브넷 생성
VPC의 CIDR을 10.0.0.0/16으로 했으므로 VPC 내부에서 사용할 수 있는 호스트 주소는
10.0.0.0 ~ 10.0.255.255라고 했다. 여기서 대역을 한번 더 나누어서
VPC내부에 서브넷을 만들 것이다.
- 가용영역 sp-northeast-2a에 Public Subnet, Private Subnet
- 가용영역 sp-northeast-2c에 Public Subnet, Private Subnet
이렇게 총 4개의 서브넷을 만들 예정이다.
VPC는 당연히 위에서 만든 VPC를 사용하고 가용영역을 위에서 말했듯 설정을 해준다.
먼저 이 예시는 ap-northeast-2a에 Public Subnet을 하나 만드는 예시이다, 나머지 3개도 동일하게 하면 된다.
Availabilty Zone(AZ, 가용영역)
AWS 리전(Region) 내에 위치한 물리적으로 격리된 데이터 센터
현제 Region이 서울로 되어있고
가용영역을 선택하면 서울과 관련된 영역이 4가지가 나온다.
리전을 도쿄로 설정한다면 도쿄에 대한 가용영역들이 따로 보이겠지?
서울이라는 지역에 물리적으로 떨어져 있는 데이터 센터가 4개가 있다는 말이다.
혹은 여러 개의 데이터 센터를 하나의 그룹으로 묶어서 표현했을 수도 있다.
즉 서브넷을 어느 데이터 센터에서 보관할지 정하는 작업이다.
2a가 강남구에 있다면 2c는 마포구에 있을 수도 있다.
왜 가용영역을 ap-northeast-2a로 전부 안 하고 ap-northeast-2c로 또 나누나요?
고가용성 때문이다.
왜 가용영역을 ap-northeast-2a로 전부 안 하고 ap-northeast-2c로 또 나누나요?
시스템의 장애가 없이 지속적으로 작동을 하도록 할 수 있는 능력이다.
ap-northeast-2a라는 AZ에 모든 서브넷과 인스턴스를 넣었다고 가정을 해보자.
근데 하필 2a라는 AZ에 불이 나서 데이터 센터가 재기능을 못한다면 내 서비스에 심각한 장애가 생길 것이다.
즉 고가용성 측면에서 상당히 어긋난다.
하지만 가용영역을 2a와 2c로 나누어서 적절하게 분배를 한다면 위와 같은 상황이 일어났을 때 사용자의 트래픽을 2c로 돌린다면 사용자 입장에서는 시스템의 장애가 없이 지속적으로 작동을 한다고 느낄 것이다.
서브넷 이란?
VPC라는 논리적인 네트워크 영역을 만들어 주었고 이 영역을 세분화해서 쓰는 것이다.
본인의 집을 VPC라고 생각을 하자, 집에 거실, 화장실, 베란다, 안방, 방 이런 식으로 있을 것이다.
이것들 하나하나를 서브넷이라고 생각하면 된다. 물론 집에 모든 벽을 허물고 엄청 큰 원룸으로 쓸 수는 있지만 그렇게 쓰는 사람은 없을 것이다.
10.0.0.1 ~ 10.0.0.254 사이에서 가족들끼리 공간을 어떻게 나누어 쓸 것인지 정해야 한다.
ipv4 VPC CIDR 블록은 위에서 설명한
ipv4 서브넷 CIDR 블록이 이제 엄마, 아빠, 누나, 나 의 영역을 나누는 기준이 될 것이다.
10.0.0.0/24
lab-edu-sub-pub-1이라는 서브넷을 엄마방이라고 하고
우리 집 주소는 10.0.0.0인데 그 안에서도 엄마방의 주소는 10.0.0.0이다.
우리 집 주소 10.0.0.0에서 10.0.0.0이라는 엄마방 주소가 있는데 엄마방에는
10.0.0.1~10.0.0.254 즉 254개의 가구를 놓을 수 있다.
10.0.1.0/24
아빠방도 만들어 주자(lab-edu-sub-pub-2).
우리 집 주소는 10.0.0.0이고
그 안에서 아빠방의 주소는 10.0.1.0이다.
엄마방과 동일하게 아빠방에도 가구마다 주소를 붙여주는 희한한 관습이 있는데.
- 아빠방 주소와
- 브로드 캐스트 주소
를 제외한
10.0.1.1 ~ 10.0.1.254 즉 254개의 가구를 배치할 수 있다.
10.0.40.0/24
이제는 누나 방이다(lab-edu-sub-pri-1)
우리 집 주소는 10.0.0.0이고 누나방의 주소는 10.0.40.0이다.
- 누나방 주소와
- 브로드 캐스트 주소를 제외한
누나방에 배치할 수 있는 가구들도 엄마 아빠와 동일하게 10.0.40.1 ~ 10.0.40.254 즉 254개이다
10.0.41.0/24
이제는 내 방이다. 우리 집 주소 10.0.0.0에서 내방주소 10.0.41.0을 제외한
10.0.41.1 ~ 10.0.41.254 즉 254개의 가구를 배치할 수 있다.
Public 서브넷과 Private서브넷은 무슨 기준?
서브넷을 만드는 과정을 보면 알겠지만 이름에만 pri, pub으로 구분을 했지 특별히 다른 작업을 하진 않았다.
집을 처음 건축하고 벽들을 새울 때 이 벽 안에 공간이 화장실(프라이버시 보호를 위한 private subnet)인지 누구나 드나들 수 있는 거실(public subnet)인지는 입주하는 내가 정의하기 나름이다.
즉 이름을 pri로 지어놓고 public 하게 써도 문제 될 건 없다.
뒤에서 다룰 내용이지만
인터넷 게이트웨이에 해당 서브넷이 연결이 되어있냐 아니냐로 구분이 됨.
지금까지는 인터넷게이트웨이랑 연결을 안 했기에 4개의 서브넷이 사실상 전부 private이다.
서브넷을 나누는 이유?
집의 공간을 효율적으로 사용이 가능하고,
- 프라이버시 보호도 되고(보안)
⇒ 아빠(백엔드 서버), 누나(프런트 서버) 나(DB 서버)
나랑 누나는 사이가 너무 안 좋아서 같은 집에는 있지만 의절을 해서 서로의 방에 들어갈 일이 전혀 없다,
(실제로 프런트엔드에서 DB에 디렉트로 접근하는 경우가 없듯이.)
하지만 아빠는 누나랑도 사이가 좋고 나랑도 사이가 좋아서 서로의 방에 드나들 수 있다.
(디비에 접근 가능한 서버는 백엔드 서버이므로)
가끔 누나가 아쉬운 게 있어 나한테 부탁할 게 있으면 아빠를 통해 부탁을 한다.
(프런트→백엔드→DB)
- 트래픽 또한 분산이 된다.
⇒ 원룸이면 아빠 손님이 와도 엄마 누나 내가 전부 마주치게 되지만 서브넷으로 공간을 나누어 놓으면 아빠 손님이 내 방에 들어오지 않기 때문
라우팅 테이블
라우팅 테이블 생성
- public 라우팅 테이블 1개 (public subnet 2개 연결)
- private 라우팅 테이블 2개 (private subnet 각각 1개씩 연결)
라우팅 테이블을 기본적으로 생성하면 10.0.0.0/16 이 보인다.
VPC의 CIDR도 10.0.0.0/16 이였다.
저 말은 즉슨 VPC내부에 서브넷끼리는 전부 통신이 가능하도록 라우팅 테이블이 잡혀있다.
내가 알던 라우팅 테이블이랑 다른데, Public 클라우드랑 온프레미스 환경이랑 무슨 차이죠 ?
원래의 라우팅 테이블의 경우에는 Static으로 경로를 잡아주던가 혹은 BGP를 이용해 서로의 경로를 알려주는 식으로 작동을 한다.
위 예시는 10.0.1.100이라는 아이피를 가진 피씨가 10.0.5.100번대의 PC에게 Ping을 보냈을 때 ICMP 패킷이 가는 그림을 대략 그려보았다.
즉 물리적인 라우터에 라우팅 테이블이 있어 Longest Matching 방식으로 전달이 되는데.
클라우드 환경에서는?
AWS VPC는 물리적 라우터 대신 소프트웨어 정의 네트워크(SDN) 방식으로 구현한다.
VPC내부에서 서브넷들이 통신을 할 때 물리적인 라우터가 아닌 소프트웨어적인 방식으로 구현이 되어있어.
온프레미스 환경에서 라우팅 테이블과 살짝 차이가 있다.
라우팅 테이블에 VPC의 CIDR이 들어있다면 해당 VPC내부에서는 경로를 서로 알고 있다는 뜻이 된다
하지만 아직 외부랑 통신이 불가능하다
우리가 쓰는 10.0.0.0 대역의 아이피는 사설 아이피 대역이므로.
ISP에 의해 서비스가 될 수 없다.
또한 아직 EC2인스턴스를 만들어보지 않았지만, EC2인스턴스가 공인아이피를 따로 할당받아 쓴다 한들
인터넷 게이트웨이가 없으면 외부로 트래픽이 나가거나 내부로 트래픽이 들어올 수 없다
인터넷 게이트 웨이
인터넷 게이트 웨이 생성
인터넷 게이트웨이를 생성했다면 VPC에 연결을 해야 한다
지금 집은 있는데 현관문이 없어서 엄마 아빠 누나 내가 고립이 된 상황이다 🤣
온프레미스 환경에 비교해 보면 게이트웨이 라우터와 상응되는 개념이다.
라우팅 테이블에 인터넷 게이트웨이 경로 지정
게이트 웨이라는 현관문을 만들었다면 현관문이 어디인지를 방(서브넷)에 알려줘야 한다.
반대로 현관문에서 손님이 왔는데 아빠방인지 엄마방인지 누나방인지를 알려줘야 한다.
lab-edu-rtb-pub은 퍼블릭 서브넷들에게 라우팅 경로를 제공하는 라우팅 테이블인데. 해당 테이블에 인터넷 게이트웨이의 경로를 연결을 해준다면.
해당 테이블을 참조하는 서브넷들은 외부랑 통신이 가능하다. 이제 이름만 퍼블릭이 아닌 진짜 public subnet으로써의 자질을 갖추었다.
0.0.0.0/0의 의미는 무엇인가요
디폴트 게이트웨이
VPC내부에서 트래픽이 발생하면 라우팅 테이블을 참고해서 Longest prefix matching방식으로 올바른 경로로 보내줄 것이다.
우리는 기존에 10.0.0.0/16이라는 걸 통해 VPC내부의 경로는 전부 파악을 하고 있다.
그럼에도 불구하고 매치가 안 되는 아이피가 발생을 한다면 이건 VPC내부가 아닌 외부로 보내는 요청이라 판단을 한다는 말이다.
0.0.0.0/0의 의미는 디폴트 게이트웨이이고 이 경로를 인터넷 게이트웨이로 해주겠다는 의미이다.
NAT게이트웨이
NAT게이트 웨이란 ?
AWS에서 NatGateway는 프라이빗 서브넷에 있는 리소스가 외부 인터넷과 통신할 수 있도록 도와주는 역할을 한다.
NatGateway도 인터넷게이트웨이를 통해 트래픽이 나감.
엥 Private Subnet이라 외부랑 통신을 못하게 하려고 인터넷게이트웨이를 설정 안 했잖아
외부에서 트래픽이 Private Subnet 안으로 들어오는 건 당연히 불가능하다 왜냐면 인터넷게이트웨이를 연결을 안 함으로써 해당 서브넷을
Private Subnet으로 만들었기 때문에, 근데 NATGateway를 설정해 주는 이유는
해당 서브넷에 있는 인스턴스에서 파일 다운로드나, 버전패치 혹은 외부 API에 요청을 보내는 경우는 있을 수 있다 이 경우에 트래픽이 외부로 나가야 한다.
하지만 반대로 요청의 주체가 VPC외부에 있는 무언가라면 허용이 되지 않는다.
같은 VPC내부에서는 Private Subnet과 Public Subnet끼리 기본적으로 통신이 가능하다
Internet Gateway와 Nat Gateway가 말하는 통신의 범주는 VPC 외부를 기준으로 한다. 단 보안그룹을 사용해서 VPC내부에서의 통신도 조율이 가능하다.
NatGateway 생성
NatGateway를 왜 private이 아닌 Public Subnet안에 생성을 하죠?
위에 한 말들을 종합을 해보면.
- Private Subnet은 인터넷 게이트웨이랑 연결을 안 했음 ⇒ VPC바깥으로 나갈 수 없음.
- Public Subnet은 인터넷 게이트웨이에 연결이 되었음 ⇒ VPC 바깥으로 나갈 수 있음.
- 기본적으로 같은 VPC내부에서는 Private Subnet과 Public Subnet이 통신이 가능함.
- NatGateway도 인터넷게이트웨이를 통해 VPC바깥으로 나감
- 라우팅 테이블에서 인터넷게이트웨이로 가는 경로를 적용한 건 Public Subnet임
이 상황에서 NatGateway를 Private Subnet에 배치를 한다면? ⇒ NatGateway도 결국 인터넷 게이트웨이를 통해 나가는데 Private Subnet에 배치를 한다면 NatGateway가 인터넷게이트웨이의 경로를 찾을 수 없어 통신이 불가능함.
대신 Private Subnet에서 NatGateway로 가도록 라우팅 테이블을 추가해줘야 함.
