[AWS] 📚 VPC 개념 & 사용 - 인프라 구축 [Subnet / Routing / Internet Gateway]

VPC (Virtual Private Cloud) 개념 정리

VPC는 사용자가 정의하는 aws 계정 사용자 전용 가상의 네트워크 이다.

사용자는 자기가 원하는대로 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워크 환경을 구성해 VPC를 생성할 수 있다.

한마디로 AWS용 나만의 개인 네트워크 망 데이터센터 라고 이해하면 된다.

 

AWS는 VPC의 중요성을 강조하여 모든 서비스에 VPC를 적용하도록 강제하고 있다.

2011년 VPC 출시 이후 EC2-Classic Platform(VPC 출시 전의 네트워크)의 사용이 중단되고, VPC 사용이 의무화된 데다 대부분의 AWS 서비스가 VPC에 의존적이기 때문에 VPC에 대한 이해는 필수적이다.

 

예전에는, 아래와 같이 VPC 이전 EC2-클래식 네트워크는 여러 사용자의 인스턴스들이 거미줄처럼 얽혀있어 복잡도가 높았다. 

 

그러나 Amazon VPC가 도입된 이후로 아래와 같이 인스턴스가 VPC에 속함으로써 네트워크를 구분할 수 있고 VPC 별로 필요한 설정을 통해 인스턴스에 네트워크 설정을 적용할 수 있게 되었다. 

사용자는 직접 VPC를 생성해서 사용할 수도 있고 계정을 생성시 region별로 디폴트로 생성되는 VPC를 사용할 수도 있다. 

인스턴스는 하나의 가상 컴퓨터라고 이해하면 된다.

---

VPC를 알아보기 이전 선수 지식 (필수)

AWS VPC를 이해하고 구축하기 위해선 아래의 지식들이 필수이다. 앞으로 VPC를 설정할때 자주자주 등장하는 개념과 용어들이다.

만일 애매하게 알고있거나 잘 모른다면 포스팅 링크로 가서 마스터를 하고 돌아오기를 권장한다.

 

IP 클래스 • 서브넷 마스크 • 서브넷팅 완벽 정리

[WEB] 🌐 IP 클래스 • 서브넷 마스크 • 서브넷팅 💯 완벽 이해하기

 

CIDR 개념 정리 & 계산법

[WEB] 🌐 CIDR 이 무얼 말하는거야? ⇛ 개념 정리 & 계산법

 

Region(리전) / AZ(Availability Zone) / Edge Location 개념 정리

[AWS] 📚 아마존 웹 서비스 구조 (Region / AZ / Edge Location / Cache) 완벽 정리

 

aws 네트워크 / 클라우드 용어 정리 (고가용성, 장애허용 ...등)

[AWS] 📚 클라우드 용어 정리 (고가용성 / 장애내구성 / 확장성 / 탄력성)

---

VPC (Virtual Private Cloud) 구성 요소

전체적인 VPC 모델 지도이다.

생소한 용어들이 많지만 차근차근 배워보면 그렇게 복잡하지 않다.

하나하나 씩 배워나가고 실전 구축을 통해 익혀보자.

---

VPC (Virtual Private Cloud)

위의 그림에서 보면 알 수 있듯이 AWS Cloud 내에는 IDC의 집합인 'Region'이 존재하며 Region은 2개의 'Availability Zone(AZ)'으로 이루어져 있다. 그중에서 VPC는 Region에 상응하는 규모의 네트워크라는걸 그림을 통해 알 수 있다.

IDC는 ‘인터넷 데이터 센터’(Internet Data Center)의 준말로, 인터넷 연결의 핵심이 되는 서버를 한 데 모아 집중시킬 필요가 있을 때 설립하는 시설을 말한다. 

즉, VPC는 독립된 하나의 네트워크를 구성하기 위한 가장 큰 단위이다.

그리고 VPC는 Region에 하나씩 이다. 다른 Region과 걸쳐서 확장이 불가능하다.

 

VPC는 각 region에 종속되며 RFC1918이라는 사설 IP 대역에 맞추어 설계해야 한다.

VPC에서 사용하는 사설 IP 대역은 아래와 같다.

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

AWS VPC는 On-premise(전통적인 인프라)와 동일한 대역의 사설 IP를 이용해 범위 내에서 vpc의 ipv4 CIDR영역을 설정한다.

참고로 한 리전안에 VPC를 여러개 생성할때 서로 아이피는 겹치면 안된다. 생성은 되지만 DNS IP를 잡지 못하는 에러가 발생하기 때문이다.

예를 들어, 기본 VPC가 172.31.0.0/16으로 생성되어 있다면 우리는 172.31 네트워크 IP주소를 피해서 생성해야 한다.

 

그리고 유의할 점이 있는데, 원래 규정된 사설 IP 범위와는 다르게 aws에서는 /16 ~ /28 비트의 서브넷 마스크만을 허용한다는 것이다.

즉, AWS VPC를 생성할 수 있는 가장 큰 IP 대역은 /16이며, 가장 작은 대역은 /28 인 셈이다.

이 범위내에서만 CIDR를 설정해야 된다.

 

그리고 VPC에서 한번 설정된 IP 대역은 수정할 수 없으며, 각각의 VPC는 독립적이기 때문에 서로 통신할 수 없다.

만일 통신을 원한다면 VPC 피어링(peering) 서비스를 통해 VPC 간에 트래픽을 라우팅할 수 있도록 설정할 수 있다.

---

VPC 실전 구성하기

먼저 검색창에 vpc라 검색하고 서비스에 들어간다.

그리고 region을 미국에서 서울로 변경하고 vpc 마법사 시작 버튼을 누른다.

 

설정값을 선택하고 생성버튼을 누르면 다음과 같이 study라는 vpc가 생성되는걸 볼 수 있다.

(참고로 위에 있는 - vpc는 계정 생성할때 같이 만들어지는 기본 vpc이다)

 

다시 VPC 메뉴로 돌아가서 방금 만든 VPC를 선택하고 우측 상단에 있는 작업 버튼을 눌러 DNS 호스트 이름 편집으로 들어가 호스트 이름 활성화에 체크해주고 저장해준다.

---

서브넷 (Subnet)

서브넷은 VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위를 뜻한다.

VPC가 논리적인 범위를 의미한다면, 서브넷은 VPC안에서 실제로 리소스가 생성될 수 있는 네트워크 영역이라고 생각하면 된다. 실제로 EC2, RDS같은 리소스를 생성 할 수 있다.

 

그리고 하나의 VPC에 N개의 서브넷을 가질 수 있으며 하나의 AZ에만 생성이 가능하다.

다음 사진처럼 여러 AZ에 걸쳐서 서브넷을 생성할수 없다는 말이다.

 

서브넷 역시 vpc처럼 CIDR 범위는 /16(65536개) ~ /28(16개)을 사용할 수 있으며, VPC CIDR 블록 범위에 속하는 CIDR 블록을 지정할 수 있다.

 

아래 사진을 보면 VPC(10.0.0.16) 내에서 다시 크기를 두개로 쪼개서 사용하게 되는데 VPC를 쪼갠 조각들이 바로 Subnet(10.0.1.0/24)이다.

그리고 하나의 AZ(Availability Zone)에 서브넷이 각각 할당되어 있는 것을 볼 수 있다.

VPC를 잘게 나눈 것이 서브넷이기 때문에 당연히 VPC보다 대역폭이 낮아야 한다.

 

단, 서브넷 대역폭을 지정해 호스트를 사용할때 유의할 점이 있다.

AWS가 관리용으로 사용하는 IP도 존재하는데, 아래에 서술한 IP들은 AWS의 관리 IP로서 사용자가 사용할 수 없는 AWS의 예약 주소이다. (10.0.0.0/24 기준)

10.0.0.0	네트워크 주소 (Network ID)
10.0.0.1	AWS에서 VPC 라우터용으로 예약 (Default Gateway)
10.0.0.2	DNS 서버 주소 DNS 서버의 IP 주소는 기본 VPC 네트워크 범위에 2를 더한 주소이다. CIDR 블록이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치하게 된다.
10.0.0.3	AWS에서 앞으로 사용하려고 예약한 주소
10.0.0.255	네트워크 브로드캐스트 주소

기억을 떠올려보면 네트워크 이론에서 호스트 범위의 가장 첫번째 주소는 네트워크 주소, 마지막 주소는 브로드캐스트 주소로서 호스트를 이용할 수 없었다.

그런데 AWS에서는 자체 서비스에 이용되는 호스트가 추가로 할당되어있어서 총 2+3개를 사용을 못한다고 이해하면 된다.

예를들어 이런 AWS 기출 문제가 있다고하면,

Q. AWS에 192.168.0.0/24 에서 총 사용가능한 호스트 갯수는?

1이 24개 있으니 호스트ID는 8비트니까, 2^8=256개 이고 그중 처음과 끝은 빼면 254개다! 라고 하면 틀린 것이다.
256-5=251이 정답이다.

 

Public Subnet  / Private Subnet 

서브넷은 다시 Public Subnet과 Private Subnet으로 나뉠 수 있다.

인터넷과 연결되어있는 서브넷을 public subnet이라고 하고, 인터넷과 연결되어있지 않은 서브넷을 private subnet이라고 한다.

• Private Subnet : 인터넷에 접근 불가능한 subnet (VPC 내부에서만 통신)
• Public Subnet : 인터넷에 접근 가능한 Subnet (VPC 외부/내부와 통신)

따라서 public subnet에 존재하는 인스턴스는 Public IP와 Elastic IP를 보유하여 인터넷에 연결되어 아웃바운드, 인바운드 트래픽을 주고받을 수 있는 반면, private subnet은 외부에 노출이 되어 있지 않기 때문에 접근할 수 없다.

인바운드 : 외부에서 - > 인스턴스로 오는 트래픽
아웃바운드 : 인스턴스에서 - > 외부로 가는 트래픽

그래서 private subnet에 민감한 데이터 정보들을 저장해 보안을 강화하는 식으로 설계를 하는 편이다.

이처럼 Private 서브넷 내부의 인스턴스들은 오직 다른 서브넷과만 연결이 가능한데, 만일 데이터를 업데이트하는데 인터넷 연결이 필수라면 뒤에 배울 NAT instance를 통해서 Private 내부의 인스턴스들이 인터넷을 가능하게 만들 수도 있다.

 

위 사진은 서브넷 구조의 완성형이다. (사진에 보이는 Router나 Internet gatway는 다음 섹션에서 진행한다)

AZ안에 public 서브넷 과 private 서브넷을 배치했다.

 

public Subnet인 10.0.1.0/24와 10.0.2.0/24은 EC2 다수를 탑재해야하니 다수의 사설 IP 필요하므로 cidr값을 낮게 줘서 /24(256개) Subnet 범위를 크게 나누었다.

private Subnet인 10.0.3.0/25과 10.0.4.0/25은 RDS와 같은 소수의 서비스를 탑재하므로 많이 필요하지 않아 cidr 값을 높게 /25(128개) 주었다.

 

이런식으로 서브넷을 나눠 구성하면 된다. 그렇게 어렵지 않다.

정리하자면, 다음과 같이 구성이 되어진다.

• VPC : 10.0.0.0/16
• public Subnet : 10.0.1.0/24, 10.0.2.0/24,
• private Subnet : 10.0.3.0/25, 10.0.4.0/25

---

Subnet 실전 구성하기

위의 그림처럼 대로 AZ 2개 서브넷을 public 2개, private 2개 구성해볼 계획이다.

	ap-northeast-2a (AZ)	ap-northeast-2c (AZ)
Public subnet	10.0.1.0/24	10.0.2.0/24
Private subnet	10.0.3.0/25	10.0.4.0/25

서브넷을 성공적으로 생성했다면, 서브넷 목록 페이지로 이동된다.

이렇게 서브넷 4개를 구성을 완료했다.

public 서브넷과 private 서브넷을 각기 다른 AZ에 설정해도 될까?

결론적으로는 문제가 없다. 다만 같은 AZ에 설정하는 이유는 각기 나누어 다른 AZ에 설정할 경우 데이터센터 끼리의 통신이 추가적으로 발생하기 때문에 트래픽 속도가 느려질수 있기 때문이다.

서브넷은 한번 만들면 옵션 수정이 불가능하다.
그래서 설정을 바꿔야 할 상황이 생기면 지우고 새로 만들어야 한다.

 

 

퍼블릭 서브넷에 public IP 자동 할당 설정

후에, EC2 인스턴스를 생성할때 하는 작업이라 여기서 해도 되고 안해도 되지만 미리 설정해서 확실히 서브넷을 구분 짓는것도 나쁘지 않다.

이 서브넷에 들어간 모든 IP는 자동으로 퍼블릭 주소로 활성화 하는 옵션이다. 이걸 설정하지 않으면 인터넷과 통신을 못한다.

퍼블릭 서브넷은 외부 인터넷과 통신하라고 만든 서브넷이기 때문에, 앞서 만든 2개의 퍼블릭 서브넷에 주소 자동 할당 활성화를 체크 한다.

 

Subnet에 EC2 인스턴스 넣기

EC2 인스턴스를 생성하고 적절히 설정을 진행해준다.

그러다 [단계 3: 인스턴스 세부 정보 구성 단계]에 오면 VPC와 서브넷을 지정해 줄수 있게 된다.

 

1. Public 서브넷 인스턴스 생성

네트워크와 서브넷에 위에서 생성한 VPC와 퍼블릭 서브넷을 선택한다. 

퍼블릭 IP 자동할당은 활성화를 선택한다 (그래야 EC2 인스턴스를 만들었을 때 퍼블릭IP를 자동으로 할당받는다)

만일 바로 위에서 서브넷에 퍼블릭 IP 자동 할당 설정을 체크했으면, 사진처럼 기본으로 (활성화)가 되어있을 것이다.

 

 

2. Private 서브넷 인스턴스 생성

현재 화면에서 한꺼번에 public, private 서브넷을 생성할수는 없고, 인스턴스를 만들고 난뒤 또 만드는 식으로 하나하나 등록을 해야 한다.

인스턴스를 또 생성하고 앞서 만든 private subnet을 등록해주면 된다.

 

퍼블리과 프라이빗 인스턴스를 생성 완료하게 되면 다음과 같이 될 것이다. (다른 가용영역의 서브넷에 인스턴스 연결은 나중에 할 예정이니 우선 2개만 생성해 두자)

---

라우팅 테이블 (Routing Table)

각각의 Subnet은 서로 다른 네트워크 영역을 가지고 있다. 따라서, 한 Subnet이 다른 Subnet으로 가기 위해서는 'Routing'이 필요하게 된다.

라우팅 테이블은 VPC 안에서 발생한 네트워크 요청을 처리하기 위해 어디로 트래픽을 전송해야 하는지 알려주는 표지판 역할을 수행한다.

각 서브넷들은 이러한 네트워크 트래픽 전달 규칙에 해당하는 라우팅 테이블을 가지고 있으며, 요청이 발생하면 이 라우트 테이블을 사용해서 목적지를 찾게 되는 것이다.

[위 라우팅 테이블의 뜻]

트래픽이 발생하면,
CIDR 10.0.0.0/16 (10.0.0.1 ~ 10.0.255.255) 아이피들은 local로 보내달라
다른 모든 대역들(0.0.0.0/0)는 인터넷 게이트웨이(igw-092d..)를 통해 바깥으로 보내달라

[WEB] 🌐 0.0.0.0/0 란 무엇인가?

 

VPC 내부(모든 Sunbet)에 대해서는 디폴트로 Routing이 자동으로 생성되어져 있다.

즉 별도의 설정 없이 한 Subnet에서 다른 Subnet으로 통신이 가능하다는 말이다.

위 그림에서 보듯이 Subnet 내의 모든 Resource는 자신이 소속된 Subnet이 아닌 다른 곳으로 향하고자 할 때 VPC Router를 거치게 된다.

 

아래 그림에서는 Subnet 10.0.3.0/25의 Routing table을 보여주고 있다.

VPC 대역인 10.0.0.0/16에 대해 Local Rouing이 지정되어 있음을 알 수 있다.

나머지 3개 Subnet도 해당 라우팅 테이블을 보유하고 있다.

이렇게 각 서브넷에 라우팅 테이블이 있음으로서, VPC 내 Subnet에 할당된 Resource라면 어느 Subnet이든 다른 Subnet의 Resource와 자유롭게 통신할 수 있게 된다.

 

또한 라우팅 테이블은 내부에서만 통신하는 Local Routing 뿐만 아니라 외부 인터넷망으로 나갈 수 있는 Routing을 가질 수 있다. 이를 인터넷 게이트웨어 (Internet Gateway)라고 한다.

---

인터넷 게이트웨이 (Internet Gateway)

VPC는 기본적으로 격리된 네트워크 환경이다. 따라서 VPC에서 생성된 리소스들은 기본적으로 인터넷을 사용할 수 없다.

 

이러한 환경에서, 인터넷 게이트웨이는 VPC의 인스턴스와 인터넷간에 통신을 할 수 있게 해준다.

인터넷 게이트웨이는 VPC의 리소스와 인터넷 간의 통신을 활성화하기 위해 VPC에 연결하는 관문이라고 이해하면 된다.

즉, VPC 리소스가 인터넷으로 나가기위한 통로이다.

인터넷으로 데이터를 보내야한다면 당연히 인터넷 게이트웨이로 트래픽을 전달해야 한다.

 

앞서서 위에서 서브넷을 private 2개, public 2개를 만들어 줬었다.

그런데 이름만 저렇게 한거고 실제로는 private 서브넷 4개를 만든 것이다.

서브넷을 진짜 퍼블릭용으로 바꾸기 위해선 인터넷 게이트웨이를 라우팅 테이블에 설정하고 등록해줘야 하기 때문이다.

이런식으로 서브넷이 인터넷 게이트웨이로 향하는 라우팅이 있는 경우 퍼블릭 서브넷이라고 부르게 되는 것이다.

반대로 어떤 서브넷이 인터넷 연결을 할 필요가 없다면 이 서브넷은 프라이빗 서브넷이라고 한다.

위 그림은 Custom route table에 igw-id(인터넷 게이트웨이)를 추가하고 Subnet 1(10.0.0.0/24)에 연결 시킴으로서, 이 VPC의 서브넷1은 퍼블릭 서브넷이 된 것을 표현한 것이다.

 

route table 적힌 의미를 알아보자

Destination에 10.0.0.0/16은 local 타겟으로 가라고 안내하고 있다.

이 말은 만일 10.0.0.6의 인스턴스로 오면 로컬에서 찾으라는 말이다. 그리고 아래에는 10.0.0.0/16 대역 이외의 모든 인터넷 트래픽(0.0.0.0/0) 은 인터넷 게이트웨이(igw)로 가라고 매핑 되어 있다.

 

VPC에서 Resource(EC2 등)가 외부 인터넷과 통신하고자 할 경우 갖추어야 할 조건이 있는데 다음과 같다.

1. Internet 통신하고자 하는 Resource가 공인 IP를 보유할 것
2. Resource가 소속된 Subnet의 Routing Table에 '0.0.0.0/0' 목적지로 갖는 Routing 'Internet Gateway'이 있을 것
3. Network ACL과 Security Group 규칙에서 허용할 것 (뒤에서 다룸)

---

인터넷 게이트웨이 만들기

 

 

vpc에 인터넷 게이트웨이 연결하기

 

 

퍼블릭용 라우팅 테이블 만들기

각 서브넷의 라우팅 테이블을 수정하여, 퍼블릿 서브넷은 외부와 통신할수 있게, 프라이빗 서브넷은 외부에서는 통신할수 없고 내부에서만 가능하게 라우팅 설정을 한다.

이렇게 설정하면,

기본(예)으로 생성된 서브넷들은 기본적으로 private-table을 사용해서 인터넷에 접근 못하는 보안성을 확보하고,

외부와 연결이 필요한 서브넷들만 따로 public-table을 추가로 만들어줘서 넣어주면 된다.

 

 

퍼블릭 라우팅 테이블에 서브넷 등록하기

이제 라우팅 테이블(public-table)에 퍼블릭 서브넷을 등록하기 위해서 편집을 누른다.

 

어느어느 서브넷을 외부 인터넷과 연결시킬지 public routing table에 등록을 한다.

 

 

라우팅 테이블에 인터넷 게이트웨이 연결하기

그리고 이제 public 라우팅 테이블에 인터넷 게이트웨이만 연결을 해주면 퍼블릭 서브넷 등록이 완료 된다.

라우팅 테이블 연결 설정을 맞췄으면 이제야 정말로 public 서브넷과 private 서브넷을 완성 시킨 것이다.

사진에서 보듯이 서브넷을 명시적으로 인터넷 게이트웨이를 연결한 라우팅 테이블에 등록함으로서 외부에 연결이 되게 되어, 인터넷 게이트웨이로 향하는 라우팅이 있는 경우 퍼블릭 서브넷 쪽으로 라우팅 테이블에 적혀있는대로 가는 것이다.

 

 

지금까지의 구축 과정을 그림으로 표현하면 다음과 같게 된다.

위 그림에서 Public Subnet 2개는 Local Routing과 함께 Internet Gateway에 연결되어 있으므로 내부와 Internet 통신이 가능하며 Private Subnet은 Local Routing만을 갖고 있으므로 내부 통신만 가능하다.

• 공인 인터넷과 통신 가능한 Subnet을 Public Subnet
• 공인 인터넷이 차단된 사설 IP만 할당된 Subnet을 Private Subnet
• Private Subnet은 IGW로 연결되어 있지 않음
• 인터넷 게이트웨이는 VPC 내부가 아닌 VPC와 외부의 통신에 관여함

---

# 참고자료

https://www.youtube.com/@AWSClassroom

https://kimjingo.tistory.com/172

https://aws-hyoh.tistory.com/entry/VPC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-1