AWS re:Post을(를) 사용하면 다음에 동의하게 됩니다. AWS re:Post 이용 약관

cloudformation을 삭제할 임시 권한을 받은 유저가 cloudformation 지우는 방법 문의

0

A라는 cloudformation stack을 지우려고 합니다. 이때, 해당 stack을 지우는 방식이 cloudformation이 있는 계정에 대한 콘솔 로그인 or CLI 로 작업하는 것이 아니고 DELETE에 대한 권한을 다른 aws account 계정에서 임시로 할당하여 진행을 하려고 합니다.

이때 타 aws 계정이 삭제할 수 있는 cloudformation stack 내에는 삭제에 대한 임시 권한 주는 중첩스택이 존재 합니다.

임시 권한을 받은 계정이 아닌 실제 cloudformation stack을 가진 계정에서는 문제가 없으나 임시 권한을 통해 해당 cloudformation stack을 지울 땐 main cloudformation stack을 삭제할 때 에러가 발생합니다

해당 에러는 1달 전까지만 해도 발생하지 않고 임시권한자도 cloudformation stack을 삭제 시 main도 같이 지워졌는데 현재는 main만 안지워지는 상태 입니다.

이를 해결하기 위해 우선적으로는 cloudformation stack내에 임시권한을 주는 중첩 스택에 해당 스택이 생성하는 리소스를 지우지 않게 했는데 더욱 근본적인 해결 방법을 알고 싶습니다.

1개 답변
0

안녕하세요. 'astron' 사용자님.

AWS CloudFormation 서비스에 대하여 중첩 스택 사용과 관련된 질문을 주셨습니다.

'main' 스택을 생성한 후 본 스택에 대한 삭제 권한을 타 AWS 계정에 임시로 부여하는 중첩 스택을 생성하시어 스택 삭제 시에는 임시 권한을 부여받은 타 계정에서 'main' 스택 및 중첩 스택을 삭제하고 계십니다.

기존에는 그 과정에서 문제를 경험하지 않으셨으나, 질문을 주신 시점에는 중첩 스택은 삭제가 되지만 'main' 스택 삭제에 실패하는 현상을 경험하셨습니다.

혹시 제가 사용자님의 상황을 잘못 이해하여 정정을 희망하시거나 추가를 희망하는 내용이 있다면 알려주세요.

답변의 간결성 및 가독성 향상을 위해 아래에서는 위의 두 AWS 계정에 대하여 이와 같이 통칭하겠습니다:

A 계정: 'main' 스택 및 임시 스택을 생성하는 주 계정

B 계정: 'main' 스택 삭제 권한을 임시로 부여받은 부 계정

AWS CloudFormation에서는 리소스 생성, 업데이트 및 삭제 작업을 최대한 병렬적으로 처리합니다. 따라서 스택 삭제 작업 중에 'main' 스택과 중첩 스택에 대한 삭제 시도가 함께 처리될 수 있으며, 중첩 스택이 main 스택보다 먼저 지워지는 경우에는 B 계정은 'main' 스택에 대하여 액세스를 잃게 되어 main 스택 삭제에 실패하게 됩니다.

다만 이러한 경우에도 A 계정은 기본적으로 본 계정에 의해 생성된 모든 스택에 권한을 가지고 있으므로 B 계정의 상황과 관련 없이 스택 삭제가 가능할 것입니다.

제가 사용자님의 CloudFormation 스택에 대한 정확한 구조를 확인할 수는 없으므로 A 계정에서 중첩 스택을 통해 IAM 정책 자원을 생성하여 스택 삭제 권한을 B 계정에 대하여 임시로 부여하고 계신다는 가정 하에 아래와 같이 질문에 답변 드리겠습니다.

질문주신 것과 같은 상황을 방지하기 위해서는 여러가지 방법이 있습니다.

첫 번째로는, 중첩 스택을 사용하지 않고 'main' 스택에서 임시 권한을 부여하는 IAM 정책을 함께 생성하도록 하며 (스택 업데이트 작업을 통해 추가하실 수도 있습니다), DependsOn 속성 [1]을 활용하여 리소스 (기존 main 스택의 리소스들과 임시 권한을 부여하는 IAM 정책) 간의 종속성을 부여하는 방법입니다.

예를 들어 리소스 A와 B가 있다고 할 때 리소스 A가 B에 대하여 종속성을 가진다고 하겠습니다.

JSON 템플릿 예시:

AWSTemplateFormatVersion: '2010-09-09'
...
Resources:
  A:
    Type: ...
    ...
    DependsOn: B
  B:
    Type: AWS::IAM::Policy
...

이와 같은 경우, 스택 생성 및 업데이트 시, 리소스 B가 A보다 먼저 생성 및 업데이트 됩니다.

  • 또한 스택 삭제 시에는 리소스 A가 B보다 먼저 삭제됩니다.

따라서 위와 같이 DependsOn 속성을 활용하시어 B 계정에서 스택 삭제 과정 중에 정책이 먼저 삭제되어 전체 스택에 대한 삭제 권한을 먼저 잃어 작업 중간에 문제가 발생하지 않도록 하는 방안을 긍정적으로 검토해보시길 바랍니다.

두 번째로는, 임시 권한을 부여할 IAM 정책을 생성하는 스택을 부모 스택으로, 'main' 스택을 앞의 정책에 대한 중첩 스택으로 추가하는 방법입니다.

기존의 중첩 스택 활용 방법을 유지하셔야 하는 경우에는 이와 같은 방법을 활용하실 수 있습니다.

스택 삭제와 같은 작업 시에 AWS CloudFormation에서는 이를 최대한 병렬적으로 처리하지만, 기본적으로 중첩 스택에 대하여 작업을 먼저 수행한 이후에 부모 스택 (이번 경우에는 'main' 스택)에 대하여 작업을 수행합니다.

따라서 기존에 사용하고 계신 구조와 반대로, 임시 권한을 부여할 스택을 부모 스택으로 그리고 'main' 스택을 중첩 스택으로서 구성하여 삭제를 시도하시는 경우 기존에 경험하신 상황을 최대한 방지하실 수 있을 것입니다.

기존에 존재하고 있는 스택을 중첩 스택으로서 추가하는 방법은 이와 관련된 AWS의 공식 문서 '기존 스택 중첩 [2]'를 참고하시길 바라며, AWS 콘솔 혹은 AWS CLI를 통해 이를 수행하실 수 있으니 선호하시는 방법을 통해 기존 스택을 중첩 스택으로 추가하시어 사용하는 방법을 검토해보시길 바랍니다.

이상 위와 같이 공유드린 방법들이 사용자님의 질문에 대하여 도움이 되기를 바랍니다.

혹시 사용자님의 CloudFormation 스택 자원에 대하여 보다 구체적이고 전문적인 지원을 받기를 희망하시는 경우 사용자님 계정 및 스택 자원 등에 대한 기밀 정보가 필요합니다.

따라서 AWS Premium Support의 지원을 희망하시는 경우 함께 공유드리는 링크 [3]를 통해 AWS에서 Support Case를 열어 주시길 바랍니다.

감사합니다.

곽명섭 드림

참고 자료:

[1] DependsOn 속성

https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/aws-attribute-dependson.html

[2] 기존 스택 중첩

https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/resource-import-nested-stacks.html

[3] AWS Support 콘솔 - Create a new support case

https://console.aws.amazon.com/support/home#/case/create

profile picture
전문가
답변함 일 년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠