Lambda가 VPC에 연결될 때 Hyperplane ENI가 하는 역할

배경

Lambda에 VPC 설정을 추가하면 Lambda가 해당 VPC 안에서 직접 실행된다고 생각하기 쉽다.

실제로 Lambda Execution Environment는 AWS가 관리하는 Lambda Service VPC에서 동작한다. 사용자가 선택한 VPC와 연결되는 구간에는 Hyperplane ENI가 사용된다.

이 구조를 이해할 때는 아래 2가지를 구분해야 한다.

• Lambda가 사용자 VPC에 들어오는 경로
• 사용자 VPC에서 실제 목적지까지 가는 경로

Hyperplane ENI는 첫 번째 경로를 해결한다. 두 번째 경로는 Subnet의 Route Table, Security Group, NAT Gateway, VPC Endpoint 같은 VPC 설정에 따라 결정된다.

Hyperplane ENI란

Hyperplane ENI는 Lambda 실행 환경과 사용자 VPC 사이를 연결하는 AWS 관리형 Network Interface다.

Lambda Function에 VPC 설정을 추가하면 Lambda Service가 선택한 Subnet과 Security Group 조합에 맞는 Hyperplane ENI를 생성하거나 기존 ENI를 재사용한다.

Lambda Execution Environment
  -> AWS Lambda Service Network
  -> Hyperplane ENI
  -> 사용자 VPC
  -> 실제 목적지

Hyperplane ENI는 Lambda가 사용자 VPC의 Private IP와 Security Group을 이용해 통신할 수 있는 출발 지점이 된다.

Lambda를 호출하는 경로는 API Gateway, Event Source, Lambda Invoke API 같은 Lambda Service 영역에서 처리된다. Hyperplane ENI는 외부에서 Lambda를 직접 호출하기 위한 Inbound Interface가 아니다.

일반 ENI와 다른 점

Lambda Execution Environment마다 Hyperplane ENI가 하나씩 생성되는 구조는 아니다. 같은 Account에서 같은 Subnet과 Security Group 조합을 사용하는 Function은 가능한 경우 Hyperplane ENI를 공유한다.

생성과 재사용

Lambda가 새로운 Subnet과 Security Group 조합을 처음 사용하면 Hyperplane ENI를 생성한다.

ENI가 준비되는 동안 신규 Function은 Pending 상태에 머물고, 준비가 끝나면 Active 상태로 변경된다. 기존에 사용 중인 조합의 ENI가 있다면 재사용할 수 있다.

Hyperplane ENI 하나는 최대 65,000개의 Connection과 Port를 지원한다. 연결량이 이 범위를 넘으면 Lambda가 Traffic과 Concurrency에 맞춰 ENI 수를 늘린다.

Lambda Function이 14일 동안 사용되지 않으면 Lambda가 사용하지 않는 Hyperplane ENI를 회수하고 Function을 Inactive 상태로 변경할 수 있다. 이후 첫 번째 호출은 실패할 수 있고 ENI가 다시 준비되는 동안 Function은 Pending 상태가 된다.

따라서 특정 Hyperplane ENI나 Private IP가 계속 유지된다는 전제로 구성하면 안된다.

Hyperplane ENI가 해결하는 것

Hyperplane ENI가 정상적으로 동작하면 Lambda는 사용자 VPC 안에서 아래와 같은 대상에 접근할 수 있다.

• RDS, ElastiCache처럼 VPC 내부에 있는 Resource
• Internal ALB나 Private IP로 노출된 Service
• EFS Mount Target
• EKS Kubernetes API Server의 Cluster Private Endpoint
• VPC Peering, Transit Gateway, VPN 등을 통해 Route가 연결된 Network

다만 ENI가 생성됐다는 사실만으로 통신이 보장되는 것은 아니다. 목적지까지 Route가 있어야 하고 양쪽 Security Group과 NACL도 통신을 허용해야 한다.

Hyperplane ENI가 해결하지 않는 것

외부 인터넷 경로

Lambda를 Public Subnet에 연결해도 Hyperplane ENI에 Public IP가 할당되는 것은 아니다. Route Table에 Internet Gateway가 있다는 이유만으로 Lambda가 인터넷에 직접 접근할 수 없다.

IPv4 인터넷 접근이 필요하다면 일반적으로 Lambda를 Private Subnet에 연결하고 Public Subnet의 NAT Gateway로 Routing한다.

Lambda
  -> Hyperplane ENI
  -> Private Subnet Route Table
  -> NAT Gateway
  -> Internet 또는 Public AWS Service Endpoint

AWS Service Endpoint의 사설 경로

Lambda가 VPC에 연결됐다고 해서 AWS Service API가 자동으로 Private 경로로 변경되지는 않는다.

eks.<region>.amazonaws.com, secretsmanager.<region>.amazonaws.com, sts.<region>.amazonaws.com 같은 Regional Service Endpoint를 외부망 없이 호출하려면 해당 Service가 지원하는 Interface VPC Endpoint가 필요하다.

Lambda
  -> Hyperplane ENI
  -> Interface VPC Endpoint의 Private IP
  -> AWS Service API

S3와 DynamoDB는 일반적인 VPC 내부 접근에서 Gateway VPC Endpoint를 사용할 수 있다. 이 경우 Route Table에 AWS가 관리하는 Prefix List 경로가 추가된다.

Lambda
  -> Hyperplane ENI
  -> Route Table의 S3/DynamoDB Prefix List
  -> Gateway VPC Endpoint
  -> S3 또는 DynamoDB

IAM 권한

Network 경로와 IAM 권한은 별개다.

Hyperplane ENI와 VPC Endpoint가 정상이어도 Lambda Execution Role에 목적지 API를 호출할 권한이 없으면 AccessDenied가 발생한다. 반대로 IAM 권한이 있어도 Route와 Endpoint가 없으면 Timeout이나 Connection Error가 발생한다.

Lambda Service가 Hyperplane ENI를 생성하고 관리하려면 Function의 Execution Role에 EC2 Network Interface 관련 권한이 필요하다. 일반적으로 AWSLambdaVPCAccessExecutionRole Managed Policy를 사용한다. 이 권한은 VPC 연결을 만들기 위한 권한이며 RDS, EKS, S3 같은 목적지 Resource에 접근하는 권한과는 다르다.

Security Group과 NACL

Lambda에 지정한 Security Group은 Hyperplane ENI의 Network Traffic에 적용된다.

예를 들어 Lambda가 RDS에 접근한다면 아래 조건이 필요하다.

• Lambda Security Group의 Outbound가 RDS Port를 허용
• RDS Security Group의 Inbound Source가 Lambda Security Group을 허용
• Subnet NACL이 요청과 응답 Traffic을 모두 허용

NACL을 좁게 운영한다면 Lambda가 사용하는 1024-65535 범위의 Ephemeral Port도 고려해야 한다. Security Group은 Stateful이지만 NACL은 Stateless이기 때문에 Return Traffic 규칙도 필요하다.

목적지별로 필요한 경로

EKS Interface VPC Endpoint는 EKS 관리 API용이다. Kubernetes API Server에 접근하는 경로는 EKS Cluster Endpoint 설정에서 별도로 결정된다.

문제 발생 시 확인 순서

Lambda의 VPC 통신이 실패한다면 아래 순서로 확인하는 것이 좋다.

1. Lambda에 설정한 VPC, Subnet, Security Group이 맞는지 확인한다.
2. Function State가 Active인지, Hyperplane ENI 생성 또는 재생성 중인지 확인한다.
3. 선택한 Subnet에 사용할 수 있는 IP가 남아 있는지 확인한다.
4. 목적지가 VPC 내부 Resource인지 AWS Regional Service Endpoint인지 구분한다.
5. Subnet Route Table에 목적지로 가는 Local, NAT, Peering, Transit Gateway, VPC Endpoint 경로가 있는지 확인한다.
6. Lambda Security Group의 Outbound와 목적지 Security Group의 Inbound를 확인한다.
7. NACL을 사용한다면 요청 Port와 Ephemeral Port의 양방향 규칙을 확인한다.
8. Interface VPC Endpoint를 사용한다면 Private DNS, Endpoint Subnet, Endpoint Security Group을 확인한다.
9. Network가 정상이라면 Lambda Execution Role, Endpoint Policy, Resource Policy를 확인한다.
10. Timeout이 발생한다면 VPC Flow Logs와 Lambda Log를 함께 확인한다.

자주 헷갈리는 부분

• 같은 AWS Account에 있는 Service라고 해서 Private Route가 자동으로 생기지는 않는다.
• Hyperplane ENI가 정상이라는 것은 Lambda가 사용자 VPC에 연결됐다는 의미다.
• Hyperplane ENI가 정상이어도 목적지까지의 Route가 없으면 통신할 수 없다.
• Lambda를 Public Subnet에 연결하는 것만으로 Public Internet Access가 생기지 않는다.
• VPC Endpoint는 Network 경로를 제공하고 IAM은 호출 권한을 제공한다.
• EKS 관리 API Endpoint와 Kubernetes API Server Endpoint는 서로 다른 목적지다.

정리

Hyperplane ENI는 Lambda를 사용자 VPC에 연결하는 출발 지점이다.

Hyperplane ENI
  = Lambda와 사용자 VPC의 연결
  != 인터넷 경로
  != 모든 AWS Service의 Private 경로
  != IAM 권한

Lambda의 VPC 통신은 Hyperplane ENI만 확인해서는 안된다. ENI 이후의 Route Table, NAT Gateway, VPC Endpoint, Security Group, NACL, DNS와 IAM 권한을 목적지에 맞게 같이 확인해야 한다.

관련 사례

• 외부망이 막힌 환경에서 Lambda가 EKS에 접근할 때 VPC Endpoint가 필요했던 이유

참고

• Giving Lambda functions access to resources in an Amazon VPC
• Enable internet access for VPC-connected Lambda functions
• Troubleshoot networking issues in Lambda
• Gateway endpoints
• Access Amazon EKS using AWS PrivateLink