[AWS] AWS를 시작하기 전에 알아두면 좋은 것

출처 : https://wblinks.com/notes/aws-tips-i-wish-id-known-before-i-started/

AWS Tips I Wish I'd Known Before I Started - W(e)blinks

위 사이트의 내용을 기반으로 작성하였습니다.

 

---

응용 프로그램 개발시

1. 서버에 애플리케이션 상태를 저장하지 말 것

 불의의 사고로 서버가 중단되어도 애플리케이션 상태를 잃어버리지 않기 위함이다. 이를 위해 세션은 데이터베이스(redis)에 저장해야합니다.

 

2. AWS와 상호작용하는 언어에 맞는 SDK를 사용할 것

 위 사이트에선 직접 만들지 말고 이미 만들어져있는 AWS SDK를 잘 이용하라고 하였다. 아마 호완성 문제일 것이라고 생각된다. 그것을 일일이 만든다면 AWS를 이용해 편하게 클라우드 환경을 조성하는 의미가 없기 때문이 아닐까라고 생각됩니다.

 

3. 애플리케이션 로그를 볼 수 있는 도구를 만들 것

 실행 중인 인스턴스에 SSH를 사용하지 않고도 현재 실시간 로그 정보를 볼 수 있는 관리 도구, syslog 뷰어 또는 무언가가 있어야 합니다. 이렇게 하면 서버 관리에 더 편리하게 이용할 수 있을 것입니다.

 

---

운영시

1. 모든 서버에 대해 SSH 액세스는 비활성화 할 것

 보안 그룹의 모든 사용자에게 22번 포트를 허용하지 말아야 합니다. 그 이유는 서버에 SSH를 사용하는 것은 자동화가 실패하는 것이기 때문입니다. 다만 이것은 주의할 필요가 있습니다. 그것에 대해선 원문에서도 작성된 것이 있는데 읽어보시고 판단하시길 바랍니다.

많은 사람들이 이 특정 팁에 대해 우려하고 있습니다( Hacker News에서 좋은 토론이 있었습니다 ). 그래서 조금 더 자세히 설명하고 싶습니다. 인바운드 SSH를 비활성화하는 것은 자동화를 속이는 것을 막기 위한 방법일 뿐입니다(아, 그냥 SSH를 사용해서 이 문제를 해결하겠습니다). 인스턴스에서 무언가를 적극적으로 디버깅해야 하는 경우 보안 그룹에서 다시 활성화할 수 있습니다.때로는 특정 문제를 디버깅할 다른 방법이 없기 때문입니다.또한 애플리케이션에 따라 다릅니다.애플리케이션이 SSH를 통해 서버에 항목을 푸시할 수 있어야 하는 경우 비활성화하는 것이 좋지 않은 생각일 수 있습니다.인바운드 SSH를 차단하면 제게는 효과가 있었고 자동화를 적절한 상태로 만들 수 있었지만 모든 사람에게 적합한 것은 아닐 수 있습니다.

 

2. 서버는 일시적이니 신경쓰지말고 서비스 전체에 대해서만 신경쓸 것

 단일 서버가 죽더라도 자동크기 조정을 통해 새 인스턴스가 제공됩니다. 서버에 정적/ 탄력적 IP를 제공하지 말고 부하 분산 장치 뒤에 모든 것을 두고 균형을 맞춰야합니다. 요점은 자동화를 하라는 것 같습니다.

 

3. 모든사람이 IAM USER를 받으므로 마스터로 로그인하지 말 것

 계정의 보호를 위해서는 모든 사람에게 다중요소인증을 활성화 해야합니다. 일반적인 방법으로 서비스에 대한 운영계정과 거기에 전체 운영팀에 비밀번호가 있는 경우는 위험하다고 합니다.

 

---

보안

1. EC2 역할을 사용하고 애플리케이션에 IAM 계정을 제공하지 말 것.

 사용자에게 직접 주는 것보다 그룹을 통해 역할을 관리하는 것이 더 쉽고 시스템을 전반적으로 파악하기 쉽기 때문입니다.

 

2. CloudTrail을 사용하여 감사 로그를 보관할 것

 CloudTrail은 API 또는 웹 콘솔을 통해 수행된 모든 작업을 S3 버킷에 기록합니다. 버전 관리로 버킷을 설정하여 아무도 로그를 수정할 수 없도록 하면 계정의 모든 변경 사항에 대한 완전한 감사 추적이 가능합니다

 

---

그 외

그 외 것들은 전체적인 것이 아닌 EC2, RDS, IAM 같은 각각의 기능들의 대한 팁이므로 아직 이해가 낮은 제가 정리하기엔 이른 것 같아 직접 한 번 들어가 살펴보셔도 괜찮을 것 같습니다. AWS를 사용하기 전에 보안과 유저관리를 신경쓰는 것이 문제가 덜 발생하게 하는 방법인 것 같습니다.