📝 학습 목표
- AWS의 VPC를 이해한다.
- 서버가 어떻게 구축되는지 이해한다.
🤔 AWS에서 리전과 가용영역
AWS를 사용해본 사람이라면,
리전과 가용영역이라는 말을 들어봤을 것이다.
리전과 가용영역은 Amazon Web Services (AWS)의 인프라스트럭처를 구성하는 중요한 요소이다.
간단히 설명하게 넘어가보자!
💡리전 (Region)
AWS에서 수많은 컴퓨팅 서비스를 제공하려면,
당연히 대규모 서버 컴퓨터를 모아둔 중앙 서버가 필요할 것이다!!
만약에 전세계 컴퓨팅을 감당할 서버 컴퓨터가 단 1개 있다면?
1. 성능 한계: 단일 서버는 처리할 수 있는 작업량이 한정되어 있다.
모든 자원이 북미에 있다면, 지구 반대편의 아시아 지역에서는 서비스가 너무 너무 느릴 것이다!
2. 고가용성 및 내결함성: 단일 서버의 장애는 전체 서비스의 중단으로 이어질 수 있다.
(Single Point of Fault)
=> 이러한 이유로 자원들을 여러 곳에 분산시켜 놓아야 한다!
그렇다면, 리전은 AWS의 데이터 센터가 위치한 지리적인 영역을 가리 킨다!
각 리전은 물리적으로 분리되어 있으며 독립적인 인프라를 갖추고 있다!
서비스를 실행하고 저장하는 데이터의 위치는 선택한 리전에 의해 결정된다~
💡가용영역 (Availability Zone)
가용영역은 각 리전 내에서 독립적인 데이터 센터를 가리킨다.
한 리전에는 여러 개의 가용영역이 있을 수 있다.
그냥 쉽게 이야기 해서 "리전을 한 번 더 분산해서 배치한 것" 이라고 이해하면 편하다.
<아래 사이트에서 실제 확인할 수 있다.>
https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/
글로벌 인프라 리전 및 가용 영역
AWS는 컴퓨팅, 스토리지, 데이터베이스, 분석, 네트워킹, 기계 학습 및 AI, 모바일, 개발자 도구, IoT, 보안, 엔터프라이즈 애플리케이션을 비롯하여 광범위한 글로벌 클라우드 기반 제품을 제공하
aws.amazon.com
✒️ AWS VPC
AWS를 처음 들어가서 사용해본 경험이 있는 사람들이라면,
초보 개발자에게 얼마나 복잡하고 다루기 어려운 인프라 서비스라는 걸 체감할 것이다...
코딩 공부만 하기도 바쁜데, AWS 공부할 것도 산더미인 느낌...
항상 개발 공부를 할 때 화나는게
"모든 지식이 그물망 처럼 연결되어 있는 것 같은데 어디부터 공부해야하지..?" 이다....
그래서 나는 AWS를 공부하려면, VPC를 먼저 알아야 한다고 말하고 싶다.
✒️ 선행 지식
물론, VPC를 이해하기 전에 선행되어야 할 지식 또한 있다.ㅠㅠ
"서브네팅, 라우팅, 사설 IP" 정도가 있다.
서브네팅(Subnetting): 서브네팅은 IP 주소를 하위 네트워크로 분할하는 작업.
효율적으로 IP 주소를 할당하기 위해 사용.
각 서브넷은 고유한 네트워크 주소 범위를 가지며, 서로 다른 서브넷 간에는 라우팅을 통해 통신할 수 있다.
라우팅(Routing): 라우팅은 네트워크에서 데이터 패킷을 보내는 방법을 결정하는 프로세스.
라우터는 수신된 패킷의 목적지 주소를 확인하고, 해당 패킷을 다음 경로로 전달한다.
라우터는 경로 테이블을 사용하여 패킷의 목적지에 대한 최적의 경로를 결정한다.
사설 IP 주소(Private IP Address): 사설 IP 주소는 인터넷에서 직접 접근할 수 없는 IP 주소 범위.
이러한 주소는 내부 네트워크에서만 사용되며, 일반적으로 사설 네트워크에서 호스트와 장치를 식별하기 위해 사용된다.
아래 포스팅을 읽으면, 아래 3가지를 고려해서 읽기를 바란다.
1. 서브넷을 나눠서 인프라 자원들을 배치한다
2. 기본적으로 사설 IP를 부여받기에 AWS에서 어떻게 이 자원들이 외부와 통신하게 하는지 잘 살펴본다.
3. 2번에 이어서 반대로 보안을 위해 보호 할 자원들은 어떻게 배치하는지 잘 살펴본다.
✒️ 지식 워밍업
203.230.7.0/24**
Q. 해당 아이피 주소에서 찾아낼 수 있는 것은?
A.
1. 네트워크 아이디 : 203.230.7.0
2. 할당 가능한 호스트 갯수 : 256개 - 2
(해당 대역은 /24 서브넷 마스크를 갖기 때문에
36-24 = 8
2의 8승 개 인 256개의 IP 주소를 가지고 있다.
하지만 네트워크 아이디와 브로드캐스트 주소를 제외 -> 실제로 사용 가능한 호스트 수는 256 - 2 = 254개 이다.)
위의 아이피 대역은 아래와 같이 두 영역으로 나눠보자.
> 203.230.7.0/25
> 203.230.7.128/25
이때, 네트워크 아이디가 다르기에 기본적으로 다른 LAN이 된다.
따라서, 라우터 혹은 L3 스위치의 라우팅이 있어야 통신이 가능하다.
라우팅, LAN, 서브네팅의 개념, 그리고 CIDR 표기법에 대한 개념이 안다고 가정하고 이야기를 시작하겠다!
✒️ 1. VPC
💡VPC와 IP 대역
VPC는 기본적으로 가상의 네트워크 영역이기에 사설 아이피 주소를 가지게 된다.
사설 아이피 대역은
10.0.0.0/8
172.16.0.0/12
192.168.0.0/24
이렇게 3개의 대역을 가지며, 하나의 VPC에는 위의 네트워크 대역, 혹은 서브넷 대역이 할당 가능하다!
10.0.0.0/8의 서브넷인 10.0.0.0/16도 VPC에 할당이 가능!
💡VPC의 실제 사용
VPC는 실제로 사용 시 VPC 자체에서도 서브넷을 나눠서 사용하게 된다.
VPC에는 리전의 각 가용영역에 하나의 서브넷이 있고,
각 서브넷에 EC2 인스턴스가 있고,
VPC의 리소스와 인터넷 간의 통신을 허용하는 인터넷 게이트웨이가 있다!
https://aws.amazon.com/ko/vpc/ 자세한 내용은 해당 링크 참고
살짝 토나올 타이밍에 예시를 들어보겠다...
예시로 10.0.0.0/16의 아이피 주소를 VPC에 할당한 상황에서,
VPC를 원하면 다시 서브넷으로 나눠서
각각 서브넷을 원하는 가용영역에 배치하여 사용할 수 있다!!
(주의 : VPC를 나눈 서브넷을 다시 나누지는 못한다)
그런데!! VPC의 서브넷 IP 대역에서 호스트에 할당할 수 없는 ip 주소가 있다!
1. 서브넷의 네트워크 대역
2. VPC 라우터에 할당
3. Amazon이 제공하는 DNS에 할당
4. 미래를 위해 예약
5. 브로드 캐스트 주소
1,3,5번은 그렇다 치자.
(브로드 캐스트 주소는 해당 서브넷에 속한 모든 호스트에게 메시지를 보내는 데 사용된다.)
또한 예약된 주소도 못쓴다! OKAY
중요한 것은 VPC 라우터에 할당 불가능 하다는 것
해당 주소는 VPC 내에서 사용되는 라우터에 할당된다.
이 라우터는 VPC 내부와 외부의 통신을 관리하며, VPC 내부에서 다른 서브넷 또는 외부 리소스로의 트래픽을 라우팅한다!
또한 이어서 ROUTER에 대해 중요하게 인지해야 할 내용이 있다.
"VPC 내부적으로 라우터가 있다고? => 그럼 VPC 내부 서브넷끼리 통신이 되겠네?"
💡VPC 와 외부 통신
그렇다면 VPC는 어떻게 외부와 통신할까!?!!?!?
기본적으로 사설 아이피 대역은 공용 아이피 대역과 통신이 불가능 하다!!!
그런데 AWS로 인프라를 구축하면 통신이 된다고 하였다!
어떻게 이게 가능한 걸까?
✒️ 2. Public Subnet / Private Subent
💡Public Subnet
어떻게 Public Subnet을 만들어?
결론부터 말하면 AWS의 Internet Gateway 통해 해당 서브넷을 퍼블릭 서브넷이 되게 할 수 있다!
서브넷이 외부와 통신 할 때, Internet Gateway를 거치게 하면 외부와 통신이 가능하게 됩니다!
Internet Gateway는 VPC 내부의 인스턴스들이 인터넷과 통신할 수 있도록 해주는 게이트웨이입니다
곧 이야기 하겠지만, 사실 인터넷 게이트웨이만 만든다고 퍼블릭 서브넷이 되지 않고,
🌟 퍼블릭 서브넷으로 만들고 싶은 서브넷을 인터넷 게이트웨이를 통해 밖으로 나가도록 라우팅 테이블 설정을 해줘야 한다!
즉, 서브넷이 외부와 통신하려면 해당 서브넷이 Public Subnet으로 설정되어야 한다!
이를 위해 라우팅 테이블(Route Table) 설정이 중요 하다!
정도로 이야기할 수 있겠다.
네트워크 패킷이 이동할 때 특정 방향으로 가게 한다 = 라우팅
따라서, Public Subnet으로 만들고자 하는 서브넷의 라우팅 테이블을 수정하여
해당 인터넷 게이트웨이로 향하는 라우팅 항목을 추가해야 한다!
이렇게 하면 서브넷 내의 인스턴스들이 외부와 통신할 수 있게 된다!!!!!
해당 그림을 참고해보자.
1. 인터넷 게이트웨이를 만든다.
2. 라우팅 테이블 수정!
예시)
Destination : 0.0.0.0/0 (모든 IP주소를 의미 = 외부 모든 아이피 => 밖으로 나갈 때 외부 모든 IP 허용!)
Target : 만들어둔 인터넷 게이트웨이 식별자(저 그림에선 igw-1234567901234567)
이렇게 만들어진 라우팅 테이블을 내가 원하는 서브넷에 연결하여 public subnet을 만들게 된다!
-> 외부와 통신가능!!!
Destination : 10.0.0.0/16
Target : Local그렇다면, 이것을 해석해보면??
1. 목적지 : 10.0.0.0/16 대역에 속하는 모든 IP 주소를 대상으로 함. (VPC로 들어올 때)
2. Target : Local
해당 대상 네트워크로의 트래픽이 어디로 보내지는지!
VPC 내부의 [다른 리소스]로의 트래픽!
=> VPC 내부 에서 [LOCAL(내부)] 로의 트래픽
말이 어렵지만, 결론만 말하면
이 라우팅 항목은 같은 VPC 내에서의 트래픽을 처리하기 위해 사용된다!
💡Private Subnet
그렇다면 Private Subnet은 뭘까?
Private Subnet은 Public Subnet과 달리,
아무런 조치를 취하지 않아 (VPC가 기본적으로 사설 아이피)
외부와 단절된 서브넷을 뜻한다!
- 아주 쉽게 이야기하면,
원래 VPC = 사설 IP = Private Subnet
인터넷 게이트웨이를 만들고, 라우팅 테이블 수정! 해서 만든 것이 Public Subnet!
사설 IP 주소: 사설 IP 주소는 특정한 범위 내에서만 사용되며, 인터넷 상에서 직접 접근할 수 없다.
Private Subnet: Private Subnet은 VPC(Virtual Private Cloud) 내에서 네트워크를 분리하고 보안을 강화하기 위해 사용된다.
이러한 Private Subnet에 속한 인스턴스들은 외부와 직접 통신할 수 없고, 사설 IP 주소를 사용하여 내부에서만 통신한다.
💡사설 IP 대역에 대하여
그래서 왜 Private Subnet이 필요하고, 왜 이런식으로 복잡한 구조를 만들어 놓은거야? 😞😞
그 이전에 사설 IP는 무슨 역할을 하는걸까?
1. 부족한 아이피 주소 문제를 완화
우리가 사용하는 디바이스 (핸드폰, 혹은 노트북)에 공용 아이피 주소가 할당이 되어 있을까?
답은 "NO"
공유기를 사용하는 휴대폰을 가정해보자!
공유기는 NAT(Network Address Translation)라는 서비스를 사용한다!
공용 아이피 주소는 공유기에만 할당되고,
나머지 공유기에 연결한 디바이스들은 사설 아이피 대역을 배정 받는다.
사설 네트워크 내에서는 사설 IP 주소를 사용하고, 이 네트워크의 디바이스가 인터넷에 접근하려면 공용 IP 주소가 필요 하다.
이때 NAT는 다음과 같은 역할을 수행한다!
내부 사설 IP 주소를 공용 IP 주소로 변환
패킷을 정상적으로 라우팅: (Port로 구별)
포트포워딩의 포트 와 소켓에서 포트 는 다른 개념
2. 높은 보안성
-> 결국 2번(보안성)과 연결되는 데,
NAT는 내부 네트워크의 구조를 감추고 외부로부터의 직접적인접근을 차단함으로써 보안을 향상시킨다!
AWS VPC에서 사설 IP를 이 보안성의 측면에서 조금 더 봐보자!
💡Private Subnet의 의의 - 소중한 자원의 보호
사실, 대학생 수준에서 테스트 인프라를 구축할 때는
사실 Private Subnet을 사용하지 않아도 상관없다.
허나 실제 런칭을 할 때!
릴리즈 서버의 경우는 실제 고객의 데이터가 저장되는 데이터베이스를 보호해야 하므로,
데이터베이스를 Private Subnet에 배치하는 것이 필요하다.
그렇다면 아래의 2가지 의문점이 생길 수 있습니다.
1. Private Subnet에 두면 외부와 통신이 안된다며... 어떻게 접근할까?
2. DB에 원격으로 접속하고 싶은 경우에는?
1번 해결책 : 데이터 베이스를 사용하는 EC2 등과 같은 컴퓨팅 자원을 같은 VPC에 배치하면 해결할 수 있다.
아까 같은 VPC의 서브넷은 통신이 가능하다!! 라고 했다!
2번 해결책 : Private Subnet의 Bastion host
아래에서 다시 이야기해보자!
💡Private Subnet의 Bastion host
배포할 예정이라, 데이터 베이스를 보호하기 위해 Private Subnet에 배치하였다!
그런데, 실제로 데이터가 잘 저장이 되었는지 DataGrip으로 원격 접속하여 확인해보고 싶은데..........
Private Subnet과 같은 VPC에 존재하는, Public Subnet의 호스트의 도움을 받으면 된다!
그 호스트의 이름이 바로 Bastion host(배스천 호스트)!
요약하자면,
Bastion Host는 외부에서 접근 가능한 공개적인 호스트로서
Private Subnet에 있는 자원에 접근하기 위한 게이트웨이 역할을 한다!
실제로 DataGrip으로 Private Subnet의 데이터베이스에 원격 접속을 하기 위해서는 SSH 터널링 이라는 기술이 필요하다.
하지만 DataGrip에서 아주 쉽게 설정이 가능하다!
- 다음 포스팅에서 실제로 AWS EC2 를 다뤄보자
