[AWS] VPC

 

VPC (Virtual Private Cloud)

• AWS 전용 가상 네트워크이다. VPC는 AWS클라우드에서 다른 가상 네트워크와 분리되어있다.
• VPC를 이용하면 사용자가 정의한 가상 네트워크로 AWS리소스를 시작할 수 있다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사하다.
• IP주소 범위와 VPC범위를 정하고, 서브넷을 추가해 보안그룹을 연겨한 뒤 라우팅테이블을 구성한다.
• VPC가 없다면 EC2 인스턴스들은 서로 연결되고 인터넷과 연결된다. 이런 구조는 시스템 구조를 복잡하게 하고 인스턴스를 하나만 수정해도 다른 인스턴스들까지 수정해야하는 경우들이 생긴다.
• VPC를 적용하면, VPC별로 네트워크를 구성할 수 있다. 또 각각의 VPC에 따라 다르게 네트워크를 설정할 수 있다.이 각각의 VPC는 독립된 네트워크처럼 사용된다.

VPC 생성

 

• VPC 이름을 정한다.
• IPv4 CIDR블록을 작성해준다. 이는 사설 IP가 입력된다.

VPC에서 사용하는 사설 IP

• 10.0.0.0 ~ 10.255.255.255(10/8 prefix)
• 172.16.0.0 ~ 172.31.255.255(182.16/12 prefix)
• 192.168.0.0 ~ 192.168.255.255(192.168/16 prefix)
• 한 번 설정된 IP대역은 수정할 수 없고 각 VPC는 하나의 리전에 종속된다. VPC간 통신을 하려면 피어링 서비스 참고

서브넷 생성

 

• VPC를 생성하게된다면 서브넷을 생성할 수 있게 된다.
• 서브넷은 VPC를 나눠준다고 생각하면 된다. 즉, VPC안에 작은 단위들이다.
• 적은 단위이기 때문에 일전에 VPC를 생성했던 IP보다 더 범위가 작은 IP를 가지게 된다.
• 서브넷을 나눔으로써 더 많은 네트워크망을 만들 수 있게된다.

Public Subnet

• 인터넷 게이트웨이, ELB, Public IP/Elastic IP를 가진 인스턴스를 내부에 가지고 있다.
• NAT Instance를 통해 Private Subnet에 있는 인스턴스가 인터넷이 가능하게도 만들어준다.

Private Subnet

• 말그대로 기본적으로 외부와 차단되어 있다.Private IP만을 가지며, 인터넷(인바운드/아웃바운드)가 불가능하고 오직 다른 서브넷과의 연결만 가능하다.

라우팅 테이블 생성

• IP주소에 라우팅 경로를 정의해 서브넷 밖으로 가는 아웃바운드 트래픽에 대한 라우팅 경로를 설정한다.
• 네트워크 요청이 생기면 데이터는 라우터로 간다. 이는 목적지이며 목적지를 향하는 이정표이기도 하다.
• 즉, 이를 설정하게 되면 설정한 라우팅 테이블에 따라 작동하게된다.
• Public Subnet을 위한 라우팅테이블과 Private Subnet을 위한 라우팅 테이블각각 설정 가능하다.
• 라우팅 테이블을 생성한 뒤에 기존에 생성햇던 서브넷 중에 Public Subnet을 연결시켜줘야 한다.(명시적 연결)
• 이때 Public이기 때문에 Route를 0.0.0.0/0 (모든 네트워크) 를 열어준다.
• Private Subnet또한 기본 생성과정은 같다. 하지만 Route를 0.0.0.0/0이 아닌 인스턴스의 IP를 넣어준다.

인터넷 게이트웨이

• VPC와 인터넷을 연결시켜주는 역할
• 콘솔에 인터넷 게이트웨이를 생성한 뒤에 해당하는 VPC를 연결시켜주면 된다.
• 인터넷 게이트웨이가 연결된 서브넷을 Public Subnet, 그렇지 않은 서브넷을 Private Subnet이라고 한다.

네트워크 ACL

• 방화벽의 역할을 지니고 있다.
• 여기서 인바운드/아웃바운드 트래픽의 보안정책을 설정이 가능하다.
• 초기에는 기본세팅이 되어있고 필요한 설정에 따라 변경해줘야 한다.
• EC2에 있는 보안그룹과는 조금 차이가 있다.
  • 보안그룹
    • 인스턴스 기준 (1차 계층)
    • 룰에 대한 허용 규칙만 지원
    • 아웃바운드 요청에 대한 응답 자동 허용
    • 등록된 모든 규칙을 평가해 트래픽 허용
    • 특정 그룹을 지정시에만 인스턴스에 적용된다.
  • ACL
    • 서브넷 기준 적용(2차 계층)
    • 룰에 대한 허용 및 거부 규칙 지원
    • 아웃바운드 요청에 대한 응답 규칙 정의 필요
    • 등록된 규칙의 번호순으로 트래픽 허용 및 거부
    • 설정된 서브넷 하단의 모든 인스턴스에 자동 적용된다.
• 참고
  • 다수의 Linux 커널(Amazon Linux 커널 포함)이 포트 32768-61000 사용
  • Elastic Load Balancing에서 시작된 요청은 포트 1024-65535 사용
  • Windows Server 2003까지의 Windows 운영 체제에서는 포트 1025-5000을 사용
  • Windows Server 2008 이상 버전은 포트 49152-65535를 사용
  • NAT 게이트웨이는 포트 1024 - 65535를 사용
  • AWS Lambda 함수는 포트 1024-65535를 사용

NAT 게이트웨이

• 위에서 설명했듯 NAT 게이트웨이는 Private Subnet이 인터넷과 통신하기위한 아웃바운드 인스턴스이다.
• Private외부에서 요청되는 인바운드는 필요없더라도 아웃바운드 트래픽만 허용되어야 할 때가 있다. (업데이트 등등..)
• 이때 Public서브넷 상에서 작동하는 NAT게이트웨이는 Private 서브넷에서 외부로 요청하는 아웃바운드 트래픽을 받아 인터넷 게이트웨이와 연결하게 된다.