ELB, Amazon Route 53, Amazon 네트워킹 (VPC 피어링, VPC 엔드포인트)

지난 포스팅에서는 AWS 네트워킹 중 VPC 구성 방법과 VPC Peering에 대해 살펴보았습니다.

이번 포스팅에서는 보다 나아간 네트워킹 연결 방식과 VPC 엔드포인트 그리고 로드 밸런싱과 고가용성 확보 방안에 대해 살펴보도록 하겠습니다.

 

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

 

지난 시간에 살펴보았던 Non-VPC 서비스인 S3는 리전 영역의 서비스로 S3에 저장되어 있는 데이터를 호출하기 위해 매번 인터넷 게이트웨이를 통해 외부로 나갔다가 다시 들어와야 하는 말도 안되는 구성을 해야만 하는 상황입니다.
이는 성능상에 오버헤드를 발생시킬 수 있어 이를 지원하기 위한 VPC 엔드포인트 서비스가 등장하였습니다.

지금부터 하나하나 살펴보도록 하겠습니다.

네트워크 연결

1. 가상 프라이빗 게이트웨이 (VGW- VPN Gateway)

- Amazon VPC와 다른 네트워크 사이에 프라이빗 연결(VPN)을 설정할 수 있으며, 내부적으로 두개의 엔드포인트를 생성하여 VPN을 통해 고객 게이트웨이와 연결할 수 있습니다.
- 1:1 또는 1:다 연결이 가능하고, 각각 Destination 당 2개의 엔드포인트를 생성합니다.

 

2. AWS Direct Connect (DX)

- 전용 프라이빗 네트워크 연결을 제공(1 또는 10Gbps)하여 빠른 전송속도와 데이터 전송 비용 감소 효과를 얻을 수 있으며, 예측 가능한 지표로 애플리케이션 성능 향상 효과를 가져옵니다.
- 하이브리드 클라우드 아키텍처에 사용되는 방식으로 지속적인 대용량 데이터 세트를 전송하고 네트워크 성능 예측 가능성을 높일 수 있습니다.
- DX 로케이션을 선택하여 고객 데이터센터와 AWS 네트워크를 연결할 수 있습니다.
ex) Amazon VPC <-> VPN 게이트웨이 <-> AWS Direct Connect <-> 고객 DX 디바이스 <-> 고객 데이터센터

# 온 프레미스 환경 & AWS 통합 구성 방안 아키텍처

AWS Direct Connect를 이용한 온 프레미스 환경을 AWS 환경으로 연동하여 확장하는 아키텍처입니다.

---

---

위 이미지는 온 프레미스로 구성되어 있는 기존 데이터 센터(오른쪽)와 AWS 환경을 연결하는 AWS Direct Connection의 아키텍처입니다. 크게 특이사항이라고 할 것은 없지만, 전용 연결망을 구성하기 위한 별도의 통신 / 호스팅 업체의 협업이 필요합니다. (DX Partner)

또한 전용선으로 연결하는 AWS DX에 대한 장애 복구 정책으로 VPN Connection을 사용하여 온 프레미스와 AWS 간의 연결을 보장하고 유지할 수 있습니다.

3. VPC 연결 1 - VPC 피어링

앞장에서 살펴보았던 VPC 피어링 입니다. VPC는 독립된 가상의 네트워크 공간인데, 이러한 VPC끼리 연결하기 위한 통신 방법으로 VPC Peering을 제공합니다.

- VPC 피어링은 프라이빗 IP 주소를 사용하여 인터넷 공간으로 나가는 것은 아닙니다.
- IP 공간은 중복 될 수 없어 VPC 간 CIDR을 검토하고 연결을 시도해야 합니다.
- 또한 전이적 통신은 불가하여 A VPC <-> B VPC <-> C VPC일 경우 A VPC에서 C VPC를 통신할 수는 없습니다.
- 서로 다른 AWS 계정 간 및 다른 리전간에 설정이 가능합니다.
- 대역폭 병목이 없어 고가용성을 위한 이중화 등을 고려할 필요가 없고 쌍방간에 라우팅 통신이 설정되어 있어야 통신이 가능합니다.

# VPC 피어링과 VPN을 통한 공유 서비스 구성 아키텍처

VPC 간 또는 리전 간 통신을 지원하는 VPC 피어링과 하이브리드 클라우드 형태의 종합 아키텍처를 소개합니다.

---

---

VPC 피어링의 특징은 1:1 VPC 연결이라는 특징을 같고 있습니다. 보다 확장성 있고 간결한 구성을 필요로 할 경우 다음 Transit Gateway를 고려하도록 합니다. 한국 리전에서는 5월 정식으로 Transit Gateway를 서비스 하기 시작했습니다.

 

4. VPC 연결 2 - Transit Gateway

Transit Gateway는 5000개의 VPC와 온프레이스 환경에 연결할 수 있습니다.
VPC 피어링은 메쉬 토폴로지 구성을 해야 하나 트랜짓 게이트웨이는 공통 공간에 라우팅과 같은 개념의 Transit을 구성합니다. VPC는 로컬 처리와 나머지를 Transit Gateway로 보내기 위한 라우팅 테이블을 구성하고, Transit Gateway에는 각각의 목적지 엔드포인트를 라우팅 테이블에 구성합니다.
- VPC 간의 통신을 차단하고 온-프레미스로만 연결하고자 할 경우
아웃바운드 Transit Gateway의 라우팅 테이블에 0.0.0.0/0 등록, 인바운드 Transit Gateway의 라우팅 테이블에 VPC CIDR 등록
- 이를 적절히 사용하면 공통 모듈 등을 특정 위치의 VPC에 두고 서로 같은 리전의 다른 VPC 간 또는 서로 다른 리전의 VPC 간 또는 VPN을 통한 온프레미스 데이터 센터와의 공통 모듈 사용을 할 수 있도록 구성할 수 있습니다.

# Transit Gateway를 활용한 VPC 간 통신 격리 및 온 프레미스와의 연동 구성 아키텍처

Transit Gateway를 통해 VPC 간의 통신을 허용하는 것은 매우 간단한 일입니다. 이를 반대로 VPC 간의 통신은 격리하면서도 외부의 온 프레미스 환경과의 연결 설정을 허용하는 방식으로 아키텍처를 구성하면 다음과 같은 아키텍처를 설계할 수 있을 것입니다.

---

---

위와 같이 구성하면 VPN에 등록된 각각의 라우팅 테이블은 로컬과 Transit Gateway의 엔드포인트를 갖게 되며, Transit Gateway는 AWS VPC를 통해 들어온 요청의 경우 0.0.0.0/0으로 외부로 연결하고, 외부 온 프레미스로부터 유입된 요청의 경우 내부 VPC로 라우팅하는 방식으로 상호간 연결 설정을 구성합니다.

 

5. VPC 엔드포인트

앞서 논의 된 Amazon S3와 같은 동일 리전에 있는 Non-VPC 서비스와의 통신을 할 경우 AWS를 벗어나지 않고 EC2 인스턴스를 VPC 외부 서비스와 프라이빗하게 연결합니다.

이 방법은 앞서 살펴본 NAT Gateway를 통한 인터넷 게이트웨이, VPN, 방화벽 프록시 등을 사용할 필요 없이 손쉬운 접근을 제공합니다.

당연한 이야기지만 별도의 요금이 부가됩니다. 이는 완전 관리형으로 가용성과 확장성이 매우 뛰어납니다.
- 게이트웨이 엔드포인트 방식 : S3, DynamoDB가 있음 (라우팅 테이블에 등록하여 엔드포인트를 지정하는 방식)
- 인터페이스 엔드포인트 방식 : CloudWatch Logs, CodeBuild, EC2 API, ELB API, AWS KMS, Kinesis, AWS Service Catalog, Amazon SNS, AWS Systems Manager (프라이빗 인터페이스가 하나 더 추가되어 통신하는 방식)
- 온 프레미스와 S3 간의 통신을 해야 하는 경우
=> Amazon S3 <- 게이트웨이 엔드포인트 <- 프록시 팜 <- ELB <- 인터페이스 엔드포인트 <- VPN <- ELB Resolution 호출 <- DNS를 통해 온프렘 애플리케이션에서 도메인 호출

# VPC 엔드포인트를 활용한 외부 리소스 S3로 접근하는 아키텍처

---

---

위와 같이 온 프레미스 서버와 VPC 간 VPN Gateway로 연결을 하며, VPN은 ELB - 프록시 팜 - VPC 엔드포인트를 통해 AWS S3로 접근할 수 있습니다.

AWS 기반 로드 밸런싱

1. Elastic Load Balancing (ELB)

- 관리형 로드밸런싱 서비스
- HTTP, HTTPS, TCP, SSL 지원
- DNS 도메인이 부여됨
- 비정상 인스턴스를 인식하고 대응함

	Classic Load Balancer	Application Load Balancer	Network Load Balancer
처리 Layer	L4, L7	L7	L4
처리 방식	EC2 Classic 네트워크 내에 구축 된 기존 애플리케이션 용	경로기반 애플리케이션 포워딩이 가능함 (/orders, /images, /registration 등 Context 기반 라우팅 가능)	TCP 수준의 로드 밸런싱
성능	일반적인 성능	좋은 성능	탁월한 성능 및 정적 IP

ELB의 필요성
- 고가용성, 상태 확인, 보안 기능, TLS 종료

2. Connection Draining
- 장애 발생 시 장애 발생한 인스턴스로 포워딩 하지 않고 정상 서버로만 전송
- Scale-In을 시킬 경우 클라이언트의 연결을 대기하고 이후 종료 시키는 방식 제공
- 서비스의 고가용성을 확보할 수 있음

고가용성

Five Nines (99.999%) 이상의 가용성을 보장할 경우 고가용성이라고 일반적으로 이야기 합니다. 1년 365일 기준으로 Five Niens% 가용성을 지킬 경우 1년 중 5.25분 다운타임이 발생할 수 있으며, 하루 기준 0.86sec 다운이 발생한다고 가정할 수 있습니다. 물론 이러한 기준은 사이트 마다 다르며 보다 높은 가용성을 확보하기 위해서는 그만큼 커다란 돈이 든다는 사실에는 오랜 기간 IT를 진행하면서 불변의 진리로 남아 있습니다.

자 그렇다면 고가용성을 확보하기 위해서는 어떻게 접근해야 할지 한번 살펴보겠습니다.
1) 모든 기능은 장애가 발생한다는 가정하에 역방향으로 설계
2) 장애 발생 구간을 SPOF(single point of failure)
3) 모든 구간이 SPOF가 될 수 있음을 고려함
4) 일반적인 모범사례로는 이중화 다중화를 고려하여 설계 함
5) 데이터베이스의 경우 Active-Standby로 데이터 복제하여 Master가 중지되었을 경우 자동 Fail-Over가 될 수 있도록 구성
6) AZ의 경우도 2개 이상 구성
7) ELB를 통해 로드 밸런싱 할 수 있도록 구성
8) ELB는 외부 요청을 로드밸런싱 하거나, 내부 웹 와스 연동 간 메시 역할을 대신 해주는 로드밸런싱 역할도 수행할 수 있음

Amazon Route 53

Amazon Route53은 가용성과 확장성이 뛰어난 클라우드 DNS 서비스입니다.
엣지 로케이션에 배포 된 서비스로 고가용성은 100%라고 봐도 무방할 정도입니다.
라우팅 옵션으로는 기본 라운드 로빈, 가중치 기반 라운드 로빈, 지연 시간 기반 라우팅(RTT 기반 : Round Trip Time), 지리 위치 라우팅, 트래픽 바이어스를 통한 지리 근접 라우팅, 다중 값 응답, 상태 확인 및 DNS 장애 조치 등을 다중 설정으로 적용 가능합니다.
이를 통해 블루-그린 배포도 가능해 졌습니다.
A버전의 리전 1과 B버전의 리전 2를 배포하고 B의 가중치를 10에서 100퍼센트로 늘려가며 두 버전을 동시에 서비스하며, 피드백을 받고 오픈하는 방식으로 가중치 기반 라운드 로빈을 적용할 수 있습니다.

# Route53과 ELB를 활용한 고가용성 확보 아키텍처

---

---

Route53은 고가용성을 위한 빠른 장애조치를 지원하여 DNS의 상태 확인 후 다른 리전에 백업되어 있는 환경으로 DNS를 이관합니다.

네트워크 보안

지금까지 다양한 패턴의 네트워크 아키텍처를 살펴보았습니다.

이외에도 Transit Gateway(n:n 연결 가능)와 Direct Connect(1:1 연결 가능)를 연결하여 보다 넓은 범위의 아키텍처를 설계할 수도 있지만 이번 포스팅에서는 다루지 않도록 하겠습니다.

여러분의 상상에 맞기구요.

제가 앞선 포스팅 그리고 이후에도 계속 강조할 네트워크 보안에 대한 내용을 추가로 살펴보도록 하겠습니다.

다양한 아키텍처를 설계함에 있어 보안과 관련된 Component 들은 다음과 같습니다.

- AWS Shield

- EC2 보안 그룹

- 네트워크 ACL

- ELB

- UTM

- WAF

- DMZ 망을 구성하여 DDoS 장비, UTM, WAF등을 병렬로 구성하는 방안

모든 보안 요소들을 다뤄보고는 싶지만, 간단히 이번에도 아키텍처를 그려보고 설명해 보도록 하겠습니다.

---

---

위 아키텍처는 인터넷 공간에 위치한 사용자가 요청을 처리하는 프로세스를 나타냅니다.

검정색은 Request에 대한 유입과정이며, Internet Gateway → External ELB → UTM → Internal ELB → WEB Server → Internal ELB → WAS Server 순으로 요청이 유입됩니다. 이때 EC2 보안 그룹과 ACL에 대한 정책 역시 함께 적용됩니다.

빨간색은 Response에 대한 처리과정으로 Outbound 트래픽은 UTM을 통해 통제됩니다.

초록색은 VPC 외부에 위치하는 Non-VPC 서비스인 S3에 접근하는 과정으로 Internet Gateway를 통해 접근하거나 VPC 엔드포인트로 직접 접근할 수 있습니다.

외부 로드밸런서로는 고정 IP 사용이 가능하고 고성능 처리를 제공하는 NLB로 구성하고 내부 로드밸런서로는 경로기반 라우팅이 가능한 ALB를 구성하였습니다.

가용성 확보를 위해 위와 같은 구조를 서로 다른 리전 또는 다중 VPC를 구성할 수 있으며, 서로 다른 도메인을 같은 VPC 내부에서 처리하기 위해 Route53을 적용할 수도 있습니다.

또한 필요할 경우 CDN 서비스인 CloudFront도 적용할 수 있을 것입니다.

네트워크 보안을 위해 기존부터 고려해왔던 DMZ Zone에 대한 고려는 사실 매우 중요한 부분이라고 할 수 있습니다.

AWS 서비스 자체만으로는 보안을 완벽히 수행하지 못한다고 믿는 고객에게 , WAF, UTM 등의 보안 구성과 내부망의 Private Subnet을 연결하는 유일한 통로 역할을 하기 때문입니다. DMZ Zone에서는 CDN 서비스 등을 수행하여 보다 빠른 성능을 제시하기도 합니다. 또한 SSH 등의 접근을 위한 방식도 Bastion 등의 접근 제어 솔루션을 구성하여 보다 안전한 관리를 수행할 수 있습니다.

 

관리자는 Direct Connect를 통해 Transit Gateway에 접근하고 Transit Gateway는

- Shared Service VPC Zone의 접근제어 시스템 (Bastion, DB 접근제어 등)

- DMZ VPC Zone의 UTM(public), WAF(private)

- Protect VPC Zone의 Private Subnet(WEB/WAS)

를 연결해 주고

사용자는 Route 53을 통해 IGW / CloudFront로 접근하여 마찬가지로  UTM -> Transit Gateway -> Protect VPC Zone에 접근하도록 구성할 수 있습니다.

Transit Gateway와 Direct Connect 간의 연결을 사용할 수 없을 경우 Direct Connect는 직접 모든 VPC와 1:다 연결을 수행합니다.

이를 간략한 구성으로 재정의해 보자면,

관리자는

외부에서 VPN Gateway를 통해 Shared Service VPN Zone의 Bastion에 접근하고,

사용자는

외부에서 Route 53 -> Internet Gateway로 접근한다고 볼 수 있습니다.

 

이번 포스팅에서는 다양한 Amazon 네트워킹 Component에 대해 살펴보았습니다.

VGW, DX, VPC 피어링, Transit Gateway부터 로드 밸런싱을 위한 ELB (ALB, NLB, CLB), 장애 가용성을 위한 Connection Draining 그리고 고가용성 확보를 위한 다양한 적용 가이드와 Amazon Route 53에 대해 살펴보았습니다.

항상 강조하지만 AWS에서 가장 중요한 부분은 AWS Component를 이해하는 것도 중요하지만, 네트워크를 어떻게 설계하고 이를 기반으로 Component를 배치할 것인지 고민하는 것입니다.

다음시간에는 IAM 권한 인증 관리 방안에 대해 살펴보겠습니다.