AWS 를 사용하면서 흔히 저지르는 실수에 대한 내용으로 AWS Cloud Consultant 가 경험을 바탕으로 작성한 내용입니다. 
 
대부분 AWS 를 통해 small 또는 medium size 의 웹서비스를 배포하고 있음 
전형적인 웹 어플리케이션의 최소 구성은 아래와 같으며 이러한 패턴은 상당히 일반적임 
 
- load balancer
- scalable web backend
- database
 
 
이와 같은 상황에서 사용자들이 범하는 5가지 실수에 대해 공유한다. 
 
1. 수동으로 인프라를 관리한다. 
사용자가 수동으로 AWS 를 설정하여 인프라를 관리하는 경우 가장 큰 문제는 문서화 되지 않고 오류를 포함하고 있을 수 있는데 재현하기 어렵다. 
이러한 문제에 대해서는 Cloudformation 을 통해 해결할 수 있다. cloudformation 은 템플릿 안에 수행해야 하는 내용들을 설명해 두었기 때문에 EC2인스턴스와 보안그룹, 서브넷 등을 올바른 순서로 만들어낼 것이고 실행중인 스택에 변경사항을 적용하여 템플릿을 업데이트 할 수 있다. 
 
2.Auto Scaling Groups 을 사용하지 않는 것 
비록 single 인스턴스라도 모든 EC2 인스턴스는 Auto Scaling Group 안에서 생성되어야 한다. 
Auto scaling group 은 EC2 인스턴스를 모니터링하고 가상머신의 논리적 그룹 역할을 한다.
전형적인 웹 어플리케이션은 Auto scaling gropu 내 가상머신 안에서 기동된다. 
현재 워크로드에 따라 가상 머신을 확장하기 위해 auto scaling group 을 사용할 수 있고 CPU 의 사용 또는 로드밸런서 수신 요청의 수 등 통계에 알람을 설정하여 임계 값에 도달하는 경우 가상머신을 추가 배포하는 등의 행동을 정의할 수 있다. 
 
3. Cloudwatch 사용량을 분석하지 않는다. 
Cloudwatch 를 통해 가상 머신의 CPU , 네트워크, 디스크 사용량등을 확인할 수 있다. 
예를 들어 매일 동일한 시간대에 사용량이 높아지는 것을 확인할 수 있다면 그것은 cron job 일 가능성이 높다. 웹서버로 사용하는 서버가 cronjob 때문에 대기 시간이 증가했음을 확인할 수 있었다. 이러한 문제를 해결하기 위해 별도의 가상 머신에서 cronjob 을 수행하게 변경하기도 하였다. 
이와 같이 cloudwatch 에서 보여주는 통계 분석이 필요하고 그에 대한 알람을 정의할 필요가 있다. 
 
4. Trusted Advisor 를 무시 
Trusted Advisor 는  AWS의 모범 사례에 따라 리소스를 프로비저닝하는 데 도움이 되는 실시간 안내를 제공하며 (https://aws.amazon.com/ko/premiumsupport/trustedadvisor/) 중점으로 보는 영역은 아래와 같다. 
AWS Trusted Advisor
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
- 비용 최적화 
 - 성능 
 - 보안
 - fault tolerance (오류 또는 결함이 발생하였을 때 대처할 수 있는 방법)
 
환결설정에서 Trusted Advisor 로 부터 메일을 받도록 설정하면 지난 주 변경 이후 해결했거나 새로운 문제가 무엇인지 알려준다. 비용을 지불하는 경우 조금 더 강력한 검사를 추가적으로 수행하게 된다. 
 
5. 가상 머신을 충분히 이용하지 않는다. 
사용자는 가상머신의 사양을 충분히 사용하지 않는 다는 것을 깨닫기 전까지 가상머신의 개수를 줄이거나 xlarge 의 인스턴스를 large 로 줄이는 등의 작업을 하지 않는다. 
위에서 이야기 했지만 cloudwatch 의 리포팅 통계를 통해 생성된 가상 머신이 충분히 사용되고 있는지 확인해야하고 auto scaling group 을 통한 인스턴스 증감 설정을 위한 룰을 정의하기 위해서도 인스턴스 사용량에 대해서 인지하고 있어야 한다.