aws VPC 피어링 (Arch-3)

일반적인 네트워킹은 어렵다. 장비, 케이블 배선, 복잡한 구성, 전문 기술이 필요하기 떄문이다. 다행히 Amazon VPC는 복잡한 요소를 거치지 않고 보안 프라이빗 네트워크를 간편하게 배포할 수 있다. 자신만의 가상 프라이빗 네트워크를 만들어서 리소스를 배포하고 네트워크 간 프라이빗 피어링 연결을 생성하는 방법을 배워 실습하겠다.

VPC 피어링이란 인스턴스끼리 피어링 연결을 통해 동일한 네트워크에 있는 것처럼 통신할 수 있다. 인터넷 게이트웨이를 거치지 않고 사설의 네트워크처럼 작동할 수 있다. 피어링은 프라이빗 ip주소를 사용해야 하고, 내부 및 리전 간 지원하며 IP 공간은 중복될 수 없다.(VPC가 달라고 IP가 달라야 함.) 두 VPC간 하나의 피어링 리소스만 해당한다. 전이적 피어링 관계는 지원하지 않고 서로 다른 AWS 계정 간에 설정 가능하다. 장점은 인터넷 게이트웨이 없이 데이터를 주고 받는다. 고가용성 연결을 지원하며 단일 장애 지점이 없기 떄문에 안정적인 연결을 지원한다. 대역폭 병목 현상도 없다. (*오른쪽에 Shard VPC는 이미 진행되어서 만들어져 있다.) VPC는 AWS 계정 전용 가상 네트워크이다. 이것은 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다. Amazon EC2 인스턴스 같은 AWS 리소스를 VPC에서 시작할 수 있다. 해당 IP 주소 범위를 수정하고, 서브넷을 만든 다음 라우팅 테이블, 네트워크 게이트웨이 및 보안 설정을 구성하여 VPC를 구성할 수 있다.

먼저 Services메뉴에서 VPC를 클릭한다.

탐색 창에서 Your VPCs를 클릭한다. Default(기본) VPC가 제공되어 있어 AWS를 사용하자마자 리소스를 시작할 수 있고, 실습 뒷부분에서 사용하게 될 Shard VPC도 있다. 지금은 사용자 자신의 Lab VPC를 생성할 것이다. VPC CIDR 범위는 10.0.0.0/16이며, 여기에는 10.0.x.x로 시작하는 모든 ip 주소가 포함된다.(65000개 이상의 주소) 이 주소를 subnet 주소로 나눌 것이다.

VPC 생성을 클릭한다.

이름과 IP주소 범위를 설정하고 생성한다.

생성된 Lab VPC를 선택한다. (이미 공유된 10.5.0.0/16 VPC를 확인할 수 있다.)

페이지 하단 부에 있는 Tags(태그) 탭을 클릭한다. 태그는 리소스를 식별하는 데 유용하다. 예를 들어 태그를 활용하여 Dev/Test/Production 환경 또는 비용센터를 식별가능하다.

클릭된 상태에서 Actions를 클릭하여 Edit DNS hostnames를 선택한다. 이 옵션은 VPC에 있는 친숙한 DNS이름을 Amazon EC2 인스턴스에 할당한다.

Enable(활성화)를 선택한 후 저장한다.

이제 서브넷을 생성하여보겠다. 서브넷은 VPC에 속한 하위 범위의 IP주소이다. AWS리소스를 지정된 서브넷으로 시작할 수 있다. 인터넷에 연결해야 하는 리소스에는 퍼블릿 서브넷을 사용하고, 인터넷과 격리된 상태를 유지해야 하는 리소스에는 프라이빗 서브넷을 사용한다. 퍼블릿 서브넷과 프라이빗 서브넷을 생성할 것이다.

탐색창에서 Subnet을 클릭한 후 Create Subnet을 클릭한다.

이름과 VPC와 가용영역과 IP범위를 설정한 후 생성한다. (10.0.0.0/24 대역)

Public Subnet을 선택한 후 Actions에서 자동 할당 ip 설정 수정을 선택한다.

Auto-assign IPv4를 선택한 후 저장한다.

방금 배운 방식으로 프라이빗 서브넷을 생성한다. (10.0.2.0/23대역)

CIDR 블록 10.0.2.0/23에는 10.0.2.X와 10.0.3.X로 시작하는 모든 IP 주소가 포함되어 있다. 인터넷에 엑세스할 수 있어야 하는 특별한 경우를 제외하고 프라이빗 서브넷은 대부분의 리소스를 프라이빗으로 유지해야 하기 떄문에 크기가 퍼블릿 서브넷의 두배이다. 이제 VPC에 서브넷이 2개가 있다. 그러나 완전히 격리되어 있기 대문에 VPC 밖의 리소스와 통신할 수 없다. 이제 인터넷 게이트웨이를 통해 인터넷에 연결되도록 구성한다.

인터넷 게이트웨이를 생성하겠다. 인터넷 게이트웨이는 수평적 확장으로 이중화를 지원하는 고가용성 VPC 구성 요소로서 VPC의 인스턴스와 인터넷 간 통신이 가능하다. 네트워크 트래픽에 가용성 위험이나 대역폭 제약이 발생하지 않는다. 인터넷 게이트웨이를 사용하는 목적은 다음 두 가지다. 라우팅 테이블에서 인터넷에 연결할 대상 제공, 퍼블릭 IPv5주소가 할당된 인스턴스에 네트워크 주소 변환 실행이다. 이 작업에서는 인터넷 트래픽이 퍼블릿 서브넷에 액세스할 수 있도록 인터넷 게이트웨이를 생성한다.

왼쪽 탐색 창에서 인터넷 게이트웨이를 클릭한 후 create를 선택한다.

이름을 입력하고 create 클릭한다.

생성된 Lab IGW를 선택한 후 Actions에서 VPC에 연결을 선택한다.

VPC 목록에서 Lab VPC 선택한 후 연결한다.

이제 라우팅 테이블을 구성하여야 한다. 라우팅 테이블에는 네트워크 트래픽이 향하는 방향을 결정할 때 사용되는 경로라는 규칙 세트가 포함되어 있다. VPC에 있는 각 서브넷은 라우팅 테이블에 연결되어 있어야 한다. 테이블이 서브넷에 대한 라우팅을 제어한다. 서브넷은 한번에 하나의 라우팅 테이블에만 연결할 수 있지만, 여러 서브넷을 같은 라우팅 테이블에 연결할 수 있다. 인터넷 게이트웨이를 사용하려면 서브넷의 라우팅 테이블에 인터넷에 바인딩된 트래픽을 인터넷 게이트웨이로 향하도록 지시하는 경로가 포함되어 있어야 한다. 인터넷 게이트웨이로 가는 경로가 있는 라우팅 테이블에 서브넷이 연결된 경우 이것을 Public subnet이라고 한다.

왼쪽 탐색 창에서 Route Tables를 클릭한 후 VPC ID열에 Lab VPC라고 써있는 열의 라우팅 테이블을 선택한다.

페이지 하단부의 Routes(경로)탭을 클릭한다. 경로는 하나뿐이다. 10.0.0.0/16로 가게 되는 모든 트래픽이 locally로 라우팅된다는 것을 알 수 있다. 따라서 VPC 내 모든 서브넷이 서로 통신할 수 있다.

이제 퍼블릿 트래픽을 인터넷 게이트웨이로 전송할 새로운 라우팅 테이블을 생성하겠다.

Create route table을 클릭한다.

이름을 입력하고 라우팅 테이블을 생성한다.

생성한 Public Router Table을 선택한다.

Routes 탭에서 Edit routes를 클릭한다.

경로를 추가한다. 0.0.0.0/0 Target은 Internet Gateway 목록에서 Lab IGW를 선택한다.

라우팅 테이블을 서브넷과 연결하기 위해 Edit subnet associatons를 클릭한다.

Public Subnet이 있는 행을 선택한 후 저장한다.

이 Public Subnet은 인터넷 게이트웨이를 통해 인터넷으로 트래픽을 전송하는 라우팅 테이블 항목이 있기 떄문에 이제 public 서브넷이다. 요약하면 다음과 같이 퍼블릭 서브넷을 생성할 수 있다. (인터넷 게이트웨이 생성 -> 라우팅 테이블 생성 -> 0.0.0.0/0 트래픽을 인터넷 게이트웨이로 보내는 라우팅 테이블에 경로 추가 -> 라우팅 테이블을 서브넷과 연결)

보안 그룹은 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 한다. 보안 그룹은 서브넷 수준이 아니라 인스턴스 네트워크 인터페이스 수준에서 작동한다. 따라서 각 인스턴스마다 트래픽을 제어하는 자체 방화벽이 있을 수 있다. 시작할 때 특정 그룹을 지정하지 않으면 인스턴스가 자동으로 VPC의 기본 보안그룹에 할당 된다.

왼쪽 창에서 보안그룹을 클릭한 후 보안 그룹 생성을 클릭한다.

이름, 설명, VPC를 설정하고 생성한다.

생성한 App-SG를 선택한다.

규칙을 편집한다.

인바운드 규칙은 인스턴스에 도달하는 것이 허용되는 트래픽을 결정한다. 인터넷 어디서나 나오는 HTTP 트래픽을 허용하도록 구성한다. 규칙을 설정하고 저장한다.

VPC가 제대로 구성되었는지 테스트하기 위해 이제 Amazon EC2 인스턴스를 퍼블릭 서브넷에서 시작하여 인터넷에서 액세스할 수 있는지 확인해보겠다.

서비스에서 EC2를 클릭한 후 인스턴스를 시작한다.

AMI 이미지는 Linux 2 이미지를 선택한다.

인스턴스 유형은 t2.micro로 설정한다.

NETWORK와 Subnet을 통해 인스턴스가 설치될 위치를 설정한 후 IAM role 설정한다.

User Data를 입력한다. (앱서버 설치를 위한 것)

#!/bin/bash

# Install Apache Web Server and PHP

yum install -y httpd mysql

amazon-linux-extras install -y php7.2

# Download Lab files

wget https://us-west-2-tcprod.s3.amazonaws.com/courses/ILT-TF-100-ARCHIT/v6.3.4/lab-2-webapp/scripts/inventory-app.zip

unzip inventory-app.zip -d /var/www/html/

# Download and install the AWS SDK for PHP

wget https://github.com/aws/aws-sdk-php/releases/download/3.62.3/aws.zip

unzip aws -d /var/www/html

# Turn on web server

chkconfig httpd on

service httpd start

스토리지 추가 (기본 설정 사용)

태그를 추가한다.

아까 미리 생성해 놓은 보안그룹을 선택한다. (경고창 Continue선택!)

기존 키 페어를 선택하고 인스턴스를 시작한다.

앱 서버 인스턴스가 완전히 잘 실행 되었는지 확인한다.

앱 서버 인스턴스의 공인 IP를 이용하여서 새로운 웹페이지에 접속하겠다. VPC가 제대로 구성되었다면 인벤토리 애플과 메시지가 표시될 것이다. 데이터베이스 설정은 아직 구성되지 않았지만 인벤토리 애플리케이션 모양을 보면 퍼블릭 서브넷이 제대로 구성되었는지 알 수 있다.

이제 VPC 피어링을 구성하여 보겠다. 서비스에서 VPC를 클릭한다.

왼쪽 창에서 Peering Connections를 클릭한 후 피어링 연결을 생성한다.

이름을 설정하고 VPC Requester은 Lab VPC를 선택한다.

VPC(Accepter은 Shared VPC를 선택하고 피어링 연결을 생성한다.

피어링 연결이 생성되면 대상 VPC의 수락을 받아야 한다. 대상 VPC를 다른 계정에서 소유하고 있거나 피어링 연결을 생성하는 사용자가 대상 VPC의 연결을 수락할 권한이 없을 수 있다. 생성한 Lab-Peer를 선택한 후 Actions에서 Accept Request으로 요청 수락!

이제 두 VPC의 라우팅 테이블을 업데이트하여 Lab VPC에서 피어링 연결로 트래픽 전송!

왼쪽 탐색 창에서 Route Tables를 클릭한 후 Public Route Table을 선택한다.

Routes 탭에서 Edit routes를 클릭한다.

Add route를 통해 공유 VPC의 CIDR범위를 추가한다. Target은 목록에서 Peering Connection과 Lab-peer를 차례로 선택한 후 경로 저장한다.

공유 VPC 라우팅 테이블을 선택한다. 대상 IP 주소가 Lab VPC범위에 들 경우 피어링 연결로 트래픽을 전송하도록 구성한다.

역시 Routes 탭에서 Edit routes를 클릭한다.

Add route를 통해 Lab VPC의 CIDR 범위를 설정한다. Target은 Peering Connections과 Lab-peer를 차례로 선택한 후 저장한다.

이제 트래픽이 다른 VPC용으로 정해질 때 피어링 연결을 통해 트래픽을 전송하도록 라우팅 테이블을 구성했다. 데이터베이스는 이미 공유 VPC에 프로비저닝되어 있다. 이제 피어링 연결을 통해 데이터베이스에 엑세스하도록 인벤토리 애플리케이션을 구성하여 피어링 연결을 테스트한다.

다시 웹 브라우저 탭으로 돌아가서 Settings를 클릭한다.

기존에 공유된 데이터베이스의 endpoint와 데이터베이스 정보를 입력 후 저장한다.

그렇게 되면 애플리케이션에 데이터베이스의 데이터가 표시된다. 이를 통해 공유 VPC에 인터넷 게이트웨이가 없기 떄문에 피어링 연결이 작동된다는 것을 알 수 있다. 피어링 연결을 통해서만 데이터베이스를 액세스할 수 있다.