SAP-C02 D3 도메인(기존 솔루션의 지속적 개선)에서 보안과 신뢰성 개선은 단순히 서비스 기능을 아는 것에서 그치지 않습니다. "현재 실행 중인 시스템에 어떻게 자동화된 보안 통제를 적용하고, 장애 발생 시 스스로 복구하는 아키텍처를 만드는가"를 묻습니다.
핵심 사고 방식은 두 가지입니다. 첫째, 사람이 개입하지 않아도 보안 문제가 자동으로 탐지·교정되어야 합니다. 둘째, 단일 장애 지점을 제거하고 시스템이 스스로 복구할 수 있어야 합니다.
AMI 보안 자동화 — EC2 Image Builder + Amazon Inspector
AMI를 직접 관리하면 취약점이 포함된 이미지가 배포될 위험이 있습니다. EC2 Image Builder는 AMI 빌드, 테스트, 배포 파이프라인을 완전히 자동화하는 관리형 서비스입니다. 새 AMI를 만들 때마다 정해진 레시피(소프트웨어 설치, 설정 적용)를 실행하고 테스트한 뒤 자동으로 배포합니다.
Amazon Inspector는 EC2 인스턴스와 AMI에 대해 CVE 취약점을 지속적으로 자동 평가합니다. Inspector v2는 SSM Agent를 통해 추가 에이전트 없이 에이전트리스 스캔을 지원하며, 네트워크 접근성 평가(퍼블릭 인터넷에서 접근 가능한 포트)도 함께 수행합니다.
두 서비스의 연계 패턴이 시험에 자주 출제됩니다. Inspector가 취약점 Finding을 생성하면 EventBridge가 이를 감지하고 Lambda를 트리거해 해당 AMI를 승인 목록에서 자동 제거합니다. Systems Manager Inventory와 AWS Config는 인벤토리 감사 용도이며 AMI 빌드나 취약점 평가는 수행하지 않습니다.
| 서비스 | 역할 | 시험 키워드 | |--------|------|-----------| | EC2 Image Builder | AMI 빌드·테스트·배포 파이프라인 자동화 | AMI 승인 목록, 빌드 자동화 | | Amazon Inspector | CVE 취약점 지속 평가, 네트워크 접근성 분석 | 에이전트리스 스캔, 취약점 Finding | | AWS Config | 구성 변경 기록 및 규정 준수 평가 | 컴플라이언스 감사 (스캔 아님) | | SSM Inventory | 소프트웨어 인벤토리 수집 | 인벤토리 (평가 아님) |
Secrets Manager — 자격 증명 자동 교체
하드코딩된 데이터베이스 비밀번호는 보안의 가장 큰 취약점 중 하나입니다. AWS Secrets Manager는 RDS 자격 증명의 자동 교체를 기본으로 지원합니다. Parameter Store의 SecureString과 달리 별도 구현 없이 콘솔 설정만으로 자동 교체가 가능합니다.
자동 교체 메커니즘은 다음과 같습니다. 설정한 교체 주기가 되면 Secrets Manager가 내장 Lambda 함수를 호출해 새 비밀번호를 생성하고 RDS에 적용합니다. 교체 중에는 구버전과 신버전이 동시에 유지되어 연결이 끊기지 않는 무중단 롤오버가 이루어집니다.
애플리케이션에서는 하드코딩 대신 API 한 줄로 항상 최신 자격 증명을 가져옵니다. 교체 후에도 코드 변경이 필요 없습니다. Lambda에서도 동일하게 런타임 API 호출로 최신 자격 증명을 획득합니다.
IAM DB 인증은 비밀번호가 필요 없지만 15분마다 토큰을 재발급받아야 하고, 코드와 RDS 설정 모두 변경이 필요합니다. 운영 복잡도를 최소화하면서 자동 교체를 원한다면 Secrets Manager가 명확한 선택입니다.
S3 Block Public Access — 4가지 설정의 이해
S3 Block Public Access는 퍼블릭 접근을 차단하는 4가지 설정으로 구성됩니다. 시험에서는 각 설정의 정확한 동작 방식을 묻는 문제가 출제됩니다.
| 설정 | 동작 | |------|------| | BlockPublicAcls | 새 퍼블릭 ACL 추가 차단, 기존 ACL은 유지 | | IgnorePublicAcls | 기존 퍼블릭 ACL 즉시 무효화 (수동 제거 불필요) | | BlockPublicPolicy | 퍼블릭 접근 허용 버킷 정책 추가 차단 | | RestrictPublicBuckets | 퍼블릭 버킷 정책이 있어도 퍼블릭 접근 차단 |
IgnorePublicAcls가 특히 중요합니다. 이 설정은 기존에 존재하는 퍼블릭 ACL을 수동으로 제거할 필요 없이 즉시 무효화합니다. Block Public Access 활성화 후에도 Presigned URL은 정상 동작하므로 애플리케이션 코드 변경이 불필요합니다. 계정 수준에서 일괄 적용하면 모든 버킷에 적용되어 운영 오버헤드를 최소화할 수 있습니다.
!S3 Block Public Access의 설정 4가지
AWS Config Rules + SSM Automation — 자동 교정
AWS Config는 리소스 구성이 정의된 규칙을 준수하는지 지속적으로 평가합니다. 규칙을 위반하면 자동 교정(Auto Remediation)을 통해 SSM Automation Document를 실행해 문제를 자동으로 수정할 수 있습니다.
실용적인 예시를 들면, 관리형 규칙은 SSH(22번 포트)를 0.0.0.0/0에 허용한 보안 그룹을 자동으로 탐지합니다. 탐지 즉시 SSM Automation이 해당 보안 그룹 규칙을 제거하도록 자동 교정을 설정할 수 있습니다.
GuardDuty와의 차이를 명확히 해야 합니다. Config는 설정 컴플라이언스(리소스가 올바르게 구성되었는가)를 검사하고, GuardDuty는 트래픽 패턴과 행동 분석으로 위협을 탐지합니다. 두 서비스는 상호 보완적입니다.
EventBridge와 연동하면 Config Rule 위반 시 SNS를 통해 이메일·SMS·Lambda로 알림을 전송할 수 있습니다. 에이전트가 필요 없고 관리형 규칙으로 즉시 활성화할 수 있어 운영 오버헤드가 낮습니다.
GuardDuty + EventBridge + Lambda 자동 대응
보안 위협을 탐지하는 것만으로는 부족합니다. 탐지 즉시 자동으로 대응하는 파이프라인을 구성해야 합니다.
GuardDuty가 위협 Finding을 생성하면 EventBridge가 이를 감지합니다. EventBridge 규칙으로 특정 Finding 유형(예: EC2 인스턴스에서 비트코인 마이닝 탐지)을 필터링해 Lambda를 트리거합니다. Lambda는 해당 인스턴스의 보안 그룹을 변경하거나 IAM 키를 비활성화하는 자동 대응을 수행합니다.
IAM 시크릿 자동 탐지 파이프라인도 유사합니다. GitLeaks가 Git 커밋 내 IAM 키를 탐지하면 EventBridge가 Lambda를 트리거하고, Lambda는 API를 호출해 키를 즉시 비활성화합니다. SNS로 개발자와 보안팀에 동시에 알림을 전송합니다. 이 패턴은 커밋 단계에서 시크릿을 차단하는 Shift-Left 보안의 구현 방법입니다.
Patch Manager — 대규모 OS 패치 자동화
수백 대의 서버에 OS 패치를 적용하는 것은 운영 팀의 큰 부담입니다. AWS Systems Manager Patch Manager는 이를 완전히 자동화합니다.
Patch Baseline에서 자동 승인할 패치 규칙을 정의합니다. OS 종류와 심각도별로 세분화할 수 있어, 예를 들어 Critical 패치는 즉시 자동 승인하고 Important 패치는 7일 후 자동 승인하도록 설정할 수 있습니다.
Maintenance Windows에서는 패치를 실행할 일정, 시간, 대상 서버를 세밀하게 제어합니다. Patch Group 태그를 활용하면 환경별(개발/스테이징/프로덕션)로 다른 Patch Baseline을 적용할 수 있습니다.
SSM Agent 하나로 AWS 인스턴스와 온프레미스 서버를 함께 관리하는 하이브리드 지원도 중요한 특징입니다. Systems Manager 콘솔에서 미패치 서버 현황을 중앙에서 모니터링할 수 있어 컴플라이언스 관리가 용이합니다.
신뢰성 개선 — SPOF 제거와 자가 치유
신뢰성 개선의 핵심은 단일 장애 지점(SPOF, Single Point of Failure)을 제거하고 자가 치유(Self-Healing) 능력을 갖추는 것입니다.
Multi-AZ 배포는 SPOF 제거의 기본입니다. Amazon Aurora는 3개 AZ에 6개의 복제본을 유지합니다. 장애 감지 후 30초 이내에 Replica가 Primary로 자동 승격됩니다. RDS Multi-AZ는 2개 AZ 동기 복제이지만, Aurora는 3개 AZ 분산 스토리지로 더 높은 내구성을 제공합니다.
Auto Scaling 헬스 체크는 자가 치유의 핵심 메커니즘입니다. EC2 인스턴스가 비정상 상태가 되면 Auto Scaling이 자동으로 교체합니다. Route 53 Failover 라우팅 정책과 연계하면 리전 수준 장애도 자동으로 처리할 수 있습니다.
Route 53 프라이빗 IP 페일오버는 특별한 주의가 필요합니다. Route 53은 VPC 내부 프라이빗 IP를 직접 헬스 체크할 수 없습니다. 대신 CloudWatch Alarm 기반 헬스 체크를 사용합니다. CloudWatch Agent가 EC2 내 애플리케이션 상태 지표를 수집하고 Alarm을 트리거하면, Route 53이 이 Alarm 상태를 기반으로 DNS 레코드를 자동 전환합니다.
AWS Backup — 중앙 집중식 백업 거버넌스
AWS Backup은 여러 AWS 서비스의 백업을 중앙에서 관리합니다. 백업 스케줄과 보존 정책을 자동화하고, 크로스 계정과 크로스 리전 복사도 지원합니다. DLM(Data Lifecycle Manager)은 EBS 볼륨의 단순 수명 주기 관리에 사용하지만, 크로스 계정·크로스 리전 거버넌스가 필요할 때는 AWS Backup이 더 적합합니다.
EBS direct APIs는 인스턴스를 마운트하거나 SSH 없이 스냅샷의 블록 데이터를 직접 읽고 쓸 수 있습니다. 과 를 사용하면 변경된 블록만 선택적으로 추출할 수 있어 포렌식 분석이나 데이터 검증에 활용됩니다. Snapshots Archive는 90일 이상 보관이 필요한 스냅샷을 저비용으로 아카이빙하지만, 복원에 24~72시간이 소요됩니다.
시험 핵심 정리
"AMI 빌드 자동화 + CVE 취약점 평가 동시 요구" -- EC2 Image Builder + Amazon Inspector
"RDS 자격 증명 자동 교체, 코드 변경 최소화" -- AWS Secrets Manager (Parameter Store는 자동 교체 미지원)
"기존 퍼블릭 ACL 즉시 무효화" -- S3 Block Public Access IgnorePublicAcls 설정
"보안 그룹 SSH 허용 자동 탐지 및 교정" -- AWS Config restricted-ssh 규칙 + SSM Automation
"위협 탐지 후 자동 대응 파이프라인" -- GuardDuty → EventBridge → Lambda
"대규모 OS 패치 자동화, 하이브리드 지원" -- Systems Manager Patch Manager + Maintenance Windows
"VPC 내부 프라이빗 IP 페일오버" -- CloudWatch Alarm 기반 Route 53 헬스 체크 (직접 헬스 체크 불가)
"Config(설정 컴플라이언스) vs GuardDuty(트래픽 위협 탐지)" -- 용도 혼동 주의
"크로스 계정·크로스 리전 백업 거버넌스" -- AWS Backup (DLM은 단일 계정 EBS 전용)
"ElastiCache Redis 암호화 사후 활성화" -- 불가, 신규 클러스터 생성 후 Blue/Green 전환 필요