AWS : private subnet 서버 접근 2 - Session Manager 사용

예전에 private subnet에 있는 호스트에 접근하기 위한 방법으로 bastion 서버를 사용하도록 설정했는데, 아무리 생각해도 서버접근용으로 서버를 둔다는 부분이 마음이 들지 않았다. 그래서, AWS Systems Manager의 Session Manager를 사용하도록 설정을 변경하였다.

 

1. 현재 웹서비스를 기동하기 위한 가장 간단한 방법인 Elastic BeansTalk을 사용하고 있다.

 

2. EC2가 SSM에 접근할 수 있도록 ROLE을 생성해 주고,

  2-1 아래의 role은 aws-elasticbeanstalk-ec2-role 기본 role에 AmazonSSMManagedInstanceCore를 추가한 롤이다.

  2-2 이런 이유는 EC2가 Beanstalk의 리소스를 사용하는 권한 + SSM에 서비스에를 사용하는 권한을 EC2에 부여하기 위함이다.

 

3. 만든 ROLE을 Elastic Beanstalk 환경 설정에 넣어 준다.

  3-1 기존에 만들어진 Beanstalk환경을 업데이트 하고 있다. 신규생성일 경우는 처음에 설정에 해당 role을 넣어준다.

  3-2 실제 개발 서버에서 작업한 거라 모자이크 처리했다.

  3-3 apply를 누르면 바로 반영되지 않고 환경을 다시 만들어야 한다고 경고가 뜬다. 다시 만들면 된다. 

 

 

4. Beanstalk 환경을 반영을 적용하여 새로 환경을 생성한다. 서비스를 다시 올리는 것이라 시간이 좀 걸린다.

 

5. SSM의 Fleet Manager에 해당 EC2 정보가 올라온 것을 확인할 수 있다. role에서 설정한 내용이 SSM에 EC2를 등록되도록 허용해주는 부분이다.

  5-1 목록에 development가 올라온 것을 확인할 수 있다.

  5-2 fleet manager는 말그대로 fleet을 제어할 수 있는 기능이다. fleet은 보통 함대라고 하는데 그냥 여러 개를 동시에 제어할 수 있다는 의미다.

  5-3 SSM에 등록된 리소스가 표출되는데 이것이 가능한 이유는 Amazon Linux를 사용한 리소스는 기본적으로 SSM agent가 설치되어 있기 때문이다. 

 

 

6. SSM의 Session Manager에 가면 해당 EC2가 나오고 세션을 시작하면 ssm-user로 접속되는 것을 확인할 수 있다.

 

 

  6-1 ssm-user는 sudo 권한을 가지고 있다. Beanstalk의 서비스 folder는  / var/app/current에 존재한다.

 

 

 

7. 아래가 EC2 정보인데 public IP가 없는 것을 확인할 수 있다. 즉 private subnet에 있어도 이 방식으로 접근이 가능하다는 의미다.