Lambda에서 Private RDS 연결 안 될 때 — VPC 설정부터 Security Group까지 완전 진단

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 Group이 적용된다. Lambda 코드는 이 ENI를 통해 VPC 내부 리소스와 통신하게 된다.

graph LR subgraph AWS_Managed["AWS 관리 네트워크"] LambdaDefault["Lambda (VPC 미설정)"] end subgraph CustomerVPC["고객 VPC"] subgraph PrivateSubnet["Private Subnet"] ENI["Hyperplane ENI"] RDS["RDS Instance"] end NAT["NAT Gateway"] end Internet["인터넷"] LambdaDefault -. "연결 불가" .-> RDS LambdaVPC["Lambda (VPC 설정 후)"] --> ENI ENI --> RDS ENI --> NAT NAT --> Internet
  1. 기본 Lambda (VPC 미설정): AWS 관리 네트워크에서 실행. VPC 내부 RDS에 도달 불가.
  2. VPC 설정 후: Lambda 실행 환경 ↔ Hyperplane ENI ↔ 고객 VPC Subnet 경로 생성.
  3. Security Group: Lambda에 붙은 SG가 RDS SG의 인바운드 규칙에서 허용되어야 통신 가능.
  4. NAT Gateway: VPC에 배치된 Lambda가 외부 인터넷(예: 외부 API)에 접근하려면 NAT Gateway가 필요. IGW는 Lambda ENI에 직접 연결되지 않는다.

Step 1 — Lambda에 VPC 설정 추가 (Private RDS 연결의 전제 조건)

VPC 설정이 없는 Lambda는 Private RDS에 연결 자체가 불가능하다. 먼저 현재 Lambda의 VPC 설정 상태를 확인한다.

aws lambda get-function-configuration \
  --function-name my-function \
  --query 'VpcConfig' \
  --region us-east-1

출력에 VpcId가 비어 있거나 SubnetIds가 없으면 VPC 설정이 없는 상태다. 아래 명령으로 VPC 설정을 추가한다.

aws lambda update-function-configuration \
  --function-name my-function \
  --vpc-config SubnetIds=subnet-0abc1234,subnet-0def5678,SecurityGroupIds=sg-0lambda1234 \
  --region us-east-1

Subnet은 RDS가 위치한 VPC 내의 Private Subnet을 지정한다. 가용 영역(AZ)을 2개 이상 포함하는 것이 운영 환경에서 권장된다 — Lambda 실행 환경이 특정 AZ에서 ENI를 생성하지 못할 경우 다른 AZ로 폴백할 수 있기 때문이다.

Step 2 — Security Group 인바운드 규칙 확인

VPC 설정을 붙였는데도 연결이 안 된다면 십중팔구 Security Group 문제다. Lambda에 붙은 SG에서 RDS SG로의 트래픽이 허용되어 있는지 확인해야 한다.

먼저 RDS 인스턴스에 붙은 Security Group을 확인한다.

aws rds describe-db-instances \
  --db-instance-identifier my-db-instance \
  --query 'DBInstances[*].VpcSecurityGroups' \
  --region us-east-1

그 다음, 해당 RDS SG의 인바운드 규칙을 확인한다.

aws ec2 describe-security-groups \
  --group-ids sg-0rds5678 \
  --query 'SecurityGroups[*].IpPermissions' \
  --region us-east-1

RDS SG 인바운드 규칙에 Lambda SG(sg-0lambda1234)가 소스로 허용되어 있어야 한다. IP CIDR로 열어두는 방식보다 SG를 소스로 지정하는 것이 더 정확하고 관리하기 쉽다. 규칙이 없다면 추가한다.

aws ec2 authorize-security-group-ingress \
  --group-id sg-0rds5678 \
  --protocol tcp \
  --port 3306 \
  --source-group sg-0lambda1234 \
  --region us-east-1

PostgreSQL이라면 포트를 5432로 변경한다.

graph LR LambdaFn["Lambda 함수"] --> LambdaSG["Lambda SG sg-0lambda1234"] LambdaSG -- "아웃바운드 허용 (3306/5432)" --> RDSSL["RDS SG sg-0rds5678"] RDSSL -- "인바운드 규칙: Source = sg-0lambda1234" --> RDSInst["RDS Instance"] subgraph SubnetLayer["Subnet 레벨"] NACL["Network ACL (stateless)"] end LambdaSG -. "NACL 통과 필요" .-> NACL NACL -. "인바운드 + 아웃바운드 각각 허용 필요" .-> RDSSL
  1. Lambda SG (sg-0lambda1234): 아웃바운드 규칙에서 RDS 포트(3306/5432)로의 트래픽을 허용해야 한다. 기본 아웃바운드 규칙은 전체 허용이지만, 커스텀 제한이 있을 경우 확인 필요.
  2. RDS SG (sg-0rds5678): 인바운드 규칙에서 Lambda SG를 소스로 허용해야 한다.
  3. Network ACL: Subnet 레벨 필터. NACL이 기본값(전체 허용)이 아닌 경우, 해당 포트와 임시 포트(ephemeral ports) 범위도 확인해야 한다.

Step 3 — Lambda 실행 역할 IAM 권한 확인

Lambda가 VPC ENI를 생성하려면 실행 역할에 특정 EC2 권한이 필요하다. 이 권한이 없으면 Lambda 배포 또는 콜드 스타트 시점에 ENI 생성에 실패하고 연결이 되지 않는다.

Lambda 실행 역할을 확인한다.

aws lambda get-function-configuration \
  --function-name my-function \
  --query 'Role' \
  --region us-east-1

해당 역할에 아래 정책이 포함되어 있어야 한다. AWS 관리형 정책인 AWSLambdaVPCAccessExecutionRole을 사용하는 것이 가장 간단하다.

aws iam attach-role-policy \
  --role-name my-lambda-execution-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole

직접 인라인 정책을 작성한다면 최소 권한 원칙에 따라 아래 권한이 필요하다.

🔽 최소 권한 IAM 정책 예시 (클릭하여 펼치기) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateNetworkInterface",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DeleteNetworkInterface"
      ],
      "Resource": "*"
    }
  ]
}

ec2:CreateNetworkInterface와 ec2:DeleteNetworkInterface는 리소스 수준 제한을 지원하지 않아 "Resource": "*"가 필요하다. AWS Service Authorization Reference에서 확인된 동작이다.

Step 4 — Subnet 라우팅 테이블 확인

Lambda가 배치된 Subnet의 라우팅 테이블이 잘못 구성되어 있으면 VPC 내부 통신도 영향을 받을 수 있다. Private Subnet이라면 로컬 라우트(local)만 있어도 VPC 내부 통신은 가능하지만, 외부 인터넷 접근이 필요한 경우 NAT Gateway 라우트가 있어야 한다.

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0abc1234 \
  --query 'RouteTables[*].Routes' \
  --region us-east-1

VPC 내부 RDS 연결만 필요하다면 local 라우트만으로 충분하다. Lambda 코드에서 외부 API를 호출하거나 S3에 접근해야 한다면 NAT Gateway 라우트 또는 VPC 엔드포인트가 필요하다.

VPC에 배치된 Lambda에서 S3에 접근할 때 인터넷을 경유하면 NAT Gateway 비용이 발생한다. S3 게이트웨이 엔드포인트를 사용하면 추가 비용 없이 VPC 내부 경로로 S3에 접근할 수 있다.

Step 5 — RDS 인스턴스 상태 및 엔드포인트 확인

네트워크 설정이 모두 맞는데도 연결이 안 된다면, RDS 인스턴스 자체 상태를 확인해야 한다. 인스턴스가 available 상태가 아니거나, 엔드포인트 주소를 잘못 입력한 경우도 흔하다.

aws rds describe-db-instances \
  --db-instance-identifier my-db-instance \
  --query 'DBInstances[*].{Status:DBInstanceStatus,Endpoint:Endpoint.Address,Port:Endpoint.Port}' \
  --region us-east-1

Lambda 코드에서 사용하는 호스트 주소가 이 엔드포인트와 일치하는지 확인한다. RDS Proxy를 사용하는 경우 RDS 인스턴스 엔드포인트가 아닌 Proxy 엔드포인트를 사용해야 한다.

실제 운영에서 자주 겪는 오진 패턴

Lambda에 VPC 설정을 추가했는데 여전히 연결 타임아웃이 발생한다고 CloudWatch Logs에서 확인된 상황이었다. 처음엔 Security Group 문제라고 판단해서 RDS SG 인바운드를 0.0.0.0/0으로 열어봤는데도 동일한 증상이 반복됐다.

실제 원인은 Lambda Subnet 라우팅 테이블이었다. Lambda를 배치한 Subnet이 Public Subnet이었고, 해당 Subnet의 라우팅 테이블에는 IGW 라우트만 있었다. VPC 내부 로컬 라우트는 있었지만, RDS가 위치한 Subnet과 다른 AZ였고 NACL에서 해당 AZ 간 트래픽을 차단하고 있었다.

Lambda를 Private Subnet으로 이동하고 NACL 규칙을 수정하자 즉시 연결됐다. Security Group만 보고 NACL을 확인하지 않은 것이 오진의 원인이었다.

Security Group은 상태 추적(stateful)이지만, NACL은 상태 비추적(stateless)이다. NACL에서 인바운드를 허용해도 아웃바운드(임시 포트 포함)를 별도로 허용하지 않으면 응답 패킷이 차단된다.

Lambda Private RDS 연결 — 전체 진단 흐름

graph TD Start(["Lambda → RDS 연결 실패"]) --> CheckVPC{"Lambda에 VPC 설정 있음?"} CheckVPC -- "없음" --> AddVPC["VPC 설정 추가 (Subnet + SG)"] AddVPC --> CheckVPC CheckVPC -- "있음" --> CheckSG{"RDS SG 인바운드에 Lambda SG 허용?"} CheckSG -- "없음" --> AddSGRule["RDS SG 인바운드 규칙 추가"] AddSGRule --> CheckSG CheckSG -- "있음" --> CheckIAM{"Lambda 역할에 ENI 생성 권한?"} CheckIAM -- "없음" --> AddIAM["AWSLambdaVPCAccessExecutionRole 연결"] AddIAM --> CheckIAM CheckIAM -- "있음" --> CheckRoute{"Subnet 라우팅 + NACL 정상?"} CheckRoute -- "문제 있음" --> FixRoute["라우팅 테이블 / NACL 수정"] FixRoute --> CheckRoute CheckRoute -- "정상" --> CheckRDS{"RDS 상태 available?"} CheckRDS -- "아님" --> FixRDS["RDS 인스턴스 상태 확인"] CheckRDS -- "available" --> Success(["연결 성공"])
  1. Lambda VPC 설정 여부를 먼저 확인한다. 없으면 즉시 추가.
  2. Lambda SG → RDS SG 인바운드 규칙 허용 여부를 확인한다.
  3. Lambda 실행 역할에 VPC ENI 생성 권한이 있는지 확인한다.
  4. Lambda Subnet 라우팅 테이블과 NACL을 확인한다.
  5. RDS 인스턴스 상태와 엔드포인트 주소를 최종 검증한다.

마무리 및 다음 단계 — Lambda에서 Private RDS 연결 완성

Lambda에서 Private RDS에 연결하려면 반드시 Lambda에 VPC 설정(Subnet, Security Group)을 추가해야 한다. 이것이 전제 조건이고, 그 위에 Security Group 규칙, IAM 권한, 라우팅이 모두 맞아야 한다.

연결 구성 후 운영 환경에서는 다음을 추가로 고려한다:

  • RDS Proxy: Lambda의 짧은 실행 주기로 인한 DB 연결 폭증을 완화한다. Lambda와 RDS 사이에 RDS Proxy를 두면 연결 풀링을 Proxy가 관리한다.
  • VPC 엔드포인트: Lambda에서 S3, Secrets Manager 등 AWS 서비스에 접근할 때 NAT Gateway 없이 VPC 내부 경로를 사용할 수 있다.
  • Secrets Manager: DB 자격증명을 환경 변수에 하드코딩하지 말고 Secrets Manager에서 런타임에 가져오는 방식을 사용한다.

관련 AWS 공식 문서: Lambda VPC 설정 가이드, RDS Proxy 문서

핵심 용어 정리

용어설명
Hyperplane ENILambda VPC 설정 시 AWS가 고객 VPC에 생성하는 Elastic Network Interface. Lambda 실행 환경과 VPC를 연결하는 네트워크 브릿지 역할.
Security Group (SG)인스턴스/ENI 레벨의 가상 방화벽. 상태 추적(stateful) 방식으로 동작.
Network ACL (NACL)Subnet 레벨 트래픽 필터. 상태 비추적(stateless) 방식으로 인바운드/아웃바운드를 각각 설정해야 함.
RDS ProxyLambda와 RDS 사이의 완전관리형 DB 프록시. 연결 풀링을 통해 DB 연결 수를 제어.
NAT GatewayPrivate Subnet의 리소스가 인터넷에 아웃바운드 접근할 수 있도록 하는 관리형 서비스. VPC 배치 Lambda의 외부 통신에 필요.

Related Posts

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...
자세한 내용 보기

IAM User vs IAM Role 차이점 완전 정리 — EC2에서 S3 접근 시 무엇을 써야 하는가

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...
자세한 내용 보기