VPC (Virtual Private Cloud) 구성 요소
전체적인 VPC 모델 지도이다.
생소한 용어들이 많지만 차근차근 배워보면 그렇게 복잡하지 않다.
VPC (Virtual Private Cloud)
위의 그림에서 보면 알 수 있듯이 AWS Cloud 내에는 IDC의 집합인 'Region'이 존재하며 Region은 2개의 'Availability Zone(AZ)'으로 이루어져 있다. 그중에서 VPC는 Region에 상응하는 규모의 네트워크라는걸 그림을 통해 알 수 있다.
Tip
IDC는 ‘인터넷 데이터 센터’(Internet Data Center)의 준말로, 인터넷 연결의 핵심이 되는 서버를 한 데 모아 집중시킬 필요가 있을 때 설립하는 시설을 말한다.
즉, VPC는 독립된 하나의 네트워크를 구성하기 위한 가장 큰 단위이다.
그리고 VPC는 Region에 하나씩 이다. 다른 Region과 걸쳐서 확장이 불가능하다.
VPC는 각 region에 종속되며 RFC1918Visit Website이라는 사설 IP 대역에 맞추어 설계해야 한다.
VPC에서 사용하는 사설 IP 대역은 아래와 같다.
Info
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 간에 트래픽을 라우팅할 수 있도록 설정할 수 있다.
서브넷 (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개를 사용을 못한다고 이해하면 된다.
Info
예를들어 이런 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은 외부에 노출이 되어 있지 않기 때문에 접근할 수 없다.
Tip
인바운드 : 외부에서 - > 인스턴스로 오는 트래픽
아웃바운드 : 인스턴스에서 - > 외부로 가는 트래픽
그래서 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
라우팅 테이블 (Routing Table)
각각의 Subnet은 서로 다른 네트워크 영역을 가지고 있다. 따라서, 한 Subnet이 다른 Subnet으로 가기 위해서는 'Routing'이 필요하게 된다.
라우팅 테이블은 VPC 안에서 발생한 네트워크 요청을 처리하기 위해 어디로 트래픽을 전송해야 하는지 알려주는 표지판 역할을 수행한다.
각 서브넷들은 이러한 네트워크 트래픽 전달 규칙에 해당하는 라우팅 테이블을 가지고 있으며, 요청이 발생하면 이 라우트 테이블을 사용해서 목적지를 찾게 되는 것이다.
Info
[위 라우팅 테이블의 뜻]
트래픽이 발생하면,
CIDR 10.0.0.0/16 (10.0.0.1 ~ 10.0.255.255) 아이피들은 local로 보내달라
다른 모든 대역들(0.0.0.0/0)는 인터넷 게이트웨이(igw-092d..)를 통해 바깥으로 보내달라
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 등)가 외부 인터넷과 통신하고자 할 경우 갖추어야 할 조건이 있는데 다음과 같다.
- Internet 통신하고자 하는 Resource가 공인 IP를 보유할 것
- Resource가 소속된 Subnet의 Routing Table에 '0.0.0.0/0' 목적지로 갖는 Routing 'Internet Gateway'이 있을 것
- Network ACL과 Security Group 규칙에서 허용할 것
