서론
AWS 클라우드를 사용하면서, 기본적인 VPC, CIDR에 대한 개념을 확실하게 정리하지 않고 사용하고 있다고 생각했습니다. 그래서 기본에 충실히 하고자 AWS VPC, CIDR에 대한 개념을 정리하고, 이를 바탕으로 Bastion Host를 구현하는 것을 목표로 글을 쓰려고 합니다.
VPC
VPC는 어떤 역할?
VPC는 데이터센터처럼 논리적으로 격리된 가상의 네트워크로 네트워크를 분리할 수 있게 도와줍니다.
VPC를 왜 사용하고 특징은?
VPC 사용 이유
만약 VPC가 없었다면, 인스턴스에 대해 공통으로 네트워크 설정이 필요할 때, 각각의 인스턴스마다 설정하는 번거로움이 있을 것입니다. 또한 사내에서만 사용되는 인스턴스들이 있을 수 있고, 또 대외적으로 사용하는 인스턴스들이 있을 수 있는데, 규모가 커질수록 이를 관리하는 비용이 커지게 됩니다 .
하지만 VPC의 등장으로 이런 수고를 덜 수 있게 되었습니다.
그래서 VPC는 다음과 같은 장점이 있습니다.
- 하나의 네트워크 안에 인스턴스들이 존재하기 때문에 관리 비용이 줄어듭니다.
- 네트워크를 분리하여 각자 독립된 환경을 구성할 수 있습니다.
CIDR
이렇게 AWS VPC 개념에 대해 알게 되었는데, 저희는 VPC 내부에 Subnet을 생성하여 EC2, RDS와 같은 리소스를 두게 됩니다. 이때 Subnet에 IPv4 CIDR이라는 용어가 나오게 되는데, 이 CIDR에 대해 알아보겠습니다.
CIDR은 무엇이고 왜 사용하는가?
CIDR은 Classless Inter-Domain Routing의 약자입니다. 해석하면 클래스 없는 도메인 간 라우팅 기법으로, 이것이 의미하는 바는 클래스 없이 네트워크를 구분하겠다는 얘기입니다.
CIDR 탄생 배경
그러면 CIDR이 나오게 된 배경이 무엇인지 먼저 설명할 필요가 있습니다.
IP 주소는 한정되어 있어 이를 효율적으로 사용하기 위한 방법이 필요했습니다. 그 해결책으로 위 이미지에서 볼 수 있듯 하나의 IP에 대해 네트워크 영역, 호스트 영역을 나누어 클래스 단위로 이를 구분했습니다.
Class A
- 1.0.0.0 ~ 126.0.0.0까지로 네트워크 주소를 가질 수 있습니다.
- 호스트의 개수는 네트워크 영역을 제외해서 2^24 - 2 개입니다.
- 0.0.0.0은 미지정 주소, 127.0.0.0은 루프백 주소로 사용되기 때문입니다.
Class B
- 128.0.0.0 ~ 191.255.0.0를 네트워크 주소로 가질 수 있습니다.
- 호스트의 개수는 네트워크 영역을 제외해서 2^16 - 2 개입니다.
Class C
- 192.0.0.0 ~ 223.255.255를 네트워크 주소로 가질 수 있습니다.
- 호스트의 개수는 네트워크 영역을 제외해서 2^8 - 2 개입니다.
클래스마다 공통으로 호스트의 개수를 2개씩 빼주었는데, C 클래스를 예시로 그 이유를 설명하겠습니다.
C 클래스에서 네트워크 주소를 192.0.0.0으로 가진다고 가정했을 때, 호스트 영역은 192.0.0.0 ~ 192.0.0.255 까지입니다. 192.0.0.0은 네트워크 주소로 사용되고, 192.0.0.255는 브로드캐스트 주소로 사용되고 있기 때문에 특별히 사용할 수 없어 2개를 빼주게 됩니다.
문제점
클래스 단위로 나누었을 때 한 가지 문제점이 있습니다. 만약 사내에서 사용하는 인스턴스가 500개가 있다고 가정해 보겠습니다. 이때 C 클래스 호스트 개수는 254개이기 때문에 충족하기 어려워, C클래스를 사용하는 2가지 네트워크 주소가 필요하거나 B 클래스를 사용해 IP를 할당해야 합니다.
만약 C 클래스를 두 개를 사용하면 분리된 네트워크이기 때문에 통신하는 과정이 추가로 필요할 것이고, B 클래스를 사용하면 비효율적으로 IP 주소를 사용하게 됩니다.
결국 클래스 단위의 IP 할당은 IP 주소 낭비와, 너무 큰 브로드캐스트 범위로 패킷전송을 느리게 하여 비효율이 발생하게 됩니다. CIDR는 이런 비효율적인 IP할당을 유연하게 해줍니다.
CIDR로 유연하게 IP 할당
위 그림처럼 AWS에서 VPC나 Subnet을 보면 172.31.0.0/16, 172.31.32.0/20 와 같은 정보들이 보이는데 이것이 CIDR 표기법입니다. 172.31.0.0/16을 예시로 들어보면 172.31 부분은 네트워크 영역, 172.31.0.0 ~ 172.31.255.255는 호스트 영역으로 가질 수 있습니다. 이전에 봤던 B 클래스와 동일하다고 볼 수 있습니다.
그러면 앞에서 가정했던 500개 인스턴스에 대해 IP를 할당하고 싶다고 했을 때 IPv4 CIDR 블록은 172.31.2.0/23과 같이 지정하여 해결할 수 있습니다. 여기서 호스트 영역은 172.31.2.0 ~ 172.31.3.255로 총 512개 IP를 가질 수 있기 때문입니다.
결론적으로 CIDR을 잘 활용하면 낭비를 최소화하여 IP를 할당할 수 있습니다.
Bastion Host
CIDR을 통해 서브넷을 분리하였는데, 서브넷 종류 중 Public Subnet, Private Subnet이 존재합니다. Private Subnet은 아무나 접근할 수 없도록 리소스들을 배치하고, Public Subnet에는 문지기와 같은 리소스를 하나 두어 이를 통해서만 Private Subnet에 위치한 리소스를 접근하도록 구축하면 보안성이 올라가지 않을까요? 이 때 활용할 수 있는 개념이 Batstion Host 입니다.
Bastion Host는 무엇이고 왜 사용하는 가?
모든 AWS 리소스를 같은 VPC 내부 Public Subnet에 둔다면 외부에서 직접 접근할 수 있게 되는 면적이 커지면서 보안 취약점이 생기게 됩니다.
이를 방지하기 위해선 위 그림처럼 인터넷에서 접근 가능한 리소스를 Public Subnet에 하나만 두고, 다른 리소스들은 Private Subnet에 두어 직접 접근할 수 있는 면적을 최소화 시켜야 합니다. 이 때 Public Subnet에서 Private Subnet으로 접근을 가능하게 만들어 주는 리소스를 Bastion Host라고 명명합니다.
장점
- Private Subnet에 위치한 리소스는 인터넷에서 바로 접근할 수 없기 때문에 더 안전한 환경을 가질 수 있습니다.
- Bastion Host를 거쳐서 Private Subnet에 위치한 리소스에 접근할 수 있기에 이에 대한 로그를 남겨 모니터링을 할 수 있습니다.
단점
- Bastion Host를 무조건 거쳐서 리소스를 획득하는 인스턴스들이 많다면 Bastion Host의 성능에 신경써야 한다.
- Bastion Host 서버가 다운되면 리소스 획득이 어려워질 수 있다(SPOF 문제).
SSH Tunneling
Bastion Host를 통해 Public Subnet에서 Private Subnet으로 접근 가능하다는 것을 확인했습니다. 그러면 저희가 매번 private subnet에 있는 요소들에 접근하기 위해서는 터미널에서 매번 bastion host에 접속해야 할까요?
꼭 그렇지만은 않습니다. SSH Tunneling을 통해서 직접 접근할 수 있습니다. 예를 들어 RDS를 Private Subnet에 두어 public 접근을 막고, Public Subnet에 있는 EC2를 통해 접속하고 싶다고 가정해보겠습니다.
저는 IDE를 통해서 접속할 수 있도록 해보겠습니다.
1. IDE에 SSH 탭을 선택
Jetbrains의 Intellij는 기본적으로 SSH Tunneling을 지원하고 있습니다.
맨 오른쪽에 Database를 눌러 Datasource를 추가하는 과정에서 설정을 보면 SSH/SSL 탭을 눌러 SSH tunneling을 할 수 있습니다.
2. 터널링 설정
Private Subnet에 위치한 RDS에 접근하기 위해서, Public Subnet에 위치하고 Bastion Host 역할을 하고 있는 EC2에 대한 정보를 기입해줍니다.
Host, Username, Authentication type, Private key file에 대한 정보는 EC2 인스턴스 연결에서 SSH 클라이언트 탭에서 확인하실 수 있습니다.
3. DB 연결
터널링 설정을 끝마치면 실제로 접속할 DB 인스턴스 정보를 입력해야 합니다. RDS에서 사용하고 있는 Host 주소, User, Password에 기입하고 연결을 하면 성공적으로 SSH Tunneling 세팅을 끝마칠 수 있습니다.
이번 포스팅에서 NAT, IGW, DHCP와 같은 개념에 대해 다루진 못하였지만, 추가적으로 보면 좋을 개념이라고 생각됩니다.
궁금한 점이나 보충했으면 하는 부분이 있다면, 댓글 남겨주시는대로 확인하겠습니다.
부족한 글이지만 읽어주셔서 감사합니다.
'AWS' 카테고리의 다른 글
| AWS Lambda Java With SnapStart (2) | 2024.06.24 |
|---|---|
| Route 53, DNS 그리고 레코드 (2) | 2024.05.30 |