메뉴

문서정보

목차

VPC

클라우드의 기본 개념은
  1. 컴퓨팅,네트워크,스토리지 풀을 만들고
  2. 유저가 자원을 요청하면 컴퓨팅,네트워크,스토리지를 제공 - IaaS
  3. 유저가 소프트웨어를 요청하면 IaaS 위에 소프트웨어를 전개해서 제공 - SaaS
  4. 유저가 개발환경을 요청하면 IaaS와 SaaS를 기반으로 개발 환경을 제공 - PaaS
이다. 인터넷 공간에 "하드웨어와 소프트웨어 풀"을 만들어야 하기 때문에 "논리적으로 격리"할 수 있어야 한다.

그 중에서도 네트워크 격리가 핵심이다.: 네트워크는 다른 네트워크와 완전히 격리 될 수 있어야 한다. 이 네트워크에는 권한을 가진 유저와 애플리케이션만 접근 할 수 있다. 유저는 모든 컴퓨팅 자원을 격리된 네트워크에 둘 수 있어야 한다. 즉 "유저는 퍼블릭 네트워크 상에 논리적인 IDC(Internet Data Center)"를 만들 수 있어야 한다.

개발자(혹은 관리자는) VPC를 이용해서 클라우드상에 격리된 네트워크를 구성 할 수 있다. 아래는 VPC의 특징이다.

Region

AWS는 전 세계에 걸쳐서 서비스를 제공하고 있다. 주요 지역에는 물리적인 데이터센터가 위치하는데, 이 지역을 리전(Region)이라고 한다. 2018년 현재 16개의 리전이 있다.

Avaliability Zone

하나의 리전은 2개 이상의 가용성 존(Avaliability Zone)으로 구성된다. 물리적인 IDC를 분산함으로써, 특정 존에 문제가 생기더라도 다른 존을 이용해서 서비스가 계속되도록 할 수 있다. 이론적으로는 지진과 같은 전 지역적인 재앙이 발생하지 않는한 서비스를 계속 할 수 있다.

예를 들어 서울(Seoul)리전은 ap-northeast-2a와 ap-northeast-2c 두 개의 가용성 존으로 구성된다. 사용자는 EC2등의 자원을 전개 할 때, 가용성 존을 선택 할 수 있다.

 AWS Region

 AWS Region

Subnet

VPC를 만들 때는 VPC의 IPv4 주소 범위를 CIDR(Classless Inter-Domain Routing)형태로 설정해야 한다. 10.0.0.0/16 과 같은 형태다. 이 경우 개발자는 16비트 크기를 가지는 네트워크를 만들수 있는데, 대략 2^16=65546 개의 IP를 관리 할 수 있는 규모다.

이렇게 VPC 네트워크를 할당 받은 다음, 다시 서브넷단위로 나눠서 사용한다. 10.0.1.0/24, 10.0.2.0/24 이런 식이 되겠다. 따라서 이 경우 255개의 서브넷을 만들 수 있게 된다.

Router

네트워크를 서브넷으로 나눴다면, 트래픽을 제어할 라우터를 준비해야 한다. 이 라우터는 트래픽을 인터넷 게이트웨이로 보내거나 VPN으로 연결된 다른 네트워크로 보내는 등의 작업을 한다. NAT, VPN, Private/Public Network 의 구성 혹은 스토리지 네트워크와 서비스 네트워크의 분리와 같은 작업을 하기 위해서는 Router를 사용 할 수 있어야 한다. 아래 그림을 보자.

 VPC Router

개발자는 10.0.0.0/16 네트워크를 10.0.0.0/24 와 10.0.1.0/24 두 개의 서브넷으로 나눴다. 10.0.0.0/24는 Public subnet 으로 (밑에 설명할) internet gateway를 통해서 인터넷으로 연결이 된다. 여기에는 웹 서버등 인터넷에 공개되는 자원들이 배치 된다. Public subnet의 라우팅 테이블을 분석해보자.
  1. 10.0.0.0/16 -> local : VPC 내부로 향하는 패킷은 local 서브넷으로 향한다. 이 규칙으로 VPC 내부에 있는 다른 자원들(RDS, API를 제공하는 다른 서버 등)에 접근 할 수 있게 된다 1. 0.0.0.0/0 -> igw-id : 1의 패킷을 제외한 다른 모든 패킷은 인터넷 게이트웨이로 향한다.
Private subnet의 라우팅 테이블 정책이다.
  1. 10.0.0.0/16 -> local : 어쨋든 VPC 내부 통신은 해야 할테다.
  2. 0.0.0.0/0 -> vgw-id : Private subnet에 있는 자원은 인터넷으로 부터 격리된다. 여기에는 RDS나 WAS 혹은 Git 저장소와 같이 외부로 부터 격리가 필요한 자원이 배치된다. 하지만 Corporate network에 있는 관리자는 여기에 접근을 해야 한다. 이 경우 VPN을 이용해서 연결을 한다. local이 아닌 패킷 즉 목적지가 0.0.0.0/0 인 패킷을 VPN 게이트웨이(vgw-id)로 보내는 것으로 private subnet에 접근 할 수 있게 된다.
데이터 센터를 구축하는 건 쉬운 일이 아니기 때문에 요즘엔 회사 데이터를 AWS에 두는 경우도 있다. 이들 데이터는 인터넷을 통한 접근은 필요하지 않기 때문에 위 구성에서 Internet Gateway만 제거해서 (클라우드)IDC를 구축하기도 한다.

IGW(Internet Gateway)

IGW(인터넷게이트웨이)는 VPC 내부에 있는 인스턴스와 인터넷이 서로 통신할 수 있게 해주는 "게이트웨이" 역할을 한다.

 Internet gateway

특정 subnet에 있는 인스턴스가 인터넷과 통신을 하려면, IGW로 라우팅 설정을 해야만 한다.

Public subnet & Private subnet

IGW로 향하는 라우팅 룰이 있는 subnet은 Public subnet이고, 없을 경우 private subnet 이 된다. 인터넷을 통해서 private subnet으로 접근하기 위해서는 VPN 연결을 해야 한다. Private subnet에 있는 인스턴스에서 인터넷으로 나가기 위해서는(인터넷에 있는 패키지를 다운로드하거나 S3에 접근하는 등) NAT Gateway를 설정해야만 한다.

VPC peering

일반적으로 독립적인 VPC를 만들어서 프로젝트를 진행을 한다. 프로젝트를 진행함에 따라서 VPC도 함께 늘어나는데 이들 VPC를 연결해야 하는 경우도 있다. 전체 시스템을 관리하는 관리 VPC를 연결하는게 대표적인 경우다.

 VPC Peering

PrivateLink

Private subnet에서 AWS의 S3, DynamoDB에 접근하기 위한 전통적인 방법은 NAT 게이트웨이 혹은 방화벽 프록시를 사용하는 거였다. 2017년부터 제공하는 PrivateLink를 이용하면 NAT등 별도의 장비 없이 AWS의 서비스에 접근 할 수 있다.

 PrivateLink

위 그림은 인스턴스에서 AWS S3에 접근해야 하는 시나리오를 보여주고 있다. 이전에는 인터넷 게이트웨이를 거쳐서 S3에 연결해야 했는데, 이제는 VPC 네트워크를 벗어나지 않고 S3에 접근 할 수 있게 됐다.

PrivateLink를 이용하면 다양한 시도를 할 수 있다. 따로 정리를 해봐야겠다.