문돌이가 설명하는 AWS 클라우드 시스템

이번 시간엔 2017년에 개최된 AWS SUMMIT Seoul의 강의 아닌 강의를 유튜브에서 보고 정리한 내용을 공유합니다. 제 공부 목적으로 필기식으로 작성되었기 때문에 불친절하더라도 이해 부탁드립니다^^

 

---

 

VPC(Virtual Private Cloud)란, 고객 전용의 가상 데이터센터라고 생각하면 된다. 이전에는 AWS에서도 내가 만든 EC2 인스턴스가 어디에 위치한지 전혀 알지 못했다. 하지만 VPC가 출시되면서 나만의 데이터센터를 구축하고 그 안에 여러 개의 EC2 인스턴스를 생성하면서 보다 나의 서버가 어디에 있는지, 어떻게 작동되는 지 등 가시성이 증가했다. 

가상 데이터 센터 만들기 - VPC 기본 및 연결 옵션 - 양승도 솔루션즈 아키텍트(AWS 코리아) - YouTube

VPC 설정 단계

1. 내부적으로 사용할 프라이빗 ip 주소를 결정해야 함
2. 서브넷으로 바운더리를 만들어줌
3. 인터넷으로 연결되는 통로인 라우팅 테이블(routing table) 설정
4. 접속 허용 여부를 결정하는 방화벽 설정 

<출처: AWS SUMMIT Seoul>

1. 프라이빗 ip 주소 결정

일반적으로 CIDR 방식(예: 172.31.0.0/16)으로 설정한다. AWS는 Recommended: RFC 1918 range 사용을 추천하는데, 그 이유는 연결할 수 있는 다른 네트워크와 겹치는 범위를 피할 수 있기 때문이다. 

172.31.0.0/16 주소를 해석해보면 마지막 16은 16bit로 마스킹 방식을 뜻한다. 앞에 있는 16bit는 언제나 고정된 형식이고, 나머지 16bit는 변경이 가능하다. 즉 다시 말해 총 $2^{16}$개(약 64K)의 ip 주소를 가질 수 있는 커다란 네트워크를 정의하겠다는 의미이다. 

참고: RFC 1918 (private ip address 전문)

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

2. 서브넷 설정

서브넷(Subnet)이란, 인터넷으로 향하는 길목을 만들어서 외부에서 접속할 수 있도록 만들어주는 역할이다.

<출처: AWS SUMMIT Seoul>

3. 인터넷 경로

VPC에 기본적인 route table이 존재하긴 하지만 서브넷에 다른 route table을 할당할 수 있다.

route table 종류에는 target 값이 local 또는 IGW로 나뉘는데, local은 내부 vpc에만 패킷을 보내라는 의미다. IGW는 Internet Gateway의 약자로 외부 인터넷과 연결되는 통로를 말하며 모든 주소에 허용하려면 0.0.0.0/0 으로 설정하면 된다. 

4. 네트워크 보안: Network ACLs / Security Groups

4-1. Network ACLs: Stateless firewalls 

서브넷 단위로 적용 가능
AWS는 디폴트 값으로 허용해줌

4-2. Security Groups: Staefull firewalls

AWS는 디폴트 값으로 외부 진입을 허용하지 않음
MyWebServers라는 프론트엔드 웹서버가 있을 경우, 이에 대해서만 외부 트래픽을 허용하고 싶음
MyBackends라는 백엔드의 경우 외부 트래픽은 허용하지 않은 채 MyWebServers 에서의 접속만 허용해주고 싶음 

<출처: AWS SUMMIT Seoul>

참고
1. Stateful 방식:
서버에 허용된 클라이언트가 접속하고, 나갈 때는 이미 접속했기 때문에 자동으로 허용해준다는 개념으로 inbound rule만 설정해주면 된다.
2. Stateless 방식:
말 그대로 상태가 없는 것으로 클라이언트가 들어올 때의 상태를 저장하지 않기 때문에 나갈때도 따로 열어주어야 한다. 따라서 inbound rule과 outbound rule 모두 설정해주어야 한다.

NAT gateway: 아웃바운드 전용 인터넷 허용

위의 보안 그룹에서 이어 이야기하면 인터넷을 연결하지 않은 백엔드의 경우 외부 소스를 다운받거나 배치시켜야 할 필요가 있을 때 불편함을 겪는다. 보통 인터넷이 연결된 프론트엔드 서버에서 외부 소스를 다운받고 이를 백엔드 쪽에 복사해줘야 하기 때문이다. 이를 해결하기 위한 방법이 바로 NAT(Network Address Translation) gateway이다.

아래 왼쪽 서브넷이 백엔드고, 오른쪽 서브넷이 프론트엔드다. 왼쪽에서 오른쪽으로 연결된 ip 주소는 오로지 외부 소스를 다운받기 위해 존재한다. 외부에선 해당 백엔드 서버를 찾아갈 방법이 없다. 

<출처: AWS SUMMIT Seoul>

<출처: AWS SUMMIT Seoul>

VPC 간 연결: VPC peering

<출처: AWS SUMMIT Seoul>

게임을 예로 들면, 위 그림의 VPC A는 마스터 서버다. 모든 게임 유저들 정보를 저기서 관리하고 인증을 해주면 각 게임마다 VPC를 따로 설정해서 원활한 서비스를 제공할 수 있다. 공통/핵심 서비스로는 1) 인증/디렉토리, 2) 모니터링, 3) 로깅, 4) 원격 관리, 5) 스캐닝 등이 있다.

서로 다른 VPC는 계정이 같을수도, 다를수도(다른 회사간 연결할 경우) 있다.  VPC peering을 하기 위해선 아래와 같은 단계를 거친다. 

<출처: AWS SUMMIT Seoul>

아래와 같이 10.55.0.0/16 주소로 피어링 경로를 설정하려면 아래와 같이 target을 pcx로 시작하면 된다.

<출처: AWS SUMMIT Seoul>

회사 네트워크에 연결(하이브리드 클라우드): VPN(Virtual Private Network) & DX(Direct Connect)

<출처: AWS SUMMIT Seoul>

회사 내부 데이터센터를 AWS와 연결하기 위해선 VPN이나 DC를 사용하면 된다. 두가지 모두 온 프레미스 네트워크와 VPC 사이의 보안 연결을 지원하는데, VPC는 인터넷을 통한 IPSec 터널로 인터넷 품질 상태의 영향을 받는다. 과거에 비만 오면 전화 품질이 떨어지거나 인터넷이 느려지는 등의 현상과 관련이 있다. 반면, DC는 전용선을 사용하기 때문에 이런 문제가 발생하지 않는다. 따라서 높은 가용성을 원한다면 두가지 모두 사용하는 것이 좋다. 

(참고) S3는 본래 인터넷만 연결되어 있으면 사용할 수 있도록 설계되었다. 따라서 VPC 내부에 속할 수 없으며 IGW를 통해 S3에 있는 데이터에 접근할 수밖에 없다. 물론, 이것이 불편하게 느껴지기 때문에 AWS는 VPC endpoints for S3라는 서비스를 별도로 제공한다. IGW처럼 공개적으로 인터넷을 통해 S3에 접근하는 것이 아니라 private하게 접근할 수 있게 해준다. 

IAM 정책을 적절히 사용한다면 아래와 같이 보안 측면에서도 걱정 없이 S3에 접근할 수 있다. 원래 인터넷을 통해 접근했던 S3를 외부 인터넷은 차단하고 오로지 VPC endpoint에서의 접근만 허용하는 것이다. 

<출처: AWS SUMMIT Seoul>