02. AWS (VPC & Internet Gateway & EC2)
💡 학습 목표
1️⃣ AWS의 VPC 이해
2️⃣ 서버가 어떻게 구축되는지 이해
이번 챕터에서는 Amazon Web Service의 VPC에 대한 이론을 학습하고, EC2를 구축해 보는 실습을 진행해 보려고 한다!
AWS의 리전과 가용영역
AWS를 사용하다 보면, 리전 이나 가용영역 이라는 말을 자주 볼 수 있다.
이름만 보면 어떤 의미인지 유추할 수 있지만 각각 개념을 살펴보면 다음과 같다.
리전 (Region)
리전은 내가 사용할 리소스가 있을 지리적 위치를 의미한다.
(💡공식 홈페이지에는 'AWS가 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치'라고 소개되어 있다.)컴퓨팅 서비스를 위해서는 대규모 서버를 모아두어야 하는데 이를 한 곳에 두면 두 가지 문제점이 생길 수 있다.
- 자연 재해가 발생할 경우 모든 서비스가 마비됨
- 예를 들어, 북미에 모든 자원이 있다면 아시아 지역은 서비스가 느림
따라서 이를 해결하고자 컴퓨팅 서비스를 하기 위한 자원들을 여러 곳(리전)에 분산해서 배치한다.
위 이미지는 AWS가 현재 어떤 리전에서 서비스를 하는지 나타낸다. 현재 33개의 지리적 리전을 가지고 있다고 한다! 👍🏻
AWS에서는 아래 이미지처럼 리전을 선택해야 리소스를 사용할 수 있다.
가용영역 (Availability Zone)
가용영역은 리전을 한번 더 분산해서 배치한 것으로, 리전 내의 하나의 데이터 센터라고 이해할 수 있다.
(💡공식 홈페이지에는 'AWS 리전의 중복 전력, 네트워킹 및 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성됩니다.'라고 적혀 있다.)
그리고 하나의 서비스를 여러 가용 영역에 분산해 두면 가용성이 높아진다!
AWS VPC
본격적으로 VPC에 대해 학습하기 전에 다음 세 가지를 기억해 두자.
✏️ Keywords
1️⃣ Subnet
2️⃣ 사설 IP로 외부와 통신하는 방법
3️⃣ 보안을 위한 자원 배치 방법
또한, 서브네팅 & CIDR 표기법과 관련한 지식도 필요하다.
203.230.7.0/24 IP 주소에서 찾아낼 수 있는 것은 무엇일까?
네트워크 아이디가 203.230.7.0 이고,
254개 (2^(32-24) - 2)의 host IP 설정이 가능하다는 것을 IP 주소로 알 수 있다.
VPC
VPC는 Virtual Private Cloud의 약자로, 논리적으로 분리되어 있는 가상의 네트워크를 의미한다.
또한, 이름에서도 알 수 있듯이 Private IP 주소를 가지게 된다.
뒤에 이어질 실습에서 리전을 선택한 후에는 VPC를 생성하게 되는데, 리전에서 VPC를 만들면 자동으로 VPC 안에 모든 가용 영역이 포함된다.
리전 하나에는 최대 5개의 VPC가 가능하고, 각 리전에는 기본 VPC가 하나씩 존재한다.
그리고 다음 세 개의 Private IP 대역을 가진다.
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/24
마지막으로 각 리전에 존재하는 VPC들은 아이피 대역이 겹치면 안된다.
Subnet
VPC를 실제로 사용할 때에는 서브넷을 나누어서 사용한다.
서브넷을 통해 IP 주소를 세분화하면 리소스 배치 및 네트워크 관리가 용이하기 때문이다.
예를 들어, 10.0.0.0/16 의 IP 주소를 VPC에 할당했다면, 아래 이미지와 같이 서브넷을 나눌 수 있다.
VPC의 서브넷 마스크가 16이기 때문에 서브넷의 10.0 부분은 동일해야 한다.
각 서브넷에서는 24bit까지 모두 동일한 값을 가져야 한다. (💡 IPv4 주소에서는 8bit씩 묶어서 표현한다!)
이때 유의할 점은 서브넷을 다시 서브넷으로 나눌 수 없다는 것이다.
그리고 VPC의 Subnet IP 대역에서는 아래 5가지 IP 주소를 Host IP에 할당할 수 없다.
- 서브넷의 네트워크 대역
- VPC 라우터에 할당 🌟
- 아마존이 제공하는 DNS에 할당
- 미래를 위해 예약
- Broadcast 주소
Public Subnet
Public Subnet 은 VPC 서브넷 중 외부와 통신이 원활히 되는 서브넷 대역을 의미한다.
VPC는 논리적으로 독립된 네트워크 망이기 때문에 기본적으로 인터넷 연결이 되어 있지 않다.
따라서 AWS의 Internet Gateway를 이용하면 서브넷을 퍼블릭 서브넷이 되게 만들 수 있다.
즉, Internet Gateway를 거치면 VPC 내부 리소스와 외부 인터넷 간 트래픽을 주고 받을 수 있다.
이때 실제 사용을 위해서는 해당 서브넷의 트래픽이 모두 IGW로 빠져나가도록 라우팅 테이블 설정이 필요하다.
(💡 네트워크 패킷이 이동할 때 특정 방향으로 가게 하는 것은 '라우팅'을 의미함)
즉, 설정된 라우팅 테이블은 위의 이미지와 같다.
여기서 Local은 내부 VPC 라우터가 알아서 잘 보내준다고 생각하면 쉽다.
Private Subnet
Private Subnet 은 외부와 통신이 되지 않는 서브넷 대역을 의미한다.
외부와 통신이 되지 않는다면 의미가 없다고 생각될 수 있지만, Private IP는 IPv4 부족 문제 완화 및 높은 보안성을 제공하는 역할을 한다!
실제로 우리 핸드폰이나 노트북에는 Public IP가 할당되지 않으며, 공유기에만 Public IP가 할당되어 포트를 통해 Private IP가 할당된 각 디바이스를 구분한다.
이때 이 과정을 포트포워딩 (Port Forwarding)이라고 한다.
위 이미지에서 외부 인터넷은 공유기로 먼저 데이터를 보낸다.
그리고, 공유기의 80번 포트에는 192.168.0.1 Private IP가 할당 된 노트북이, 8080번 포트에는 192.168.0.2 Private IP가 할당 된 노트북이 연결되어 외부 인터넷으로부터 데이터를 받을 수 있다.
※ 여기서 포트포워딩의 포트와 소켓의 포트는 서로 연관이 없다 ‼️
그렇다면 Private Subnet은 왜 사용하는 것일까?
만약 서버가 전부 Public IP를 가진다면 외부에서 서버를 찾아갈 수 있는 방법이 있기 때문에, 악의적인 공격을 받을 수 있다.
이때 Private Subnet에 서버가 존재한다면, VPC에 속하지 않은 외부의 공격자는 서버에 찾아갈 수 없기 때문에 보안성이 좋다.
예를 들어, 릴리즈 서버 같은 경우는 실제 고객의 데이터가 저장되는 DB를 보호해야 하기 때문에 우리는 이를 Private Subnet에 배치해야 한다.
여기서 헷갈리기 쉬운 개념이 하나 있다! 🌟
Private Subnet은 Private IP를 가진다. (X)
Public Subnet은 Public IP를 가진다. (X)
IGW 연결 유무로 Private Subnet/Public Subnet이 구분된다는 점을 항상 유의하자!!
데이터베이스를 Private Subnet에 둔다면 두 가지 궁금증이 생길 수 있다.
-
외부와 통신이 안 되는 Private Subnet에 데이터베이스를 두면 쓸 수 있을까?
→ 같은 VPC의 서브넷은 통신이 가능하기 때문에 EC2를 같은 VPC에 배치하면 된다. -
Private Subnet에 위치한 데이터베이스에 원격으로 접속할 수 있을까?
→ Bastion host의 도움을 받으면 가능하다.
위의 이미지에서 볼 수 있듯이 Bastion host에서 pem 키를 이용하여 Private Subnet에 ssh 연결을 할 수 있다.
실습
1️⃣ VPC를 이용한 EC2 구축
서울을 Region으로 한 후, 검색창에VPC를 검색하면 VPC를 생성할 수 있다.
VPC의 IP 대역을 10.0.0.0/16 으로 하여 my-vpc 라는 이름의 VPC를 생성했다.
IP 대역의 서브넷 마스크를 잘 설정해야 서브넷의 CIDR 블록을 설정할 때 쉽다 🙃
그리고 두 가지 Subnet을 생성했다. 하나는 IGW를 연결할 public-subnet-1, 다른 하나는 private-subnet-1 이다.
다음으로 Internet Gateway를 만들어야 한다.
이름은 my-igw 로 설정했다!
이를 사용하기 위해서는 꼭 이전에 만든 VPC에 연결을 해야 한다.
또한, 라우팅 테이블 설정을 아래와 같이 해야 Public Subnet이 외부와 통신할 수 있다.
이론 설명에서 확인했던 테이블을 AWS에서도 확인할 수 있다.
2️⃣ 보안그룹 생성
보안그룹은 인스턴스 각각에 보안 설정을 할 수 있는 서비스이다.
쉽게 생각하면 가상 방화벽이라고 할 수 있다.
보안그룹의 인바운드 규칙을 위의 이미지처럼 설정했다.
인바운드 규칙은 화이트리스트와 비슷한데, 기본적으로 차단하되 리스트에 올라간 목록만 허용하는 방식이다.
3️⃣ EC2 생성
이제 본격적으로 EC2를 생성해 보자!
VPC 생성과 마찬가지로 서울을 Region으로 한 후, 검색창에EC2를 검색한다.
EC2 운영체제를 Ubuntu 20.04 로, 인스턴스 유형을 t2.micro 로 선택했다.
(💡 Ubuntu 20.04가 구글링 시 정보가 많이 나온다고 한다!)
기존에 만들었던 키 페어가 없다면, 원하는 이름으로 생성하면 된다. 이때 생성된 .pem 파일은 꼭 잃어버리지 않도록 조심해야 한다!!
보안그룹도 앞서 인바운드 규칙을 설정한 기존 보안그룹으로 지정했다.
이렇게 생성된 EC2는 Public IP 자동 할당 설정을 했기 때문에 IP 주소가 할당이 되지만, EC2를 중지 후 재실행하게 되면 Public IP가 변경된다.
이러한 상황은 실제 서비스 중이라면 큰 문제가 될 수 있기 때문에 탄력적 IP 설정이 필요하다.
4️⃣ Elastic IP 설정 & 원격 접속
탄력적 IP는 생성 후, 탄력적 IP 주소 연결을 해야 한다.
앞서 생성한 EC2를 선택하면 설정이 완료된다.
macOS에서는 터미널에서 원격접속이 가능하기 때문에 IntelliJ 나 VSCode를 사용하지 않고 터미널에서 남은 실습을 진행했다.
먼저, 앞서 생성된 pem 키를 .ssh 디렉토리로 옮긴 후, 실행권한을 변경해 주어야 한다.
기존 pem 키는 user, group, others 모두에게 읽기 권한이 있어서 pem 키의 권한이 too open 되어있다는 에러가 발생하기 때문이다.
따라서 chmod 600 명령어를 통해 user에게만 read, write 권한을 부여했다.
$ ssh -i "[pem 키 이름].pem" ubuntu@[탄력적 IP 주소]위의 명령어를 이용하면 쉽게 ssh 연결을 할 수 있다!
마지막으로 EC2 서버에 NGINX 설치 후, 브라우저에서 접속 되는지 확인해 보자.
$ sudo apt update
$ sudo apt upgrade -y
$ sudo apt install nginx -y
탄력적 IP 주소를 입력했을 때 위 화면이 뜬다면 성공적으로 접속된 것이다!🙌
최용욱님의 [UMC Server Workbook]을 기반으로 작성했습니다.
