• 독립된 네트워크 환경을 구성할 수 있는 VPC
• 논리적으로 격리된 공간을 프로비저닝하여 고객이 정의하는 가상 네트워크에서 AWS 리소스를 시작할 수 있다.
• 클라우드 위에서 생성한 리소스들(EC2, RDS...)들은 기본적으로 네트워크를 통해서 접근한다. 이때, 하나의 계정에서 생성하는 리소스들만의 격리된 네트워크를 만들어주는 기능이 VPC
  • VPC를 사용하면 특정 사용자의 리소스들이 논리적으로 격리된 네트워크에서 생성되기 때문에 다른 사람들은 접근하는 것은 물론 보는 것도 불가능하다.
    
• 반드시 인스턴스가 속할 하나의 VPC를 지정해야만 한다.
• 서브넷도 VPC 리소스 중 하나
  • 서브넷은 VPC에 속해있는 리소스이며, 하나의 인스턴스에는 반드시 하나의 서브넷에 속해야한다.

기본 VPC의 구성요소들

• 1 VPC
• n Subnet
• 1 Route table
• 1 Security Group
• 1 Internet Gateway
• 1 DHCP optionsets

VPC

• 논리적인 독립 네트워크를 구성하는 리소스
  • 물리적으로 다른 네트워크를 가지고 있는 인스턴스들을 논리적으로 같은 네트워크를 갖고 있는 것처럼 해준다.
  • 완전히 논리적이고 독립적인 네트워크
  • 서브넷은 VPC 네트워크를 잘게 쪼개는 것 뿐 ( 서브넷에 해당하여 가용존이 들어가진다. )
• 이름과 IPv4 CIDR블록을 필수적으로 가진다.

CIDR

• IP 의 범위를 지정하는 방식
• IP 주소와 슬래시( / )뒤에 따라오는 서브넷 마스크 비트 수로 구성되어 있다.
• 192.168.0.0/32 → Subnet Mask : 255.255.255.255 → 즉 호스트를 1개도 사용할 수 없음
• 192.168.0.0/24 → Subnet Mask : 255.255.255.0
  • [ 192.168.0 ] . [ 0 ]
  • Network . Host
  • 2^8 - 2 개의 호스트 사용 가능
  • 0000/0000 → Route Host , 1111/1111 → Broad Cast
• 클라우드에서 생성하는 자원들은 기본적으로 특정 네트워크 위에서 생성되고 이에 접근하기 위한 Private IP 를 가집니다.
  • 이 리소스들은 특정한 VPC 위에서 만들어집니다.
  • VPC 의 CIDR 범위 안에서 적절한 IP 를 할당받게 된다.
    • 192.168.0.0/24 → 192.168.0.17 이라는 IP를 할당받을 수 있다.

고려해야할 점

• 52.12.0.0/16 을 CIDR 블록으로 지정한 경우
• 이 VPC에서 52.12.0.0/16 로 접속하는 트래픽은 VPC 내부로 라우트된다.
• 하지만 이 범위의 IP(52.12.0.0/16)는 인터넷에서 사용할 수 없는 IP
• 따라서 이 VPC에서는 52.12.0.0/16 에 속한 IP에 접근하는 것이 원천적으로 불가능
• 인터넷 연결이 필요한 경우 반드시 사설망 대역을 사용, 필요하지 않더라도 권장
  10.0.0.0/8 , 172.16.0.0/12 , 192.168.0.0/16

Subnet Mask

• Subnet Mask 에 의해 Network / Host 부분을 나눌 수 있다.
• 129.35.4.7 [ subnet mask : 255.255.0.0 ] → Network : 129.35.0.0 / Host : 129.35.0.0 ~ 129.35.255.255 ( 2개 뺼 것 )

서브넷

• VPC만 가지고는 아무것도 할 수 없다.
• VPC는 다시 한 번 CIDR블록을 가지는 단위로 나뉘어진다.
  ( VPC도 CIDR블록을 가지는 단위를 갖고 있다. )
• 서브넷은 실제로 리소스가 생성되는 물리적인 공간인 가용존( Available Zone )과 연결된다.
• VPC가 논리적인 범위 / 서브넷은 VPC 안에서 실제로 리소스가 생성될 수 있는 네트워크
• 하나의 VPC는 N개의 서브넷을 가질 수 있다.
• 서브넷의 넷마스크 범위는 16(65535개) 에서 28(16개)를 사용할 수 있으며 VPC CIDR 블럭 범위에 속하는 CIDR 블럭을 지정할 수 있습니다.
• 하나의 서브넷은 하나의 가용존과 연결된다. ( 최소 )
  • 하나의 가용존 내부에 여러 개의 서브넷이 존재할 수 있다. ( 하나의 가용존 내부에 여러 개의 네트워크를 나누는 것 )

Public Subnet

• 라우트 테이블에 IG 가 연결되어 있는 서브넷

Private Subnet

• 라우트 테이블에 IG가 연결되어 있지 않는 서브넷
• 직접 접근 불가 → SSH 로 접근이 안된다 ( Security를 열어놓아도 )
  • Internet Gateway 연결이 되어 있지 않음

라우트 테이블

• 서브넷과 연결되어 있는 리소스
• 서브넷에서 네트워크를 이용할 때는 이 라우트 테이블을 사용해서 목적지를 찾게 된다.
• 이 라우트 테이블은 VPC에 속한 서브넷을 만들 때 기본 라우트 테이블로 사용된다.
• 하나의 라우트 테이블은 VPC에 속한 다수의 서브넷에서 사용 가능
• 자동 생성되는 라우트 테이블에는 한 가지 룰만이 정의되어 있다.
  • VPC의 CIDR 블럭을 목적지로 하는 경우, 타깃이 local인 규칙
  • 예를 들어 VPC의 CIDR 이 172.31.0.0/16 이고
  • 이 네트워크 안에서 목적지가 172.31.0.0/16 범위에 있는 리소스를 찾는다면 VPC 내부에서 찾는다.

인터넷 게이트웨이

• VPC는 기본적으로 격리된 네트워크 환경
• 따라서 VPC에서 생성된 리소스들은 기본적으로 인터넷을 사용할 수 없다.
• 인터넷에 연결하기 위해서는 인터넷 게이트웨이가 필요
• 라우팅 테이블에 인터넷 게이트웨이를 향하는 적절한 규칙을 추가해주면 특정 서브넷이 인터넷과 연결된다.
  • 서브넷과 인터넷 게이트웨이를 연결하는 것만으로는 인터넷을 사용할 수 없다.
  • 인터넷을 사용하고자 하는 리소스는 퍼블릭 IP를 가지고 있어야 한다.

DHCP Options set

• TCP/IP 네트워크 상의 호스트로 설정 정보를 전달하는 DHCP 표준
• DNS, 도메인 네임, NTP, NetBIOS 서버등의 정보를 설정할 수 있다.
• 일반적으로 VPC 생성 시 만들어지는 DHCP 옵션셋을 그대로 사용

Network ACL vs Security Group

NetworkACL

• Inbound port를 열어주어야 Outbound port가 허용됩니다!
• 서브넷 앞단에서 트래픽을 제어
• Stateless → inbound rule 이 변경되도 outbound rule 은 변경되지 않는다.
  • inobund 로 80번 포트를 열었다면 outbound로도 80번 포트를 열어주어야 한다.
• inbound / outbound traffic을 제어하는 가상 방화벽
• 하나의 Network ACL은 다수의 서브넷에서 재사용가능

Security Group

• 인스턴스 앞단에서 트래픽을 제어
• Stateful → inbound rule의 변경이 적용되면 자동으로 outbound rule도 적용된다
  • inbound 로 80번 포트를 열었다면 → outbound 도 자동으로 80번 포트를 연다

NAT gateways

• private subnet 내부에 있는 Instance가 인터넷에 접속할 수 있게끔 해준다
• 하지만 private subnet으로 접속하는 인터넷은 막는다.

출처
만들면서 배우는 아마존 VPC(Amazon VPC) 입문: AWS 네트워크의 기초
NAT gateways