AWS_VPC(Virtual Private Cloud) I

1. 개념

 AWS 계정 전용 네트워크를 만들기 위한 격리된 공간. IPv4, v6 모두 사용 가능하며, *CIDR표기법을 통해 어떤 주소를 사용할 것인지 설정 가능. 인바운드/아웃바운드 엑세스 규칙으로 보안을 방화시킬 수 있다. 전용 네트워크를 '서브넷'이라고 부른다. 리전 내의 모든 가용영역이 VPC에 포함되기 때문에 가용영역을 선택할 수가 없다. 단, VPC에서 '서브넷'을 생성할 시 가용영역을 선택 할 수있다. VPC의 범위는 리전, 서브넷의 범위는 가용영역이다. 그렇기 때문에 VPC 자체는 네트워크라고 부를수가 없고, '네트워크를 만들기 위해 만들어진 격리된 공간' 정도로 생각하면 된다. 

"서브넷을 실제 네트워크라고 생각하면 편하다!"

 

*CIDR(Classless Inter-Domain Routing) 표기법 : Prefix 표기법. ex>/16, /24

2. 특징 

 - AWS Cloud의 사설 네트워크 공간 제공

 - 작업 대상에 대한 논리적 격리 제공 = 서로 다른 VPN간 통신 불가!

 - 자원에 대한 엑세스 제어(Access Control) 및 보안설정 가능

 - 리전당 최대 5개까지 VPC를 사용할 수 있다(소프트 제한). 단, 제한을 풀어 다른 리전에 생성도 가능

 - 각 VPC는 사용자가 지정하는 Private IP 주소의 범위를 예약

 - 이 Private IP 주소들은 VPC 안에 있는 서브넷에 생성된 인스턴스에 할당(DHCP 가동중)

 

3. VPC 추천 갯수

1) VPC 한개

 : VPC간에 통신이 네트워크 간 거리가 멀어지기 때문에 통신 속도가 떨어진다. 때문에 속도에 민감한 인프라일때는 VPC가 한 개일때가 좋다.

 ex> 한명 또는 매우 작은 팀이 관리하는 소규모 단일 개발, 고성능 컴퓨팅 , 자격 증명 관리

2) 2개 이상의 VPC

 i) 다중 VPC : 한개의 계정에 여러개의 VPC. 단일 팀이거나 단일 서비스를 제공하는 경우 적합. 하지만 회사의 크기가 커질수록 한계가 뚜렷해진다. 만일 특정 인스턴스를 보고싶다면 모든 인스턴스중에서 직접 필터링하여 찾아내야만 한다. 또한 권한의 경계가 모호해 제대로된 제어가 민감해야 한다. 비용에 대한 구분도 모호

 ii) 복수 계정 VPC : 대규모 조직 및 여러 팀이 있는 조직에 적합. 계정당 VPC를 가지기 때문에 권한, 비용에 대한 구분이 명확하다. 작업환경 역시 계정마다 인스턴스가 구분되어 있기 때문에 구분이 수훨. 하지만 계정 관리에 능숙치 못하다면 사고날수도 있다.

 

 *Organizations : 다중 계정 환경에서 불편했던 점을 해결해주는 서비스. 다중 계정을 관리해주는 Root 계정을 생성하고, 이 계정이 통합 결제, 휘하 계정에 대한 권한관리도 가능. 

3. Subnet

 - 가용영역을 묶어 하나의 서브넷으로 만들수는 없다. 단, 가용영역 내에 서브넷을 여러개 만들 수 있다.

 - 각 서브넷당 5개의 주소가 선 예약된다.

         > Network / BroadCast / DNS / Routing / Spare

 1) 라우팅 테이블

 - VPC 리소스간 트래픽을 연결하는데 필요

 - 기본 라우팅은 VPC 생성 시 자동 생성되며 모든 서브넷들은 기본적으로 기본 라우팅 테이블에 적재된다.

 - 물론 사용자가 새로운 라우팅 테이블을 생성 가능

 - 동일한 VPC에서 만들어진 서브넷들은 ACL이 아니면 기본적으로 서로 통신 가능

   => 특정 VPC에서 만들어지는 라우팅 테이블은 VPC 네트워크 정보(배포할 IP 테이블)가 적재되어 있다.

 - Private Subnet과 Public Subnet 구분 : 게이트웨이의 유무 차

 2) Public Subnet

 - 인터넷에서 누구나 접근 가능한 Subnet

 - 인바웃, 아웃바운드 엑세스를 지원하도록 게이트웨이를 라우팅 테이블 항목에 포함

 3) Private Subnet

 - 인터넷에 공개되어 있지 않아 접근할 수 없는 Subnet

 - 외부와 연결되어 있지 않기 때문에 게이트웨이의 존재 X

 - 단, 인터넷과 연결이 필요한 경우에는 Public Subnet에 NAT 서버를 만들어 이 정보를 Private Subnet 라우팅 테이블에 등록 후 사용하면 된다.

*Subnet을 생성 후, 그 Subnet의 라우팅 테이블에 게이트웨이를 등록하면 Public Subnet이 된다. 그냥 놔두면? Private

 4) Internet Gateway

 - VPC를 생성 시, Public Subnet이 생성될 예정이라면 게이트웨이 장비를 생성 후, 해당 Subnet의 라우팅 테이블에 적재

 - 기본적으로 가용성이 매우 뛰어나며 중복적이며 수평적으로 확장하면 된다. 

 5) NAT Gateway

 - Private Subnet에서 인터넷 통신이 요구될 때 사용하는 장비

 - 인터넷 중계를 해주기 때문에 Public Subnet에 생성되어야 한다. 

 - Private Subnet 라우팅 테이블에 NAT 게이트웨이에 대한 정보가 적재되어 있어야 질의가 가능하다. 

 - 존재만으로 비용이 추가되며, 트래픽 처리 건수에도 비용이 추가되지만 AWS에서 관리하여 다운될 위험이 전혀 없다.

 - NAT Gateway가 부담스럽다면 인스턴스를 생성하여 NAT Server을 직접 구축하면 된다. 관리 필요(ex>Linux Iptables)