Day 5 - Week 6 종합 복습: CloudFormation 운영 완전 정복

Week 6는 CloudFormation을 단순 "인프라 생성 도구"에서 "대규모 조직의 운영 플랫폼"으로 바라보는 주간이었다. Day 1의 템플릿 구조와 스택 라이프사이클에서 시작해, Day 2의 변경 안전 관리(Change Set, Drift, Rollback Trigger), Day 3의 대규모 IaC 패턴(Nested/Cross-Stack/StackSets), Day 4의 자가 서비스와 동적 설정(Service Catalog, AppConfig, AppRegistry)까지 이어졌다.

SOA-C02에서 CloudFormation은 단순 API 암기 문제가 아니다. "어떤 상황에서 어떤 도구를 선택해야 하는가", "이 변경이 Replacement를 유발하는가", "스택이 이 상태일 때 어떤 복구 방법이 가능한가"를 판단하는 능력을 측정한다. 이 복습은 그 판단력을 기르는 데 집중한다.

Week 6 핵심 개념 맵

CloudFormation 운영 플랫폼
============================================================

[Template 구조]                    [안전한 변경 관리]
 - Resources만 필수                 - Change Set (dry-run)
 - 10개 섹션 (나머지 선택)           - Drift Detection (괴리 감지)
 - Pseudo Parameters              - Rollback Trigger (자동 복구)
 - Intrinsic Functions            - Stack Policy (수정 차단)
 - Dynamic References             - Termination Protection
        │                                   │
        ▼                                   ▼
[Stack 라이프사이클]              [대규모 IaC 패턴]
 ROLLBACK_COMPLETE                 - Nested Stack (모듈화)
   → 삭제 후 재생성                 - Cross-Stack (팀 간 공유)
 UPDATE_ROLLBACK_FAILED            - StackSets (조직 전체)
   → continue-update-rollback      - Auto-deployment (신규 계정)
 DELETE_FAILED
   → --retain-resources
        │                                   │
        ▼                                   ▼
[리소스 보호]                     [거버넌스 & 동적 설정]
 DeletionPolicy: Snapshot/Retain    - Service Catalog (자가 서비스)
 UpdateReplacePolicy: Snapshot      - Launch Constraint (대리 실행)
 cfn-signal (readiness 확인)        - AppConfig (런타임 설정)
 AutoScalingRollingUpdate           - AppRegistry (자산 그룹화)

핵심 비교표: 혼동하기 쉬운 개념들

스택 패턴 비교:

변경 안전 도구 비교:

리소스 보호 정책 비교:

거버넌스 서비스 비교:

💡 관련 이론: CloudFormation의 전체 설계는 분산 시스템 이론의 "State Reconciliation" 패턴이다. Kubernetes 컨트롤러가 desired state와 current state를 지속적으로 비교해 수렴시키는 것처럼, CloudFormation은 템플릿(desired state)와 실제 AWS 리소스(current state)의 차이를 계산해 변경 작업을 수행한다. Drift Detection은 이 수렴 루프의 "역방향 검사"다. 운영자가 템플릿 밖에서 리소스를 변경했을 때, 현실이 desired state에서 벗어났음을 감지한다. Leslie Lamport의 "State Machine Replication"(1984) 이론이 이 패턴의 이론적 기반이다.

중요 실수 컬렉션: 시험에 나오는 함정

CloudFormation Template & 스택:

Nested Stack & Cross-Stack:

StackSets:

AppConfig:

가상의 사례로, 2024년 물류 스타트업 L사에서 CloudFormation으로 관리하던 RDS 인스턴스의 MultiAZ를 false에서 true로 변경했다. 운영자는 "MultiAZ 활성화는 인플레이스 변경"이라고 알고 있었다. 그러나 해당 인스턴스의 엔진 버전이 함께 업그레이드되는 경우 Replacement가 트리거될 수 있었다. Change Set을 사용했다면 Replacement: Conditional을 보고 추가 확인을 했을 것이다. 결과적으로 RDS가 교체되어 새 엔드포인트가 생겼고, 애플리케이션 연결 설정을 변경하지 못한 서버들이 5분간 DB 접속 실패를 겪었다. 이후 모든 RDS 변경은 반드시 Change Set 확인 + UpdateReplacePolicy: Snapshot 표준이 됐다.

CloudFormation의 Replacement 판단 기준은 AWS 내부 리소스 핸들러(Resource Handler)가 결정한다. CloudFormation Registry에 등록된 각 리소스 타입의 스키마에 각 속성의 "createOnlyProperties", "readOnlyProperties" 등이 정의돼 있다. "createOnlyProperties"에 해당하는 속성을 변경하면 반드시 Replacement가 발생한다. AWS CLI로 aws cloudformation describe-type --type RESOURCE --type-name AWS::RDS::DBInstance를 실행하면 스키마를 확인할 수 있다. 이를 이해하면 "왜 이 속성 변경은 Replacement를 유발하는가"를 외우지 않고도 판단할 수 있다.

SOA-C02 시험 핵심 판단 체계

시나리오: "스택이 X 상태입니다. 어떻게 해야 하는가?"

Stack 상태별 대응:

ROLLBACK_COMPLETE
  → 삭제 후 재생성. update-stack, continue-update-rollback 불가

UPDATE_ROLLBACK_FAILED
  → continue-update-rollback [--resources-to-skip 문제 리소스]
  → 가장 먼저 이 명령 시도

DELETE_FAILED
  → delete-stack --retain-resources 문제리소스ID
  → 잔여 리소스 수동 정리 후 재삭제

CREATE_FAILED (--on-failure DO_NOTHING 설정 시)
  → 실패 리소스가 남아있어 직접 디버그 가능
  → 디버그 완료 후 반드시 수동 정리

시나리오: "어떤 CFn 패턴을 써야 하는가?"

Q: 하나의 앱을 여러 팀이 각자 배포하는 컴포넌트로 나누고 싶다
   → Nested Stack

Q: 팀 A의 VPC를 팀 B, C, D의 앱 Stack이 공유하고 싶다
   → Cross-Stack Reference (Export/ImportValue)

Q: 50개 계정 모두에 GuardDuty를 배포하고, 신규 계정도 자동 포함하고 싶다
   → StackSets + Service-Managed + AutoDeployment=true

Q: 개발자가 권한 없어도 표준 인프라를 만들 수 있게 하고 싶다
   → Service Catalog + Launch Constraint

시나리오: "데이터 손실 방지"

RDS/ElastiCache 삭제:
  DeletionPolicy: Snapshot (Stack 삭제 시 스냅샷)

RDS 업데이트로 인한 교체:
  UpdateReplacePolicy: Snapshot (업데이트 중 교체 시 스냅샷)

변경 전 안전 확인:
  Change Set → Replacement 필드 확인
  Replacement=True 이면 UpdateReplacePolicy 확인

Stack 실수 삭제 방지:
  Termination Protection 활성화

특정 리소스 수정 방지:
  Stack Policy + Deny Update:Replace/Delete

⚠️ 함정: DeletionPolicy와 UpdateReplacePolicy는 "스택 삭제"와 "업데이트 중 교체"라는 완전히 다른 상황에 적용된다. RDS를 보호하려면 두 가지를 모두 설정해야 한다. DeletionPolicy: Snapshot만 있고 UpdateReplacePolicy가 없으면, 스택 삭제 시에는 스냅샷이 생기지만 업데이트 중 교체가 발생할 때는 기존 RDS가 스냅샷 없이 삭제된다. 시험에서 "RDS 변경 시 데이터 손실을 방지하려면?" 문제의 완전한 답은 UpdateReplacePolicy: Snapshot이다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

RDS DB 인스턴스 타입을 db.t3.medium에서 db.r5.large로 변경하려 한다. 데이터 손실 없이 안전한지 어떻게 확인하는가?

• A바로 update-stack을 실행하고, RDS가 교체되면 자동 생성되는 스냅샷에서 복원해 데이터 손실을 막는다
• BChange Set을 생성하고 Replacement 필드를 확인한다. False이면 인플레이스 업데이트, True이면 RDS 교체 + 데이터 손실 위험
• C먼저 RDS 수동 스냅샷을 만든 뒤 update-stack을 실행하면 교체가 발생해도 스냅샷이 있어 안전하다
• DStack을 삭제하고 새 인스턴스 클래스로 재생성하면 깨끗한 상태에서 안전하게 타입을 바꿀 수 있다

문제 2

Stack이 ROLLBACK_COMPLETE 상태다. 동일한 이름으로 Template를 수정해 재배포하려 한다. 올바른 절차는?

• Aupdate-stack으로 새 Template를 적용해 ROLLBACK_COMPLETE 상태를 정상 상태로 덮어쓴다
• Bcreate-change-set으로 변경 사항을 미리 확인한 뒤 execute-change-set으로 적용한다
• Cdelete-stack으로 삭제한 후 create-stack으로 재생성한다
• Dcontinue-update-rollback으로 미완료 롤백을 마저 진행해 Stack을 복구한 뒤 업데이트한다

문제 3

회사가 Organizations로 50개 계정을 관리한다. 모든 계정에 보안 Baseline(CloudTrail, GuardDuty)을 일괄 배포하고, 앞으로 새로 추가되는 계정도 자동으로 포함되길 원한다. 가장 적합한 솔루션은?

• A50개 계정 각각에 수동으로 CloudFormation Stack을 배포하고, 신규 계정은 온보딩 체크리스트에 Stack 배포 단계를 추가해 누락을 방지한다
• BStackSets with Service-Managed Permissions + AutoDeployment=true를 설정한다
• CEventBridge로 Organizations CreateAccountResult 이벤트를 감지해 Lambda가 신규 계정에 CloudFormation Stack을 배포하도록 자동화한다
• DAWS Control Tower로 전환해 Account Factory가 신규 계정 프로비저닝 시 보안 Baseline을 자동 적용하게 한다

문제 4

운영팀이 Production Stack을 실수로 삭제하는 것을 방지하려 한다. 어떤 방법이 가장 직접적인가?

• A운영자 IAM 정책에서 cloudformation:DeleteStack을 Deny하고, prod Stack ARN을 조건으로 걸어 삭제를 차단한다
• BStack에 Termination Protection을 활성화한다
• CStack Policy에 "Effect":"Deny","Action":"Update:Delete","Resource":"*"를 추가해 모든 리소스 삭제를 차단한다
• Dcloudformation:DeleteStack 호출에 aws:MultiFactorAuthPresent: true 조건을 걸어 MFA 없이는 삭제를 막는다

문제 5

개발자가 IAM에서 RDS 생성 권한이 없는데, 표준 RDS 패키지를 자가 서비스로 프로비저닝하게 하려 한다. 어떻게 구성하는가?

• A개발자에게 시간 제한이 걸린 임시 RDS 생성 권한을 STS로 부여하고, CloudTrail로 사용 이력을 감사한다
• BService Catalog Portfolio에 RDS 제품을 등록하고, Launch Constraint에 RDS 생성 권한이 있는 IAM Role을 지정한다
• C표준 RDS CloudFormation Template를 S3에 두고 개발자가 직접 create-stack으로 배포하도록 cloudformation:CreateStack만 허용한다
• D개발자에게 RDS Multi-AZ·암호화 등 표준 설정을 문서로 교육하고 콘솔에서 직접 생성하게 한다

문제 6

Lambda 함수의 Feature Flag를 코드 재배포 없이 점진적으로 토글하고 싶다. 배포 중 에러율이 급증하면 자동으로 이전 설정으로 돌아가야 한다. 가장 적합한 도구와 설정은?

• AParameter Store에 Flag 값을 두고 Lambda가 매 호출마다 읽게 한 뒤, 에러율 알람이 울리면 운영자가 값을 되돌린다
• BAppConfig + Feature Flag 타입 프로파일 + Canary 배포 전략 + CloudWatch Alarm Monitor 설정
• CDynamoDB 테이블에 Flag 값을 저장하고 DynamoDB Streams + Lambda로 점진 토글·에러 시 롤백을 직접 구현한다
• DLambda 환경 변수에 Flag를 두고 CodeDeploy Canary로 별칭 트래픽을 점진 이동시키며 알람 시 롤백한다

문제 7

누군가 콘솔에서 CloudFormation으로 관리되는 보안 그룹에 0.0.0.0/0:22 규칙을 직접 추가했다. 이 변경을 자동으로 감지해 알림을 받으려면?

• AAuthorizeSecurityGroupIngress API를 추적하는 CloudWatch Metric Filter + Metric Alarm으로 SG 규칙 추가를 감지해 알림한다
• BDrift Detection을 EventBridge Scheduled Rule + Lambda로 주기적으로 실행하고, MODIFIED 리소스 발견 시 SNS로 알림을 발송한다
• CGuardDuty가 0.0.0.0/0:22 같은 개방 규칙을 의심스러운 구성 변경으로 자동 Finding을 생성한다
• DAWS Config Rule restricted-ssh로 SG를 평가해 비준수 시 알림하고, Inspector로 EC2 노출을 함께 스캔한다

문제 8

Cross-Stack Reference에서 Stack A가 VPC ID를 Export하고, Stack B와 Stack C가 !ImportValue로 사용 중이다. Stack A의 VPC ID Export를 다른 VPC로 변경하려 한다. 어떻게 해야 하는가?

• AStack A만 업데이트하면 Export 값이 갱신되고 Stack B, C가 다음 drift 감지 시 자동으로 새 VPC ID를 참조한다
• BExport는 참조 무결성을 자동 관리하므로 Stack A를 바로 업데이트하면 CloudFormation이 B, C를 순서대로 함께 갱신한다
• CStack B와 Stack C에서 !ImportValue를 제거하고, Stack A를 업데이트한 후, Stack B와 Stack C를 새 Export 값으로 업데이트한다
• DStack A를 삭제 후 재생성해 Export를 새 VPC ID로 다시 만들면 B, C가 끊김 없이 새 Export에 다시 연결된다

문제 9

Stack 업데이트 완료 후 10분 내에 HTTP 5xx 에러율이 급증하면 자동으로 이전 상태로 되돌아가도록 설정하려 한다. 어떤 구성이 필요한가?

• AEventBridge 스케줄로 Lambda가 5xx CloudWatch Alarm 상태를 폴링하다가 ALARM이면 cancel-update-stack을 호출해 직전 상태로 되돌린다
• Bupdate-stack 또는 execute-change-set 실행 시 --rollback-configuration에 CloudWatch Alarm ARN과 MonitoringTimeInMinutes: 10을 설정한다
• CCodeDeploy Blue/Green과 CloudFormation을 통합해 5xx 알람 발생 시 트래픽을 원래 환경으로 자동 전환한다
• DCloudFormation 콘솔에서 "Enable Auto Rollback" 옵션을 켜고 임계 알람을 연결해 업데이트 후 10분간 감시하게 한다

문제 10

Template에서 항상 최신 Amazon Linux 2 AMI를 자동으로 사용하고 싶다. 하드코딩이나 Mapping 없이 구현하는 방법은?

• AMappings 섹션에 리전별 최신 AMI ID를 넣고, EventBridge 스케줄 + Lambda로 매월 Mapping을 자동 갱신해 하드코딩 부담을 줄인다
• BLambda 기반 Custom Resource를 두어 Stack 배포 시마다 ec2:DescribeImages로 최신 Amazon Linux 2 AMI를 조회해 반환하게 한다
• CParameter 타입을 AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>로 설정하고, Default에 AWS 공식 SSM 경로(/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2)를 지정한다
• DCloudFormation 콘솔의 "Use Latest AMI" 옵션과 Fn::LatestAMI 내장 함수를 함께 써서 배포 시 최신 이미지를 자동 선택한다

문제 11

AppConfig Deployment Strategy에서 FinalBakeTimeInMinutes: 15를 설정했다. AllAtOnce 전략으로 배포했을 때 정확한 동작은?

• AAllAtOnce라도 FinalBakeTime이 있으면 15분에 걸쳐 트래픽이 선형으로 새 설정에 점진 적용된다
• B설정이 즉시 100% 적용되고, 이후 15분 동안 CloudWatch Alarm을 감시한다. 알람 발생 시 자동 롤백된다
• CFinalBakeTime이 시작 지연으로 작용해 배포가 15분 대기 후에 비로소 100% 적용된다
• DGrowthFactor 기본값에 따라 배포가 10%씩 15분 간격으로 단계 적용된다

문제 12

Service Catalog Launch Constraint Role에 Permission Boundary를 설정하는 이유는?

• APermission Boundary가 Launch Role의 정책 평가 범위를 좁혀 CloudFormation 프로비저닝 실행 속도를 높이기 위해
• BLaunch Role이 Service Catalog의 Provision/Terminate API를 호출할 수 있도록 필요한 신뢰 관계를 부여하기 위해
• C사용자가 Service Catalog를 통해 Launch Role보다 강력한 권한(예: Admin)으로 리소스를 만드는 권한 에스컬레이션을 방지하기 위해
• DLaunch Role을 멀티 계정·멀티 리전 StackSet 배포에 사용할 수 있도록 경계를 확장하기 위해

다음 주 예고 (Week 7)

Week 7은 배포·프로비저닝 주간이다. Elastic Beanstalk의 배포 정책(All at Once/Rolling/Immutable/Traffic Splitting), CodeDeploy의 배포 훅과 AppSpec, EC2 Image Builder로 Golden AMI 파이프라인 구축, Launch Template과 Auto Scaling 심화를 다룬다.

SOA-C02에서 배포 정책의 속도/비용/다운타임 트레이드오프는 빈출 주제다. 예: "다운타임 없이 최소 비용으로 배포하려면?" → Rolling. "빠르게 배포하되 문제 시 즉시 롤백 가능하려면?" → Immutable.

💡 관련 이론: 배포 전략은 마틴 파울러(Martin Fowler)가 2010년 정의한 "Deployment Pipeline" 개념의 구체화다. Blue-Green, Canary, Rolling은 트레이드오프가 다른 세 가지 근본 전략이다. AWS 서비스마다 이 전략을 다른 이름으로 구현한다: Beanstalk(Immutable=Blue-Green 유사), CodeDeploy(Blue/Green), AppConfig(Canary), CloudFormation ASG(AutoScalingRollingUpdate). 이름보다 "어떤 메커니즘인가"를 이해하면 어떤 서비스의 문제도 풀 수 있다.