정상적으로 접속된던 SSH가 갑자기 접속 안 됨

저의 경험과 기술지식으로는 ssh로 접속이 되어야 하는데 안 되고 있습니다.(참고 자료에 나와 있는 접속 에러에는 저의 경우에는 해당 사항이 안 되는 것으로 판단됨) 접속이 안 되고 있으므로 OS자체내의 방화벽이 어떻게 작동하는지 확인은 할 수 없습니다. 다른 instance로는 ssh 접속이 되고 있으므로 저희쪽 방화벽 문제는 아니라고 봅니다.
링크를 보시면 해당 instance에 설치된 citymart.kr 로 쇼핑몰 접속이 되고 있음을 확인할 수 있습니다. ssh 접속이 안 되었다면 어떻게 서버를 startup 할 수 있었겠습니까?
예전에도 이래서 instance 다시 만들고 setting도 다 다시 했는데 또 그래야 하는지. 불안해서 AWS 못 쓸 듯.

https://1drv.ms/p/s!AkmHQz00IGhEmrRiVkQhrVNDiSiDZA?e=FNZuze

공유해 주신 자료에 나와있는 내용을 보니 Connection time out 에러 메시지가 나온다면, 22 포트로 연결 수립에 있어서 인스턴스 측에서 포트를 열어주지 않는 사항으로 보여집니다. 가장 가능성 있는 시나리오로는, t2.small 인스턴스를 사용중이신 것으로 보이는데, 이는 버스트 가능 인스턴스 타입 중 하나로 CPU 기준 사용률이 20%로 제한되어 있습니다. 이 이상 CPU를 사용하고 있으면, CPU 크레딧 이라는 버스팅 시에 사용할 수 있는 가용량 적립이 안되고 성능이 20%로 제한됩니다. 이 제한 때문에 SSH 데몬이 정상 작동을 하지 못해 ssh 접근을 못할 가능성이 있습니다. CloudWatch 에서 지표들을 확인해 보시면 CPU 크레딧이 남아있는 지, CPU 성능이 제한되어 있지 않은 지 확인해보실 수 있습니다. https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#earning-CPU-credits 제한이 됨이 확인된다면, 인스턴스를 좀 더 높은 유형으로 변경하여 일시적으로 해소해 볼 수 있습니다. 또는 t3 로 변경하시면 무제한(unlimited) 모드를 적용하여 기준 사용률 이상이 발생할 경우 추가 비용을 부담하는 방법이 있습니다.

다른 가능성으로는, 디스크의 용량 또는 inode 용량이 다 차서, 새로운 파일을 생성하지 못해 ssh 포트를 열지 못하는 경우입니다. 이 경우는 OS에 어떻게든 접근해야 무엇을 할 수 있으므로, 새로 OS 구성 하시면서 데이터를 저장하는 볼륨을 추가로 연결하시면, 나중에 재구성하실 때 조금 더 수월하게 설정이나 작업을 하실 수 있을 것으로 예상됩니다.

https://1drv.ms/p/s!AkmHQz00IGhEmrRiVkQhrVNDiSiDZA?e=HJF4Eu

누가 ssh를 내리지 않았다면 발생하지 않을 현상입니다. 저는 그런 적 없는데. 그렇지 않고서는 이 현상을 제가 받아들이기기 쉽지 않습니다.

처음 instance를 만들었을 때 부터 ssh 접속이 잘 안 되었으나, 응답이 느릴 뿐 접속은 하였습니다. 성능상의 문제일 수 있겠다 생각들어 AMI를 만들어 새로운 ec2를 만들었고 -현재의 EC2- 접속도 잘 되었고 응답도 좋았습니다. 제가 소스 수정을 하였고 server restart 했고 개발한 쇼핑몰은 어째든 지금까지 잘 돌고 있습니다. 그리고 다음날 부터 현재까지 ssh는 더 이상 접속되지 않고 있습니다.

다른 ec2를 접속해 ssh,sftp 봤을 때 아무 문제 없습니다. 접속되는 ec2는 99% 동일한 쇼핑몰 서버인데 잘 접속됩니다. 저희 내부적인 network 문제는 아니라고 판단되며 지적해 주신 거 처럼 AMI를 만들어 T3로 , volume도 8G짜리 새로 EC2를 생성해 보았으나 여전히 접속이 안 되고 있습니다. 이런 일이 이번이 처음이 아니라서 원인 해결책을 알 수 없다면 다른 호스팅을 알아보려 합니다.

마지막으로 한번더 검토해 주시면 고맙겠습니다.

안녕하세요.

초기 인스턴스 생성 시 응답이 이미 느려지고 있었다는 점에 초점을 맞춰봐야 할 것 같습니다. 띄워진 인스턴스를 기반으로 AMI를 생성하고 새로운 인스턴스를 띄웠는데 동일한 현상이 나타났다는 점은 AWS 인프라 보다는 해당 인스턴스 OS 내 설정 등에서 문제가 발생중인 상황으로 추측해 볼 수 있습니다. 추가로 기존 인스턴스의 CPU가 2% 정도 사용중이고, CPU 크레딧이 충분히 적립되어 있으므로(=버스팅 사용량을 소진한 적이 없으므로) t 인스턴스의 성능 제한때문에 일어나는 일은 아닌 것으로 생각됩니다.

OS 상에서 어떤 작업을 하셨는지 확인이 어려운 상황이고, 웹 서비스도 약간의 지연이 발생하는 것으로 보아 OS 내부의 메모리 등의 문제가 있거나, 네트워크 연결 과정에서 (예를 들면 client 의 reverse domain 을 조회하는 경우가 생긴다든가, 네트워크 mtu 튜닝 등을 하셨다거나) 어떠한 지연이 발생하여 접속이 원활치 않고, 특히 ssh 의 경우에는 오랜 지연시간 후 결국 연결을 못하는 상황으로 보여집니다. 제가 위 답변에서 디스크를 분리해 보라는 의견을 드린 것의 전제는, OS는 새로 띄우고 어플리케이션 데이터만 별도의 볼륨에 위치시켜, 새로 인스턴스를 구성해야 할 경우에는 깨끗한 OS에서 데이터만 이동하는 시나리오를 전제로 드렸습니다. 가장 권장하는 방법은 말씀드린 것처럼, 새로운 인스턴스를 새로운 AMI 기반으로 생성하시고 웹서비스를 새로 구성하시는 방법을 추천 드리나, 원인 파악을 해 보시는 것도 중요할 것 같아 다른 방식으로 시스템에 접근하시는 방법도 설명 드리겠습니다.

AWS에서 제공하는 ubuntu AMI 를 통해 인스턴스를 생성하셨다면 SSMAgent 가 기본적으로 설치되어 있습니다. 여기에 systems manager 의 session manager 의 접근 권한을 가진 IAM Role 을 EC2에 적용하면 SSMAgent 데몬을 통해 시스템에 접근이 가능합니다. 설정 방법은 다음 사이트를 참고해 보시고, ec2에 role 설정 직후에는 바로 접속이 안될 수 있으니 role 설정 후에 인스턴스 재기동을 하시는 것을 추천 드립니다. https://catalog.workshops.aws/general-immersionday/ko-KR/basic-modules/10-ec2/ec2-linux/3-ec2-1 만약 session manager로 시스템 접근이 되신다면 /var/log/message 나 /var/log/secure 등 시스템 전반의 로그 등을 확인해 보시기 바랍니다. ssh brute force 등 다양한 이유가 있을 수 있습니다만, 원인을 찾으셨으면 좋겠네요.