AWS를 처음 배우는 분이라면 "인프라를 코드로 관리한다"는 말이 낯설게 느껴질 수 있습니다. 이 글에서는 CloudFormation이 무엇인지, 왜 필요한지, 그리고 어떻게 동작하는지를 쉬운 비유와 함께 설명합니다.
CloudFormation이란 무엇인가요?
집을 지을 때 설계도 없이 바로 벽돌을 쌓는 사람은 없습니다. 설계도가 있어야 어디에 방이 생기고, 어디에 문이 달리는지 미리 알 수 있고, 같은 설계도로 똑같은 집을 여러 채 지을 수 있습니다.
CloudFormation은 AWS 인프라의 설계도입니다. EC2 서버, S3 저장소, 데이터베이스, 네트워크 설정 등을 설계도(템플릿 파일)에 적어두면, CloudFormation이 그 설계도를 읽고 실제 AWS 리소스를 자동으로 만들어줍니다.
이것이 바로 IaC(Infrastructure as Code), 즉 "인프라를 코드로 관리"하는 방식입니다.
왜 이렇게 하는 걸까요? 온라인 쇼핑몰을 운영한다고 상상해보세요. 개발 환경, 테스트 환경, 실제 운영 환경을 각각 따로 구성해야 합니다. 수동으로 클릭클릭해서 만들면 시간도 오래 걸리고, 환경마다 설정이 조금씩 달라져 버그가 생길 수 있습니다. CloudFormation을 쓰면 같은 설계도로 세 환경을 완전히 동일하게 배포할 수 있습니다.
템플릿의 핵심 섹션들
CloudFormation 템플릿은 YAML 또는 JSON 형식의 파일입니다. 마치 요리 레시피처럼 여러 섹션으로 구성됩니다.
| 섹션 | 역할 | 예시 | |------|------|------| | Parameters | 배포할 때 입력받는 값 | 인스턴스 타입, 환경 이름(dev/prod) | | Mappings | 조건에 따른 값 조회 테이블 | 리전별로 다른 AMI ID | | Resources | 생성할 AWS 리소스 목록 (유일한 필수 섹션) | EC2, S3 버킷, RDS | | Outputs | 스택 생성 후 내보내는 값 | 로드 밸런서의 DNS 주소 | | Conditions | 조건에 따라 리소스를 만들지 말지 결정 | 운영 환경에서만 NAT Gateway 생성 |
레시피로 비유하면 이렇습니다. Parameters는 "몇 인분을 만들 건가요?"라는 질문, Mappings는 "나라마다 다른 재료 목록", Resources는 "실제로 요리하는 단계들", Outputs는 "완성된 요리를 어디에 담을까요", Conditions는 "파티용이면 장식을 추가하세요"입니다.
시험에서 자주 나오는 포인트: Resources 섹션만 필수이고 나머지는 모두 선택입니다. Parameters로 값을 입력받고, Mappings로 리전마다 다른 AMI ID를 선택하고, Conditions로 환경별로 다른 리소스를 만드는 패턴을 꼭 기억하세요.
Change Sets — 변경 전 미리보기
여러분이 쇼핑몰에서 물건을 살 때 "결제하기" 버튼을 누르기 전에 장바구니를 한 번 더 확인하죠? Change Sets는 AWS 인프라를 변경하기 전에 어떤 일이 일어날지 미리 보여주는 기능입니다.
이런 상황을 생각해보세요. 운영 중인 서버의 보안 그룹 규칙을 바꾸려고 CloudFormation 템플릿을 수정했습니다. 그런데 이 변경이 데이터베이스를 재시작시키는지, 아니면 그냥 설정만 바뀌는 건지 확신이 없습니다. 이럴 때 Change Set을 만들면 "이 리소스는 수정됩니다, 저 리소스는 교체됩니다, 이 리소스는 삭제됩니다"라는 목록이 나옵니다.
Change Set를 만들었다고 해서 실제로 변경이 되는 건 아닙니다. "실행(Execute)"을 눌러야 비로소 변경이 적용됩니다. 마음에 들지 않으면 그냥 삭제하면 됩니다.
시험 핵심: "인프라 업데이트 전에 영향을 미리 확인하려면?" 하면 Change Sets가 정답입니다.
Stack Policies — 중요한 리소스 보호하기
직원이 실수로 중요한 데이터베이스를 삭제하거나 변경하는 일을 막고 싶다면 어떻게 할까요? Stack Policy가 그 역할을 합니다.
Stack Policy는 "이 스택 안에서 어떤 리소스는 변경할 수 없다"는 규칙을 설정합니다. 마치 은행 금고에 이중 자물쇠를 다는 것과 같습니다. CloudFormation 스택에 Stack Policy를 설정하면, 정책에서 명시적으로 허용하지 않은 리소스는 업데이트가 차단됩니다.
중요한 특성이 있습니다. Stack Policy는 한 번 설정하면 제거할 수 없습니다. 다만, 모든 리소스 업데이트를 허용하는 빈 정책으로 교체하는 방법으로 사실상 무효화할 수는 있습니다.
시험 핵심: "특정 리소스(예: RDS 데이터베이스)를 실수로 변경하지 못하게 막으려면?" 하면 Stack Policy가 정답입니다.
드리프트 감지 (Drift Detection) — 몰래 바뀐 설정 찾기
CloudFormation으로 완벽하게 인프라를 구성했습니다. 그런데 어느 날 동료가 콘솔에 접속해서 EC2 인스턴스의 보안 그룹을 손으로 직접 수정했습니다. 이제 실제 AWS 상태와 CloudFormation 템플릿이 다릅니다. 이렇게 설계도와 실제 상태가 달라진 것을 "드리프트(drift)"라고 합니다.
드리프트는 마치 건물 도면과 실제 건물이 달라지는 것과 같습니다. 도면에는 문이 없는데 실제 건물에 문이 생긴 거죠.
Drift Detection을 실행하면 CloudFormation이 각 리소스의 현재 상태를 확인하고 템플릿과 비교합니다. 결과는 두 가지입니다. IN_SYNC는 설계도와 일치한다는 뜻이고, DRIFTED는 차이가 있다는 뜻입니다. DRIFTED가 나오면 어떤 속성이 어떻게 달라졌는지 상세 내용도 볼 수 있습니다.
시험 핵심: "콘솔에서 수동으로 변경한 내용과 CloudFormation 템플릿의 차이를 확인하려면?" 하면 Drift Detection이 정답입니다.
StackSets — 여러 계정과 리전에 한 번에 배포
회사가 성장해서 AWS 계정이 10개가 되었습니다. 모든 계정에 동일한 보안 그룹 규칙을 적용해야 합니다. 10개 계정에 각각 들어가서 배포하는 건 너무 번거롭습니다. StackSets가 이 문제를 해결합니다.
StackSets는 하나의 CloudFormation 템플릿을 여러 AWS 계정과 여러 리전에 동시에 배포하는 기능입니다. 본사에서 전국 지점에 동일한 운영 매뉴얼을 한 번에 배포하는 것과 같습니다.
동작 방식은 이렇습니다. 관리자 계정에서 StackSet을 생성합니다. 배포할 대상 계정 목록 또는 Organizations의 OU를 지정합니다. 그러면 CloudFormation이 각 계정에 스택 인스턴스를 자동으로 생성합니다. 동시에 배포할 계정 수와 실패를 몇 개까지 허용할지도 설정할 수 있습니다.
시험 핵심: "여러 계정과 여러 리전에 동일한 CloudFormation 스택을 배포하려면?" 하면 StackSets가 정답입니다.
ROLLBACK_COMPLETE 상태 이해하기
CloudFormation 스택 생성 도중 오류가 발생하면 어떻게 될까요? CloudFormation은 자동으로 롤백을 시도합니다. 이미 만들어진 리소스들을 다시 지워서 원상태로 되돌리려는 것입니다.
그런데 롤백까지 실패하면 스택은 ROLLBACK_COMPLETE 상태가 됩니다. 이 상태에서 할 수 있는 일은 딱 하나, 스택을 삭제하는 것뿐입니다. 업데이트나 재시작은 불가능합니다.
일반적인 ROLLBACK_COMPLETE 발생 원인으로는 IAM 권한 부족, 서비스 한도 초과, 잘못된 파라미터 값 등이 있습니다.
시험 핵심: "ROLLBACK_COMPLETE 상태의 스택을 복구하는 방법은?" 하면 삭제 후 오류를 수정해서 재생성이 정답입니다.
cfn-init, cfn-signal, CreationPolicy
EC2 인스턴스를 만들 때 Apache 웹 서버와 PHP를 자동으로 설치하고 싶다고 해봅시다. 그리고 설치가 완료되기 전까지 CloudFormation이 "스택 생성 완료"라고 표시하지 않기를 원합니다.
cfn-init은 CloudFormation 템플릿의 메타데이터 섹션에 설치할 패키지, 만들 파일, 시작할 서비스를 정의해두면 EC2 인스턴스가 시작될 때 자동으로 그 작업들을 수행합니다.
cfn-signal은 설치가 완료되면 CloudFormation에 "작업 완료"라는 신호를 보내는 명령입니다. 설치 스크립트 마지막에 이 명령을 넣어두면 됩니다.
CreationPolicy는 CloudFormation에게 "신호를 받을 때까지 기다려"라고 알려주는 설정입니다. 타임아웃도 설정할 수 있습니다. 타임아웃 안에 신호가 오지 않으면 스택 생성이 실패로 처리됩니다.
이 세 가지는 세트로 함께 사용합니다. cfn-init으로 설치하고, 완료되면 cfn-signal로 알리고, CreationPolicy로 기다리는 구조입니다.
Nested Stacks와 AWS CDK
쇼핑몰 인프라를 하나의 거대한 CloudFormation 템플릿에 전부 넣으면 관리가 어려워집니다. Nested Stacks는 이 문제를 해결합니다.
Nested Stacks는 큰 템플릿을 여러 개의 작은 템플릿으로 나누는 방식입니다. 예를 들어 네트워크 스택, 보안 스택, 서버 스택, 데이터베이스 스택을 각각 만들고 부모 스택에서 이들을 조합합니다. 각 스택은 재사용이 가능해서 다른 프로젝트에서도 같은 네트워크 스택을 가져다 쓸 수 있습니다.
AWS CDK(Cloud Development Kit)는 조금 다른 접근입니다. CloudFormation 템플릿을 YAML이나 JSON으로 직접 작성하는 대신, Python이나 TypeScript 같은 프로그래밍 언어로 인프라를 정의합니다. 코드를 실행하면 CloudFormation 템플릿이 자동으로 생성됩니다. 개발자들이 익숙한 언어로 인프라를 관리할 수 있어 생산성이 높아집니다.
시험 핵심 정리
"업데이트 전에 변경 영향을 미리 확인하고 싶다" -- Change Sets
"콘솔에서 수동 변경한 부분과 템플릿의 차이를 확인하고 싶다" -- Drift Detection
"여러 계정과 리전에 같은 스택을 동시 배포하고 싶다" -- StackSets