Bastion Host 없이 EC2에 접속하기: AWS Session Manager와 EC2 Instance Connect Endpoint

AWS에서 Private Subnet의 EC2에 접속할 때 예전에는 Bastion Host, Jump Server를 두는 구성이 일반적이었다. 관리자는 먼저 Public Subnet의 Bastion EC2에 SSH/RDP로 접속하고, 그다음 Private Subnet의 서버로 다시 접속했다. 하지만 최근 AWS 환경에서는 단순 관리 접속을 위해 Bastion Host를 별도로 운영하기보다, AWS Systems Manager Session Manager나 EC2 Instance Connect Endpoint를 사용하는 방식이 더 선호된다. AWS 공식 문서에서도 Session Manager는 인바운드 포트 오픈, Bastion Host 유지, SSH 키 관리 없이 EC2 같은 관리 대상 노드에 접근할 수 있다고 설명한다. (AWS Documentation)

 

왜 Bastion Host를 줄이려는가?

Bastion Host는 Private Subnet에 있는 서버로 들어가기 위한 관문 역할을 한다. 구조 자체는 단순하고 익숙하지만, 결국 인터넷에서 접근 가능한 EC2 한 대를 추가로 운영하는 방식이다. 이 서버는 보안 패치, 접근 제어, SSH 키 관리, 로그 수집, 장애 대응, 비용 관리 대상이 된다.

 

전통적인 구조는 다음과 같다.

관리자 PC
  -> Public Subnet Bastion Host
      -> Private Subnet EC2

 

문제는 Bastion Host가 뚫리면 내부 서버로 가는 경로가 열릴 수 있다는 점이다. 그래서 보안그룹으로 회사 IP만 허용하거나 MFA, 접근 승인, 세션 기록 등을 붙이지만, 운영 부담은 계속 남는다.

 

AWS 블로그에서도 Bastion Host를 Systems Manager로 대체하면 공격 표면을 줄이고, 호스트에서 실행된 명령에 대한 가시성을 높일 수 있다고 설명한다. (Amazon Web Services, Inc.) 2024년 AWS 블로그에서도 Bastion Host 방식은 배포, 하드닝, 유지관리, 모니터링 부담과 EC2 실행 비용이 있으며, Session Manager를 사용하는 방식은 보안·감사 태세 개선과 관리 부담 감소에 도움이 된다고 설명한다. (Amazon Web Services, Inc.)

 

핵심 대안 1: AWS Systems Manager Session Manager

Session Manager는 AWS Systems Manager의 기능 중 하나로, EC2에 직접 SSH 포트를 열지 않고도 콘솔이나 AWS CLI를 통해 서버 셸에 접속할 수 있게 해준다. AWS 문서 기준으로 Session Manager는 브라우저 기반 셸과 AWS CLI 접속을 지원하며, IAM 정책을 통해 어떤 사용자가 어떤 인스턴스에 접속할 수 있는지 제어할 수 있다. (AWS Documentation)

구조는 다음과 같다.

관리자 PC
  -> AWS Systems Manager Session Manager
      -> SSM Agent
          -> Private EC2

 

이 방식의 핵심은 EC2로 인바운드 SSH를 여는 것이 아니라, EC2 내부의 SSM Agent가 AWS Systems Manager 서비스와 통신한다는 점이다. 따라서 보안그룹에서 22번 SSH나 3389번 RDP를 인터넷에 열 필요가 없다.

Session Manager를 사용하려면 보통 다음 조건이 필요하다.

구성 요소	설명
SSM Agent	EC2 내부에서 Systems Manager와 통신하는 에이전트
IAM Role	EC2가 Systems Manager와 통신할 수 있는 권한
네트워크 경로	EC2에서 Systems Manager 엔드포인트로 HTTPS 443 통신 가능
사용자 IAM 권한	관리자가 Session Manager 세션을 시작할 수 있는 권한

 

EC2 인스턴스에는 일반적으로 AmazonSSMManagedInstanceCore 정책이 포함된 IAM Role을 붙인다. AWS 문서에서도 개별 인스턴스 프로파일을 구성할 때 이 정책을 선택하는 절차를 안내한다. (AWS Documentation)

aws ssm start-session \
  --target i-xxxxxxxxxxxxxxxxx \
  --region us-east-1 \
  --profile my-sso

 

Private Subnet에서 NAT Gateway 없이 완전히 폐쇄적인 구조를 만들고 싶다면 VPC Endpoint를 사용한다. Systems Manager용 VPC Endpoint를 구성하면 관리 대상 인스턴스가 인터넷 게이트웨이, NAT 장치 없이도 AWS PrivateLink를 통해 Systems Manager와 통신할 수 있다. AWS 문서에서도 PrivateLink 사용 시 관리 인스턴스와 Systems Manager, EC2 간 트래픽이 Amazon 네트워크 안에서 처리되며, 인터넷 접근이 필요 없다고 설명한다. (AWS Documentation)

 

대표적으로 필요한 엔드포인트는 다음과 같다.

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages

 

AWS 문서 기준으로 관리 대상 노드는 ssm, ssmmessages, ec2messages 엔드포인트로 HTTPS 443 아웃바운드 통신이 가능해야 하며, VPC Endpoint를 쓰는 경우 ssmmessages 엔드포인트는 Session Manager의 보안 데이터 채널 통신에 필요하다. (AWS Documentation) (AWS Documentation)

 

핵심 대안 2: EC2 Instance Connect Endpoint

Session Manager가 “SSH 없이 접속하는 방식”에 가깝다면, EC2 Instance Connect Endpoint는 “Bastion 없이 SSH/RDP 사용성을 유지하는 방식”에 가깝다.

 

EC2 Instance Connect Endpoint는 인터넷에서 Private IP 인스턴스에 안전하게 접속할 수 있게 해주며, Bastion Host나 VPC의 직접적인 인터넷 연결이 없어도 사용할 수 있다. AWS 문서에서는 이 기능을 “identity-aware TCP proxy”로 설명하며, IAM 자격 증명으로 사용자 PC에서 엔드포인트까지 private tunnel을 만들고, 트래픽이 VPC에 도달하기 전에 인증·인가된다고 설명한다. (AWS Documentation)

 

구조는 다음과 같다.

관리자 PC
  -> EC2 Instance Connect Endpoint
      -> Private EC2

 

이 방식은 기존 SSH 클라이언트, SSH 키, 운영 도구를 유지해야 하는 조직에 적합하다. 다만 EC2 Instance Connect Endpoint는 관리 트래픽 용도이며 대용량 데이터 전송용이 아니다. AWS 문서에서도 고용량 데이터 전송은 제한될 수 있고, 엔드포인트당 동시 연결 수와 연결 지속 시간 제한이 있다고 안내한다. (AWS Documentation)

 

Bastion Host, Session Manager, EC2 Instance Connect Endpoint 비교

항목	Bastion Host	Session
Public IP 필요	Bastion에 필요	불필요	대상 EC2에는 불필요
SSH 22번 오픈	Bastion에 필요	불필요	대상 보안그룹에서 엔드포인트 경로 허용
SSH 키 관리	필요	기본 접속은 불필요	사용 방식에 따라 필요
접근 제어	OS 계정, SSH 키, SG 중심	IAM 중심	IAM + 네트워크 제어
운영 부담	높음	낮음	중간
사용성	익숙함	콘솔/CLI 기반	기존 SSH 방식과 유사
추천 상황	레거시, 특수 환경	일반적인 운영 접속	SSH 사용성 유지 필요

실무 기준 추천

일반적인 EC2 운영 접속이라면 Session Manager를 우선 검토하는 것이 좋다. 보안그룹에서 SSH/RDP 인바운드를 제거할 수 있고, IAM 기반으로 접근 제어를 통합할 수 있기 때문이다. AWS 문서도 Session Manager의 장점으로 중앙화된 IAM 접근 제어, 인바운드 포트 제거, Bastion Host와 SSH 키 관리 불필요, 콘솔/CLI 원클릭 접근, 세션 활동 로깅 등을 설명한다. (AWS Documentation)

 

다만 모든 상황에서 Session Manager가 정답은 아니다. 기존 운영 자동화가 SSH 기반으로 강하게 묶여 있거나, scp, SSH 터널, 기존 관리 도구와의 호환성이 중요하다면 EC2 Instance Connect Endpoint가 더 자연스러울 수 있다. AWS 문서에서도 Session Manager를 통한 SSH 연결과 SCP 사용이 가능하지만, SSH나 포트 포워딩 방식의 세션은 SSH가 데이터를 암호화하기 때문에 Session Manager가 세션 내용을 로깅할 수 없다는 제한이 있다. (AWS Documentation)

 

결론

AWS에서 Bastion Host는 여전히 사용할 수 있다. 하지만 단순히 Private EC2에 접속하기 위한 용도라면, 이제는 Bastion Host를 새로 만드는 것보다 Session Manager나 EC2 Instance Connect Endpoint를 먼저 검토하는 것이 더 현대적인 설계다.

 

특히 운영 접속, 보안 감사, 키 관리 최소화, Private Subnet 중심 설계를 고려한다면 Session Manager가 가장 깔끔하다. 반대로 기존 SSH 사용성을 유지하면서 Bastion EC2만 제거하고 싶다면 EC2 Instance Connect Endpoint가 좋은 대안이다.

 

한 문장으로 정리하면 다음과 같다.

과거에는 Private EC2 접속을 위해 Bastion Host를 두는 구성이 일반적이었지만,
최근 AWS 환경에서는 Session Manager나 EC2 Instance Connect Endpoint를 사용해
Bastion Host 없이 접근하는 방식이 더 선호된다.