Amazon S3 버킷
AWS Backup은 단독으로 또는 다른 AWS 데이터베이스, 스토리지 및 컴퓨팅 서비스와 함께 S3에 데이터를 저장하는 애플리케이션의 중앙 집중식 백업 및 복원을 지원합니다. S3 백업에는 Backup Audit Manager를 비롯한 다양한 기능을 사용할 수 있습니다.
AWS Backup에서 단일 백업 정책을 사용하여 애플리케이션 데이터의 백업 생성을 중앙에서 자동화할 수 있습니다. AWS Backup는 여러 AWS 서비스 및 서드 파티 애플리케이션의 백업을 암호화된 중앙 위치(백업 볼트트라고 함)에 자동으로 구성하므로 중앙 집중식 환경을 통해 전체 애플리케이션의 백업을 관리할 수 있습니다. S3의 경우 클릭 한 번으로 연속 백업을 생성하고 S3에 저장된 애플리케이션 데이터를 복원한 다음, 백업을 시점 복원할 수 있습니다.
AWS Backup을 사용하면 객체 데이터, 태그, 액세스 제어 목록(ACL), 사용자 정의 메타데이터를 포함하여 다음과 같은 유형의 S3 버킷 백업을 생성할 수 있습니다.
-
연속 백업을 사용하면 최근 35일 중 원하는 시점으로 복원할 수 있습니다. S3 버킷의 연속 백업은 하나의 백업 계획으로만 구성해야 합니다.
지원되는 서비스 목록 및 AWS Backup을 사용하여 연속 백업을 수행하는 방법에 대한 지침은 시점 복구를 참조하세요.
-
정기 백업에서는 데이터의 스냅샷을 사용하여 최대 99년까지 지정된 기간 동안 데이터를 유지할 수 있습니다. 정기 백업을 1시간, 12시간, 1일, 1주, 1개월과 같은 빈도로 예약할 수 있습니다. AWS Backup은 백업 계획에서 정의한 백업 기간 동안 정기적으로 백업을 수행합니다.
AWS Backup이 백업 계획을 리소스에 적용하는 방법을 이해하려면 백업 계획 생성성을 참조하세요.
S3 백업에는 교차 계정 및 교차 리전 복사본을 사용할 수 있지만 연속 백업의 복사본에는 시점 복원 기능이 없습니다.
S3 버킷의 연속 및 정기 백업은 모두 동일한 백업 볼트에 있어야 합니다.
두 백업 유형 모두 첫 번째 백업은 전체 백업이고 후속 백업은 객체 수준에서의 증분 백업입니다.
참고
Amazon S3에 AWS Backup을 사용하려면 S3 버킷에서 S3 버전 관리를 활성화해야 합니다. 데이터 보호를 위한 모범 사례로 S3 버전 관리를 권장하기 때문에 AWS에서 이 전제 조건을 유지했습니다.
S3 버전 관리에 수명 주기 만료 기간을 설정하는 것이 좋습니다. 수명 주기 만료 기간을 설정하지 않으면 AWS Backup이 만료되지 않은 S3 데이터 버전을 모두 백업하고 저장하므로 S3 비용이 증가할 수 있습니다. S3 수명 주기 정책 설정에 대해 자세히 알아보려면 이 페이지의 지침을 따르세요.
S3 백업 유형 비교
S3 리소스에 대한 백업 전략에는 연속 백업만 포함하거나, 정기(스냅샷) 백업만 포함하거나, 이 둘을 조합하여 사용할 수 있습니다. 아래 정보는 조직에 가장 적합한 전략을 선택하는 데 도움이 될 수 있습니다.
연속 백업만:
-
기존 데이터의 첫 번째 전체 백업이 완료된 후에는 S3 버킷 데이터의 변경 사항이 발생하는 즉시 추적됩니다.
-
추적된 변경 사항을 통해 연속 백업의 보존 기간 동안 PITR(시점 복원)을 사용할 수 있습니다. 복원 작업을 수행하려면 복원하려는 시점을 선택합니다.
-
각 연속 백업의 보존 기간은 최대 35일입니다.
정기(스냅샷) 백업만, 예약 또는 온디맨드 백업:
-
AWS Backup는 전체 S3 버킷을 스캔하고, 각 객체의 ACL 및 태그를 검색하고, 이전 스냅샷에는 있었지만 생성 중인 스냅샷에서는 발견되지 않은 모든 객체에 대해 Head 요청을 시작합니다.
-
백업은 특정 시점 일관성입니다.
-
기록된 백업 날짜 및 시간은 백업 작업이 생성된 시간이 아니라 AWS Backup이 버킷 순회를 완료하는 시간입니다.
-
버킷의 첫 번째 백업은 전체 백업입니다. 이후의 각 백업은 증분 백업이며, 이는 마지막 스냅샷 이후의 데이터 변경을 나타냅니다.
-
정기 백업에 의한 스냅샷의 보존 기간은 최대 99년입니다.
정기/스냅샷 백업과 결합된 연속 백업:
-
기존 데이터(각 버킷)의 첫 번째 전체 백업이 완료되면 버킷의 변경 사항이 발생하는 대로 추적됩니다.
-
연속 복구 시점에서 시점 복원을 수행할 수 있습니다.
-
스냅샷은 특정 시점 일관성입니다.
-
스냅샷은 연속 복구 시점에서 직접 생성되므로 버킷을 다시 스캔할 필요가 없어 프로세스가 더 빠릅니다.
-
스냅샷과 연속 복구 시점은 데이터 계보를 공유하므로 스냅샷과 연속 복구 시점 간의 데이터 스토리지는 중복되지 않습니다.
지원되는 S3 스토리지 클래스
AWS Backup을 사용하면 다음 S3 스토리지 클래스에 저장된 S3 데이터를 백업할 수 있습니다.
-
S3 Standard
-
S3 Standard-Infrequent Access (IA)
-
S3 One Zone-IA
-
S3 Glacier Instant Retrieval
-
S3 Intelligent-Tiering(S3 INT)
스토리지 클래스 S3 Intelligent-Tiering(INT)에 있는 객체의 백업은 해당 객체에 액세스합니다. 이 액세스는 S3 지능형 계층화를 트리거하여 해당 객체를 Frequent Access로 자동으로 이동합니다.
S3 Standard-Infrequently Access(IA) 및 S3 One Zone-IA 클래스를 포함하여, Infrequent Access 계층에 액세스하는 백업은 (Infrequent Access 또는 Archive Instant Access 계층에 적용되는) Frequent Access의 S3 스토리지 요금 아래로 이동합니다.
Glacier Instant Retrieval을 제외하고, 보관된 스토리지 클래스는 지원되지 않습니다.
Amazon S3의 스토리지 요금에 대한 자세한 내용은 Amazon S3 요금
Amazon S3에 대한 AWS Backup 고려 사항
S3 리소스를 백업할 때는 다음 사항을 고려해야 합니다.
-
집중 객체 메타데이터 지원 – AWS Backup는 태그, 액세스 제어 목록(ACL), 사용자 정의 메타데이터, 원본 생성 날짜 및 버전 ID와 같은 메타데이터를 지원합니다. 또한 원본 생성 날짜, 버전 ID, 스토리지 클래스, e-태그를 제외한 모든 백업 데이터 및 메타데이터를 복원할 수 있습니다.
-
S3 객체를 복원할 때 원래 객체가 체크섬 기능을 사용하지 않았더라도 체크섬 값을 적용합니다.
-
S3 객체 키 이름은 대부분의 UTF-8 인코딩 가능 문자열로 구성될 수 있습니다. 다음 유니코드 문자가 허용됩니다.
#x9
|#xA
|#xD
|#x20 to #xD7FF
|#xE000 to #xFFFD
|#x10000 to #x10FFFF
.이 목록에 없는 문자가 포함된 객체 키 이름은 백업에서 제외될 수 있습니다.
-
콜드 스토리지 전환 - AWS Backup 수명 주기 관리 정책을 사용하여 백업 만료 타임라인을 정의합니다. S3 백업의 콜드 스토리지 전환은 지원되지 않습니다.
-
동일한 시점에 생성된 동일한 객체의 여러 버전이 포함된 S3 버킷의 백업은 지원되지 않습니다.
-
정기 백업의 경우 객체 AWS Backup은 최선의 노력으로 메타데이터의 모든 변경 사항을 추적합니다. 그러나 태그 또는 ACL을 1분 이내에 여러 번 업데이트하면 AWS Backup이 중간 상태를 모두 캡처하지 못할 수 있습니다.
-
AWS Backup는 SSE-C 암호화 객체의 백업을 지원하지 않습니다. AWS Backup는 또한 버킷 정책, 설정, 이름 또는 액세스 포인트를 포함한 버킷 구성의 백업도 지원하지 않습니다.
-
AWS Backup는 AWS Outposts의 S3의 백업을 지원하지 않습니다.
-
CloudTrail 로깅 - 데이터 읽기 이벤트를 로깅하는 경우 CloudTrail 로그가 다른 대상 버킷에 있어야 합니다. CloudTrail 로그를 로깅되는 버킷에 저장하는 경우 무한 루프가 생겨서 예기치 않은 요금이 발생할 수 있습니다.
자세한 내용을 알아보려면 CloudTrail 사용 설명서의 데이터 이벤트를 참조하세요.
-
서버 액세스 로깅 - 서버 액세스 로깅을 활성화하는 경우 로그는 다른 대상 버킷으로 전달되어야 합니다. 이러한 로그를 로깅되는 버킷에 저장하면 무한 루프가 발생합니다. 자세한 내용은 Amazon S3 서버 액세스 로깅 활성화를 참조하세요.
S3 백업 완료 기간
아래 표에는 S3 버킷의 초기 전체 백업 완료 시간을 추정하는 데 도움이 되는 다양한 크기의 샘플 버킷이 나와 있습니다. 백업 시간은 각 버킷의 크기, 콘텐츠, 구성 및 설정에 따라 달라집니다.
버킷 크기 | 객체 수 | 초기 백업을 완료하는 데 걸리는 예상 시간 |
---|---|---|
425GB(기가바이트) | 1억 3,500만 개 | 31시간 |
800TB(테라바이트) | 6억 7,000만 개 | 38시간 |
6PB(페타바이트) | 50억 개 | 100시간 |
370TB(테라바이트) | 75억 개 | 180시간 |
Amazon S3 백업 및 복원에 대한 권한 및 정책
S3 리소스를 백업, 복사, 복원하려면 역할에 올바른 정책이 있어야 합니다. 이러한 정책을 추가하려면 AWS 관리형 정책으로 이동하세요. S3 버킷 백업과 복원에 사용하려는 역할에 AWSBackupServiceRolePolicyForS3Backup 및 AWSBackupServiceRolePolicyForS3Restore를 추가합니다.
충분한 권한이 없는 경우 조직의 관리(관리자) 계정 관리자에게 의도한 역할에 정책을 추가해 달라고 요청하세요.
자세한 내용은 IAM 사용 설명서의 관리형 정책과 인라인 정책을 참조하세요.
S3용 AWS Backup은 Amazon EventBridge를 통해 S3 이벤트를 수신해야 합니다. S3 버킷 알림 설정에서 이 설정을 비활성화하면 해당 설정이 비활성화된 버킷에 대해서는 연속 백업이 중지됩니다. 자세한 내용은 EventBridge 사용을 참조하세요.
S3 백업의 모범 사례 및 비용 고려 사항
모범 사례
객체를 3억 개 이상 포함하는 버킷의 경우:
-
객체를 3억 개 이상 포함하는 버킷의 경우 버킷의 초기 전체 백업 시 백업 속도는 초당 최대 17,000개까지 도달할 수 있으며(증분 백업은 속도가 달라짐), 3억 개 미만의 객체를 포함하는 버킷은 초당 1,000개 객체에 가까운 속도로 백업됩니다.
-
연속 백업을 권장합니다.
-
백업 수명 주기가 35일을 초과하도록 계획된 경우 연속 백업이 저장된 동일한 볼트에서 버킷의 스냅샷 백업을 활성화할 수도 있습니다.
비용 고려 사항
-
S3 수명 주기 정책에는 만료된 객체 삭제 마커 삭제라는 선택적 기능이 있습니다. 이 기능을 사용하지 않으면 삭제 마커(때로는 수백만 개가 있음)가 정리 계획 없이 만료됩니다. 이 기능이 없는 버킷을 백업하면 시간과 비용에 영향을 미치는 두 가지 문제가 발생합니다.
-
삭제 마커는 객체와 마찬가지로 백업됩니다. 백업 시간 및 복원 시간은 삭제 마커 대비 객체의 비율에 따라 영향을 받을 수 있습니다.
-
백업되는 각 객체 및 마커에는 최소 요금이 부과됩니다. 각 삭제 마커에는 128KiB 객체와 동일한 요금이 부과됩니다.
-
-
적어도 매일 또는 그 이상 자주 백업하는 계정의 경우 백업 간에 백업 내 데이터에 변화가 거의 없는 경우 연속 백업을 사용하면 비용을 절감할 수 있습니다.
-
자주 변경되지 않는 대용량 버킷은 연속 백업의 이점을 누릴 수 있습니다. 기존 객체(이전 백업 이후 변경되지 않은 객체)에 대해 객체당 여러 요청과 함께 전체 버킷을 스캔할 필요가 없으므로 비용이 절감될 수 있기 때문입니다.
-
1억 개 이상의 객체를 포함하고 전체 백업 크기에 비해 삭제율이 작은 버킷의 경우 보존 기간이 2일인 연속 백업과 보존 기간이 더 긴 스냅샷을 모두 포함하는 백업 계획을 사용하면 비용을 절감할 수 있습니다.
-
정기(스냅샷) 백업 시간은 버킷 스캔이 필요하지 않은 백업 프로세스의 시작 시간과 일치합니다. 연속 백업과 스냅샷이 모두 있는 버킷에서는 스캔이 필요하지 않습니다. 이러한 경우 스냅샷은 연속 복구 시점에서 생성되기 때문입니다.
-
단일 S3-GIR(Amazon S3 Glacier Instant Retrieval)의 각 객체에 대해 AWS Backup는 여러 번의 직접 호출을 수행하므로, 백업이 수행될 때 검색 요금이 발생합니다.
S3-IA 및 S3 One Zone-IA 스토리지 클래스에 객체가 있는 버킷에도 유사한 검색 비용이 적용됩니다.
-
백업 전략의 일부인 AWS KMS, CloudTrail 및 Amazon CloudWatch 기능으로 인해 S3 버킷 데이터 스토리지 외에 추가 비용이 발생할 수 있습니다. 이러한 기능에 대한 자세한 내용은 다음을 참조하세요.
-
Amazon S3 사용 설명서의 Amazon S3 버킷 키를 사용하여 SSE-KMS 비용 절감.
-
AWS KMS 이벤트를 제외하고 S3 데이터 이벤트를 비활성화하여 CloudTrail 비용을 줄일 수 있습니다.
-
AWS KMS 이벤트 제외: CloudTrail 사용 설명서에서 콘솔(기본 이벤트 선택기)에서 추적을 생성하면 AWS KMS 이벤트를 제외하여 추적에서 해당 이벤트를 필터링할 수 있습니다(기본 설정에는 모든 KMS 이벤트가 포함됨).
-
KMS 이벤트를 로그하거나 제외하는 옵션은 추적에서 관리 이벤트를 로그하는 경우에만 사용할 수 있습니다. 관리 이벤트를 로그하지 않도록 선택하는 경우 KMS 이벤트가 로그되지 않으며, KMS 이벤트 로깅 설정을 변경할 수 없습니다.
-
AWS KMS,
Encrypt
,Decrypt
와 같은GenerateDataKey
작업은 일반적으로 대량의 이벤트(99% 이상)를 생성합니다. 이러한 작업은 이제 읽기 이벤트로 로그됩니다.Disable
,Delete
및ScheduleKey
와 같은 저용량의 관련 KMS 작업(일반적으로 KMS 이벤트 볼륨의 0.5% 미만을 차지함)은 쓰기 이벤트로 로그됩니다. -
Encrypt
,Decrypt
및GenerateDataKey
와 같은 대량의 이벤트를 제외하지만Disable
,Delete
및ScheduleKey
와 같은 관련 이벤트를 계속 로그하려면 쓰기 관리 이벤트를 로그하도록 선택하고 AWS KMS 이벤트 제외 확인란의 선택을 취소합니다. -
S3 데이터 이벤트 비활성화: 기본적으로 추적 및 이벤트 데이터 스토어는 데이터 이벤트를 로그하지 않습니다. 초기 백업 전에 S3 데이터 이벤트를 비활성화하여 비용을 줄이세요.
-
-
CloudWatch 비용을 줄이려면 CloudWatch Logs 설정을 비활성화하도록 추적을 업데이트할 때 CloudWatch Logs로 CloudTrail 이벤트 전송을 중지할 수 있습니다.
-
S3 백업 복원
AWS Backup을 사용하여 백업한 S3 데이터를 S3 Standard 스토리지 클래스로 복원할 수 있습니다. S3 데이터를 원본 버킷을 포함한 기존 버킷에 복원할 수 있습니다. 복원 중에 새 S3 버킷을 복원 대상으로 생성할 수도 있습니다. S3 백업은 백업이 위치하는 동일한 AWS 리전에만 복원할 수 있습니다.
전체 S3 버킷 또는 버킷 내 폴더 또는 객체를 복원할 수 있습니다. AWS Backup은 해당 객체의 현재 버전을 복원합니다.
AWS Backup을 사용하여 S3 데이터를 복원하려면 AWS Backup를 사용하여 S3 데이터 복원을 참조하세요.