AWS 기본 개념

VPC의 개념

• VPC(Virtual Private Cloud)는 사용자가 정의하는 가상의 네트워크
• VPC를 통해 인스턴스가 속하는 네트워크를 구분하여 각 네트워크에 맞는 설정을 부여할 수 있음
  • 만일 VPC 없이 인스턴스를 생성한다면 인스턴스끼리의 구분없는 연결로 인해 시스템 복잡도가 증가할 것
  • 또한 인터넷을 통해 전달되는 트래픽의 전송이 굉장히 비효율적이게 될 것

• VPC를 적용하면 인스턴스가 VPC에 속함으로써 네트워크를 구분할 수 있고 VPC 별로 필요한 설정을 통해 인스턴스에 네트워크 설정을 적용할 수 있음
  • AWS는 VPC의 중요성을 강조하여 2019년부터 모든 서비스에 VPC를 적용하도록 강제하였음
  • 만일 지금까지 VPC를 한번도 만들어 보지 않고 인스턴스 생성을 했다면 AWS에서 제공하는 default VPC에 인스턴스가 배치되어 있을 것

VPC의 구성 요소 및 구축 과정

VPC

• 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)

• 각 대역폭마다 고정되어있는 prefix가 다름
  • IPv4 주소인 xxx.xxx.xxx.xxx에서 .으로 구분된 xxx은 0~255 사이의 숫자이며 이는 8bits로 표현할 수 있음
    • 즉 1번은 00001010~, 2번은 0101100.0001~, 3번은 11000000.10101000~가 앞에 고정되어 있고 나머지 주소 범위에 해당하는 IP 주소를 할당할 수 있음
    • 예를 들어 10.0.0.0/16으로 설정된 IP 대역폭은 총 65,536개의 프라이빗 IPv4 주소를 가짐

• VPC에서 한번 설정된 IP 대역은 수정할 수 없으며 각각의 VPC는 독립적이기 때문에 서로 통신할 수 없음
  • 만일 통신을 원한다면 VPC 피어링 서비스를 통해 VPC 간에 트래픽을 라우팅할 수 있도록 설정할 수 있음

Subnet

• 서브넷(Subnet)은 VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위를 뜻함
  • VPC를 잘게 나눈 것이 서브넷이기 때문에 VPC보다 대역폭이 낮으며 하나의 AZ(Availability Zone)에 하나의 서브넷이 연결되기 때문에 region의 AZ 수를 미리 확인하고 설정해야함

• 서브넷은 다시 public Subnet과 private Subnet으로 나뉠 수 있음
  • 인터넷과 연결되어있는 서브넷을 public subnet이라고 하고 인터넷과 연결되어있지 않은 서브넷을 private subnet이라고 함
    • 이처럼 인터넷 연결 여부로 subnet을 구분하는 이유는 보안을 강화하기 위함
  • public subnet에 존재하는 인스턴스는 인터넷에 연결되어 아웃바운드, 인바운드 트래픽을 주고받을 수 있음
  • 반면 private subnet은 외부에 노출이 되어 있지 않기 때문에 접근할 수 없음
    • 즉 인터넷과 연결되어 외부에 노출되어 있는 면적을 최소화함으로써 네트워크 망에 함부로 접근하는 것을 막기 위함

Router

• 라우터(Router)는 VPC 안에서 발생한 네트워크 요청을 처리하기 위해 어디로 트래픽을 전송해야 하는지 알려주는 표지판 역할을 수행
  • 각각의 서브넷은 네트워크 트래픽 전달 규칙에 해당하는 라우팅 테이블을 가지고 있으며 요청이 발생하면 가장 먼저 라우터로 트래픽을 전송
    • 일반적으로 VPC 내부 네트워크에 해당하는 주소는 local로 향하도록 함

Internet Gateway

• 인터넷 게이트웨이(Internet Gateway, IGW)는 VPC 리소스와 인터넷 간 통신을 활성화하기 위해 VPC에 연결하는 게이트웨이
  • 앞서 설명했듯 public subnet만 외부와 통신해야 하므로 public subnet의 라우팅 테이블에만 인터넷 게이트웨이로 향하는 규칙을 포함
  • 아래 그림과 같이 라우팅 규칙을 설정하면 네트워크 요청 발생 시 목적지의 IP 주소가 10.0.0.0/16(VPC 내부)에 해당하는지 확인
    • 해당하지 않는 모든 트래픽은 인터넷 게이트웨이를 통해 외부로 전송되어 목적지를 찾음

NAT Gateway

• public subnet만 인터넷 게이트웨이를 통해 외부와 트래픽을 주고받을 수 있다면 private subnet의 트래픽은 무조건 VPC 안에서만 처리된다는 뜻일까?
  • private subent 역시 마찬가지로 인터넷과 통신할 수 있지만 private subnet에서 직접하는 것은 불가능하므로 트래픽을 public subnet에 속한 인스턴스에 전송해서 인터넷과 통신을 해야 하는데 NAT 게이트웨이가 이 역할을 수행

• private subent에서 발생하는 네트워크 요청이 VPC 내부의 주소를 목적지로 하는 것이 아니라면 public subnet에 존재하는 NAT로 트래픽을 전송
  • 트래픽을 받은 NAT는 public subnet의 라우팅 규칙에 따라 처리함으로써 private subnet이 인터넷과 통신할 수 있도록 함

네트워크 액세스(ACL) 제어 목록

• ACL은 1개 이상의 서브넷 내부와 외부 트래픽을 제어하기 위한 방화벽 역할
  • EC2에서도 보안그룹(Security Group)을 생성할 수 있듯이 VPC에서도 보안을 생성할 수 있는데 그것이 ACL

• 보안그룹 (Security Group)
  • 인스턴스 레벨에서 운영
  • 허용 규칙만 지원 (어떤 ip 대역을 허용할지)
  • 인스턴스 시작 시 지정하거나 보안 그룹을 나중에 인스턴스와 연결해야 적용됨

• 네트워크 ACL
  • 서브넷 레벨에서 운영
  • 허용 규칙과 거부 규칙 지원
  • 연결된 서브넷의 모든 인스턴스에 자동 적용

• 상단 네모칸은 네트워크 ACL 설정
  • 172.31.1.2/32라는 특정 ip만 제외하고 다른 모든 트래픽은 막아놓았음
    • 즉, 저 서브넷은 172.31.1.2/32 한 개의 ip만이 접근 가능
  • 아웃바운드 규칙도 보니 그 특정 ip를 제외하고는 트래픽이 나갈수조차 없음
• 이에 반해 하단 네모칸의 인스턴스의 보안그룹 규칙을 보면 SSH 연결은 그 ip가 허용이 되어있고 모든 트래픽이 허용
  • 즉, 저 서브넷 안에서 누구와도 통신이 가능한것으로 보이네요.
  • 다시 말해 서브넷 내부와 자유롭게 통신을 할 수 있고 외부는 원천 차단하는(특정 ip 제외) 그림

VPC Endpoint

• VPC 엔드포인트(VPC Endpoint, Private Link)는 인터넷 게이트웨이나 NAT 게이트웨이와 같은 다른 게이트웨이 없이 AWS 서비스와 연결하여 통신할 수 있는 private connection을 제공하는 서비스
  • private link를 통해 AWS 서비스와 연결함으로써 데이터를 인터넷에 노출하지 않고 바로 접근할 수 있음
  • 또한 연결하는 서비스의 IP 주소를 바꾸는 등 네트워크 정보의 변경 등의 작업에서 불필요하게 발생하는 비용을 줄일 수 있음

VPC 피어링 (Peering)

• VPC 피어링은 두 VPC 간에 트래픽을 라우팅할 수 있도록 만들어줌
  • 동일한 네트워크에 속하는 경우 혹은 다른 리전 간의 VPC에서도 피어링이 가능

• 게이트웨이나 VPN 커넥션과 상관이 없고 Single Point of Failure나 대역폭 병목도 문제 없음
• AWS 계정이 두 개 이상인 경우 두 계정 리소스간 통신이 필요한 경우 사용할 수 있음