읽기 전용 AWS/Azure 위생 스캐너를 만들었습니다 (자동 삭제는 위험하기 때문에)

Source: Dev.to

문제

현대 클라우드 환경은 복잡합니다:

• 팀이 지속적으로 리소스를 생성함
• 배포 과정에서 인프라를 만들고 파괴함
• 인스턴스가 종료될 때 리소스가 고아가 됨
• 무엇을 삭제해도 안전한지 아무도 모름

대부분의 클라우드‑위생 도구는 두 가지 진영으로 나뉩니다:

모두 자동 삭제 → 프로덕션에 너무 위험함
모두 플래그 지정 → 너무 시끄러워서 실용적이지 않음

다음과 같은 상황에서는 두 접근 방식 모두 실패합니다:

• 탄력적인 인프라(자동 스케일링, 스팟 인스턴스)
• 서로 다른 소유권을 가진 여러 팀
• 사용되지 않은 것처럼 보이지만 실제로는 중요한 리소스

자동 삭제가 실패하는 이유

나는 이것을 힘들게 배웠다.

우리가 시도한 “스마트” 정리 도구:

1. 7일 동안 연결이 없는 데이터베이스를 발견함
2. 고아 데이터베이스라고 가정함
3. 자동으로 삭제함
4. 실제로는 분기별 보고용 데이터베이스였음을 발견함

그 실수의 비용: 복구에 3일, 화난 CFO, 자동화에 대한 신뢰 상실.

잘못된 리소스를 삭제했을 때의 파급 효과는 몇 주 더 실행해 두는 것보다 수십 배 더 크다.

CleanCloud의 접근 방식: 신호 우선, 행동 나중

자동 정리 대신, CleanCloud는 더 안전한 질문에 답합니다:

“어떤 리소스를 인간이 검토해야 하며, 그에 대한 신뢰도는 어느 정도인가?”

핵심 원칙

1. 항상 읽기 전용

   // Required AWS permissions – notice no Delete* or Modify*
   {
     "Action": [
       "ec2:DescribeVolumes",
       "ec2:DescribeSnapshots",
       "logs:DescribeLogGroups",
       "s3:ListAllMyBuckets"
     ]
   }

   쓰기 권한은 없습니다. 절대. 프로덕션에서 안전하게 실행할 수 있습니다.

2. 보수적인 신호

   단순히 “연결이 끊겼나요?”가 아니라:

   • 얼마나 오래 연결이 끊겼는가? (14 일 이상 = 높은 신뢰도)
   • 여러 신호가 필요함 (연령 + 상태 + 태그)
   • 명시적인 신뢰도 수준: LOW, MEDIUM, HIGH

   예시:

   🔴 HIGH confidence:   Volume unattached for 45 days
   🟡 MEDIUM confidence: Volume unattached for 10 days
   🟢 LOW confidence:    Volume unattached for 3 days (probably autoscaling)

3. 검토 전용 권고

   CleanCloud는 절대 “삭제하세요”라고 하지 않습니다. 대신 이렇게 말합니다:

   “이 볼륨은 45 일 동안 연결이 끊겨 있었고, 태그가 없으며, 알려진 배포 패턴과 일치하지 않습니다. 검토할 가치가 있습니다.”

   최종 결정은 인간이 내립니다.

감지 항목

AWS 규칙 (현재 4개)

• 연결되지 않은 EBS 볼륨 (14 + days = HIGH)
• 오래된 스냅샷 (365 + days = HIGH)
• 무한 보존 기간을 가진 CloudWatch 로그 (30 + days = HIGH)
• 태그가 없는 리소스 (ownership unclear = MEDIUM)

Azure 규칙 (현재 4개)

• 연결되지 않은 관리형 디스크 (14 + days = HIGH)
• 오래된 스냅샷 (90 + days = HIGH)
• 사용되지 않는 공용 IP (immediate = HIGH)
• 태그가 없는 리소스 (MEDIUM)

1주 차 결과

지난 주에 릴리스되었습니다. 일어난 일은 다음과 같습니다:

통계

• 300 + 다운로드 (≈170명의 실제 사용자, 나머지는 PyPI 미러)
• 0 프로덕션 사고 (읽기 전용이기 때문)
• 가장 흔한 발견: AWS 계정당 15‑30개의 연결되지 않은 EBS 볼륨

사용자 피드백 주제

• “드디어 프로덕션에서 신뢰할 수 있는 도구를 찾았어요”
• “첫 스캔에서 월 $2K의 낭비를 발견했어요”
• “무언가가 표시된 WHY를 설명해 주는 점이 마음에 들어요”

빠른 시작

# Install
pip install cleancloud

# Validate credentials
cleancloud doctor --provider aws

# Scan a single region
cleancloud scan --provider aws --region us-east-1

# Scan all active regions
cleancloud scan --provider aws --all-regions

# Output to JSON
cleancloud scan \
  --provider aws \
  --all-regions \
  --output json \
  --output-file results.json

빠른 시작 (Azure)

- name: Set up Azure credentials
  uses: azure/login@v1
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- name: Scan
  run: cleancloud scan --provider azure

AWS_SECRET_ACCESS_KEY 또는 AZURE_CLIENT_SECRET가 필요 없습니다. ✅

$ cleancloud scan --provider aws --region us-east-1

🔍 Scanning region us-east-1

Found 12 findings:
  HIGH confidence:   8
  MEDIUM confidence: 4

Top findings:
  • vol-0abc123 – Unattached volume (45 days, 100 GB) – ~$10/mo
  • snap-0def456 – Old snapshot (120 days, 500 GB) – ~$25/mo
  • log-group-xyz – Infinite retention (2.1 GB stored) – ~$6/mo

💰 Estimated monthly waste: ~$156

Review findings and decide what to delete.

CI/CD 통합

예측 가능한 종료 코드를 가진 파이프라인을 위해 구축되었습니다:

# GitHub Actions example
- name: Run hygiene scan
  run: |
    pip install cleancloud
    cleancloud scan \
      --provider aws \
      --all-regions \
      --fail-on-confidence HIGH

종료 코드

사용 사례

• 높은 신뢰도 발견이 있는 PR 차단
• 주간 위생 보고서 생성
• 태깅 표준 적용
• 개발 단계에서 리소스 누수 방지

인증: OIDC 우선

오래 지속되는 자격 증명이 필요 없습니다.

AWS (GitHub Actions)

- name: Configure AWS credentials (OIDC)
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::ACCOUNT:role/CleanCloudReadOnly
    aws-region: us-east-1

- name: Scan
  run: cleancloud scan --provider aws

Azure (GitHub Actions)

- name: Azure Login (OIDC)
  uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- name: Scan
  run: cleancloud scan --provider azure

CleanCloud 이(가) 아닌 것

비용 최적화 도구가 아님

• 청구 데이터를 접근하지 않음
• 적정 규모 권장을 하지 않음
• 절감이 아니라 위생에 초점을 맞춤

FinOps 플랫폼이 아님

• 대시보드 없음
• 비용 추적 없음

자동 복구 서비스가 아님

• 절대 어떤 것도 삭제하지 않음
• 절대 리소스를 수정하지 않음
• 절대 리소스에 태그를 붙이지 않음

이것은 전략적 설계 선택이며, 제한이 아닙니다.

개인정보 및 텔레메트리

CleanCloud는 텔레메트리를 전혀 수집하지 않습니다.
분석 없음. 추적 없음. 전화 회신 없음.

왜?

• 보안 도구는 데이터를 어디에도 전송해서는 안 됩니다
• 격리된 환경에서도 작동합니다
• 옵트아웃 플래그가 필요 없습니다
• 계정 정보 유출 위험이 전혀 없습니다

개선은 다음을 통해 이루어집니다:

• GitHub 이슈
• 직접 피드백
• 커뮤니티 기여

다음 단계

v0.3.1 (방금 출시)

• 문서 전면 개편
• 더 똑똑한 AWS 지역 자동 감지
• 보안 등급을 포함한 향상된 진단
• 지역 감지 버그 수정

곧 출시 예정

• GCP 지원
• 추가 규칙(사용되지 않은 Elastic IP, 오래된 AMI)
• 규칙 필터링(--rules 플래그)
• 이력 추적

계획되지 않음

• 자동 정리
• 비용 최적화
• 청구 데이터 접근

CleanCloud는 자동화가 아닌 안전한 위생 감지에 집중할 것입니다.

설계 철학

1. 기본적으로 보수적

   • 연령 기반 신뢰 임계값
   • 다중 신호 필요
   • 위양성보다 위음성을 선호

2. 항상 읽기 전용

   • Delete* 권한 없음
   • Tag* 권한 없음
   • 수정 API 없음

3. 검토 전용 권고

   • 발견 사항은 자동 조치가 아니라 검토 후보
   • 각 발견에 대한 명확한 근거
   • 인간이 제어 유지

대상은 누구인가?

주요 사용자

• SRE 팀
• 플랫폼 엔지니어
• 인프라 팀

이해관계자

• 보안 (읽기 전용 = 보안 검토 통과)
• 컴플라이언스 (SOC2/ISO27001 친화적)
• FinOps (공격적인 최적화 없이 낭비를 식별)

대상이 아닌 경우

• 자동 정리를 원하는 팀
• 비용 최적화를 주요 목표로 하는 경우
• 공격적인 절감 권고

실제 이야기: 내가 이것을 만든 이유

나는 너무 많은 “똑똑한” 자동화 도구가 장애를 일으키는 것을 보았다:

• 트래픽 급증 중에 0으로 스케일 다운된 자동 스케일러
• “사용되지 않음” 보안 그룹을 삭제한 정리 도구(프로덕션 중단)
• 데이터베이스를 축소한 비용 최적화 도구(성능 재앙)

패턴: 자동화는 자신감이 있다. 인간은 신중하다. 프로덕션은 신중함을 요구한다.

CleanCloud는 자동화보다 신뢰를 중시하는 팀을 위해 설계되었습니다.

Try It

피드백을 찾아서

• 현재 어떤 클라우드 위생 도구를 사용하고 계신가요?
• 읽기 전용 시그널이 팀에 도움이 될까요?
• 어떤 기능이 있으면 이 제품을 바로 사용하실 수 있을까요?

오픈 소스, MIT 라이선스. 기여를 환영합니다!

이 내용이 도움이 되었다면

• ⭐ 레포지토리에 스타를 달아 주세요
• 💬 댓글에 여러분의 클라우드 위생 공포 이야기를 공유해 주세요
• 🐛 이슈를 보고하거나 기능을 제안해 주세요

신뢰를 자동화보다 중시하는 SRE 팀을 위해 제작되었습니다.