공부

AWS System Manager(SSW) EC2 인스턴스 연결 설정(SSH 대체)

na0-0 2025. 4. 11. 20:10
반응형

 

 

이전 글에서 https://na0-0.tistory.com/196 Github self hosted runner와 SSM 을 비교하고,

최종적으로 우리 서비스는 SSM을 사용하기로 결정했다.

 

현재 EC2를 확인해본 결과, ECR에 올려져 있지는 않고,

인/아웃바운드 포트 22가 열려서 SSH 연결이 오고 들어가는 것을 허용한 것 처럼 보인다.

 

SSH와 Bastion Host를 이용한 방법 (기존)

일반적인 방법으로, 필요 EC2 이외에 추가 리소스는 아래와 같다.

  • Public Subnet에 호스팅된 Bastion Host (EC2)
  • Bastion Host에 SSH(22) 접근을 허용하는 보안 그룹 (Security Group) : 적절한 IP 대역에 22(SSH) 포트 허용
  • SSH 접속 인증을 위한 EC2 Key Pair (EC2 생성시)

아래 명령어로 접근 가능

ssh -i <keypair 경로> <사용자>@<호스트 주소>

 

Bastion Host는 같은 VPC 네트워크의 Private Subnet에 있는 호스트에 접근 가능

 

:: AWS SSM을 사용하면 필요 없다.

  • Bastion Host가 필요없다.
  • Key Pair가 필요없다.
  • Security Group + Rule이 필요 없다.
  • Private Subnet에 있는 EC2 인스턴스에 바로 접속할 수 있다. 
  • AWS Client VPN을 사용하는 것에 비해서 비용이 적게 든다.

=>

ssh 명령으로 Bastion Host에 접속하는 대신, AWS CLI의 ssm 서비스의 start-session 명령으로 AWS Systems Manager에 연결

SSM은 HTTPS 프로토콜을 사용하여, Key Pair X + 포트 허용을 위해 Security Group X

인증은 AWS CLI를 사용하기 위해 등록한 AWS Credentials를 사용

그러나 문제는,, 우리가 AWS Credentials를 사용하지 않는다.

 

SSM: AWS Systems Manager

원격 호스트 접속 방법 비교 : SSH(기존) vs. SSM(개선)

 

Bastion Server 접근 플로우

로컬 환경에서 Public subnet에 위치한 Bastion Server로 개인별 발급받은 Keypair를 이용해 SSH로 접근

Bastion Server에 도착한 시스템 엔지니어는 최종 목적지인 서비스 EC2로 다시 한번 ssh를 이용하여 접속

 

Session Manager 접근 플로우

Session Manager를 사용할 경우 보다 더 간결한 아키텍처를 구성

AWS IAM을 통해 인증을 받고 AWS Console 혹은 AWS CLI를 사용하여 Session Manager를 통해 서비스 VM에 접근

 

2.4.1 Session Manager 연결을 위한 사전 작업
2.4.1.1 EC2 Instance Profile 생성 및 연결
System Manager를 통해 EC2에 접근하기 위해선 EC2의 Instance Profile에 권한 설정이 필요

Poilcy Name : AmazonSSMManagedInstanceCore

AmazonSSMManagedInstanceCore 정책은 관리형 정책이라서 IAM에 이미 만들어져 있다.

 

그러나 해당 인스턴스는 다양하게 사용하기 때문에

최대한의 변화없이 수정하고자 한다.

아래는 이미 타겟 ec2 instance의 IAM 역할로 할당되어있던 역할이었으므로,

해당 역할에 "AmazonSSMManagedInstanceCore" 를 추가한다.

 

연결된 것을 확인할 수 있음

 

해당 EC2에 IAM 할당

 

 

추가로 아래와 같이 IAM role이 EC2에 할당되어있는지 확인이 가능했다.

위와 같은 정책은 해당 정책과 연결된 보안 주체는 모든 인스턴스(*)에 대해 Action을 할 수 있다는 것

만약에 Resouce에 해당 값이 있다면, "arn:aws:ec2:<리전>:<AWS Account>:instance/i-xxx",

i-xxx EC2 인스턴스에 대해서만 Action을 할 수 있다는 뜻이다.

 

 

2.4.1.2 VPC Endpoint 구성

Private Subnet에 구성된 EC2는 외부와의 연결이 없다. 즉, 외부 AWS 서비스(SSM 포함)에 연결 불가능

하지만VPC 엔드포인트 (VPC Endpoint)를 구성한다면 AWS 서비스와 연결 가능

 

VPC 엔드포인트란?
AWS 서비스에 인터넷 없이도 VPC 내부에서 비공개 통신 경로를 제공하는 기능.
왜 필요할까?
예를들어, VPC Endpoint가 없다면 EC2 인스턴스에서 S3로 액세스 할 때, EC2는 NAT와 Internet Gateway를 통해 외부로 나가 S3에 접속한다. (EC2와 S3 둘 다 AWS 서비스이지만, 외부 통신) EC2, RDS 등의 서비스는 ENI(Eliastic Network Interface)를 탑재하고 이 ENI에 Public 혹은 Private IP를 부며해 VPC안에 존재한다.
 AWS Region 안에 위치하는 건 맞지만 VPC 내부에 위치하지 않고 공인 IP를 통해 외부에서 접근하는 방식으로 즉, S3 등의 서비스를 이용하기 위해서는 외부 인터넷을 이용해야 한다. 그래서 중요 정보가 외부 인터넷을 타는 것을 꺼린다면 VPC Endpoint를 고려해야 함

 

 

1. Security Group 생성

VPC Endpoint에서 사용할 Security group을 생성

ec2 > 네트워크 및 보안 > 보안 그룹으로 들어가면 보안 그룹 생성을 클릭할 수 있다.

(할때 내 region이 어디에 있는지 잘 파악하고 해야 한다.

미국 버지니아 북부로 가있어서, EC2 연결할때는 서울로 되어있어 연결이 되지 않았다.

다시 작업해줘야 됐음)


System Manager는 TCP 443 port를 사용함으로 VPC 대역에서 들어오는 룰을 작성

 

관련된 내용에 한글을 썼더니 빠꾸 먹고 다시 작성


태그는 태그 컨벤션에 맞춰서 작성함

그러면 아래처럼 작성이 완료된다.

 

 

 

 

System Manager는 TCP 443 port를 사용함으로 VPC 대역에서 들어오는 룰을 작성

 

다시 연결되어있는 보안 그룹으로 가서

인바운드 규칙을 편집해주었다.

 

이렇게 위와 동일하게 수정해주었다.

type은 HTTPS (HTTP가 아닌), 프로토콜 TCP는 자동 할당, 포트 범위 443도 자동 할당이다.

대신 소스는 10.0.1.0/24 가 아닌, VPC endpoint 보안 그룹 → 인바운드 규칙을 172.31.0.0/16 로 지어주었다. (내가 연결하고자 하는 인스턴스의 파라이빗 IPv4 주소가 172.32.X.X 이여서 맞춰줘야 했다.)

 

VPC 는 Virtual Private Cloud 의 약자로, AWS 에서 가상 개인(사설) 네트워크 구성을 가능하게 해주는 네트워크 서비스
Private(사설) IP Address, AWS 에서는 10.0.0.0/16, 172.16.0.0/16, 192.168.0.0/24 등을 사용

따라서 VPC 내부에서는 선언한 CIDR 10.0.0.0/16 의 Private IP Address 로 EC2 같은 리소스들에게 IP Address 를 할당하고 인터넷 방향으로 통신을 하고자 하면 Public Subnet 은 Internet Gateway 를 통해서, Private Subnet 은 NAT Gateway 를 통해서 아웃바운드 통신

Subnet 10.0.1.0/24 로 설정
이유?
- 만일 10.0.0.0/16 을 통으로 사용하게 되면 65xxx개의 IP Address 를 사용 => EC2 를 65xxx 개에 IP Address 할당이 가능
(AWS 를 사용하는 넷플릭스도 2000 ~ 3000 여개를 사용)
그럼 나머지 63xxx ~ 62xxx 개는 사용하지 않게되니 낭비
Subnet 이란 이런 IP Address  를 좀 더 낭비 없이 잘 사용할 수 있도록 IP Address  대역을 합리적으로 사용하고자 작게 나누는 것을 말합니다. 이 실습의 Subnet 처럼 10.0.1.0/24 로 선언하면 256 개 IP Address 를 사용

 

2. VPC Endpoint 생성
3가지 Endpoint를 생성한다.

  • com.amazonaws.ap-northeast-3.ssmmessages
  • com.amazonaws.ap-northeast-3.ssm
  • com.amazonaws.ap-northeast-3.ec2messages

 

 

정책은 일단 전체 액세스로 제어하기로 했다.

3개 생성 완료!

 

2.4.2 Session Manager 연결

  1. AWS Console 사용
    a. EC2 선택 > Connect로 Session Manager를 통해 접근

아래처럼 연결 버튼에는 계속 로딩 중이다.

그러다가 계속 위와 같이 에러가 떠서 이것저것 해보다가

밥먹고 왔더니 (기다렸더니) 됐다.

 

아마도 반영이 안되었던 것으로 추정한다.

 

보안 그룹이나,, VPC나, IAM 정책 추가 등등 (IAM 역할에 AmazonSSMManagedInstanceCore 정책을 추가했다면, SSM Agent는 자동으로 새 자격증명을 받아서 다시 연결 시도한다는대)

 

그런 부분을 내가 이것저것 만져서 인스턴스에 반영이 안되었던 것이라고 판단한다. (어쩐지 다해줬는데 안되더라)

다행이도 인스턴스를 재시작 안해서 다행이다.

 

그리고 내 로컬 터미널에서 awscli와 aws-session-manager-plugin

brew install awscli
brew tap dkanejs/aws-session-manager-plugin
brew install aws-session-manager-plugin
aws ssm start-session --target i-XXX

 

해서 접속이 되는 것을 확인할 수 있다 !

 

 

 

 

출처 및 참고

- https://dev.to/afiqiqmal/aws-session-manager-vs-ssh-n3f

- https://www.lgcns.com/blog/cns-tech/aws-ambassador/40899/

- https://www.inflearn.com/community/questions/172754/

- https://juneyoung.io/devops-continuous-deploy-ec2-docker-ssm-github-actions-220601

- https://musma.github.io/2019/11/29/about-aws-ssm.html

가장 큰 도움을 주신 LGCNS 블로그[2] 와 musma 블로그[5]에게 큰 절을..

 

반응형