AWS SAA 자격증 준비 (4) - 네트워크 (VPC, 네트워크 ACL, 보안그룹, Route 53, ELB)

AWS VPC (Virtual Private Cloud)

AWS는 계정별로 (default) VPC라는걸 갖게 된다. VPC는 어떤 것이며 어떤 용도로 사용될까? 만약 EC2에 웹사이트를 띄웠다면 최종 사용자가 웹사이트에 접근해야할텐데 어떤 네트워크를 열어줄 것인지, 혹은 DB를 띄웠을 때 private망을 어떻게 설계할 것인지를 고민할 때 VPC를 찾게 된다.

VPC는 리소스를 배치하기 위한 격리된 네트워크 공간이다. EC2 등 리소스를 띄워서 사용하게 되는데 일전에 살펴본 서버리스 리소스는 VPC 바깥에 위치하게 된다. VPC는 리전에 한정되어있다. 따라서 여러 리전에 걸쳐서 VPC를 생성할 수는 없다. VPC는 고가용성을 위해 리전당 여러 가용영역에 걸쳐 생성된다. 또한 default VPC는 자동으로 생성되지만 고객이 셋팅하여 변경할 수 있다.

 

VPC는 계정당 리전당 5개까지 생성 가능하나 AWS에 요청하여 limit을 풀 수는 있다고 한다. 하지만 보통 계정을 여러개 생성하여 VPC 개수를 추가한다고 한다. 다중 VPC를 사용하게 되면 보안 강화의 효과가 있다.

 

CIDR

VPC를 처음 생성하면 CIDR (Classless Inter Domain Route)을 설정하라고 한다. CIDR은 사이더 블럭이라고 읽는데 IP주소의 범위를 간략하게 표현한 것이라고 생각하면 된다. 예를 들어 새로 생성하고자 하는 VPC의 CIDR을 10.0.0.0/16 으로 지정하게 되면 IP주소 범위가 10.0.0.0~10.0.255.255인 총 65,536개 IP를 보유한 VPC를 생성하게 되는 것이다. 슬래쉬(/) 뒤에 오는 숫자가 blocking할 단위를 의미하게 되는데 예시로 보자면 10.0.x.x로 10.0 은 고정하고 그 이후 16비트를 변경할 수 있어 총 2의 16가지 IP를 사용할 수 있게 되는 것이다. CIDR 범위는 최소 /16, 최대 /28로 (cf. /32는 1개밖에 사용못함) 설정할 수 있다. CIDR이 잘 와닿지 않는다면 https://cidr.xyz 사이트를 통해 시각화해서 사용 가능한 IP주소 범위를 한눈에 볼 수 있다.

 

Subnet

VPC 내부에는 서브넷(subnet) 을 구성할 수 있다. VPC내부를 가상으로 공간을 분리하는 방법인데, 예시를 통한 이해가 훨씬 쉽다. VPC를 생성하면서 사용할 IP주소 범위는 정하게 되었다. 그런데 VPC안에서 리소스에 따라서 다른 통신 방법을 설계하고 싶은 것이다. 예를 들어 인터넷과의 통신이 가능한 public subnet과 그렇지 않은 private subnet을 구성한다고 하면 public subnet은 대외망 서비스인 애플리케이션 등의 리소스를 배치할 수 있고, private subnet은 데이터베이스 등 외부 접근을 단절할 필요가 있는 리소스를 배치할 수 있다. 예시로 든 public subnet과 private subnet은 AWS에서 가장 흔하게 등장하는 용어이지만 사실상 개념이며 어떠한 서비스가 아니다. 그저 인터넷 게이트웨이(Internet Gateway)가 연결된 subnet을 퍼블릭 서브넷, 아닐 경우를 프라이빗 서브넷으로 부른다. 그리고 AWS는 각 서브넷에서 5개의 IP주소를 예약한다. 즉 서브넷의 CIDR 범위를 지정하면 실제 사용 가능한 IP주소는 5개 차감된 개수로 가능하다. 따라서 서브넷을 설계할 때는 사용하고자하는 IP주소 개수에 +5된 범위로 CIDR을 지정해야한다.

서브넷은 가용영역을 선택할 수 있다. 여러 가용영역을 선택할 순 없지만 여러 가용영역에 동일한 서브넷 구조를 구축한뒤 ELB등으로 트래픽을 분산하면 고가용성을 취할 수 있다.

 

Route Table

서브넷에는 라우팅 테이블(route table)을 설정해야한다. 라우팅테이블은 '목적지(destination)'과 '대상(target)'을 저장하게 되어있는데, 기본적으로 서브넷을 생성하게 되면 VPC 내부 IP주소가 destination, "Local"이 target으 로 설정되어있다. 목적지는 가야할 곳을 알려주는 것인데 앞서 살펴본 예시 VPC에 따르면 default 라우팅 테이블은 10.0.0.0/16, Local로 해당 주소범위는 로컬에 머물라는 의미가 된다. 참고로 default는 삭제가 되지 않는다. 여기에 추가로 인터넷 게이트웨이 설정하기 위해서는 0.0.0.0/0, IGW로 라우팅테이블에 추가해야한다. 이렇게 추가된 라우팅 테이블에 연결된 서브넷은 public subnet이라고 부른다.

 

참고로 라우팅 테이블 생성시에는 어떤 VPC에 연결될 건지만 선택하며, 라우팅 테이블 생성 후 subnet associations로 라우팅 테이블을 서브넷에 연결시켜주게 된다.

 

NAT Gateway

인터넷 게이트웨이에서 더 나아가 NAT 게이트웨이에 대해 잠깐 언급하고 넘어가자. NAT 게이트웨이는 퍼블릭 서브넷에 NAT 게이트웨이를 두고 프라이빗에서 NAT 게이트웨이를 통해 인터넷 통신이 가능하게끔 설정하는 방법인데, 요약하자면 프라이빗 서브넷에서 시작하는 인터넷 트래픽을 허용하는 방법이다. 프라이빗 서브넷 라우팅 테이블에 0.0.0.0/0, NAT로 등록하면 된다. 예를 들어 데이터베이스에서 인터넷을 통신하고 싶을 때 직접적인 통신보다는 퍼블릭 서브넷을 통해 트래픽을 전송하여 인터넷 망으로 전송하도록 설계하는 방식이다.

 

VPC 엔드포인트(Endpoint) : VPC와 서비스간 연결

VPC 엔드포인트란 VPC 기반 서비스가 VPC 엔드포인트를 통해 퍼블릭 서비스에 접근가능하게 해주는 기능을 한다. 공식 문서에도 인터넷 게이트웨이, NAT 디바이스, VPN 연결 등의 필요 없이 VPC와 지원 서비스간의 연결을 설정할 수 있다고 한다. 예를 들어 S3, Dynamo DB 등은 서버리스로 퍼블릭 서비스인데 이러한 서비스와 VPC내부 서비스(ex. EC2)간의 연결이 필요하다면 VPC 엔드포인트를 통해 가능하다. VPC 엔드포인트를 통해 연결되기 때문에 따로 퍼블릭 인터넷 엑세스가 필요하지 않게끔 해준다.

 

VPC 엔드포인트에는 두 가지 종류가 있다.

1. 게이트웨이 엔드포인트(Gateway Endpoint) : 프라이빗 서프넷에 연결된 라우팅 테이블에 연결하고자 하는 서비스의 엔드포인트를 생성하고 그 대상을 라우팅 테이블에 등록한다.

2. 인터페이스 엔드포인트(Interface Endpoint) : AWS 가 소유하고 있는 서비스이거나 온프레미스와 같이 고객이 소유하고 있는 서비스로 전달되는 트래픽에 대한 진입점 역할을 한다. 예를 들어 온프레미스에서 Amazon S3에 엑세스하기 위해서는 인터페이스 엔드포인트가 필요하다. 이 때 VPC내 인터페이스 엔드포인트를 만들어 S3 버킷을 연결하여 온프레미스와 VPC를 Direct Connect 혹은 VPN 연결을 하게 되면 온프레미스와 S3를 연결할 수 있다. 인터페이스 엔드포인트를 사용하는 것 중에 AWS PrivateLink 솔루션이 있다.

 

 

게이트웨이 엔드포인트 (왼)         인터페이스 엔드포인트 (오)

VPC 피어링 (Peering) : VPC간 연결

다른 AWS계정에 속한 VPC끼리의 통신이 필요하다면 VPC 피어링을 활용할 수 있다. VPC피어링은 리전 내부 뿐만 아니라 리전 간 지원도 가능하다. 단 IP공간은 중복될 수 없기 때문에 각 VPC는 다른 범위의 CIDR를 사용해야한다. 뿐만 아니라 교차 계정 지원도 가능하다. 게다가 VPC 피어링은 AWS가 고가용성 구조로 설계해두었기 때문에 단일 장애 지점이 발생하지 않는다.

 

한 가지 더 주의해야할 점은 전이적인 피어링은 지원하지 않는다. 예를 들어 A VPC와 B PVC를 피어링으로 연결, B VPC와 C PVC를 피어링으로 연결하더라도 A VPC와 C VPC는 서로 연결되지 않는다. 이 때문에 만약 풀 메시 피어링 상황(모든 VPC가 서로 VPC에 연결되어있는 full-mesh 구조)이라면 VPC피어링이 아닌 Transit Gateway추천한다. 반면 하나의 공유 애플리케이션을 중심으로 여러 VPC를 연결하는 등의 구조라면 VPC 피어링을 추천한다.

 

VPC Peering

Transit Gateway : VPC간 연결

앞서 살펴보았던 VPC피어링과 비슷한 역할을 한다. 하지만 Transit Gateway는 수백 개의 VPC의 트래픽 흐름과 보안을 관리하기 위한 서비스이다. 최대 5천개의 VPC와 온프레미스 환경을 서로 연결할 수 있다. 한마디로 Traffic Curve 역할을 한다. 이 때문에 앞에서 언급했듯 풀메시 구조라면 VPC피어링보다는 Transit Gateway를 사용하도록 권고하고 있다. Transit Gateway는 거꾸로 활용하여 VPC간 통신을 서로 격리하는 데에도 사용할 수 있다.

 

Transit Gateway는 네트워크 연결하기 위해서 ‘Attachment’를 생성하게 된다. 라우팅 테이블에 목적지와 Attachment를 관리하여 서로 연결지점을 지정하게 된다.

 

 

 

AWS Site to Site VPN

VPC와 온프레미스 VPN서버간 통신시 사용하게 되는 서비스로서 1) 고객 게이트웨이 디바이스와 2) 가상 프라이빗 게이트웨이 두 가지로 이루어져있다. 온프레미스에 고객 게이트웨이 디바이스를 설치하고, VPC에 가상 프라이빗 게이트웨이를 설치하여 서로를 연결한다. 이 때 VPN은 2개의 엔드포인트(터널)를 보유하여 고가용성 구조를 만족할 수 있도록 되어있다.

 

 

 

AWS Direct Connect

아예 물리적인 데이터 센터에서 AWS 리소스까지 광 링크를 구축하는 서비스이다. private 선이고 인터넷 통신이 불가능하도록 구성한다.

 

 

 

 

VPC 내부 인스턴스를 공개적으로 엑세스 가능하도록 설정하는 방법

추가로 VPC 내에서 인스턴스를 공개적으로 엑세스 가능하도록 설정하는 법을 정리하자면 아래와 같다.

1. 인터넷 게이트웨이 생성 후 VPC에 연결

2. 퍼블릭 라우팅 테이블 업데이트 후 서브넷에 연결

3. EC2에 공인(public) IP주소를 할당 (이 때 EC2 stop하고 다시 run하면 IP주소가 바뀜(가상머신이기 때문에 stop하면 IP 등을 릴리스), 이를 피하기 위해서는 탄력IP 발급 필요)

4. EC2의 보안그룹(Security Group)에 http 통신 가능하도록 허용 등록

4까지 완료해야 비로소 EC2가 인터넷 망에 접근이 가능해진다.

 

*탄력적 IP주소 : 변경 안되는 고정적 IP로 사용하도록 하는 서비스. 인스턴스 혹은 네트워크 인터페이스와의 연결이 가능하다. 재연결 즉시 새 트래픽을 디렉션하여 고정적인 IP인 것 처럼 보이게 한다. 리전당 5개로 제한되어있지만 Bring Your Own IP 지원이 되기 때문에 기존에 사용하던 IP를 EC2의 탄력IP 주소로 설정할 수 있다. 탄력적 IP주소는 발급만 받고 사용하지 않더라도 요금이 발생한다는 것에 주의할 필요가 있다.

 

AWS 네트워크 엑세스 제어 목록 (Network Access Control List, NACL)

AWS에는 두 가지 유형의 방화벽이 있다. 하나는 NACL, 다른 하나는 SG이다. 흔히 두 개 서비스를 놓고 서로 비교를 많이 한다.

 

NACL은 subnet 단위의 방화벽이다. 상태비저장(stateless)의 특성을 지니고 있는데, 쉽게 말해서 inbound 트래픽 중에서 OK 했던 트래픽을 기억하지 않기 때문에 outbound 트래픽에 대해 허용 여부를 다시 검사하게 된다. 즉 인바운드와 아웃바운드 트래픽에 대해 명시적인 규칙(허용/거부) 정의가 필요하다. 그렇지 않은 보안그룹에 비해 좀 더 번거로울 수 있다.

 

NACL은 기본적으로 모든 트래픽을 거부하도록 셋팅되어있다. NACL에 제어 목록을 추가할 때마다 규칙번호를 지정하게 되어있는데 규칙 번호 값이 작을 수록 우선 결정권을 갖고 이 우선순위에 따라 순서대로 처리된다.

 

NACL은 인스턴스가 서브넷에 추가될 때 자동으로 적용된다.

IPv4만을 지원하는 VPC에 대한 기본 네트워크 ACL의 예시

 

AWS 보안그룹 (Security Group, SG)

보통 NACL보다 SG를 더 많이 사용하곤 한다. 그 이유는 아래 SG의 특성에 대해 살펴보면 알 수 있다.

 

보안그룹은 리소스 단위의 방화벽이다. 상태 저장 특성에 따라서 inbound rule 설정하면 outbound rule에 써있는 것과 상관없이 inbound rule대로 진행하게 된다. 그래서 보안그룹에 비해 좀 더 설정해야하는 양이 적다.

 

기본적으로 보안그룹은 인바운드 트래픽을 허용하지 않는다. 아웃바운드 트래픽은 모두 허용하도록 되어있다. 그리고 인바운드와 아웃바운드 트래픽에 대해 새롭게 규칙을 추가할 때는 허용할 것만 설정이 가능하다. 즉 Rule에 정의된 트래픽만 허용하도록 되어 있어 특별한 것을 거부할 수는 없다. 작성하면 무조건 허용되는 것이며 기본적으로 전부 거부하도록 되어있다.

 

보안그룹은 인스턴스에 수동으로 지정해주어야한다.

 

default 보안그룹

 

AWS Route 53

AWS의 DNS서비스이다. 도메인 이름을 등록 또는 이전하여 대기시간과 상태확인 후에 사용 시간에 따라 요청을 라우팅하는 서비스이다. 라우팅 정책은 여러가지가 있는데 나열하자면 단순, 장애조, 지리적 위치, 지리적 근접성, 대기 시간 기반, 다중값 응답, 가중치가 있다. 그 중에서 가중치 기반 라우팅은 새 production 환경이 생겼을 때 기존에 운영중이던 prd 환경과 이중적으로 운영하며 새 prd로의 트래픽을 점진적으로 늘리고 싶을 때 사용할 수 있다.

 

AWS ELB (Elastic Load Balancing)

로드밸런싱 서비스로는 ELB가 있다. ELB는 트래픽을 자동으로 분산해주는 서비스로서 사전에 정의된 타겟그룹의 대상으로 트래픽을 분산하여 전송한다. ELB는 리스너와 규칙, 대상으로 이루어져있는데 리스너가 인입된 트래픽을 받아 규칙에 따라 대상으로 나누게 되는 구조이다. ELB는 고가용성을 제공하고 지속적으로 대상의 상태 확인을 하여 정상인 대상에게만 트래픽을 전송하는 상태확인 기능도 제공한다.

 

ELB는 아래와 같이 4가지로 구성되어 있다.

- Application Load Balancer : 7계층 (Application층) HTTP, HTTPS

- Network Load Balancer : 4계층 (Transport층) TCP, UDP

- Gateway Load Balancer

- Classic Load Balancer : VPC 서비스가 생기기 이전의 EC2를 위해서 과거 서비스를 유지

현재에는 ALB를 가장 많이 사용한다. Network Load Balancer는 IP주소나 대상 포트와 같은 네트워크단의 트래픽을 분산하기 위함이다.

 

---

 

그 외 추가로 네트워크 공격과 관련된 대응책 서비스를 간단하게 소개하고자 한다.

 

우선 AWS Global Accelerator라는 서비스가 있다. 이 서비스는 장애가 발생하게 되면 경로를 최적화하여 가장 가까운 AWS 리전으로 패킷 손실을 최소화하고 대기 시간을 낮게 유지한다. 이 서비스와 흔히 CloudFront 서비스가 많이 비교되는데, CloudFron는 7계층 HTTP, HTTPS 콘텐츠 전송 네트워크임에 반면 Acceleartor는 4계층인 TCP 또는 UDP 프록시 트래픽 관리자이다.

 

또한 DDoS 공격이라 하여 (* Denial of Service, 서비스가 안되게 하는 것이 목적. DDoS는 Distributed DoS로서 여러 분산된 컴퓨터로 DoS 공격) OSI 계층 공격이 발생할 경우 AWS Shield라는 서비스로 방어할 수 있다. 뿐만 아니라 AWS WAF 서비스도 마찬가지로 방어가 가능하다. 참고로 AWS Shield Advanced는 공격을 방어하기 위해 과다 트래픽량을 받아들이느라 늘어난 EC2 용량에 대해서는 요금을 부과받지 않는다고 한다.

 

---

첨부된 그림자료는 모두 AWS Docs 출처입니다.