메뉴

문서정보

AWS VPC 구성

목차

개요

VPC 소개

AWS VPC를 이용하면, AWS region에 논리적인 가상의 네트워크를 만들 수 있다. Public network상에 private network를 구축하도록 지원하는 서비스라고 보면 되겠다. 이 가상의 네트워크에서 유저는 IP 주소, 서브넷, 라우팅 테이블, 인터넷 게이트웨이 등을 자유롭게 구성할 수 있다.

VPC 의 장점

VPC 구성요소 정리

VPC를 자세히 설명하기 전에 VPC의 구성요소들을 살펴볼 필요가 있을 것 같아서, 그림으로 정리했다.

Subnets

네트워크 Subnet의 그 Subnet이다. VPC를 만들면 10.0.0.0/16 주소가 할당되는데, 관리자는 이 16비트 주소를 subnet으로 나눠서 사용할 수 있다.

10.50.0.0/16 네트워크를 가지는 VPC를 만들었다면 이런식으로 subnet을 나눌 수 있다.

Public subnet

인터넷으로 연결되는 서브넷이다. 라우팅 테이블에 Internet Gateway가 있다면, Public subnet이 된다. Public subnet에 생성된 인스턴스에 EIP를 할당하면, 인터넷에서 인스턴스로 접근할 수 있다.

Private subnet

인터넷에서 격리된 서브넷이다. Public subnet과 별다른 차이가 있는건 아니다. 라우팅 테이블에 Internet Gateway로 향하는 경로가 없다면, private subnet이다. private subnet의 instance는 EIP를 가지더라도 인터넷에서 접근할 수 없다.

Route Tables

VPC를 만들면 가상의 Router가 만들어진다. 관리자는 Route Tables를 수정해서 트래픽 흐름을 제어할 수 있다. 예를들어 private subnet에 생성된 인스턴스들은 인터넷에서의 접근은 불 가능하지만, 인터넷으로는 나갈 수 있어야 한다. Public subnet에 NAT 인스턴스를 두고 0.0.0.0/0 트래픽을 NAT로 보내도록 Route tables을 추가하는 것으로 인터넷에 접근하도록 할 수 있다. OpenVPN등의 VPN 소프트웨어를 이용해서 VPN으로 연결도 route tables을 조작해서 설정할 수 있다.

VPC를 활용하기 위한 가장 중요한 요소라 할 수 있다.

Internet Gateway

인터넷으로 트래픽을 보내기 위한 게이트 웨이다. Route Tables에 Internet Gateway가 있는지 없는지에 따라서 Public subnetPrivate Subnet으로 구분된다. Inter Gateway는 IGW라고 부르기도 한다.

VPC 구성

단일 네트워크 구성

하나의 Public subnet을 가지는 단순한 구성이다.

"네트워크와 시스템에 대한 최소한의 지식만 가지고 있어도 인프라를 구성할 수 있다"는게 AWS의 장점이긴 하지만, VPC의 경우에는 좀 다르다. 상당한 수준의 네트워크 지식을 가지고 있어야 제대로 활용할 수 있다.

만약 아직 VPC를 제대로 활용할 만한 지식을 가지고 있지 않다면, 하지만 VPC 환경의 장점을 사용하고 있다면 초기에는 하나의 public subnet을 가지는 구조로 시작하는 것도 괜찮다. 하나의 구조로 시작한 후 VPC(그리고 네트워크에 대한)관리 경험이 쌓이면 그때, 다층 네트워크 구조로 확장하면 된다.

물리적인 인프라라면, 초기의 네트워크 구조를 바꾸는게 굉장히 어렵겠지만 AWS의 VPC는 간단히 변경할 수 있다.

다층 네트워크 구성

나는 다층 네트워크 구성을 만들 것이다. 즉 2개 이상의 subnet을 가지는 네트워크를 만든다. 나는 총 5개의 subnet으로 이루어진 VPC 네트워크를 설계할 것이다.

Private subnet와 public subnet

VPC를 만들면 16bit 크기의 서브넷을 할당 받는다. 이 서브넷을 VPC subnet이라고 하겠다. 유저는 VPC subnet에 다시 여러 개의 subnet을 만들 수 있다. 이 subnet은 크게 private subnet과 public subnet으로 나눌 수 있다.

Private subnet과 pubic subnet은 단지 라우팅테이블에 igw(internet gateway)로 향하는 라우팅룰이 있는지 없는 지로 결정한다. 만약 해당 서브넷의 라우팅테이블이 igw로 향한다면, 이 서브넷에 있는 인스턴스들은 EIP를 붙이는 것으로 인터넷으로 패킷을 직접 보낼 수 있다. igw로 향하는 룰이 없는 private subnet은 당연히 인터넷으로 패킷을 보낼 수가 없다. AWS는 Private subnet의 인스턴스에 EIP를 붙이는 것을 허용하긴 하지만, 붙여봤자 외부에서 접근할 수 없다.

결국 public subnet은 인터넷에 직접 연결해야 하는 인스턴스를, private subnet에는 인터넷으로 부터 숨겨야 하는 인스턴스를 배치할 수 있다.

가용성 존 구성

간단한 다층 네트워크 구성은 하나의 public subnet과 하나의 private subnet으로 구성할 수 있다. 하지만 다른 목적으로 좀 더 많은 subnet 구성이 가능하다. 나는 가용성존(Availability zone)을 구성하기 위해서 2개씩의 public subnet과 private subnet을 만들었다.

이렇게 구성하면 하나의 zone에 문제가 생기더라도 다른 zone을 이용해서 서비스를 할 수 있다. AWS에서 하나의 zone에 문제가 생기는 경우는 드물지 않으므로 가용성이 필요한 서비스는 반드시 가용성존 구성을 해줘야 한다.

NAT subnet 구성

Private subnet에 있는 인스턴스들이 인터넷으로 패킷을 보내야할 경우가 있을 수 있다. 패킷 업데이트 혹은 외부로 로그/데이터 전송, 외부로 부터의 인증 등의 경우다. Private subnet의 인스턴스는 EIP를 가질 수 없으므로, public subnet에 별도의 NAT 인스턴스를 만들어야 한다.

NAT 인스턴스는 마스커레이딩(SNAT)을 할 수 있는 리눅스 인스턴스를 만들어서 EIP를 붙여주면 된다. NAT 인스턴스는 public subnet 어디에 있어도 상관은 없지만, 다른 인스턴스와는 특성이 좀 다르므로 따로 subnet을 만들기로 했다.

트래픽 흐름은 대략 아래와 같을 것이다.

  1. VPC routing 테이블에 0.0.0.0/0으로 향하는 패킷을 NAT instance로 향하도록 룰을 추가한다.
  2. Private subnet 인스턴스에서 0.0.0.0/0으로 향하는 패킷은 라우터에 의해서 NAT instance로 향한다.
  3. NAT instance는 SNAT 한 후 igw로 패킷을 보낸다.
  4. igw로 향한 패킷은 EIP로 다시한번 SNAT 한후 인터넷으로 향한다.

라우팅 테이블

라우팅 테이블을 구성해보자 대략 다음과 같을 것이다.

Public subnet의 routing 테이블
10.10.0.0/16 local VPC 내부로 향하는 트래픽
0.0.0.0/0 igw Internet으로 향하는 트래픽
10.10.10.0/24 와 10.10.15.0/24 subnet이 이 routing 테이블의 멤버가 된다.

NAT subnet의 routing 테이블
10.10.0.0/16 local VPC 내부로 향하는 트래픽
0.0.0.0/0 igw Internet으로 향하는 트래픽
10.10.100.0/24 subnet이 이 routing 테이블의 멤버가 된다..

Private subnet의 rougint 테이블
10.10.0.0/16 local VPC 내부로 향하는 트래픽
0.0.0.0/0 NAT instance 인터넷으로 향하는 트래픽은 NAT instance로 보낸다.
10.10.20.0/24와 10.10.25.0/24 subnet이 이 routing 테이블의 멤버가 된다.

또 다른 구성

DMZ trust 구성

VPC가 비록 public subnet와 private subnet을 구성하도록 하고 있기는 하지만 igw가 있느냐 없느냐의 차이일 뿐 별다른 의미를 가지지는 못한다. 따라서 다층 네트워크 구조를 만들었다고 하더라도 우리가 알고 있는 그런 DMZ trust 구성은 아니다. Security group을 이용한 트래픽 필터링이 가능하기는 하지만, 이건 호스트 레벨의 필터링일 뿐으로 제대로 구성하려면 router와 router 사이에 방화벽을 둬야 한다.

대략 이런 구조다. 방화벽은 리눅스 인스턴스로 구성하면 된다. 단 VPC 환경안에서 굳이 이런 복잡한 구성이 필요한지에 대한 의문은 있다. 내 생각에 이건 (구성하는 재미는 있겠지만) 배보다 배꼽이 더 큰 구성인 것 같다. 그냥 Security group으로 충분하지 싶다.

Security

Security Groups

Security Groups는 아마존에서 제공하는 방화벽 정책 적용 툴이다. 이 툴을 이용해서 유저는 입/출력을 허용할 IP와 PORT 번호를 지정할 수 있다. 인스턴스는 반드시 하나 이상의 securigy groups를 가지고 있어야 한다.

EC2 classic과 VPC의 Security group는 기능에 차이가 있다.

Network ACLs

Security Groups와 같은 방화벽 정책 적용 툴이다. 주요한 차이점은 Security group은 인스턴스 단위의 방화벽 정책 툴인 반면, Network ACLs는 Subnet 단위의 방화벽정책 툴이라는 점이다. Security group와 Network ACLs의 차이점을 정리했다.

Security Group Network ACL
인스턴스 레벨에서 제어 한다. Subnet 단위로 제어한다.
Allow 룰만 적용할 수 있다. Allow 룰과 deny룰을 적용할 수 있다.
리턴 트래픽은 자동으로 허용된다. 리턴 트래픽에 대한 정책이 분리된다.
트래픽을 허용할지 판단하기 전에 모든 룰을 평가 한다. We process rules in number order when deciding whether to allow traffic
인스턴스 단위로 일일이 적용을 해줘야 한다. Subnet에 포함된 모든 인스턴스에 자동으로 적용된다.

히스토리