[Cloud] AWS EC2 자동 복구 설정 가이드 (2026년)

목차

• 서버가 새벽에 죽으면? AWS EC2 자동 복구 설정이 답입니다
• AWS EC2 자동 복구, 정확히 뭔가요?
• 자동 복구(Auto Recovery)란?
• 자동 복구 vs 자동 재시작, 뭐가 다르죠?
• 방법 1: CloudWatch 알람으로 EC2 자동 복구 설정하기
• 지원 인스턴스 타입 확인
• AWS CLI로 자동 복구 설정하기
• Terraform으로 관리하기 (IaC 방식)
• 방법 2: Auto Scaling Group으로 EC2 자동 재시작 설정하기
• Launch Template 먼저 만들기
• Auto Scaling Group 생성
• 인스턴스 리프레시(Instance Refresh) 설정
• 방법 3: EC2 인스턴스 종료 방지 + 자동화 설정
• ⚠️ 실제로 삽질한 것들, AWS EC2 자동 복구 주의사항
• 문제 1: 자동 복구가 작동 안 해요
• 문제 2: 복구 후 애플리케이션이 안 뜨는 경우
• 문제 3: 헬스 체크 유예 기간 때문에 인스턴스가 계속 교체됨
• 문제 4: 복구 알림을 못 받는 경우
• 설정 검증 및 결과 확인하기
• CloudWatch 알람 상태 확인
• 자동 복구 기록 확인
• ASG 활동 로그 확인
• 테스트 방법 (주의해서 하세요!)
• AWS EC2 자동 복구 방법 비교 및 정리
• 마무리 — 자동화가 새벽잠을 지켜줍니다

서버가 새벽에 죽으면? AWS EC2 자동 복구 설정이 답입니다

몇 년 전 일인데요, 새벽 3시에 모니터링 알림 때문에 잠에서 깬 적이 있었습니다. EC2 인스턴스 하나가 하드웨어 장애로 응답이 없어진 거거든요. 그때 저는 부랴부랴 AWS 콘솔에 접속해서 수동으로 인스턴스를 재시작했는데, 그 사이 서비스 다운타임이 20분 가까이 됐었죠. 지금 생각해도 아찔합니다 ㅎㅎ

그 이후로 저는 AWS EC2 자동 복구(Auto Recovery) 설정을 모든 인스턴스에 필수로 적용하고 있어요. 혹시 여러분도 비슷한 경험 있으신가요? 아니면 아직 EC2 자동 복구를 설정 안 하고 운영 중이신 분도 계실 텐데, 이 글이 도움이 됐으면 합니다.

오늘은 AWS EC2 자동 복구 및 재시작 설정을 처음부터 끝까지 제대로 정리해 드릴게요. CloudWatch(클라우드워치) 기반 자동 복구부터, Auto Scaling(오토 스케일링), 그리고 고급 자동화 방법까지 실전 위주로 다뤄보겠습니다.

AWS EC2 자동 복구 전체 구성도 — CloudWatch 알람, EC2 Auto Recovery, Auto Scaling Group이 어떻게 연동되는지 한눈에 볼 수 있습니다.

AWS EC2 자동 복구, 정확히 뭔가요?

자동 복구(Auto Recovery)란?

쉽게 말해서, EC2 인스턴스가 하드웨어 장애나 네트워크 문제로 정상 동작하지 않을 때 AWS가 알아서 인스턴스를 다른 정상 하드웨어로 옮겨서 재시작해주는 기능이에요. 사람이 개입하지 않아도 되는 거죠.

이때 중요한 게 있는데요, EC2 자동 복구가 실행되면 인스턴스 ID, 개인 IP, Elastic IP(탄력적 IP), 인스턴스 메타데이터는 그대로 유지됩니다. 반면 인스턴스 스토어(Instance Store)에 있던 데이터는 날아가요. 이 부분은 꼭 기억해 두셔야 해요.

자동 복구 vs 자동 재시작, 뭐가 다르죠?

저도 처음엔 이 둘이 헷갈렸거든요. AWS EC2 자동 복구와 자동 재시작은 작동 방식이 완전히 달라요. 정리하면 이렇습니다.

구분	자동 복구 (Auto Recovery)	자동 재시작 (Auto Restart via ASG)
트리거	하드웨어/시스템 장애	인스턴스 종료, Health Check 실패
인스턴스 ID	유지됨	새 인스턴스 생성 (ID 변경)
IP 주소	Private/Elastic IP 유지	새 IP 할당 (Elastic IP 연결 필요)
설정 방법	CloudWatch 알람	Auto Scaling Group
적합한 상황	단일 인스턴스 복구	확장성 있는 서비스

상황에 따라 두 가지를 같이 쓰는 경우도 많아요. 저는 보통 스테이트풀(Stateful, 상태를 저장하는) 서비스에는 AWS EC2 자동 복구를, 스테이트리스(Stateless, 상태 비저장) 서비스에는 Auto Scaling Group을 쓰더라고요.

방법 1: CloudWatch 알람으로 EC2 자동 복구 설정하기

가장 기본적이고 직접적인 방법이에요. CloudWatch(클라우드워치, AWS 모니터링 서비스) 알람을 설정해서 인스턴스에 문제가 생기면 자동으로 EC2 자동 복구 액션을 실행하도록 하는 거거든요.

지원 인스턴스 타입 확인

⚠️ 먼저 확인하셔야 할 게 있어요. AWS EC2 자동 복구는 모든 인스턴스 타입을 지원하지 않습니다. C3, C4, C5, M3, M4, M5, R3, R4, R5, T2, T3, X1 계열 등 대부분의 최신 타입은 지원하지만, 인스턴스 스토어 볼륨을 사용하는 타입은 지원 안 돼요. 2026년 현재는 대부분의 Nitro 기반 인스턴스에서 AWS EC2 자동 복구를 지원합니다.

AWS CLI로 자동 복구 설정하기

콘솔에서 클릭해도 되지만, 저는 CLI(명령줄 인터페이스)로 하는 걸 더 선호해요. 재현 가능하고 자동화하기도 쉽거든요.

1단계: 인스턴스 상태 체크 알람 생성

# StatusCheckFailed_System 메트릭 기반 자동 복구 알람 생성
aws cloudwatch put-metric-alarm \
  --alarm-name "EC2-AutoRecover-i-1234567890abcdef0" \
  --alarm-description "EC2 인스턴스 시스템 상태 체크 실패 시 자동 복구" \
  --metric-name StatusCheckFailed_System \
  --namespace AWS/EC2 \
  --statistic Minimum \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --period 60 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:automate:ap-northeast-2:ec2:recover \
  --ok-actions arn:aws:sns:ap-northeast-2:123456789012:MyAlertTopic \
  --treat-missing-data breaching

💡 여기서 중요한 포인트! StatusCheckFailed_System은 AWS 인프라 문제를 감지하고, StatusCheckFailed_Instance는 OS/애플리케이션 문제를 감지해요. AWS EC2 자동 복구 액션은 System 체크 실패에만 동작합니다.

2단계: 인스턴스 재시작 알람도 추가 (선택)

# 인스턴스 상태 체크 실패 시 재시작 알람
aws cloudwatch put-metric-alarm \
  --alarm-name "EC2-AutoRestart-i-1234567890abcdef0" \
  --alarm-description "EC2 인스턴스 상태 체크 실패 시 재시작" \
  --metric-name StatusCheckFailed_Instance \
  --namespace AWS/EC2 \
  --statistic Minimum \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --period 60 \
  --evaluation-periods 3 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:automate:ap-northeast-2:ec2:reboot \
  --treat-missing-data breaching

Terraform으로 관리하기 (IaC 방식)

실제 운영 환경에서는 Terraform(테라폼, 인프라 코드화 도구)으로 관리하는 게 훨씬 편해요. AWS EC2 자동 복구 설정을 코드로 관리하면 버전 관리도 되고 재현도 쉽거든요.

resource "aws_cloudwatch_metric_alarm" "ec2_auto_recover" {
  alarm_name          = "ec2-auto-recover-${var.instance_id}"
  alarm_description   = "EC2 시스템 상태 체크 실패 시 자동 복구"
  metric_name         = "StatusCheckFailed_System"
  namespace           = "AWS/EC2"
  statistic           = "Minimum"
  period              = 60
  evaluation_periods  = 2
  threshold           = 1
  comparison_operator = "GreaterThanOrEqualToThreshold"
  treat_missing_data  = "breaching"

  dimensions = {
    InstanceId = var.instance_id
  }

  alarm_actions = [
    "arn:aws:automate:${var.region}:ec2:recover"
  ]

  ok_actions = [
    var.sns_topic_arn
  ]

  tags = {
    Name        = "ec2-auto-recover"
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

resource "aws_cloudwatch_metric_alarm" "ec2_auto_reboot" {
  alarm_name          = "ec2-auto-reboot-${var.instance_id}"
  alarm_description   = "EC2 인스턴스 상태 체크 실패 시 재부팅"
  metric_name         = "StatusCheckFailed_Instance"
  namespace           = "AWS/EC2"
  statistic           = "Minimum"
  period              = 60
  evaluation_periods  = 3
  threshold           = 1
  comparison_operator = "GreaterThanOrEqualToThreshold"
  treat_missing_data  = "breaching"

  dimensions = {
    InstanceId = var.instance_id
  }

  alarm_actions = [
    "arn:aws:automate:${var.region}:ec2:reboot"
  ]
}

CloudWatch 알람에서 EC2 자동 복구 액션을 설정하는 화면 — StatusCheckFailed_System 메트릭과 recover 액션이 연결된 모습입니다.

방법 2: Auto Scaling Group으로 EC2 자동 재시작 설정하기

단일 인스턴스가 아니라 서비스 가용성 자체를 높이고 싶다면 Auto Scaling Group(ASG, 오토 스케일링 그룹)을 쓰는 게 맞아요. 인스턴스가 완전히 죽어도 새 인스턴스를 자동으로 띄워주거든요.

Launch Template 먼저 만들기

# Launch Template 생성
aws ec2 create-launch-template \
  --launch-template-name "my-app-template" \
  --version-description "초기 버전" \
  --launch-template-data '{
    "ImageId": "ami-0c9c942bd7bf113a2",
    "InstanceType": "t3.medium",
    "KeyName": "my-keypair",
    "SecurityGroupIds": ["sg-0123456789abcdef0"],
    "IamInstanceProfile": {
      "Name": "my-instance-profile"
    },
    "UserData": "IyEvYmluL2Jhc2gKc3VkbyB5dW0gdXBkYXRlIC15",
    "TagSpecifications": [{
      "ResourceType": "instance",
      "Tags": [{"Key": "Name", "Value": "my-app-server"}]
    }],
    "MetadataOptions": {
      "HttpTokens": "required",
      "HttpPutResponseHopLimit": 1
    }
  }'

Auto Scaling Group 생성

# Auto Scaling Group 생성 (최소 1개, 원하는 수 1개, 최대 3개)
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name "my-app-asg" \
  --launch-template LaunchTemplateName=my-app-template,Version='$Latest' \
  --min-size 1 \
  --max-size 3 \
  --desired-capacity 1 \
  --vpc-zone-identifier "subnet-0123456789abcdef0,subnet-0fedcba9876543210" \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --tags Key=Name,Value=my-app-server,PropagateAtLaunch=true

💡 health-check-grace-period(헬스 체크 유예 기간)를 충분히 주는 게 정말 중요해요. 애플리케이션 기동 시간보다 짧으면 멀쩡한 인스턴스가 계속 교체되는 황당한 상황이 벌어지거든요. 저도 처음에 이걸 너무 짧게 줬다가 인스턴스가 무한 교체되는 걸 보고 식겁했습니다 ㅎㅎ

인스턴스 리프레시(Instance Refresh) 설정

AMI(아마존 머신 이미지)를 업데이트하거나 설정을 바꿀 때 무중단으로 인스턴스를 교체하는 기능인데요, 이것도 자동화해두면 정말 편해요.

# 인스턴스 리프레시 시작
aws autoscaling start-instance-refresh \
  --auto-scaling-group-name "my-app-asg" \
  --preferences '{
    "MinHealthyPercentage": 90,
    "InstanceWarmup": 300,
    "CheckpointPercentages": [20, 50, 100],
    "CheckpointDelay": 600
  }'

방법 3: EC2 인스턴스 종료 방지 + 자동화 설정

이건 좀 다른 관점인데요, 실수로 인스턴스가 종료되는 것을 막는 방법이에요. 운영 중에 누군가 실수로 인스턴스를 Terminate(종료)해버리는 경우가 생각보다 많거든요. 저도 스테이징 환경이라고 생각하고 프로덕션 EC2 인스턴스를 종료한 적이 있었는데... 그때 정말 아찔했습니다.

# EC2 인스턴스 종료 방지 활성화
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --disable-api-termination

# 종료 방지 상태 확인
aws ec2 describe-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --attribute disableApiTermination

그리고 EC2 인스턴스가 중지(Stop)됐을 때 자동으로 재시작하도록 하는 설정도 있어요.

# EC2 인스턴스 중지 시 동작 설정 (terminate 대신 stop으로 설정)
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --instance-initiated-shutdown-behavior stop

⚠️ 실제로 삽질한 것들, AWS EC2 자동 복구 주의사항

이론은 이론이고, 실제로 하다 보면 별별 상황이 다 생기더라고요. AWS EC2 자동 복구를 설정할 때 제가 겪은 것들 솔직하게 공유해 드릴게요.

문제 1: 자동 복구가 작동 안 해요

가장 흔한 원인은 인스턴스 타입이 AWS EC2 자동 복구를 지원하지 않는 경우예요. 특히 인스턴스 스토어 볼륨이 붙어 있는 인스턴스는 자동 복구가 안 됩니다. EBS(Elastic Block Store, 탄력적 블록 스토리지)만 사용하는 인스턴스에서만 동작해요.

• 인스턴스 타입 확인: Nitro 기반 인스턴스인지 확인
• 루트 볼륨이 EBS인지 확인
• CloudWatch 알람 ARN이 올바른 리전인지 확인
• IAM(Identity and Access Management, 권한 관리) 권한 확인

문제 2: 복구 후 애플리케이션이 안 뜨는 경우

AWS EC2 자동 복구로 인스턴스는 복구됐는데 정작 서비스가 안 되는 경우가 있어요. 이건 대부분 애플리케이션 서비스가 자동 시작으로 등록이 안 된 경우예요. systemd(시스템디, 리눅스 서비스 관리자) 설정을 꼭 확인하세요.

# 서비스 자동 시작 설정 확인
systemctl is-enabled my-application

# 자동 시작 활성화
systemctl enable my-application

# 서비스 상태 확인
systemctl status my-application

문제 3: 헬스 체크 유예 기간 때문에 인스턴스가 계속 교체됨

앞에서도 잠깐 언급했는데, ASG의 health-check-grace-period가 너무 짧으면 AWS EC2 인스턴스가 기동 중인데 헬스 체크에 실패해서 계속 교체되는 상황이 발생해요. 애플리케이션 기동 시간 + 여유 시간을 넉넉하게 설정하세요. 저는 보통 실제 기동 시간의 1.5배 정도로 설정하더라고요.

문제 4: 복구 알림을 못 받는 경우

AWS EC2 자동 복구가 됐는지 안 됐는지 모르면 의미가 없죠. SNS(Simple Notification Service, 간단한 알림 서비스) 토픽을 연결해서 Slack이나 이메일로 알림을 받도록 설정하는 걸 꼭 추천드려요.

# SNS 토픽 생성
aws sns create-topic --name ec2-recovery-alerts

# 이메일 구독 추가
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-2:123456789012:ec2-recovery-alerts \
  --protocol email \
  --notification-endpoint your-email@example.com

설정 검증 및 결과 확인하기

AWS EC2 자동 복구 설정을 다 했으면 실제로 잘 동작하는지 검증해봐야겠죠? 드디어 이 단계까지 왔네요 🎉

CloudWatch 알람 상태 확인

# 알람 목록 및 상태 확인
aws cloudwatch describe-alarms \
  --alarm-names "EC2-AutoRecover-i-1234567890abcdef0" \
  --query 'MetricAlarms[*].{Name:AlarmName,State:StateValue,Action:AlarmActions}' \
  --output table

자동 복구 기록 확인

# 인스턴스 이벤트 히스토리 확인
aws ec2 describe-instance-status \
  --instance-ids i-1234567890abcdef0 \
  --include-all-instances \
  --query 'InstanceStatuses[*].Events'

ASG 활동 로그 확인

# Auto Scaling Group 활동 내역 확인
aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name my-app-asg \
  --max-items 10 \
  --query 'Activities[*].{Time:StartTime,Status:StatusCode,Desc:Description}' \
  --output table

CloudWatch 대시보드에서 EC2 상태 체크 메트릭과 AWS EC2 자동 복구 알람 상태를 모니터링하는 화면 — 정상 상태(OK)와 알람 상태가 시각적으로 구분됩니다.

테스트 방법 (주의해서 하세요!)

⚠️ 프로덕션 환경에서는 절대 하지 마시고, 테스트 환경에서만 해보세요.

1. CloudWatch 알람을 수동으로 ALARM 상태로 변경해서 AWS EC2 자동 복구 액션이 실행되는지 확인
2. AWS 콘솔에서 인스턴스를 Stop했다가 ASG가 새 인스턴스를 자동으로 띄우는지 확인
3. 부하 테스트로 인스턴스가 비정상 상태가 됐을 때 동작 확인

# CloudWatch 알람 수동 ALARM 상태 설정 (테스트용)
aws cloudwatch set-alarm-state \
  --alarm-name "EC2-AutoRecover-i-1234567890abcdef0" \
  --state-value ALARM \
  --state-reason "자동 복구 테스트"

AWS EC2 자동 복구 방법 비교 및 정리

AWS EC2 자동 복구 세 가지 방법 비교 — 상황에 따라 적합한 방법이 다르므로 서비스 특성에 맞게 선택하는 것이 중요합니다.

설정 방법	적합한 상황	복구 시간	설정 복잡도	비용
CloudWatch 자동 복구	단일 인스턴스, 스테이트풀 서비스	3~5분	낮음	CloudWatch 알람 비용
Auto Scaling Group	스테이트리스 서비스, 고가용성	5~10분	중간	추가 비용 없음
두 가지 병행	미션 크리티컬 서비스	3~5분	높음	CloudWatch 알람 비용

마무리 — 자동화가 새벽잠을 지켜줍니다

처음에 말씀드린 새벽 3시 사건 이후로, 저는 인프라 자동화에 훨씬 더 진지하게 임하게 됐어요. AWS EC2 자동 복구 설정은 사실 한 번만 해두면 그다음부터는 신경 쓸 일이 많이 줄어들거든요. 물론 완벽한 건 아니지만, 없는 것과 있는 것의 차이는 엄청나더라고요.

오늘 다룬 AWS EC2 자동 복구 내용을 정리하면 이렇습니다.

• ✅ CloudWatch 알람 기반 자동 복구 — 하드웨어 장애 대응
• ✅ Auto Scaling Group — 인스턴스 완전 장애 시 자동 교체
• ✅ 종료 방지 + 자동 시작 — 실수 방지 및 OS 재시작 후 서비스 자동 기동
• ✅ SNS 알림 연동 — 복구 이벤트 실시간 알림

다음 글에서는 AWS EC2 자동 복구와 함께 쓰면 더 강력한 EventBridge(이벤트브릿지) + Lambda를 활용한 고급 자동화를 다뤄볼 예정이에요. 인스턴스 상태 변화에 따라 더 세밀한 대응을 자동화하는 방법인데, 꽤 실용적이니 기대해 주세요.

혹시 AWS EC2 자동 복구 설정하다가 막히는 부분이 있으시면 댓글로 남겨주세요. 같이 고민해 볼게요! 😊

📚 함께 읽으면 좋은 글

• Ansible Vault: 민감 정보 안전 관리 및 자동화 보안 강화 가이드
• Pulumi vs Terraform: 2026년 IaC 도구 완벽 비교 분석
• Terraform State 관리 보안: 1.7+ Remote Backend & 암호화 설정 가이드