7. CloudFormation

1. Overview

 

개요 및 배경

• 코드를 통해 AWS 인프라 리소스를 프로비저닝하고 관리하는 IaC (Infrastructure as Code) 서비스임
• 인프라 구성을 선언적(Declarative)으로 작성하면, 내부적으로 생성 순서와 구성을 자동 조율하여 리소스를 생성함
• 수동 작업을 제거하여 인프라의 버전 관리(Git 등 연동), 재현성 향상, 자동화된 인프라 파기/생성을 통한 비용 절감을 가능하게 함

주요 리소스 및 기능

1. 스택 (Stack) 동작 방식
   • 템플릿 파일(YAML/JSON)을 Amazon S3에 업로드한 후 CloudFormation이 이를 참조하여 스택(Stack)을 생성함
   • 인프라 변경이 필요할 경우 기존 템플릿을 덮어쓰는 것이 아니라, 새로운 버전의 템플릿을 업로드하여 스택을 업데이트해야 함
   • 스택을 삭제하면 해당 스택을 통해 생성되었던 모든 연결된 AWS 리소스가 일괄 삭제됨
2. 배포 및 관리 방식
   • 수동 배포: AWS Infrastructure Composer나 콘솔을 사용하여 템플릿 파라미터를 직접 입력하고 스택을 관리함
   • 자동 배포: AWS CLI나 CI/CD 파이프라인 도구(CodePipeline 등)를 연동하여 완전 자동화된 인프라 배포 워크플로우를 구현함
3. 템플릿 핵심 구성 요소 (Building Blocks)
   • Resources: 템플릿에서 유일하게 필수(Mandatory)인 섹션으로, 생성할 AWS 리소스(EC2, S3 등)를 선언함
   • Parameters: 템플릿 실행(스택 생성/업데이트) 시 외부에서 동적으로 주입받는 입력값임
   • Mappings: 템플릿 내부에 사전 정의된 정적 변수 매핑 테이블임
   • Outputs: 스택 생성 완료 후 생성된 리소스의 속성값(예: IP, URL)을 외부에서 참조할 수 있도록 내보냄
   • Conditions: 환경(Dev, Prod 등)에 따라 특정 리소스의 생성 여부를 제어하는 논리적 조건임

헷갈리는 포인트 (Tips)

• CloudFormation 템플릿을 작성할 때 Parameters나 Outputs는 선택 사항이지만, Resources 섹션은 반드시 하나 이상 포함되어야 템플릿 유효성 검사를 통과함
• 스택 생성 시 사용되는 모든 템플릿 원본 파일은 CloudFormation 서비스 자체가 아니라 백엔드의 Amazon S3 버킷에 저장되고 참조됨을 명확히 인지해야 함
• 대규모 아키텍처 구성 시, 하나의 거대한 템플릿을 만드는 대신 네트워크 계층(VPC 등)과 애플리케이션 계층 스택을 분리(Separation of Concerns)하여 관리하는 것이 모범 사례임

---

2. User Data

 

개요 및 배경

• EC2 인스턴스 최초 시작 시 실행할 초기화 스크립트(User Data)를 CloudFormation 템플릿 내에서 정의하여 인프라 프로비저닝과 OS 환경 설정을 동시 처리함
• 스크립트를 통해 웹 서버(HTTPD) 설치, 데몬 실행, 인덱스 파일 생성 등의 부트스트래핑(Bootstrapping) 작업을 자동화함

주요 리소스 및 기능

1. User Data 스크립트 인코딩
   • CloudFormation 템플릿을 통해 User Data를 전달할 때는 반드시 Base64 내장 함수(Fn::Base64 또는 !Base64)를 사용하여 스크립트를 인코딩해야 함
   • YAML 문법 적용 시, 여러 줄의 쉘 스크립트 문자열을 안전하게 전달하기 위해 파이프 기호(|)를 활용하여 다중 라인(Multi-line) 문자열 블록을 선언함
2. cloud-init 로그 확인 (트러블슈팅)
   • 인스턴스 접속 후 User Data 스크립트의 실제 실행 결과, 출력된 메시지 및 패키지 설치 내역 등을 디버깅할 때 활용함
   • 모든 User Data 실행 로그는 EC2 인스턴스 내부의 /var/log/cloud-init-output.log 파일에 상세히 기록됨

헷갈리는 포인트 (Tips)

• CloudFormation의 기본 동작 방식상, User Data 스크립트 내부에서 패키지 설치 실패나 에러가 발생하더라도 EC2 인스턴스가 '실행 중(Running)' 상태로만 전환되면 스택 배포는 성공(Success)으로 잘못 간주됨
• 이처럼 스크립트 실제 수행 결과와 스택 상태 불일치 문제를 해결하려면, 스크립트 완료 여부를 CloudFormation에 명시적으로 알리는 추가적인 구성(이후 다루게 될 cfn-signal 및 CreationPolicy 등)이 반드시 필요함

---

3. cfn-init

 

개요 및 배경

• 기존 User Data 쉘 스크립트의 복잡성, 가독성 저하, 인스턴스 교체 없는 상태 변경의 어려움을 극복하기 위해 도입됨
• Amazon Linux에 내장되거나 패키지로 설치 가능한 Python 기반의 CloudFormation 헬퍼 스크립트(cfn-init, cfn-signal, cfn-get-metadata, cfn-hup) 중 하나임
• EC2 인스턴스 내부에서 CloudFormation 서비스를 쿼리하여 복잡한 구성을 가독성 높은 선언적 방식으로 적용함

주요 리소스 및 기능

1. AWS::CloudFormation::Init 메타데이터 블록
   • 리소스의 Metadata 섹션 내에 선언되며, 다양한 구성 요소를 직관적으로 정의함
   • packages: MySQL, httpd 등 필요한 애플리케이션 및 패키지 설치
   • files: 인스턴스 내부에 파일 생성 및 내용(텍스트/데이터) 주입
   • commands: 사용자 지정 쉘 명령어 순차 실행
   • services: 데몬 및 서비스(httpd 등)의 활성화 및 실행 상태 보장(ensureRunning: true)
   • 기타 groups, users, sources(외부 파일 다운로드) 지원
2. cfn-init 동작 메커니즘
   • User 단의 짧은 쉘 스크립트에서 cfn-init 명령을 호출하여 스택 ID(s), 리소스 논리적 ID(r), 리전 정보를 인수로 전달함
   • 인스턴스가 부팅되면서 CloudFormation API를 호출해 자신의 AWS::CloudFormation::Init 설정 데이터를 가져온 뒤, 정의된 패키지, 파일, 서비스를 순차적으로 구성함

헷갈리는 포인트 (Tips)

• 구성 중 발생한 오류나 실행 결과를 디버깅하려면 기본 User Data 로그가 아닌, 전용 로그 파일인 /var/log/cfn-init.log 및 명령어 상세 출력이 담긴 /var/log/cfn-init-cmd.log를 확인해야 함
• cfn-init을 통해 구성을 완벽하게 마쳤더라도, 그 성공 여부가 CloudFormation 스택 배포 상태에 자동으로 보고되지는 않음 (이를 동기화하려면 cfn-signal 헬퍼 스크립트와의 연동이 필수적임)

---

4. cfn-signal & Wait Condition

개요 및 배경

• cfn-init 스크립트를 통한 EC2 인스턴스 구성이 성공적으로 완료되었는지 CloudFormation 서비스가 알 수 있도록 피드백 루프를 구성함
• 인스턴스의 단순 프로비저닝 상태(Running)와 내부 애플리케이션의 실제 구성 상태 간의 불일치 문제를 해결하기 위해 도입됨
• cfn-signal 헬퍼 스크립트와 WaitCondition (또는 CreationPolicy)을 결합하여 신뢰성 있는 인프라 배포를 구현함

주요 리소스 및 기능

1. cfn-signal 동작 메커니즘
   • 일반적으로 cfn-init 명령 실행 직후에 호출되어, 리소스 구성의 성공 또는 실패 상태를 CloudFormation 스택에 보고함
   • cfn-init의 쉘 실행 결과 코드(성공 시 0, 실패 시 0 이외의 에러 코드)를 변수(예: init_status)에 저장한 뒤, 이를 cfn-signal의 인수로 전달하여 스택의 최종 상태를 결정함
2. WaitCondition 및 CreationPolicy
   • WaitCondition: CloudFormation이 cfn-signal로부터 명시적인 신호를 받을 때까지 스택 배포를 일시 중지하고 대기(CREATE_IN_PROGRESS)하도록 만드는 논리적 리소스임
   • CreationPolicy: EC2 인스턴스나 Auto Scaling 그룹(ASG) 구성 시 적용하며, 대기할 타임아웃(Timeout) 시간과 수신해야 할 신호의 개수(Count)를 정의함
   • 지정된 타임아웃 시간 내에 성공 신호를 받지 못하거나 실패 신호를 수신할 경우, 스택 배포는 즉시 실패로 처리되고 롤백됨

헷갈리는 포인트 (Tips)

• cfn-init 단독 사용 시 내부 패키지 설치나 구성에 실패하더라도 EC2 인스턴스 상태가 'Running'이 되면 스택은 'CREATE_COMPLETE'로 처리되는 맹점이 있음. 스크립트 실행의 실제 성공 여부를 스택 배포 결과와 일치시키려면 반드시 cfn-signal을 연동해야 함
• 여러 대의 인스턴스를 동시에 프로비저닝해야 하는 경우, CreationPolicy의 Count 속성을 기대하는 인스턴스 수 이상으로 설정해야 모든 리소스의 정상 구성 신호를 누락 없이 대기할 수 있음

---

5. cfn-signal Failures

 

개요 및 배경

• WaitCondition이 EC2 인스턴스로부터 필요한 신호를 제때 받지 못해 스택 배포가 실패하는 주요 원인과 디버깅 방법을 다룸
• cfn-init 스크립트 실행 중 비정상 종료 코드(Non-zero status code, 예: exit 1)가 발생하면, cfn-signal이 이를 감지하고 CloudFormation에 실패 신호를 전송하여 전체 스택을 롤백(Rollback) 처리함

주요 리소스 및 기능

1. 배포 실패 주요 원인
   • 사용 중인 AMI에 CloudFormation 헬퍼 스크립트(cfn-init, cfn-signal 등)가 설치되어 있지 않음
   • EC2 인스턴스가 프라이빗 서브넷 등에 배치되어 인터넷 연결이 불가함 (인스턴스가 CloudFormation 서비스 엔드포인트와 통신할 수 없어 신호 전송 실패)
2. 트러블슈팅 및 디버깅 방법
   • 원인 분석을 위해 EC2 인스턴스에 접속하여 /var/log/cfn-init.log 및 /var/log/cfn-init-cmd.log 파일을 확인해야 함
   • 기본적으로 스택 생성 실패 시 인스턴스를 포함한 모든 리소스가 즉시 자동 삭제되므로 로그를 확인할 수 없음
   • 이를 방지하려면 스택 생성 시 실패 옵션(Stack failure options)을 '성공적으로 프로비저닝된 리소스 보존 (Preserve successfully provisioned resources)'으로 설정하여 롤백을 비활성화(Disable Rollback)해야 함

헷갈리는 포인트 (Tips)

• WaitCondition의 타임아웃 오류가 발생했을 때 가장 먼저 점검해야 할 아키텍처 요소는 EC2 인스턴스의 아웃바운드 네트워크 설정임 (NAT 게이트웨이, 라우팅 테이블, 또는 VPC 엔드포인트가 올바르게 구성되어 있는지 확인 필수)
• 템플릿 개발 및 테스트 단계에서는 반드시 스택의 롤백 기능 비활성화를 켜두어야, 실패 상태에 빠진 EC2 인스턴스에 SSH나 EC2 Instance Connect로 직접 접속하여 근본 원인을 파악할 수 있음

---

6. Nested Stacks

 

개요 및 배경

• 로드 밸런서, 보안 그룹 구성 등 반복적으로 사용되는 인프라 패턴을 별도의 템플릿으로 분리하여 재사용성(Reusability)을 극대화함
• 부모 스택(Parent Stack) 내에서 하위 스택(Child Stack)을 호출하는 구조이며, 여러 단계로 깊은 중첩(Nesting) 구성이 가능함

주요 리소스 및 기능

1. AWS::CloudFormation::Stack
   • 템플릿 내에서 중첩 스택을 정의할 때 사용하는 전용 리소스 타입임
   • TemplateURL 속성을 사용하여 Amazon S3에 저장된 하위 스택 템플릿의 경로를 반드시 참조해야 함
2. 파라미터 및 출력 연동
   • 부모 스택에서 Parameters 필드를 통해 하위 스택으로 필수 입력값을 전달함
   • 하위 스택에서 반환된 Outputs 값을 부모 스택에서 GetAtt 내장 함수 등을 통해 참조하여 사용할 수 있음
3. CAPABILITY_AUTO_EXPAND 명시
   • 중첩 스택이 포함된 템플릿을 배포할 때, CloudFormation이 참조된 하위 템플릿을 내부적으로 자동 확장(Expand)할 수 있도록 해당 권한(Capability)을 체크(승인)해야 정상 배포됨

헷갈리는 포인트 (Tips)

• 중첩 스택(Nested Stacks) vs 교차 스택(Cross Stacks)
  • 중첩 스택: 특정 아키텍처 구성 요소를 캡슐화하여 반복적으로 찍어내듯 재사용할 때 적합하며, 하위 스택은 부모 스택의 생명주기에 완전히 종속됨
  • 교차 스택(Export / Fn::ImportValue): VPC 네트워크 스택과 애플리케이션 스택처럼 서로 생명주기(Lifecycle)가 다른 스택 간에 식별자(Subnet ID 등) 값을 안전하게 공유할 때 사용함
• 업데이트 및 삭제 원칙: AWS 콘솔이나 CLI에서 하위 중첩 스택을 개별적으로 직접 업데이트하거나 삭제하면 상태 불일치가 발생함. 모든 변경 및 파기 작업은 반드시 최상위 부모 스택(Root/Parent Stack)을 통해서만 수행해야 함

---

7. StackSets

 

개요 및 배경

• 단일 작업으로 여러 AWS 계정 및 여러 리전에 걸쳐 CloudFormation 스택을 동시에 배포하고 관리하기 위해 사용함
• 관리자(Administrator) 계정에서 StackSet을 생성 및 업데이트하면, 타겟(Target) 계정에 배포된 모든 스택 인스턴스에 변경 사항이 일괄 적용됨

주요 리소스 및 기능

1. 권한 모델 (Permission Models)
   • 자가 관리형 권한 (Self-managed permissions): AWS Organizations를 사용하지 않을 때 적용함. 관리자 계정에 Administration Role을 생성하고 타겟 계정에 Execution Role을 생성하여 수동으로 IAM 신뢰 관계(Trust Relationship)를 구성해야 함
   • 서비스 관리형 권한 (Service-managed permissions): AWS Organizations와 통합하여 작동함. AWS가 백그라운드에서 필요한 IAM 역할을 자동으로 생성 및 관리하므로 운영 오버헤드가 감소함 (Organizations의 모든 기능 활성화 및 신뢰할 수 있는 액세스 활성화 필수)
2. AWS Organizations 연동 및 자동화 기능
   • 자동 배포 (Auto-deploy): 특정 조직 단위(OU)에 새로운 AWS 멤버 계정이 생성되거나 추가될 때, 구성된 스택 인스턴스를 해당 새 계정에 자동으로 배포하도록 설정 가능함
   • 위임된 관리자 (Delegated Administrator): 보안 및 거버넌스 원칙(최소 권한)에 따라, Organizations의 마스터 계정 대신 특정 멤버 계정에 StackSet 관리 권한을 위임하여 중앙 배포 작업을 수행할 수 있음

헷갈리는 포인트 (Tips)

• 타겟 계정 내부에서는 배포된 스택 인스턴스의 템플릿을 임의로 수정하거나 삭제할 수 없음. 모든 구성 변경과 파기 작업은 반드시 관리자 계정(또는 위임된 관리자 계정)의 StackSet 레벨에서 하향식(Top-down)으로 수행해야 상태 불일치가 발생하지 않음
• Service-managed 권한 모델을 사용하려면 반드시 AWS Organizations의 신뢰할 수 있는 액세스(Trusted Access)가 사전 구성되어 있어야 위임된 관리자 지정 및 OU 대상 자동 배포가 정상적으로 동작함

---

8. Troubleshooting

 

개요 및 배경

• CloudFormation 스택의 생성, 업데이트, 삭제 과정에서 발생하는 주요 상태 오류(DELETE_FAILED, UPDATE_ROLLBACK_FAILED 등)의 원인과 해결 방법을 다룸
• 단일 스택뿐만 아니라 다중 계정/리전 배포 기능인 StackSets 구성 시 발생하는 특수한 제약 조건 및 트러블슈팅 기법을 이해해야 함

주요 리소스 및 기능

1. DELETE_FAILED (삭제 실패) 문제 해결
   • 원인: S3 버킷 내부에 객체가 남아있거나, 스택 외부에 있는 다른 EC2 인스턴스가 스택 내 보안 그룹(Security Group)을 참조하고 있을 때 발생함
   • 해결책: S3 버킷 삭제 전 내부 객체를 자동으로 비우려면 AWS Lambda를 연동한 사용자 지정 리소스(Custom Resources)를 구성해야 함
   • 지속적으로 삭제에 실패하는 특정 리소스가 있다면, 템플릿에 DeletionPolicy=Retain 속성을 추가하여 해당 리소스의 삭제만 건너뛰고 나머지 스택 삭제를 진행할 수 있음
2. UPDATE_ROLLBACK_FAILED (업데이트 롤백 실패) 문제 해결
   • 원인: 스택 업데이트 실패 후 롤백을 시도했으나, 리소스가 CloudFormation 외부에서 수동으로 변경되었거나, IAM 권한 부족, ASG 신호 수신 실패 등의 이유로 롤백조차 실패한 심각한 상태임
   • 해결책: AWS 콘솔이나 CLI를 통해 오류의 근본 원인(예: 수동 변경된 리소스 복구, 권한 추가 등)을 수동으로 해결한 뒤, 반드시 ContinueUpdateRollback API를 명시적으로 호출하여 롤백 프로세스를 끝까지 완료시켜야 함
3. StackSets 배포 트러블슈팅
   • 특정 타겟 계정이나 리전에서 배포가 실패하면 해당 스택 인스턴스의 상태가 OUTDATED로 표시됨
   • 주요 원인: 타겟 계정의 IAM 권한/신뢰 관계 부족, 해당 계정의 서비스 할당량(Quota, 예: EC2 최대 개수) 초과
   • S3 버킷 이름과 같은 글로벌 고유 리소스를 템플릿에 고정해 두면, 여러 계정/리전에 동시 배포할 때 이름 충돌(Naming Collision)이 발생하여 단 한 곳에서만 성공하고 나머지는 실패함
4. 템플릿 제약 및 교차 리전 배포 문제
   • EC2 인스턴스의 PrivateDnsName과 같이 AWS 관리 콘솔 UI를 통해 직접 설정할 수 없는 속성은 CloudFormation 템플릿으로도 설정할 수 없음
   • 템플릿이 특정 리전에서는 정상 작동하나 다른 리전에서 실패할 경우: 대상 리전에 해당 서비스가 출시되었는지 파악하고, 하드코딩된 AMI ID(AMI는 리전별로 고유함)나 특정 리전의 ARN이 포함되어 있지 않은지 점검해야 함

헷갈리는 포인트 (Tips)

• DELETE_FAILED 상태를 우회하기 위해 DeletionPolicy=Retain을 사용하는 것은 시험에 자주 출제되는 핵심 패턴임
• UPDATE_ROLLBACK_FAILED 상태에서는 스택 업데이트나 삭제를 바로 재시도할 수 없으며, 반드시 수동 조치 후 ContinueUpdateRollback을 실행해야만 스택이 정상(UPDATE_ROLLBACK_COMPLETE) 상태로 돌아옴
• 다중 리전 배포 시 AMI ID 오류를 방지하려면, 템플릿 내에 하드코딩하는 대신 Mappings 섹션을 활용하여 리전별 AMI ID를 동적으로 매핑하거나 SSM Parameter Store를 참조하는 방식을 사용해야 함