EC2 관리 접속을 위해 배스천 서버와 SSH 키 운영을 줄이고 싶다면 Session Manager를 검토할 수 있습니다. 단, 에이전트·IAM 권한·AWS 서비스로 나가는 연결이 준비돼야 합니다. 또한 접속 요청을 기록하는 것과 세션의 명령 내용을 기록하는 것은 다릅니다. 특히 SSH와 포트 포워딩 세션의 내용은 Session Manager 세션 로깅 대상으로 볼 수 없습니다.
자료 확인 기준일은 2026년 10월 13일입니다. 아래 예시는 공식 문서를 바탕으로 작성한 설계·점검 예이며, 이 글에서 실제 계정이나 서버에 실행한 시험 결과는 아닙니다.
원인: 연결·권한·감사 기록을 하나의 기능으로 봅니다
배스천을 통한 SSH에서는 배스천과 목적지의 경로, SSH 인증, 운영체제 권한을 구성합니다. Session Manager의 지원되는 관리 세션에서는 관리형 노드의 에이전트와 AWS 권한을 이용하므로 인바운드 SSH 포트를 열거나 배스천을 둘 필요가 없는 접속 방식을 구성할 수 있습니다.
이것이 네트워크 연결이나 서버 권한 검토가 필요 없다는 뜻은 아닙니다. 관리형 노드가 필요한 서비스 엔드포인트로 통신할 수 있어야 하고, 세션을 여는 사용자의 AWS 권한과 세션 안에서 사용하는 운영체제 계정 권한을 각각 확인해야 합니다.
해결 절차 1: 요구하는 접속 경로부터 정합니다
| 비교 지점 | Session Manager | 배스천 기반 SSH |
| 접속 전제 | 관리형 노드·에이전트·IAM·서비스 연결 | 배스천·목적지 경로·SSH 인증 |
| 키와 인바운드 | 지원 세션에 SSH 키·인바운드 SSH가 필수인 것은 아님 | 선택한 SSH 인증과 인바운드 경로를 관리 |
| 운영 책임 | 에이전트·권한·세션 설정을 관리 | 배스천 패치·가용성·키·접속 경로를 관리 |
| 명령 기록 | 지원 셸 세션의 로그 구성을 확인 | 별도 세션 기록 수단의 실제 범위를 확인 |
| 터널 내용 | SSH·포트 포워딩 내용 로깅은 제공되지 않음 | 구성한 감사 도구의 가시성과 한계를 확인 |
요구 사항을 ‘EC2 셸에서 장애 조사’, ‘로컬 도구로 내부 포트 사용’, ‘SSH 기반 기존 도구 유지’로 나누세요. 같은 Session Manager 경로라도 사용하는 세션 종류가 다르면 기록 범위가 달라집니다. ‘관리형 접속을 쓴다’는 이유만으로 감사 요건을 충족했다고 판단하지 않습니다.
해결 절차 2: 에이전트·IAM·네트워크를 확인합니다
- 관리 대상 EC2가 Systems Manager의 관리형 노드로 연결되는지 먼저 확인합니다.
- 해당 기능에 맞는 SSM Agent와 인스턴스 권한이 준비됐는지 공식 전제조건을 대조합니다.
- CLI로 접속한다면 AWS CLI 외에 Session Manager 플러그인 전제도 확인합니다.
- 필요한 AWS 엔드포인트로의 아웃바운드 HTTPS 연결과 이름 해석을 확인합니다. 사설 엔드포인트를 선택하면 그 경로와 정책도 별도로 검토합니다.
- 세션을 시작할 IAM 주체의 대상·작업 범위를 정하고, 허용 사용자와 거부 사용자를 함께 검증합니다.
버전 요구는 세션 기능별로 다를 수 있습니다. 2026년 10월 13일 확인한 전제조건 문서를 기준으로 배포 환경의 에이전트·플러그인 버전을 대조하세요. 최소 버전 설명을 모든 환경에 권장되는 최신 버전으로 해석하지 않습니다.
문서는 기본 생성되는 ssm-user의 관리자 권한도 설명합니다. AWS에서 접속을 허용하는 권한과 운영체제에서 어떤 작업까지 가능한지를 나누어 검토하세요. 기본 동작을 확인하지 않은 채 ‘IAM만 제한하면 셸도 최소 권한’이라고 가정하지 않습니다.
해결 절차 3: 기록할 내용을 먼저 정의합니다
CloudTrail의 API 활동은 누가 어떤 접속 API를 호출했는지 조사하는 데 활용할 수 있습니다. 지원되는 셸 세션의 데이터 기록은 CloudWatch Logs 또는 S3의 설정·권한 등 별도 구성을 확인해야 합니다. API 기록이 곧 모든 명령의 원문 기록은 아닙니다.
SSH와 포트 포워딩 세션의 내용은 Session Manager 로깅에서 기록할 수 없습니다. 명령·SQL·파일 전송 내용까지 요구한다면 실제 사용 경로에서 별도 기록 수단이 어떤 내용을 관찰할 수 있는지 검증해야 합니다. 내용 기록 요구가 해결되지 않았다면 감사 용도로 도입 완료라고 쓰지 않습니다.
다음은 접속 방식 선정 때 작성할 감사 요구 표의 예입니다. 실제 감사 결과나 규정 준수 인증을 뜻하지 않습니다.
| 요구 | 확인할 증거 | 통과 조건 예 |
| 누가 접속을 요청했는가 | API 활동과 사용자 식별 기록 | 대상·시각·주체를 연결할 수 있음 |
| 셸에서 무엇을 했는가 | 지원 셸의 실제 세션 로그 | 설정된 저장소에 필요한 내용이 남음 |
| 터널 안에서 무엇을 했는가 | 앱·목적지의 별도 기록 | 해당 경로의 가시성 한계를 확인 |
| 누가 기록을 볼 수 있는가 | 로그 저장소 접근 권한 | 업무상 필요한 사용자만 조회 가능 |
확인 방법: 접속 성공 외에 거부와 로그도 시험합니다
비운영 EC2에서 승인된 사용자 접속, 권한 없는 사용자 거부, 네트워크 경로 제한 시 실패를 나누어 시험합니다. 세션을 종료한 뒤 요청 기록과 필요한 세션 데이터가 의도한 저장소에 남는지 실제로 조회하세요. SSH·포트 포워딩의 내용 기록이 남을 것이라고 기대하는 시험은 조건부터 다시 정해야 합니다.
운영 전환 전에는 기존 접근 경로와 복구 담당자를 보존하고, 로그가 확인되지 않거나 필요한 도구가 지원되지 않을 때 되돌릴 기준을 정합니다. 인바운드 규칙을 먼저 삭제하거나 여러 권한을 한꺼번에 확대하는 방식으로 문제를 해결하지 않습니다.
주의사항: EC2 범위와 전체 비용을 구분합니다
2026년 10월 13일 확인한 공식 가격표는 Amazon EC2에서의 Session Manager 사용에 추가 사용 요금이 없다고 설명합니다. 그렇다고 선택한 구성 전체가 비용 없이 운영된다는 뜻은 아닙니다. 로그 저장, 사설 연결 경로 등 연결한 서비스와 운영 비용은 별도로 검토합니다.
이 글의 비교 대상은 EC2입니다. 하이브리드·다른 클라우드 노드의 조건을 EC2와 같다고 적용하지 말고 공식 가격표의 해당 범위를 확인하세요. 실제 단가·원화 견적·절감률을 제시하지 않으며 준비일의 문서 내용을 다음 날 확정 요금으로 표현하지 않습니다.
세션 로그에는 업무 데이터나 비밀 값이 들어갈 수 있습니다. 기록 범위·열람 권한·보존 요구를 먼저 정하고, 자격 증명을 입력 예나 공개 로그에 남기지 않습니다.
FAQ
SSH 포트를 닫아도 접속할 수 있나요? 지원되는 Session Manager 접속의 전제조건이 갖춰져 있다면 인바운드 SSH가 필요한 방식은 아닙니다. 에이전트와 서비스 연결을 먼저 확인하세요.
모든 명령을 자동으로 기록하나요? 세션 종류와 로그 구성을 확인해야 합니다. SSH·포트 포워딩 내용은 해당 세션 로깅으로 기록되지 않습니다.
배스천을 바로 제거해도 되나요? 필요한 도구·권한·로그·복구 경로를 먼저 시험하고 운영 전환 절차에 따라 판단하세요.
공식 출처와 관련 글
함께 읽기: Tailscale와 Tunnel·Access의 내부 접속 경로 비교
'소프트웨어개발' 카테고리의 다른 글
| EventBridge Scheduler와 서버 cron 비교: 예약 작업 재시도·중복 실행·운영 비용 선택 (0) | 2026.10.14 |
|---|---|
| GitHub Actions SSH Permission denied (publickey) 해결: 배포 서버와 저장소 인증 구분 (0) | 2026.10.12 |
| Docker port is already allocated 해결: Compose 호스트 포트 충돌 점검 (0) | 2026.10.12 |
