AWS Cloudformation stack의 region별 설정 어떻게 할까? (핸즈온, 간단구축)

 

0. 잡설

 

 요즘 Iac 트렌드는 Terraform임을 부정하시는 분들은 그리 많지 않을 겁니다. 러페런스의 양, 유사 프로그래밍 경험, 멀티플랫폼 다양성 등등 이유는 많죠. 하지만 최근 개인적인 이유로 AWS CloudFormation을 연습해야할 이유가 생겼습니다. 

 

사실 AWS를 수년 다루어 왔음에도 불구하고 CloudFormation은 선뜻 손이 가질 않더군요.  yaml, json 마크업 언어 기반 인프라 처리는 너무 손이 많이가요.. 마치 Cloudformation은 python, Modern C++, Java 같은 고추상화 언어가 등장했음에도 불구하고, 고집을 못버리고 어셈블리나 C 또는 Jsp를 고수하는 느낌입니다. 차라리 아직 안정성 이슈가 좀 있더라도 CDK를 사용함이 어떨까 싶습니다. 하지만 필요성이 생긴만큼 공부를 하고, 공부한 내용은 정리하려고 합니다.

 

---

 

1. nested stack

 

 

기존 Cloudformation을 사용하시는 분들은 nested stack에 대해 잘 알고 계실겁니다. 루트 stack에서 계층 stack을 쌓는 방법입니다. cfn으로 대규모 인프라를 관리하기 위해서는 필수적인 활용 방법입니다. 밑은 제가 예제로 한번 만들어본 초간단 vpc 제작 cfn nested 템플릿 입니다.

 

구성은 Root stack 아래에 두개의 vpc를 설정합니다. 한쪽 Vpn은 서울 리전, 한쪽은 도쿄 리전으로 구성하려 합니다. 익숙하신 분은 금방 눈치채실텐데 문제점이 보이시나요? 타이틀에도 적혀있지만 문제는 바로 리전 설정이 여기에 기술되어 있지 않다는 점입니다. 단순 nested cfn 템플릿에서는 리전 설정이 불가능합니다.

 

이대로 디플로이를 하면 아래와 같이 디플로이를 한 리전에 두개의 VPC가 만들어지게 됩니다.

 

 

그렇다면 리전 설정은 어떻게 해야할까요

 

---

2. CloudFormation StackSet 활용

 

클라우드 계정이 기능별, 서비스별로 분화됨에 따라 계정 제어의 필요성이 생기고 AWS Organization, Control tower 등이 등장했죠. cfn을 사용한 인프라 제어도 그 트렌드에 맞추어야할 필요성이 생겼고 하나의 계정에서 다른 계정, 리전의 Cfn Stack을 관리해야할 솔루션이 필요하게 되었습니다. 그 솔루션이 CloudFormation StackSet입니다.

 

 

위에서 언급했듯이 StackSet은 다중 계정을 관리하는 솔루션이지만, 하나의 계정에서 다른 리전의 Stack을 관리할 때도 활용이 가능합니다. 그럼 구체적으로 어떻게 구축하는지 한번 살펴보도록 하겠습니다.

 

 

---

3. CloudFormation StackSet 구축 방법

 

먼저 만드는 구성은 아래와 같습니다.

 

위의 예제 템플릿 기준으로 서울리전의 VPC는 수정 없이 그대로 작성할 것입니다. 그 뒤 StackSet을 만들어 도쿄 리전에  VPC를 작성하게끔 구성할 것입니다. 다이어그램에서 보이듯이 StackSet을 활용할 때는 적절한 권한이 필요합니다. 그것이 AWSCloudFormationStackSetAdministrationRole와 AWSCloudFormationStackSetExecutionRole입니다.

 

 

3-1. 미리 해야할 것

 

위에서 언급했듯이 먼저 해야할 일은 Cfn을 사용할 계정에서 AWSCloudFormationStackSetAdministrationRole과 AWSCloudFormationStackSetExecutionRole의 IAM Role 만들어야 합니다.

IAM Role 이름	용도	AWS 템플릿 디폴트 정책
AWSCloudFormationStackSetAdministrationRole	컨트롤 주체 계정이 StackSet의 권한 범위를 설정	{     "Version": "2012-10-17",     "Statement": [         {             "Action": [                 "sts:AssumeRole"             ],             "Resource": [                 "arn:*:iam::*:role/AWSCloudFormationStackSetExecutionRole"             ],             "Effect": "Allow"         }     ] }
AWSCloudFormationStackSetExecutionRole	타계정(타리전)의 StackSet이 접근할 때 허용할 권한 범위 설정	{     "Version": "2012-10-17",     "Statement": [         {             "Effect": "Allow",             "Action": "*",             "Resource": "*"         }     ] }

이 Role을 특별히 만드는 콘솔 페이지가 존재하지는 않습니다. 그냥 IAM Role에서 저 이름으로 작성하시면 됩니다. 꼭 저 이름대로 작성하셔야 합니다. AWS가 참조하는 이름이 저 이름이기 떄문에 다른 이름으로 작성하시면 참조가 안되고, Cfn 작성에서 에러가 발생하게 됩니다.

 

직접 작성하시기 보다는 AWS가 제공하는 Role 작성 Cfn템플릿을 활용하시는 편이 혹여나 있을 실수를 줄일 수 있을 겁니다.

• AWSCloudFormationStackSetAdministrationRole
• AWSCloudFormationStackSetExecutionRole

이 포스트는 2022.08.21 기준으로 작성되었고, 지금 기준으로 저 템플릿 링크는 살아있습니다. 혹시 이 포스팅을 참고하는 시점에 링크가 죽었다면 AWS 공식 StackSet 문서를 참조해주세요.

 

작성은 아래와 같이 하시면 됩니다. IAM Role은 글로벌 서비스이기 때문에 어느 리전에서 생성해도 결과는 같지만 Stack을 생성하는 리전은 다르기 떄문에 admin은 서울리전, execute는 도쿄리전으로 작업하였습니다.

 

먼저 서울 리전 AWSCloudFormationStackSetAdministrationRole를 작성합니다.

 

 

 

 

그 뒤 같은 방법으로 도쿄리전에서 AWSCloudFormationStackSetExecutionRole를 작성했습니다. 

2의 AccountID는 자신의 AWS AccountID를 입력하시면 됩니다. 우측 상단의 프로필을 클릭하시면 10자리 이상의 번호가 나오는데 그것이 AccountID입니다.

 

 

 

 

 

이렇게 하면 사전준비는 완료되었습니다. 

 

 

 

 

반응형

3-2. StackSet템플릿 작성

 

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  nestedVpcSeoulStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://for-cfn-stack-22-08.s3.ap-northeast-2.amazonaws.com/vpc-seoul.yml

#  nestedVpcTokyoStack:
#    Type: AWS::CloudFormation::Stack
#    Properties:
#      TemplateURL: https://for-cfn-stack-22-08.s3.ap-northeast-2.amazonaws.com/vpc-tokyo.yml

  TokyoVpcStackSet:
    Type: AWS::CloudFormation::StackSet
    Properties:
      StackSetName: VpcTest
      PermissionModel: SELF_MANAGED
      StackInstancesGroup:
        - Regions:
            - ap-northeast-1
          DeploymentTargets:
            Accounts:
              - !Ref "AWS::AccountId"
      TemplateURL: https://for-cfn-stack-22-08.s3.ap-northeast-2.amazonaws.com/vpc-tokyo.yml

기존 도쿄리전의 코드는 지우고, TokyoVpcStackSet을 추가하였습니다. 다른 부분은 대부분 읽어서 알겠지만 PermissionModel의 SELF_MANAGED가 바로 알기 좀 힘드실겁니다.

 

PermissionModel	용도
self-managed	- 특정 계정 특정 리전에 스택 인스턴스를 배포 - 유저가 직접 IAM Role을 생성해야함
service-managed	- AWS Organizations이 관리하는 특정 리전에 스택 인스턴스를 배포 - IAM Role 생성 불요(Oranizations가 자동으로 생성) - OU에 추가되는 계정에 대해 자동배포 설정 가능

 

현 예제에서는 Organizations는 사용하지 않기에 SELF_MANAGED로 설정하였습니다.

 

 

 

3-3. 스택 작성

 

위에서 작성한 템플릿을 S3에 업로드 하고 서울 리전에서 스택을 생성합니다.

 

 

 

 

스택 디플로이 뒤 시간이 좀 지나면 아래와 같은 구성이 확인이 가능합니다.

서울리전 - VPC / 도쿄리전 - VPC

사실 StackSet 하나에 서울 리전을 추가로 설정하면 첫번쨰 서울 리전을 따로 작성할 필요없이 StackSet하나만으로 구성이 가능했지만, 이 예제에서는 명확하게 차이점을 보여주기 위해 따로 기술하여 디플로이 했습니다.

 

 

---

 

4. 마치면서

 

 이 StackSet은 여러부분에서 활용이 가능할 듯 싶습니다. 예를 들면 CloudFront에 붙이는 WAFv2는 무조건 us-east-1에 설정해야합니다. CloudFront는 us-east-1에 생성되어 배포되기 때문이죠. 이 때 서울리전에 다른 리소스와 함께 WAFv2 도 구성해야 한다면? 하나의 템플릿에서 처리하고자 한다면 반드시 별도 리전 설정이 필요하게 됩니다. 이 때 이 StackSet 활용이 가능하겠죠,.

 

 잡설에서 언급했듯이 아직 AWS CloudFormation은 좀 다루기 까다롭다는 느낌이 있습니다. 저와 같은 사람들을 위해 많은 분들이 Github에 사용 메뉴얼을 작성하는 아주 보기 편한 메뉴얼도 있네요. 저와 같은 분들은 참고하셔서 활용 자료를 얻어가시면 좋을 것 같습니다.

 

https://github.com/awsdocs/aws-cloudformation-user-guide/tree/main/doc_source