SAP-C02에서 배포 전략과 비즈니스 연속성은 D2(새로운 솔루션 설계)와 D3(기존 솔루션 지속 개선) 두 도메인에 걸쳐 출제됩니다. 단순히 서비스 이름을 아는 것을 넘어서, "어떤 상황에서 어떤 배포 방식을 선택해야 하는가"라는 판단 능력을 검증합니다. 이 포스트에서는 실제 시험 시나리오를 기반으로 CloudFormation 변경 관리, CI/CD 파이프라인, Blue/Green 배포, 그리고 재해 복구 패턴을 체계적으로 정리합니다.
CloudFormation 변경 관리 — Change Sets와 Stack Policy
프로덕션 인프라를 CloudFormation으로 관리할 때 가장 위험한 순간은 스택을 업데이트하는 순간입니다. 특히 RDS 인스턴스의 엔진 버전 변경이나 DynamoDB 키 스키마 변경처럼 리소스를 삭제하고 재생성해야 하는 "교체(Replacement)" 변경은 데이터 손실로 이어질 수 있습니다.
Change Sets는 이 문제를 해결하는 핵심 도구입니다. 실제 스택을 변경하기 전에 변경 계획을 먼저 생성해서 Add, Modify, Remove, Replace 중 어떤 작업이 일어날지 미리 확인할 수 있습니다. 특히 Replacement: True로 표시된 항목은 리소스가 삭제되고 새로 만들어진다는 뜻이므로, 이를 확인하고 승인하는 과정이 필수입니다.
Stack Policy는 JSON 형식의 정책으로 특정 리소스에 대한 Replace나 Delete 작업을 자동으로 차단합니다. Change Sets가 "미리보기" 역할이라면, Stack Policy는 "가드레일" 역할입니다. PCI DSS나 SOX 같은 규제 환경에서는 Change Sets 이력이 변경 승인 감사 증적(Audit Trail)으로 활용되기도 합니다.
Drift Detection은 자주 혼동되는 개념입니다. Drift Detection은 배포 후 CloudFormation 외부에서 누군가 콘솔이나 CLI로 직접 변경한 내역을 감지하는 기능입니다. 배포 전 교체 예방과는 목적이 다르므로 시험에서 구분해야 합니다.
| 기능 | 목적 | 타이밍 | |------|------|--------| | Change Sets | 변경 내용 미리보기 (Replacement 식별) | 배포 전 | | Stack Policy | 특정 리소스 교체/삭제 자동 차단 | 배포 시 | | Drift Detection | 외부 수동 변경 감지 | 배포 후 |
CI/CD 파이프라인 — CodePipeline, CodeBuild, ManualApproval
AWS 네이티브 CI/CD의 기본 흐름은 CodePipeline이 전체 파이프라인을 오케스트레이션하고, CodeBuild가 빌드와 테스트를 담당하며, CodeDeploy가 실제 배포를 수행하는 구조입니다.
CloudFormation과 연동한 안전 배포 파이프라인은 다음 순서로 구성됩니다. 소스 감지(CodeCommit/GitHub) → Change Sets 생성 → ManualApproval 단계에서 엔지니어가 Change Sets를 검토 → 승인 후 ExecuteChangeSet. 이 패턴은 PCI DSS 환경에서 변경 관리 권한 분리(Segregation of Duties)를 구현하는 표준 방법입니다.
Jenkins와의 통합도 자주 출제됩니다. 기존에 Jenkins를 사용하고 있는 조직이 AWS로 이전할 때, Jenkins를 완전히 교체하지 않고 CodePipeline의 빌드 단계에서 Jenkins를 공급자로 직접 지정할 수 있습니다. 이렇게 하면 기존 Jenkins 투자를 보호하면서 AWS 파이프라인 오케스트레이션을 추가할 수 있습니다. CodeBuild는 Jenkins를 완전히 대체하는 선택지이고, 기존 Jenkins를 유지하고 싶을 때는 CodePipeline과 Jenkins 조합을 선택합니다.
컨테이너 CI/CD에서는 ECR 이미지 스캐닝이 중요합니다. Basic Scanning은 CVE 데이터베이스 기반이고, Enhanced Scanning은 Amazon Inspector를 활용해 더 깊은 취약점 분석을 제공합니다. ECS 배포 방식으로는 Rolling Update(순차 교체)와 Blue/Green(CodeDeploy 기반, 다운타임 0)이 있으며, 다운타임 없는 배포가 요구사항이면 Blue/Green을 선택합니다.
Lambda 점진적 배포 — Alias, Canary, Linear
Lambda 함수를 안전하게 업데이트하려면 $LATEST를 직접 호출하는 방식 대신 버전과 별칭(Alias)을 먼저 설정해야 합니다. CodeDeploy와 연동하면 세 가지 배포 전략을 사용할 수 있습니다.
Canary 배포는 초기에 소량(예: 10%)의 트래픽만 새 버전으로 보내고, 검증이 완료되면 나머지 90%를 한 번에 전환합니다. Linear 배포는 매 N분마다 X%씩 점진적으로 증가시킵니다. AllAtOnce는 즉시 전체 전환으로 롤백이 필요 없는 낮은 위험의 변경에 사용합니다.
CloudWatch 알람과 연동하면 오류율이 급증할 때 CodeDeploy가 자동으로 이전 버전으로 롤백합니다. SAM을 사용하면 속성으로 선언적으로 이 설정을 구성할 수 있습니다.
| 전략 | 동작 | 자동 롤백 | |------|------|----------| | Canary | X% → 검증 → 100% | CloudWatch Alarm 연동 | | Linear | 매 N분마다 X%씩 증가 | CloudWatch Alarm 연동 | | AllAtOnce | 즉시 100% | 수동 롤백 |
!Lambda 점진적 배포 유형
Blue/Green 배포 — 무중단과 즉시 롤백
Blue/Green 배포의 핵심은 두 환경을 병렬로 유지하고, 트래픽 전환만으로 버전을 교체한다는 점입니다. 롤백도 트래픽을 Blue로 다시 돌리면 되므로 5분 이내에 완료됩니다. 반면 Rolling이나 In-place 배포는 롤백 시 재배포 시간이 동일하게 소요됩니다.
플랫폼별 Blue/Green 구현 방식이 다릅니다. EC2/ASG에서는 Blue ASG와 Green ASG를 병렬 운영하다가 ALB 타겟 그룹을 전환합니다. ECS에서는 CodeDeploy가 Blue(구버전) 태스크와 Green(신버전) 태스크를 병렬 실행하고, ALB의 이중 리스너(테스트 포트 8080, 프로덕션 포트 443)를 활용합니다. Elastic Beanstalk에서는 두 환경의 DNS CNAME을 순간 스왑합니다.
Route 53 가중치 기반 라우팅(Weighted Routing)을 활용하면 Blue/Green 트래픽 전환을 더 세밀하게 제어할 수 있습니다. 예를 들어 처음에는 Blue 90%, Green 10%로 시작해서 점진적으로 비율을 조정하는 카나리 방식의 Blue/Green도 가능합니다.
DR 시나리오 — RTO/RPO와 비용 트레이드오프
비즈니스 연속성 문제에서 가장 중요한 판단 기준은 RTO(복구 시간 목표)와 RPO(복구 시점 목표)입니다. 비용과 복구 속도는 반비례 관계이므로, 요구사항에 맞는 최소 비용 솔루션을 찾는 것이 SAP-C02의 핵심입니다.
Aurora Global Database는 스토리지 레이어 복제로 RPO를 1초 미만으로 달성하고, 보조 리전 승격(Promote)으로 RTO를 1분 미만으로 달성합니다. 엄격한 RPO/RTO 요구사항이 있는 금융, 의료 시스템에 적합합니다. Aurora Serverless v2는 Global Database와 함께 사용할 수 있어 멀티 리전 서버리스 DR도 가능합니다.
RDS Cross-Region Read Replica는 비동기 복제이므로 RPO가 수 초에서 수 분입니다. Aurora Global Database보다 비용이 낮지만 RPO가 느슨합니다. 재해 발생 시 Promote에 5~10분이 소요됩니다. CloudWatch RDS 이벤트와 EventBridge, Lambda를 조합하면 Promote 과정을 자동화할 수 있습니다.
Route 53 Failover 라우팅과 Calculated Health Check의 조합은 자동 DR 전환의 핵심입니다. Calculated Health Check는 여러 자식 헬스 체크를 AND/OR로 조합하여 false positive로 인한 불필요한 페일오버를 방지합니다.
DynamoDB Global Tables는 멀티 리전 Active-Active 구조로 어느 리전에서나 읽기/쓰기가 가능합니다. Aurora Global Database가 단일 Primary 리전만 쓰기를 허용하는 Active-Passive 구조인 것과 대조됩니다. NoSQL이면서 멀티 리전 쓰기가 필요한 시나리오에서는 DynamoDB Global Tables를 선택합니다.
Systems Manager Patch Management
Systems Manager Patch Manager는 EC2뿐 아니라 SSM Agent를 설치한 온프레미스 서버도 AWS 콘솔에서 통합 관리할 수 있습니다. 하이브리드 환경에서 패치 관리를 통합하려면 온프레미스 서버에 SSM Agent를 설치하고 하이브리드 활성화(Hybrid Activation)를 설정합니다. 이후 Patch Baseline과 Maintenance Window를 정의하면 온프레미스와 클라우드 서버를 동일한 방식으로 관리할 수 있습니다.
시험 핵심 정리
"Change Sets Replacement True 의미" -- 리소스 삭제 후 재생성 (데이터 손실 위험)
"배포 전 교체 예방 도구" -- Change Sets + Stack Policy
"배포 후 외부 수동 변경 감지" -- Drift Detection
"Lambda 소량 트래픽 먼저 검증 후 나머지 전환" -- Canary 배포 (CodeDeploy + Alias)
"Lambda 매 N분마다 X%씩 점진 증가" -- Linear 배포
"Blue/Green 5분 내 롤백 가능한 이유" -- 트래픽만 재전환하면 완료 (재배포 불필요)
"ECS Blue/Green 이중 리스너" -- 테스트(8080) + 프로덕션(443) 동시 운영
"멀티 리전 NoSQL Active-Active 쓰기" -- DynamoDB Global Tables
"RPO 1초 미만 + RTO 1분 미만 관계형 DB" -- Aurora Global Database
"비동기 복제, Promote에 5~10분, 비용 절감" -- RDS Cross-Region Read Replica
"온프레미스 서버를 AWS 콘솔에서 패치 관리" -- Systems Manager Patch Manager + Hybrid Activation
"PCI DSS 변경 관리 권한 분리 구현" -- CodePipeline + ManualApproval + Change Sets