네트워킹

네트워킹

AWS Lambda MicroVM에 대한 네트워크 접근은 런타임 시 Network Connector 리소스를 MicroVM과 연결해 구성해요. 네트워크 커넥터는 run-microvm을 호출할 때 지정되며, MicroVM이 실행되는 동안에는 변경할 수 없어요.

출처: AWS Lambda 개발자 안내서

본문

개요

각 MicroVM은 독립적인 인바운드(inbound) 및 아웃바운드(outbound) 네트워크 구성을 가질 수 있어요:

• 인바운드 네트워크 커넥터는 인바운드 연결을 가능하게 해요. 클라이언트는 서비스 관리형 HTTPS 엔드포인트에 연결하고, Lambda는 MicroVM 내부에서 구성한 포트로 트래픽을 전달해요. 인바운드 커넥터는 AWS 관리형이며, MicroVM 실행 시 ARN으로 참조해요.
• 아웃바운드 네트워크 커넥터는 아웃바운드 트래픽을 가능하게 해요. 기본적으로 MicroVM은 공개 인터넷에 접근할 수 있어요. 대신 고객 관리형 VPC 이그레스 커넥터를 만들어 아웃바운드 트래픽을 VPC를 통해 라우팅할 수 있어요.

하나의 커넥터는 많은 MicroVM에서 재사용할 수 있어요 — 이는 의도된 사용 패턴이에요.

인바운드 연결

각 Lambda MicroVM은 run-microvm을 호출할 때 할당되는 고유한 HTTPS 엔드포인트 URL에서 접근할 수 있어요. 클라이언트는 HTTPS를 통해 이 엔드포인트로 요청을 보내요. Lambda는 각 요청을 MicroVM 내부의 포트로 라우팅하며, 거기서 애플리케이션이 요청을 받아요.

기본적으로 엔드포인트에서 받은 요청은 MicroVM 내부의 8080 포트로 라우팅돼요. 다른 포트로 라우팅하려면 포트 라우팅을 참고하세요.

인바운드 엔드포인트에서 지원하는 프로토콜은 다음과 같아요:

• HTTP/1.1
• HTTP/2
• WebSockets
• gRPC
• Server-Sent Events (SSE)

참고
클라이언트와 MicroVM 엔드포인트 사이의 트래픽은 항상 TLS로 암호화돼요. 애플리케이션은 내부적으로 HTTP 또는 HTTPS 중 어느 것이든 요청을 서빙할 수 있어요.

포트 라우팅

Lambda는 다음 우선순위 순서로 MicroVM 내부의 대상 포트를 선택해요:

1. X-aws-proxy-port 헤더 – 표준 HTTP 요청의 경우 이 헤더에 대상 포트 번호를 포함하세요.

2. WebSocket 하위 프로토콜 – WebSocket 클라이언트가 커스텀 헤더를 설정할 수 없다면, lambda-microvms.port.{{N}}이라는 하위 프로토콜로 대상 포트를 지정하세요. 여기서 {{N}}은 포트 번호예요. WebSocket 연결을 열 때 하위 프로토콜을 제공해요. 예시는 프로토콜을 참고하세요.

3. 기본값 (8080) – 둘 다 지정하지 않으면 요청은 8080 포트로 라우팅돼요.

중요
대상 포트는 인증 토큰에 정의된 allowedPorts 안에 있어야 해요. 허용되지 않은 포트로의 요청은 403 Forbidden 응답을 받아요.

인증

MicroVM 엔드포인트에 대한 모든 요청은 X-aws-proxy-auth 헤더에 유효한 인증 토큰이 필요해요. create-microvm-auth-token을 사용해 토큰을 생성해요. 각 토큰은 암호화된 JWE(JSON Web Encryption) 문자열로 다음 범위로 한정돼요:

• 특정 MicroVM (ID로 식별).
• 허용된 포트 집합 (단일 포트, 범위, 또는 전체 포트).
• 만료 시간 (토큰 생성 시 구성).

다음 예제는 토큰을 생성하고 이를 사용해 인증된 요청을 보내요:

aws lambda-microvms create-microvm-auth-token \
  --microvm-identifier {{microvm-id}} \
  --expiration-in-minutes 30 \
  --allowed-ports '[{"port":8080}]'

curl 'https://{{microvm-endpoint}}' \
  -H 'X-aws-proxy-auth: {{TOKEN}}' \
  -H 'X-aws-proxy-port: 8080'

토큰 생성과 MicroVM 연결에 대한 전체 워크스루는 WebSocket 연결을 포함해 MicroVM에 연결을 참고하세요.

오류 응답

애플리케이션에 요청을 처리하거나 전달할 수 없을 때 MicroVM 엔드포인트는 다음 HTTP 상태 코드를 반환해요. 이 응답은 엔드포인트에서 오는 것이지 애플리케이션에서 오는 것이 아니에요.

코드	상태	원인과 해결 방법
400	Bad Request	잘못된 요청, 또는 유효하지 않은 포트 헤더나 WebSocket 하위 프로토콜. 형식을 확인하세요.
403	Forbidden	토큰이 없거나, 만료되었거나, 유효하지 않음; 또는 요청한 포트가 토큰의 allowedPorts에 없음. 새 토큰을 생성하거나 허용된 포트를 사용하세요.
429	Too Many Requests	요율 제한 초과(계정 수준 또는 MicroVM별). 지수 백오프로 재시도하세요.
500	Internal Server Error	내부 오류 발생. 요청을 재시도하세요.
502	Bad Gateway	애플리케이션이 응답하지 않거나, 자동 재개가 최대 재시도 횟수 내에 성공하지 못함. 자동 재개를 참고하세요.

요청 헤더

X-aws-proxy-* 헤더 네임스페이스는 인증 토큰(X-aws-proxy-auth)과 대상 포트(X-aws-proxy-port) 같은 요청 메타데이터를 위해 Lambda가 예약해요. Lambda는 요청을 애플리케이션으로 전달하기 전에 X-aws-proxy-* 헤더를 제거해요.

요청/응답 대역폭

각 Lambda MicroVM은 크기에 따라 선형적으로 확장되는 요청/응답 대역폭을 가져요. 이 대역폭은 인바운드 요청과 아웃바운드 응답 모두 MicroVM 엔드포인트를 통과하는 모든 트래픽에 적용돼요.

MicroVM 크기 (기준)	최대 대역폭
0.5 GB, 0.25 vCPU	1 MB/s (8 Mbps)
1 GB, 0.5 vCPU	2 MB/s (16 Mbps)
2 GB, 1 vCPU	4 MB/s (32 Mbps)
4 GB, 2 vCPU	8 MB/s (64 Mbps)
8 GB, 4 vCPU	16 MB/s (128 Mbps)

네트워크 포화로 요청 지연이 증가한다면, 요청 동시성이나 페이로드 크기를 줄이거나 사용 가능한 대역폭을 늘리기 위해 더 큰 MicroVM 크기를 선택하세요.

HTTP/2 지원

Lambda MicroVM은 인바운드 엔드포인트에서 HTTP/2를 지원해요. Lambda는 TLS 핸드셰이크 중 ALPN(Application-Layer Protocol Negotiation)으로 프로토콜을 협상하며, HTTP/2를 선호하고 HTTP/1.1로 폴백해요. HTTP/2를 지원하는 클라이언트는 자동으로 이를 사용해요.

엔드포인트와 MicroVM 내부 애플리케이션 사이에서 HTTP/2를 사용하려면:

• 애플리케이션이 TLS를 제공 – Lambda는 ALPN으로 애플리케이션과 HTTP/2를 협상하며, HTTP/2가 지원되지 않으면 HTTP/1.1로 폴백해요.
• 애플리케이션이 평문 HTTP를 제공 – 애플리케이션으로의 연결에서 HTTP/2를 사용하려면 요청에 X-aws-proxy-force-h2: true 헤더를 포함하세요.

아웃바운드 연결

기본적으로 Lambda MicroVM은 이그레스 경로에서 공개 인터넷 접근이 가능해요. RDS, ElastiCache, 내부 API, Direct Connect나 VPN을 통한 온프레미스 시스템 같은 프라이빗 VPC의 리소스와 MicroVM을 연결하려면 VPC 구성으로 Lambda Network Connector를 만드세요.

VPC 이그레스를 사용할 때 아웃바운드 트래픽은 VPC의 트래픽을 규율하는 보안 그룹 규칙과 네트워크 ACL의 적용을 받아요.

이그레스 네트워크 커넥터 사용

이그레스 네트워크 커넥터는 MicroVM의 아웃바운드 트래픽을 VPC를 통해 라우팅해요. 커넥터를 한 번 만든 다음, run-microvm 명령으로 MicroVM을 시작할 때 ARN으로 참조해요.

사전 요구 사항

네트워크 커넥터를 만들기 전에 Lambda가 VPC에서 탄력적 네트워크 인터페이스(ENI)를 만들 수 있게 하는 IAM 역할이 필요해요. 역할은 다음 권한이 필요해요:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateENI",
      "Effect": "Allow",
      "Action": "ec2:CreateNetworkInterface",
      "Resource": [
        "arn:aws:ec2:*:*:network-interface/*",
        "arn:aws:ec2:*:*:subnet/*",
        "arn:aws:ec2:*:*:security-group/*"
      ]
    },
    {
      "Sid": "TagENI",
      "Effect": "Allow",
      "Action": "ec2:CreateTags",
      "Resource": "arn:aws:ec2:*:*:network-interface/*",
      "Condition": {
        "StringEquals": {
          "ec2:ManagedResourceOperator": "network-connectors.lambda.amazonaws.com"
        }
      }
    }
  ]
}

네트워크 커넥터 만들기

VPC 서브넷, 보안 그룹, 네트워크 프로토콜(IPv4 또는 DualStack)을 지정해 커넥터를 만들어요:

aws lambda-core create-network-connector \
  --name my-connector \
  --configuration '{
    "VpcEgressConfiguration": {
      "SubnetIds": ["{{subnet-xxx}}"],
      "SecurityGroupIds": ["{{sg-xxx}}"],
      "NetworkProtocol": "IPv4",
      "AssociatedComputeResourceTypes": ["MicroVm"]
    }
  }' \
  --operator-role arn:aws:iam::{{123456789012}}:role/NetworkConnectorOperatorRole

네트워크 커넥터 상태

run-microvm에서 참조하려면 커넥터가 ACTIVE 상태여야 해요.

상태	설명
PENDING	커넥터 생성 중 (기본 ENI가 프로비저닝되는 중).
ACTIVE	커넥터 사용 준비 완료.
INACTIVE	커넥터가 일시적으로 비활성 상태.
FAILED	프로비저닝 또는 업데이트 실패. StateReason 확인.
DELETING	커넥터 삭제 중; ENI 정리 중.
DELETE_FAILED	삭제 실패.

네트워크 커넥터로 MicroVM 실행

MicroVM을 실행할 때 커넥터 ARN을 참조해요:

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:us-east-1:{{123456789012}}:microvm-image:my-microvm-image \
  --egress-network-connectors {{connector-arn}} \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800,"autoResumeEnabled":false}'

참고
커넥터를 업데이트하거나 삭제하기 전에 이를 사용하는 모든 MicroVM이 종료되었는지 확인하세요. 사용 중인 커넥터를 수정하면 실행 중인 MicroVM의 네트워크 연결 문제가 발생할 수 있어요.

인터페이스 VPC 엔드포인트(AWS PrivateLink)로 Lambda MicroVM 사용

AWS PrivateLink를 사용해 공개 인터넷을 통과하지 않고 AWS 네트워크를 통해 VPC 리소스와 Lambda MicroVM 사이에서 프라이빗 연결을 할 수 있어요. MicroVM은 원하는 트래픽 대상에 따라 두 가지 VPC 엔드포인트를 지원해요:

• MicroVM 관리 API (이미지 생성, 실행, 일시 중단, 종료) – 기존 Lambda VPC 엔드포인트(com.amazonaws.{{region}}.lambda)를 사용해요.
• MicroVM 연결 (실행 중인 애플리케이션으로의 HTTPS 트래픽) – 별도 엔드포인트(com.amazonaws.{{region}}.lambda-microvm)를 사용해요.

MicroVM 관리 API용 VPC 엔드포인트

Lambda MicroVM은 Lambda와 동일한 VPC 엔드포인트 서비스(com.amazonaws.{{region}}.lambda)를 공유해요. 전체 지침은 Lambda용 인터페이스 엔드포인트 생성을 참고하세요.

MicroVM 관리 API용 엔드포인트 정책

인터페이스 엔드포인트를 사용할 수 있는 사용자와 그들이 수행할 수 있는 Lambda MicroVM API 작업을 제어하려면 엔드포인트 정책을 연결하세요. 정책은 작업을 수행할 수 있는 보안 주체(principal), 수행할 수 있는 작업, 작업 대상 리소스를 지정해요. Lambda MicroVM 작업은 lambda: IAM 작업 접두사를 사용해요.

자세한 내용은 Amazon VPC 사용자 안내서의 VPC 엔드포인트로 서비스 접근 제어를 참고하세요.

다음 예제 정책은 사용자 MyUser가 엔드포인트를 통해 MicroVM 이미지를 나열하고 가져올 수 있게 해요:

{
  "Statement": [
    {
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:user/MyUser"
      },
      "Effect": "Allow",
      "Action": [
        "lambda:ListMicrovmImages",
        "lambda:GetMicrovmImage"
      ],
      "Resource": "*"
    }
  ]
}

MicroVM 연결용 VPC 엔드포인트

실행 중인 MicroVM으로의 HTTPS 트래픽을 프라이빗으로 유지하려면 com.amazonaws.{{region}}.lambda-microvm 서비스에 대한 인터페이스 엔드포인트를 만드세요. 이 엔드포인트는 MicroVM 엔드포인트 URL(예: abc123def456.lambda-microvm.us-east-1.on.aws)로의 연결을 처리해요.

인터페이스 엔드포인트 속성에 대해 자세히 알아보려면 Amazon VPC 문서의 인터페이스 엔드포인트 안내서를 검토하세요.

엔드포인트 생성

MicroVM 연결용 인터페이스 엔드포인트를 만들려면 (콘솔)

1. Amazon VPC 콘솔의 Endpoints 페이지를 엽니다.

2. Create endpoint를 선택합니다.

3. Service category에서 AWS services가 선택되었는지 확인합니다.

4. Service Name에서 com.amazonaws.{{region}}.lambda-microvm을 선택합니다. Type이 Interface인지 확인합니다.

5. VPC와 서브넷을 선택합니다.

6. 인터페이스 엔드포인트에 대해 프라이빗 DNS를 사용하려면 Enable DNS name 확인란을 선택합니다(권장). 이렇게 하면 공개 MicroVM 엔드포인트 호스트 이름을 사용하는 요청이 클라이언트 측 변경 없이 자동으로 인터페이스 엔드포인트로 확인됩니다.

7. Security group에서 하나 이상의 보안 그룹을 선택합니다. 보안 그룹은 엔드포인트 네트워크 인터페이스로의 443 포트 아웃바운드 TCP 트래픽을 허용해야 합니다.

8. Create endpoint를 선택합니다.

프라이빗 DNS 옵션을 사용하려면 VPC의 enableDnsHostnames 및 enableDnsSupport 속성을 설정해야 합니다. 자세한 내용은 Amazon VPC 사용자 안내서의 VPC의 DNS 지원 보기 및 업데이트를 참고하세요.

MicroVM 연결용 인터페이스 엔드포인트를 만들려면 (AWS CLI)

aws ec2 create-vpc-endpoint \
  --vpc-id {{vpc-ec43eb89}} \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.{{us-east-1}}.lambda-microvm \
  --subnet-id {{subnet-abababab}} \
  --security-group-id {{sg-1a2b3c4d}} \
  --private-dns-enabled

엔드포인트를 사용할 수 있고 프라이빗 DNS가 적용되는지 확인하려면:

aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids {{vpce-1a2b3c4d5e6f7g8h9}} \
  --query 'VpcEndpoints[0].{State:State,PrivateDns:PrivateDnsEnabled,Dns:DnsEntries[*].DnsName}'

프라이빗 DNS 동작

프라이빗 DNS가 활성화된 경우 – 엔드포인트는 VPC 내부에서 *.lambda-microvm.{{region}}.on.aws에 대한 DNS 해석을 관리해요. 기존 MicroVM 엔드포인트 호스트 이름(예: abc123def456.lambda-microvm.us-east-1.on.aws)이 엔드포인트 네트워크 인터페이스의 프라이빗 IP 주소로 확인됩니다. 클라이언트 변경이 필요 없어요.

프라이빗 DNS가 비활성화된 경우 – Amazon VPC는 {{vpce-id-hash}}.lambda-microvm.{{region}}.vpce.amazonaws.com 형태의 엔드포인트별 DNS 이름을 생성해요. 이 엔드포인트를 통해 트래픽을 라우팅하면서도 올바른 MicroVM에 도달하려면 두 곳에서 원래 MicroVM 호스트 이름을 유지해야 해요:

• TLS Server Name Indication (SNI) – TLS 핸드셰이크는 이 값을 사용해 연결 대상 MicroVM을 식별해요.
• HTTP Host 헤더 – 프록시는 이 값을 사용해 요청을 올바른 MicroVM으로 라우팅해요.

어느 쪽 값을 MicroVM 호스트 이름 대신 VPC 엔드포인트 호스트 이름으로 설정하면 연결을 올바른 MicroVM으로 라우팅할 수 없어요.

예제: 엔드포인트별 DNS 이름으로 연결

다음 예제는 curl의 --connect-to 플래그를 사용해 TCP 연결을 VPC 엔드포인트로 리디렉션하면서 MicroVM 호스트 이름을 URL, SNI, Host 헤더에 유지해요:

ENDPOINT_HOST=abc123def456.lambda-microvm.us-east-1.on.aws
VPCE_HOST=vpce-0a1b2c3d4e5f67890-a1b2c3d4.lambda-microvm.us-east-1.vpce.amazonaws.com

curl --connect-to "$ENDPOINT_HOST:443:$VPCE_HOST:443" \
  -H "x-aws-proxy-auth: $MICROVM_AUTH_TOKEN" \
  -H "x-aws-proxy-port: 8080" \
  "https://$ENDPOINT_HOST/"

--connect-to 플래그는 curl에 VPC 엔드포인트 주소로 TCP 연결을 열도록 지시하면서, URL, TLS SNI, Host 헤더는 MicroVM 호스트 이름으로 유지돼요.

자세한 내용은 Amazon VPC 사용자 안내서의 인터페이스 엔드포인트를 통한 서비스 접근을 참고하세요.

MicroVM 연결용 엔드포인트 정책

lambda-microvm VPC 엔드포인트를 통해 도달할 수 있는 MicroVM을 제어하도록 엔드포인트 정책을 연결할 수 있어요. lambda-microvm 서비스의 엔드포인트 정책을 사용하면 연결을 특정 계정이나 조직으로 범위를 한정할 수 있어요. 기본적으로 엔드포인트는 모든 AWS 계정의 MicroVM에 대한 연결을 허용해요. (참고: 연결을 설정하는 클라이언트는 접근 권한을 부여받기 위해 여전히 유효한 MicroVM 인증 토큰을 보유해야 해요.)

기본적으로 VPC 엔드포인트는 모든 트래픽을 허용하는 전체 접근 정책을 가져요. 기본 정책을 커스텀 정책으로 교체하면 Lambda MicroVM은 엔드포인트를 통한 모든 연결에서 lambda:ConnectMicrovm 작업에 대해 그 정책을 평가해요. 정책이 MicroVM 연결을 허용하지 않으면 연결은 HTTP 403 Forbidden 응답으로 거부돼요. lambda:ConnectMicrovm을 부여하지 않는 정책은 엔드포인트를 통한 모든 연결을 거부해요.

참고
lambda:ConnectMicrovm 작업은 인터페이스 엔드포인트를 통해 MicroVM 엔드포인트에 대한 연결을 승인해요. 이는 Lambda API 작업이 아니며 IAM 자격 기반 또는 리소스 기반 정책에는 사용할 수 없어요 — VPC 엔드포인트 정책에서만 유효해요.

보안 주체와 리소스

MicroVM 엔드포인트에 대한 연결은 AWS Signature Version 4가 아니라 MicroVM 인증 토큰으로 인증돼요. 그렇기 때문에 연결과 연결된 IAM 보안 주체가 없어요. 대신 Lambda MicroVM은 익명 보안 주체로 엔드포인트 정책을 평가해요. 이는 다음을 의미해요:

• Principal은 "*"여야 해요. 특정 보안 주체를 이름으로 지정하는 정책은 아무것도 일치하지 않아 모든 연결을 거부해요.
• 요청자 신원에 의존하는 조건 키(예: aws:PrincipalArn, aws:PrincipalOrgID, aws:userid)는 채워지지 않아 일치하지 않아요.
• Resource도 "*"여야 해요. Lambda MicroVM은 엔드포인트 정책 평가를 개별 MicroVM 리소스 ARN으로 범위를 한정하지 않아요. 엔드포인트가 도달할 수 있는 MicroVM을 제한하려면 Resource 요소가 아니라 aws:ResourceAccount 조건 키를 사용하세요.

지원되는 조건 키

조건 키	설명
aws:ResourceAccount	연결 대상 MicroVM을 소유한 AWS 계정.
aws:ResourceOrgID	MicroVM을 소유한 계정의 AWS Organizations 조직 ID.
aws:SourceVpce	연결이 통과한 인터페이스 엔드포인트의 ID.
aws:SourceVpc	연결이 시작된 VPC의 ID.
aws:VpcSourceIp	연결을 만든 클라이언트의 프라이빗 IP 주소.

예제: 자신의 계정의 MicroVM에만 연결 허용

다음 엔드포인트 정책은 계정 111122223333이 소유한 MicroVM에만 엔드포인트를 통한 연결을 허용해요. 다른 계정이 소유한 MicroVM으로의 연결은 거부돼요.

{
  "Statement": [
    {
      "Principal": "*",
      "Effect": "Allow",
      "Action": "lambda:ConnectMicrovm",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceAccount": "111122223333"
        }
      }
    }
  ]
}

더 알아보기 (Learn more)

• MicroVM에 대한 인바운드·아웃바운드 네트워크 구성을 구성하고, 포트 라우팅·인증·오류 응답·대역폭·HTTP/2 지원을 이해해 보세요.
• 이그레스 네트워크 커넥터를 만들어 아웃바운드 트래픽을 VPC를 통해 라우팅하는 방법을 익혀 보세요.
• AWS PrivateLink 인터페이스 VPC 엔드포인트로 MicroVM 관리 API와 MicroVM 연결을 프라이빗하게 유지하는 방법을 배워 보세요.