[AWS] 퍼블릭 클라우드 기초 맛보기 - 네트워크 (VPC, Subnet, Routing Table)

 

드디어 접하게 된 AWS

최근들어 평생 자체 클라우드만 쓸까봐, 보고서만 쓰다가 커리어가 마무리 될까봐 걱정이 많았다.

 

다행히도 자원한 AWS 교육을 수강하게 되어 기쁜 마음으로 수강중~

본업 돌아가면, 또 까먹을까봐 정리한다. ㅎㅎ

 

바로 본론으로 !

 

 

 

 

 

우선, 기업에서 IT 서비스를 하려면 보편적으로 데이터센터(혹은 전산실)에 장비를 도입해야 했다.

 

하나의 서비스를 위해

장비 도입 → 운영체제 설치 → 애플리케이션 개발까지 많은 비용과 시간, 공수가 발생하는데

이를 좀 더 효율적으로 개선한게 가상화이고, 더 나아가 클릭 몇 번만으로도 서버가 생성되게끔 나타난 것이 오늘의 퍼블릭 클라우드다.

 

 

몰랐는데.. 이런 아마존의 컴퓨팅을 임대해주는 서비스는 2006년부터 소개되었다고 한다.

ㅋㅋㅋ 몇수를 내다보신겁니까..

 

 

 

 

 

 

퍼블릭 클라우드만 쓴다면 기업에서 이런 데이터센터, 전산실을 이제 직접 관리하지 않아도 된다.

 

근데 아직까진 장단점이 뚜렷한 듯

직접 관리하지 못하니, 보고체계가 중요한 회사나 보수적인 금융권은 다소 관리가 어렵게 느껴질 듯하다.

(AWS 장애 시, 하드웨어 파트가 Fault난건지?  OS Hang이 있던건지? 등 세부적인 원인이 친절히 공지될 것 같진 않음)

 

 

 

 

 

AWS 로그인한 메인 화면

 

AWS는 그냥 네이버 가입하듯, 웹 사이트에서 계정을 생성하면 되는데

처음 약 6개월 정도는 프리티어(Free Tier) 계정이 되어 무료 사용 가능한 서비스를 이용할 수 있다.

6개월 지나면 다시 가입하면 된다고 한다. ㅋㅋㅋ

 

콘솔 홈에는 이론으로만 접했던 여러 이름들이 보인다. VPC, EC2, S3 등등

 

 

 

 

 

서버 어디에 만들래?

 

상단에는 지역(리전)이 적혀 있는데,

당연히 내가 IT 서비스할 대상의 지역으로 선택하면 된다!

 

리전은 코드로 구분되며, 서울은 사진과 같이 ap-northeast-2 이다.

아시아의 서울로 선택되어 있는지 중간중간 체크 해보기 ㅎㅎ

 

 

 

 

 

공식 홈페이지에 가면 지역마다 가용 영역이 얼마나 있는지 나와있는데

AWS는 전세계에 다수의 리전과 가용 영역이 있고, 서울 리전에는 4개의 가용 영역이 있는걸 알 수 있다.

하나의 서버를 여러 가용 영역에 분산배치하도록 설계 ~

 

리전(Region)

여러 독립적인 데이터센터 그룹의 물리적인 위치

 

가용 영역(AZ; Availability Zone)

데이터센터 그룹. 여러 지역(리전)에 격리되어 위치

 

* 데이터센터(AZ)에 화재나 정전 등 문제가 생기면 다른 데이터센터(AZ)로 가용성이 보장되도록 하는 구조

* 동일 리전 내 AZ 간에는 전용망이 구성되어 있어, 낮은 지연과 높은 처리량이 보장된다.

* 리전끼리는 전용망이 아닌 인터넷으로 연결되어 있다. 따라서 리전 간 복제도 가능하지만, AZ 분산하는 것만큼은 성능이 나오지 않음

 

 

 

 

 

 

 

실제 데이터센터에서 서버 구축할 때, 네트워크가 준비되어 있어야 하는 것처럼 AWS도 네트워크 환경이 마련되어 있어야 한다.

리전 단위로 IP 대역을 정하고(VPC), AZ마다 서브넷을 할당할 수 있다. 그럼 그 서브넷 안에서 할당받은 IP를 VM이 사용하는 방식.

 

VPC (Virtual Private Cloud)

AWS의 대표 네트워크. AWS의 리소스들이 서로 통신할 수 있게 제공되는 NW 환경이다.

기본적으로 사설 네트워크 환경을 권장하는데, 쉽게 리전의 IP 대역이라고 생각하면 된다. (CIDR 방식)

 

서브넷 (Subnet)

VPC의 IP 대역을 적절한 단위로 분할하는 방식으로, AZ에서 VM이 사용할 IP 주소의 범위라고 보면 된다.

AZ끼리는 서브넷이 같을 수 없다.

 

처음 물음표가 떴던게, AZ마다 분산배치함으로써 이중화를 하려면 같은 서브넷이 권장 아닌가..?

찾아보니 AWS는 '이중화'와 '재해복구'의 경계가 모호하고, Active-Active 환경의 Site Recovery 가 기본인 컨셉 같다.

특히, 이중화 시 성능 보장이 중요한 DB나 Cache 시스템은 AWS에서 제공하는 별도 전용 서비스가 있다.

 

 

 

 

 

 

VPC 생성화면

 

AWS 네트워크는 기본적으로 클래스 방식이 아닌 CIDR 방식을 사용한다.

크게 디테일한건 없고, 사용하고자 하는 IP 대역으로 CIDR 방식으로 넣어주면 된다.

 

DNS 통신을 하고 싶다면, 생성된 VPC [설정 편집] 후, DNS 호스트 이름 활성화를 체크해줘야 한다.

 

 

 

 

 

 

서브넷 생성 화면

 

리전 영역에 대해 VPC로 IP 대역을 정해주면, 그 안에서 AZ마다 서브넷을 할당해준다.

 

생성한 VPC가 사설 10 대역이고,

해당 VPC에 AZ를 할당한다면 해당 10 대역 안에서 사용할 IP 주소 범위를 정해주면 된다.

 

위에서 한국에 AZ가 4개 있다고 했는데,

나는 분산 배치와 용도에 맞춰 아래와 같이 만들었다.

 

AZ #1(2a) 서브넷 2개 / AZ #2(2c) 서브넷 2개

각각 외부망 통신용 서브넷, 내부망 통신용 서브넷으로 총 4개 생성 !

 

 

 

 

 

 

VPC는 처음 생성하면 외부 네트워크와 단절되어 있어, 라우팅을 통해 목적지와 통신이 되게끔 잡아줘야 한다.

생성한 VPC를 선택 후, 하단의 [리소스맵] 매뉴를 보면 사진과 같이 설정된 현황을 볼 수 있다. (지금 상태에선 라우팅만 없어야 정상)

 

라우팅 테이블 (Routing Table)

각 서브넷에 필요한 트래픽 흐름을 잡아주는 네트워크 통로

VPC 생성 시, 기본 라우팅 테이블이 생성된다. 그외 필요한 라우팅은 이어서 추가하는 방식

 

 

 

 

라우팅 생성 화면

 

처음에는 기본 라우팅 테이블이 있을텐데, 용도에 따라 더 생성해주면 된다.

 

라우팅 생성 자체는 쉽다 !

라우팅 메뉴에서 생성하기 선택 후, 대상 VPC를 선택해주면 된다.

 

 

 

 

라우팅 [서브넷 연결 편집] 에서, 대상 서브넷을 선택해주면 된다.

 

나는 외부망 통신용 서브넷, 내부망 통신용 서브넷이 있으니

각각의 서브넷을 연결해줄 라우팅 테이블을 만들어줬다.

 

 

 

 

 

 

비즈니스 로직에 따른 네트워크 구성

 

기본적으로 WEB - WAS - DB 환경의 3-Tier 구조 시스템이 많을 것이다.

요즘은 인프라도 WEB을 프론트엔드, WAS와 DB 등 내부 시스템을 백엔드로 묶어 부르기도 한다.

 

기업 환경마다 요구사항은 천차만별이지만,

WEB 서버만 인터넷에 제공하고 WAS와 DB는 내부망에 위치한다고 가정해보면

추가로 설정을 잡아줘야 하는 부분들이 있다.

 

 

인터넷 게이트웨이

외부와 통신하기 위해서는 인터넷 게이트웨이를 생성 후,

라우팅 테이블에 대상 VPC를 인터넷 게이트웨이에 연결해줘야 한다.

 

NAT 게이트웨이

내부용 시스템도 외부 Outbound로 통신 가능하게끔 NAT 게이트웨이 연결이 가능하다.

라우팅 테이블에 대상 VPC를 NAT 게이트웨이에 연결해주면 된다.

 

위의 케이스에선

WEB 서버용 VPC를 인터넷 게이트웨이로, WAS/DB용 VPC는 필요 시 NAT 게이트웨이로 잡아주면 된다.

 

 

 

 

 

라우팅 테이블에서, 대상 라우팅을 선택 후 [라우팅 편집] 에 들어가서 대상 게이트웨이를 선택해주면 된다.

 

외부망 통신용 라우팅 테이블은 인터넷 게이트웨이, 내부망 통신용 라우팅 테이블은  NAT 게이트웨이로 넣어주면 된다.

 

ㅋㅋ 드롭박스에 목록이 많은데.. 아직 다 해보진 못했다😅

피어링 연결은 VPC 간에 통신하기 위해서 사용 !

 

 

 

 

---

네트워크 보안적인 기능도 당연히 있다.

위에는 네트워크 통신을 위한 설정들이라면, 보안을 위한 메뉴들도 존재

 

NACL (Network ACL)

패킷의 IP, 포트 기준으로 트래픽을 허용/거부를 결정하는 정책 리스트

라우터, 방화벽 장비에서 설정하는 전통적인 방법으로, 서브넷 기준으로 허용/거부가 가능하다.

 

Default는 모두 허용(0.0.0.0/0 에 대해 Allow)이라, 직접 변경 설정해줘야 한다.

기본이 모두 허용이라니.. AWS는 편의성에 초점이 확고한 듯ㅋ

 

 

SG (Security Group)

NACL과 유사하다. 트래픽 허용/거부 정책을 결정해주는 요소인데, IP 대역 기준이 아닌 인스턴스 기준으로 가능하다.

기본 All Deny라, 허용할 정책만 추가해주는 방식

 

 

NACL 은 Rule 기반으로 여러 정책에 대해 상위 번호부터 우선순위를 갖고 가면

SG는 Rule 우선순위가 없고 출/도착지에 대한 정책 정보만 저장해서 활용되는 방식이다.

 

NACL과 SG를 혼용해서 사용하면 철통 보안이 되어 안전하지만, 관리가 매우 복잡해진다고 한다.

주변 실무자한테 물어보니 거기도 SG만 쓰고 있다고.. ㅎㅎ

---

 

 AWS의 네트워크로 시작한 첫인상은 아직까진 '편리한데 불편하다'는 생각이 든다.

그동안 보수적으로 운영한 내 경험과 좀 상반되는 느낌이라 해야 하나.. ㅋㅋ

 

부딪히기 보다 미리 돌다리 두들겨보고 건너가는 성향이 있어서

나한테 이런 도전적인 환경은 설레기도 하고 낯설기도 하다.

 

좀 더 편한, 용어만 다른 인프라를 GUI로 만나본 느낌인데

아직 너무 기초단계이고, 아마 IaC 단계로 들어가면 맨땅에 헤딩만 엄청하겠지ㅋ

 

다음 포스팅은 EC2 내용으로 최대한 빨리 돌아와보겠다 !!