SW BBANG K

새벽 2시에 온콜 알림이 울렸다. EC2 인스턴스가 응답을 멈췄는데, DNS가 여전히 죽은 서버를 가리키고 있어서 사용자들은 그냥 타임아웃 화면만 보고 있었다. Route 53 DNS 페일오버를 미리 구성해뒀다면, 헬스 체크가 실패하는 순간 트래픽이 S3 정적 백업 사이트로 자동 전환됐을 것이다. 이 글은 그 설정을 처음부터 끝까지 다룬다. TL;DR — Route 53 DNS 페일오버 핵심 요약 단계 구성 요소 역할 1 Route 53 헬스 체크 EC2 엔드포인트 상태를 주기적으로 확인 2 Primary 레코드 (Failover) EC2를 가리키며 헬스 체크와 연결 3 Secondary 레코드 (Failover) S3 정적 웹사이트 엔드포인트를 가리킴 4 S3 버킷 정적 웹사이트 호스팅 백업 페이지 서빙 5 자동 전환 헬스 체크 실패 시 Secondary로 DNS 응답 변경 Route 53 DNS 페일오버 동작 원리 Route 53의 페일오버 라우팅 정책은 Active-Passive 구조다. Primary 레코드에 헬스 체크를 연결해두면, Route 53 헬스 체커가 전 세계 여러 위치에서 해당 엔드포인트를 주기적으로 폴링한다. 헬스 체크가 임계값 이상 실패하면 Route 53은 해당 레코드를 'Unhealthy'로 표시하고, 동일한 이름과 타입을 가진 Secondary 레코드로 DNS 응답을 전환한다. 중요한 점은 이것이 DNS 레벨의 전환이라는 것이다. 기존 TCP 연결은 끊기지 않으며, TTL이 만료된 이후 새로운 DNS 조회부터 Secondary 주소를 받게 된다. 따라서 TTL 값 설정이 실제 전환 속도에 직접적인 영향을 준다. sequenceDiagram participant Client as 클라이언트 participant R53 as Route...

5개의 EC2 인스턴스가 동일한 디렉토리를 읽고 써야 하는 상황이 생겼다. 처음엔 EBS 볼륨 하나를 여러 인스턴스에 붙이면 되지 않을까 생각했는데, 실제로 해보려고 하면 콘솔에서 막히거나 데이터가 꼬이는 경험을 하게 된다. 이 글은 여러 EC2 인스턴스 간 스토리지 공유 문제를 EBS와 EFS 관점에서 실제 운영 경험 기반으로 정리한다. TL;DR — EBS vs EFS 핵심 비교 항목 EBS (일반 볼륨) EBS Multi-Attach EFS 동시 다중 인스턴스 마운트 ❌ 불가 ⚠️ 제한적 가능 ✅ 기본 지원 파일시스템 공유 ❌ ❌ (클러스터 파일시스템 필요) ✅ NFS v4.1/4.2 AZ 제약 동일 AZ만 동일 AZ만 리전 전체 (멀티 AZ) 일반적 공유 폴더 용도 ❌ ❌ ✅ 운영 복잡도 낮음 높음 낮음 결론부터: 5개 EC2 인스턴스가 동일 폴더를 공유하려면 EFS를 사용 해야 한다. EBS는 구조적으로 단일 인스턴스 전용 블록 스토리지이며, Multi-Attach는 공유 파일시스템을 제공하지 않는다. EBS와 EFS의 동작 원리 — 왜 EBS는 공유가 안 되는가 EBS는 블록 스토리지다. 인스턴스에 마운트되면 해당 OS가 파일시스템(ext4, xfs 등)을 직접 관리한다. 두 인스턴스가 동시에 같은 EBS 볼륨을 마운트하면, 각 OS가 독립적으로 파일시스템 메타데이터를 쓰게 되어 데이터 손상이 발생한다. 이건 AWS 제약이 아니...

배포 직후엔 멀쩡하던 서버가 트래픽이 몰리고 나서 갑자기 응답이 느려진다. CPU 사용률을 보면 100%도 아닌데 레이턴시는 치솟는다. T3 인스턴스를 운영하다 보면 한 번쯤 마주치는 상황이고, 원인을 모르면 인스턴스 타입을 무작정 업그레이드하게 된다. 문제는 CPU 크레딧이다. TL;DR — T3 CPU 크레딧 핵심 요약 항목 내용 T3 동작 방식 기준선(Baseline) 이하 사용 시 크레딧 적립, 초과 시 소진 크레딧 소진 시 동작 Standard 모드: CPU가 기준선으로 스로틀링 / Unlimited 모드: 추가 과금 후 버스트 유지 T3 기본 모드 Unlimited (T3 출시 이후 기본값) 성능 저하 주요 원인 Standard 모드에서 크레딧 고갈, 또는 Unlimited 모드에서 예상치 못한 추가 비용 진단 지표 CloudWatch: CPUCreditBalance, CPUSurplusCreditsCharged T3 버스터블 인스턴스의 동작 원리 T3는 일반 인스턴스와 달리 vCPU를 항상 전속력으로 쓸 수 없다. 인스턴스 크기마다 정해진 CPU 기준선(Baseline) 이 있고, 그 이하로 사용하면 크레딧이 쌓이고, 초과하면 크레딧을 소진하는 구조다. 크레딧이 있을 때만 기준선 이상의 CPU 성능을 낼 수 있다. 기준선은 인스턴스 크기에 따라 다르다. 예를 들어 t3.micro는 vCPU 2개 기준으로 약 10%의 기준선을 가진다. 즉, 평균 CPU 사용률이 10% 이하일 때 크레딧이 적립되고, 10%를 넘으면 크레딧을 소진한다. 정확한 기준선 수치는 인스턴스 크기마다 다르므로 AWS 공식 문서 에서 확인해야 한다. 크레딧 시스템은 은행 계좌와 비슷하다. 조용할 때 저축하고, 바쁠 때 인출한다. 잔고가 바닥나면 더 이상 인출할 수 없다 — Standard 모드에서는. g...

프라이빗 서브넷의 EC2 인스턴스가 yum update나 apt-get을 실행했는데 타임아웃이 발생하는 상황 — 대부분의 엔지니어가 처음 VPC를 구성할 때 한 번씩 겪는 문제다. 원인은 단순하다. 프라이빗 서브넷은 인터넷 게이트웨이로 직접 라우팅되지 않기 때문에, 아웃바운드 인터넷 트래픽을 처리할 NAT 계층이 없으면 패킷이 어디로도 가지 못한다. 이 포스트는 NAT Gateway vs NAT Instance 선택 기준을 실제 운영 관점에서 정리한다. TL;DR — NAT Gateway vs NAT Instance 핵심 비교 항목 NAT Gateway NAT Instance 관리 주체 AWS 완전 관리형 직접 운영 (EC2) 가용성 AZ 내 자동 이중화 단일 인스턴스 (직접 HA 구성 필요) 대역폭 확장 자동 스케일링 인스턴스 타입에 종속 소스/목적지 확인 자동 비활성화 수동으로 비활성화 필요 보안 그룹 적용 불가 적용 가능 포트 포워딩 지원 안 함 iptables로 구성 가능 비용 구조 시간당 요금 + 데이터 처리 요금 EC2 인스턴스 요금 권장 사용 시나리오 대부분의 프로덕션 환경 비용 최적화가 최우선이거나 커스텀 트래픽 제어가 필요한 경우 NAT가 작동하는 방식 — 먼저 메커니즘을 이해하자 NAT(Network Address Translation)는 프라이빗 IP를 퍼블릭 IP로 변환해서 인터넷으로 내보내고, 응답 패킷을 다시 원래 프라이빗 인스턴스로 돌려보내는 역할을 한다. 핵심은 상태 추적(stateful) 이라는 점이다. 아웃바운드 연결의 소스 IP와 포트를 기록해 두었다가, 인바운드 응답이 들어오면 해당 기록을 참조해 올바른 내부 인스턴스로 전달한다. VPC 라우팅 관점에서 보면, 프라이빗 서브넷의 라우트 테이블에 0.0.0.0/0 대상을 NAT 장...

EC2 인스턴스를 띄울 때마다 Nginx 설치, 환경 변수 설정, 애플리케이션 배포를 수동으로 반복하고 있다면, User Data를 제대로 활용하지 못하고 있는 것이다. 이 글은 EC2 User Data 를 사용해 인스턴스 최초 부팅 시 셸 스크립트를 자동 실행하는 방법을 실제 운영 관점에서 정리한다. TL;DR — EC2 User Data 핵심 요약 항목 내용 실행 시점 인스턴스 최초 부팅 시 1회 (기본값) 실행 주체 root 권한으로 실행됨 스크립트 시작 반드시 #!/bin/bash 또는 #!/bin/sh 포함 로그 위치 /var/log/cloud-init-output.log 콘솔 입력 위치 인스턴스 시작 마법사 → '고급 세부 정보' → 'User Data' CLI 파라미터 --user-data file://userdata.sh 크기 제한 최대 16KB (일반 텍스트 기준) EC2 User Data가 동작하는 방식 User Data는 cloud-init 데몬이 처리한다. 인스턴스가 처음 부팅될 때 cloud-init은 EC2 인스턴스 메타데이터 서비스(IMDS)에서 User Data를 가져와 실행한다. 스크립트가 #!/bin/bash 로 시작하면 셸 스크립트로 처리되고, #cloud-config 로 시작하면 cloud-init 네이티브 YAML 형식으로 처리된다. 중요한 점은 기본적으로 최초 1회만 실행된다는 것이다. 인스턴스를 재시작해도 User Data는 다시 실행되지 않는다. 매 부팅마다 실행하려면 별도 설정이 필요하다. sequenceDiagram participant EC2 as EC2 인스턴스 participant IMDS as 메타데이터 서비스 participant CI as cloud-init ...

어느 날 오전, 모니터링 알림이 울리고 확인해보니 운영 중이던 EC2 인스턴스가 없다. 콘솔에서 찾을 수 없고, Auto Scaling 그룹도 아니다. 누군가 TerminateInstances API를 직접 호출한 것이다. CloudTrail Event History는 이 상황에서 가장 먼저 열어야 할 도구다. TL;DR — 핵심 요약 단계 목적 핵심 확인 항목 1. Event History 필터 TerminateInstances 이벤트 검색 이벤트 이름, 리소스 ID 2. 이벤트 상세 확인 호출 주체 식별 userIdentity, sourceIPAddress 3. CLI로 정밀 조회 인스턴스 ID 기준 필터링 lookup-events 파라미터 4. 원인 분석 역할/사용자 권한 검토 assumedRole, sessionContext CloudTrail Event History가 동작하는 방식 CloudTrail은 AWS 계정 내 API 호출을 기록하는 감사 로그 서비스다. 리전별로 활성화되며, 별도 Trail을 구성하지 않아도 Event History 는 기본적으로 각 리전에서 최근 90일간의 관리 이벤트(Management Events)를 자동으로 보관한다. EC2 인스턴스 종료는 TerminateInstances API 호출로 기록되며, 이 이벤트에는 호출 주체, 시간, 소스 IP, 대상 리소스 정보가 포함된다. 중요한 점은 Event History가 기록하는 것은 관리 이벤트(Management Events) 뿐이라는 것이다. S3 객체 읽기 같은 데이터 이벤트는 별도 Trail 설정이 필요하다. EC2 종료는 관리 이벤트에 해당하므로 기본 Event History에서 조회 가능하다. sequenceDiagram participant U as IAM 사용자/역할 partic...

ASG가 멀쩡히 응답하는 인스턴스를 계속 교체하고 있다면, 헬스 체크 타입 설정을 의심해야 한다. 'EC2' 타입은 인스턴스 OS가 살아있는지만 확인하고, 실제 애플리케이션이 HTTP 200을 반환하는지는 전혀 모른다 — 이 간극이 예상치 못한 인스턴스 교체 루프의 원인이 되는 경우가 많다. TL;DR: Auto Scaling Group 헬스 체크 타입 비교 항목 EC2 헬스 체크 ELB 헬스 체크 확인 대상 인스턴스 상태 (하이퍼바이저 레벨) 애플리케이션 응답 (HTTP/TCP) 기본값 예 (ASG 생성 시 기본) 아니오 (명시적 활성화 필요) Unhealthy 판정 조건 stopped, terminated, stopping, shutting-down ELB 타겟 그룹이 unhealthy로 표시 적합한 상황 인스턴스 장애 복구만 필요한 경우 앱 레벨 장애 자동 복구가 필요한 경우 오탐 위험 낮음 ELB 헬스 체크 설정에 따라 높을 수 있음 Auto Scaling Group 헬스 체크가 동작하는 방식 ASG는 주기적으로 각 인스턴스의 상태를 평가하고, unhealthy로 판정된 인스턴스를 종료한 뒤 새 인스턴스로 교체한다. 이 판정의 기준이 바로 헬스 체크 타입이다. EC2 헬스 체크 는 EC2 서비스 자체가 보고하는 인스턴스 상태(instance status)를 기반으로 한다. 인스턴스가 running 상태이고 시스템 상태 체크를 통과하면 healthy로 간주한다. 즉, Nginx가 죽어있어도, 앱 프로세스가 OOM으로 종료되어도 — OS가 살아있으면 ASG는 아무 조치를 취하지 않는다. ELB 헬스 체크 를 활성화하면 ASG는 연결된 로드 밸런서(ALB/NLB)의 타겟 그룹이 해당 인스턴스를 healthy로 표시하는지를 추가로 확인한다. ELB가 unhealthy로 표시하...