Amazon SAA-C03: 고가용성, 내결함성 및 재해 복구 — 학습 가이드

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SAA-C03 — 완벽 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

다중 AZ 배포 및 복제

다중 AZ(Multi-AZ) 아키텍처는 단일 데이터 센터 또는 가용 영역(Availability Zone)의 장애에 대응하기 위한 것입니다. 그 이상은 아닙니다. 이 차이점은 고가용성 설계에서 가장 많이 오해되는 부분입니다. 다중 AZ 배포는 한 리전 내의 AZ 손실은 허용하지만, 리전 전체의 중단, 리전 서비스 장애, 또는 대기 인스턴스로 삭제 작업이 즉시 복제되는 리소스의 우발적 삭제는 허용하지 않습니다. 복제는 논리적 손상, 스키마 실수, 랜섬웨어 쓰기와 같은 잘못된 데이터를 충실하게 전파합니다. 이것이 바로 복제와 백업이 대체 관계가 아닌 상호 보완적인 관계인 이유입니다.

Amazon RDS의 경우, 다중 AZ는 다른 AZ에 동기식 대기 복제본을 프로비저닝합니다. 쓰기는 승인 전에 두 인스턴스 모두에 커밋되므로, RPO는 실질적으로 0이 되고 자동 장애 조치 시 RTO는 일반적으로 60-120초가 됩니다. 전통적인 다중 AZ 인스턴스 배포에서는 대기 인스턴스를 읽을 수 없으며, 순전히 내구성과 장애 조치를 위해서만 존재합니다. 다중 AZ 클러스터 배포(읽기 가능한 두 개의 대기 인스턴스)는 장애 조치 시간을 더욱 단축하고 일부 읽기 확장성을 제공하지만, 여전히 단일 리전에 국한됩니다.

읽기 확장성을 위해서는 **읽기 전용 복제본(read replicas)**을 추가합니다. 읽기 전용 복제본은 비동기식 복제를 사용하며, 리포팅, 분석, 대시보드 쿼리의 부하를 분산시키는 역할을 합니다. 읽기 전용 복제본을 HA 장애 조치 메커니즘으로 취급하는 것은 세 가지 이유로 잘못되었습니다. 복제가 비동기식이어서 승격 시 데이터 손실이 발생할 수 있고, 승격이 수동 또는 스크립트로 이루어지며(자동이 아님), 기본 엔드포인트가 유지되지 않기 때문입니다. 워크로드가 증가하여 새로운 복잡성 없이 더 많은 읽기 용량이 필요할 때는 읽기 전용 복제본을 추가하고, 데이터 손실 없는 자동 장애 조치가 요구될 때는 다중 AZ를 사용합니다. 관계형 엔진에서 리전 장애를 극복해야 하는 RPO/RTO 요구사항이 있다면, Aurora Global Database가 1초 미만의 리전 간 복제 지연 시간과 1분 미만의 관리형 장애 조치 RTO를 제공합니다.

Amazon ElastiCache도 복제 그룹(replication groups)을 통해 동일한 패턴을 따릅니다. 다중 AZ가 활성화된 Redis 복제 그룹은 여러 AZ에 걸쳐 프라이머리와 하나 이상의 복제본을 유지합니다. 프라이머리에 장애가 발생하면 ElastiCache가 복제본 중 하나를 승격시키고 기본 엔드포인트를 업데이트합니다. 수평적 확장을 위해 Redis(클러스터 모드 활성화)는 데이터를 여러 샤드에 걸쳐 파티셔닝하며, 각 샤드는 자체적인 복제 그룹이 됩니다. 반면 Memcached는 복제하지 않으므로, 노드 손실은 해당 파티션의 데이터 손실을 의미합니다.

Amazon FSx는 FSx for Windows File Server와 FSx for ONTAP에 대해 다중 AZ 배포 유형을 제공하며, 기본 파일 서버와 대기 파일 서버 간에 동기식 복제를 사용합니다. FSx for Lustre는 일반적으로 단일 AZ(스크래치 또는 영구) 방식입니다. Lustre의 내구성은 AZ 복제가 아닌 S3 데이터 리포지토리 연결을 통해 확보됩니다.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

RDS 자동 백업 및 지정 시간 복구

RDS 자동 백업은 일일 스냅샷과 5분 간격의 지속적인 트랜잭션 로그 S3 업로드를 결합하여, 1일에서 35일 사이의 보존 기간 내에 원하는 시점으로 **지정 시간 복구(PITR)**를 가능하게 합니다. RPO가 2시간이라면 RDS의 기본 백업만으로도 충분합니다. 추가적인 스냅샷 스케줄링이 필요 없으며, RDS 스냅샷 복사 기능이 제공하는 것 이상의 리전 간 복사, 계정 간 격리, 또는 Vault Lock 시맨틱이 필요한 경우가 아니라면 AWS Backup을 추가로 사용하는 것은 중복입니다. 적당한 수준의 RPO 요구사항에 대해서는 기본 자동 백업이 가장 저렴하고 올바른 해결책인 경우가 많습니다.

중앙 제어 플레인으로서의 AWS Backup

AWS Backup은 EBS, EC2(AMI 형태), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3 등 다양한 서비스의 백업을 위한 정책 기반 중앙 제어 플레인입니다. 서비스별 스냅샷 로직을 스크립트로 작성하는 대신, 빈도, 백업 기간, 시작/완료 기간, 콜드 스토리지로의 수명 주기 전환, 보존 기간, 대상 볼트를 기술하는 규칙들을 그룹화한 **백업 계획(backup plans)**을 정의합니다. 리소스는 태그나 ARN을 통한 **리소스 할당(resource assignments)**을 통해 등록되므로, Backup=Daily와 같은 태그 지정 규칙이 백업 적용 범위를 관리하는 운영상의 계약이 됩니다. 수백 개의 EC2 인스턴스 그룹의 경우, 태그 기반 선택이 가장 노력이 적게 드는 접근 방식입니다. 인스턴스별 스케줄을 작성하는 대신 태그를 적용하고 AWS Backup이 리소스를 열거하도록 하면 됩니다.

**백업 볼트(backup vault)**는 복구 지점이 저장되는 KMS 암호화 컨테이너입니다. 접근은 볼트의 리소스 정책에 의해 제어됩니다.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

리전 간 및 계정 간 복사

CopyActions 블록은 리전 간(cross-Region) DR 복사를 위한 메커니즘입니다. AWS Backup은 스냅샷 복사를 처리하고, 대상 리전의 KMS 키로 다시 암호화하며(대상 볼트는 해당 리전의 키를 참조해야 함), 독립적인 수명 주기를 적용합니다. EBS와 RDS 스냅샷은 기본적으로 소스 리전에 저장됩니다. 만약 리전 전체에 장애가 발생하면 스냅샷도 영향을 받습니다. 리전 복원력을 언급하는 규제 또는 비즈니스 요구사항은 AWS Backup 복사 작업, RDS 자동 스냅샷의 리전 간 복사, 또는 리전 간 대상을 지정한 DLM 정책 등을 통해 명시적인 리전 간 복사 단계를 포함해야 합니다.

계정 간(cross-account) 복사의 경우, AWS Organizations를 통해 AWS Backup의 관리자 계정을 위임합니다. 소스 볼트의 정책은 대상 계정을 허용하고, 대상 볼트는 소스로부터의 복사를 허용합니다. 이것이 DR을 중앙 집중화하는 비용 효율적인 방법입니다. 하나의 관리 계정이 여러 워크로드 계정의 복구 지점을 보유하고 어느 리전으로든 복원할 수 있습니다. EC2의 경우, AMI를 두 번째 리전으로 복사하고 스냅샷을 공유하면 웜(warm) 인프라 없이도 해당 리전에서 인스턴스를 시작할 수 있습니다. 암호화된 스냅샷은 CMK 공유가 필요합니다. — 대상 계정이나 리전은 kms:CreateGrant 권한과 해당 키에 대한 접근 권한이 있어야 합니다. 이 부분이 누락되면 계정 간 복원이 조용히 실패하는 원인이 됩니다.

24시간의 RPO는 리전 간으로 복사되는 일일 자동 스냅샷으로 저렴하게 충족할 수 있습니다. 이는 리전 간 읽기 전용 복제본이나 웜 스탠바이 클러스터보다 훨씬 비용이 적게 듭니다. RPO가 스냅샷 주기로 감당할 수 있는 수준보다 낮아질 때만 지속적인 복제로 전환해야 합니다.

AMI 수명 주기와 EC2 백업

EC2 백업을 자동화하는 메커니즘은 **Data Lifecycle Manager (DLM)**와 AWS Backup 두 가지가 있습니다. DLM은 AWS Backup보다 먼저 나왔으며, 정책 기반으로 EBS 스냅샷이나 AMI를 정해진 스케줄에 따라 생성하고 리전 간 및 계정 간 복사 작업을 수행합니다. AWS Backup은 이 기능을 포함하면서 중앙 집중식 정책, Vault Lock, 여러 서비스를 포괄하는 기능을 추가합니다. 이미 다른 서비스에 AWS Backup을 사용하고 있다면 AWS Backup을 선호하고, 볼트 기능이 필요 없는 순수 EBS/AMI 시나리오에서는 DLM을 사용하세요.

Auto Scaling 그룹 뒤에 있고 영구적인 로컬 데이터가 없는 상태 비저장(stateless) 웹 티어의 경우, 실행 중인 EC2 인스턴스를 백업하는 것은 낭비입니다. 올바른 방식은 EC2 Image Builder나 CI 파이프라인을 통해 강화된 AMI를 만들고(bake), 시작 템플릿에서 이를 참조하여 ASG가 인스턴스 교체를 처리하도록 하는 것입니다. 백업 작업은 상태 저장(stateful) 티어에 집중해야 하며, 이 티어의 네이티브 자동 백업 기능으로 RPO를 충족시킵니다.

불변성: Vault Lock과 Object Lock

계정에 있는 일반 스냅샷은 적절한 IAM 권한을 가진 누구나 삭제할 수 있습니다. 스냅샷만으로는 불변성 요구 사항을 충족하지 못합니다. 규제 체제(SEC 17a-4, FINRA, HIPAA, GDPR)는 관리자조차 우회할 수 없는 WORM(Write-Once-Read-Many) 보존을 요구하는 경우가 많습니다. 두 가지 AWS 메커니즘이 이를 제공합니다.

AWS Backup Vault Lock은 백업 볼트에 WORM을 강제합니다:

규정 준수 모드에서는 유예 기간이 지나면 root 계정을 포함한 어떤 사용자도 보존 기간을 단축하거나, 만료 전에 복구 지점을 삭제하거나, 잠금 자체를 제거할 수 없습니다. 이는 내부자의 삭제 행위와 계정을 완전히 장악한 랜섬웨어 공격자 모두를 막아냅니다.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock은 거버넌스 모드(특권 사용자가 s3:BypassGovernanceRetention 권한으로 재정의 가능) 또는 규정 준수 모드(root를 포함한 누구도 보존 기간을 삭제하거나 단축할 수 없음)에서 객체 수준 WORM을 제공합니다. 법적 보존(Legal Hold)은 보존 기간과 무관합니다. Object Lock은 버전 관리가 필요하며, 완전한 보호를 위해서는 버킷 생성 시 활성화해야 합니다.

장애 조치 리전을 위한 용량 예약

대규모 이벤트 발생 당일 장애 조치 리전에서 EC2 용량을 사용할 수 있을 것이라고 가정하는 DR 계획은 계획이 아닙니다. 한 리전이 장애를 일으키면 모두가 동시에 장애 조치를 시도하며, 인스턴스 유형(특히 크거나, GPU를 사용하거나, 특화된 형태)이 고갈될 수 있습니다. 대상 리전의 **On-Demand Capacity Reservations (ODCRs)**는 특정 인스턴스 유형, 플랫폼, AZ에 대한 용량을 보장하며, 사용 여부와 관계없이 요금이 청구됩니다. 비용을 상쇄하려면 Savings Plan과 함께 사용하세요. 장기적인 GPU/ML 약정의 경우 Capacity Blocks가 적용되며, 패밀리 유연성이 필요하다면 Capacity Reservation Fleet이 여러 인스턴스 패밀리를 포괄합니다. 원칙은 이렇습니다: 비즈니스가 DR 리전에서 보장된 컴퓨팅을 요구한다면, 예약하십시오. 최선 노력 기반의 온디맨드 가용성에 의존하지 마십시오.

DR 전략 선택

AWS는 비용/복구 절충점이 각기 다른 네 가지 표준 DR 티어를 정의합니다:

올바른 티어는 아키텍처 선호도가 아니라 비즈니스의 RPO와 RTO에 따라 결정됩니다. 24시간의 RPO는 매일 리전 간 스냅샷 복사(백업 및 복원)를 허용합니다. 수 초의 RPO는 지속적인 복제(리전 간 읽기 전용 복제본, Aurora Global Database, DynamoDB Global Tables 또는 S3 Cross-Region Replication)를 요구합니다. 예산과 상관없이 야간 스냅샷으로 5분의 RPO를 달성하려는 시도는 아키텍처적으로 불가능합니다. 반대로, 모든 워크로드에 액티브-액티브를 기본으로 적용하는 것은 비용 안티패턴입니다. 이는 전역적으로 일관된 데이터(DynamoDB Global Tables 또는 쓰기 전달 기능이 있는 Aurora Global), 전체 규모의 중복 컴퓨팅, Route 53 또는 Global Accelerator를 통한 복잡한 트래픽 조정을 요구합니다. 명시된 RPO/RTO를 충족하는 가장 저렴한 패턴을 선택하십시오. 2시간 RPO의 경우, 백업 및 복원 또는 파일럿 라이트로 충분하며 웜 스탠바이는 과도한 설계입니다.

삭제 방지 및 계층적 보호 조치

복원력은 단순히 “백업이 있는가"의 문제가 아니라 “단일 행위자, 실수 또는 공격으로 백업을 지울 수 있는가"의 문제입니다. 계층적 통제는 한 번의 잘못된 클릭으로 인한 대재앙을 방지합니다:

• RDS: DeletionProtection을 활성화하고 삭제 시 최종 스냅샷을 요구하도록 설정합니다.
• EC2: 중요한 인스턴스에 DisableApiTermination 및 DisableApiStop을 활성화합니다.
• DynamoDB: 삭제 방지 및 특정 시점 복구를 활성화합니다.
• S3: 버전 관리 + MFA 삭제 + 불변성을 위한 Object Lock을 사용합니다.
• CloudFormation: 상태 저장 리소스에 DeletionPolicy: Retain을 설정하고 스택 종료 방지를 활성화합니다.
• IAM SCPs: 비상 역할(break-glass role) 외부에서는 backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance, ec2:DeleteSnapshot을 거부합니다.

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

규정 준수 모드의 Vault Lock과 결합하면, 이러한 조치들은 심층 방어(defense in depth)를 구축합니다. 즉, 관리자 자격 증명이 탈취되더라도 최후의 방어선인 복구 지점을 파괴할 수 없습니다.

흔한 함정

Multi-AZ를 DR로 취급하기. RDS Multi-AZ, ElastiCache Multi-AZ, FSx Multi-AZ는 모두 단일 리전(Region) 내에 존재합니다. 리전 API 중단, 실수로 인한 테이블 삭제, 잘못 적용된 스키마 마이그레이션 등은 두 노드 모두에 영향을 줍니다. ‘다른 리전’, ‘리전 장애’, ‘리전 간 RPO’와 같은 요구사항이 언급되면 반드시 리전 간 복제 또는 복사가 필요합니다. Multi-AZ만으로는 이 요구사항을 충족할 수 없습니다.

읽기 전용 복제본을 HA와 혼동하기. 읽기 전용 복제본은 비동기식이며, 수동으로 승격해야 하고, 엔드포인트가 변경됩니다. 이는 자동 장애 조치가 아닌 읽기 확장성(read scaling) 문제를 해결합니다.

스냅샷이 규정 준수를 의미한다고 가정하기. Vault Lock(규정 준수 모드) 또는 Object Lock이 없는 스냅샷은 적절한 IAM 권한을 가진 모든 보안 주체(principal)나 루트 계정에 의해 삭제될 수 있습니다. WORM 규제 보존 요건을 충족하려면 잠긴 냉각 기간(cooling-off period)이 경과된 명시적인 불변성(immutability) 구성이 필요합니다.

리전 RPO에 대해 로컬 스냅샷만 사용하기. EBS 및 RDS 스냅샷은 기본적으로 소스 리전에 저장됩니다. 리전 복원력(resilience)을 확보하려면 명시적인 리전 간 복사 작업이 필요합니다.

복원 테스트나 예약된 용량 없이 백업하기. 한 번도 복원해 본 적 없는 스냅샷은 백업이 아니라 가설일 뿐입니다. 복원 훈련을 통해 누락된 IAM 역할, 대상 리전 및 계정에서의 KMS 키 액세스 문제, 사용할 수 없는 인스턴스 유형 등을 발견할 수 있습니다. 중요 워크로드를 위한 Capacity Reservations가 없다면, 모두가 동시에 장애 조치를 수행할 때 DR 리전에 필요한 형태의 인스턴스가 없을 수 있으며, 이 경우 RTO는 무한정 길어질 수 있습니다.

액티브-액티브로 과도하게 설계하기. 글로벌 컴퓨팅 이중화, 전 세계적으로 일관된 데이터 복제, 복잡한 트래픽 라우팅은 비용이 많이 듭니다. RPO/RTO가 이를 정당화하지 않는다면, 파일럿 라이트(pilot light)나 웜 스탠바이(warm standby)가 올바른 아키텍처입니다.

상태 비저장(stateless) 티어 백업하기. ASG 뒤에 있는 임시 웹 서버를 스냅샷으로 만드는 것은 비용 낭비이며 복구를 복잡하게 만듭니다. AMI를 만들고(bake), 시작 템플릿에서 이를 참조하며, 백업 투자는 상태 저장(stateful) 데이터에 집중해야 합니다.

← 관리 · 모든 도메인

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →