[reinvent 2024] Amazon EBS 스냅샷으로 중요한 데이터를 보호하기

들어가며

EBS 스냅샷으로 중요한 데이터를 보호하기란 세션입니다. EBS 스냅샷이란 인스턴스를 구성하는 인스턴스 볼륨과 인스턴스에 장착되는 볼륨에 대한 백업을 위해 스냅샷을 생성하게되면 EBS스냅샷이 됩니다. 인스턴스 볼륨과 장착된 볼륨은 구동 중이며, 그대로 돌아가는 상태에서 고정적인 상태를 취하는 EBS 스냅샷이 만들어지면, 그 자체로 훌륭한 백업이 됩니다. 그 후에 구동 중이던 인스턴스가 OS내부의 문제가 망가진다거나, 장착된 볼륨의 파일시스템 문제로 깨진다해도 EBS 스냅샷으로 되돌릴 수 있기 때문입니다. 물론, 그 사이에 발생한 데이터를 소실되겠지만요.

그리고, 강력한 재해복구나 심화된 안전성을 요구하는 경우 다른 리전으로의 스냅샷 복사나 2본 이상의 replica 등을 준수해야하는 상황이라면 조금 더 복잡해 질겁니다. 이번 세션에서는 EBS 스냅샷으로 어떻게 우리의 데이터를 더 효율적이며 안전하게 지킬 수 있는지 알아보겠습니다.

Agenda는 아래와 같습니다.

먼저 EBS 스냅샷을 소개한 뒤에 EBS 스냅샷을 암호화하는 방법을 다룹니다. 그리고, SAP의 RISE를 위해 랜섬웨어와 불변성 보호에 관해 얘기합니다. 마지막으로 EBS 스냅샷으로 데이터 보호하는 것으로 마무리할 예정입니다.

Introduction to Amazon EBS snapshots

EBS 스냅샷을 얘기하기 전에 AWS가 제공하는 스토리지 서비스를 훑어봄으로써 우리가 하려는 일의 범위나 포지션을 확인해 봅니다. EBS 스냅샷의 원천이 되는 EBS는 가운데 코어 서비스 중 블록스토리지에 해당하고, EBS 스냅샷 서비스는 좌측 상단에 데이터 서비스로 분류되어있는걸 보실 수 있습니다.

블록 스토리지에 들어가서 살펴보면, 하나는 인스턴트 스토리지이고, 다른 하나는 EBS (Elastic Block Store)입니다. 서두에 말씀드린 것처럼 인스턴스 스토리지는 EC2 인스턴스에 연결된 임시 스토리지입니다. 인스턴스를 중지(Terminate)하게되면 기본적으로 삭제될 수 있습니다. 그럼에도, 인스턴스에 장착되어있던 EBS는 그대로 유지됩니다.

EBS볼륨이 장착된 EC2 인스턴스의 스냅샷을 생성하게 되면, 2개 볼륨 모두 개별적인 EBS 스냅샷이 생성되며 이는 특정 시점(Point-in-time)의 데이터를 저장한 백업 데이터가 됩니다. 그리고, 최초 스냅샷 이후의 스냅샷은 증분(Incremental) 백업이므로, 변경된 데이터만 백업이 됩니다. 이는 스냅샷을 생성하는 속도가 빨라지고, 매번 전체 데이터를 저장하지않기 때문에 데이터 저장효율이 좋아지는 이점이 있습니다.

그리고, 스냅샷을 생성할때, 단일 API 호출을 통해 충돌 일관성(Crash-consistent)을 제공하므로, 인스턴스 구동중에 쉽게 스냅샷을 생성할 수 있습니다.

여기 고객이 사용하는 스냅샷 사용사례 4가지가 있습니다.

• 첫 번째로 가장 흔히 사용하는 인스턴스를 스냅샷해서 재해 복구를 위해 다른 리전으로 한벌 더 백업해 둔다든가 하는 식입니다.
• 두 번째는 엔터프라이즈 회사의 중앙조직에서 표준 인스턴스를 공급하기위해 표준 OS이미지를 생성하고, 이를 다른 계정에서 사용할 수 있도록 공유하고, 보안 패치나 업데이트가 있을떄 표준 OS이미지를 업데이트해서 재배포하는 케이스입니다.
• 세 번째는 온프레미스 환경의 인스턴스를 스냅샷으로 백업하여 클라우드 내에 복원하는 사례도 있습니다.
• 네 번째는  서드파티 솔루션을 통해 스냅샷 백업을 다른 계정으로 이동시킨 후 복원하는 사례가 있습니다.

한번 더 요약해보면 EBS스냅샷은 특정시점에 대한 백업이라는 특징이 있습니다. 이후에 데이터변경이 있더라도 이 내용은 스냅샷에 반영이 되지않고, 해당 스냅샷을 복원할 경우 데이터변경분은 소실되고, 스냅샷 생성시점의 데이터상태로 돌아갑니다.

최초 이후의 스냅샷은 증분의 특성을 가지고 있으므로, 최근 스냅샷 이후의 데이터변경분을 저장하게된다는 특성이 있습니다. 그리고, 각 스냅샷은 각각이 데이터전체본이 아니라 일부분의 데이터를 보유하게되므로, 비용도 일부분의 데이터에 해당하여 청구하게 됩니다.

Securing EBS snapshots

EBS의 암호화는 KMS서비스를 통해 AES-256 알고리즘을 진행되고, 저장할때 뿐 아니라, 인스턴스와 볼륨 간 이동하는 데이터도 암호화됩니다. 암호화된 EBS으로 생성한 스냅샷은 자동적으로 암호화됩니다. 그럼, 암호화된 EBS 스냅샷으로 복원된 볼륨도 자동적으로 암호화됩니다.

암호화되지않은 스냅샷은 복사할 때 암호화여부를 선택할 수 있습니다. 또한, KMS키를 기본키에서 다른 키 (예를 들면, CMK)로 변경하여 암호화 할 수도 있습니다.

EBS암호화에서 제공하는 기본 키는 계정 내 리전별 기본 제공하는 암호화 키이며, 이는 CMK생성 및 지정으로 변경할 수 있습니다.

계정 내 리전 수준에서 필수적인 볼륨 및 스냅샷 암호화를 쉽게 강제화할 수 있는데, 이를 EBD (EBS Encryption by Default)라고 합니다. 설정 이후 부터 생성되는 모든 볼륨과 스냅샷은 설정된 키를 기반으로 자동 암호화됩니다.

KMS는 리전수준 서비스이며, EBD 또한 리전별로 별개로 적용된다는 것을 유념해 두십시오.

EBD의 설정 이후 새롭게 생성되는 볼륨과 스냅샷은 모두 암호화되겠지만, 기존의 암호화되지않은 리소스들은 어떻게 해야할까요?

비암호화된 인스턴스 볼륨은 ‘CreateReplaceRootVolumeTask’ API호출 후 루트볼륨을 암호화된 볼륨으로 복원할 수 있습니다. 비암호화된 데이터 볼륨은 스냅샷 생성 후 복원하여 사용하면 됩니다. 비암호화된 스냅샷의 경우, 스냅샷 복사를 통하면 암호화된 스냅샷을 만들 수 있습니다.

스냅샷 복사의 사용 사례를 보면, 크게 2가지로 볼 수 있습니다.

리전 내 혹은 리전 간 복사를 필요로하는, 재해 복구 요구사항이 있는 고객의 케이스가 첫 번째 입니다.

두 번째는 새로운 리전으로의 애플리케이션 확장을 하거나, 마이그레이션하는 케이스가 있습니다.

2024년 11월말에 출시된 기능인데, 재해 복구 요구사항 중 복구지점목표(RPO)를 엄격히 준수해야하는 고객들을 대상으로 하는 시간기반 스냅샷 복사입니다. 15분에서 48시간 범위 내에서 스냅샷 복사에 소요되는 시간을 지정하기만 하면 AWS가 알아서 이를 충족하게 됩니다.

스냅샷을 공유하는 사례도 있습니다. 기본적으로 스냅샷은 계정 내부에만 공유됩니다.

권장되지않지만, 스냅샷의 공유설정을 통해 다른 계정으로 혹은 Public하게 완전 공유도 가능합니다. 이것을 막기위해 Block-all-sharing mode를 활성화하여 Public공유를 막을 수 있습니다.

다음음 스냅샷 잠금이고, 수많은 기업들이 요구하는 WORM (Write-Once-Read-Many)보호를 충족하는 기능입니다. 특정 기간에 해당하는 스냅샷을 잠금으로써 사고나 이상현상으로 인해 삭제되지않도록 합니다. 스냅샷 단위로 잠금여부 선택이 가능하며, 잠그는 기간도 설정할 수 있습니다. 또한 잠금은 규정준수 모드와 거버넌스 모드를 선택할 수 있습니다.

규중준수 모드는 잠금기간 내 그 누구도 삭제불가하며, 기간연장만 가능합니다. 거버넌스 모드는 규정준수 모드보다 유연하여 잠금기간 내에라도 잠금제거나 기간연장에 대한 설정을 변경할 수 있습니다.

Immutability and ransomware protection for RISE with SAP

RISE with SAP은 클라우드 환경으로 고객의 ERP구성 혹은 전환하는것을 촉진하는 프로그램입니다.

On-premise에서 뿐만 아니라 클라우드 환경에서도 SAP을 구축, 운영하고, 전환해 가는걸 장려하고 지원하고 있습니다. 이 프로그램에서 요구되는 조건은 빠른 백업과 복원이 기본이며, 백업된 데이터로 가능한 복원력, 백업하는 동안 워크로드의 부하가 없을 것, 짧은 복구지점목표, 보안과 암호화 입니다.

EBS 스냅샷은 어떻게 미션크리티컬한 데이터를 보호하게 할까요?

위에서 기술했듯이 전통적인 백업보다 빠른 백업(예시 : 증분백업), 지역별 붕괴를 회피할 수 있는 복원력, 백업시 워크로드 부하없이 유연하게 관리가능할것, 증분스냅샷 덕에 비용효율적이며, 암호화지원 등입니다. 다소 내용이 반복되는 것같지만, AWS EBS 스냅샷은 RISE with SAP프로그램의 요건을 충족한다는걸로 이해하시면 됩니다.

EBS 스냅샷 잠금에 따른 불변성에 관한 이야기입니다. 불변성 백업이란 백업데이터에 대한 변조, 삭제, 덮어쓰기를 보호하는 개념을 말합니다.

EBS 스냅샷 잠금에서 규정 준수 모드를 언급한 바 있습니다. 바로 변조불가, 삭제불가, 덮어쓰기불가이며, 잠금기간을 연장 외에는 아무것도 할 수 없으므로, 원본 등의 랜섬웨어 감염에 대비할 수 있습니다.

SAP에서 EBS스냅샷을 위해 구성하는 아키텍처입니다. 특히할만한 점은 EC2에 20~30개정도의 볼륨이 장착되는데, 내부적으로는 LVM구성에 따라 백업이 필요한 볼륨을 선별하여 백업을 받는다는 점입니다.  그래서, 스냅샷 워크플로우는 인스턴스 내 백업대상볼륨을 식별하여 스냅샷을 생성하고, 스냅샷잠금 설정 후 보존수명주기 관리를 위한 태깅을 수행합니다.

EBS스냅샷을 복원하는 아키텍처입니다. EBS스냅샷을 FSR(Fast Snapshot Restore)를 통해 볼륨으로 복원 후 기존 볼륨을 분리하고, 복원볼륨으로 대체 장착하는 절차로 진행됩니다. FSR은 스냅샷 복원시 일정 성능이상을 보장받기 위한 선택지이며, SAP의 HANA시스템이 이를 요구합니다.

Data protection with EBS snapshots

EBS스냅샷의 라이프사이클을 관리하는 Data Lifecycle Manager에 대한 이야기이며, 정책 및 태그기반의 백업이 가능하고, 백업스케줄링 및 유지기간 관리, 스냅샷 아카이빙 및 애플리케이션 일관성 자동화, 무료 사용이 그 특징입니다. 애플리케이션 일관성 스냅샷은 AMI를 통해 새롭게 만들어진 인스턴스에 볼륨 간 충돌없이 정확한 순서로 장착될 수 있도록 System Manager와 연동하게 동작하는 기능입니다.

준비할 것은 System Manager Agent이 설치된 EC2인스턴스, 인스턴스 프로파일로서의 IAM-role, DLM정책, System Manager의 실행명령 문서가 있습니다.

주요절차를 살펴보면, DLM의 스케쥴로부터 System Manager의 pre-script구동이 시작됩니다. EC2의 SSM Agent로 전달되어 EC2의 DB엔진을 정지하고, 메모리의 내용을 디스크에 쓰는 등의 정리 작업을 수행합니다. 이 후에 본격적인 DLM의 애플리케이션 일관성 스냅샷 생성을 시작합니다. 이 후 pro-script구동을 통해 DB엔진을 시작하고, 기타 작업을 재시작하는 과정을 거칩니다.

Data Lifecycle Manager의 또다른 유용한 기능은 계정 내 존재하는 모든 EC2인스턴스의 볼륨과 스냅샷 상태를 쉽게 가시화하는 것입니다. 많은 볼륨이 다양한 백업요구사항으로 혼재된 때에 스토리지 관리자는 백업대상 식별을 위해 모든 볼륨을 살펴보는 것이 현재까지의 방식이었습니다. 그러나, 이제부터는 DLM의 기본정책을 사용하여 백업대상 여부를 쉽게 식별하여 스냅샷을 지정할 수 있습니다.

EBS서비스에서 고객은 우발적인 혹은 악의적인 삭제를 방지하기 위해 삭제된 스냅샷은 복원가능한 휴지통으로 유지기간 동안 자동 보관되며, 유지기간 이후 정말 삭제됩니다. ??유지기간 이내에 복원해야한다면 복원이 가능합니다. 이 기능에는 제외태그가 지원되어 보호할 필요가 없는 스냅샷과 AMI는 제외태그 설정으로 휴지통 사용없이 즉각 삭제할 수 있습니다.

결론

EC2인스턴스는 AWS컴퓨팅 서비스의 기본이며, EBS볼륨은 AWS스토리지 서비스의 기본이며, EBS스냅샷과 AMI는 AWS백업 서비스의 기본입니다. 기본이지만, 기본을 튼튼히 해야 더 성장할 수 있다는 걸 확인한 세션이었습니다.

EBS볼륨은 반드시 초기부터 암호화해야하는 대상으로 간주되고있고, 이를 위해 EBD설정은 언제든 초기부터 진행해야합니다.

SAP을 위해 DLM을 통해 애플리케이션 일관성 스냅샷같은 또다른 기능을 배울 수 있어서 좋은 시간이었고,

DLM을 통해 EBS볼륨과 스냅샷, AMI전반에 대한 가시성과 운용성을 높일 수 있다는 사실에 한층 더 기쁨이 느껴졌습니다.

On-premise의 백업지옥을 떠나 클라우드 네이티브한 백업환경을 보니 정말 기쁘기 그지없고

상전벽해를 느끼게되는 Old 엔지니어의 감상이었습니다.