리전
AWS에서 수많은 컴퓨팅 서비스를 하려면 당연히 대규모의 서버 컴퓨터를 모아 둔 곳이 필요할 것이다. 이 때 한 곳에 전부 다 몰아두면 아래의 2가지 불편한 점이 생긴다.
- 자연 재해가 발생 할 경우 모든 서비스가 마비가 된다.
- 모든 자원이 북미에 있다면, 지구 반대편의 아시아 지역은 멀어서 서비스가 느리다.
따라서 위의 2가지 문제를 해결하고자 서비스를 하기 위한 자원들을 여러 곳에 분산해서 배치를 해둔 것이라고 생각하면 된다.
가용영역
가용영역은 리전을 한번 더 분산해서 배치한 것이라고 생각하면 된다.
VPC
VPC는 독립적인 가상의 네트워크 공간으로 사용자의 설정에 따라 자유롭게 구성할 수 있는 공간을 의미한다. 따라서 사용자는 서브넷 생성, 라우팅 테이블, 네트워크 게이트웨이 구성 등 네트워킹 환경을 사용자가 원하는 대로 완벽하게 제어할 수 있다.
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 자체에서도 서브넷을 나눠서 사용하게 된다.
예시로 10.0.0.0/16의 아이피 주소를 VPC에 할당한 상황에서, VPC를 원하면 다시 서브넷으로 나눠서 (단, VPC를 나눈 서브넷을 다시 나누지는 못한다.) 각각 서브넷을 원하는 가용영역에 배치하여 사용하게 된다.
이 때, **유의해야 하는 점**이 있다.
VPC의 서브넷 아이피 대역에서는 실제 네트워크와 달리, 총 5개의 아이피 주소를 호스트에 할당 할 수 없다는 것이다.
| 10.0.0.1 | 네트워크 주소(Network ID) |
| 10.0.0.2 | AWS에서 VPC 라우터용으로 예약(Default Gateway) |
| 10.0.0.3 | DNS 서버 주소 DNS 서버의 IP 주소는 기본 VPC 네트워크 범위에 2를 더한 주소이다. CIDR 블록(서브넷)이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치하게 된다. |
| 10.0.0.4 | AWS에서 앞으로 사용하려고 예약한 주소 |
| 10.0.0.255 | 네트워크 브로드캐스트 주소 |
이를 통해 우리는 'VPC 내부적으로 라우터가 있고, VPC 내부 서브넷끼리 통신이 된다'라는 것을 알 수 있다.
VPC와 외부통신
아시다시피 기본적으로 사설 아이피 대역은 공용 아이피 대역과 통신이 불가능하다. 그런데 AWS로 인프라를 구축하면 통신이 된다. 왜 그럴까요?
여기서 또 한 가지 개념이 등장한다. 바로 Public Subnet과 Private Subnet이다.
Public Subnet
VPC 서브넷 중 외부와 통신이 원활하게 되는 Subnet 대역
AWS의 Internet Gateway를 통해 해당 Subnet을 Public Subnet이 되게 할 수 있다.
Subnet이 외부와 통신 할 때, Internet Gateway를 거치게 하면 외부와 통신이 가능하게 된다.
하지만, Internet Gateway만 만든다고 Public Subnet이 되지 않는다. Public Subnet으로 만들고 싶은 Subnet을 Internet Gateway를 통해 밖으로 나가도록 라우팅 테이블(Routing Table)을 설정해줘야 한다.
위 그림처럼 Internet Gateway를 만들고 라우팅 테이블에서
Destination : 0.0.0.0/0(모든 IP주소를 의미 = 외부 모든 아이피 = 밖으로 나갈 때)
Target : 만들어둔 인터넷 게이트웨이 식별자(저 그림에선 igw-1234567901234567)
이렇게 만들어진 라우팅 테이블을 **내가 원하는 서브넷에 연결하여** public subnet을 만들게 된다.
Destination : 10.0.0.0/16 (VPC 주소 = VPC로 들어올 때)
Target : Local (내부 VPC 라우터가 알아서 잘 보내줄 것)
이렇게 해석하면 된다.
Private Subnet
Public Subnet과 달리, 아무런 조치를 취하지 않아 외부와 단절된 Subnet입니다.(VPC가 기본적으로 사설 아이피이다.)
그러면 Private Subnet은 무슨 의미가 있을까?
이는 사설 IP 대역의 존재 의의를 생각해보면 쉽게 이해할 수 있다.
사설 IP 대역의 역할은 크게 2가지가 있다.
- 부족한 IP 주소 문제 완화
- 높은 보안성
먼저, 1번부터 말을 해보자.
Q. 우리들의 휴대폰, 혹은 노트북에 공용 IP 주소가 할당되어 있을까?
대답은 '아니다' 이다.
사실 공용 IP 주소는 공유기에만 할당이 되고, 공유기에 연결한 디바이스들은 사설 IP 대역을 받게 된다.
외부 인터넷은 공유기로 먼저 데이터를 보내고, 공유기는 포트를 통해 각 디바이스들을 구분하여 데이터를 보내주게 된다.
다시 말해, 공유기의 80번 포트는192.168.0.1이 할당 된 노트북이, 공유기의 8080번 포트는 192.168.0.2가 할당 된 PC가 연결이 된 것이다. 즉, 포트포워딩이 된 것이다.
포트포워딩
하나의 공용 아이피 주소를 가진 공유기가 자신의 포트를 통해 올바른 사설 아이피 주소를 가진 디바이스에게 데이터를 주는 것
자, 다음으로 아이피 주소 부족을 완화하는 것 외에도 사설 아이피를 사용하는 것은 다른 이점이 있다, 이는 바로 보안성이다.
외부 네트워크의 디바이스는 공유기 뒤에 사설 아이피를 가지고 있다. 이 숨어있는 디바이스로 직접 데이터를 절대로 전송할 수 없고, 무조건 공유기를 거쳐야 한다.
이 때, 공유기가 이상한 데이터는 버려준다면, 이는 보안성 측면에서 좋다고 할 수 있을 것이다.
AWS VPC에서 사설 아이피는 이 보안성의 측면에서 이해를 하면 된다.
우리가 프로젝트를 진행하며 인프라를 구축할 때는 사실 Private Subnet을 사용하지 않아도 된다.
허나, 릴리즈 서버의 경우는 실제 고객의 데이터가 저장되는 데이터베이스를 보호해야 하므로,
데이터베이스를 Private Subnet에 배치하는 것이 필요하다.
Private Subnet의 의문점
위의 글을 읽으면 아래와 같은 2가지 의문점이 생길 수 있다.
- Private Subnet에 두면 외부와 통신이 안되는데, 그러면 데이터베이스를 못 쓰는 것 아닌가?
- 데이터베이스에 원격으로 접속하고 싶은데 가능한가?
우선 1번의 경우는, 데이터 베이스를 사용하는(DB에 데이터를 저장하려는) EC2 등과 같은 컴퓨팅 자원을 같은 VPC에 배치하면 됩니다.(같은 VPC의 서브넷은 통신이 가능하기 때문)
2번의 경우는 다음 개념을 이해하면 된다.
Bastion Host
아래와 같은 상황이 있다고 하자.
릴리즈 인프라에서 사용 될 데이터 베이스를 보호하기 위해 Private Subnet에 배치하였고, 실제로 데이터가 잘 저장이 되었는지 Mysql Workbench 혹은 DataGrip으로 원격 접속하여직접 눈으로 편하게 확인하고 싶다.
허나 Database는 Private Subnet에 존재하여 DataGrip으로는 절대 원격접속이 안됩니다.
(실제로는 DataGrip으로 Private Subnet의 데이터베이스에 SSH 터널링 기술을 통해 원격 접속을 할 수 있다.)
이런 경우, Private Subnet과 같은 VPC에 존재하는, Public Subnet의 호스트의 도움을 받으면 된다.
이 때, Private Subnet의 자원에 접속이 되도록 도와주는 호스트를 배스천 호스트( Bastion host )라고 부른다.
