AWS Cloud Club Hongik에서 실습 환경 구성하기

AWS Cloud Club Hongik

안녕하세요, Sean입니다. 저는 AWS Cloud Club Hongik을 운영중이고, AWS 클라우드 기초 스터디를 진행하고 있습니다.

AWS 클라우드 기초 스터디에서는 단순히 이론 세션만 진행하지 않습니다. 매주 '트러블슈팅 실습 세션'을 준비했습니다. AWS 환경에서 발생하는 문제 상황에서, 직접 콘솔에서의 작업을 통해 문제를 해결하는 경험을 제공해드리고자 이러한 실습 세션을 준비했습니다.

 

실습 세션 자료 일부

 

트러블슈팅 실습 환경을 제공해드리기 위해 AWS Organization과 CloudFormation StackSets 사용을 결정했습니다.

• AWS Organization을 통해 계정을 통합 관리하고 실습 과정에서 발생할 수 있는 추가적 비용을 중앙 계정에서 관리할 수 있습니다.
• CloudFormation StackSets을 통해 단일한 템플릿으로 여러 계정에서 실습 환경을 구축할 수 있습니다.

---

Cost & Free tier benefit

채택 시 여러 고려 사항이 있었습니다. 그 중 가장 큰 고려 사항은 비용이었습니다.

 

Organization 내에서는 한 계정만큼의 free tier benefit만 받을 수 있습니다. 하지만, 실습 시 사용되는 리소스의 사용량이 한 계정의 free tier benefit으로도 커버 가능한 용량임을 계산하였고, 이는 큰 문제가 되지 않는다고 판단했습니다. (예: 750시간/월의 프리티어 EC2 사용량은 15명의 멤버 계정에 매주 두시간 인스턴스를 두개씩 프로비저닝 하는데 무리가 없습니다. 15 * 2 * 2 * 4 = 240시간/월)

 

저희가 사용한 서비스 리스트는 다음과 같습니다:

• EC2 Instance & AMI & Snapshots
• Applicaiton Load Balancer
• S3 Bucket
• VPC & internal resources (subnet, firewalls, routing tables, ...)
• etc

 

실제로 현재까지 7주차의 스터디 세션을 진행하였고 2달러 이하의 비용을 기록하였습니다. 다만 consolidated billing을 하는 만큼, 멤버 계정 내에서 원치 않는 리소스가 생성되는지 면밀히 검토할 필요가 있습니다. 실습 계정에 멤버분이 몰래 값비싼 리소스를 생성해서 채굴이라도 한다면 문제가 되겠죠? 그래서 권한 관리와 감사(auditing)가 중요합니다.

---

Permission Management

다중 계정을 관리한다면 권한 관리가 중요합니다. 최소 권한 원칙을 따라 정말 필요한 권한만 주는 것이 좋겠지만, 저는 실습 진행 시 멤버분들에게 자율성을 보장해주고자 했습니다. 따라서 Organization Unit과 SCP를 통해 권한을 관리했습니다.

 

 

ACC Hongik의 Organization Unit은 다음과 같이 Restricted, Working, Finished 유닛들을 가집니다.

 

 

먼저, Restricted Unit에 속한 멤버들은 어떠한 권한도 가지지 않습니다. 실습 진행중이 아닐 때 모든 멤버 계정을 해당 유닛으로 옮겨 사용을 제한하였습니다. 이것을 통해 멤버들이 통합 청구에 연결된 계정으로 몰래 작업을 수행하는 것을 방지했습니다. (그럴 일은 없을 것이라고 믿지만요)

 

 

Working Unit에는 실습을 진행중인 멤버들의 계정을 포함시킵니다. 해당 유닛엔 Oregon 지역 외의 모든 리전에 대한 권한을 차단했습니다. Oregon 지역을 선택한 이유는 저희가 사용하는 리소스들의 가격이 타 리전보다 저렴하기 때문입니다. 권한 설정을 보시면 전체 리소스에 대한 와일드카드(*)를 쓰지 않고 제한할 리소스들을 명시해둔 것을 확인할 수 있습니다. 와일드카드를 쓰지 않는 것은 글로벌 서비스에 대한 접근을 허용해주기 위함입니다. SCP에서 명시적으로 거부한 리소스들에 대해서는 허용 규칙을 만들어도 절대 허용해주지 않습니다. 그렇기 때문에 AWS Documentation에서도 그림의 정책과 같은 방식으로 리전을 제한할 것을 권장합니다.

 

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region

 

이 유닛에 실습 환경에 대한 StackSets을 배포합니다. 

 

 

Finished Unit은 실습을 마친 멤버들의 계정을 포함시킵니다. 유닛에 대한 구조는 Working Unit과 크게 다르지 않습니다. 해당 유닛엔 마찬가지로 Oregon 지역 외의 모든 리전에 대한 권한을 차단했습니다. 실습을 마친 계정에 모든 권한을 바로 차단하지 않는 이유는 StackSets이 실습 리소스를 삭제하기 위한 권한을 부여해야 하기 때문입니다. 이 유닛에 실습 환경 Cleanup을 위한 StackSets을 배포합니다. (Cleanup에 대해서는 CloudFormation StackSets 파트에서 자세히 다룹니다)

 

Unit별로 권한을 관리함으로써 멤버분들의 우발적 행동으로 인한 리스크를 최소화하면서도, 실습 시간에는 자율성을 보장할 수 있었습니다.

 

이 방식으로 운영하며 아쉬운 점이 있었습니다. SCP는 계정 전체에 대해 적용되는 정책이기 때문에, 가령 계정 내 StackSets role은 허용하고 계정 사용자는 허용하지 않는 방식의 세밀한 권한 관리가 불가능하다는 문제가 있었습니다.

 

IAM User를 생성하도록 하고, 이 IAM User의 Role을 관리하면 더욱 세밀한 권한 관리가 가능할 것입니다. 하지만 저는 많은 대학생 분들이 IAM User를 사용하지 않고 루트 계정을 사용한다는 점 🥲, 그리고 루트 계정 정보를 각각의 멤버분들이 관리한다는 점을 고려해 루트 계정에도 권한을 제한할 수 있는 방식인 SCP를 채택했습니다.

---

CloudFormation StackSets

StackSets이 무엇인가에 대한 기본적인 설명에 대해서는 다음을 참고하세요.

 

 

StackSets은 Unit 단위로 배포되어 있습니다. 먼저 Working Unit에 실습 환경을 생성하는 deploy-infrastructure 템플릿을 StackSets으로 배포하고, Finished Unit에 실습 환경을 제거하는 delete-infrastructure 템플릿을 StackSets으로 배포합니다. 그런 이후엔 상황에 맞게 계정들이 속한 Unit을 바꿔주기만 하면 알아서 Stack이 적용되고 삭제됩니다.

 

예를 들어 실습 환경이 구성되어 있는 Working Unit에 속한 계정을 Finished Unit으로 옮기면, 자동으로 실습 환경에 대한 Stack(deploy-infrastructure)이 제거되고 Cleanup에 대한 Stack(cleanup-infrastructure)이 생성됩니다. 따라서 저는 계정을 옮겨주기만 하면 알아서 실습 환경 정리를 할 수 있는 것이죠.

 

원래 StackSets을 배포할 때 동시에 몇 개의 계정에 작업을 실행할 것인지, 또 몇개가 실패하면 롤백할 것인지 정의할 수 있습니다. 그래서 저는 빠른 실습 환경 구축을 위해 15개의 계정에 동시에 환경을 구축하도록 설정하는데요, 계정 OU를 옮겨 처리할 땐 Stack 배포 처리가 한번에 하나씩만 됩니다. 즉 병렬 처리가 안됩니다. 저희 실습 환경의 경우엔 Stack 생성 및 삭제 작업이 얼마 걸리지 않아서 큰 문제가 되진 않았지만, 설정했던 대로 움직이지 않아서 의아했습니다. 

 

저는 빠른 실습 환경 구축을 위해 StackSets 배포 전에 먼저 계정들을 Working Unit으로 옮기고 StackSets를 배포하여 병렬적으로 리소스가 생성되도록 처리했습니다.

 

단순히 deploy-infrastructure를 삭제하는 것만으로는 실습 과정에서 생성된 추가적 리소스를 삭제할 수 없습니다. Cleanup 템플릿은 CloudFormation의 Custom Resource를 활용합니다. Custom Resource를 활용해 Lambda 함수를 호출하고, 그 Lambda 함수가 SDK를 이용해 계정 내 생성된 리소스들을 조회하여 삭제합니다. 이러한 방식을 통해 실습 과정에서 생성된 추가적 리소스들을 삭제할 수 있었습니다.

---

Auditing

StackSets을 통해 Cleanup을 자동화했다고 해도, 모든 리소스를 전부 조회해서 마법처럼 싹 지워주지는 않습니다. 따라서 여전히 누군가 예상 범위 밖의 리소스를 생성했을 가능성이 있었습니다. 따라서 실습을 마친 후엔 멤버분들의 계정에 들어가 CloudTrail의 Event History를 조회해 이를 관리했습니다.

 

Organization 내에서 CloudTrail 중앙화 로깅을 구현할 수 있습니다. 다만, 이 부분에 대해서는 조심스러웠습니다. 멤버들의 각 계정에 모든 멤버들의 계정에 대한 Trail이 생성된다는 점을 알게 되었습니다. 15명의 계정 각각에 모든 계정에 대한 이벤트들이 쌓이게 된다면 비용에 대한 부담이 커질 수 있겠다는 판단이 들어 적용하지는 못했습니다. (사실 바빠서 테스트 및 구현할 시간이 없기도 했습니다 😇) 결국 이 부분은 HumanOps로 해결했는데(..) 좋은 방법이 있다면 공유해주시면 감사하겠습니다. 

---

Lessons learned

여러 계정을 다루는 것은 어렵습니다. 정확히 말하자면 작업 자체가 어렵다기보다는, 모든 작업에 대해 아주 신중해야 한다는 점이 어려웠습니다. 작은 실수가 치명적인 문제로 이어질 수 있기 때문에, 매번 작업 전에 도큐멘테이션을 뒤져보며 면밀히 검토하고, 개인 계정에서 테스트해보며 정상적으로 작동하는지 계속해서 검증했습니다. 처음엔 이러한 이유로 개발 및 구성에 시간을 많이 쏟았지만, 지금은 꽤 빠르게 환경 구성이 가능해졌고, 관리가 쉬워졌답니다.

 

자동화를 위해 쏟은 시간은 정말 많았지만, 결과적으로 제 실험은 성공적이었습니다. 어떤 레퍼런스 없이 새로운 솔루션을 만들어본 경험은 많지 않았는데, 이번에 좋은 경험을 하게 되었습니다. 긴 글 읽어주셔서 감사합니다.