[AWS] NAT Instance: 직접 구성 & AMI로 NAT Gateway 대체 (1부)

 

글의 개요 

1. Why Nat Instance (Instead of Nat gateway) (1부)
2. AWS상에서 제공하는 Nat Instance AMI 이용 하는 방법 (1부)
3. Ip-tables를 이용한 Nat Instance 직접 구성 (2부)

 

 이번 1부 글에서는 AWS 커뮤니티에서 제공되는 Nat Instance AMI를 이용하는 포스팅입니다. 만약, Ip-Tables를 이용해 직접 Nat Instance를 구성하고자 하신다면, 2부를 참고하시기 바랍니다. (아래 링크가 2부입니다)

[AWS] Nat Instance(EC2) 설정 : 직접 구성 & AMI이용(Nat gateway 대체) (2부)

 

 

Nat gateway & Nat Instance?

 최근, AWS상에서 네트워크 및 애플리케이션 아키텍처 구성을 도맡아서 하게 되었다. 당시 그대로는 아니지만, 생각했던 네트워크 구성도는 아래와 같다.

그림1. Nat gateway 대신 Nat Instance(EC2)를 이용한 Private subnet 인터넷 연결도

 

 원래는 사설망(Private subnet)에 인터넷과 통신이 되게 하기 위해서는 Nat Gateway가 필요하다. 하지만, 이번 구성에서는 Public subnet에 Nat Gateway를 따로 두지 않고, EC2(Nat Instance)를 통해 Private Subnet의 인터넷을 연결시키고자 했다. 동시에 Revers Proxy Server의 역할과 Bastion Server의 역할을 동시에 하게 했다. 

 

Nat Instance의 장/단점을 기술해보자면 다음과 같이 서술할 수 있을 것 같다.

 

장점

•  AWS상에서 Nat Gateway를 직접사용하지 않으므로, 가격을 감축할 수 있다. 어차피 Proxy Server 또는 Bastion Server를 둘 거면 해당 Proxy Server를 이용해 인터넷을 연결시킨다는 것이 취지이다.

단점

•  Proxy Server가 셧다운되거나 이상이 생기면 Private Subent의 인터넷이 끊긴다. (어치파 애플리케이션 아키텍처상 Proxy Server가 문제가 생기면 뒤의 서비스는 공급이 안되는게 맞다고 판단) 
•  AWS의 Nat gateway처럼 고가용성, 확장성, 보안, 패치 관리 등을 보장해주지 않는다. 다시 말하면, 본인이 직접 OS버전, 보안 등을 다 관리 해야 한다는 의미이다. (사실상 AWS의 Nat gateway를 쓰는 이유라 할 수 있다)

 

 위의 단점에도 불구하고 Nat Instance를 지접 구성해서 사용하고자 했던 이유는 프로젝트 Scale이 크지 않은 것도 있었으며, 무엇보다 비용을 감축했어야 했기 때문이다. (대략 한달에 기본 유지 비용 $32 + 트래픽에 따른 추가 요금이 들어간다)

 

---

AWS상에서 Nat Instance를 어떻게 만들수 있는지를 알아보도록 해보자. 총 두 가지 방법으로 축약할 수 있을 것이다.

 

 

첫 번째, AWS에서 제공하고 있는 AMI 이용 (커뮤니티에서)

 

1. AMI를 이용한 NAT Instance 생성

그림2. EC2생성창에서 더 많은 AMI 찾아보기 선택

 

EC2생성창에서 "더 많은 AMI 찾아보기"를 클릭한다.

그림3. 커뮤니티 AMI 탭에서 검색

 

 커뮤니티 AMI탭에서 'amzn-ami-vpc-nat'로 검색한다. region마다 커뮤니티에 등록되어 있는게 다르다. 서울 region으로 잡았을때는 위와 같이 여러개의 AMI들이 나오는 것을 확인할 수 있다. 이중 게시 날짜를 기준으로 가장 최근에 게시된 AMI를 선택했다.

 

그림4. Nat Instance 생성

 

 해당 AMI를 선택하게 되면 그림4와 같이 해당 AMI에 맞는 CPU아키텍처 (위에서는 x86_64) storage형식 등이 나와 있고 해당 유형 위에서 인스턴스 유형을 선택할 수 있게 된다. 이렇게 해서 EC2를 생성하면 해당 Instance는 외부에서 오는 트래픽을 다른 destination으로 Pass할 수 있게 설정이 되어 있을 것이다. 즉, 해당 인스턴스는 'Nat gateway 역할을 할 수 있게 설정이 되어 있다' 라고 생각하면 된다.

 

* 참고로 SSH접속할때의 usernaem은 위의 그림4에서 처럼 사용자 이름 : ec2-user 이런식으로 표기되어 있음을 확인 가능하다.

 

 EC2를 생성할때 각자 생성한 VPC내의 Public subnet에 위치시켜준다. 이후 public subnet의 routing table은 당연히 internet gateway에 연결해줘야 하며, VPC 내부 local에서는 다 통신이 되게 해줘야 한다. 또한 필요하다면, 보안은 보안그룹 또는 NACL을 설정을 권장한다. (이번 포스팅에서 AWS기본이 되는 것들은 세부적으로 설명하지 못하며, 언급만 하고 넘어가도록 하겠습니다)

 

Public subnet의 routing table 참고만 하세요. (인터넷 게이트웨이와 연결하지 않으면 AWS에서는 외부 통신이 안됩니다)

참고 그림. public subnet의 routing table (참고만 하세요)

 

 

 

 

2. Private subnet Routing Table 설정 및 Nat Instance Console창에서 설정

 

 이후, AWS 콘솔창에서 네트워크 라우팅 테이블 및 인스턴스 설정을 추가적으로 하면 마무리가 된다. 마무리 추가 설정을 해서 private subnet에 있는 ec2랑 인터넷 연결이 되는 것을 확인해 보도록해보자.

 

Private Subnet Routing Table 설정

 기존에 Nat gateway를 사용하더라도 Private subnet과 mapping되어 있는 routing table에서 Nat gateway와 직접 연결해 주었다. Nat Instance또한 해당 작업을 해줘야 한다.

그림5. Private subnet의 routing table 설정

 

 Private subnet: routing table에서 대상을 '인스턴스'로 설정하고 그 아래는 내가 위에서 만든 Nat-instance를 선택한다 (저의 경우 nat-instance라고 명명했습니다) 이 의미는 private subnet에서 인터넷으로 나가는 모든 트래픽이 Nat-instance를 거친다라고 이해해도 무방하다. 

 

 * 참고로 설정을 하고나면 아래와 같이 대상이 eni- 로 시작하게 되는데 이는 Elatic Network Interface로 네트워크 카드 리소스랑 직접적으로 mapping되는 것을 확인할 수 있다. 이는 OS 레벨에서 2계층(데이터 링크 계층)과 3계층(네트워크 계층)을 거쳐 다른 대상으로 트래픽을 전달한다는 점을 유추할 수 있다. (위에서 만든 커뮤니티 AMI에서 이 설정이 되어 있는 것이다)

참고 그림. 네트워크 카드 연결

 

 

Nat Instance EC2 네트워크 설정

 EC2 대시보드에서 본인이 만든 nat-instance를 클릭한 이후 오른쪽 상단의 '작업' tab 하위에 '네트워킹'의 '소스/대상 확인 변경'을 클릭한다. (라우팅 테이블외에도 AWS EC2 인스턴스 자체의 설정을 바꿔줘야 한다)

그림6. nat instance 네트워킹 설정 변경

 

그림7. 소스/대상 확인

 

 그림 7번처럼 소스/대상 확인 부분에서 "중지" 라디오 버튼을 클릭해야 한다. AWS에서는 트래픽이 대상 EC2 인스턴스로 도달하지 않으면 해당 트래픽을 버리는 방식으로 동작하는 것 같다. 즉, 특정 인스턴스를 통해 다른 인스턴스로 트래픽을 우회시키는 설정을 해주는 것이라고 이해하면 된다.

 

 

* 필수 사항 - 일반적으로 기본 보안그룹을 사용하게 되면 SSH만 뚫려 있을 확률이 높다. 최소한 보안에서 는 통신할 수 있게 설정해줘야 한다.

참고 그림. private ec2 security group

 private subnet에 있는 ec2의 보안그룹 설정을 임의로 모든 트래픽을 받아올수 있게 해 놓았다. 해당 부분은 프로젝트 정책에 따라 설정하면 된다. (해당 포스팅 글에서는 보여주기 위해 위와 같이 설정 했다)

 

 또한, 이번 포스팅에서는 Elastic IP를 설정하지 않았지만, EIP를 하지 않아도 Nat Instance의 public ip만 활성화 되어 있으면 임의의 IP가 알아서 붙는다. Dynamic Host Configuration Protocol정책에 의해 ec2를 껐다 키면 public ip가 변하겠지만, 만약 계속 켜 놓을거라면 EIP설정은 하지 않아도 무방하다.

 

Nat Instance 구축 결과

그림8. Nat Instance 연결 전

그림9. Nat Instance 연결 이후

 

 Nat Instance를 연결하기 전에는  sudo apt-get update 를 통해 debian계열이 주로 사용하는 apt저장소 update가 되지 않는 것을 확인할 수 있다. 하지만 연결 이후에는 잘 받아지는 것을 확인 할 수 있다.

 

맺음말

 AWS의 커뮤니티에서 제공하는 NAT 인스턴스 관련 AMI를 사용하면, 별다른 설정 없이 NAT 인스턴스를 구축할 수 있다. 하지만, 해당 AMI는 오래된 OS 버전을 사용하고 있으며 서비스 종료(End of Service)가 된 상태이다. 또한, 패키지를 수동으로 다운로드하려고 할 때 필요한 파일을 찾는 것이 매우 어렵고, 지원되는 사이트도 제한적이다. 따라서 유지 관리가 매우 힘들고, NAT 인스턴스 기능 외의 다른 용도로 사용하기에는 어려움이 많다. (이미 시도해 봄)

 필자는 NAT 인스턴스를 Reverse Proxy 서버로도 활용하고자 하기 때문에 OS 버전 관리가 중요하다. 최소한 HTTPS를 지원할 수 있도록 인증서 관련 패키지가 제공되어야 하는데, 앞서 언급한 AMI는 이를 지원하지 않는 것으로 확인되었다. 따라서, 2부에서는 AWS에서 제공하는 최신 버전의 OS를 기반으로 직접 NAT 인스턴스를 구축하는 방법을 다룰 예정이다.