AWS Certified CloudOps Engineer - Associate (SOA-C03) #7 Domain 3-1 배포: CloudFormation 깊이와 IaC
#6까지 신뢰성 도메인을 마쳤습니다. 세 번째 도메인은 배포,프로비저닝,자동화(22%)이며, 그 중심에 IaC(Infrastructure as Code)가 있습니다. 운영에서 IaC가 중요한 이유는 단순합니다. 콘솔에서 손으로 만든 환경은 재현되지 않고, 누가 무엇을 바꿨는지 추적되지 않습니다. CloudFormation은 AWS의 기본 IaC 도구로, 인프라를 템플릿(코드)으로 선언하고 그 상태를 관리합니다.
스택과 템플릿 #
| 개념 | 설명 |
|---|---|
| Template | 만들 자원을 선언한 JSON,YAML 파일 |
| Stack | 템플릿으로 생성,관리되는 자원의 묶음(배포 단위) |
| Resource | 스택이 만드는 개별 자원(EC2,S3,RDS 등) |
스택을 지우면 그 스택이 만든 자원이 함께 정리됩니다. 이것이 손으로 만든 환경과의 결정적 차이입니다. 생성,갱신,삭제가 한 단위로 관리됩니다.
템플릿의 주요 섹션 #
| 섹션 | 역할 |
|---|---|
| Parameters | 배포 시 입력값(환경,인스턴스 타입 등) |
| Mappings | 키로 값을 찾는 정적 표(리전별 AMI 등) |
| Conditions | 조건에 따라 자원 생성 여부 결정 |
| Resources | 실제 만들 자원(유일한 필수 섹션) |
| Outputs | 생성 결과 내보내기(다른 스택이 참조) |
Parameters로 환경 차이를 흡수하고, Outputs와 교차 스택 참조(Export/ImportValue)로 스택을 나눠 조립합니다. “VPC 스택과 애플리케이션 스택을 분리하고 연결하라"는 답이 Outputs export + ImportValue입니다.
변경 집합(Change Set)과 드리프트 #
운영에서 가장 중요한 두 기능입니다.
변경 집합 #
스택을 갱신하기 전에 무엇이 바뀌는지 미리 보는 기능입니다. 특히 일부 변경은 자원을 교체(replacement)해 다운타임이나 데이터 손실을 부릅니다(예: RDS의 특정 속성 변경). 변경 집합으로 교체 여부를 확인한 뒤 적용하는 것이 안전한 운영입니다. “프로덕션 스택을 갱신하는데 영향 범위를 미리 확인하라"는 답이 변경 집합입니다.
드리프트 탐지(Drift Detection) #
스택이 만든 자원을 누군가 콘솔에서 직접 바꾸면, 실제 상태가 템플릿과 어긋납니다. 이것이 드리프트입니다. 드리프트 탐지는 템플릿과 실제 자원을 비교해 어긋난 자원과 속성을 보고합니다. “IaC로 만든 환경인데 누가 손으로 바꿨는지 찾아라"는 답이 드리프트 탐지입니다.
스택 보호 장치 #
| 장치 | 역할 |
|---|---|
| Stack Policy | 갱신 중 특정 자원을 변경,교체로부터 보호 |
| Termination Protection | 스택 자체의 실수 삭제 방지 |
| DeletionPolicy(Retain) | 스택을 지워도 특정 자원(DB,S3)은 남김 |
| Rollback | 갱신,생성 실패 시 이전 상태로 자동 복귀 |
운영 단골은 DeletionPolicy: Retain입니다. 스택을 지우더라도 데이터베이스나 S3 버킷은 함께 사라지면 안 되므로, 그 자원에 Retain을 걸어 보존합니다.
StackSets: 여러 계정,리전 배포 #
하나의 템플릿을 여러 계정과 여러 리전에 한 번에 배포,관리하는 기능입니다.
- Organizations와 연동해 새 계정에 자동으로 표준 스택 배포
- 보안 기준선(IAM 역할,로깅,Config)을 전 계정에 일괄 적용
- 한 곳에서 갱신하면 전 대상에 전파
“조직의 모든 계정에 표준 보안 설정을 일관되게 깔고, 새 계정에도 자동 적용하라"는 답이 StackSets(+ Organizations)입니다.
다른 IaC 도구: CDK,Terraform #
SOA-C03은 CloudFormation 외 도구도 범위에 넣었습니다. 관계를 정리하면 다음과 같습니다.
| 도구 | 성격 |
|---|---|
| CloudFormation | AWS 네이티브. 선언형 템플릿(JSON,YAML) |
| CDK | 프로그래밍 언어(TypeScript,Python 등)로 작성 → CloudFormation으로 합성되어 배포 |
| Terraform | 서드파티(HashiCorp). 멀티 클라우드. 자체 상태 파일(state) 관리 |
| SAM | 서버리스 특화. CloudFormation의 확장 |
핵심 구분은 CDK는 결국 CloudFormation으로 변환되어 배포된다는 점, Terraform은 AWS 밖 리소스까지 다루며 상태를 자체 파일로 관리한다는 점입니다. “개발 언어로 인프라를 작성하되 AWS 네이티브 배포를 쓰고 싶다"는 CDK, “여러 클라우드를 한 도구로 관리"는 Terraform이 맞습니다.
시험 출제 패턴 #
- 스택 갱신 전 영향 확인 → 변경 집합(Change Set)
- IaC 환경의 수동 변경 추적 → 드리프트 탐지
- 스택 삭제 시 DB,S3 보존 → DeletionPolicy: Retain
- 갱신 중 특정 자원 보호 → Stack Policy
- 전 계정,리전에 표준 배포 → StackSets + Organizations
- 스택 분리,연결 → Outputs Export + ImportValue
- 개발 언어로 IaC 작성, AWS 네이티브 배포 → CDK
자주 만나는 함정 #
1) 갱신이 항상 무중단이라고 생각 #
일부 속성 변경은 자원을 교체합니다. 변경 집합으로 교체 여부를 미리 봐야 합니다.
2) 드리프트를 CloudFormation이 자동으로 막는다고 오해 #
CloudFormation은 드리프트를 탐지,보고할 뿐, 콘솔의 수동 변경 자체를 막지는 않습니다. 변경을 막으려면 IAM 권한으로 직접 수정을 제한합니다.
3) StackSets 없이 계정마다 스택을 따로 만든다 #
수십 계정에 같은 스택을 손으로 배포하는 답안은 운영 부담 최소화 조건에서 오답입니다. StackSets가 정석입니다.
4) CDK가 별도 런타임이라고 생각 #
CDK는 합성 단계에서 CloudFormation 템플릿을 생성합니다. 배포,드리프트,롤백은 CloudFormation의 것을 그대로 씁니다.
정리 #
이번 글에서 잡은 것:
- CloudFormation은 인프라를 템플릿(코드)으로 선언하고 스택 단위로 생성,갱신,삭제
- 변경 집합으로 갱신 영향(특히 자원 교체) 사전 확인, 드리프트 탐지로 수동 변경 추적
- DeletionPolicy: Retain으로 스택 삭제 시 DB,S3 보존. Stack Policy,Termination Protection으로 보호
- StackSets + Organizations로 여러 계정,리전에 표준 일괄 배포
- CDK는 CloudFormation으로 합성, Terraform은 멀티 클라우드 + 자체 상태
다음: Domain 3-2 Systems Manager #
인프라를 코드로 배포하는 법을 잡았으니, 다음은 배포된 인스턴스를 운영,관리하는 도구입니다.
#8 Domain 3-2 배포: Systems Manager 운영 자동화에서는 Parameter Store로 설정을 관리하는 법, Patch Manager로 패치를 일괄 적용하는 법, State Manager로 원하는 상태를 유지하는 법, Session Manager로 키 없이 접속하는 법, 그리고 Run Command와 Automation까지 묶어 정리하겠습니다.