네트워킹 서비스 범위
- 가용 영역과 리전
가용 영역(AZ)은 여러 데이터 센터로 구성된 지역 단위이다.
가용 영역은 다른 가용 영역과 전용선으로 연결된다.
전용선은 클라우드 서비스만을 위한 케이블을 뜻하는데,
때문에 선이 낼 수 있는 최대한의 효율을 동원할 수 있다.
리전(Region)은 가용 영역들의 집합으로,
예를 들어 우리는 4개의 가용 영역으로 구성된 서울 리전을 쓴다.
- 엣지 로케이션
특정 미디어 서비스가 저장되어 있는 리전에서
멀리 떨어진 곳에서는 접근에 지나치게 많은 시간이 소모된다.
이를 막기 위해 미디어서비스를 캐싱해 놓은 장소를 엣지 로케이션이라고 한다.
이 방식으로 제공되는 컨텐츠 네트워크를 CDN(Contents Delivery Network)라고 한다.
이외에도 DNS 서비스 제공에 주로 쓰이는 방법이다.
가상 프라이빗 네트워크(Virtual Private Cloud)
클라우드에서 만들어 내는 가상의 네트워크 공간으로,
이 안에서 클라우드 리소스를 생성 및 사용하게 된다.
이를 AWS와 GCP에서는 VPC,
Azure에서는 VNet으로 지칭한다.
실습은 AWS 중심으로 이루어지므로 앞으로는 VPC로 통일해서 언급하자.
VPC를 생성하는 과정은 4단계로 나눌 수 있다.
1. 리전 지정
2. IP 주소 범위 지정
3. 가용 범위 지정
4. 원하는 개수의 서브넷 생성
이중에 2번과 4번 과정을 눈여겨 볼 필요가 있다.
- IP 주소 범위 지정
VPC는 기본적으로 프라이빗 IP이므로,
UN에서 정한 프라이빗 IP 주소 범위 내에서 지정해야 한다.
이후 설정에서 CIDR 체계 기반으로 IP를 할당하게 될텐데,
이때 일반적으로 /16 ~ /24 사이에서 가상 네트워크 크기를 지정할 수 있다.
결정한 범위 내에서만 호스트 IP를 할당할 수 있고,
VPC가 생성된 이후에는 CIDR을 변경할 수 없다.
그렇기에 가급적 넉넉한 범위(/16에 가깝게)로 지정해 주는 것이 좋다.
- 원하는 개수의 서브넷 구성
2단계에서 설정한 범위에 속한 서브넷을 만든다.
이때 인터넷 접근이 가능하도록 만들거나(Public), 불가능하게 만들 수(Private) 있다.
web 서버 기능의 VM은 Public으로,
WAS, DB 서버 기능의 VM은 Private으로 생성하는게 보안상 좋겠지?
(여기서 WAS, DB 서버를 분리하면 그게 3Tier 아키텍처다.)
프라이빗 서브넷을 만들면,
라우팅 테이블 상에 인터넷 게이트웨이로 향하는 경로가 없다.
반면 퍼블릭 서브넷은 경로가 있어야겠지?
따라서 우리는 퍼블릭 서브넷을 구성할 때 3가지 작업을 추가로 해야 한다.
① 인터넷 게이트웨이 설정
② 라우팅 테이블에 인터넷 게이트웨이로 향하는 경로 설정
③ 인스턴스에 퍼블릭 IP 추가 할당
< 라우팅 테이블과 인터넷 게이트웨이 >
ⅰ. 라우팅 테이블
서브넷의 네트워크 트래픽이 향하는 방향을 결정하는 규정이다.
VPC 생성 시 모든 서브넷에 적용되는 기본 라우팅 테이블이 생기고,
서브넷마다 사용자 정의 라우팅 테이블을 만들어 따로 연결시킬 수 있다.
ⅱ. 인터넷 게이트웨이
말 그대로 인터넷으로 향하는 관문.
VPC와 인터넷을 이어 주는 통로이다.
라우팅 테이블에 여기로 가는 경로가 정의되어 있을 때,
그 라우팅 테이블에 연결된 서브넷이 바로 퍼블릭 서브넷이다.
이때 주의해야 할 것이,
하나의 서브넷마다 예약된 IP 주소가 있으므로 이것들은 VM의 IP 주소로 쓸 수 없다.
.0 : 네트워크 주소
.1 : VPC 라우터용
.2 : DNS 서버 용도
.3 : AWS에서 추후에 쓰기 위해 예약
.255 : 네트워크 브로드캐스트 주소
- NAT 게이트웨이
위와 같이 서브넷을 설정하면 하나의 문제를 만날 수 있다.
프라이빗 서브넷이라 하더라도
OS 업데이트 등의 이유로 VPC 외부로 트래픽을 보낼 일이 있기 때문이다.
이때 사용하는 것이 NAT 게이트웨이이다.
이것은 네트워크 주소를 변환해주는 서비스(Network Address Tranformation)으로,
프라이빗 서브넷의 인스턴스가 외부로 트래픽을 내보내려고 할 때
이것의 프라이빗 IP를 잠깐 퍼블릭 IP로 변환해 준다.
물론 트래픽을 들일 때는 반대로 수행한다.
- EIP와 ENI
VPC 구축 시 권장되는 점이 탄력적(Elastic)으로 구축하는 것이다.
여기에 해당하는 것이 두 개 있는데,
탄력적 IP(Elastic IP, EIP)와 탄력적 네트워크 인터페이스(Elastic Network Interface, ENI)이다.
< EIP >
서비스가 외부 클라이언트와 통신할 때,
나의 IP가 고정적이어야 하는 경우가 많다.
하지만 VPC 인스턴스의 퍼블릭 IP는 기본적으로 동적이기 때문에
가상머신이 중지되거나 재시작되었을 때 변한다.
이때 EIP를 사용하면 변하지 않는 고정적 IP를 확보할 수 있다.
다만 주의할 점이 있는데,
일단 AWS 계정마다 리전당 5개라는 제한이 있고,
EIP가 연결된 인스턴스가 중지되어 있는 동안에 요금이 발생한다.
따라서 EIP를 사용하지 않을 때는 릴리즈를 통해 연결을 끊어 놓아야 한다.
< ENI >
네트워크 인터페이스(NI)란 네트워크 연결을 위한 하드웨어를 말한다.
AWS에서는 이를 가상으로 구현하는데 그게 ENI이다.
이렇게 가상 네트워크 인터페이스를 활용하면,
하나의 인스턴스를 두 네트워크 인터페이스에 연결시켜서
퍼블릭 트래픽을 처리하는 용도와 관리 트래픽을 처리하는 용도를 분리할 수 있다.
- VPC 피어링
이렇게 VPC 내에서의 서브넷이 통신할 수 있지만,
VPC 끼리 통신해야 하는 상황도 많다.
이때, VPC는 같은 VPC와 통신하는지,
아니면 On-Premise 식의 물리적 서버와 통신하는지에 따라 통신 방법에 차이가 있다.
VPC간의 네트워크 연결은 VPC 피어링이라고 한다.
동일 리전이든 다른 리전이든 무관하게 Private IP 바탕의 통신이 가능하다.
반면 On-Premise 네트워크와 연결하기 위해서는
Site-toSite VPN과 Direct Connect라는 방법을 사용한다.
Direct Connect는 주로 여력이 좀 있는 기업이 사용하는듯
VPC 보안
- 방화벽
내가 아는 그거 맞다.
떠올려야 하는 포인트는 방화벽의 원리.
방화벽의 트래픽 제어 규칙은 IP, 포트, 프로토콜을 기반으로 설정한다는 점이다.
AWS의 경우에는 가상 방화벽 기능을 위해 두 가지 수단을 사용하는데,
그게 보안 그룹(Security Group)과 네트워크 ACL(Network ACL)이다.
- 보안 그룹
보안 그룹이란 서브넷 안의 인스턴스들을 묶어 놓은 것으로,
같은 보안 그룹 안에 있는 인스턴스들은 같은 보안 규칙을 공유한다.
얘도 가상 방화벽의 일종이지?
따라서 저 보안 규칙이란건 IP, 포트, 프로토콜에 의해 통제된다.
즉, 보안 그룹은 서브넷 내의 인스턴스들을 묶어
얘네가 특정 방화벽을 적용받게 만드는 거라고 볼 수 있다.
물론 하나의 인스턴스에만 특정 보안 그룹을 지정할 수도 있기 때문에,
인스턴스 단위의 보안 관리가 가능하다.
보안 그룹을 만들 떄 일반적으로 인바운드/아웃바운드 규칙을 따로 추가한다.
인바운드 : 외부에서 내부로 들어오는 트래픽
아웃바운드 : 내부에서 외부로 나가는 트래픽
이때 인바운드 규칙 설정 요소로는 소스, 범위, 프로토콜이라고 하는데,
위에서 언급한 IP, 포트, 프로토콜에 대응된다.
기본값은 모든 인바운드 차단, 모든 아웃바운드 허용이다.
보안 그룹의 특징이 상태 저장(Stateful)인데,
쉽게 말하자면 인바운드 규칙 설정을 저장하여
자동으로 아웃바운드 규칙에도 적용하는 것이다.
보안 그룹은 3Tire 아키텍처에 대한 계층적 보안 구성을 만들 수 있다.
이를테면 다음과 같은 보안 그룹이 구성되어 있을 때,
| Tier(Subnet type) | 소스 | 프로토콜 | 포트 |
| Web(Public) | 0.0.0.0/0 | TCP | 443(HTTPS) |
| App(Private) | Web | TCP | 80(HTTP) |
| DB(Private) | App | TCP | 3306(MySQL) |
인바운드 HTTPS 액세스는 443포트가 개방된 Web 서버에만 접근이 가능하고
App, DB 서버에는 각각 이전 계층을 거친 트래픽만이 접근할 수 있다.
- 네트워크 ACL
네트워크 ACL은 보안 그룹같은 규칙을 서브넷 단위로 적용하는 가상 방화벽이다.
VPC가 생성될 때 수정 가능한 형태로 제공되며,
보안 그룹과는 달리 상태 비저장 특성을 가진다.
정리하자면 다음과 같다.
| 보안 그룹 | 네트워크 ACL |
| 인스턴스 단위 | 서브넷 단위 |
| 상태 저장 | 상태 비저장 |
| 등록된 모든 규칙을 평가 | 등록된 규칙의 번호 순으로 트래픽 제어 |
| 특정 인스턴스 대상 | 서브넷 내의 모든 리소스 대상 |