AWS VPC

Contents

클라우드의 기본 개념은

1. 컴퓨팅,네트워크,스토리지 풀을 만들고
2. 유저가 자원을 요청하면 컴퓨팅,네트워크,스토리지를 제공 - IaaS
3. 유저가 소프트웨어를 요청하면 IaaS 위에 소프트웨어를 전개해서 제공 - SaaS
4. 유저가 개발환경을 요청하면 IaaS와 SaaS를 기반으로 개발 환경을 제공 - PaaS

이다. 인터넷 공간에 "하드웨어와 소프트웨어 풀"을 만들어야 하기 때문에 "논리적으로 격리"할 수 있어야 한다.

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

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

• 16 Bit 네트워크를 만들 수 있다. 개발자는 이 네트워크를 (예를 들어 24 비트)서브넷으로 나눠서 네트워크를 구성 할 수 있다.
• VPC는 라우터를 제공한다. 이 라우터를 이용해서 VPC 네트워크에서의 트래픽을 제어 할 수 있다.
• VPC에 인터넷게이트웨이(IGW)를 붙일 수(attach)있다. 개발자는 라우터를 이용해서 특정 서브넷의 트래픽을 IGW로 향하게 할 수 있다. IGW로 트래픽을 보낼 수 있는 서브넷은 인터넷 통신을 할 수 있다. 반면 IGW 라우팅 룰이 없는 서브넷은 인터넷으로 부터 완전히 격리된다.
• NAT Gateway를 붙일 수 있다. IGW 라우팅 룰이 없는 서브넷은 인터넷으로 부터 격리된다. 하지만 나가는 트래픽은 허용해야 할 수도 있다. NAT 게이트웨이를 이용해서 인터넷으로 패킷을 보낼 수 있다.
• 고정된 IPv4, IPv6 주소를 사용 할 수 있다.
• 시큐리티그룹(Security group)외에 네트워크 ACL을 적용해서 인스턴스에 대한 접근 보안을 한단계 더 강화 할 수 있다.

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

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

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

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개의 서브넷을 만들 수 있게 된다.

네트워크를 서브넷으로 나눴다면, 트래픽을 제어할 라우터를 준비해야 한다. 이 라우터는 트래픽을 인터넷 게이트웨이로 보내거나 VPN으로 연결된 다른 네트워크로 보내는 등의 작업을 한다. NAT, VPN, Private/Public Network 의 구성 혹은 스토리지 네트워크와 서비스 네트워크의 분리와 같은 작업을 하기 위해서는 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(인터넷게이트웨이)는 VPC 내부에 있는 인스턴스와 인터넷이 서로 통신할 수 있게 해주는 "게이트웨이" 역할을 한다.

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

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

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

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

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

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