[AWS] Amazon Web Service 왕초보 탈출하기 - [1] Region, AZ, VPC, Subnet 편

※ 이 포스팅은 AWS 왕초보(자바봄 멤바들)를 위해 작성되었습니다. 나는 VPC를 모른다, EC2 만들때 VPC, Subnet이고뭐고 신경쓴적이없다. 아이피대역 그런거 신경써본적없다. 보안그룹만 막아놓으면되는거아닌가? 등등의 분들이 읽기에 최적화되어있습니다. 하나의 기본 아키텍쳐를 차근차근 구성해보며 핵심 개념을 익힙니다.포스팅 내용 자체는 그간의 게시글과 중복되는 부분이 많습니다. 차이점은 이 포스팅은 서비스 "사용" 측면이 아닌 "아키텍처"에 집중합니다.※

 

 

이 포스팅에서는 하단의 아키텍처를 완성하며 기본 개념들을 익힙니다. 핸즈온이 있다면 좋겠지만 소량의 과금이 있을 수 있으니 조심 또 조심..

 

 

1. Region 과 AZ(Avaliability Zone)

 

 

AWS 는 Region 별로 리소스를 제공합니다. 예외적으로 IAM처럼 리전 구분이 필요없는 서비스도 있습니다.

 

클라우드 서비스는 사용자가 물리적인 데이터센터를 고려하지 않도록 논리적인 서버를 제공합니다. 그리고 당연하게도 그 기반에는 물리적 서버가 존재합니다. 

 

리전은 바로 이 물리적 서버가 존재하는 국가를 뜻합니다. 서울 리전이라고 서울에 서버가 있다는 뜻이 아닌 한국의 대표 지역의 이름을 딴 것입니다. 

 

그리고 이 한국 리전을 AWS 는 "ap-northeast-2" 라고 칭합니다. 그 외 리전 코드 정보는 아래 링크에서 찾아볼 수 있습니다.

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

 

 

 

참고로 리전별로 AWS 서비스 비용은 조금씩 상이합니다. 미국과 한국을 비교하면 미국이 조금 더 싸지만 한국 사용자를 대상으로 하는 서비스라면 속도만 생각해도 서울 리전을 사용하겠죠?

 

그런데 만약 대한민국에 AWS가 제공하는 데이터센터가 한 군데 뿐이면 AWS는 안정성, 가용성을 내세우지 못할 것 입니다. 그 지역의 센터가 특정 문제로 다운된다면 서울리전에서 제공하는 모든 서비스가 중단되기 때문입니다.

 

 

여기에서 Availability Zone(이하 AZ) 개념이 등장합니다. AWS는 리전별 최소 2개 이상의 가용영역(AZ)를 제공합니다.

 

 

예를들어, 서울리전을 기준으로 센터는 총 세군데 흩어져 있습니다. 즉, 서울 리전의 AZ는 3개 입니다. 이를 이용해 두 개 이상의 가용영역에 서비스를 배포함으로써 서비스는 높은 가용성을 획득하게 되는 것입니다. (더 높은 수준의 격리를 제공하는 멀티리전 운영을 택하기도 합니다. 서울 리전이 통으로 장애가 난 케이스도 있었죠.)

 

 

AZ 정보는 아래와 같이 리전코드의 뒤에 붙여 표현합니다. a zone, b zone, c zone 을 보유하는 서울리전은 아래처럼 표기합니다.

ap-northeast-2a    ap-northeast-2c    ap-northeast-2b(오픈한지 얼마 안됐습니다.)   

 

아 재밌는 점은 모든 사용자에게 가용영역 a, b, c 가 같은 가용영역은 아닙니다.

말이 좀 어려운데, 예를들어 A 사용자의  a 가용영역이 "용인" 센터라면, B 사용자의 a 가용영역은 "서울" 센터일 수도 있습니다. 아무래도 한 가용영역에 리소스가 몰리는 것을 방지하기 위해서겠죠? 

 

 

 

 

 

2. VPC(Virtual Private Cloud)

AWS 의 모든 리소스는 VPC 안에 존재합니다. 단, 서버리스(Lambda, DynamoDB, 등)나 S3 같은 독립된 서비스는 제외합니다.

 

위의 fact를 기반으로 EC2 를 만들어보았던 경험을 되살려봅시다.

EC2 > Create Instance > 다음 > 다음 > 다음 > 보안그룹 다열기 > 다음 .. > 생성  ...

 

 

VPC를 지정했던 기억이 있나요? 있다면 이번 장은 패스해도 무방합니다. 

 

우리는 VPC 를 지정하지 않고도 그동안 EC2 를 잘 만들어 왔습니다. 어떻게 그게 가능했던 걸까요? 

 

답은 아래 사진에서 볼 수 있습니다.

 

 

네트워크 vpc 아이디 옆에 default 가 적혀져 있습니다.

 

AWS 계정을 생성하면 VPC 를 생성하지 않아도 default VPC 가 자동으로 생성되어있습니다.

따라서 우리는 별도의 VPC 를 생성하지 않고도 EC2 생성이 가능했던 것입니다.

 

그럼 아래와 같은 질문이 따라올 수 있습니다.

default VPC 쓰면 되는데 왜 VPC 만들어야 하나요?

 

 

우선 VPC 내부의 리소스는 서로 private IP를 통해 통신할 수 있습니다.(물론 추가적인 조치는 필요합니다.) 그런데, A 애플리케이션과 B 애플리케이션을 Default VPC에 배포한다면 어떻게 될까요?

 

서로 다른 성격을 지닌 두 애플리케이션은 격리되지 못하고 언제든 서로에게 영향 끼칠 수 있게 됩니다.

참고로 Public IP는 인터넷 망을 통해 접속할 수 있는 글로벌 아이피(세상에 하나밖에 없음)를, Private IP 는 인터넷에 공개되지 않고 내부 네트워크에서 사용하는 내부 아이피(다른 네트워크 망의 Private IP와 겹쳐도 상관 없음)을 뜻합니다.

 

애플리케이션 관점이 아닌 설계 측면에서 바라봐도 불편합니다. A 애플리케이션만 관리하고 싶은데 같은 VPC에 뒤죽박죽 섞여 있으니 당연히 개발도, 운영도 힘들어 질 것입니다.

 

또, VPC 각각은 자신의 IP 사이더 대역을 가지는데요, 한정된 IP를 두 애플리케이션이 나눠쓴다? 그런데 후에 또 다른 애플리케이션이 추가된다면? 그러다 아이피가 부족하게 된다면? 

 

여러 측면을 고려해봐도 하나의 서비스는 하나의 "격리된 공간"을 가지는 것이 옳습니다.

 

 

그 격리된 공간을 제공하는 AWS의 서비스가 VPC(Virtual Private Cloud)입니다. 하나의 격리된 "사설 네트워크 대역" 을 제공해주는 것이죠.

 

 

이제 VPC를 구성해보겠습니다.

 

VPC > VPC 생성

 

 

차례대로 보겠습니다.

 

1. 이름태그

해당 태그를 통해 VPC 검색을 용이하게 할 수 있습니다. 자동 생성되는 VPC 아이디를 외울 수 없으니 의미있고 기억하기 쉬운 네임 태그가 적절합니다. 보통 프로젝트명-vpc 컨벤션을 사용합니다만 그건 자유 ,, 

 

 

2. IPv4 CIDR 블록

VPC 가 사용할 수 있는 사설 CIDR 대역입니다. VPC 에 존재하는 모든 리소스는 이 대역 내에서만 존재할 수 있습니다. 

일반적으로 사용되는 RFC 표준에 따른 사설 아이피 대역을 주로 씁니다. 이 예제에서는 16비트 블록을 사용하였습니다. 참고로 여기서 아이피 대역을 많이 준다고 비용이 더 들지는 않습니다

 

아이피 대역을 정하는 것은 신중해야합니다.

VPC 의 사이더 대역을 중도에 변경할 수 없기 때문입니다.(물론 우회하는 방법이 있기는 하지만 매우 복잡합니다.) 

 

 

Q. 돈이 드는 것도 아닌데 부족하지 않게 무조건 많이씩 할당하면 되는거 아닌가요?

인터넷 망에 관계없이 대역을 사용할 수있다는 것은 사설 네트워크의 장점입니다. 하지만, 시스템의 구조를 잘 살펴보아야 합니다.
만약 내가 지금 구축하고 있는 AWS 서비스가 온프레미스 IDC 서버와 직접 통신해야 할 일이 있다면 어떻게 될까요?
아마 대다수가 VPN을 사용하여 VPC와 온프레미스 서버가 통신할 수 있도록 할 것 입니다.

이때, 온프레미스의 아이피 대역과 AWS VPC 의 아이피 대역이 겹치게 되면 문제가 발생합니다.
예를들어, 온프레미스의 아이피대역은 192.168.0.0/16, AWS VPC의 A Subnet 아이피대역은 192.168.0.0/24 라고 가정합시다.
A Subnet의 라우팅 테이블이 192.168.0.0/24  -> 온프레미스 게이트웨이로 되어있다면 어떻게 될까요?

192.168.0.0/24 는 온프레미스의 대역이면서 동시에 A 서브넷의 대역입니다. 하지만 이 라우팅 테이블에 의해 해당 서브넷의 해당 아이피대역으로 오는 요청은 모두 온프레미스로 가게되고 A Subnet 내부의 리소스로는 향할 수 없게 됩니다.

그렇기 때문에 온프레미스의 서비스와 VPN 을 하게 된다면 아이피대역이 겹치지 않게 신경써야 합니다.

 

 

3. 테넌시

테넌시는 기본과 전용으로 나눠집니다. 기본은 AWS 의 IDC 센터 어디든 해당 VPC가 위치할 수 있다는 것이고, 이 하드웨어에는 다른 계정의 VPC가 존재할 수도 있습니다. 전용은 고객과 하드웨어가 1:1 을 이루는 것을 의미합니다. 보안에 민감한 서비스의 경우는 전용을 사용하기도 합니다.

 

 

VPC 생성을 완료하였습니다. 현재 아키텍쳐는 다음과 같습니다.

 

 

3. Subnet

이제 리소스를 생성하기 전 마지막 단계입니다.

 

Subnet은 아이피 대역을 논리적으로 더 쪼개 사용할 수 있도록 "서브 네트워크를" 구성하는 네트워크 요소입니다. 

 

VPC로 격리된 하나의 네트워크 망을 구성했지만 아직 부족합니다.

어떤 리소스는 인터넷과 직접 통신할 필요가 있고, 어떤 리소스는 보안상 반드시 내부에 숨겨야합니다.

또 어떤 리소스는 오직 애플리케이션과 관계가있고, DB와 관계되어있는 리소스는 따로 관리하는 것이 편합니다.

 

 

즉, VPC 도 나눠서 쓸 필요가 있습니다. 

VPC의 아이피 대역을 또 다른 서브 네트워크 "서브넷"으로 나누도록 하겠습니다.

 

Q. 그럼 용도별로 관리가 편하게 최대한 쪼개는게 좋나요?

서브넷을 쪼갠다고 비용이 드는 것은 아닙니다. 하지만 쪼개는 것에 신중해야합니다.
서브넷으로 지정한만큼의 IP 를 모두 쓸 수 있는 것이 아니기 때문입니다. 
AWS는 서브넷별로 5개의 아이피를 예약합니다. 10.0.0.0/24 서브넷의 경우 아래 5개의 IP를 예약합니다.
즉, /24 사이더의 서브넷은 2^8 = 256 개의 아이피를 쓸 수 있는 것이 아닌 5개를 제외한 251개의 아이피를 사용할 수 있습니다. 서브넷을 나누는 것은 아이피 5개를 잃고 가는 것이기 때문에 신중해야합니다.

 

 

 

 

 

 

 

 

위 그림처럼 Public Subnet(인터넷과 통신 가능한) 2개를 생성하겠습니다.

 

VPC > Subnet > Create Subnet

 

 

 

1. Name tag 

역시나 후에 확인하기 쉽게 정합니다. 저같은 경우 프로젝트명 - [public/private] - AZ 컨벤션을 사용합니다. 

 

2. VPC

클릭하면 지정한 네임태그와 함께 출력됩니다. aws-beginner-vpc를 선택해줍니다.

 

3. Avaliablilty Zone

초반에 나왔던 AZ 지정은 서브넷 생성 단계에서 합니다. AZ 별로 같은 용도의 서브넷을 만들어줌으로써 "이중화"합니다. 서울 AZ는 a, b, c 가 있지만 저는 a, c에 이중화하겠습니다.

 

4. IPv4 CIDR block

VPC 사이더 내에 존재해야하며 다른 서브넷의 사이더와 중복되어서는 안됩니다. VPC를 구성하기전에 사이더 대역을 먼저 나눠두는 것이 좋습니다. 후에 꼬이면 정말 다꼬이게하는 주범..! 192.168.0.0/24 (서브넷마스크: 255.255.255.0) 을 지정합니다. 상단의 완성 아키텍처를 참고해주세요. 

 

 

 

같은 방식으로 아래와같이 c 존 public subnet 1개, a, c 존 private subnet 2개를 마저 생성합니다. 

public - c subnet

 

private-a subnet

 

private-c subnet

 

 

현재 상태는 아래와 같습니다. (251개의 사용가능한 아이피 갯수가 보이죠?)

 

 

 

 

 

위 아키텍처에 빼먹은 것이 있습니다. 

바로 RDS가 위치할 서브넷입니다. 이 서브넷은 DB 전용 서브넷으로 만들기 위해  추후 생성하겠습니다.