Amazon VPC (Virtual Private Cloud), VPC Peering

자 이번 포스팅에서는 AWS 네트워킹에 대해 살펴보겠습니다.

사실상 개인적으로 생각하는 Amazon Webservice의 꽃이 아닐까 싶은 파트인데요. 네트워킹 부분을 마스터 하게 되면 이후 AWS에 대한 아키텍처를 수립하는데 아주 많은 부분이 보일 것이고 시각이 넓혀 질거라고 생각합니다.

 

# 본 포스팅은 개인적으로 또는 회사 차원에서 진행한 TF의 다양한 학습 결과 그리고 Architecting On AWS 교육 등을 통해 습득한 지식을 리마인드하며 공유하는 것임을 알려드립니다.

 

앞서 몇번이나 강조했듯이 Public 공간에 개인정보나, 민감정보들을 오픈한다는 것 자체에 굉장히 거부감을 갖고 있는 많은 사이트 들이 있습니다.

이에 AWS에서는 Public 공간을 완전히 분리하여 관리할 수 있는 Vitual Private Cloud 즉 VPC 영역을 제공하여 네트워크 보안 관리에 힘쓸 수 있게 되었으며, 리소스에 대한 사용자 지정 액세스 제어 및 보안 설정을 허용하고 있습니다.

Amazon Virtual Private Cloud (VPC)

- VPC는 리전 Scope의 서비스입니다. 리전 내부의 AZ를 선택하여 생성할 수 있습니다.
- AWS에서는 기본 Default 서브넷을 제공하며, 원하는 가상 네트워크 인프라를 구분하기 위한 Amazon Virtual Private Cloud(VPC)를 제공합니다. 앞서 테스트를 진행했던 RDS와 EC2에서 사용한 VPC가 바로 Default VPC입니다.

- VPC는 AWS 계정 전용 가상 네트워크로 IPv4 또는 IPv6 주소 범위에 존재하게 됩니다.
점유 리소스에 대한 특정 CIDR 범위를 생성할 수 있습니다. 참고로 Amazon의 경우 CIDR을 16이하로만 사용이 가능합니다. (16~32까지)

 

# 참조

- CIDR

10.1.0.0/16 : /16은 네트워크 할당 비트를 나타냄 (32비트 - 네트워크 할당 비트 = 사용 가능한 IP 개수)

---

=> 0.0.0.0/0 = 모든 IP
=> 10.22.33.44/32 = 10.22.33.[44] 특정 호스트 고정
=> 10.22.33.0/24 = 10.22.33.*
=> 10.22.0.0/16 = 10.22.*.*
==> /16 = 65536개의 IP 사용 가능하며 /17은 그 절반으로... /22는 1024개, /28은 16개의 IP 사용 가능

---

- 계정당 / 리전당 VPC 5개 (nrson 계정으로 로그인하면, 서울에 5개, 도쿄에 5개의 VPC를 갖을 수 있다는 의미)까지 생성이 가능하며, LIMIT에서 해당 제한을 풀수도 있습니다.

Subnet (서브넷)
- Amazon VPC의 경우 서브넷을 사용하여 공간을 분리하여 관리할 수 있습니다. 하나의 VPC에서 많은 IP를 할당하여 사용할 경우 네트워크 Latency나 관리, 성능 문제등이 발생할 수 있어 서브넷으로 또 다시 분리하여 관리하는 것이 효율적입니다.
- VPC 서브넷은 AZ Scope을 갖고 있습니다.
- VPC에서 사용 가능한 IP 영역을 서브넷 개수만큼 분리하여 네트워크를 구성하게 되며, 서브넷은 VPC CIDR 블록의 하위 집합으로 구성됩니다. 서브넷 CIDR 블록은 중첩 될 수 없으며, 하나의 AZ에서만 존재할 수 있습니다.
- AZ에는 여러 개의 서브넷이 포함될 수 있습니다.
- AWS는 각 서브넷에서 5개의 IP 주소를 예약주소로 사용하여 할당된 IP - 5개가 인스턴스 IP로 할당 될 수 있습니다.

---

# 참조

예약 주소는 각 서브넷을 첫 4개의 주소와 마지막 주소를 예약합니다.

- 10.0.0.0 : 네트워크 주소

- 10.0.0.1 : AWS에서 VPC 라우터용으로 예약

- 10.0.0.2 : DNS 서버의 IP 주소

- 10.0.0.3 : 차후 사용을 위한 예약

- 10.0.0.255 : 네트워크 브로드캐스트 주소

---

Routing Table (라우팅 테이블)
- 기본 VPC의 내부통신은 별도의 설정없이 통신이 가능하지만 외부로 나가야 할 경우 라우팅 테이블 엔트리를 목적별로 등록하여 사용할 수 있습니다.
- 라우팅 테이블은 서브넷에 의존하고 있으며, 모든 서브넷에는 라우팅 테이블이 있어야 합니다.

- 기본 VPC를 생성하면 라우팅 테이블이 생성되며, 이는 서브넷과 연결됩니다. 이때 로컬 통신을 위한 기본 CIDR이 등록되어 있으며, 외부와 연결을 원할 경우 그에 맞는 추가가 필요합니다.
- 이때 라우팅 테이블을 통해 인터넷 공간에 연결할 수도 있는데 이를 기준으로 퍼블릭 서브넷과 프라이빗 서브넷으로 나눌 수 있습니다.
퍼블릭 서브넷은 인터넷 게이트웨이에 대한 라우팅 테이블 항목을 포합니다. 그와 반대로 프라이빗 서브넷은 인터넷 게이트웨이에 대한 라우팅 테이블이 포함되어 있지 않겠죠.
퍼블릭 서브넷은 추가적으로 공인 IP를 할당 받을 것인지를 결정할 수 있습니다. 이를 통해 인터넷에서 직접 액세스할 수 있는 Public IP를 부여하게 되지만, 프라이빗 서브넷은 인터넷에서 직접 액세스할 수 없습니다.

인터넷 게이트웨이

- 인터넷 게이트웨이는 퍼블릭 서브넷을 만드는 즉 퍼블릭 서브넷을 인터넷에 연결해 주는 게이트웨이입니다.

- 인터넷 게이트웨이는 VPC Scope의 서비스입니다.
- 특정 VPC의 인스턴스와 인터넷 간의 통신을 허용하기 위해 존재합니다. 인터넷 게이트웨이는 각 VPC 별로 연결해서 사용해야 합니다.
- 앞서 살펴본 봐와 같이 인터넷으로 라우팅 가능한 트래픽을 위해 서브넷 라우팅 테이블의 대상을 제공하고 서브넷에 연결된 라우팅 테이블에 인터넷 게이트웨이를 엔트리로 추가하는 방식으로 Public 인터넷에 접근할 수 있습니다.

# 참조
- 서브넷의 퍼블릭 라우팅 테이블
10.0.0.0/16 = 대상 로컬 (default)
0.0.0.0/0 = <igw-id> (add)

위와 같이 추가할 경우 10.0.*.*의 경우 로컬 VPC 영역으로 라우팅하며, 나머지 요청의 경우 igw-id로 라우팅하여 처리한다.로 해석할 수 있습니다.

NAT 게이트웨이 & NAT 인스턴스

- NAT 게이트웨이는 프라이빗 서브넷을 인터넷에 연결하기 위한 게이트웨이입니다.

- 프라이빗 서브넷을 사용하는 인스턴스는 VPC NAT 게이트웨이를 통해 인터넷 게이트웨이와 아웃바운드 통신을 연결할 수 있습니다.

- 프라이빗 서브넷의 아웃 바운드 퍼블릭 인터넷을 지원하기 위해 사용합니다. 일반적으로 제한된 아웃 바운드 퍼블릭 인터넷 액세스를 지원하기 위해 NAT 게이트웨이를 사용 (ex - 리눅스 업데이트)하여 업데이트를 수행합니다.

인바운드 접근은 불가능하지만 아웃바둔드 트래픽만 허용하여 특정 업데이트를 다운로드 받는다던지의 역할을 수행할 수 있도록 구성합니다.
- 라우팅 테이블에 게이트웨이를 NAT 게이트웨이로 등록하면 로컬 통신 이외를 NAT 게이트웨이를 통해 외부로 아웃바운드 통신이 가능해집니다.

# 참조

- 서브넷의 프라이빗 라우팅 테이블
10.0.0.0/16 = 대상 로컬 (default)
0.0.0.0/0 = <nat-id> (add)
위와 같이 추가할 경우 10.0.*.*의 경우 로컬 VPC 영역으로 라우팅하며, 나머지 요청의 경우 nat-id로 라우팅하여 아웃바운드 트래픽에 대한 인터넷 연결을 허용한다.로 해석할 수 있습니다.

VPC Subnet (서브넷)

서브넷의 사용 사례
서브넷의 사용 사례는 다양하지만 주로 다음과 같이 배치 할 수 있습니다.
- 프라이빗 서브넷 : 데이터 스토어 인스턴스, 배치 처리 인스턴스, 백엔드 인스턴스
- 퍼블릭 서브넷 : 웹 애플리케이션 인스턴스 또는 로드밸런서

서브넷 설계

본격적인 서브넷 설계를 위해서 어떠한 고려사항들이 있는지 살펴보겠습니다.

- 일반적으로 작은 크기 보다는 /24이상의 큰 크기의 서브넷을 고려해야 합니다. 워크로드를 구분하여 관리하는 이점이 있는 대신에 너무 많은 서브넷을 구분하여 관리할 경우 발생되는 복잡도와 불필요한 시간 소모 등을 최소화 하는 것이 중요합니다.
- 또한 서브넷은 최초 구성 이후 변경 불가 정보이기 때문에 서브넷에 배치 될 인스턴스 개수를 예측하고 이후 확장성 등을 고려하여 넉넉한 수준으로 설정하는 것이 중요합니다.
- 기본 서브넷 구성으로 하나의 퍼블릭, 하나의 프라이빗 서브넷을 구분하여 구성하는 것으로 시작하곤 하는데 일반적으로 웹서버를 퍼블릭 서브넷, 와스 서버를 프라이빗 서브넷 공간에 구성하고 이를 분리하여 관리하는 구조로 설계를 합니다. 이때 일반적으로 내부망에 더 많은 서버를 배치하는 경우가 많아 내부는 /23으로 한 비트 더 사용하는 경우도 있습니다.

# 참조

VPC 10.0.0.0/21 (10.0.0.0 ~ 10.0.7.255)
- 퍼블릭 서브넷 1 : 10.0.0.0/24, 퍼블릭 서브넷 2 : 10.0.1.0/24

21 비트의 네트워크 할당 비트 + 3개의 서브넷 주소를 합친 24개를 네트워크 비트로 사용한다는 의미입니다. 즉 3개의 서브넷 주소는 8개를 가져 갈 수 있다는 의미이며, 호스트 주소는 그 나머지인 11 - 3 = 8개를 가져 갈 수 있습니다. 즉 256 - 5개를 인스턴스 IP로 가져 갈 수 있으며, 총 8개의 서브넷을 생성할 수 있습니다.
- 프라이빗 서브넷 1 : 10.0.2.0/23, 프라이빗 서브넷 2  : 10.0.4.0/23

탄력적 네트워크 인터페이스 (ENI)
- 탄력적 IP 주소는 AWS 리전 Scope을 갖습니다.
- 클라우드 환경에서 변경되는 정보를 유지하게 해줄 수 있습니다. 유지 정보는 프라이빗 IP 주소, 탄력적 IP 주소, MAC 주소 등을 고정 IP와 같이 재기동을 하더라도 유지할 수 있도록 관리해 줍니다.
- 주의해야 할 사항은 Running 중인 EIP의 경우 과금되지 않지만, 사용하지 않을 경우 EIP에 대한 비용이 차지 됩니다. 바로 Elastic IP는 실제 Real IP를 제공해 주는 것이라 사용하지 않고 낭비하는 것에 대한 차지를 부여하는 것이라 생각하면 됩니다.
- 또한 DR 서버를 구축하는 경우 Primary / Backup 구조로 Primary가 다운 되었을 시 손쉽게 IP를 넘겨 줄 수 있어 네트워크 구성이 단순화 되고 손쉬운 전개를 진행할 수 있습니다.

클라우드에서의 보안

앞서 수번이나 살펴보고 강조했던 내용이지만, 여전히 강조를 하는 것은 바로 클라우드 환경의 보안이 정말로 중요하기 때문입니다.

다시한번 클라우드 상의 보안 요소들을 되짚어 보도록 하겠습니다.

1. 보안 그룹

1) 보안 그룹은 AWS 리소스에 대한 인바운드/아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 수행합니다.
2) 트래픽은 모든 IP 프로토콜, 포트 또는 IP 주소로 제한될 수 있습니다.
3) Allow 정책의 White List 방식 / Deny 정책의 Black List 방식 중 대체로 White List 방식을 선택합니다.
- 허용할 Source IP를 직접 지정하거나 보안 그룹을 등록하는 방식을 선택할 수 있음
- 기본 인바운드는 Deny 상태로 허용을 원하는 Source IP를 추가하는 방식을 사용합니다.
- 기본 아웃바운드는 Allow 상태로 차단을 원하는 경우 Source IP를 추가하는 방식을 사용합니다.
4) 체인다이어그램 (기존 3Tier Architecture 기반 설계 시)
- 웹 서버 보안 그룹 : 인바운드 규칙 (HTTPS 또는 443 포트 허용 / 0.0.0.0/0 소스 IP 허용)
- 애플리케이션 서버 보안 그룹 : 인바운드 규칙 (HTTP 또는 80 포트 허용 / 웹 티어 보안 그룹을 지정하여 허용 즉 웹 티어를 통해 들어온 요청만 허용 한다는 의미)
- 데이터베이스 보안 그룹 : 인바운드 규칙 (TCP 또는 3306 포트 허용 / 어플리케이션 티어 보안 그룹을 지정하여 허용 즉 어플리케이션 보안 그룹을 통해 들어온 요청만 허용 한다는 의미)

5) 퍼블릭 서브넷 구성

- 인터넷 게이트웨이 : 퍼블릭
- 퍼블릭 서브넷 (NAT 게이트웨이)를 통한 인터넷 게이트웨이 연동
- 앱 서브넷  : EC2 인스턴스 브라이빗 서브넷
- 데이터 서브넷 : Memcached, Amazon RDS, Amazon EFS 등 프라이빗 서브넷
6) Network ACL (Access Control List) / NACL
- 서브넷 경계의 방화벽 역할을 수행합니다.

- 기본 모든 인바운드 / 아웃바운드 트래픽을 허용하며, 정책 변경을 원할 시 명시적으로 선언해야 합니다.

이와 같은 보안 관련 Component를 배치하고 운영하는 아키텍처는 다음과 같습니다.

---

---

다중 보호 계층으로 보호되는 VPC 내부의 도식화 아키텍처 입니다.

VPC에서 인프라를 실행함으로써 어떤 인스턴스를 인터넷 공간에 오픈할 것인지를 결정할 수 있으며, 보안 그룹과 네트워크 ACL을 통해 인프라 및 서브넷 보호를 강화할 수 있습니다.

보안 그룹은 상태 저장 패킷 필터링을 적용하고, 해당 보안 그룹을 참조하는 방식으로 적용하여 특정 보안 그룹을 통해 유입된 요청만 허용한다던지 등의 다양한 용도로 활용할 수 있습니다.

네트워크 ACL의 경우 특정 하위 집합을 거부하거나, 서브넷의 고급 수준의 Guard를 제공하여 보조 방화벽 역할을 수행합니다.

검토

그럼 지금까지 살펴본 VPC에 대한 정리를 진행하고 실습 과정을 살펴보도록 하겠습니다.

먼저 위에서 살펴본 다양한 네트워크 계층은 결국은 보안과 관련되어 있는 요소들이라고 돌려 말할 수 있을 것입니다.

예를 들어

인터넷 게이트웨이 → 라우팅 테이블 → 네트워크 ACL 인/아웃 → 서브넷 → 보안 그룹 인/아웃 → EC2

위와 같은 구조로 요청이 유입 될 경우

- 라우팅 테이블을 통해 네트워크 ACL 인바운드 트래픽 허용 여부를 검토
- 서브넷에 요청이 유입되면 특정 ec2 인스턴스에 인바운드 보안그룹을 검토하여 유입되고
- 비즈니스 로직 처리가 수행된 이후 아웃바운드 보안 그룹을 검토하여 서브넷을 통해 네트워크 ACL 아웃바운드 룰을 검토하여
- 라우팅 테이블을 통해 인터넷 게이트웨이로 나가는 방식으로 다중 보호 계층을 인프라 구조에 유입하는 것이 중요합니다.

마지막으로 VPC를 통해 외부로 트래픽을 전송하기 위해서는 다음과 같은 과정을 거쳐야 합니다.

- 인터넷 게이트웨이를 VPC에 연결하는 작업을 수행한다.
- 라우팅 테이블을 인터넷 게이트웨이에 연결한다.
- 인스턴스에 퍼블릭 IP 또는 탄력적인 IP 주소가 있는지 확인한다.
- 네트워크 ACL과 SG가 관련 트래픽 흐름을 허용하는지 확인한다.

VPC 구성 실습 1. VPC

앞서 살펴본 봐와 같이 VPC는 AWS 계정 전용 가상 네트워크입니다. 다른 AWS 계정이나 네트워크와 논리적으로 구분되어 있는 구조로 설계되어 있습니다.

1. VPC 생성

Services → VPC → VPC 생성

이름 태그	AWS-VPC	AWS VPC 이름 지정
IPv4 CIDR 블록	10.0.0.0/16	16이하 CIDR 범위 지정

VPC가 성공적으로 생성되었을때 확인해 봐야 할 부분은 바로 VPC 대시보드입니다.

최초 VPC를 생성하기 이전에 모든 네트워크 관련 인터페이스를 제거하였으며, VPC를 생성하였을때 어떠한 요소들이 함께 생성되는지 살펴보겠습니다.

위와 같이 VPC가 생성되면 라우팅 테이블 1개, 네트워크 ACL 1개, 보안 그룹 1개, DHCP 옵션 세트 1개가 함께 생성되는 것을 확인할 수 있습니다.

 

2. VPC 구성

생성된 VPC를 클릭하고 Edit DNS Hostname (DNS 호스트 이름 편집)을 선택합니다.

위와 같이 DNS 호스트 이름 : 활성화를 체크하고 저장합니다. 활성화가 적용되면 이제 해당 VPC를 사용하는 EC2 인스턴스에 도메인이 할당됩니다.

 

3. 서브넷 생성

Services → VPC → 서브넷 생성

이름 태그	Public Subnet	인터넷 게이트웨이와 연결할 서브넷
VPC	VPC-xxx	앞서 생성한 AWS-VPC 선택
가용 영역	ab-southeast-2a	한국에는 3개의 AZ가 존재하며 그중 하나 선택
IPv4 CIDR 블록	10.0.0.0/24	CIDR 블록을 10.0.0.0/16 보다 작게 구분

- 서블릿에 자동 할당 IP 설정 수정 반영

기본으로 생성한 서브넷에 자동 할당 IP를 추가합니다.

다음으로 프라이빗 서브넷을 생성합니다. 퍼블릭 서브넷과 생성과정은 동일합니다.

여기서 차이점은 IPv4 CIDR 불론의 경우 퍼블릭 공간은 /24, 프라이빗 공간은 /23을 잡아 주었다는 것입니다. 대체로 퍼블릭 공간보다 프라이빗 공간에 WAS 또는 DB, 솔루션 등을 구성하여 보다 많은 인스턴스가 필요한 경우가 많습니다. 이로인해 일반적으로는 프라이빗 공간에 보다 많은 인스턴스 IP를 할당할 수 있도록 위와 같이 구성하게 됩니다.

 

4. 인터넷 게이트웨이 생성

다음으로 인터넷 게이트웨이를 생성해 보도록 하겠습니다.

인터넷 게이트웨이는 라우팅 테이블을 통한 인터넷에 연결할 대상을 제공하는 역할을 담당합니다.

Services → VPC → 인터넷 게이트웨이 생성

인터넷 게이트웨이의 경우 고가용성 VPC 구성 요소로 네트워크 트래픽에 가용성 위험이나 대역폭 제약등이 발생하지 않는 완전 가용성 VPC Component라고 할 수 있습니다.

다음으로 생성한 VPC와 연결하는 과정입니다.

 

5. 라우팅 테이블 생성

라우팅 테이블에는 네트워크 트래픽이 향하는 방향을 결정할 때 사용되는 Route가 포함되어 있습니다.

Services → VPC → 퍼블릭 라우팅 테이블 생성

기본으로 생성된 라우팅 테이블의 경우 VPC 내부 통신을 지원하는 라우팅이 추가되어 있습니다.

라우팅을 추가하여 인터넷 게이트웨이로 연결과정을 설정해야 합니다.

위와 같이 구성하면 10.0.0.0/16 CIDR에 포함되는 요청의 경우 VPC 내부에서 처리가 되며, 나머지 요청은 인터넷 게이트웨이로 라우팅 되도록 구성됩니다.

마지막으로 연결이 완료된 라우팅 테이블을 퍼블릭 서브넷과 연동하여 서브넷에 인터넷이 제공되는 환경으로 만듭니다.

위와 같이 라우팅 테이블을 생성한 Public Subnet과 연결하고 저장합니다.

 

6. 앱 서버용 퍼블릭 보안 그룹 생성

보안 그룹 이름	AWS-APP-SG	웹 서버용 보안 그룹
설명	HTTP	Description
VPC	VPC-xxxxxxxx	VPC 선택

생성된 보안 그룹을 기준으로 인바운드 규칙에 80 (http port) port를 모두에게 접근할 수 있도록 허용하는 규칙을 적용합니다.

여기까지 구성이 완료되면 이제 실제 앱을 운영할 인스턴스를 구성하게 됩니다.

 

7. 앱 서버 시작

Services → EC2 → 인스턴스 시작

[주요 설정]

AMI 선택	Amazon Linux 2 AMI (HVM), SSD Volume Type	Amazon Linux
인스턴스 유형	t2.micro	Free 티어

네트워크	AWS-VPC	VPC 선택
서브넷	Public Subnet	퍼블릭 인터넷 게이트웨이와 연결 된 서브넷 선택

추가로 사용자 데이터 정보를 다음과 같이 입력합니다.

#!/bin/bash yum install -y httpd mysql amazon-linux-extras install -y php7.2 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/ wget https://github.com/aws/aws-sdk-php/releases/download/3.62.3/aws.zip unzip aws -d /var/www/html chkconfig httpd on service httpd start

앞서 생성한 보안 그룹을 적용하고 인스턴스를 생성합니다.

 

8. VPC & EC2 생성 상태 확인

- EC2 인스턴스에 디플로이되어있는 애플리케이션 접속 테스트를 진행하고 상태를 점검합니다.

VPC 구성 실습 2. VPC Peering

VPC 피어링 연결은 두 VPC 사이에서 비공개적으로 트래픽을 라우팅할 수 있게 하는 두 VPC 사이의 네트워킹 입니다.

1. VPC 피어링 생성

Services → VPC → 피어링 연결 → 피어링 연결 생성

위와 같이 피어링할 로컬 VPC를 선택하고 피어링 할 다른 VPC를 선택합니다.

다른 VPC 선택 기준은 계정과 리전을 구분하여 추가할 수 있습니다.

이때 피어링을 연결하기 위해서는 CIDR 구간이 중첩되지 않는 2개 이상의 VPC 사이에서만 연결이 가능합니다. 마찬가지로 CIDR 기준으로 라우팅 테이블에 분기 조건이 등록이 되기 때문에 동일한 CIDR을 사용하는 VPC 간의 연결은 불가능 합니다.

 

2. 피어링 요청 수락

자 위와 같이 정상적으로 피어링 연결이 생성되었습니다.

본 테스트의 경우 동일 계정 내에서 VPC 피어링 연결을 시도하여 

다음과 같이 요청 수락을 동일 계정에서 수행할 수 있지만, 다른 계정의 VPC와 피어링을 연결하고자 할 경우 수신측에서도 반드시 요청 수락을 해주어야만 연결이 가능합니다.

자 다음과 같이 요청을 수락하면 이제 두개의 VPC는 피어링으로 연결되어 있는 상태입니다.

그렇다고 바로 연결할 수 있는 것은 아닙니다. 라우팅 테이블에 상대방의 라우팅 정보를 기입해 주어야만 라우팅할 수 있는데

요.

 

3. 라우팅 테이블 설정

마지막으로 라우팅 테이블로 연결하는 과정을 살펴보도록 하겠습니다.

다음과 같이 라우팅 테이블에 상대 VPC CIDR 영역을 지정해 주면 해당 IP 대역으로 요청이 유입되었을때 피어링을 통해 VPC 간 통신을 수행할 수 있게 됩니다.

자 오늘은 VPC를 구성하고 VPC를 구성하는 각 요소들을 살펴보았으며, 이를 실습을 통해 직접 하나하나 구성해 보고 마지막으로 VPC Peering을 통해 VPC 간의 네트워킹 과정까지 살펴보았습니다.

다음 포스팅에서는 추가적인 AWS 기반 네트워킹에 대해 살펴보겠습니다.

 

#참조

실습 최종 정리
Public Web Server - Private Was Server - Private DB Server
1. VPC를 생성한다.
- VPC에서 사용할 CIDR을 지정
- DNS 호스트 이름 편집에서 활성화
2. 웹을 위한 Public Subnet을 생성한다.
- 생성한 VPC, AZ, CIDR 지정(CIDR은 VPC보다 당연히 작은 범위로 지정) 및 선택
- 자동 IP 할당 수정 활성화
- 인터넷 게이트웨이를 연결하여 라우팅 테이블에 등록해 주면 퍼블릭 서브넷이 됨
3. WAS를 위한 Private Subnet을 생성한다.
- 동일한 방식으로 생성하되 자동 IP는 할당하지 않음
- 대체로 대부분의 리소스를 프라이빗으로 유지해야 하기 때문에 크기가 퍼블릭 서브넷의 두배로 설정 함
4. 인터넷 게이트웨이를 생성한다.
- 인터넷 게이트웨이는 라우팅 테이블에서 인터넷에 연결할 대상을 제공한다.
- 퍼블릭 IPv4 주소가 할당된 인스턴스에 네트워크 주소 변환(NAT)을 실행한다.
- 인터넷 게이트웨이 생성 후 생성한 VPC에 연결한다. 아직은 퍼블릭 서브넷으로 변경되지 않는다. 라우팅 테이블에 인터넷 게이트웨이를 사용하도록 등록해 주어야 한다.
5. 라우팅 테이블을 생성한다.
- 인터넷에 바인딩된 트래픽용 Public table을 생성한다.
- 인터넷 게이트웨이로 인터넷에 바운딩된 트래픽을 보내는 라우팅 테이블에 Route를 추가한다.
- 퍼블릭 서브넷을 새 라우팅 테이블에 연결한다.
- 기본으로 생성된 프라이빗 라우팅 테이블이외에 신규로 라우팅 테이블을 생성한다.
- 생성한 라우팅 테이블에 Route를 편집하여 타겟에 인터넷 게이트웨이를 선택해 준다. 이 시점에 퍼블릭 서브넷으로 변경된다.
- 즉 인터넷 게이트웨이 생성 -> 라우팅 테이블 생성 -> 0.0.0.0/0 트래픽을 인터넷 게이트웨이로 보내는 라우팅 테이블에 경로 추가 -> 라우팅 테이블을 서브넷과 연결하면 퍼블릭 서브넷으로 변경된다.
6. 보안그룹을 생성한다.
- 보안 그룹은 인스턴스에 인바운드와 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 한다.
- 보안 그룹을 생성하고 웹에서 사용할 HTTP를 0.0.0.0/0으로 인바운드 규칙을 허용한다.
7. 퍼블릭 서브넷에서 웹서버 시작
- 인스턴스를 생성한다.
- 이때 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

---

를 입력하여 자동 실행되도록 구성해 준다.
8. VPC 간 통신을 위한 VPC Peering을 생성한다.
- 두 VPC 사이에서 비공개적으로 트래픽을 라우팅할 수 있게 하는 네트워킹 연결
- VPC Peering으로 연결을 요청할 경우 Destination 측에서 요청을 허락해 주어야 연결이 가능
- 피어링 연결에서 피어링을 생성하고 Source VPC와 Destination VPC를 지정한다.
- 이때 Destination 측에서 허용을 해주어야만 연결이 가능하다.
- 라우팅 테이블에 라우팅을 추가한다.
- 인바운드 트래픽을 위한 Destination VPC의 CIDR 범위를 추가하고 피어링에 추가한 피어링 이름을 선택하고 저장한다.
- 반대쪽 Destination VPC에서도 마찬가지로 Souce VPC의 CIDR 범위를 추가하고 피어링에 추가한 피어링 이름을 선택하고 저장한다.