devops

EKS 재해 복구, 간소화: AWS Backup을 활용한 네이티브 백업

발행: (2025년 12월 22일 오전 06:53 GMT+9)
9 min read
원문: Dev.to

Source: Dev.to

번역을 진행하려면 번역하고자 하는 전체 텍스트를 제공해 주시겠어요? 텍스트를 주시면 한국어로 번역해 드리겠습니다.

전환점 – 2025년 11월 10일

지난 달 AWS는 Amazon EKS에 대한 네이티브 지원을 AWS Backup에 추가함으로써 오랫동안 존재하던 격차를 마침내 해소했습니다.
이는 사소한 기능 추가가 아니라 DIY 백업 엔지니어링에서 관리형 신뢰성으로의 실질적인 전환입니다.

왜 이것이 중요한가

기존 방식새로운 방식
분산된 복구 지점 – 클러스터 구성, EBS 스냅샷 및 S3 객체가 별도 위치에 존재했습니다.복합 복구 지점 – AWS Backup이 클러스터 상태 와 영구 스토리지(EBS, EFS, S3)를 하나의 일관된 스냅샷으로 캡처합니다.
다중 도구 – Velero, 사용자 정의 스크립트, 수동으로 관리되는 S3 버킷, 그리고 끝없는 불안.하나의 화면 – EKS 백업이 EC2, RDS, DynamoDB 등에서 이미 사용 중인 동일한 AWS Backup 콘솔에 표시됩니다. 추가 컨트롤러나 클러스터당 Velero 에이전트가 필요 없습니다.
스크립트 기반 스케줄 – 클러스터 내부의 CronJob.정책 기반 스케줄 – 백업 플랜 정의(예: “6시간마다 백업, 30일 보관”). AWS가 스케줄링, 암호화, 불변성 및 수명 주기를 자동으로 처리합니다.
스트레스가 많은 복구 – 수동, 오류 발생 가능성이 높고 종종 도박과 같습니다.스트레스 없는 복구 – 전체 클러스터, 단일 네임스페이스, 개별 PV, 혹은 새로운 EKS 클러스터까지 복구 워크플로의 일부로 복구할 수 있습니다.

지금 바로 얻을 수 있는 운영상의 이점

  • 클러스터 업그레이드(예: 1.30 → 1.31) 시 데이터 손실에 대한 두려움 없이.
  • AMI 롤아웃이 계획대로 진행되지 않을 때.
  • 보안 패치 적용 시 안전망 제공.
  • Kubernetes API 변경으로 워크로드가 중단될 위험.

프로덕션 EKS를 운영한다면, 이 기능은 밤에 잠을 자는 방식을 조용히 바꿔줍니다. AWS는 단순히 백업 옵션을 추가한 것이 아니라, 운영 스트레스 전체 카테고리를 제거한 것입니다.

실용 가이드: AWS Backup을 사용한 네이티브 EKS 백업 활성화

1. EKS를 보호된 리소스로 추가

  1. AWS Backup 콘솔을 엽니다.
  2. Settings → Configure resource 를 선택합니다.
  3. Amazon EKS 를 선택하고 활성화합니다.

Configure resource screen

2. 온‑디맨드 백업 생성

  1. Protected resources 화면에서 Create on‑demand backup 을 클릭합니다.

Create on‑demand backup button

3. 백업 역할 설정

맞춤형 IAM 역할(예: EKS-BACKUP-ROLE-EXAMPLE)을 생성하고 다음 관리형 정책을 연결합니다:

  • AWSBackupServiceRolePolicyForBackup
  • AWSBackupServiceRolePolicyForRestores

IAM role attachment screen

Policy list view

4. 백업 진행 상황 확인

온‑디맨드 백업을 시작하면 상태가 In progress 로 변경되는 것을 볼 수 있습니다.

Backup in progress view

5. 완료 확인

백업이 완료되었는지는 AWS Backup 콘솔이나 EKS 콘솔에서 직접 확인할 수 있습니다.

Backup completed view

TL;DR

  • AWS Backup이 이제 Amazon EKS를 기본적으로 지원합니다 – 제어 플레인 상태와 영구 스토리지를 모두 한 번의 클릭으로 정책 기반 보호.
  • 복합 복구 지점으로 파편화된 스냅샷을 없앱니다.
  • 통합 콘솔을 통해 모든 워크로드를 한 눈에 볼 수 있습니다.
  • 설정 후 잊어버리기 백업 계획으로 불안정한 CronJob과 맞춤 스크립트를 대체합니다.
  • 복구는 신뢰할 수 있습니다 – 전체 클러스터, 네임스페이스 수준, 또는 PV 수준 복구까지, 새 클러스터에도 복구 가능.

오늘 바로 활성화하고 재해 복구를 악몽에서 관리형 서비스로 전환하세요.

![Backup screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fkkmc6v25h0hmc0s4txt5.png)

That is how to back up; now moving to the **Restore process**.

### Initiating a Restore

1. Open **AWS Backup** → **Protected resources**.  
2. Click the **Resource ID** of the cluster you want to restore.  
3. Choose the **Composite recovery point** you created.  
4. Press the **Restore** button.

![Restore button screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fdauixjqk92f146ntwjzf.png)

### Choosing Restore Options

During the restore workflow, AWS Backup presents several recovery options:

- **Restore scope** – entire EKS cluster or a specific namespace.  
- **Restore destination** – original source cluster, an existing EKS cluster, or a brand‑new cluster created as part of the restore.

In this walkthrough I restored into a newly created EKS cluster to demonstrate the full capabilities of native EKS recovery and to validate how well the feature supports clean, isolated disaster‑recovery scenarios.

![Restore scope screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fguer8ohxzfccwft09200.png)

### Selecting Storage Resources

The next step asks you to select the storage resources to include in the restore.  
In my case no persistent storage was attached to the workloads, but AWS Backup also supports restoring data backed by **Amazon EBS**, **EFS**, and **S3**, ensuring that application data and cluster state remain consistent.

![Storage selection screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fp5f2v9ad64fcfq426wjk.png)

### Restoration in Progress

Once the restore is initiated, AWS Backup begins recreating the cluster based on the selected recovery options, provisioning a new EKS environment as specified. This doesn’t replace disciplined GitOps workflows or careful upgrade strategies, but it finally gives platform teams a native, reliable safety net. For production EKS environments, that’s a meaningful shift in operational confidence.

![Restore progress screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3sgwfxmyy72zkhprlvk6.png)

최종 생각

AWS Backup의 네이티브 Amazon EKS 지원은 플랫폼 팀이 전통적으로 직접 관리해야 했던 복잡성을 크게 줄여줍니다. 추가 컨트롤러나 운영 오버헤드 없이 일관된 정책 기반 백업과 예측 가능한 복원을 제공합니다.

중요한 고려 사항

  • 모든 Kubernetes 리소스가 그대로 복원되는 것은 아니며, 특히 외부 통합 및 클라우드 관리 서비스는 예외입니다.
  • 복원 시간은 영구 볼륨 크기와 데이터 양에 크게 좌우됩니다.
  • 스냅샷, 스토리지 및 보존에 대해 표준 AWS Backup 비용이 적용됩니다.
  • 이는 GitOps를 대체하지 않으며, 마지막으로 정상 작동했던 런타임 복구 옵션을 제공함으로써 보완합니다.

AWS에서 프로덕션 EKS를 운영하는 팀에게 이 기능은 좋은 엔지니어링 관행의 필요성을 없애지는 않지만, 클러스터 수준 장애와 관련된 위험과 스트레스를 크게 감소시킵니다. 이것만으로도 EKS 운영 툴킷에 의미 있는 추가가 됩니다.

참고 자료

Back to Blog

관련 글

더 보기 »