[VPC, Subnet]
AWS 서비스 구조
우리가 깃허브나, 넷플, 네이버를 이요할 때 퍼블릭인터넷의 다양한 노드를 통해서 퍼블릭인터넷에 존재하는 여러 다양한 웹사이트를 이용한다. S3나 클라우드 서비스들도 퍼블릭 인터넷을 통해 사용한다.
이중에 예외는 VPC다. VPC는 원칙적으로 퍼블릭인터넷을 통해 접근이 불가능하다. 따라서 다른 AWS 서비스들은 모두 퍼블릭으로 엔드포인트가 있어서 퍼블릭 접근이 가능하지만 VPC는 불가능하다.
이렇게 퍼블릭인터넷으로 접근 가능한 AWS 서비스들은 안에 있는 내부 AWS 클라우드 내부에서도 예외는 아니다.
무슨말이냐, 예를들어서 아마존 EC2로 S3로 접근하고 싶다 하면 바로 접근이 가능한게 아니다. AWS 클라우드 내부더라도 EC2에서 Internet Gateway를 이용해 퍼블릭인터넷으로 나간다음에 다시 S3로 들어와야 한다.
우리가 VPC를 이요한다는 것은 외부와 격리된 서버를 만드는게 목적이다.
VPC(Virtual Private Cloud)
- 가상 네트워크이다.
- IP주소 범위와 VPC 범위를 설정하고 서브넷을 추가하고 보안 그룹을 연결한 다음 라우팅 테이블을 구성합니다.
- 외부에 격리된 네트워크 컨테이너(docker가 아닌 네트워크를 담는 unit) 구성 가능
- 원하는 대로 사설망 구축 가능
- 부여된 IP 대역을 분할하여 사용 가능
- 원하는 대로 사설망 구축 가능
즉, 가상으로 존재하는 데이터센터.
즉, 외부와 단절되어있는 가상의 네트워크 단위
VPC 구성 요소
- 서브넷
- 인터넷 게이트웨이
- NACL/보안그룹
- 라우트 테이블
- NAT Instance/ NAT Gateway
- Bastion Host
- VPC Endpoint
1. 서브넷
- VPC의 하위 단위로 VPC에 할당된 IP를 더 작은 단위로 분할한 개념
- 하나의 서브넷은 하나의 가용영역(AZ)안에 위치
(하나의 가용 영역에는 다수의 서브넷이 존재할 수 있다.) - CIDR block range로 IP 주소 지정
- AWS의 사용 가능 IP숫자는 아래 5개를 제외하고 계산한다.
- 예) 10.0.0.0/24라면,
- 10.0.0.0 : 네트워크 어드레스
- 10.0.0.1 : VPC Router = VPC가 점유하고 있어서 못 씀
- 10.0.0.2 : DNS Server = DNS 서버가 가지고있어서 못 씀
- 10.0.0.3 : 미래에 사용을 위해 남겨 둬서 못 씀
- 10.0.0.255[마지막번호] : 네트워크 브로드캐스트 어드레스(단 브로드캐스트는 지원하지 않음)로 점유되어있어서 못씀
- 예) 10.0.0.0/24라면,
참고
/24 면 24비트가 고정 따라서 10.0.0 까지가 고정
총 32개 중 24개 빠졌으니까 마지막 .0 은 8승 할당될 수 있다. 즉, 총 사용 가능한 IP 갯수는 2의 8승 - 5 = 256-5 = 251
2. 라우트 테이블(Route Table)
- 트래픽이 어디로 가야 할지 알려주는 이정표
- VPC 생성시 기본으로 하나 제공
요청이 들어오면,
1. Destination(CIDR Block)목록에서 가장 구체적인 걸 찾아다가 알려준다.
(10.0.0.0/16은 IP Range이지 하나의 IP가 아니다.)
2. 타겟이 local이라고 쳤을 떄 2️⃣ 처럼 들어 갈 수 있다.
- 그럼 2️⃣ 목록이 어디에 해당되느냐?
10.0.0.0/16,0.0.0.0/0에도 해당될 수 있다. 여기서 더 구체적인10.0.0.0/16을 따르게 되는 것이다
클라이언트 요청이 들어오면
- 클라이언트: 야, 이 IP는 어디로 보내면 되는지 알려줘~
- 라우터테이블: 여기서
10.0.0.0/16이 가장 구체적이네? 그럼 local로 가야해~
Q. 가장 구체적인건 어떻게 아나요?
/{여기에 붙는 숫자}가 클수록 구체적인 것이다.
Q. 만약 171 대역대가 들어온다면?
172.31.0.0/16,0.0.0.0/0둘 다 가능하지만 더 구체적인172.31.0.0/16의 pcx-... VPC 피어링 주소로 연결된다.peering은 VPC가 두대 이상일 때 쓴다.
Q. 만약 여러 대역대가 들어온다면?
나머지 트래픽은 매칭되는애가 없다면0.0.0.0/0의 igw-... 인터넷 게이트웨이 주소로 연결된다.
라우트 테이블이 연결되어 있기 때문에 이 서브넷A와 서브넷B끼리 통신을 할 수 있는 것이다.
예를들어 이 서브넷A안에 있는 EC2가 10.0.1.31로 뭔가를 보냈다면 라우트 테이블에 보내고 10.0.1.31한테 메시지 전달해줘. 하면 라우트테이블에서 이 메시지는 어디로 가야하지~?하고 라우트테이블의 Destination 참고해보니까 10.0.0.0/16에 매칭이 되네? > local로 보내~
결과적으로는 서브넷B의 10.0.1.31이 있는 EC2 인스턴스가 받아서 처리를 한다.
서브넷의 종류
- public subnet : 외부에서 인터넷을 통해 연결할 수 있는 서브넷
- 인터넷 게이트웨이(IGW)를 통해 외부의 인터넷과 연결되어 있음
- 안에 위치한 인스턴스에 퍼블릭 IP 부여 가능
- 웹서버, 어플리케이션 서버 등 유저에게 노출되어야 하는 인프라
- private subnet : 외부에서 인터넷을 통해 연결할 수 없는 서브넷
- 외부 인터넷으로 가는 경로가 아예 없음
- 퍼블릭 IP 부여 불가능(있다고 해도 쓸모가 없기 때문)
- 데이터베이스, 로직 서버 등 외부에 노출 될 필요가 없는 인프라 == 외부의 유저들이 접속할 필요가 없는 서버
인터넷 게이트 웨이
- VPC가 외부의 인터넷과 통신할 수 있도록 경로를 만들어주는 리소스
- 기본적으로 확장성과 고가용성이 확보되어 있음
(트래픽에 따라 확장하거나 더 많이 프로비전할 필요가 없음) - IPv4, IPv6 지원
- IPv4의 경우 NAT 역할
- Route Table에서 경로 설정 후에 접근 가능
- 무료
Q. 만약 서브넷A에서 8.8.8.8 외부로 트래픽을 보낸다고 했을 때 라우트 테이블에서는
0.0.0.0/0의 igw(인터넷 게이트웨이)로 보내게 된다.
그러면 인터넷 게이트웨이는 이 요청을 외부에 있는 퍼블릭 인터넷으로 보낸다. 그럼 8.8.8.8은 알아듣고 응답을 보내게됨.
따라서 인터넷 게이트웨이는 외부의 퍼블릭 인터넷으로 경로를 만들어주는 역할을 한다.
이 인터넷 게이트웨이로 경로가 있는 즉 어떤 트래픽이 이 인터넷 게이트 웨이로 들어갈 수 있는 라우트 테이블이 붙어있는 서브넷을 퍼블릭 서브넷이라 한다.
