SW BBANG K

프라이빗 서브넷의 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 장...

프로덕션 RDS 인스턴스를 처음 설정할 때 Multi-AZ 옵션을 보고 '이거 켜면 성능도 좋아지겠지?'라고 생각했다면, 그 가정이 장애 대응 중에 당신을 배신할 수 있다. Multi-AZ는 고가용성과 페일오버 를 위한 기능이지, 읽기 성능 향상을 위한 기능이 아니다. TL;DR: RDS Multi-AZ 핵심 요약 항목 Multi-AZ 동작 목적 고가용성 및 자동 페일오버 스탠바이 인스턴스 직접 접근 불가 (읽기/쓰기 모두 차단) 읽기 성능 향상 없음 — 읽기 스케일아웃은 Read Replica 사용 쓰기 성능 영향 동기 복제로 인한 소폭 지연 가능 페일오버 소요 시간 일반적으로 60~120초 (공식 보장 없음) 데이터 내구성 동기 복제로 RPO ≈ 0 자동 백업 스탠바이에서 수행 (프라이머리 I/O 영향 감소) RDS Multi-AZ가 실제로 하는 일 Multi-AZ를 활성화하면 AWS는 다른 가용 영역(AZ)에 스탠바이 인스턴스를 자동으로 프로비저닝한다. 프라이머리 인스턴스에 쓰기가 발생하면 Amazon RDS는 동기식 블록 수준 복제를 통해 스탠바이에 데이터를 미러링한다. 애플리케이션은 항상 프라이머리 엔드포인트 하나만 바라본다. 여기서 핵심은 동기(synchronous) 복제 라는 점이다. 프라이머리가 트랜잭션을 커밋하기 전에 스탠바이에도 기록이 완료되어야 한다. 이 구조 덕분에 페일오버 시 데이터 손실이 없지만, 반대로 스탠바이는 항상 '대기 중'이지 '서비스 중'이 아니다. graph LR App["애플리케이션"] -->|"단일 엔드포인트 (DNS)"| Primary["프라이머리 인스턴스 AZ-A"] Primary -->|"동기 ...