본 실습 과정은 AWS Training and Certification을 바탕으로 작성되었습니다.
애플리케이션의 실제 서버 역할을 하는 AppServer
라는 인스턴스가 있고, 이는 private 서브넷에 위치하여 인터넷에서 직접적으로 접근할 수 없다.
🧐 그렇다면 어떻게 접근 할 수 있을까?
그림에 답이 나와있다.
ProxyServer
와PublicServer
라는 중간 인스턴스를 연결해서 사용한다.
ProxyServer
와 PublicServer
는 동일한 가상 사설 클라우드(VPC)의 public 서브넷에 위치하도록 하여 인터넷(외부)와의 연결이 가능하도록 한다.
이후 들어오는 요청에 대해서 이러한 프록시 서버는 들어오는 웹 요청을 AppServer
인스턴스로 전달한다.
이처럼 프록시 서버 모델을 구현하는 것은 프라이빗 서브넷 리소스에 원격으로 액세스하기 위한 일반적인 네트워크 보안 구성이다.
보안 그룹은 기본적으로 stateful 즉, 상태를 저장한다. AWS 공식 문서
즉, 요청이 허용된 경우, 해당 요청에 대한 응답 트래픽도 허용된다.
자세한 내용은 [AWS] 보안그룹과 ACL을 참고하라.
각 인스턴스마다 고유의 보안그룹이 현재 존재하며, 세 보안그룹 모두 모든 IP와 포트에 대해서 전부(Anywhere) 트래픽이 허용되어 있는 것을 확인할 수 있다.
따라서 ProxyServerUrl
과 PublicServerUrl
어디를 통하든 AppServer로 접속할 수 있었다.
이제, AppServer
쪽의 보안 인바운드 트래픽을 전체 허용에서 ProxyServer
의 트래픽만 받도록 변경해보자.
전체 허용을 뜻하는 0.0.0.0에서 ProxyServer
의 내부 IP 주소(10.0.1.131)로 변경해 주었다.
이제 AppServer
는 10.0.1.131에서 오는 트래픽만을 허용하게 된다.
따라서, PublicServerUrl
로 접근해보면, 접근이 되지 않는 것을 확인할 수 있다.
이제 이 사용이 불가능해진 PublicServer
를 다시 사용 가능하도록 해보자.
어떻게 해야할까?
AppServer
의 보안 그룹에 PublicServer
의 내부IP 주소 또한 추가하면 될까?
물론, 그것도 하나의 방법이 될 수 있지만 일반적으로 보안 그룹 규칙에 고정 IP 주소를 설정하는 것은 그닥 효율적인 방법이 아니다.
인스턴스가 계속 생긴다면, 계속해서 인바운드에 추가해 주어야 할테니 말이다.
또한, 직접적으로 IP주소를 쓰는 것이므로 보안적인 측면에서도 문제가 생길 수 있다.
여러 호스트에 대해 동일한 액세스 권한을 배포하는 가장 간단하고 안전한 방법은 개별 IP 주소가 아닌 보안 그룹 이름을 인바운드 소스로 사용하는 것이다.
정답(최선의 방법)은 다음과 같다.
PublicServer
의 기존PublicServer
보안 그룹을 사용하지 않고,ProxyServer
보안 그룹을 사용한다.
PublicServer
의 Security Groups에 들어간 다음
이처럼 PublicServer
의 기존 PublicServer
보안 그룹을 사용하지 않고, ProxyServer
보안 그룹을 사용하도록 한다.
이제 마지막 과정만 남았다.
ProxyServer
보안 그룹을 사용하도록 하였으므로, 이 보안 그룹을 AppServer
의 보안 그룹의 인바운드 소스로 사용하도록 지정만 해주면 끝난다.
잘 접속되는 것을 확인할 수 있다.