6. AWS 네트워킹(2)

네트워크 연결

가상 프라이빗 게이트웨이(VGW)

Amazon VPC와 다른 네트워크 사이에 프라이빗 연결(VPN)을 설정할 수 있음

- 기본적으로 Amazon에서 시작하는 인스턴스는 고객의 네트워크와 통신할 수 없음, 따라서 VPC에 가상 프라이빗 게이트웨이(VGW)를 연결하고 사용자 지정 라우팅 테이블을 생성 후 VPC에서 원격 네트워크에 액세스하도록 할 수 있음

- VPN연결이라는 용어는 일반적인 용어이지만, VPC설명서에는 VPC와 고객 네트워크 사이의 연결을 뜻함

- AWS는 인터넷 프로토콜보안(IPsec) VPN 연결을 지원함

- VGW는 VPC연결의 Amazon 측 VPN집선 장치

- VGW를 만든 후 VPN 연결을 생성할 VPC에 연결함

 

ON-Premise 네트워크를 AWS로 확장: VPN연결

- VPC의 가상 게이트웨이와 데이터 센터 간에 VPN 연결을 사용한다

- AWS 하드웨어 VPN에서는 기본적인 자동 장애 조치를 지원할 수 있도록 2개의 VPN 앤드포인트가 제공됨

 

ON-Premise 네트워크를 AWS로 확장: 다수의 VPN연결

- 위처럼 고객이 VPN 연결의 고객 측 중복성과 장애조치를 구현할 수 있도록 AWS의 VGW는 다수의 고객 게이트웨이 연결을 지원 및 권장함

- 라우팅 구성 시 고객에게 유연성을 제공하도록 동적 및 정적 라우팅 옵션 둘 다 제공됨

- 동적 라우팅은 BGP 피어링을 사용하여  AWS와 해당 원격 엔드 포인트간에 라우팅 정보를 교환함

 또한 고객이 BGP광고의 가중치(지표), 라우팅 속성 및 정책을 지정하고 네트워크와 AWS간의 네트워크 경로에 영향을 줄 수 있음

 

AWS Direct Connect(DX)

DX는 1 또는 10Gbps의 전용 프라이빗 네트워크 연결을 제공함

DX

데이터 전송 비용 감소

예측 가능한 지표로 애플리케이션 성능 향상

인터넷을 통한 당순한 연결을 넘어 , 중요한 애플리케이션을 위해 AWS 네트워크에 규모, 속도 및 일관성을 가지고 액세스할 수 있는 고유 솔루션

DX는 인터넷을 필요로하지 않는다, 대신 사용자의 ON-Premise 솔루션과 AWS 간에 프라이빗 네트워크 연결을 사용함

DX 사용

DX 사용 사례
하이브리드 클라우드 아키텍처	고객이 소유한 기존 데이터 센터 장비에 액세스해야하는 애플리케이션
지속적인 대용량 데이터 세트 전송	AWS 클라우드와 데이터 센터 간에 전송해야 하는 대용량 데이터 세트에서 작동하는 HPC 애플리케이션의 경우(데이터 센터나 사무실의 위치에서 네트워크 전송의 인터넷 대역폭을 두고 경쟁할 필요가 없음)
네트워크 성능 예측 가능성	애플리케이션 성능 향상 오디오 또는 동영상 스트림과 같은 실시간 데이터 피드에서 운영되는 애플리케이션에 적합하며 일관된 네트워크 성능을 제공
네트워크 전송 비용 절감	대용량 데이터 세트 전송에 DX를 사용하여 인터넷 대역폭을 제한할 수 있음 이를 통해 인터넷 서비스 공급자(ISP)에게 지불하는 네트워크 비용 절감, 인터넷 대역폭 증가 약정 또는 새로운 계약에 비용을 지불할 필요가 없음 또한 DX를 통해 전송되는 데이터는 저렴한 DX 데이터 전송 요금으로 부과되어 네트워크 비용 절감 가능
보안 및 규정 준수	엔터프라이즈 보안 및 규제에 따라 AWS클라우드에 호스팅된 애플리케이션이 프라이빗 네트워크 회로로만 액세스 되도록 한다

 

DX를 사용하여 ON-Premise 네트워크를 AWS로 확장

이점

예측 가능한 네트워크 성능

대역폭 비용 감소

1Gbps 또는 10Gbps 프로 비저닝 된 연결

BGP 피어링과 라우팅 정책 지원

 

크리티컬 워크로드를 위한 AWS DX 복원력

- AWS고객은 더 저렴한 백업 연결과 결합하여 하나 이상의 AWS DX 연결을 AWS에 대한 기본 연결에 사용 가능

 

VPC 연결

- 일반적으로 일부 워크로드를 격리하는 것이 좋음

- 하지만 둘 이상의 VPC 간에 데이터를 전송해야 할 수도 있음

VPC 연결 - VPC 피어링

- 인스턴스는 피어링 연결을 통해 동일한 네트워크에 있는 것처럼 통신할 수 있음

- 프라이빗 IP 주소 사용

- 내부 및 리전 간 지원

- IP 공간은 중복될 수 없음

- 두 VPC간 하나의 피어링 리소스만 해당

-  소유한 VPC에 대해 여러개의 VPC 피어링 연결을 생성할 수있지만 전이적 피어링 관계는 지원되지 않음

- 서로 다른 AWS 계정 간에 설정 가능

- VPC피어링 연결은 두 VPC간에 일대일 관계임

- 위에 다이어그램은 개발 VPC와 테스트 VPC는 서로 페어링 되어있다. 하지만 서로 연결되어 있다고해서 개발용 VPC와 프로덕션용 VPC가 서로 통신할 수 있다는 것을 의미하지 않는다.

 

- 인터넷 게이트웨이 또는 가상 게이트웨이가 필요 없음

- 고가용성 연결, 단일 장애 지점 없음

- 대역폭 병목 현상 없음

- 트래픽은 항상 글로벌 AWS 백본에서 유지됨

 

VPC Peering 규칙

- VPC당 연결의 수에는 제한이 있음

- VPC 피어링은 전이적 피어링 관계 지원 X,

- 동일한 2개의 VPC간에 동시에 두 개 이상의 피어링 연결 생성할 수 없음

- VPC 피어링 MTU(최대 전송 단위)는 1,500바이트

- 리전 간 VPC피어링을 사용하는 트래픽은 전 세계의 AWS백본에 항상 머무르며 퍼블릭 인터넷을 통과하지 않아 일반적인 도용 또는 DDos 공격으로 비교적 자유로움

 

여러 VPC피어링 네트워크 설계 원칙

- 중복되는 CIDR블록 없음

- 필수 VPC만 연결

- 솔루션을 확장 가능성 고려

- 단일 장애 지점이 없는 고가용성설계 구현

 

VPC 연결 - Trensit Gateway

- 단일 게이트웨이로 최대 5,000개의 VPC와 온프레미스 환경 연결

- 네트워크 사이를 이동하는 모든 트래픽 허브역할 담당

- 가용성이 뛰어나고 유연한 관리형 라우팅 서비스

- 멀티캐스트 및 리전 간 피어링 허용

 

Transit Gateway 실행 - 연결

 

Transit Gateway를 이용하여 VPC 3개 연결하기

1. Transit Gateway 설정하기

- Amazon EC2 대시보드를 통해 설정 가능

- 여러 VPC를 연결하는 것이 효과적인 경우가 많으며 대규모 그룹에서 VPC를 연결을 관리하기가 수월해짐

<<Transit Gateway설정>>

2. Attachment 배포하기

Transit Gateway를 효과적으로 사용하기 위해서는 대상 VPC가 있는 가용영역마다 하나의 Attachment배포를 해야한다.

 

3. 라우팅 테이블 확인하기

각각의 VPC 라우팅 테이블에서 트래픽이 Transit Gateway attachment를 향해 외부로 라우팅되는지 확인해야하며

이러한 attachment는 Transit Gateway에 연결됨

<<라우팅테이블 확인, attachement연결>>

4. Transit Gateway 라우팅테이블 생성

Transit Gateway 내부에서 라우팅테이블을 생성하여 적절한 트래픽 분배가 가능하다

<<Transit Gateway 라우팅테이블 설정>>

Transit Gateway 실행 - 격리

VPN소스에서 환경에 대한 전체 액세스 권한을 가지며 VPC간 서로 통신하지 않게 하는 것

 

5. 라우팅테이블 VPN향하기

초기 테이블의 경로를 수정하여 VPN으로 연결한다. 그 후에 VPC간 통신이 중지되고 아웃바운드 액세스를 제공한다.

<<라우팅 테이블을 VPN으로 대상 설정>>

6. VPN에 격리된 환경 생성 후 라우팅테이블 생성

VPN만 연결된 환경을 생성 후 Trans Gateway 내에 다른 라우팅 테이블을 추가한다.

이 때 VPN에서 각 VPC을 향하도록 라우팅 테이블을 설정하는 것이 중요하며 교차 통신 없는 격리되고 안전한 VPN 액세스 설정이 완료된 것이다.

<<VPN리우팅테이블 설정>>

 

VPC 엔드포인트

AWS를 벗어나지 않고 EC2 인스턴스를 VPC 외부 서비스와 프라이빗하게 연결하는 것

- 인터넷 게이트웨이, VPN, NAT 디바이스 및 방화벽 프록시를 사용할 필요가 없음

- 동일한 리전에 있어야함

- 엔드포인트는 가상 디바이스수평적으로 확장하며 가용성이 높은 중복 VPC구성 요소로서 가용성 위험, 네트워크 트래픽에 대한 대역폭 제약으로 부터 자유로워 VPC의 인ㅅ스턴스와 서비스간 통신 가능

두 가지 유형의 엔드포인트
인터페이스 엔드포인트	지원되는 서비스로 향하는 트래픽의 진입점 역할을 하는 프라이빗 IP 주소가 할당된 탄력적 네트워크 인터페이스 ㆍAmaonzon EC2 API ㆍElastic Load Balancing API
게이트웨이 엔드포인트	라우팅 테이블의 지정된 라우팅의 대산인 게이트웨이이며, 지원되는 AWS 서비스의 트래픽에 사용됨 ㆍAmazon S3 ㆍAmazon DynamoDB

 

VPC 외부에서 부터 VPC 엔드포인트로 액세스하기

DNS서버가 S3를 내부 ELB 로드 밸런서로 확인하도록 구성

기업 도메인 서비스(DNS)

- 원격 네트워크에서 VPC 엔드 포인트를 사용하는 첫 번째 단계는 엔드포인트를 통해 리 디렉션할 트래픽을 식별하는 것이다.  기업 DNS 서버를 사용하여 VPC엔드 포인트 전용 트래픽에 대한 DNS확인을 무시한다.

 

ELB(Elastic Load Balancing)

- 수신되는 S3 TCP, UDP 연결을 여러 EC2 프록시 인스턴스로 자동 분산기킴 

- S3 트래픽을 여러 프록시 서버로 분산하는 데 필요한 로드 밸런싱을 원할하게 제공하여 프록시 팜의 내결함성 수준을 개선할 수 있음

 

프록시 팜 

- S3 트래픽을 VPC 엔드포인트로 *프록시함

- ACL을 사용하여 VPC 엔드포인트 트래픽에 대한 추가 제어를 제공할 수 있음

 

*프록시 : 다른 서버 상의 자원을 찾는 클라이언트로부터 요청을 받아 중계하는 서버

 

AWS 기반 로드 밸런싱

- 수신되는 애플리케이션 트래픽을 여러 EC2인스턴스, 컨테이너 및 IP 주소에 걸쳐 분산하는 관리형 로드 밸런싱 서비스

- 웹 계층의 기반은 아키텍처에서 ELB를 포함

- AWS가 제공하는 관리형 모니터링 서비스인 Amazon CloudWatch로 지표 전송

- EC2 및 ELB의 지표는 트리거의 역할을 할 수 있음

<<ELB 역할>>

ELB 기능

ㆍHTTP, HTTPS, TCP, UDP 및 SSL(보안 TCP, UDP)프로토콜을 사용함

ㆍ외부 또는 내부에 위치할 수 있음

ㆍ각 로드 밸런서에 DNS이름이 부여됨

ㆍ비정상 인스턴스를 인식하고 이에 대응함

ㆍ내결함성에 필요한 고가용성, 자동확장/축소, 강력한 보안을 갖추고 있음

ELB 옵션
Application Load Balancer	요청수준(계층 7)에서 운영됨	HTTP HTTPS
	콘텐츠기반 라우팅을 지원하고 컨테이너에서 실행되는 애플리케이션 지원
	HTTP 또는 HTTPS를 통해 기본 Web Socket을 지원함
	대상이 EC2 인스턴스이던지 컨테이너이던지 관계없이 확인함
Network Load Balancer	연결 수준(계층 4)에서 운영됨	TCP TLS UDP
	애플리케이션에 대한 탁월한 성능 및 정적 IP
Classic Load Balancer	여러 가용 영역의 EC2 인스턴스 사이에서 기본적인 로드 밸런싱을 제공하며, OSI의 요청 수준 및 연결 수준 모두에서 작동함	이전 세대 (HTTP, HTTPS 및 TCP용)

 

ELB 장점

ELB장점
고가용성	트래픽을 여러 가용 영역에 있는 대상들(EC2 인스턴스, 컨테이너, IP주소)에 자동으로 분산함
상태확인	ㆍ상태 확인 - 로드 밸런서는 주기적으로 EC2의 가용성 확인을 위해 핑을 보내거나, 연결 및 요청을 시도하여 EC2 인스턴스를 테스트함 ㆍ HTTP 상태코드 200으로 응답해야 ELB는 정상으로 간주함
보안기능	VPC내에 프로비저닝된 ELB는 보안 그룹과 같은 네트워크 보안 그룹을 활용할 수 있음
TLS종료 (전송 게층 보안 종료)	통합 인증 관리 및 SSL 복호화를 지원하여 사용자가 Load Blanacer의 SSL설정을 중앙 집중식으로 관리하고 애플리케이션으로부터 CPU 집약적 작업을 오프로드할 수 있는 유연성 제공

 

고가용성

- 애플리케이션은 허용되는 성능 저하 시간 내에 장애로부터 복구하거나 보조 소스로 이동할 수 있는 기능

- 모든 기능은 장애가 발생할 수 있다는 가정을 두고 역방향으로 설계

- 가능한 모든 지점에 중복성을 구현하여, 단일 장애로 인해 전체 시스템이 중단되지 않도록 함

가동률	연간 최대 가동 중간	일일 기준 가동 중단 시간
90%	36.5일	2.4시간
99%	3.65일	14분
99.9%	8.76시간	86초
99.99%	52.6분	8.6초
999.999%	5.25분	0.86초

 

알맞은 가용 영역 설계 개수

- 대부분의 애플리케이션은 리전 당 두개의 가용 영역을 지원하도록 설계 가능

- 기본/보조 장애 조치만 지원하는 애플리케이션의 경우 리전에서 3개 이상 가용영역에 리소스를 복제할 필요 x

- 한 가용 영역의 리소스에 접근할 수 없더라도 다른 애플리케이션의 정상 작동을 위해 ELB가 비정상 인스턴스로 트래픽 분배를 중단함

 

다중 리전 고가용성 및 DNS

Amazon Route 53

- 가용성과 확장성이 뛰어난 클라우드 Domain Name System(DNS) 서비스

DNS

DNS는 도메인 이름을 IP주소로 변환함 - example.com -> 192.0.2.1

도메인 이름을 구입하여 관리하고 DNS설정을 자동으로 구성할 수 있음

AWS에서 유연한 고성능, 고가용성 아키텍처를 위한 도구를 제공함

멀티플 라우팅 옵션

 

Route 53과 고가용성

SLA가 엄격하거나 애플리케이션에 빠른 장애 조치를 취해야할 경우 아키텍처에 Global Accelerator를 추가

* Global Accelerator

- 장애조치에서 DNS의 역할을 제거하여 네트워크 복원력 상승

- 사용자와 애플리케이션을 캐싱 문제로부터 보호 및 즉각적인 조치로 트래픽을 정상 엔드포인트로 리디렉션

- 고정 진입점 주소를 제공하여 사용자와 가장 가까운 엣지로케이션에 트래픽 수신 유도

 

Route 53 라우팅 옵션

Route 53 옵션
간단한 라운드 로빈	- 다수의 요청을 모든 참여 서버로 최대한 균일하게 분산
가중치 기반 라운드 로빈	- 각 응답이 처리되는 빈도를 지정하기위해 리소스 레코드 세트에 가중치를 할당할 수 있음, 따라서 소프트웨어를 변경한 서버로 소규모 트래픽을 전송하여 A/B 테스트 수행 가능 ex) 하나의 DNS와 연결된 A와 B 레코드에 각각 가중치 3과 1일 부여한다. 이 경우 Route53은 A에 75%에 가중치 3레코드 세트를 반환, 나머지 25%는 가중치 1 레코트 세트를 반환함(가중치는 0~255사이)
지연시간 기반 라우팅 (LBR)	- 전 세계 사용자를 대상으로 애플리케이션 능력 향상가능 - 애플리케이션이 실행되고있는 여러 리전의 성능 측정치를 기준으로하여 가장 빠른 환경을 제공하는 AWS 엔드포인트(EC2 인스턴스 및 탄력적 IP주소 및 로드 밸런서)로 고객을 라우팅함
상태확인 및  DNS 장애조치	- 웹 애플리케이션, 웹 서버, 기타 리소스의 상태 및 성능을 모니터링함
지리 위치 라우팅	- 사용자의 지리적 위치에 따라 트래픽을 지원할 리소스를 선택 가능 - 지리 위치 라우팅 사용 시 콘텐츠 현지화 및 사용자의 언어로 표시 가능 - 배포권한이 있는 위치에만 콘텐츠 배포 제한 가능
지리 근접 라우팅	- 사용자와 리소스 사이의 물리적 거리를 기반으로 트래픽 라우팅 할 수 있음 - 양 또는 음의 바이어스를 지정하여 각 리소스로 라우팅되는 트래픽 증감할 수도 있음