AWS Naming 모범사례를 알아보자

 기존 구축되어 있던 환경을 Cloud로 Migration하는 것은 많은 생각을 하게 만든다. 특히 경험이 많은 시니어 개발자가 이끌어 주는, 혹은 이미 기존에 존재하던 대규모 시스템에 적용되어 있는 규칙을 따를 수 있는 상황이 아니라면 앞으로 구축할 인프라에 대한 걱정이 앞설 수 밖에 없다. 이제는 개발된 서비스의 방향성과 그에 따른 아키텍처, 인프라 구축에 대한 설계가 어느정도 끝이 나고있고 이제는 그에따라 구축만 하면되는 상황이지만 서비스 규모가 커지고, 개발자 인원이 늘어날 경우 리소스들이 스파게티 처럼 엉켜 처치불가한 상태가 될 수 있다. AWS에서는 이런 상황에 대한 다양한 해결법을 제시해 주고 있지만 우리는 먼저 가장 간단하게 바로 적용할 수 있는 리소스들의 Naming 규칙을 정해 도입해보는 것이 좋다. 실제로 구축 초기단계에 네이밍 규칙을 정해 도입했더니 기존 설계에 문제점을 파악해 개선된 부분이 조금 있었고 리소스 검색도 훨씬 편해졌다.

 

 기왕 Naming 규칙을 정할 거면 다른 큰 시스템에도 도입되어 있는 표준화된 규칙을 따르고 싶었고 구글링을 조금 해본 결과 괜찮은 모범사례를 찾을 수 있었다. 큰 시스템에서 사용하는 방식인지는 모르겠으나 다른 좋은 모범사례를 찾고 있지 못한 상황이라면 이 사례를 참고해 보는 것도 좋은 듯 하다.

 

AWS Naming Convention Best Practices Tagging - Myrtec

위 방식은 14년도에 작성된 모범사례이다. Tag은 16년도 이전에는 리소스당 태그제한이 10개 이하여서 단일 태그에 여러요소를 넣는 방식을 많이 사용했는데 현재는 리소스당 50개로 제한이 풀려서 태그당 하나의 데이터 요소만을 담는 걸 권장한다. 그런데 왜 저 옛날 방식을 보여주느냐 하면 예시가 정말 간단해서 초기에 구축을 시작하는 팀에게 적합해 보여서이다. 실제로 권장사항도 초반에는 최대한 적은 Tag로만 운영하다가 점차 늘려가는 방식을 권장하고 있기 때문에 초반부터 너무 거대한 Naming규칙을 정하는 것보다는 일단 필수적인 Tag로만 빠르게 구축을 진행하는 것이 좋은 방법이 아닌가 싶다.

 

AWS에서는 거의 대부분의 상황에 대한 모범사례를 제공해 주고 있으니 맨땅에 해딩을 해야하는 상황이라면 꼭 들어가서 모범사례와 권장사항을 확인해보는 것이 좋다.

 

Tagging Best Practices: Implement an Effective AWS Resource Tagging Strategy - Tagging Best Practices