반응형
1️⃣ CloudFormation Stack Policy
항목설명
| 적용 대상 | 하나의 스택 내부 리소스 |
| 목적 | 스택 내 특정 리소스(예: 데이터베이스, 보안 그룹 등)가 수정/삭제되지 않도록 보호 |
| 예시 용도 | “DB 인스턴스는 스택 업데이트 시 절대 교체하지 마라” |
| 형태 | JSON 정책으로, 리소스별로 Allow/Deny 업데이트 정의 |
| 범위 | 단일 스택 수준 (조직 전체 적용 불가) |
| 주요 한계 | 잘못된 리소스 생성/구성 자체를 “사전 방지”하지는 못함. 이미 배포된 스택 내 보호만 수행 |
| 예시 | { "Statement": [ { "Effect": "Deny", "Action": "Update:*", "Principal": "*", "Resource": "LogicalResourceId/MyDatabase" } ] } |
2️⃣ AWS Service Catalog
항목설명
| 적용 대상 | 조직/계정 전반의 CloudFormation 템플릿 묶음(포트폴리오) |
| 목적 | 승인된 IaC 패턴만을 사용자나 팀이 배포하도록 거버넌스(승인형 셀프서비스) 제공 |
| 예시 용도 | “모든 팀은 오직 이 VPC 템플릿이나 이 S3 정책 패턴만 배포 가능” |
| 형태 | CloudFormation 템플릿들을 ‘제품(product)’ 단위로 묶고 포트폴리오로 배포 |
| 범위 | AWS Organizations 전역 적용 가능 |
| 주요 장점 | - 승인된 아키텍처 패턴 강제 |
✅ 즉, Service Catalog는 “조직 전반의 승인된 IaC만 배포 가능하게 하는 중앙 관리 플랫폼” 입니다.
Stack Policy는 그 반대로, “한 번 배포된 특정 스택의 일부 리소스만 보호”하는 미시적 도구입니다.
🧠 비유로 정리
항목비유
| Stack Policy | 이미 만들어진 건물(스택) 안에서 “이 벽은 건드리지 마라” |
| Service Catalog | “우리 회사는 이런 구조의 건물만 지을 수 있다” (표준 설계도 강제) |
반응형
'퍼블릭 클라우드 관련 > AWS' 카테고리의 다른 글
| IAM 역할 내부 구조 (0) | 2025.10.18 |
|---|---|
| Verified Access vs Verified Permissions 차이 (0) | 2025.10.17 |
| ECR 기본 스캐닝 vs Amazon Inspector 통합 스캐닝 비교 (0) | 2025.10.14 |
| AWS IAM 핵심 용어 비교표 (0) | 2025.10.11 |
| DNSSEC 신뢰 체인 원리 (0) | 2025.10.07 |