📌 작성하는 이유
AWS 인프라를 이용하면서 사내에서 빈번하게 일어날 수 있는 상황에 대해서 정리하고자 합니다.
특히 Bastion Host를 통한 연결 시 Public IP 와 Private IP 혼용으로 인하여 업무 진행에 제한을 받는 경우가 종종 발생합니다.
각각의 시나리오를 통해 어떤 상황에서는 연결이 되지만, 왜 이상황에서는 연결이 안되지? 에 대한 답변을 유추할 수 있습니다.
⚡ 서버 개발 및 운영시 적절한 엔드포인트를 이용하여 보다 효율적으로 서버를 운영할 수 있습니다.
예시의 편의성을 위해 아래 조건으로 가정합니다.
- Bastion Host를 통해 Private Subnet에 배치된 Database에 접속
- Bastion의 보안그룹은 On-premise의 IP와 내부 VPC 영역에 대해서 모든 트래픽을 허용
- (예시) Allow 10.0.0.0/16
- (예시) Allow 58.32.15.6/32
📌 보안
✅ On-Premise to Bastion Public IP
On-Premise에 배치되어 있는 서버에서 Bastion의 외부 IP를 이용하여 접속을 시도하는 경우입니다.
트래픽은 On-premise(오피스)의 할당된 58.32.15.6(예시)의 IP를 가지며, Bastion의 외부 IP로 전달됩니다.
📋 SG에서 58.32.15.6/32 IP에 대해서 Inbound 허용했으므로, 요청은 정상적으로 Bastion으로 전달됩니다.
✅ (Allow)Public EC2 to Bastion Private IP
Public subnet의 EC2 인스턴스에서 Bastion의 내부 IP를 이용하여 접속을 시도하는 경우입니다.
Route Table에 명시된 규칙에 따라 bastion의 내부 IP로 요청이 전달되므로, managed server의 내부 ip를 사용하게 됩니다.
📋 SG에서 VPC의 IP 영역(10.0.0.0/16)에 대해서 Inbound 허용했으므로, 요청은 정상적으로 Bastion으로 전달됩니다.
⛔ (Deny)Public EC2 to Bastion Public IP
Public subnet의 EC2 인스턴스에서 Bastion의 외부 IP를 이용하여 접속을 시도하는 경우입니다.
Route Table에 명시된 규칙에 따라 Bastion의 외부 IP는 10.0.0.0/16에 매칭되는 IP가 아니므로, 인터넷 게이트웨이를 통해 전달됩니다. 이 경우, Client IP가 managed server의 Public IP가 됩니다.
📋 SG에서 managed server의 Public IP에 대해서 허용하지 않았으므로 요청은 Deny가 되어 DB를 연결할 수 없습니다.
✅ (Allow)Private EC2 to Bastion Private IP
Private subnet의 EC2 인스턴스에서 Bastion의 내부 IP를 이용하여 접속을 시도하는 경우입니다.
Route Table에 명시된 규칙에 따라 bastion의 내부 IP로 요청이 전달되므로, managed server의 내부 ip를 사용하게 됩니다.
📋 SG에서 VPC의 IP 영역에 대해서 Inbound 허용했으므로, 요청은 정상적으로 Bastion으로 전달됩니다.
⛔ (Deny)Private EC2 to Bastion Public IP
Private subnet의 EC2 인스턴스에서 Bastion의 외부 IP를 이용하여 접속을 시도하는 경우입니다.
Route Table에 명시된 규칙에 따라 Bastion의 외부 IP는 10.0.0.0/16에 매칭되는 IP가 아니므로, 인터넷 게이트웨이를 통해 전달됩니다. 이 경우, Client IP가 NAT Gateway의 EIP가 됩니다.
📋 SG에서 NAT Gateway의 EIP에 대해서 허용하지 않았으므로 요청은 Deny가 되어 DB를 연결할 수 없습니다.
📌 Cost
NAT Gateway, VPN 연결 또는 AWS Direct Connect와 같은 추가적인 비용이 드는 서비스를 사용하지 않아도 됩니다. 또한, 인터넷망을 사용하지 않기 떄문에 인터넷 연결 비용을 절감할 수 있습니다.
VPC Endpoint를 생성하는 데에는 추가적인 비용이 발생하지 않지만, 사용하는 AWS 서비스, 데이터 전송량, 지역에 따라 추가적인 비용이 발생할 수 있습니다.
👉 NAT 게이트웨이 요금
VPC에 NAT 게이트웨이를 생성하는 경우 게이트웨이를 프로비저닝하고 사용하는 각 ‘NAT 게이트웨이 시간’에 대한 요금이 부과됩니다.
데이터 처리 요금은 트래픽 소스나 대상과 관계없이 NAT 게이트웨이를 통해 처리된 각 기가바이트에 적용됩니다.
1시간 미만의 각 NAT 게이트웨이 사용 시간은 1시간으로 청구됩니다. 또한 NAT 게이트웨이를 통해 전송된 모든
데이터에 대한 표준 AWS 데이터 전송 요금도 발생합니다.
NAT 게이트웨이에 대한 요금이 청구되지 않도록 하려면 AWS 관리 콘솔, 명령줄 인터페이스 또는 API를 사용하여 NAT 게이트웨이를 삭제하면 됩니다.
도쿄 리전 기준
NAT 게이트웨이당 요금(USD/시간) 처리된 데이터 GB당 요금(USD) 0.062 USD 0.062 USD
📌 성능
데이터 전송 속도가 빨라지고 대기 시간이 줄어드는 이점이 있습니다.
VPC Endpoint가 VPC 내의 인스턴스에서 AWS 서비스로 직접 액세스 할 수 있도록 하여 VPC 외부가 아닌 내부에서 처리됩니다.
AWS 서비스마다 차이가 있지만 대부분 매우 높은 성능을 제공합니다.
예를 들어, S3 VPC Endpoint를 사용하여 S3 버킷에 액세스 할 때, VPC 내부로 전송되어 인터넷 트래픽으로 인한 지연시간이 사라지므로 대기 시간이 거의 0ms, 데이터 전송속도 최대 5Gbps로 측정됩니다.
대기시간은 VPC Endpoint가 생성되는 과정의 지연, S3 API 호출 및 객체 다운로드 등의 작업으로 인해 약간 지연될 수 있습니다.
📌 결론
VPN으로 연결이 되어있지 않고 Pubilc Subnet에 배치된 Bastion Host를 통해 외부에서 AWS 서비스를 이용하는 경우 쉽게 혼동할 수 있는 케이스를 정리해 보았습니다.
개발시 오피스와 같이 외부에서 DB서버 또는 AWS 리소스를 이용할 경우에는 공개된 Bastion의 Public IP를 사용하고, 보안그룹을 통해 접근권한을 제어합니다.
이 경우를 제외하면, AWS 내부에서는 Private IP를 사용하여 서비스를 운영합니다.
보안, 비용, 성능에 대한 이점을 모두 가져갈 수 있습니다.
📌 Reference
