[AWS_Builders] VPC

 

각각의 리전은 이중화 되어있는 100G급의 AWS 자체 네트워크로 연결되어 리전 간에 고속의 네트워크 환경을 제공한다. 

각 AWS 리전은 지리적 영역 내에서 최소 3개의 독립적인 가용영역으로 구성된다. 

그리고 하나의 가용영역은 하나 이상의 개별 데이터센터로 구성된다. 

 

즉, 데이터센터가 모여서 하나의 가용영역으로 이루어지고, 가용영역이 모여 하나의 리전으로 구성된다. 

현재 서울 리전은 4개의 가용영역으로 이루어져 있다. 

 

가용영역이란 다른 가용영역과 완전히 격리된 하나 이상의 데이터센터를 의미한다. 

한 가용영역에는 충분한 물리적 거리를 두어 특정 가용영역에서 발생한 재난 상황이 다른 가용영역에까지 영향을 미치지 않도록 설계되었다.

또한 각 가용영역들은 독립된 전력 및 낸각 인프라를 구축하고 있다. 

각 가용영역과의 통신도 AWS의 자체 네트워크를 통해 높은 처리량과 짧은 지연시간을 제공한다. 

이런 고속의 네트워크 환경을 바탕으로 여러 가용영역에 어플리케이션을 동시에 서비스하고 데이터 복제를 제공하여 고객분들의 서비스에 고가용성을 제공한다. 

 

AWS에서 제공하는 서비스들은 제공하는 지역에 따라 세 가지로 구분한다. 

첫 번째로, Amazon CloudFront와 Amazon Route 53은 AWS 글로벌 영역에 배치된 글로벌 서비스이다. 

글로벌 서비스는 데이터를 특정 지역에 국한하지 않고, 글로벌 영역에 분산하여 저장한다. 

 

두 번째로 Amazon S3 또는 Amazon DynamoDB는 하나의 리전에서 여러 가용영역에 동시에 제공하는 리전 서비스이다. 

Amazon VPC도 리전 서비스이며 여러 가용영역에 걸쳐 네트워크 환경을 제공한다. 

 

세 번째로, Amazon EC2의 경우 EC2를 생성하는 가용영역에 독립적으로 서비스되는 가용영역 서비스이다. 

 

 

VPC란 자체 데이터센터에서 운영하는 기존 네트워크와 아주 유사한 가상의 네트워크를 의미한다. 

VPC는 다른 네트워크와 논리적으로 격리된 가상의 사설 네트워크 환경을 제공한다. 

많은 엔터프라이즈 기업이 사내 프라이빗 네트워크 환경을 구현하는 것처럼, VPC를 통해서 완전히 독립된 네트워크를 구축할 수 있다. 

 

 

VPC를 생성하기 위해서는, 먼저 VPC가 위치할 리전을 선택한다. 

다음으로, IP 범위를 설정하여 전체 VPC의 네트워크 크기를 지정한다. 

 

VPC가 배치될 가용영역을 선택하고, 각 가용영역에 네트워크 서브넷을 배치한다. 

각 네트워크 서브넷에 라우팅 테이블을 구성하여 Amazon EC2와 같은 리소스들의 네트워크 경로를 지정한다. 

 

마지막으로 보안을 위한 VPC의 액세스 제어 환경을 구성한다. 

 

 

VPC를 최초 생성할 때 CIDR 블록을 통하여 VPC의 크기를 조정할 수 있습니다. 

VPC에서 허용된 CIDR 블록은 16비트부터 28비트까지를 제공합니다. 

 

왼쪽 그림과 같이 VPC의 CIDR 블록을 16비트로 지정했을 때, 총 65,536개의 IP를 사용할 수 있으며, 설정한 VPC 크기에 따라서 서브넷을 생성할 수 있습니다. 

또한 VPC의 CIDR 블록 범위에서 벗어난 IP 또는 서브넷은 생성이 불가능하다. 

VPC는 RFC1918 규격대의 사설 IP범위를 사용하는 것을 권장하며, VPC 생성시 설정한 CIDR 블록의 크기는 늘리거나 줄일 수 없습니다. 

만약 VPC내 IP 주소가 부족할 시 보조 CIDR 블록을 VPC에 추가하여 IP 범위를 확장할 수 있다.  

 

 

++ CIDR이란 무엇인가요?

Classless Inter-Domain Routing(CIDR)은 인터넷상의 데이터 라우팅 효율성을 향상시키는 IP 주소 할당 방법입니다.

인터넷에 연결되는 모든 컴퓨터, 서버 및 최종 사용자 디바이스에는 IP 주소라는 고유한 번호가 연결되어 있습니다.

 

AWS상에서 사용자분들이 배포하는 애플리케이션은 데이터센터에 재난 상황이 발생하더라도 서비스에 영향을 최소화할 수 있도록 고가용성이 보장되어야 한다.

이를 위해 하나의 VPC에서는 최소 2개의 가용영역을 배치하는 것을 권장한다. 

두 개의 가용영역을 사용했을 때, 하나의 가용영역에서 장애가 발생하더라도 고객이 사용 중인 어플리케이션이 중단 없이 신속하게 장애가 조치될 수 있도록 하고, 전체 서비스의 영향을 최소화 할 수 있다. 

 

다음으로 생성한 VPC가 인터넷과의 통신이 필요한 경우에는 인터넷 게이트웨이와 VPC간 연결이 필요하다. 

인터넷 게이트웨이는 IPv4 및 IPv6의 트래픽을 지원하며, 네트워크 트래픽에 별도의 대역폭을 제한하지 않습니다. 

VPC 내의 퍼블릭 IP주소를 갖는 Amazon EC2 인스턴스는 인터넷 게이트웨이를 통해서 인터넷과 통신할 수 있다. 

이를 위해서는 라우팅 테이블에 인터넷 게이트웨이에 대한 라우팅 정보를 추가해야 한다. 

 

 

서브넷은 인터넷과의 통신을 기준으로 퍼블릭 서브넷과 프라이빗 서브넷으로 구분한다. 

 

퍼블릭 서브넷의 경우 인터넷과 직접적으로 통신할 수 있는 네트워크로 온프레미스 환경에서 DMZ와 같은 구간을 의미합니다.

퍼블릿 서브넷에 배치되는 리소스로는 대표적으로 Bastion 호스트 및 NAT Gateway가 있습니다. 

 

프라이빗 서브넷은 외부에서 접근이 불가능한 구간으로 온프레미스에서 서버팜과 같은 구간을 의미한다. 

프라이빗 서브넷에 대표적으로 데이터베이스 서비스인 Amazon RDS를 배치할 수 있다. 

 

 

 

서브넷을 구성할 때 사용하는 용도에 따라 서브넷을 생성하고 배치한다.

그리고 고가용성 확보를 위하여 동일 용도의 서브넷을 여러 가용영역에 배치한다. 

 

예를 들어 웹 서버가 위치할 서브넷을 여러 가용영역에 배치하고, AWS의 로드밸런서 서비스인 Elastic Load Balancing을 통해 네트워크 트래픽을 분산하여 가용 영역 간의 고가용성을 확보할 수 있다. 

 

 



라우팅 테이블은 네트워크 트래픽의 전송 위치를 결정하며, 각 서브넷에 할당된다.

VPC를 생성할 때 자동으로 기본 라우팅 테이블이 생성되고, 라우팅 테이블이 매핑되지 않은 서브넷에 기본 라우팅 테이블이 할당된다. 

그러나 VPC를 운영할 때는 기본 라우팅 테이블이 아닌, 사용자분들이 직접 구성한 사용자 지정 라우팅 테이블을 사용하는 것을 권장한다. 

 

라우팅 테이블은 목적지와 타겟 기반의 간단한 테이블로 구성된다. 

목적지 항목에는 트래픽을 전달할 IP주소를 입력하고, 타겟에는 트래픽을 전달하기 위한 게이트웨이 또는 인터페이스를 입력한다. 

 

 

 

퍼블릭 서브넷의 경우 라우팅 테이블은 로컬 통신을 위한 Local 라우팅과 인터넷과의 통신을 위한 인터넷 게이트웨이 라우팅으로 구성될 수 있다. 

인터넷과의 통신 시에는 모든 IP, 즉 0.0.0.0 대역의 IP를 인터넷 게이트웨이로 전달하여 인터넷과 통신할 수 있도록 라우팅을 설정한다. 

 

 

프라이빗 서브넷의 경우에도 OS 및 어플리케이션 버전 패치와 같이 인터넷과의 통신이 필요할 수 있다. 

이를 위해 퍼블릭 서브넷에 NAT GW를 구성하여 프라이빗 서브넷에 위치한 리소스들도 인터넷과의 통신이 가능하도록 구성할 수 있다. 

NAT GW의 경우 내부에서 외부로의 통신은 가능하지만, 인터넷 외부에서 내부로의 통신은 원천적으로 차단한다. 

 

 

NAT GW를 생성하면 NAT Gateway에 Elastic IP가 할당된다. 

Elastic IP란 인터넷과 연결 가능한 고정된 공인 IP를 의미한다. 

기본적으로 Amazon EC2를 생성할 때 EC2의 IP는 동적으로 할당된다. 

이로 인해 Amazon EC2 인스턴스를 종료 후 재실행했을 때, IP 주소의 변경이 발생한다. 

사용자들의 워크로드 환경에 따라서 인스턴스의 고정된 공인 IP가 필요로 할 경우에 Elastic IP를 생성하여 매핑할 수 있다. 

또한 사용자들이 보유하고 있는 공인 IP를 AWS로 가져와 사용할 수 있는 Bring Your Own IP를 지원한다. 

 

 

올해 2월 AWS에서는 VPC의 구성을 한 눈에 확인할 수 있도록 VPC Resource Map을 발표했다. 

사용 중인 VPC를 Resource Map을 통해서 VPC의 구성 요소와 각 연결 다이어그램을 시각화로 제공한다. 

그림과 같이 VPC Resource Map에서 특정 구성 요소를 클릭했을 때, 다른 구성 요소 간의 관계를 쉽게 확인할 수 있다. 

 

 

다음으로 VPC의 보안 구성 요소에 대해서 알아봅니다.

VPC의 보안을 구성하기 위한 첫 번째 기능으로는 NACL이 있다. 

NACL은 서브넷에 대한 접근 제어 정책을 설정하는 것을 의미합니다. 

하나의 서브넷은 하나의 NACL을 갖게 되고, 하나의 NACL은 여러 서브넷에 매핑할 수 있다. 

NACL을 지정할 경우 서브넷에 위치한 모든 리소스에 적용된다. 

NACL은 Stateless 성격을 가지며, 서브넷으로 들어오는 Inbound Traffic과 Outbound Traffic에 대해 각각 별도로 설정해야 한다. 

Inbound Rule에서 허용된 트래픽이라도 Outbound Rule에 설정되지 않았다면 트래픽에 대해 응답하지 않습니다.

 

 

보안 그룹은 인스턴스의 Elastic Network Interface에 설정된다. 

보안 그룹은 NACL과는 다르게 Stateful의 성격을 갖습니다. 

Inbound Rule에 허용된 트래픽들은 보안 그룹에서 해당 트래픽의 내용을 저장하고, 별도의 OutBound Rule 설정 없이도 트래픽의 응답을 허용한다. 

 

또한 하나의 ENI에 여러 보안 그룹을 설정할 수 있으며, 보안 그룹 정책을 설정할 때 IP 기반 뿐만 아니라, 다른 보안그룹과의 관계를 통해서도 정책을 설정할 수 있다. 

 

 

서브넷에 위치한 리소스들이 다른 서브넷과 통신할 시 NACL과 보안 그룹을 모두 적용받는다. 

순서는 그림과 같이 NACL부터 적용되고 그 후에 보안 그룹이 적용된다. 

서브넷 내부에서 리소스들간의 통신 시에는 NACL은 적용받지 않으며 보안 그룹만 적용된다. 

 

NACL 생성 시 기본 설정은 모든 트래픽이 허용된 상태로 생성된다. 

반면에 보안그룹 생성 시에는 모든 트래픽이 거부된 상태로 설정되며 허용될 포트 및 소스들을 보안 그룹에 설정해야 한다. 

 

 

 

 

 

AWS의 리소스들은 통신을 위한 각각의 DNS 또는 IP 주소를 가지고 있다. 

VPC 내의 리소스들이 AWS 리소스와 통신 시 기본적으로 인터넷을 기반으로 통신한다. 

그러나 인터넷을 기반으로 한 통신에는 알 수 없는 네트워크 홉을 지나고 보안상에도 권장되지 않는다. 

또한 인터넷을 통한 통신 시 VPC에 IGW가 연결되어 있지 않더라면 AWS 서비스와의 통신은 불가하게 된다. 

 

이러한 문제를 해결하기 위해 AWS와의 리소스들은 인터넷이 아닌 AWS 자체 네트워크를 통해서 통신이 필요하다. 

 

 

VPC Endpoint는 AWS 자체 네트워크를 통한 AWS 리소스와의 통신 환경을 제공한다. 

VPC Endpoint는 Gateway 타입과 Interface 타입으로 구분된다.

 

첫 번째로 Gateway 타입은 Routing Table에 경로를 추가하는 방식으로 AWS 리소스와의 통신 환경을 제공한다. 

Gatway 타입을 통해 Amazon EC2 인스턴스가 Amazon S3와 통신할 시 라우팅 테이블에 반영된 경로를 통해, VPC Endpoint로 트래픽이 전달되고 Amazon S3와 통신한다. 

 

Gateway 타입은 Amazon S3와 Amazon DynamoDB만 지원합니다. 

 

Interface 타입은 AWS 서비스와 통신하기 위한 별도의 ENI를 서브넷에 배치한다. 

ENI에는 AWS 리소스와 통신할 수 있도록 사설 IP 주소 및 DNS가 매핑된다. 

 

만약 Amazon EC2 인스턴스가 Amazon SQS와 통신할 시 인터페이스 타입인 ENI를 통해서 통신한다.

Interface 타입은 Gateway 타입과는 다르게 다양한 AWS 서비스들을 지원한다. 

 

다음으로 VPC 간의 통신이다. 

VPC간의 통신은 VPC가 인터넷 게이트웨이와 연결되어 있을 시 인터넷 게이트웨이를 통해 인터넷 기반으로 통신할 수 있다. 

하지만 VPC간의 통신도 인터넷 기반이 아닌 AWS 자체 네트워크를 통한 통신이 필요합니다. 

 

 

VPC 간의 통신을 위해서 가장 간단하게 사용할 수 있는 방안으로는 VPC Peering이 있다. 

연결시켜줄 두 개의 VPC를 VPC Peering으로 연결한다. 

그리고 각 VPC에서 라우팅 테이블을 업데이트하여 VPC 간의 통신을 허용할 수 있다. 

하지만 VPC Peering의 경우 연결하는 VPC 간에 동일한 IP 주소를 사용할 경우 연결에 제약이 있기에, VPC 설계 시 VPC 간 IP 중복이 발생하지 않도록 유의해야 한다. 

 

VPC Peering은 전이적 라우팅이 불가능합니다.

VPC1과 2가 연결되어 있고, 2와 3이 연결되어 있더라도, 1과 3의 통신은 불가능합니다. 

 

 

 

VPC 1과 3의 통신을 위해서는 별도의 VPC Peering 을 생성해 주고, 라우팅 테이블을 추가해 줘야 합니다. 

전체 VPC를 VPC Peering을 통해 연결할 경우, VPC Peering의 수는 n(n-1)/2 만큼의 수가 필요로 합니다.

 

 

VPC 수가 적을 경우에는 VPC Peering으로 VPC 간의 연결을 간단하게 구성할 수 있다. 

 

하지만 위 그림과 같이 VPC의 수가 많을 경우에는 어떻게 될까요?

6개의 VPC인 환경에서는 총 15개의 VPC Peering이 필요로 합니다. 

이처럼 다수의 VPC 환경에서는 VPC Peering 을 통해서는 운영의 복잡성이 발생할 수 있습니다. 

 

다수의 VPC 환경에서 VPC의 연결을 간단히 하기 위해 AWS Transit Gateway를 사용한다. 

 

 

AWS Transit Gateway는 다수의 VPC의 상호 연결을 위한 중앙 허브 역할을 합니다.

다수의 VPC가 중앙의 Transit Gateway로 연결되어 복잡한 VPC Peering 없이도 VPC간 통신을 가능하게 합니다. 

AWS Transit Gateway는 VPC와의 연결 외에도 다수의 온프레미스 네트워크와의 연결도 VPN 또는 전용회선으로 지원합니다. 

 

다음으로 AWS에서 생성한 VPC를 온프레미스 데이터센터 또는 사무실 네트워크와 연결이 필요할 수 있습니다. 

인터넷을 통해서도 네트워크 연결이 가능하지만 보안을 고려했을 때 사설망을 통한 연결이 필요로 합니다. 

 

첫 번째 방안으로는 IPSec VPN 기반의 Site to Site VPN으로 사설망을 구축할 수 있습니다. 

VPC에 Virtual Private Gateway와 온프레미스 데이터센터의 Customer Gateway 간 VPN 연결을 지원합니다. 

Costomer Gateway는 물리적 VPN 장비 또는 소프트웨어 어플라이언스가 될 수 있습니다.

 

 

 

Site-to-Site VPN은 2개의 터널링을 제공하며하나의 터널 당 1.25Gbps의 Bandwidth를 지원합니다. 

두 개의 VPN 터널은 고가용성을 위해 서로 다른 가용영역에 배치되며 하나의 VPN 터널 장애 시 다른 VPN 터널로 자동으로 네트워크를 복구합니다. 

 

AWS VPC와 온프레미스 데이터센터를 전용회선 방식의 Direct Connect 로 연결할 수 있다. 

Direct Connect 연결은 Direct Connect 파트너사를 통해 Direct Connect Location에서 이루어집니다.

DX Location의 AWS 라우터와 고객의 Router를 연결하여 온프레미스와 AWS 백본 네트워크 간의 전용회선 기반의 연결을 지원합니다. 

 

 

Direct Connect의 전용 연결방식은 고객의 라우터는 AWS의 라우터와 물리적으로 직접 연결하는 방식입니다. 

전용 연결 방식을 사용할 경우 최대 100G급의 Bandwidth를 확보할 수 있으며 51개의 네트워크 가상 인터페이스를 사용할 수 있습니다. 

호스팅 연결은 기 구축되어 있는 파트너사의 라우터를 통해서 연결하는 방식입니다. 

최소 50 Mbps부터 최대 10Gbps까지 네트워크 Bandwidth를 사용할 수 있습니다. 

 

 

데모에서 사용할 VPC 아키텍처입니다. 

두 개의 가용영역에 퍼블릭 서브넷과 프라이빗 서브넷을 배치합니다.

그리고 각 가용 영역에는 프라이빗 서브넷이 인터넷과 통신할 수 있도록 NAT Gateway를 퍼블릭 서브넷에 배치합니다. 

마지막으로 AWS 자체 네트워크를 통해서 AWS 리소스와 통신할 수 있도록 VPC Endpoint를 생성합니다. 

VPC 생성 과정을 VPC 생성하기 메뉴로 간단히 진행해 봅니다. 

 

 

1. 올바른 리전 선택

2. VPC 메뉴 이동

- 기본적으로 디폴트 VPC가 생성되어 있는 것을 확인할 수 있다. 

3. VPC 생성 버튼을 눌러 VPC 생성 화면으로 이동한다. 

4. VPC 생성시 VPC만 생성하거나 VPC 외 서브넷과 같은 기타 구성 요소를 함께 생성할 수 있다. 

5. 'VPC등'을 선택하여 기타 구성 요소까지 한 번에 생성합니다.

6. VPC의 이름을 설정한다. 

- 설정한 이름에 따라서 미리보기가 함께 변경되는 것을 확인할 수 있다. 

7. 다음으로 CIDR 블록을 통해서 VPC의 크기를 설정할 수 있습니다. 

8. VPC 가 배치될 가용영역의 수는 기본 설정(2)으로 두고, 가용 영역 사용자 지정을 클릭하여 배치할 가용영역을 수동으로 변경할 수 있습니다.

9. 퍼블릭 서브넷과 프라이빗 서브넷 수는 각 2개씩 지정합니다.

10. 서브넷 CIDR 블록 사용자 지정 버튼을 클릭하여, 각 서브넷의 CIDR 블록을 수동으로 변경할 수 있습니다. 

11. 각 서브넷의 CIDR 블록을 24비트씩 지정하고 하나의 서브넷 당 256 개의 IP를 사용할 수 있도록 지정합니다.

12. NAT GW는 가용 영역당 하나씩 배치되게 설정하고, AWS 자체 네트워크를 통해 Amazon S3와 통신할 수 있도록 VPC Endpoint를 지정합니다.

13. VPC 생성을 위한 모든 설정을 완료하고 우측의 미리보기를 통해 설정이 올바르게 반영되었는지 확인할 수 있습니다.

14. VPC 생성 버튼을 클릭한다. 

15. VPC 메뉴에서 생성한 VPC를 확인할 수 있다. 

16. 생성한 VPC를 클릭한다. 

 

17. 하단 메뉴 중 Resource Map을 통해서 생성한 VPC의 구성 요소와 연결 다이어그램을 확인할 수 있다. 

18. 서브넷 중 프라이빗 서브넷을 하나 클릭한다. 

19. 프라이빗 서브넷으로 이동하여 프라이빗 서브넷의 라우팅 테이블을 확인한다. 

20. 로컬 통신과 NAT GW와의 통신 그리고 Gateway 타입인 VPC Endpoint와의 통신이 라우팅 테이블에 반영된 사항을 확인할 수 있습니다.