프라이빗 EC2에 SSH 없이 접속하는 법 — NAT Gateway 끊고 SSM으로 바꾼 이유

 

NAT Gateway 요금 청구서를 처음 봤을 때 잠깐 멈췄다. 실습 환경인데 한 달에 생각보다 많이 나왔다. 강사님이 수업 때마다 "NAT Gateway는 켜두면 돈이 나간다"고 하셨는데, 직접 보고 나서야 그 말이 실감났다.

그러다 강사님이 SSM(AWS Systems Manager Session Manager)을 소개해주셨다. 처음엔 그냥 또 다른 접속 도구인 줄 알았다. 근데 구조를 이해하고 나서 생각이 바뀌었다. 단순히 SSH 대체가 아니라, 설계 자체가 달라지는 이야기였다.

---

기존 구조의 문제 — 배스천 호스트와 NAT Gateway

AWS 실습 초반에 만든 구조는 이랬다.

인터넷
  ↓
퍼블릭 서브넷
  └── 배스천 EC2 (공인 IP, 22포트 개방)
        ↓ SSH 터널
프라이빗 서브넷
  └── 웹서버 EC2 (공인 IP 없음)
  └── RDS (공인 IP 없음)

프라이빗 EC2 → NAT Gateway → 인터넷 (패키지 설치용)

이 구조에서 문제가 세 가지 있었다.

첫 번째, 배스천 호스트 22포트 노출 문제

Security Group에서 내 IP만 허용하면 되지 않나 싶지만, 현업에서는 IP가 고정이 아닌 경우가 많다. 재택근무나 여러 거점에서 접속하는 환경에서는 IP 관리가 복잡해진다. 결국 0.0.0.0/0으로 열어두거나, IP 변경할 때마다 Security Group을 수정해야 하는 상황이 생긴다.

"22포트가 인터넷에 열려있으면 하루에도 수천 번 브루트포스 시도가 들어온다. CloudTrail 로그 보면 확인된다. 키 페어로 막혀있으니까 뚫리진 않는데, 그 자체가 공격 표면이다."

두 번째, 키 페어 관리 문제

프라이빗 EC2에 접속하려면 배스천에 키 페어를 올려야 하거나, 에이전트 포워딩을 써야 한다. 키 파일이 배스천 서버에 올라가는 순간 그 서버가 탈취되면 내부 서버 접근 권한까지 같이 날아간다.

세 번째, NAT Gateway 비용

프라이빗 EC2에서 패키지 설치할 때 인터넷이 필요하다. NAT Gateway를 켜두면 사용 안 해도 시간당 요금이 나간다.

ap-northeast-2(서울) 기준 NAT Gateway 요금:

시간당: $0.059
데이터 처리: $0.059/GB

월 비용 계산 (24시간 × 30일):
기본 요금: $0.059 × 720시간 = $42.48/월
데이터 처리 10GB 추가: $0.059 × 10 = $0.59
→ 월 약 $43 (약 57,000원)

실습 환경에서 NAT Gateway를 켜두면 아무것도 안 해도 매달 약 5만 원 이상 나간다. 개발 환경 여러 개 운영하면 이게 쌓인다.

---

SSM이 뭔가 — 구조부터 이해해야 한다

SSM Session Manager는 EC2에 접속하는 방식 자체가 다르다.

기존 SSH 구조:
내 PC → (인터넷) → EC2 22포트 (인바운드)

SSM 구조:
내 PC → AWS Management Console/CLI
            ↓
        SSM Service (AWS 관리 영역)
            ↓
        EC2 내부 SSM Agent → (아웃바운드 443) → SSM Endpoint

핵심 차이는 방향이다. SSH는 외부에서 EC2로 들어오는 인바운드 연결이다. SSM은 EC2 내부 에이전트가 SSM 서비스에 아웃바운드로 연결을 맺고, 세션을 그 채널로 역방향으로 연다.

"SSH는 문을 열어두고 들어오는 거다. SSM은 EC2가 먼저 전화를 걸어서 연결을 만들어놓고, 그 전화선으로 명령을 주고받는 거다. 인바운드 포트를 전혀 안 열어도 된다."

이 구조가 동작하려면 EC2가 SSM 서비스에 아웃바운드 443으로 통신할 수 있어야 한다. 방법이 두 가지다.

방법 1: NAT Gateway 사용
프라이빗 EC2 → NAT Gateway → 인터넷 → SSM 엔드포인트

방법 2: VPC Endpoint 사용
프라이빗 EC2 → VPC Interface Endpoint → SSM (인터넷 경유 없음)

방법 2가 핵심이다. VPC Endpoint를 쓰면 EC2가 인터넷에 나갈 필요 없이 AWS 내부 네트워크로 SSM 서비스와 통신한다. NAT Gateway가 필요 없어진다.

---

SSM + VPC Endpoint 구조 설계

퍼블릭 서브넷
└── (아무것도 없음, 배스천 제거)

프라이빗 서브넷 (10.10.2.0/24)
├── EC2 웹서버 (공인 IP 없음, 22포트 인바운드 없음)
└── RDS MySQL (공인 IP 없음)

VPC Endpoint (프라이빗 서브넷에 배치)
├── com.amazonaws.ap-northeast-2.ssm
├── com.amazonaws.ap-northeast-2.ssmmessages
└── com.amazonaws.ap-northeast-2.ec2messages

NAT Gateway: 없음
배스천 호스트: 없음
SSH 22포트 인바운드: 없음

SSM 동작에 필요한 VPC Endpoint가 세 개다. 하나만 만들면 안 된다.

Endpoint	역할
ssm	SSM 서비스 기본 통신
ssmmessages	Session Manager 세션 채널
ec2messages	EC2 인스턴스와 SSM 에이전트 통신

"ssm 엔드포인트만 만들고 나머지 두 개를 빠뜨리면 세션이 안 열린다. 에러 메시지도 불친절하게 나온다. 처음 설정하는 사람들이 여기서 많이 막힌다."

---

IAM 설정 — 이게 빠지면 아무것도 안 된다

IAM Role 이름: role-ec2-ssm
연결 정책: AmazonSSMManagedInstanceCore

이 역할을 EC2 인스턴스 프로파일로 붙인다. EC2 생성할 때 "IAM 인스턴스 프로파일" 항목에서 선택하면 된다. 이미 만들어진 EC2에 붙이려면 콘솔에서 작업 → 보안 → IAM 역할 수정으로 가면 된다.

Security Group 설정:

인바운드 규칙: 없음 (전부 삭제)
아웃바운드 규칙: HTTPS(443) → VPC Endpoint Security Group 허용

22포트 인바운드를 아예 없애도 된다. 처음 이걸 실습할 때 인바운드 규칙을 전부 지우는 게 심리적으로 불안했다. 근데 SSM 세션이 정상으로 열리는 걸 보고 나서 이해가 됐다.

---

실제로 접속해보기

AWS 콘솔에서 EC2 선택 → 연결 → Session Manager → 연결.

또는 CLI로:

aws ssm start-session \
    --target i-xxxxxxxxxxxxxxxxx \
    --region ap-northeast-2

접속되면 이런 프롬프트가 나온다:

Starting session with SessionId: [계정ID]-xxxxxxxxxx
sh-4.2$

SSH랑 달리 키 파일도 없고, 포트도 없고, 배스천도 없다. 그냥 연결된다.

접속 이력은 CloudTrail과 Session Manager 로그에 자동으로 남는다. 누가 언제 어느 인스턴스에 접속했는지 전부 기록된다.

"보안 감사 나오면 서버 접속 이력을 제출해야 한다. SSH 기반 구조에서는 각 서버 로그 파일 뒤져야 하는데, SSM은 CloudTrail에서 바로 뽑힌다. 이것만으로도 SSM 쓸 이유가 된다."

---

비용 비교 — 실제 숫자로

ap-northeast-2 기준 (2025년 기준):

NAT Gateway 구조
- 기본 요금: $0.059/시간 × 720시간 = $42.48
- 데이터 처리 50GB: $0.059 × 50 = $2.95
- 월 합계: 약 $45.43 (약 60,000원)

VPC Interface Endpoint 구조
- Endpoint 요금: $0.013/시간/AZ × 3개 × 720시간 = $28.08
- 데이터 처리 50GB: $0.01 × 50 = $0.50
- 월 합계: 약 $28.58 (약 38,000원)

구성	NAT Gateway	VPC Endpoint (1AZ)	VPC Endpoint (2AZ)
기본 요금/월	$42.48	$28.08	$56.16
데이터 50GB	$2.95	$0.50	$1.00
합계	$45.43	$28.58	$57.16

"Endpoint 비용 계산할 때 AZ 수를 곱해야 한다. 고가용성을 위해 2개 AZ를 쓰면 Endpoint도 AZ당 하나씩 만들어야 한다. 3개 Endpoint × 2 AZ면 비용이 두 배가 된다. 그렇게 되면 NAT Gateway보다 비싸질 수도 있다. 무조건 SSM이 싸다는 말이 아니다."

---

언제 SSM이 맞고, 언제 NAT Gateway가 필요한가

SSM + VPC Endpoint가 최적인 경우

금융이나 의료처럼 접속 감사 추적이 중요한 환경. SSH 키 관리가 복잡해지는 다수의 EC2를 운영할 때. 프라이빗 EC2가 인터넷에 나갈 이유가 없는 순수 내부 서비스. 단일 AZ 구조로 충분한 개발/스테이징 환경.

NAT Gateway가 필요한 경우

프라이빗 EC2에서 외부 API를 주기적으로 호출해야 할 때. 패키지 업데이트를 자주 해야 하는 환경. 다수의 AZ에 걸쳐 고가용성이 필요한데 Endpoint 비용이 더 나오는 경우.

"SSM이 NAT를 대체하는 게 아니다. EC2 관리 접속 경로를 대체하는 거다. 프라이빗 EC2가 외부 API 호출하거나 패키지 받아야 하면 NAT는 여전히 필요하다. 다만 그 NAT를 배스천 접속용으로 쓸 필요는 없어진다."

---

실습하면서 느낀 것

SSH 기반 구조에서 SSM으로 바꾸면 설계 자체가 심플해진다. 퍼블릭 서브넷에 배스천 EC2가 없어도 되고, 22포트 인바운드가 없어도 되고, 키 파일 관리도 없어도 된다.

근데 "무조건 SSM이 좋다"는 결론을 내리면 안 된다는 걸 비용 비교하면서 배웠다. 2개 AZ 고가용성 구조에서는 Endpoint 비용이 NAT보다 더 나올 수 있다. 내 환경의 AZ 수, 데이터 처리량, 보안 요구사항을 같이 놓고 봐야 맞는 선택이 나온다.

"클라우드 설계에서 '이게 무조건 좋다'는 건 없다. 상황에 따라 다르다는 말이 피곤하게 들릴 수 있는데, 그게 현실이다. 숫자를 직접 뽑아보고 비교하는 습관이 있는 엔지니어랑 없는 엔지니어는 1년 뒤에 설계 수준이 달라진다."

다음에는 NAT Gateway 없이 S3, ECR 같은 AWS 서비스에 접근하는 게이트웨이 Endpoint도 실습해볼 예정이다. 인터페이스 Endpoint랑 다르게 게이트웨이 Endpoint는 무료라는 것도 이번에 처음 알았다.