AWS 리소스 삭제 전에 영향 확인하기
2025.07.08안녕하세요 클래스메소드의 이수재입니다.
AWS에서 리소스를 생성한 후 필요없어지거나 비용 적인 문제로 삭제해야 하는 경우가 많이 있습니다.
의존 관계가 확실히 있는 서비스(EC2와 루트 볼륨 등)는 어느 한 서비스를 삭제하기 전에 다른 한쪽의 서비스를 먼저 삭제해야한다고 경고가 표시되지만, 선행이 필수가 아닌 리소스들도 많습니다.
이런 의존관계는 CloudFormation으로 모든 리소스를 생성했다면 그나마 확인하고 관리하기 쉽지만 콘솔에서 직접 만들거나 따로따로 생성한 경우에는 이를 한눈에 파악하는 것은 쉽지 않습니다.
이 글에서는 리소스간의 상관관계를 확인하고, 특정 리소스를 삭제하기 전에 영향을 확인하는 방법에 대하여 알아봅니다.
AWS 서비스 활용하기
"리소스 간의 관계"를 명확하게 명시하는 서비스로는 아래 서비스를 고려해볼 수 있습니다.
- AWS Config
- AWS Resource Explorer
조건에 따라서 다음 기능 및 서비스를 활용하여 리소스 관계를 파악할 수 있습니다.
- CloudFormation으로 리소스를 생성한 경우
- AWS CloudFromation 드리프트 감지 및 종속성 확인
- 애플리케이션 레벨의 종속성 확인이 필요한 경우
- AWS Systems Manager Inventory
- AWS Service Catalog AppRegistry
AWS 리소스 간의 관계 확인하기
리소스 간의 관계를 보여주는 서비스에 대해 먼저 알아보겠습니다.
AWS Config
AWS Config 자체는 리소스의 자세한 보기를 제공하고 관리하는데 사용하는 서비스입니다.
기능의 일환으로 AWS Config을 사용하여 리소스 구성과 리소스 간의 관계를 추적할 수 있습니다.
예로 들면 Config에서 특정 EC2에 연결된 EIP의 구성 항목의 JSON을 보면 다음과 같은 내용을 확인할 수 있습니다.
...
...
"relationships": [
{
"relationshipName": "Is attached to Instance",
"resourceId": "i-0cb32563b9732f292",
"resourceType": "AWS::EC2::Instance"
},
{
"relationshipName": "Is attached to NetworkInterface",
"resourceId": "eni-06a882d2ab244da44",
"resourceType": "AWS::EC2::NetworkInterface"
}
],
...
...
리소스 정보나 타임라인에서 관계를 확인할 수 있으며, 쿼리를 실행하여 특정한 관계를 확인하는 것도 가능합니다.
이런 기능들을 이용하여 특정 리소스의 삭제로 인한 영향을 사전에 파악할 수 있습니다.
결과는 시각화할 수 있기 때문에 이해하는데 도움을 줍니다.
장점 으로는 위에서 말한 리소스의 관계를 시각적으로 확인할 수 있다는 점이나 리소스의 기록을 확인할 수 있다는 점입니다.
단점 으로는 Config을 미리 활성화해야 한다는 점과 활성화 전의 기록은 표시하지 않는다는 점입니다. Config을 활성화 하는 것으로 비용이 발생합니다.
서비스를 사용하는데 있어 주의 사항 으로는 만약 AWS 환경의 추적이나 관계 확인 등이 필요하다면 환경을 구성하기 전에 Config을 우선 활성화 할 필요가 있습니다.
또한 직접적인 종속은 확인이 가능하지만 간접적인 종속은 확인할 수 없습니다.
그리고 모든 리전에서 리전 간 종속성도 설정해야 합니다.
비용 은 서울 리전 기준으로 구성 항목 당 비용[1]으로 연속적 기록은 USD 0.003, 주기적 기록은 USD 0.012 입니다.
그리고 첫 100,000개의 규칙 평가까지 리전별 규칙 평가당 USD 0.001 가 발생합니다.
자세한 내용은 공식 문서를 참고해주세요.
AWS Resource Explorer
AWS Resource Explorer 자체는 이름, 태그 및 ID와 같은 메타데이터를 사용하여 여러 리전의 계정에 있는 AWS 리소스를 검색할 수 있는 서비스입니다.
사용하기 위해서는 우선 대상으로 하는 리전에서 서비스를 활성화해야합니다.
대상으로하는 리소스를 선택하는 보기(view)를 생성하면 선택한 조건에 부합하는 리소스를 확인할 수 있습니다.
예로 들면 다음과 같은 보기에서 대상으로 하는 태그나 리소스 종류, 리전 등을 선택하고
리소스를 살펴보면 필터에 부합하는 리소스들을 확인할 수 있습니다.
확인하고자 하는 리소스를 선택하면 리소스의 상세한 내용(Config 규정 준수, 타임라인, 관계 등)을 확인할 수 있습니다.
장점 으로는 모든 리전에서 빠르고 색인된 검색을 활용할 수 있으며, 리소스 메타데이터 및 태그 표시가 Config 보다 훨씬 보기 좋게 되어 있습니다.
또한 매우 직관적이고 간단한 설정으로 바로 활용할 수 있습니다.
무료 티어도 사용 가능한 것도 큰 장점입니다.
단점 으로는 Config에 비해 제한된 관계 매핑을 제공하기 때문에 서비스에서 제공하는 것 이상의 관계를 파악하기는 쉽지 않습니다.
또한 초기 활성화 후 기존 리소스의 인덱싱 시간이나 새 리소스의 인덱싱 시간이 조금 걸립니다.
주의사항 이라고 할 건 특히 없지만 처음 소개했듯 검색하려는 각 리전에서 활성화되어야 합니다.
그리고 단점에서 설명한 인덱스 업데이트가 약간 지연될 수 있다는 점, 복잡한 관계 확인이 아닌 서비스의 목적인 리소스 검색에 국한된다는 점 정도라고 생각합니다.
비용 은 발생하지 않는 서비스입니다.
조건적으로 리소스 관계 확인하기
조건에 따라 리소스 간의 관계를 확인할 수 있는 방법에 대하여 알아보겠습니다.
AWS CloudFromation 드리프트 감지 및 종속성 확인
CloudFormation을 사용하여 리소스를 생성한 경우 드리프트 감지 및 스택 종속성 기능을 사용하여 관계를 이해할 수 있습니다.
스택에서 드리프트 감지 작업을 수행하면 스택이 예정 템플릿 구성에서 드리프트되었는지 확인하고, 드리프트 감지를 지원하는 스택의 각 리소스에 대한 드리프트 상태 관련 세부 정보를 반환합니다.
사용 방법은 간단합니다.
변경되었는지 확인하고 싶은 스택을 선택한 후 이미지와 같이 드리프트 감지를 클릭하면 현재 기록된 스택의 내용과 실제 리소스의 내용이 어떤 차이점이 있는지를 검출합니다.
이를 통해서 스택으로 작성한 리소스가 향후 어떤 변화가 있었는지 감지하고 이를 스택에 반영하여, 스택을 기반으로한 리소스 관리를 유지할 수 있습니다.
CloudFormation은 스택의 리소스 간 종속성을 자동으로 관리하기 때문에 리소스를 수동으로 변경한 후라도 드리프트 감지를 통하여 스택 기반 리소스 관리를 유지할 수 있다면 특정 리소스의 삭제나 변경으로 인해 스택에 주는 영향을 최소화 할 수 있습니다.
장점 으로는 스택으로 일관된 관리를 유지할 수 있기 때문에 스택 내에서 명확한 종속성을 확인하고 관리할 수 있습니다.
단점 으로는 CloudFormation 으로 리소스를 작성하는 것이 전제(즉, 스택으로 리소스를 관리한다는 점)라는 점, 일부 리소스는 드리프트 감지를 지원하지 않는다는 점이 있습니다.
주의 사항 으로는 드리프트 감지 자체는 자동으로 실행되지 않습니다. 따라서 주기적으로 자동으로 실행하도록 다른 서비스를 이용하여 주기적으로 이를 실행하도록 설정하거나 수동으로 한번씩 실행해주어야 합니다.
비용 은 따로 발생하지 않는 기능입니다.[2]
애플리케이션 레벨의 종속성 확인이 필요한 경우
AWS Systems Manager Inventory 를 사용하거나 AWS Service Catalog AppRegistry 를 사용하여 애플리케이션의 종속성을 AWS 서비스에서 확인할 수 있습니다.
Inventory 는 인스턴스와 설치된 소프트웨어에 대한 메타데이터를 수집하여 애플리케이션 수준의 종속성을 이해하는 데 도움을 줍니다.
ssm agent가 설치되어 있는 인스턴스만을 대상으로 하기 때문에 사전 준비가 필요합니다.
OS나 애플리케이션에 대해 자세한 정보를 AWS 상에서도 확인할 수 있도록 제공하는 점, 수집한 정보를 AWS Config와 통합할 수 있다는 점 등은 장점이지만 주로 EC2 인스턴스에 중점을 두는 기능이라는 한계가 있습니다.
App Registry 는 애플리케이션을 정의하고 관리하는 데 도움이 되며, 어떤 리소스가 어떤 애플리케이션에 속하는지 보여줍니다.
애플리케이션 중심의 리소스 보기나 태그 기반 자동 리소스 연결 등의 기능을 제공하기에 이를 활용할 수 있다면 장점으로 활용이 가능하지만 일관된 태깅 전략이 있어야 효율적으로 기능을 사용할 수 있다는 점은 도입 전에 고려해보아야 합니다.
그래서 어떤 식으로 활용할까?
위의 내용들을 종합하여 생각해보면 다음과 같은 방식으로 관계를 파악하고, 영향을 분석하여, 관리를 하는 것이 좋다고 생각합니다.
우선 인프라 종속성을 위해 AWS Config을 사용합니다.
그리고 리소스를 작성하거나 변경할 때는 일관된 태깅 규칙으로 태그를 지정합니다.
만약 리소스 삭제 전 영향을 확인하고자 한다면 Config의 relationship 이나 태그를 기반으로 리소스 탐색기에서 리소스를 검색하여 영향을 확인합니다.
애플리케이션 수준의 관계(종속성) 확인이 필요하다면 Systems Manager Inventory나 Service Catalog AppRegistry 의 도입을 검토합니다.
IaC로 환경을 구성한 경우 CloudFormation의 드리프트 감지를 주기적으로 실행하여 스택 기반 관리를 항상 유지하는 것이 좋습니다.
마무리
위에서 설명한 기능이나 서비스로는 부족한 경우가 있습니다.
만약 Terraform 등의 IaC 도구로 환경을 구성하였다면 자체적으로 종속성 등을 확인할 수 있는 기능을 제공하는 경우가 많기 때문에 찾아보시는 것을 추천합니다.
이 외의 경우에는 CloudHealth, Cloudability 등 클라우드 관리를 위한 기능을 제공하는 서비스 등이 있으므로 찾아보시는 것을 권장합니다.
긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.
문의 사항은 클래스메소드 코리아로!
클래스메소드 코리아에서는 다양한 세미나 및 이벤트를 진행하고 있습니다.
진행중인 이벤트에 대해 아래 페이지를 참고해주세요.
AWS에 대한 상담 및 클래스 메소드 멤버스에 관한 문의사항은 아래 메일로 연락주시면 감사드립니다!
Info@classmethod.kr
