Amazon SAA-C03: 스토리지 및 데이터 수명 주기 — 학습 가이드

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

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

S3 스토리지 클래스와 비용/지연 시간 스펙트럼

S3 스토리지 클래스는 GB당 스토리지 비용과 검색 지연 시간, 최소 스토리지 기간, GB당 검색 요금을 맞바꾸는 스펙트럼에 존재합니다. 올바른 클래스를 선택하는 것은 객체 스토리지 비용 최적화에서 가장 큰 단일 수단입니다.

S3 Standard는 기본값입니다: 3개 이상의 AZ에 걸친 99.999999999%의 내구성, 밀리초 단위의 지연 시간, 검색 요금 없음, 가장 높은 GB당 가격. Standard-IA와 One Zone-IA는 스토리지 비용을 약 40-50% 절감하지만, GB당 검색 요금, 30일의 최소 청구 기간, 128KB의 최소 객체 크기가 추가됩니다(더 작은 객체는 128KB로 청구되어 절감 효과를 잠식합니다). One Zone-IA는 단일 AZ에 저장하여 비용을 더욱 절감합니다. 이는 단일 AZ 손실을 감내할 수 있는, 재현 가능한 보조 복사본에만 적합합니다.

S3 Intelligent-Tiering은 액세스 패턴을 알 수 없거나, 예측 불가능하거나, 대규모 데이터 집합 전반에 걸쳐 변동이 심할 때 올바른 선택입니다. 이 클래스는 관찰된 액세스 패턴에 따라 frequent, infrequent, archive-instant, archive, deep-archive 티어 간에 객체를 자동으로 마이그레이션하며, 객체당 소액의 모니터링 요금을 부과합니다. frequent 티어와 infrequent 티어 간에는 검색 요금이 없고 최소 기간도 없기 때문에, 128KB 이상의 객체를 사용하는 데이터 레이크 및 혼합 워크로드에 가장 안전한 기본 선택입니다. 객체가 영구적으로 자주 액세스되거나(추가 모니터링 비용 발생) 10년 동안 영구적으로 거의 액세스되지 않을 것임을 이미 알고 있는 경우(Deep Archive가 훨씬 저렴함)에는 잘못된 선택입니다.

Glacier Instant Retrieval은 분기별 또는 그보다 드물게 액세스되는 데이터(예: 의료 이미지, 요청 시 즉시 제공해야 하는 규정 준수 PDF)에 대해 아카이브 가격으로 밀리초 단위 액세스를 제공합니다. Glacier Flexible Retrieval은 분에서 시간 단위의 검색을 제공합니다. Glacier Deep Archive는 월별 약 1달러/TB로 AWS에서 가장 저렴한 티어이며, 12시간의 표준 검색(또는 48시간의 대량 검색)과 180일의 최소 기간을 가집니다. 7-10년의 규제 데이터 보존 및 테이프 교체에 적합한 해답입니다.

두 가지 주요 비용 함정은 정반대의 실수에서 비롯됩니다. 장기간 거의 읽지 않는 데이터를 위해 Standard를 선택하는 것은 돈을 낭비하는 일입니다. Standard에는 콜드 스토리지 가격 할인이 없기 때문입니다. 수년간 Standard에 보관된 5TB 데이터 세트는 Deep Archive에 보관된 동일한 데이터보다 몇 배 더 많은 비용이 듭니다. 반대로, 새로운 객체를 바로 Standard-IA나 Glacier로 옮기는 것도 함정입니다. 객체가 아직 활발히 액세스되는 동안에는 30/90/180일의 최소 요금과 검색 요금이 절감액을 초과하기 때문입니다. Glacier Flexible 또는 Deep Archive는 동기식 읽기를 기대하는 모든 워크로드와는 완전히 호환되지 않습니다. HTTP GET을 기다리는 사용자는 분에서 12시간에 이르는 검색 SLA를 견딜 수 없습니다. Glacier Instant Retrieval은 즉시 액세스와 호환되는 유일한 Glacier 티어입니다.

수명 주기 정책과 버전 관리

수명 주기 구성은 버킷에 연결된 선언적 JSON/YAML로, 객체의 수명, 태그 또는 접두사를 기반으로 객체를 전환하거나 만료시킵니다. 전환은 하루에 한 번 평가되며 지정된 수명에 도달한 후에만 실행됩니다. 예를 들어 Days: 30 전환은 처음 30일 동안 Standard 요금이 적용된다는 의미입니다. 전환은 점진적으로 더 저렴한(colder) 티어로 이동해야 하며, 128KB보다 작은 객체는 객체당 오버헤드가 절감액보다 크기 때문에 Standard에서 IA로 전환되지 않습니다. 먼저 tar/zip 또는 S3 Batch Operations를 통해 작은 객체들을 통합해야 합니다.

처음 30일 동안은 활발히 액세스되고 그 이후에는 거의 액세스되지 않지만, 전체 기간 동안 즉시 액세스가 필요하며, 4년간 보존되고, 적절한 데이터 위생 관리를 포함하는 워크로드의 표준적인 정책은 다음과 같습니다:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

자주 발생하는 버전 관리 함정: 버전 관리가 활성화된 버킷에서 현재 버전의 객체를 만료시키는 수명 주기 규칙은 삭제 마커만 삽입할 뿐입니다. 이전 버전들은 조용히 누적되어 계속 요금이 청구됩니다. 현재 버전이 아닌 객체(Noncurrent versions)는 별도의 NoncurrentVersionTransitions 및 NoncurrentVersionExpiration 규칙이 명시적으로 필요합니다. 마찬가지로, 항상 AbortIncompleteMultipartUpload를 포함해야 합니다. 완료되지 않은 멀티파트 업로드의 조각(orphaned multipart parts)은 콘솔 목록에 보이지 않으며 무기한으로 스토리지 비용이 발생합니다.

혼합된 패턴의 경우, 예를 들어 첫 달에는 ML 훈련을 위해 활발히 사용되고, 그 후 1년 동안은 분기별로 쿼리된 다음, 아카이브되는 IoT 원격 측정 데이터의 경우, 올바른 해답은 첫 1년 동안 Intelligent-Tiering을 사용하여 (훈련 폭주 기간과 유휴 기간 사이에서 클래스가 자동 최적화되도록 하고) 365일째에 Deep Archive로 전환하도록 예약하는 것입니다.

버전 관리, MFA Delete, 객체 잠금

버전 관리는 한번 활성화하면 일시 중단만 가능하며, 비활성화할 수는 없습니다. 모든 PUT 요청은 새로운 버전 ID를 생성하며, DELETE 요청은 데이터를 제거하는 대신 삭제 마커(delete marker)를 삽입합니다. 버전 관리는 실수로 덮어쓰는 것을 방지하지만, 불변성(immutability)을 보장하지는 않습니다. s3:DeleteObjectVersion 권한이 있는 모든 보안 주체는 특정 버전을 영구적으로 제거할 수 있습니다. MFA Delete는 루트 계정이 버전을 영구적으로 제거하거나 버전 관리 상태를 변경할 때 MFA 토큰을 제시해야 하는 요구 사항을 추가합니다. 이를 통해 가치가 높은 버킷의 실수로 인한 삭제 가능성을 줄일 수 있지만, 권한 있는 행위자가 데이터를 파괴하는 것을 막지는 못합니다.

진정한 불변성을 위해서는 S3 Object Lock이 필요하며, 이는 버전 관리를 요구하고 일반적으로 버킷 생성 시 활성화해야 합니다. 자주 혼동되는 두 가지 모드가 있습니다.

보존은 객체별(Retain-Until-Date)로 적용하거나 만료일이 없는 **법적 보존(Legal Hold)**을 통해 적용할 수 있습니다. 1년 동안 hot 상태로, 9년 동안 아카이브 상태로 보관하고 10년 동안 삭제하지 않아야 하는 회계 기록의 경우, 올바른 패턴은 10년 보존 기간을 설정한 규정 준수 모드의 Object Lock과, 365일째에 Deep Archive로 전환하는 수명 주기 정책을 결합하는 것입니다. 거버넌스 모드는 법적 요구 사항을 대체할 수 없습니다. 규제 기관은 ‘권한 있는 누군가가 이것을 삭제할 수 있었다’는 상태를 불변성으로 인정하지 않을 것입니다.

기존의 대량 PDF 파일에 단일 작업으로 보존 설정을 적용하려면 S3 Inventory 매니페스트를 기반으로 하는 S3 Batch Operations를 사용합니다. Batch Operations는 수십억 개의 키에 걸쳐 보존, 태깅, PUT-copy 재암호화, Lambda 호출과 같은 대규모 변경 작업을 위한 관리형 솔루션입니다. 직접 작성한 반복 스크립트는 올바른 패턴이 아닙니다.

암호화: SSE-S3, SSE-KMS, Bucket Keys

모든 버킷에는 기본 암호화가 설정되어 있습니다. SSE-S3(AES-256, S3 관리형 키)는 무료이며 키 관리가 필요 없습니다. SSE-KMS는 KMS 고객 마스터 키(CMK)를 사용하여 키별 CloudTrail 감사 추적, IAM 기반 키 액세스 정책, 키 순환 제어를 가능하게 합니다. 하지만 KMS API 요금이 발생하고, 더 중요하게는 처리량이 많은 읽기 워크로드에 병목 현상을 일으킬 수 있는 KMS 요청 제한(throttling)이 발생할 수 있습니다. 이러한 제어(규제 증명, 직무 분리, 교차 계정 키 공유)가 실제로 필요할 때 SSE-KMS를 선택하십시오. SSE-S3로도 요구 사항을 충족할 수 있는데 ‘안전을 위해’ SSE-KMS를 기본으로 사용하면 불필요한 비용과 복잡성이 추가됩니다.

S3 Bucket Keys는 SSE-KMS의 요청 비용 문제를 해결합니다. S3는 CMK에서 수명이 짧은 버킷 수준 키를 생성하고 이를 기반으로 객체별 데이터 키를 로컬에서 파생시켜, 객체마다 KMS GenerateDataKey/Decrypt를 호출하는 것을 방지하고 KMS 요청 비용을 최대 99%까지 절감할 수 있습니다.

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

요구 사항에서 KMS 사용을 의무화하는 경우 ‘KMS 비용을 피하기 위해’ SSE-S3로 전환하는 것은 잘못된 해결 방법입니다. Bucket Keys는 KMS를 포기하지 않으면서 규정 준수와 비용 목표를 모두 만족시킵니다.

버킷 기본 암호화를 활성화하면 모든 향후 업로드가 암호화됩니다(암호화되지 않은 PUT 요청은 투명하게 암호화됩니다). 암호화되지 않은 PUT 요청을 완전히 거부하려면, 해당 헤더가 없는 쓰기 요청을 거부하십시오.

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

기본 암호화는 기존의 암호화되지 않은 객체에는 아무런 영향을 미치지 않습니다. 각 키를 제자리에서 덮어쓰는 Copy 작업을 실행하는 S3 Inventory + Batch Operations를 통해 재암호화하십시오. 이것이 표준적인 대량 재암호화 패턴입니다.

임시방편적인 클라이언트 측 암호화는 기본 암호화와 KMS를 함께 사용하는 것보다 열등합니다. 키 관리가 애플리케이션 팀 전반에 분산되고, CloudTrail KMS 이벤트를 통해 중앙에서 감사할 수 없으며, Bucket Keys를 사용할 수 없습니다.

교차 리전 복제와 다중 리전 KMS 키

**교차 리전 복제(Cross-Region Replication, CRR)**는 규정 준수, 재해 복구(DR) 또는 지연 시간 단축을 위해 객체를 다른 리전의 버킷으로 비동기적으로 복사합니다. **동일 리전 복제(Same-Region Replication, SRR)**는 규정 준수를 위한 분리, 로그 집계, 교차 계정 복사 등의 목적에 사용됩니다. 두 기능 모두 소스 및 대상 버킷에 버전 관리가 활성화되어 있어야 하며, 소스 버킷이 수임할 IAM 역할이 필요합니다. 버킷을 다른 리전으로 미러링해야 할 때 CRR은 가장 적은 노력으로 구현할 수 있는 해결책입니다. aws s3 sync 스크립트를 작성하거나, ObjectCreated 이벤트에 Lambda를 연결하거나, 예약된 배치 복사를 실행하는 것은 운영 오버헤드, 경쟁 조건(race condition), 조용한 실패(silent failure)를 유발합니다. CRR과 SRR 모두 기본적으로 기존 객체를 복제하지 않습니다. 기존 객체를 채우려면 S3 Batch Replication을 사용하십시오.

암호화와의 상호 작용은 설계 시 흔히 실패하는 지점입니다.

• SSE-S3 객체는 투명하게 복제됩니다.
• SSE-KMS 객체는 기본적으로 복제되지 않습니다. 명시적으로 옵트인하고, 대상 리전에 있는 대상 KMS 키를 지정하고, 복제 역할에 소스 키에 대한 kms:Decrypt 권한과 대상 키에 대한 kms:Encrypt 권한을 부여해야 합니다. 단일 리전 키는 다른 리전의 객체를 암호화할 수 없습니다.
• 클라이언트 측에서 암호화된 객체는 불투명한 암호문(ciphertext)으로 복제됩니다. 클라이언트의 키 물질을 대상 리전에서 사용할 수 없다면 아무런 이득이 없습니다.

두 개의 독립적인 CMK를 관리해야 했던 기존의 불편함은 **AWS KMS 다중 리전 키(multi-Region keys)**로 해결됩니다. 다중 리전 키는 여러 리전에서 동일한 키 물질과 키 ID(리전 접두사 포함)를 제공합니다. 이를 통해 복제된 객체는 리전 간 KMS 호출이나 데이터 키를 다시 래핑(re-wrapping)할 필요 없이 대상 리전에서 해독될 수 있습니다. 이것이 리전 장애 조치 시에도 사용 가능해야 하는 암호화된 복제 버킷을 위한 표준 패턴입니다.

고객 관리형 KMS 키를 사용하여 교차 계정 스냅샷 및 객체를 공유하려면, 대상 계정의 보안 주체가 키 정책을 통해 소스 키에 대한 kms:Decrypt, kms:CreateGrant, kms:DescribeKey, kms:ReEncrypt* 권한을 보유해야 하며, 이에 상응하는 IAM 권한도 필요합니다. AWS 관리형 키(예: aws/ebs, aws/s3)는 계정 간에 공유할 수 없으므로, 교차 계정 워크플로에는 고객 관리형 키가 필수입니다.

퍼블릭 액세스 차단 및 CloudFront로 액세스 제한

**S3 퍼블릭 액세스 차단(BPA)**에는 버킷별로, 그리고 더 중요하게는 계정 수준에서 구성할 수 있는 네 가지 설정(새 퍼블릭 ACL 차단, 기존 퍼블릭 ACL 무시, 새 퍼블릭 버킷 정책 차단, 퍼블릭 버킷 정책 제한)이 있습니다. 계정 수준 BPA는 퍼블릭 액세스를 허용하는 모든 버킷 정책보다 우선하며, “이 계정의 어떤 객체도 퍼블릭이 될 수 없음"을 위한 올바른 제어 방식입니다. 버킷 수준 정책만으로는 취약합니다. 새 버킷이 정책 없이 생성될 수 있지만, 계정 수준 BPA는 기본적으로 차단하는 안전 실패(fail-closed) 방식입니다.

멤버 계정의 관리자가 BPA를 비활성화하는 것을 방지하려면, Organizations OU 또는 루트 수준에서 서비스 제어 정책(SCP)을 계층적으로 적용하십시오.

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

CloudFront를 통해서만 S3 콘텐츠를 제공하려면, 배포에 Origin Access Control(OAC)(레거시 OAI를 대체하는 최신 기능)을 연결하고 배포 ARN을 기준으로 버킷 정책을 제어합니다.

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

BPA는 버킷에서 활성화된 상태로 유지됩니다. 특정 사용자가 프라이빗 객체에 시간제한으로 액세스(업로드/다운로드 만료)해야 하는 경우, 서명 주체의 권한을 상속하는 내장된 서명을 가진 **미리 서명된 URL(presigned URL)**을 생성합니다.

프라이빗 네트워크 경로: 게이트웨이 엔드포인트

VPC 내의 EC2-S3 트래픽은 자동으로 AWS 프라이빗 백본을 사용하지 않습니다. 별도 구성이 없으면 S3 API 호출은 퍼블릭 엔드포인트로 확인되어 인터넷 게이트웨이나 NAT 게이트웨이를 통과하며, 이로 인해 NAT 데이터 처리 요금이 발생하고 트래픽이 인터넷에 노출됩니다. S3용 게이트웨이 VPC 엔드포인트(및 DynamoDB용)는 무료이며, 지정된 라우팅 테이블에 접두사 목록(prefix-list) 라우트로 추가되어 트래픽을 AWS 네트워크 내에 유지합니다. S3용 인터페이스 엔드포인트(PrivateLink)도 존재하며 유료이지만, Direct Connect를 통해 온프레미스에서 액세스해야 할 때 유용합니다. 규제 대상 워크로드의 표준 패턴으로, 엔드포인트와 버킷 정책의 aws:SourceVpce 조건을 결합하여 승인된 VPC 엔드포인트에서만 버킷에 접근할 수 있도록 강제합니다.

실시간 변환을 위한 Object Lambda

S3 Object Lambda는 GET/HEAD/LIST 경로에 Lambda 함수를 삽입하여 호출자에게 반환되는 객체가 읽기 시점에 변환되도록 합니다. 이를 통해 각 변형(수정, 크기 조정, 형식 변환)에 대해 데이터를 복제하는 것을 방지하고, 기본 버킷에 단일 진실 공급원(single source of truth)을 유지합니다. 일반적인 사용 사례로는 분석가를 위한 개인 식별 정보(PII) 수정 대 감사자를 위한 전체 데이터 제공, 사용자별 이미지 워터마킹, 레거시 클라이언트를 위한 XML-JSON 변환 등이 있습니다. IAM 및 버킷 정책은 여전히 기본 객체에 대한 접근을 제어하며, Lambda는 자신의 실행 역할이 허용하는 것만 볼 수 있습니다.

이벤트 알림

S3는 Lambda, SQS, SNS 또는 EventBridge로 이벤트(s3:ObjectCreated:*, s3:ObjectRemoved:*, 복제 및 수명 주기 이벤트)를 발생시킵니다. 여러 대상이 필요하거나, 객체 메타데이터를 기반으로 필터링하거나, 계정 간 라우팅이 필요할 때는 EventBridge가 선호됩니다. 업로드 시 썸네일 생성과 같은 단일 대상 파이프라인의 경우 직접 알림이 더 간단하고 저렴합니다. 알림은 최소 한 번(at-least-once) 전송되므로, 소비자는 멱등성(idempotent)을 가져야 합니다.

처리량 최적화: 멀티파트 업로드 및 Transfer Acceleration

100MB가 넘는 객체의 경우 멀티파트 업로드가 권장 사항이며, 5GB가 넘으면 필수입니다. 파트는 병렬로 업로드되고, 실패한 파트는 독립적으로 재시도되며, 처리량은 동시성에 따라 확장됩니다. 바이트 범위 GET(Byte-range GET)은 다운로드 시 유사한 병렬 처리 효과를 제공합니다. 앞서 언급했듯이, 고립된 파트에 대한 요금 청구를 피하기 위해 항상 AbortIncompleteMultipartUpload 수명 주기 규칙을 연결해야 합니다.

S3 Transfer Acceleration은 AWS 백본을 통해 가장 가까운 CloudFront 엣지로 업로드를 라우팅합니다. 이는 전 세계에 분산된 클라이언트가 단일 버킷으로 업로드할 때 사용합니다. 다운로드의 경우, S3 앞에 CloudFront를 두어 엣지에서 캐시합니다. Transfer Acceleration은 업로드 중심이고 CloudFront는 다운로드 중심이며, 서로 관련 있지만 별개의 문제를 해결합니다.

EBS: 볼륨 유형, 암호화, 스냅샷

EBS 볼륨은 단일 EC2 인스턴스에 연결되는 AZ(가용 영역) 범위의 블록 디바이스입니다. gp3는 기본 범용 SSD이며, gp2에 비해 가지는 결정적인 장점은 IOPS(최대 16,000)와 처리량(최대 1,000MiB/s)이 용량과 독립적으로 프로비저닝된다는 점입니다. 이를 통해 성능 목표를 달성하기 위해 스토리지를 과도하게 프로비저닝해야 했던 gp2의 안티패턴을 없애줍니다. io2 Block Express는 지연 시간에 민감한 데이터베이스를 위해 밀리초 미만의 지연 시간으로 최대 256,000 IOPS를 제공합니다. st1과 sc1은 처리량 중심의 순차 및 콜드 워크로드를 위한 HDD 기반 볼륨입니다. io1/io2의 Multi-Attach 기능이 있지만, 동일 AZ 내에서 클러스터 인식 파일 시스템을 실행하는 16개 인스턴스로 제한됩니다. 이는 일반적인 ‘공유 EBS’ 패턴이 아니라, 좁은 범위의 예외적인 경우입니다. 여러 인스턴스(예: 로드 밸런서 뒤의 인스턴스들)에 EBS를 광범위하게 연결하려는 시도는 각 볼륨이 프라이빗 블록 디바이스이기 때문에 ‘새로고침하면 일부 문서는 보이고 다른 문서는 보이지 않는’ 증상을 정확히 유발하는 범주 오류입니다.

EBS 볼륨은 KMS로 래핑된 데이터 키를 사용하여 AES-256으로 미사용 시 암호화(at rest)됩니다. 암호화는 투명하게 이루어집니다. 즉, 성능 저하가 없고 애플리케이션 변경이 필요 없습니다. 일단 볼륨이 암호화되면, 그로부터 파생된 스냅샷과 볼륨도 암호화되며, 기존 볼륨을 암호화되지 않은 상태로 되돌릴 수는 없습니다. 리전별로 기본 EBS 암호화를 활성화하여 개발자가 신경 쓰지 않아도 모든 새 볼륨과 스냅샷이 암호화되도록 하십시오.

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

기존의 암호화되지 않은 볼륨이 소급하여 암호화되지는 않습니다. 이를 해결하려면 스냅샷을 생성하고, 암호화 옵션으로 복사한 후, 암호화된 스냅샷으로부터 볼륨을 다시 생성해야 합니다.

스냅샷은 S3가 관리하는 인프라에 저장되는 증분 방식의 블록 레벨 백업입니다. 하지만 무료가 아니며(변경된 블록 중 유지되는 부분에 대해 비용 지불), 원본 볼륨이 삭제되어도 사라지지 않고, 이를 참조하는 AMI가 등록 취소되어도 제거되지 않습니다. aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) 또는 AWS Backup을 통해 EBS Snapshots Archive 티어(75% 저렴, 복원 시간 24~72시간)로 이동시키십시오. **Fast Snapshot Restore (FSR)**는 특정 AZ에서 스냅샷을 미리 준비(pre-warm)하여, 해당 스냅샷으로 시작된 인스턴스가 즉시 최대 성능을 발휘하도록 합니다. 빠른 스케일 아웃을 처리해야 하는 오토 스케일링 그룹 뒤의 AMI에 이 기능을 활성화하십시오.

**휴지통(Recycle Bin)**은 삭제된 EBS 스냅샷과 AMI를 지정된 보관 기간(1일~1년) 동안 보관하여 복원할 수 있게 해줍니다. 이 기능이 없으면 스냅샷 삭제는 즉시 영구적으로 이루어집니다.

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

장기적인 규정 준수 데이터 보존을 위해 매일 생성하는 EBS 스냅샷에만 의존하는 것은 흔한 아키텍처 설계상의 실수입니다. 스냅샷은 웜 스토리지에 가까운 가격으로 책정되며, 명시적으로 아카이브 전환 작업을 해주어야 합니다.

Amazon EFS: Linux 집합을 위한 공유 POSIX 파일 시스템

EFS는 완전 관리형의 탄력적인 POSIX 호환 NFSv4.1 파일 시스템입니다. 한 리전 내 여러 AZ에 걸쳐 있는 수천 개의 EC2, ECS, EKS, Lambda 클라이언트에서 동시에 마운트할 수 있으며, Direct Connect나 VPN을 통해 온프레미스 호스트에서도 마운트할 수 있습니다. 가장 큰 특징은 동일한 파일 핸들과 바이트 수준의 시맨틱을 가진 동일한 파일 시스템이 모든 클라이언트에게 동시에 보인다는 점입니다. 따라서 EFS는 로드 밸런서 뒤에 있는 Linux 집합이 공통 파일 세트(사용자 업로드, 설정 파일, 공유 홈 디렉터리 등)를 공유해야 할 때 올바른 해답입니다.

마운트 대상(Mount target)은 사용자가 구성한 각 AZ의 서브넷에 생성됩니다. amazon-efs-utils 헬퍼를 사용하면 전송 중 TLS 암호화와 IAM 마운트 권한 부여를 활성화할 수 있습니다.

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

EFS 스토리지 클래스는 두 가지 차원으로 나뉩니다. **수명 주기 관리(Lifecycle management)**는 7~90일 동안 액세스하지 않은 파일을 Standard에서 Infrequent Access로, 선택적으로 Archive로 이동시켜 스토리지 비용을 최대 92%까지 절감합니다. Intelligent-Tiering은 파일에 다시 액세스하면 상위 티어로 이동시킵니다. One Zone 클래스는 단일 AZ에 데이터를 저장하여 비용을 약 47% 절감합니다. 이는 개발/테스트 환경이나 재생성 가능한 데이터에 적합하며, AZ 장애 시 데이터 손실이 허용되지 않는 경우에는 절대 사용해서는 안 됩니다. 이미 EFS Standard-IA를 사용하는 워크로드의 비용을 최적화하는 방법 중 하나는 애플리케이션 변경 없이 EFS One Zone-IA로 전환하는 것입니다.

성능에는 두 가지 독립적인 설정이 있습니다. 성능 모드(생성 시 설정): *범용(General Purpose)*은 지연 시간이 가장 짧아 메타데이터가 많은 웹 서빙에 적합합니다. *최대 I/O(Max I/O)*는 Elastic으로 대체된 레거시 옵션입니다. 처리량 모드: *버스팅(Bursting)*은 크기에 따라 확장되고(GB당 50KB/s 기준, 기준 미달 시 버스트 크레딧 적립), *프로비저닝(Provisioned)*은 크기와 무관하게 고정된 MB/s에 대해 비용을 지불하며, 현재 기본값인 Elastic은 용량 계획 없이 최대 10GB/s 이상으로 자동 확장됩니다. 지속적인 부하가 발생하는 작은 파일 시스템은 버스팅 크레딧을 모두 소진하고 낮은 기준 처리량으로 조절될 수 있으므로, 적은 용량으로 높은 I/O를 처리해야 하는 워크로드는 Elastic 또는 프로비저닝 모드를 사용해야 합니다.

EFS는 높은 IOPS를 요구하는 블록 스토리지를 대체할 수 없습니다. 모든 EFS I/O는 네트워크를 통한 NFS RPC 호출이므로, 단일 쓰기, 밀리초 미만의 지연 시간, 트랜잭션 로그 스타일의 워크로드는 EBS io2 Block Express에 더 적합합니다. 단일 볼륨으로 밀리초 미만의 지연 시간에 256,000 IOPS를 제공할 수 있는데, 이는 EFS가 개별 작업 단위로는 따라올 수 없는 성능입니다. 또한 EFS는 콜드 데이터 저장용으로는 Deep Archive에 비해 엄청나게 비쌉니다. ‘편리하다’는 이유만으로 규정 준수 데이터를 EFS에 보관하는 것은 정당화될 수 없습니다.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx는 프로토콜과 워크로드에 따라 선택하는 관리형 파일 시스템 제품군입니다.

FSx for Windows File Server는 NTFS ACL, DFS Namespaces, 섀도 복사본, Active Directory를 통한 Kerberos 인증을 지원하는 네이티브 SMB 2.0/3.1.1을 제공합니다. 다중 AZ 배포는 하나의 AZ에 액티브 파일 서버를, 다른 AZ에 동기식으로 복제된 대기(standby) 서버를 배포하고 단일 장애 조치 DNS 이름을 제공합니다. AD 통합은 선택 사항이 아닙니다. FSx는 AWS Managed Microsoft AD 또는 연결 가능한 자체 관리형 AD에 조인해야 하며, 클라이언트는 도메인 SID에 대해 도메인 사용자로 인증합니다. AD를 건너뛰거나 포리스트 간 트러스트 없이 신뢰할 수 없는 포리스트의 파일 시스템을 클라이언트가 가리키게 하면, 공유는 보이지만 액세스가 거부되는 전형적인 증상이 발생합니다. FSx for Windows는 Windows 파일 공유를 리프트 앤 시프트(lift-and-shift)하기 위한 즉각적인 마이그레이션 대상입니다.

FSx for Lustre는 HPC, ML 훈련, EDA, 유전체학을 위한 병렬 POSIX 파일 시스템으로, 수천 개의 클라이언트, 초당 수백 GB의 처리량, 밀리초 미만의 메타데이터 액세스 속도를 제공합니다. 이 서비스의 핵심적인 AWS 기능은 S3와의 데이터 리포지토리 연결입니다. 객체 키가 Lustre 네임스페이스에 파일처럼 나타나고 첫 액세스 시 지연 로딩되거나(hsm_restore를 통해 사전 로드 가능), 새로 생성되거나 수정된 파일은 예약 또는 온디맨드 방식으로 S3에 다시 내보내집니다. 표준적인 HPC 패턴은 다음과 같습니다.

1. 온프레미스 데이터 세트를 S3로 복사합니다(DataSync 또는 Storage Gateway 사용).
2. 해당 버킷에 연결된 Lustre를 생성합니다.
3. 모든 스팟(Spot) 워커에 마운트하고, 입력 데이터를 읽고 출력 데이터를 회선 속도로 씁니다.
4. 결과를 S3로 내보냅니다. S3는 내구성 있는 장기 리포지토리로 유지됩니다.
5. 작업이 끝나면 Lustre 파일 시스템을 삭제합니다.

Lustre 스크래치(Scratch) 배포는 복제 기능이 없어 하드웨어 장애 시 데이터가 손실됩니다. 가장 저렴하고 빠르며, 일시적인 작업 데이터에 적합합니다. 영구(Persistent) 배포는 AZ 내에서 복제하여 더 높은 내구성을 제공합니다. 처리량은 TiB당 MB/s(50/125/250/500/1000) 단위로 프로비저닝되어 용량과 성능을 분리할 수 있습니다.

FSx for NetApp ONTAP은 다중 프로토콜 솔루션입니다. 동일한 데이터에 대해 NFS, SMB, iSCSI를 동시에 사용하며 스냅샷, SnapMirror 복제, FlexClone, 중복 제거 기능을 제공합니다. 다중 AZ 이중화와 함께 프로토콜 간 액세스가 필요한 혼합된 Linux NFS 및 Windows SMB 공유를 통합하거나, 온프레미스 NetApp에서 마이그레이션할 때 ONTAP을 선택합니다. FSx for OpenZFS는 NFS를 통해 ZFS 기능(스냅샷, 클론)이 필요한 Linux 워크로드의 특정 요구를 충족시킵니다. ONTAP의 다중 프로토콜 강점을 다른 버전과 혼동하지 마십시오.

잘못 선택하면 명확하게 실패합니다. 공유 워크로드에 EBS를 사용하거나, Windows SMB 공유에 EFS를, AD 통합 Windows 공유에 Lustre를 사용하는 것은 모두 부적합합니다. 프로토콜과 액세스 패턴을 먼저 맞춰야 합니다.

Storage Gateway: 하이브리드 액세스

Storage Gateway는 클라우드 스토리지를 마치 로컬에 있는 것처럼 제공합니다. 이는 데이터를 이동하는 DataSync와는 다릅니다.

미디어 라이브러리를 S3로 옮겼지만 여전히 온프레미스에서 저지연 읽기가 필요한 렌더링 애플리케이션의 경우, S3 File Gateway가 적합합니다. NFS/SMB 액세스, 로컬 캐시, 자주 사용하지 않는 객체는 필요 시 S3에서 가져옵니다. FSx File Gateway는 지사를 위한 솔루션입니다. 중앙 클라우드 FSx 공유에 대한 LAN 속도의 SMB 캐시이며, EC2 인스턴스 간 공유 액세스를 위한 솔루션이 아닙니다(EC2 인스턴스는 FSx를 직접 마운트해야 함). Volume Gateway는 워크로드가 파일 시맨틱 대신 블록 iSCSI를 사용할 때 적용됩니다. Tape Gateway는 기존 백업 소프트웨어 하에서 물리적 테이프 라이브러리를 대체합니다.

데이터 전송 및 마이그레이션

AWS DataSync는 NFS, SMB, HDFS, 객체 스토어에서 S3, EFS, FSx로의 에이전트 기반 온라인 마이그레이션 서비스입니다. 오픈 소스 도구보다 최대 10배 빠르며, 암호화, 무결성 검증, 스케줄링, POSIX 메타데이터 및 NTFS ACL 보존 기능을 제공합니다. 수백만 개의 작은 파일과 깊은 계층 구조를 가진 대규모 SMB 마이그레이션의 경우, 오버헤드가 가장 적은 해결책은 DataSync를 사용하여 FSx for Windows로 이전하는 것입니다. SMB가 보존되고, ACL/타임스탬프가 그대로 유지되며, 작은 파일 처리량은 병렬 전송을 통해 처리되고, 애플리케이션 변경이 필요 없습니다. 이러한 데이터 세트를 S3로 직접 마이그레이션하는 것은 함정입니다. 객체 스토리지는 깊은 접두사(prefix)에 있는 작은 파일 목록을 잘 처리하지 못하며 SMB 클라이언트는 버킷을 마운트할 수 없습니다.

AWS Snow Family는 오프라인 전송을 위한 물리적 어플라이언스를 배송합니다. Snowcone(최대 8TB, 엣지 환경에 최적화된 견고한 설계), Snowball Edge(최대 약 80TB 사용 가능, 컴퓨팅 옵션 포함), Snowmobile(엑사바이트 규모)이 있습니다. 경험 법칙: 네트워크 전송이 일주일 이상 걸릴 경우 Snowball이 더 저렴하고 빠릅니다.

AWS Transfer Family는 S3 또는 EFS를 백엔드로 사용하는 SFTP, FTPS, FTP, AS2를 제공합니다. 외부 파트너가 표준 파일 전송 프로토콜을 계속 사용해야 할 때 올바른 해결책입니다.

AWS Backup, 리전 간 복사 및 Vault Lock

AWS Backup은 EBS, EFS, FSx, RDS, DynamoDB, S3 등 여러 서비스의 정책을 중앙에서 관리합니다. 백업 계획은 일정, 웜 스토리지 보존 기간, 콜드 스토리지 전환, 리전 간/계정 간 복사 작업을 정의합니다.

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

콜드 스토리지로 전환하려면 최소 90일의 웜 스토리지 보존 기간과 최소 90일의 콜드 스토리지 보존 기간이 필요하며, 잘못 구성된 수명 주기는 거부됩니다. 수년간의 규정 준수 보존이 필요한 경우, AWS Backup Vault Lock(WORM)과 함께 사용합니다. 이 기능은 관리자조차 보존 기간을 단축할 수 없도록 하여 SEC 17a-4 및 유사 규정을 충족합니다. 리전 간 복사는 리전별 DR(재해 복구)에 대응하고, 계정 간 복사는 프로덕션 계정의 영향 범위(blast radius)에서 백업을 격리하여 랜섬웨어 및 내부자 위협 시나리오에 대응합니다.

선택 치트 시트

← 서버리스 및 이벤트 기반 아키텍처 · 모든 도메인 · 데이터 전송 및 마이그레이션 →

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

Amazon 찾아보기 →