AWS VPC를 디자인해보자(3) - NAT Gateway 와 Bastion host

AWS VPC를 디자인해보자(3) -  Private Network을 위한 NAT Gateway 와 Bastion 호스트

[Contents]

  1. VPC를 디자인 해보자 (1) - Multi AZ를 활용한 고가용성

  2. VPC를 디자인 해보자 (2) - Network ACL과 Security Group을 활용한 보안 강화

  3. VPC를 디자인 해보자 (3) - Private Network을 위한 NAT Gateway 와 Bastion 서버

  4. VPC를 디자인 해보자 (4) - VPC Peering을 활용한 Multi VPC 사용하기

 VPC(Virtual Private Cloud) 서비스는 AWS 사용자가 직접 가상 네트워크 환경을 구성하는 서비스이다. 이 서비스를 이용하면 Public network 환경과 Private network 환경을 사용자가 원하는대로 디자인하고 구축할 수 있게 된다.

 또한 다양한 부가 기능을 통해 VPC 환경 내 네트워크 흐름을 제어할 수 있기 때문에 나만의 가상 데이터 센터를 구축하여 사용할 수 있게 된다.

 이번 포스팅에는 VPC의 Private Subnet을 위한 NAT Gateway 와 Bastion host에 대해 알아보자.

---

1. NAT Gateway

위 그림은 VPC를 이용해 구성한 Network 환경이다. 

 Subnet 을 Public 과 Private 으로 구분하여, Public subnet은 Internet Gateway 를 이용하여 외부와 통신이 가능하도록 설정하였다. 하지만, Private Subnet 의 경우는 외부와의 통신이 단절된 환경이다. 보안을 높이기 위한 선택이지만 불편함이 따를 수 밖에 없다. 

아래의 경우를 가정 해보자.

• Private Subnet에 위치한 instance가 다른 AWS 서비스에 연결해야 하는 경우. 
• 인터넷에서 Private instance 에 접근 불가 조건은 유지하면서 반대로 instance 에서 외부 인터넷으로 연결이 필요한 경우. 

 위와 같은 이유로 Private Subnet에 배포된 instance 라도 외부와의 통신이 필요한 경우가 있다. 이런 경우 가장 간단히 해결 할 수 있는 방법은 NAT 서버를 구축하는 것이다. 이전에는 외부 통신이 가능한 Public Subnet 에 EC2 instance를 배포하고 이를 NAT 서버로 구축하여 사용하는 방법이 일반적이었다. 하지만 최근 VPC 환경에 NAT 서버를 손쉽게 배포하고 관리해주는 서비스인 NAT Gateway를 제공해 주고 있다. 

NAT 서버에 대한 Managed 서비스 이기 때문에 NAT 서버에 대한 운영 부담을 덜 수 있는 장점이 있다. 

아래는 직접 NAT 서버를 구축해 사용하는 것과 NAT Gateway 서비스를 사용하는 것에 대한 비교 자료이니 참고. 

NAT 인스턴스 및 NAT 게이트웨이 비교

  위 그림은 Public Subnet 에 NAT Gateway를 추가한 형상이다. 

 사용하는 방법은 매우 간단하다. NAT Gateway를 생성 후 Private Subnet 에 적용된 Route table에 NAT Gateway 로 가는 경로만 추가해 주면 된다. 

 아래는 NAT Gateway를 적용하는 방법이다.

 * 아쉽게도 Seoul 리전의 경우 아직 NAT Gateway 기능을 제공하지 않으니 참고.

 * 6.24 일자로 Seoul 리전에도 NAT Gateway 기능이 사용 가능 합니다

---

NAT Gateway 설정 방법

 VPC 메뉴 중 NAT Gateways 를 선택 후 Create NAT Gateway 버튼을 눌러 NAT 를 생성한다. 

 

• NAT Gateway를 생성할 Subnet을 지정하는데 반드시 Public 통신이 가능한 Subnet에 생성한다. 
• NAT Gateway에 연결할 EIP를 할당한다. 만약 EIP가 없다면 Create New EIP 하면 된다. 

NAT Gateway는 생성되는데 시간이 걸리므로 Status가 Available 될때까지 기다린다. 

Available 되었으면 Private Subnet에 적용된 Route table에 NAT Gateway로 경로를 설정해 주면 끝이다. 

NAT Gateway 통신을 위한 Network ACL 설정

이미 VPC 에 Network ACL 과 Security Group 을 적용하여 사용 중이라면, Private Subnet 에서 NAT Gateway 통신을 위해 규칙 설정을 해줘야 한다. 

먼저, ACL 설정을 살펴보자. 

NAT Gateway는 Public Subnet에 존재하고 Private Subnet 과 통신을 한다. 

그러므로 Private Subnet에 적용된 ACL에 아래와 같이 설정해 보았다.

 * 참고 : 생성된 NAT Gateway 의 Private IP 를 확인하도록한다. 여기서는 10.10.1.31 로 생성되었다.

• Private Subnet 에는 MySQL이 배포된다고 가정하고, 3306 포트를 허용하였다. source IP 대역은 Public Subnet 대역인 10.10.1.0/24 10.10.2.0/24 이다. 
• 외부 통신시 사용되는 Ephemeral Port 32768~60999 를 허용하였다. source IP 는 NAT Gateway IP인 10.10.1.31 만 허용하였다. Private Subnet의 경우 외부와 통신되는 경우는 NAT Gateway 를 통해서만 되기 때문이다. 
• yum repository 와의 통신을 위해 80 포트도 추가해 주자. source IP 는 NAT Gateway IP 이다.  
• 통신이 잘 되는지 테스트해보기 위해 ICMP 를 허용 하였다. source IP 는 NAT Gateway IP 이다. 참고로 Public Subnet 에도 ICMP를 허용해 주도록 한다. NAT gateway 는 public subnet 에 있으므로 public subnet 에 적용된 ACL의 규칙을 적용 받는다. 

이제 Private Subnet에 배포된 instance 에서 외부와 통신이 잘 되는지 확인해 보자. 

간단히 instance 에서 외부로 통신이 되는지 ping 을 통해 확인해 보자. 

root@~~# ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=2.13 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=1.90 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=2.73 ms

....

global repository 에서 yum install 이 되는지도 확인해보자. 

root@~~# yum update

Loaded plugins: priorities, update-motd, upgrade-helper

Resolving Dependencies

--> Running transaction check

---> Package curl.x86_64 0:7.40.0-8.57.amzn1 will be updated

---> Package curl.x86_64 0:7.40.0-8.58.amzn1 will be an update

---> Package libcurl.x86_64 0:7.40.0-8.57.amzn1 will be updated

---> Package libcurl.x86_64 0:7.40.0-8.58.amzn1 will be an update

--> Finished Dependency Resolution

Dependencies Resolved

.....

Private 환경에 있더라도 NAT를 통해 외부와 통신이 잘 됨을 알 수 있다. 

NAT Gateway는 Managed 서비스 이므로 사용시 과금이 청구된다. 

Gateway 당 시간 단위로 비용이 청구 되며 NAT 를 통해 처리된 데이터에 대한 요금도 추가로 발생된다. 

비용은 아래 링크를 통해 확인 가능하다.

VPC NAT Gateway 비용

---

2. Bastion Host

 Private Subnet에 배포된 instance의 경우 외부에서 접근이 차단되어 있기 때문에 SSH 로 접근할 수 있는 방법이 없다. 하지만 운영자는 서버를 관리 하기 위해 SSH 접속이 필요하다. 이러한 경우 Bastion host 라는 방식으로 외부 접근이 가능하도록 구성한다.  

 Bastion host는 Private 네트워크 환경에 접근하기 위한 일종의 Proxy 역할을 하는 서버라고 보면 된다.  Private subnet에 배포된 모든 instance 들은 bastion을 통해 SSH 접속을 허용하도록 한다. 접근 허용을 한 곳으로 한정 지음으로 좀 더 보안성을 높이고자 하는 목적이 있으며 bastion host의 logging 만 관리하면 private subnet에 접속하는 모든 기록을 관리할 수 있다. 

 단, bastion host 가 공격 당하면 내부 네트워크가 모두 위험해 질 수 있으므로 bastion host에 대한 접근을 최대한 철저히 관리하는게 좋다. 

아래는 Bastion host 를 이용해 Private Subnet 에 배포된 instance 에 접속되는 구조이다.

• Bastion host는 Public Subnet에 위치하도록 EC2 instance를 생성한다. 외부 사용자는 Bastion host 를 통해 접속한다. 
• 외부 사용자의 특정 IP만 허용하여 Bastion host에 접속 가능하도록 ACL 과 Security Group을 설정한다. 
• Bastion host 를 통해 Private Subnet에 상주한 instance 로 접속 한다. 

SSH Tunneling

 Bastion host 에서 SSH 접속을 Proxy 하는 여러가지 방법이 있다. 여기서는 SSH Tunneling 을 이용해 외부에서 Private instance 에 접속하는 방법을 소개한다. 

이해를 돕기 위해 현재 환경을 정리하면 아래와 같다. 

• Bastion host Public IP :  52.100.1.1 
• 접속 타겟 instance Private IP : 10.10.101.225

먼저 Local PC 에서 Bastion host 에 SSH 할때, -L 옵션을 이용하여 접속한다. 

SSH를 이용해 Bastion host 에 접속하는데 Local 터널링으로 접속하는 명령어이다.

ssh -i key.pem -L 22:10.10.101.225:22 ec2-user@52.100.1.1

여기서 -L 옵션인 22:10.10.101.225:22 의 의미는 "로컬 포트 22번 으로 접속 타겟 instance(10.10.101.225)의 22번 포트로 접속하겠다" 는 의미이다 .

이렇게 SSH를 접속해 놓은 상태에서 터미널을 한개 더 열고 

ssh -i key.pem ec2-user@localhost

위와 같이 접속하면 자동으로 타겟 instance 로 SSH Tunneling 되어 접속됨을 볼 수 있다. 

위와 같은 방법으로 Private Subnet에 위치한 모든 서버에 접속 가능하다. 

[ 참고 ]

• https://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/vpc-nat.html
• https://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/vpc-nat-comparison.html