[참고][SSM] Systems Manager에서 EC2 인식 불가능 및 Session Manager를 이용하여 EC2 인스턴스 연결 실패(Windows AMI)

 

 

 

☄️ 문제

AWS Systems Manager(이하 SSM)에서 신규로 생성한 EC2를 인식하지 못함.

(SSM > Fleet Manager & Run command에서 EC2 목록에 해당 인스턴스 존재하지 않음)

⇒ AWS EC2 콘솔에서 해당 EC2 인스턴스에 session manger로 연결이 불가능.

Session Manager를 이용하여 EC2 연결 실패

🌎 환경

• OS : Windows 2019(AWS EC2)

 

---

 

🔫 해결 방법

1. AWS SSM Agent 확인

1-1. 인스턴스 내 AWS Systems Agent(amazon-ssm-agent)가 설치 및 실행 중인지 확인.

• 설치되어 있다면 amazon-agent가 최신 버전인지 확인 및 업데이트
• 설치되어 있지 않다면 ssm 에이전트 설치 및 구성
• Windows Powershell에서 아래 명령어로도 확인 가능하다.

Get-Service AmazonSSMAgent

(Windows Powershell) SSM Agent Status 조회

1-2. ssm-user 사용자 계정이 있는지 확인한다.

• SSM Agent는 최초 시작 또는 설치 후 재시작 시 ssm-user 로컬 사용자 계정을 생성한다.
  • Linux 및 macOS : ssm-user는 /etc/sudoers에 포함되어 있어야 한다.
  • Windows : Administrators 그룹에 포함되어 있어야 한다.

 

2. EC2 IAM Role 확인

• AWS Systems Manager가 EC2 인스턴스에 액세스할 수 있도록 IAM을 이용하여 권한을 부여해야 한다.
• EC2 인스턴스에 연결되어 있는 IAM 역할에는 AWS Managed Policy인 AmazonSSMManagedInstanceCore가 포함되어 있어야 한다.

 

3. 인스턴스 메타데이터 서비스 연결 확인

3-1. SSM Agent는 인스턴스에 대한 정보를 얻기 위해 인스턴스 메타데이터 서비스에 연결되어 있어야 한다.

• telnet 169.254.169.254 80으로 TCP connection 확인.
• Windows의 경우에는 브라우저에서 http://169.254.169.254/latest/meta-data/ 접속해서 확인하는 방법도 있다.
• 만약 연결에 실패한다면, OS 내 라우팅 설정 확인 필요 ⇒ route print로 gateway의 주소가 서브넷 CIDR 범위의 첫번째 IP인지 확인한다.

3-2. SSM 엔드포인트에 443 포트로 잘 연결이 되는지 확인한다.

tnc -p 443 ec2messages.ap-northeast-2.amazonaws.com
tnc -p 443 ssm.ap-northeast-2.amazonaws.com
tnc -p 443 ssmmessages.ap-northeast-2.amazonaws.com

⇒ 보안그룹 설정 및 NAT Gateway로의 라우팅 설정에 이슈는 없었으며 모두 PingSucceeded에서 False의 결과를 출력함.

(Windows Firewall Profiles는 이미 모두 해제되어 있던 상태. 해제하는 명령어는 다음을 참고)

netsh advfirewall set allprofiles state off

3-3. DNS 서버를 확인한다.

• DNS 서버가 VPC CIDR 대역의 두 번째 IP인지 확인한다.
• 제어판 > 네트워크 및 인터넷 > 네트워크 연결 > (우클릭) 속성 > 인터넷 프로토콜 버전 4(TCP/IPv4)
• [ 다음 DNS 서버 주소 사용 ] 에서 [ 기본 설정 DNS 서버 ] IP 확인하여 VPC CIDR 대역의 2번째 IP인지 확인
  ex) 10.0.0.0/24에서 10.0.0.1은 VPC 라우터를 위해 AWS에서 예약된 IP

⇒ DNS 서버가 다른 IP로 설정되어 있어 VPC 네트워크 주소의 2번째 IP로 변경 후, SSM에서 정상적으로 인식됨

 

 

4. SSM Logs 확인

• 3번까지 확인 및 이상 없음에도 불구하고, SSM에서 인스턴스가 제대로 인식되지 않는다면 SSM Agent의 로그를 확인해보자.
  • Linux 및 macOS : /var/log/amazon/ssm/
  • Windows : %PROGRAMDATA%\\Amazon\\SSM\\InstanceData\\

 

✅  요약 : Checklist 

1. 인스턴스에 AWS Systems Agent(amazon-ssm-agent) 설치 & 실행 중인지? (+최신 버전인지)

2. 서버 내부에 ssm-user 사용자 계정이 있는지?

3. EC2에 연결되어 있는 IAM Role에 AmazonSSMManagedInstanceCore 정책 포함되어 있는지?

4. 보안 그룹, NAT Gateway로의 라우팅, (Windows인 경우 Windows 방화벽) 설정에 문제없는지?

5. DNS 서버 주소 제대로 설정되어 있는지?

---

💡 원인 분석

EC2 Launch Initialize 작업을 수행하지 않고 Windows 2019 인스턴스에서 AMI가 생성되는 경우, 메타데이터로의 라우팅 정보를 포함한 시스템 관련 정보가 OS 구성의 일부로 인식되어 AMI에 포함되게 된다. 해당 AMI에서 생성되는 신규 인스턴스는 서브넷과 관계없이 AMI가 만들어졌던 인스턴스의 경로와 동일한 경로를 사용한다. 따라서, 메타데이터 및 활성화와 같은 작업이 다른 서브넷이나 VPC에서 시작되면 실패하게 된다.

문제 서버는 같은 VPC에서 만든 Windows AMI에서 시작한 인스턴스인데, 이미지가 만들어진 서버가 AD에 조인되어 있던 서버라 DNS 서버 주소가 AD 서버의 IP로 설정되어 있었다. 이로 인해 AWS System Manager에서 인스턴스 인식 불가능.

 

 

🔗 참고 링크

1. Systems Manager 콘솔의 관리형 인스턴스에 EC2 인스턴스가 나타나지 않는 이유는 무엇입니까?
2. 2단계: Session Manager 권한을 사용하여 IAM 역할 확인 또는 생성
3. 7단계: (옵션) ssm-user 계정 관리 권한 설정 또는 해제
4. Subnets for your VPC
5. 윈도우10 DNS 서버 변경과 의미 추천 DNS 정리 오류 캐시 초기화 방법까지

출처 : https://hyeon-joo.tistory.com/11