Bastion Host를 대체하는 AWS Systems Manager Session Manager

클라우드 환경에서 EC2 인스턴스에 접속하기 위해 오랫동안 사용되던 방식은 Bastion Host였습니다.

관리자는 Bastion Host에 먼저 SSH로 접속한 뒤, 내부 Private Subnet에 있는 서버로 다시 접속했습니다. 이 구조는 단순하고 익숙하지만, 운영 규모가 커질수록 관리 부담과 보안 위험이 함께 증가합니다.

 

최근 AWS 환경에서는 Bastion Host를 줄이거나 제거하고, AWS Systems Manager의 Session Manager를 이용해 EC2에 접속하는 방식이 많이 사용됩니다.

Bastion Host 방식의 한계

Bastion Host는 외부에서 내부 서버로 들어가기 위한 관문 역할을 합니다. 하지만 이 구조에는 몇 가지 문제가 있습니다.

 

첫째, Bastion Host 자체가 공격 표면이 됩니다.

외부 접속을 위해 SSH 22번 포트나 RDP 3389번 포트를 열어야 하고, 이 서버가 침해되면 내부망 접근 경로가 노출될 수 있습니다.

 

둘째, SSH Key 관리가 필요합니다.
사용자별 키 발급, 회수, 분실 대응, 퇴사자 키 제거 같은 관리 업무가 계속 발생합니다.

 

셋째, 접속 이력 추적이 어렵습니다.
누가 언제 어떤 서버에 접속했는지는 일부 확인할 수 있지만, 명령어 수준의 감사 로그를 일관되게 남기려면 별도 구성이 필요합니다.

 

넷째, 운영 비용과 관리 부담이 생깁니다.
Bastion Host도 결국 EC2 인스턴스이기 때문에 패치, 보안 설정, 모니터링, 장애 대응이 필요합니다.

 

Session Manager란?

AWS Systems Manager Session Manager는 EC2 인스턴스에 SSH Key 없이 접속할 수 있게 해주는 관리형 접속 기능입니다.

사용자는 AWS Console, AWS CLI 또는 SDK를 통해 Session Manager 세션을 시작합니다. 인스턴스에는 SSM Agent가 설치되어 있어야 하며, 인스턴스는 AWS Systems Manager 엔드포인트와 통신할 수 있어야 합니다.

 

접속 흐름은 다음과 같습니다.

사용자
  ↓
AWS IAM / AWS SSO 인증
  ↓
AWS Systems Manager Session Manager
  ↓
SSM Agent
  ↓
Private EC2 Instance

 

핵심은 사용자가 EC2로 직접 SSH 접속하지 않는다는 점입니다.
즉, EC2 보안 그룹에서 22번 포트를 열 필요가 없습니다.

Session Manager가 Bastion을 대체하는 이유

Session Manager를 사용하면 Bastion Host 없이도 Private Subnet의 EC2에 접속할 수 있습니다.

기존 Bastion 구조는 다음과 같습니다.

관리자 PC
  ↓ SSH
Bastion Host - Public Subnet
  ↓ SSH
Private EC2 - Private Subnet

 

Session Manager 구조는 다음과 같습니다.

관리자 PC
  ↓ AWS 인증
Session Manager
  ↓ SSM Agent
Private EC2 - Private Subnet

 

이 방식에서는 Public Subnet에 Bastion Host를 둘 필요가 없습니다.
Private EC2에 Public IP를 부여하지 않아도 되고, SSH 22번 포트를 열지 않아도 됩니다.

결국 접속 보안의 중심이 네트워크 기반 접근 제어에서 IAM 기반 접근 제어로 이동합니다.

보안 관점의 장점

1. Inbound 포트를 닫을 수 있다

Session Manager를 사용하면 EC2 인스턴스에 SSH 22번이나 RDP 3389번을 열지 않아도 됩니다.

보안 그룹 예시는 다음과 같이 단순해질 수 있습니다.

Inbound:
  없음

Outbound:
  HTTPS 443 허용

 

물론 애플리케이션 서버라면 ALB, NLB, 내부 서비스 통신 등에 필요한 포트는 별도로 허용해야 합니다.
하지만 운영자 접속을 위한 SSH 포트는 제거할 수 있습니다.

2. SSH Key 관리가 줄어든다

Session Manager 기본 접속은 SSH Key를 사용하지 않습니다.
접속 권한은 IAM 정책으로 제어합니다.

 

예를 들어 운영팀 A는 개발 서버만 접속 가능하게 하고, 보안팀은 운영 서버에 읽기 목적의 접속만 허용하는 식으로 제어할 수 있습니다.

권한 회수도 SSH Key 삭제가 아니라 IAM 권한 제거로 처리할 수 있습니다.

3. CloudTrail 기반 감사가 가능하다

Session Manager 접속은 AWS API 호출로 기록됩니다.

누가, 언제, 어떤 인스턴스에 세션을 시작했는지 CloudTrail에서 확인할 수 있습니다.

또한 설정에 따라 세션 로그를 S3나 CloudWatch Logs로 저장할 수 있습니다.

운영 환경에서는 다음과 같은 감사 체계를 구성하는 것이 좋습니다.

Session Manager 접속
  → CloudTrail 기록
  → CloudWatch Logs 또는 S3 저장
  → EventBridge로 접속 이벤트 탐지
  → SNS 또는 Slack 알림

4. Private Subnet 중심 구조에 적합하다

Session Manager는 Private Subnet의 EC2에도 적합합니다.

인스턴스가 인터넷으로 직접 나갈 필요 없이, VPC Endpoint를 구성하면 AWS PrivateLink를 통해 Systems Manager와 통신할 수 있습니다.

 

Private Subnet에서 Session Manager를 안정적으로 사용하려면 보통 다음 VPC Endpoint를 구성합니다.

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

 

CloudWatch Logs나 S3로 세션 로그를 저장한다면 관련 엔드포인트도 함께 검토해야 합니다.

구성에 필요한 요소

Session Manager를 사용하려면 크게 네 가지가 필요합니다.

1. EC2 IAM Role

EC2 인스턴스에는 Systems Manager와 통신할 수 있는 IAM Role이 필요합니다.
일반적으로 AWS 관리형 정책인 AmazonSSMManagedInstanceCore를 연결합니다.

예시 정책 연결 구조는 다음과 같습니다.

EC2 Instance
  → IAM Role
    → AmazonSSMManagedInstanceCore

2. SSM Agent

EC2 내부에는 SSM Agent가 설치되어 있어야 합니다.

Amazon Linux 2, Amazon Linux 2023, Ubuntu 일부 AMI, Windows Server AMI에는 기본 설치되어 있는 경우가 많습니다.
다만 운영 환경에서는 SSM Agent 버전을 최신으로 유지하는 것이 좋습니다.

확인 명령은 다음과 같습니다.

sudo systemctl status amazon-ssm-agent

실행 중이 아니라면 다음과 같이 시작할 수 있습니다.

sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

3. 네트워크 경로

인스턴스는 Systems Manager 엔드포인트와 HTTPS 443으로 통신할 수 있어야 합니다.

인터넷 경로가 있는 경우에는 NAT Gateway를 통해 통신할 수 있습니다.
인터넷 경로를 제거하고 싶다면 VPC Endpoint를 구성합니다.

보안이 중요한 운영 환경에서는 NAT Gateway보다 VPC Endpoint 기반 구성이 더 깔끔합니다.

4. 사용자 IAM 권한

사용자는 Session Manager 세션을 시작할 권한이 있어야 합니다.

예시 권한은 다음과 같습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:StartSession",
        "ssm:TerminateSession",
        "ssm:ResumeSession"
      ],
      "Resource": [
        "arn:aws:ec2:ap-northeast-2:123456789012:instance/i-xxxxxxxxxxxxxxxxx",
        "arn:aws:ssm:ap-northeast-2:123456789012:document/SSM-SessionManagerRunShell"
      ]
    }
  ]
}

운영 환경에서는 인스턴스 태그 기반으로 제어하는 것이 좋습니다.

예를 들어 Environment=Dev 인스턴스만 개발자가 접속하게 하거나, Environment=Prod 인스턴스는 운영자 그룹만 접속하게 만들 수 있습니다.

접속 방법

AWS CLI에서 Session Manager로 접속하는 기본 명령은 다음과 같습니다.

aws ssm start-session \
  --target i-xxxxxxxxxxxxxxxxx

접속되면 일반적인 쉘처럼 명령을 실행할 수 있습니다.

whoami
hostname
ip addr

EC2 콘솔에서도 인스턴스를 선택한 뒤 Connect 메뉴에서 Session Manager를 선택해 접속할 수 있습니다.

SSH처럼 사용해야 할 때

기본적으로 Session Manager는 SSH 없이 접속하는 방식입니다.

하지만 기존 도구가 SSH 기반으로 동작하는 경우도 있습니다.
예를 들어 SCP, rsync, Ansible, IDE Remote SSH 같은 도구는 SSH 프로토콜을 요구할 수 있습니다.

이 경우 Session Manager를 SSH 터널처럼 사용할 수 있습니다.

로컬 SSH 설정 예시는 다음과 같습니다.

Host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

이후 다음처럼 접속할 수 있습니다.

ssh ec2-user@i-xxxxxxxxxxxxxxxxx

다만 이 방식은 Session Manager가 SSH 트래픽을 터널링하는 구조이므로, 명령어 수준의 세션 로깅에는 제한이 있습니다.
감사 로그가 중요한 운영 환경에서는 기본 Session Manager 쉘 접속과 로깅 구성을 우선 검토하는 것이 좋습니다.

Port Forwarding 활용

Session Manager는 포트 포워딩도 지원합니다.

예를 들어 Private Subnet에 있는 EC2의 8080 포트를 로컬 PC의 8080 포트로 연결할 수 있습니다.

aws ssm start-session \
  --target i-xxxxxxxxxxxxxxxxx \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["8080"],"localPortNumber":["8080"]}'

이후 로컬 브라우저에서 다음 주소로 접근할 수 있습니다.

http://localhost:8080

이 방식은 내부 관리 페이지, 임시 디버깅, Private RDS 접근, 내부 API 점검 등에 유용합니다.

Bastion과 Session Manager 비교

구분	Bastion Host	Session Manager
접속 방식	SSH/RDP 직접 접속	AWS API 기반 세션
Public IP	보통 필요	불필요
Inbound 포트	22/3389 필요	불필요
SSH Key 관리	필요	기본 접속은 불필요
접근 제어	보안 그룹, 키, OS 계정	IAM 정책
감사 로그	별도 구성 필요	CloudTrail, S3, CloudWatch Logs 연동
운영 부담	EC2 패치/운영 필요	관리형 서비스 중심
Private Subnet 접속	Bastion 경유	직접 가능
비용	Bastion EC2 비용 발생	기본 사용 비용은 낮음, 로그/VPC Endpoint 비용 별도 고려

운영 환경 권장 구성

운영 환경에서는 다음 구성을 권장합니다.

1. EC2는 Private Subnet에 배치
2. EC2에는 Public IP 미부여
3. 보안 그룹에서 SSH/RDP Inbound 제거
4. EC2 IAM Role에 AmazonSSMManagedInstanceCore 연결
5. SSM Agent 최신 버전 유지
6. VPC Endpoint 구성
   - ssm
   - ssmmessages
   - ec2messages
7. Session Manager 로그를 CloudWatch Logs 또는 S3에 저장
8. CloudTrail로 StartSession, TerminateSession 이벤트 추적
9. IAM Identity Center 또는 IAM Role 기반으로 사용자 접근 제어
10. 운영 서버 접속은 태그 기반 IAM 정책으로 제한

주의할 점

Session Manager가 Bastion Host를 완전히 대체할 수 있는 경우가 많지만, 무조건 모든 상황에서 Bastion이 필요 없다는 뜻은 아닙니다.

예를 들어 매우 특수한 네트워크 장비 접근, 레거시 SSH 기반 자동화, 강한 네트워크 분리 정책이 있는 환경에서는 별도 접속 구조가 필요할 수 있습니다.

또한 Session Manager를 도입하더라도 IAM 권한을 넓게 주면 위험합니다.

다음과 같은 정책은 피하는 것이 좋습니다.

{
  "Effect": "Allow",
  "Action": "ssm:StartSession",
  "Resource": "*"
}

운영 환경에서는 최소 권한 원칙에 따라 특정 인스턴스, 특정 태그, 특정 SSM Document만 허용하는 방식으로 제한해야 합니다.

결론

AWS Systems Manager Session Manager는 Bastion Host를 대체하기에 매우 적합한 기능입니다.

가장 큰 장점은 운영자 접속을 위해 EC2에 SSH 포트를 열지 않아도 된다는 점입니다.
또한 SSH Key 관리 부담을 줄이고, IAM 기반으로 접근 권한을 중앙에서 통제할 수 있습니다.

 

기존 Bastion Host 방식이 “네트워크에 문을 하나 열고 관리하는 방식”이었다면, Session Manager는 “AWS 인증과 권한을 통해 필요한 시점에만 세션을 여는 방식”에 가깝습니다.

 

따라서 AWS 운영 환경에서는 신규 시스템부터 Bastion Host를 기본값으로 두기보다, Session Manager 기반 접속 구조를 우선 검토하는 것이 좋습니다.