SW BBANG K

Lambda 함수가 Private Subnet에 있는 RDS 인스턴스에 연결되지 않는 상황은 생각보다 자주 발생한다. 'Lambda에서 Private RDS 연결'을 처음 구성할 때 가장 많이 놓치는 부분이 Lambda 자체에 VPC 설정을 붙여야 한다는 사실이다 — Lambda는 기본적으로 AWS 관리 네트워크에서 실행되기 때문에, VPC 내부 리소스에는 아예 도달할 수 없다. TL;DR — Lambda에서 Private RDS 연결 핵심 요약 항목 설명 Lambda VPC 설정 필요 여부 필수. Subnet ID와 Security Group ID를 Lambda에 지정해야 함 Lambda용 Subnet 선택 RDS와 동일한 VPC 내 Private Subnet (가용 영역 2개 이상 권장) Security Group 규칙 Lambda SG → RDS SG 인바운드 허용 (포트 3306/5432) 인터넷 액세스 필요 시 NAT Gateway 경유 라우팅 필요 (IGW 직접 연결 불가) IAM 권한 Lambda 실행 역할에 VPC ENI 생성 권한 필요 연결 진단 순서 VPC 설정 → SG 규칙 → Subnet 라우팅 → IAM → RDS 상태 Lambda가 Private RDS에 연결되는 원리 Lambda 함수는 기본 실행 환경에서 AWS 관리 네트워크에 위치한다. 이 상태에서는 퍼블릭 엔드포인트(S3, DynamoDB 등)에는 접근할 수 있지만, 고객 VPC 내부의 RDS처럼 프라이빗 리소스에는 네트워크 경로 자체가 없다. Lambda에 VPC 설정을 추가하면, AWS는 Lambda 실행 환경과 고객 VPC 사이에 Hyperplane ENI(Elastic Network Interface) 를 생성한다. 이 ENI가 지정한 Subnet에 배치되고, 지정한 Security...

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

같은 계정, 같은 리전에 VPC가 두 개 있는데 서로 프라이빗 IP로 통신이 안 된다 — 이건 AWS를 처음 쓰는 팀이든 오래 쓴 팀이든 한 번씩은 마주치는 상황이다. VPC 피어링(VPC Peering) 자체는 단순하지만, 라우트 테이블과 보안 그룹까지 세 군데를 동시에 맞춰야 트래픽이 흐른다. 하나라도 빠지면 핑이 안 되고, 어디가 문제인지 찾는 데 시간을 쓰게 된다. TL;DR — VPC 피어링 핵심 요약 단계 작업 주체 핵심 포인트 1. 피어링 연결 요청 Requester VPC 상대 VPC ID 지정, 같은 계정이면 자동 수락 가능 2. 피어링 연결 수락 Accepter VPC 수락 전까지 트래픽 불가 3. 라우트 테이블 업데이트 양쪽 VPC 모두 상대 CIDR → pcx-xxxxxx, 양방향 필수 4. 보안 그룹 업데이트 양쪽 인스턴스 상대 CIDR 또는 SG ID 허용 5. 통신 검증 운영자 VPC Flow Logs 또는 ping/curl 확인 VPC 피어링이 동작하는 방식 VPC 피어링은 두 VPC 사이에 논리적인 1:1 네트워크 경로를 만든다. 인터넷 게이트웨이, NAT, VPN, 별도의 게이트웨이 장비가 전혀 개입하지 않는다. AWS 내부 네트워크를 통해 직접 라우팅되므로 트래픽이 공인 인터넷을 경유하지 않는다. 중요한 제약이 하나 있다. 피어링은 전이적(transitive) 라우팅을 지원하지 않는다. VPC-A ↔ VPC-B, VPC-B ↔ VPC-C가 각각 피어링되어 있어도 VPC-A에서 VPC-C로 VPC-B를 경유해 통신할 수 없다. 세 VPC가 모두 통신해야 한다면 각각 직접 피어링해야 한다. 또한 두 VPC의 CIDR 블록이 겹치면 피어링 자체가 생성되지 않는다. 설계 단계에서 CIDR 충돌을 반드시 확인해야 한다. graph LR subgraph V...

ALB 액세스 로그에 502가 쏟아지는데 타겟 그룹 콘솔에는 인스턴스가 멀쩡히 Healthy 로 표시되어 있다. 이 상황이 혼란스러운 이유는 ALB의 헬스체크와 실제 요청 처리가 완전히 별개의 레이어에서 동작하기 때문이다. 헬스체크는 통과했지만 실제 HTTP 응답이 ALB의 기대를 벗어나는 순간 502가 발생한다. TL;DR — ALB 502 원인 분류 원인 카테고리 증상 핵심 확인 지점 HTTP 프로토콜 위반 모든 요청에서 502 발생 응답 헤더 형식, Content-Length 불일치 Keep-Alive 타임아웃 불일치 간헐적 502, 로드 증가 시 악화 ALB idle timeout vs 앱 서버 keep-alive timeout 응답 헤더 크기 초과 특정 요청에서만 502 응답 헤더 총 크기 타겟 연결 거부/타임아웃 target_status_code가 비어 있음 보안 그룹, 포트 바인딩 청크 인코딩 오류 대용량 응답에서 502 Transfer-Encoding 헤더 처리 ALB 502가 발생하는 메커니즘 ALB는 클라이언트와 타겟 사이에서 HTTP 레이어 7 프록시로 동작한다. 타겟이 Healthy 상태라는 것은 ALB가 헬스체크 엔드포인트에서 정상 응답을 받았다는 의미일 뿐, 실제 애플리케이션 요청에 대한 응답이 올바르다는 보장이 아니다. ALB는 타겟으로부터 받은 HTTP 응답이 RFC를 위반하거나, 연결이 예기치 않게 끊기거나, 응답 자체를 받지 못하면 클라이언트에게 502를 반환한다. sequenceDiagram participant C as 클라이언트 participant ALB as ALB participant TG as 타겟 인스턴스 C->>ALB: HTTP 요청 ALB->>TG: 요청 전달 (Keep-Alive 연...

커스텀 VPC를 직접 만들고 EC2를 띄웠는데 ping google.com 이 응답하지 않는다. AWS 기본 VPC에서는 아무 설정 없이도 인터넷이 됐는데, 커스텀 VPC에서는 왜 안 될까 — 이 글은 그 질문에 대한 실전 답변이다. TL;DR — 커스텀 VPC EC2 인터넷 불가 핵심 체크리스트 항목 확인 내용 CLI 명령 Internet Gateway 생성 IGW가 존재하는가 aws ec2 describe-internet-gateways IGW VPC 연결 IGW가 해당 VPC에 attach되었는가 aws ec2 attach-internet-gateway Route Table 경로 0.0.0.0/0 → IGW 경로가 있는가 aws ec2 describe-route-tables 서브넷 연결 Public 서브넷이 해당 Route Table에 연결되어 있는가 aws ec2 describe-subnets Public IP 할당 EC2에 Public IP 또는 EIP가 있는가 aws ec2 describe-instances Security Group 아웃바운드 허용 규칙이 있는가 aws ec2 describe-security-groups 커스텀 VPC에서 인터넷이 되려면 — 동작 원리 AWS 기본 VPC(Default VPC)는 계정 생성 시 자동으로 IGW, Route Table, Public 서브넷이 구성된다. 커스텀 VPC는 그 어떤 것도 자동으로 만들어지지 않는다. EC2가 인터넷과 통신하려면 다음 네 가지 조건이 모두 충족되어야 한다. graph LR EC2["EC2 Instance (Public IP 필요)"] --> SG["Security Group 아웃바운드 허용"] SG --> RT["Route Tab...