# Lambda 런타임 Lambda는 *런타임*을 사용하여 여러 언어를 지원합니다. 런타임은 Lambda와 함수 간에 호출 이벤트, 컨텍스트 정보 및 응답을 릴레이하는 언어별 환경을 제공합니다. Lambda에서 제공하는 런타임을 사용하거나 나만의 런타임을 빌드할 수 있습니다. Lambda는 선택하는 런타임의 구애를 받지 않습니다. 간단한 함수의 경우 Python 및 Node.js와 같이 해석된 언어가 가장 빠른 성능을 제공합니다. 계산이 더 복잡한 함수의 경우 Java와 같은 컴파일된 언어는 초기화 속도가 느리지만 Lambda 핸들러에서 빠르게 실행됩니다. 런타임의 선택도 개발자 선호도 및 언어 친숙성의 영향도 받습니다. 각 주요 프로그래밍 언어 릴리스에는 `nodejs24.x` 또는 `python3.14`와 같은 고유한 런타임 식별자**를 가진 별도의 런타임이 있습니다. 새 메이저 언어 버전을 사용하도록 함수를 구성하려면 런타임 식별자를 변경해야 합니다. AWS Lambda는 메이저 버전 간에 이전 버전과의 호환성을 보장할 수 없으므로 이 작업은 고객이 수행해야 합니다. [컨테이너 이미지로 정의된 함수](images-create.md)의 경우 컨테이너 이미지를 생성할 때 런타임 및 Linux 배포판을 선택합니다. 런타임을 변경하려면 새 컨테이너 이미지를 생성합니다. 배포 패키지에 .zip 파일 아카이브를 사용하는 경우 함수를 생성할 때 런타임을 선택합니다. 런타임을 변경하려면 [함수의 구성을 업데이트](configuration-function-zip.md)할 수 있습니다. 런타임은 Amazon Linux 배포판 중 하나와 페어링됩니다. 기반 실행 환경은 함수 코드에서 액세스할 수 있는 추가 라이브러리와 [환경 변수](configuration-envvars.md)를 제공합니다. Lambda는 [실행 환경](lambda-runtime-environment.md)에서 함수를 간접 호출합니다. 실행 환경은 함수를 실행하는 데 필요한 리소스를 관리하는 안전하고 격리된 런타임 환경을 제공합니다. Lambda는 사용 가능한 경우 이전 호출에서 실행 환경을 다시 사용하거나 새 실행 환경을 만들 수 있습니다. Lambda에서 [Go](lambda-golang.md) 또는 [Rust](lambda-rust.md)와 같은 다른 언어를 사용하려면 [OS 전용 런타임](runtimes-provided.md)을 사용합니다. Lambda 실행 환경은 호출 이벤트를 받고 응답을 보내기 위한 [런타임 인터페이스](runtimes-api.md)를 제공합니다. [사용자 지정 런타임](runtimes-custom.md)을 함수 코드와 함께 배포하거나 하나의 [계층](chapter-layers.md)에서 구현하여 다른 언어를 배포할 수 있습니다. ## 지원되는 런타임 다음 테이블에는 지원되는 Lambda 런타임 및 예상되는 사용 중단 날짜가 나와 있습니다. 런타임이 지원 중단된 후에도 제한된 기간에 함수를 생성하고 업데이트할 수 있습니다. 자세한 내용은 [지원 중단 이후 런타임 사용](#runtime-deprecation-levels) 섹션을 참조하세요. 이 테이블에서는 [런타임 사용 중단 정책](#runtime-support-policy)에 따라 현재 예상되는 런타임 지원 중단 날짜를 제공합니다. 이 날짜는 계획 수립을 위해 제공되며 변경될 수 있습니다. **중요** Amazon Linux 2는 2026년 6월 30일에 수명 종료 예정입니다. Java 8(AL2), Java 11, Java 17, Python 3.10, Python 3.11, provided.al2용 Lambda 런타임 및 컨테이너 기본 이미지는 아래 표에 표시된 사용 중단 날짜까지 언어 런타임 패치 외에도 [심각 및 선택적 중요](https://alas.aws.amazon.com/faqs.html) Amazon Linux 2 보안 문제에 대한 패치를 계속 제공받습니다. 가능한 한 빨리 Amazon Linux 2023 기반 런타임으로 업그레이드할 것을 권장합니다. Java 21 또는 Java 25로 업그레이드하는 고객의 경우 [AWS Transform 사용자 지정](https://docs.aws.amazon.com/transform/latest/userguide/custom.html)을 사용하여 이러한 업그레이드를 지원할 수 있습니다. Java 버전을 업그레이드할 수 없는 고객을 위해 2026년 2분기 이전에 Java 8, Java 11 및 Java 17용 Amazon Linux 2023 기반 런타임을 릴리스할 계획입니다. | 이름 | 식별자 | 운영 체제 | 사용 중단 날짜 | 블록 함수 생성 | 블록 함수 업데이트 | | --- | --- | --- | --- | --- | --- | | Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 2028년 4월 30일 | 2028년 6월 1일 | 2028년 7월 1일 | | Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 2027년 4월 30일 | 2027년 6월 1일 | 2027년 7월 1일 | | Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 2026년 4월 30일 | 2026년 8월 31일 | 2026년 9월 30일 | | Python 3.14 | `python3.14` | Amazon Linux 2023 | 2029년 6월 30일 | 2029년 7월 31일 | 2029년 8월 31일 | | Python 3.13 | `python3.13` | Amazon Linux 2023 | 2029년 6월 30일 | 2029년 7월 31일 | 2029년 8월 31일 | | Python 3.12 | `python3.12` | Amazon Linux 2023 | 2028년 10월 31일 | 2028년 11월 30일 | 2029년 1월 10일 | | Python 3.11 | `python3.11` | Amazon Linux 2 | 2027년 6월 30일 | 2027년 7월 31일 | 2027년 8월 31일 | | Python 3.10 | `python3.10` | Amazon Linux 2 | 2026년 10월 31일 | 2026년 11월 30일 | 2027년 1월 15일 | | Java 25 | `java25` | Amazon Linux 2023 | 2029년 6월 30일 | 2029년 7월 31일 | 2029년 8월 31일 | | Java 21 | `java21` | Amazon Linux 2023 | 2029년 6월 30일 | 2029년 7월 31일 | 2029년 8월 31일 | | Java 17 | `java17` | Amazon Linux 2 | 2027년 6월 30일 | 2027년 7월 31일 | 2027년 8월 31일 | | Java 11 | `java11` | Amazon Linux 2 | 2027년 6월 30일 | 2027년 7월 31일 | 2027년 8월 31일 | | Java 8 | `java8.al2` | Amazon Linux 2 | 2027년 6월 30일 | 2027년 7월 31일 | 2027년 8월 31일 | | .NET 10 | `dotnet10` | Amazon Linux 2023 | 2028년 11월 14일 | 2028년 12월 14일 | 2029년 1월 15일 | | .NET 9(컨테이너만 해당) | `dotnet9` | Amazon Linux 2023 | 2026년 11월 10일 | 예약되지 않음 | 예약되지 않음 | | .NET 8 | `dotnet8` | Amazon Linux 2023 | 2026년 11월 10일 | 2026년 12월 10일 | 2027년 1월 11일 | | Ruby 3.4 | `ruby3.4` | Amazon Linux 2023 | 2028년 3월 31일 | 2028년 4월 30일 | 2028년 5월 31일 | | Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 2027년 3월 31일 | 2027년 4월 30일 | 2027년 5월 31일 | | Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 2026년 3월 31일 | 2026년 8월 31일 | 2026년 9월 30일 | | OS 전용 런타임 | `provided.al2023` | Amazon Linux 2023 | 2029년 6월 30일 | 2029년 7월 31일 | 2029년 8월 31일 | | OS 전용 런타임 | `provided.al2` | Amazon Linux 2 | 2026년 7월 31일 | 2026년 8월 31일 | 2026년 9월 30일 | **참고** 새 리전의 경우, Lambda는 향후 6개월 내에 지원 중단될 런타임은 지원하지 않습니다. Lambda는 패치를 통해 관리형 런타임 및 해당하는 컨테이너 기본 이미지를 최신 상태로 유지하고 마이너 버전 릴리스를 지원합니다. 자세한 내용은 [Lambda 런타임 업데이트](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html)를 참조하세요. Lambda 함수의 다른 AWS 서비스 및 리소스와 프로그래밍 방식으로 상호 작용하려면 AWS SDK 중 하나를 사용할 수 있습니다. Node.js, Python 및 Ruby 런타임에는 AWS SDK 버전이 포함되어 있습니다. 그러나 종속성을 완벽하게 제어하고 자동 런타임 업데이트 중에 [이전 버전과의 호환성](runtimes-update.md#runtime-update-compatibility)을 극대화하려면 항상 코드가 사용하는 SDK 모듈을 모든 종속성과 함께 함수의 배포 패키지 또는 [Lambda 계층](chapter-layers.md)에 포함하는 것이 좋습니다. 배포에 추가 패키지를 포함할 수 없는 경우에만 런타임 포함 SDK 버전을 사용하는 것이 좋습니다. 예를 들어, Lambda 콘솔 코드 편집기를 사용하거나 CloudFormation 템플릿에서 인라인 함수 코드를 사용하여 함수를 생성하는 경우입니다. Lambda는 Node.js, Python 및 Ruby 런타임에 포함된 AWS SDK의 버전을 주기적으로 업데이트합니다. 사용 중인 런타임에 포함된 AWS SDK 버전을 확인하려면 다음 섹션을 참조하세요. + [런타임에 포함된 SDK 버전(Node.js)](lambda-nodejs.md#nodejs-sdk-included) + [런타임에 포함된 SDK 버전(Python)](lambda-python.md#python-sdk-included) + [런타임에 포함된 SDK 버전(Ruby)](lambda-ruby.md#ruby-sdk-included) Lambda는 Go 1.x 런타임이 지원 중단된 후에도 Go 프로그래밍 언어를 계속 지원합니다. 자세한 내용은 *AWS 컴퓨팅 블로그*에서 [ Migrating AWS Lambda functions from the Go1.x runtime to the custom runtime on Amazon Linux 2](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/)를 참조하세요. 지원되는 모든 Lambda 런타임은 x86\$164 아키텍처와 arm64 아키텍처를 모두 지원합니다. ## 새 런타임 릴리스 Lambda는 릴리스가 언어의 릴리스 주기에서 장기 지원(LTS) 단계에 도달한 경우에만 새 언어 버전의 관리형 런타임을 제공합니다. 예를 들어, [Node.js 릴리스 주기](https://nodejs.org/en/about/previous-releases)의 경우 릴리스가 활성 LTS 단계에 도달하는 경우가 이에 해당합니다. 릴리스가 장기 지원 단계에 도달하기 전까지는 개발 상태이며, 여전히 주요 변경 사항이 적용될 수 있습니다. Lambda는 기본적으로 런타임 업데이트를 자동으로 적용하므로 런타임 버전을 크게 변경하면 함수가 예상대로 작동하지 않을 수 있습니다. Lambda는 LTS 릴리스가 예정되지 않은 언어 버전에 대해 관리형 런타임을 제공하지 않습니다. 다음 목록에서는 예정된 Lambda 런타임의 목표 출시 월을 보여줍니다. 이 날짜는 참고용일 뿐이기 때문에 변경될 수 있습니다. + **Ruby 3.5** - 2026년 3월 + **AL2023 기반 Java 8, 11 및 17** - 2026년 2분기 + **Node.js 26** - 2026년 11월 + **Python 3.15** - 2026년 11월 ## 런타임 사용 중단 정책 .zip 파일 아카이브에 대한 Lambda 런타임은 유지 관리 및 보안 업데이트가 적용되는 운영 체제, 프로그래밍 언어 및 소프트웨어 라이브러리의 조합을 기반으로 구축됩니다. Lambda의 표준 지원 중단 정책은 런타임의 주요 구성 요소가 커뮤니티 장기 지원(LTS) 종료에 도달하여 보안 업데이트를 더 이상 사용할 수 없는 경우 런타임을 지원 중단하는 것입니다. 대부분의 경우 이 런타임이 언어 런타임이지만 운영 체제(OS)가 LTS 끝에 도달하여 런타임이 더 이상 사용되지 않는 경우도 있습니다. 런타임이 사용 중단되면 AWS에서 더 이상 해당 런타임에 보안 패치 또는 업데이트를 적용하지 않을 수 있으며 해당 런타임을 사용하는 함수는 더 이상 기술 지원을 받을 수 없습니다. 이러한 사용 중단된 런타임은 어떠한 보증 없이 '있는 그대로' 제공되며 버그, 오류, 결함 또는 기타 취약성을 포함할 수 있습니다. 런타임 업그레이드 및 지원 중단 관리에 대한 자세한 내용은 다음 섹션 및 AWS 컴퓨팅 블로그에서 [Managing AWS Lambda runtime upgrades](https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/)를 참조하세요.** **중요** Lambda는 때때로 해당 런타임이 지원하는 언어 버전의 지원 종료일 이후 제한된 기간 동안 Lambda 런타임의 지원 중단을 지연합니다. 이 기간 동안 Lambda는 런타임 OS에만 보안 패치를 적용합니다. Lambda는 지원 종료일에 도달한 후에는 프로그래밍 언어 런타임에 보안 패치를 적용하지 않습니다. ## 공동 책임 모델 Lambda는 지원되는 모든 관리형 런타임과 컨테이너 기본 이미지에 대한 보안 업데이트를 큐레이팅하고 게시하는 역할을 담당합니다. Lambda는 기본적으로 관리형 런타임을 사용하는 함수에 런타임 업데이트를 자동으로 적용합니다. 기본 자동 런타임 업데이트 설정이 변경된 경우 [런타임 관리 제어 공동 책임 모델](runtime-management-shared.md)을 참조하세요. 컨테이너 이미지를 사용하여 배포된 함수의 경우 사용자는 최신 기본 이미지에서 함수의 컨테이너 이미지를 다시 빌드하고 컨테이너 이미지를 재배포해야 합니다. 런타임이 지원 중단되면 관리형 런타임 및 컨테이너 기본 이미지 업데이트에 대한 Lambda의 책임이 중단됩니다. 지원되는 런타임 또는 기본 이미지를 사용하도록 함수를 업그레이드할 책임은 사용자에게 있습니다. 모든 경우에 종속성을 포함한 함수 코드에 업데이트를 적용하는 것은 사용자의 책임입니다. 공동 책임 모델에 따른 사용자의 책임은 다음 표에 요약되어 있습니다. | 런타임 수명 주기 단계 | Lambda의 책임 | 귀하의 책임 | | --- | --- | --- | | 지원되는 관리형 런타임 | 보안 패치 및 기타 업데이트와 함께 정기적인 런타임 업데이트를 제공합니다. 기본적으로 런타임 업데이트를 자동으로 적용합니다(기본이 아닌 동작은 [런타임 업데이트 모드](runtimes-update.md#runtime-management-controls) 참조). | 종속성을 포함한 함수 코드를 업데이트하여 보안 취약성을 해결합니다. | | 지원되는 컨테이너 이미지 | 보안 패치 및 기타 업데이트와 함께 정기적인 컨테이너 기본 이미지 업데이트를 제공합니다. | 종속성을 포함한 함수 코드를 업데이트하여 보안 취약성을 해결합니다. 최신 기본 이미지를 사용하여 컨테이너 이미지를 정기적으로 다시 빌드하고 배포합니다. | | 지원 중단에 가까워진 관리형 런타임 | 런타임 지원 중단 전에 설명서, Health Dashboard, 이메일, Trusted Advisor 등을 통해 고객에게 알립니다. 런타임 업데이트에 대한 책임은 지원 중단과 동시에 종료됩니다. | Lambda 설명서, Health Dashboard, 이메일 또는 Trusted Advisor에서 런타임 지원 중단 정보를 모니터링합니다. 이전 런타임이 지원 중단되기 전에 지원되는 런타임으로 함수를 업그레이드합니다. | | 지원 중단에 가까워진 컨테이너 이미지 | 컨테이너 이미지를 사용하는 함수에 대한 지원 중단 알림은 제공되지 않습니다. 컨테이너 기본 이미지 업데이트에 대한 책임은 지원 중단과 동시에 종료됩니다. | 지원 중단 일정을 숙지하고 이전 이미지가 지원 중단되기 전에 지원되는 기본 이미지로 함수를 업그레이드합니다. | ## 지원 중단 이후 런타임 사용 런타임이 사용 중단되면 AWS에서 더 이상 해당 런타임에 보안 패치 또는 업데이트를 적용하지 않을 수 있으며 해당 런타임을 사용하는 함수는 더 이상 기술 지원을 받을 수 없습니다. 함수를 무기한으로 계속 간접적으로 호출할 수 있지만 AWS에서는 지원되는 런타임으로 마이그레이션할 것을 강력히 권장합니다. 사용 중단된 런타임은 어떠한 보증 없이 '있는 그대로' 제공되며 버그, 오류, 결함 또는 기타 취약성을 포함할 수 있습니다. 지원 중단된 런타임을 사용하는 함수는 성능이 저하되거나 인증서 만료와 같은 기타 문제가 발생하여 제대로 작동하지 않을 수 있습니다. 런타임이 사용 중단된 후 지원되는 최신 런타임을 사용하도록 언제든지 함수를 업데이트할 수 있습니다. 프로덕션 환경에 변경 사항을 적용하기 전에 새 런타임으로 함수를 테스트해 보는 것이 좋습니다. 함수 업데이트가 차단된 후에는 사용 중단된 런타임으로 되돌릴 수 없습니다. 롤백을 통해 안전하게 배포하려면 함수 [버전](configuration-versions.md) 및 [별칭](configuration-aliases.md)을 사용하는 것이 좋습니다. 아래의 타임라인에서는 런타임이 사용 중단된 경우 발생하는 상황이 설명되어 있습니다. | 런타임 수명 주기 단계 | 일시 | 무엇 | | --- | --- | --- | | 사용 중단 알림 기간 | 사용 중단 최소 180일 전 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-runtimes.html) | | 사용 중단 | 사용 중단 날짜 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-runtimes.html) | | 블록 함수 생성 | 사용 중단 후 최소 30일 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-runtimes.html) | | 블록 함수 업데이트 | 사용 중단 후 최소 60일 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-runtimes.html) | **참고** 일부 런타임의 경우 AWS는 지원 중단 후 일반적인 30일 및 60일 이후로 block-function-create 및 block-function-update 날짜를 늦춥니다. AWS는 고객 피드백을 반영하여 함수를 업그레이드할 수 있는 시간을 더 확보하기 위해 이러한 변경을 수행했습니다. 런타임 날짜를 확인하려면 [지원되는 런타임](#runtimes-supported) 및 [더 이상 사용되지 않는 런타임](#runtimes-deprecated)의 표를 참조하세요. Lambda는 이 표에 나와 있는 날짜 이전에 함수 생성 또는 업데이트 차단을 시작하지 않습니다. ## 런타임 지원 중단 알림 수신 런타임의 지원 중단 날짜가 가까워지면 Lambda는 AWS 계정의 함수가 해당 런타임을 사용하는 경우 이메일 알림을 보냅니다. 알림은 Health Dashboard 및 AWS Trusted Advisor에도 표시됩니다. + 이메일 알림 수신: Lambda는 런타임이 지원 중단되기 최소 **180일** 전까지 이메일 알림을 보냅니다. 이 이메일에는 런타임을 사용하는 모든 함수의 \$1LATEST 버전이 나열되어 있습니다. 영향을 받는 함수 버전의 전체 목록을 보려면 Trusted Advisor를 사용하거나 [지원 중단된 런타임을 사용하는 Lambda 함수에 대한 데이터 가져오기](runtimes-list-deprecated.md) 섹션을 참조하세요. Lambda는 AWS 계정의 기본 계정 연락처로 이메일 알림을 전송합니다. 계정의 이메일 주소 보기 또는 업데이트에 대한 자세한 내용은 *AWS 참조 가이드*에서 [Updating contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)을 참조하세요. + Health Dashboard을 통해 알림 수신: Health Dashboard에서는 런타임이 지원 중단되기 최소 **180일** 전까지 알림을 표시합니다. 알림은 **계정 상태** 페이지의 [기타 알림](https://health.aws.amazon.com/health/home#/account/dashboard/other-notifications)에 표시됩니다. 알림의 **영향을 받는 리소스** 탭에는 런타임을 사용하는 모든 함수의 \$1LATEST 버전이 나열됩니다. **참고** 영향을 받는 함수 버전의 전체 최신 목록을 보려면 Trusted Advisor를 사용하거나 [지원 중단된 런타임을 사용하는 Lambda 함수에 대한 데이터 가져오기](runtimes-list-deprecated.md) 섹션을 참조하세요. Health Dashboard 알림은 영향을 받는 런타임이 지원 중단되고 90일 후에 만료됩니다. + AWS Trusted Advisor 사용하기 Trusted Advisor에서는 런타임이 지원 중단되기 최소 **180일** 전까지 알림을 표시합니다. 알림은 [보안](https://console.aws.amazon.com/trustedadvisor/home#/category/security) 페이지에 표시됩니다. 영향을 받는 함수 목록은 **지원 중단된 런타임을 사용하는 AWS Lambda 함수** 아래에 표시됩니다. 이 함수 목록에는 \$1LATEST 버전 및 게시된 버전이 모두 표시되며 함수의 현재 상태를 반영하도록 자동으로 업데이트됩니다. Trusted Advisor 콘솔의 [기본 설정](https://console.aws.amazon.com/trustedadvisor/home?#/preferences) 페이지에서 Trusted Advisor가 제공하는 주간 이메일 알림을 켤 수 있습니다. ## 더 이상 사용되지 않는 런타임 다음 런타임은 지원 종료 시점에 도달했습니다. | 이름 | 식별자 | 운영 체제 | 사용 중단 날짜 | 블록 함수 생성 | 블록 함수 업데이트 | | --- | --- | --- | --- | --- | --- | | Python 3.9 | python3.9 | Amazon Linux 2 | 2025년 12월 15일 | 2026년 8월 31일 | 2026년 9월 30일 | | Node.js 18 | nodejs18.x | Amazon Linux 2 | 2025년 9월 1일 | 2026년 8월 31일 | 2026년 9월 30일 | | .NET 6 | dotnet6 | Amazon Linux 2 | 2024년 12월 20일 | 2026년 8월 31일 | 2026년 9월 30일 | | Python 3.8 | python3.8 | Amazon Linux 2 | 2024년 10월 14일 | 2026년 8월 31일 | 2026년 9월 30일 | | Node.js 16 | nodejs16.x | Amazon Linux 2 | 2024년 6월 12일 | 2026년 8월 31일 | 2026년 9월 30일 | | .NET 7(컨테이너만 해당) | dotnet7 | Amazon Linux 2 | 2024년 5월 14일 | 해당 사항 없음 | 해당 사항 없음 | | Java 8 | java8 | Amazon Linux | 2024년 1월 8일 | 2024년 2월 8일 | 2026년 9월 30일 | | Go 1.x | go1.x | Amazon Linux | 2024년 1월 8일 | 2024년 2월 8일 | 2026년 9월 30일 | | OS 전용 런타임 | provided | Amazon Linux | 2024년 1월 8일 | 2024년 2월 8일 | 2026년 9월 30일 | | Ruby 2.7 | ruby2.7 | Amazon Linux 2 | 2023년 12월 7일 | 2024년 1월 9일 | 2026년 9월 30일 | | Node.js 14 | nodejs14.x | Amazon Linux 2 | 2023년 12월 4일 | 2024년 1월 9일 | 2026년 9월 30일 | | Python 3.7 | python3.7 | Amazon Linux | 2023년 12월 4일 | 2024년 1월 9일 | 2026년 9월 30일 | | .NET Core 3.1 | dotnetcore3.1 | Amazon Linux 2 | 2023년 4월 3일 | 2023년 4월 3일 | 2023년 5월 3일 | | Node.js 12 | nodejs12.x | Amazon Linux 2 | 2023년 3월 31일 | 2023년 3월 31일 | 2023년 4월 30일 | | Python 3.6 | python3.6 | Amazon Linux | 2022년 7월 18일 | 2022년 7월 18일 | 2022년 8월 29일 | | .NET 5(컨테이너만 해당) | dotnet5.0 | Amazon Linux 2 | 2022년 5월 10일 | 해당 사항 없음 | 해당 사항 없음 | | .NET Core 2.1 | dotnetcore2.1 | Amazon Linux | 2022년 1월 5일 | 2022년 1월 5일 | 2022년 4월 13일 | | Node.js 10 | nodejs10.x | Amazon Linux 2 | 2021년 7월 30일 | 2021년 7월 30일 | 2022년 2월 14일 | | Ruby 2.5 | ruby2.5 | Amazon Linux | 2021년 7월 30일 | 2021년 7월 30일 | 2022년 3월 31일 | | Python 2.7 | python2.7 | Amazon Linux | 2021년 7월 15일 | 2021년 7월 15일 | 2022년 5월 30일 | | Node.js 8.10 | nodejs8.10 | Amazon Linux | 2020년 3월 6일 | 2020년 2월 4일 | 2020년 3월 6일 | | Node.js 4.3 | nodejs4.3 | Amazon Linux | 2020년 3월 5일 | 2020년 2월 3일 | 2020년 3월 5일 | | Node.js 4.3 엣지 | nodejs4.3-edge | Amazon Linux | 2020년 3월 5일 | 2019년 3월 31일 | 2019년 4월 30일 | | Node.js 6.10 | nodejs6.10 | Amazon Linux | 2019년 8월 12일 | 2019년 7월 12일 | 2019년 8월 12일 | | .NET Core 1.0 | dotnetcore1.0 | Amazon Linux | 2019년 6월 27일 | 2019년 6월 30일 | 2019년 7월 30일 | | .NET Core 2.0 | dotnetcore2.0 | Amazon Linux | 2019년 5월 30일 | 2019년 4월 30일 | 2019년 5월 30일 | | Node.js 0.10 | nodejs | Amazon Linux | 2016년 8월 30일 | 2016년 9월 30일 | 2016년 10월 31일 | 거의 모든 경우에 언어 버전 또는 운영 체제의 수명 종료는 미리 공개됩니다. 아래 링크는 Lambda가 관리형 런타임으로 지원하는 각 언어의 수명 종료 일정을 제공합니다. **언어 및 프레임워크 지원 정책** + **Node.js** – [github.com](https://github.com/nodejs/Release#release-schedule) + **Python** – [devguide.python.org](https://devguide.python.org/versions/#versions) + **Ruby** – [www.ruby-lang.org](https://www.ruby-lang.org/en/downloads/branches/) + **Java** – [www.oracle.com](https://www.oracle.com/java/technologies/java-se-support-roadmap.html) 및 [Corretto FAQ](https://aws.amazon.com/corretto/faqs/) + **Go** –[golang.org](https://golang.org/doc/devel/release.html) + **.NET** – [dotnet.microsoft.com](https://dotnet.microsoft.com/platform/support/policy/dotnet-core) # Lambda가 런타임 버전 업데이트를 관리하는 방법 이해 Lambda는 보안 업데이트, 버그 수정, 새로운 기능, 성능 개선 사항 및 마이너 버전 릴리스에 대한 지원을 통해 각 관리형 런타임을 최신 상태로 유지합니다. 이러한 런타임 업데이트는 *런타임 버전*으로 게시됩니다. Lambda는 이전 런타임 버전에서 새 런타임 버전으로 함수를 마이그레이션하여 함수에 런타임 업데이트를 적용합니다. 관리형 런타임을 사용하는 함수의 경우 Lambda는 기본적으로 런타임 업데이트를 자동으로 적용합니다. 자동 런타임 업데이트를 통해, Lambda는 런타임 버전에 패치를 적용하는 데 따른 운영 부담을 덜어줍니다. 대부분의 고객은 자동 업데이트를 선택하는 것이 좋습니다. [런타임 관리 설정](runtime-management-configure-settings.md)을 구성하여 이 기본 동작을 변경할 수 있습니다. 또한 Lambda는 각각의 새 런타임 버전을 컨테이너 이미지로 게시합니다. 컨테이너 기반 함수의 런타임 버전을 업데이트하려면 업데이트된 기본 이미지에서 [새 컨테이너 이미지를 생성하고](images-create.md) 함수를 재배포해야 합니다. 각 런타임 버전은 버전 번호 및 ARN(Amazon 리소스 이름)과 연결됩니다. 런타임 버전 번호는 프로그래밍 언어에서 사용하는 버전 번호에 관계없이 Lambda가 정의하는 번호 지정 스키마를 사용합니다. 런타임 버전 번호가 항상 순차적인 것은 아닙니다. 예를 들어 버전 42 다음에 버전 45가 올 수 있습니다. 런타임 버전 ARN은 각 런타임 버전의 고유 식별자입니다. Lambda 콘솔 또는 [함수 로그의`INIT_START` 줄](runtime-management-identify.md)에서 함수의 현재 런타임 버전 ARN을 확인할 수 있습니다. 런타임 버전을 런타임 식별자와 혼동해서는 안 됩니다. 각 런타임에는 `python3.14` 또는 `nodejs24.x`와 같은 고유한 **런타임 식별자**가 있습니다. 이 식별자는 각각의 메이저 프로그래밍 언어 릴리스에 해당합니다. 런타임 버전은 개별 런타임의 패치 버전을 설명합니다. **참고** 동일한 런타임 버전 번호의 ARN은 AWS 리전 및 CPU 아키텍처마다 다를 수 있습니다. **Topics** + [이전 버전과의 호환성](#runtime-update-compatibility) + [런타임 업데이트 모드](#runtime-management-controls) + [2단계 런타임 버전 롤아웃](#runtime-management-two-phase) + [Lambda 런타임 관리 설정 구성](runtime-management-configure-settings.md) + [Lambda 런타임 버전 롤백](runtime-management-rollback.md) + [Lambda 런타임 버전 변경 확인](runtime-management-identify.md) + [Lambda 런타임 관리를 위한 공동 책임 모델의 이해](runtime-management-shared.md) + [규정 준수가 엄격한 애플리케이션의 Lambda 런타임 업데이트 권한 제어](runtime-management-hc-applications.md) ## 이전 버전과의 호환성 Lambda는 기존 함수와 호환되는 런타임 업데이트를 제공하기 위해 노력합니다. 하지만 소프트웨어 패치와 마찬가지로, 드물지만 런타임 업데이트가 기존 함수에 부정적인 영향을 미칠 수 있는 경우도 있습니다. 예를 들어 보안 패치는 이전의 안전하지 않은 동작에 의존하는 기존 함수의 근본적인 문제를 노출시킬 수 있습니다. 함수를 빌드하고 배포할 때 향후 런타임 업데이트와의 잠재적인 비호환성을 방지하려면 종속성을 관리하는 방법을 이해하는 것이 중요합니다. 예를 들어, 함수가 패키지 A에 대한 종속성이 있고 패키지 A는 패키지 B에 종속된다고 가정해 보겠습니다. 두 패키지 모두 Lambda 런타임에 포함됩니다(예: SDK 또는 해당 종속성의 일부이거나 런타임 시스템 라이브러리의 일부일 수 있음). 다음 시나리오를 고려해 보세요. | 배포 | 호환 가능한 패치 | 이유 | | --- | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/runtimes-update.html) | 예 | 패키지 A 및 B에 대한 향후 런타임 업데이트는 이전 버전과 호환됩니다. | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/runtimes-update.html) | 예 | 배포본이 우선하므로 패키지 A 및 B에 대한 향후 런타임 업데이트는 영향을 미치지 않습니다. | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/runtimes-update.html) | 예\$1 | 패키지 B에 대한 향후 런타임 업데이트는 이전 버전과 호환됩니다. \$1A와 B가 긴밀하게 연결되면 호환성 문제가 발생할 수 있습니다. 예를 들어, AWS SDK for Python의 `boto3` 및 `botocore` 패키지를 함께 배포해야 합니다. | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/runtimes-update.html) | 아니요 | 패키지 A에 대한 향후 런타임 업데이트에는 패키지 B의 업데이트된 버전이 필요할 수 있습니다. 그러나 패키지 B의 배포된 버전이 우선하기 때문에 패키지 A의 향후 업데이트된 버전과 호환되지 않을 수 있습니다. | 향후 런타임 업데이트와의 호환성을 유지하려면 다음 모범 사례를 따르세요. + **가능한 경우 모든 종속성 패키징:** AWS SDK 및 해당 종속성을 포함하여 필요한 모든 라이브러리를 배포 패키지에 포함합니다. 이렇게 하면 안정적이고 호환되는 구성 요소 세트가 보장됩니다. + **런타임 제공 SDK 사용 최소화:** Lambda 콘솔 코드 편집기를 사용하거나 AWS CloudFormation 템플릿에서 인라인 코드를 사용하는 경우와 같이 추가 패키지를 포함할 수 없는 경우에만 런타임 제공 SDK를 사용하세요. + **시스템 라이브러리 재정의 방지:** 향후 런타임 업데이트와 충돌할 수 있는 사용자 지정 운영 체제 라이브러리를 배포하지 마세요. ## 런타임 업데이트 모드 Lambda는 기존 함수와 호환되는 런타임 업데이트를 제공하기 위해 노력합니다. 하지만 소프트웨어 패치와 마찬가지로, 드물지만 런타임 업데이트가 기존 함수에 부정적인 영향을 미칠 수 있는 경우도 있습니다. 예를 들어 보안 패치는 이전의 안전하지 않은 동작에 의존하는 기존 함수의 근본적인 문제를 노출시킬 수 있습니다. Lambda 런타임 관리 제어는 드물게 런타임 버전 비호환성이 발생하는 경우 워크로드에 영향을 미칠 위험을 줄이는 데 도움이 됩니다. 각 [함수 버전](configuration-versions.md)(`$LATEST` 또는 게시된 버전)에 대해 다음 런타임 업데이트 모드 중 하나를 선택할 수 있습니다. + **자동(기본값)** - [2단계 런타임 버전 롤아웃](#runtime-management-two-phase)을 사용하여 가장 최신의 안전한 런타임 버전으로 자동 업데이트합니다. 런타임 업데이트의 이점을 항상 누릴 수 있도록 대부분의 고객에게 이 모드를 권장합니다. + **함수 업데이트** - 함수를 업데이트하면 최신의 안전한 런타임 버전으로 업데이트합니다. 함수를 업데이트하면 Lambda는 함수의 런타임 버전을 최신의 안전한 런타임 버전으로 업데이트합니다. 이 방식은 런타임 업데이트를 함수 배포와 동기화하여 Lambda가 런타임 업데이트를 적용하는 시점을 사용자가 제어할 수 있도록 합니다. 이 모드를 사용하면 드물게 발생하는 런타임 업데이트 비호환성을 조기에 감지하여 해결할 수 있습니다. 이 모드를 사용하는 경우 런타임을 최신 상태로 유지하려면 함수를 정기적으로 업데이트해야 합니다. + **수동** — 런타임 버전을 수동으로 업데이트합니다. 사용자가 함수 구성에서 런타임 버전을 지정합니다. 이 런타임 버전이 함수에 무기한으로 사용됩니다. 드문 경우지만 새 런타임 버전이 기존 함수와 호환되지 않는 경우 이 모드를 사용하여 함수를 이전 런타임 버전으로 롤백할 수 있습니다. 배포 전반에서 런타임 일관성을 유지하는 데 **수동** 모드를 사용하지 않는 것이 좋습니다. 자세한 내용은 [Lambda 런타임 버전 롤백](runtime-management-rollback.md) 섹션을 참조하세요. 함수에 런타임 업데이트를 적용할 책임의 여부는 선택한 런타임 업데이트 모드에 따라 달라집니다. 자세한 내용은 [Lambda 런타임 관리를 위한 공동 책임 모델의 이해](runtime-management-shared.md) 섹션을 참조하세요. ## 2단계 런타임 버전 롤아웃 Lambda는 다음 순서로 새 런타임 버전을 도입합니다. 1. 첫 번째 단계에서 Lambda는 사용자가 함수를 생성하거나 업데이트할 때마다 새 런타임 버전을 적용합니다. 함수는 사용자가 [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) 또는 [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) API 작업을 호출할 때 업데이트됩니다. 1. 두 번째 단계에서 Lambda는 **자동** 런타임 업데이트 모드를 사용하고 아직 새 런타임 버전으로 업데이트되지 않은 모든 함수를 업데이트합니다. 롤아웃 프로세스의 전체 기간은 런타임 업데이트에 포함된 보안 패치의 심각도를 비롯한 여러 요인에 따라 달라집니다. 함수를 적극적으로 개발 및 배포하는 경우 첫 번째 단계에서 새 런타임 버전을 선택할 가능성이 높습니다. 이렇게 하면 런타임 업데이트가 함수 업데이트와 동기화됩니다. 드물지만 최신 런타임 버전이 애플리케이션에 부정적인 영향을 미치는 경우, 이 방법을 사용하면 즉각적인 시정 조치를 취할 수 있습니다. 현재 개발 중이 아닌 함수는 여전히 두 번째 단계에서 자동 런타임 업데이트라는 운영상의 이점을 누릴 수 있습니다. 이 방법은 **함수 업데이트** 모드 또는 **수동** 모드로 설정된 함수에는 영향을 미치지 않습니다. **함수 업데이트** 모드를 사용하는 함수의 경우 생성하거나 업데이트할 때만 최신 런타임 업데이트가 적용됩니다. **수동** 모드를 사용하는 함수의 경우 런타임 업데이트가 적용되지 않습니다. Lambda는 여러 AWS 리전에 새로운 런타임 버전을 점진적, 순차적으로 게시합니다. 함수가 **자동** 또는 **함수 업데이트** 모드로 설정된 경우 여러 리전에 동시에 배포되거나 동일한 리전에서 서로 다른 시간에 배포된 함수에 서로 다른 런타임 버전이 적용될 수 있습니다. 여러 환경에서 런타임 버전 일관성을 보장해야 하는 고객은 [컨테이너 이미지를 사용하여 Lambda 함수를 배포해야](images-create.md) 합니다. **수동** 모드는 드물게 런타임 버전이 함수와 호환이 안 되는 경우에 런타임 롤백을 지원하기 위한 임시 문제 해결 조치로 설계되었습니다. # Lambda 런타임 관리 설정 구성 Lambda 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용하여 런타임 관리 설정을 구성할 수 있습니다. **참고** 각 [함수 버전](configuration-versions.md)마다 런타임 관리 설정을 별도로 구성할 수 있습니다. **Lambda가 런타임 버전을 업데이트하는 방법을 구성하려면(콘솔)** 1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다. 1. 함수의 이름을 선택합니다. 1. **Code(코드)** 탭의 **Runtime settings**(런타임 설정)에서 **Edit runtime management configuration**(런타임 관리 구성 편집)을 선택합니다. 1. **Runtime management configuration**(런타임 관리 구성)에서 다음 중 하나를 선택합니다. + 함수가 자동으로 최신 런타임 버전으로 업데이트되도록 하려면 **Auto**(자동)를 선택합니다. + 사용자가 함수를 변경할 때 함수가 최신 런타임 버전으로 업데이트되도록 하려면 **Function update**(함수 업데이트)를 선택합니다. + 런타임 버전 ARN을 변경할 때만 함수가 최신 런타임 버전으로 업데이트되도록 하려면 **Manual**(수동)을 선택합니다. 런타임 버전 ARN은 **Runtime management configuration**(런타임 관리 구성)에서 확인할 수 있습니다. 함수 로그의 `INIT_START` 줄에서도 ARN을 확인할 수 있습니다. 이러한 옵션에 대한 자세한 내용은 [런타임 업데이트 모드](runtimes-update.md#runtime-management-controls) 섹션을 참조하세요. 1. **Save**(저장)를 선택합니다. **Lambda가 런타임 버전을 업데이트하는 방법을 구성하려면(AWS CLI)** 함수에 대한 런타임 관리를 구성하려면 [put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html) AWS CLI 명령을 실행합니다. `Manual` 모드를 사용할 때는 런타임 버전 ARN도 제공해야 합니다. ``` aws lambda put-runtime-management-config \ --function-name my-function \ --update-runtime-on Manual \ --runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1 ``` 다음과 유사한 출력 화면이 표시되어야 합니다. ``` { "UpdateRuntimeOn": "Manual", "FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function", "RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1" } ``` # Lambda 런타임 버전 롤백 드물지만 새 런타임 버전이 기존 함수와 호환되지 않는 경우 해당 런타임 버전을 이전 버전으로 롤백할 수 있습니다. 이렇게 하면 애플리케이션이 계속 작동하고 중단을 최소화하여 최신 런타임 버전으로 돌아가기 전에 비호환성을 해결할 시간을 확보할 수 있습니다. Lambda는 특정 런타임 버전을 사용할 수 있는 기간에 대한 시간 제한을 두지 않습니다. 하지만 최신 보안 패치, 성능 개선 사항 및 기능을 활용하려면 가능한 한 빨리 최신 런타임 버전으로 업데이트하는 것이 좋습니다. Lambda는 드물지만 런타임 업데이트 호환성 문제가 발생하는 경우를 대비하여 일시적인 문제 해결 수단으로만 이전 런타임 버전으로 롤백하는 옵션을 제공합니다. 이전 런타임 버전을 장기간 사용하는 함수는 결국 성능이 저하되거나 인증서 만료와 같은 문제가 발생하여 제대로 작동하지 않을 수 있습니다. 런타임 버전을 롤백하는 방법은 다음과 같습니다. + [수동 런타임 업데이트 모드 사용](#runtime-management-rollback-manual) + [게시된 함수 버전 사용](#runtime-management-rollback-published) 자세한 내용은 AWS 컴퓨팅 블로그에서 [Introducing AWS Lambda runtime management controls(런타임 관리 제어 소개)](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/)를 참조하세요. ## 수동 런타임 업데이트 모드를 사용하여 런타임 버전 롤백 **자동** 런타임 버전 업데이트 모드를 사용하거나 `$LATEST` 런타임 버전을 사용하는 경우 **수동** 모드를 사용하여 런타임 버전을 롤백할 수 있습니다. 롤백하려는 [함수 버전](configuration-versions.md)에 대해 런타임 버전 업데이트 모드를 **수동**으로 변경하고 이전 런타임 버전의 ARN을 지정합니다. 이전 런타임 버전의 ARN 찾는 방법에 대한 자세한 내용은 [Lambda 런타임 버전 변경 확인](runtime-management-identify.md) 섹션을 참조하세요. **참고** 함수의 `$LATEST` 버전이 **수동** 모드를 사용하도록 구성된 경우 함수가 사용하는 CPU 아키텍처 또는 런타임 버전을 변경할 수 없습니다. 이러한 변경 작업을 수행하려면 **자동** 또는 **함수 업데이트** 모드로 변경해야 합니다. ## 게시된 함수 버전을 사용하여 런타임 버전 롤백 게시된 [함수 버전](configuration-versions.md)은 생성한 시점의 `$LATEST` 함수 코드 및 구성을 보여주는 변경 불가능한 스냅샷입니다. **자동** 모드에서는 Lambda가 런타임 버전 롤아웃의 2단계에서 게시된 함수 버전의 런타임 버전을 자동으로 업데이트합니다. **함수 업데이트** 모드에서는 Lambda가 게시된 함수 버전의 런타임 버전을 업데이트하지 않습니다. 따라서 **함수 업데이트** 모드를 사용하여 게시된 함수 버전은 함수 코드, 구성 및 런타임 버전의 정적 스냅샷을 생성합니다. 함수 버전과 함께 **함수 업데이트** 모드를 사용하면 런타임 업데이트를 배포와 동기화할 수 있습니다. 트래픽을 이전에 게시된 함수 버전으로 리디렉션하여 코드, 구성 및 런타임 버전의 롤백을 조정할 수도 있습니다. 이 접근 방식을 지속적 통합 및 지속적 전달(CI/CD)에 통합하여 런타임 업데이트가 호환되지 않는 드문 경우에 완전 자동 롤백을 실행할 수 있습니다. 이 방법을 사용할 때는 정기적으로 함수를 업데이트하고 새 함수 버전을 게시하여 최신 런타임 업데이트를 적용해야 합니다. 자세한 내용은 [Lambda 런타임 관리를 위한 공동 책임 모델의 이해](runtime-management-shared.md) 단원을 참조하십시오. # Lambda 런타임 버전 변경 확인 [런타임 버전 번호](runtimes-update.md)와 ARN은 `INIT_START` 로그 줄에 기록되며, Lambda는 새 [실행 환경](concepts-basics.md#gettingstarted-concepts-runtime)을 생성할 때마다 이를 CloudWatch Logs로 내보냅니다. 실행 환경은 모든 함수 호출에 대해 동일한 런타임 버전을 사용하므로 Lambda는 init 단계를 실행할 때만 `INIT_START` 로그 라인을 내보냅니다. Lambda는 각 함수 호출에 대해 이 로그 줄을 내보내지 않습니다. Lambda는 이 로그 줄을 CloudWatch Logs로 내보내지만 콘솔에는 표시되지 않습니다. **참고** 런타임 버전 번호가 항상 순차적인 것은 아닙니다. 예를 들어 버전 42 다음에 버전 45가 올 수 있습니다. **Example INIT\$1START 로그 줄의 예** ``` INIT_START Runtime Version: python:3.13.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I ``` 로그를 직접 사용하는 대신, [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html)를 사용하여 런타임 버전 간의 전환을 식별할 수 있습니다. 다음 규칙은 각 `INIT_START` 로그 줄에서 개별 런타임 버전의 수를 계산합니다. 이 규칙을 사용하려면 예제 로그 그룹 이름 `/aws/lambda/*`를 함수 또는 함수 그룹에 적합한 접두사로 바꿉니다. ``` { "Schema": { "Name": "CloudWatchLogRule", "Version": 1 }, "AggregateOn": "Count", "Contribution": { "Filters": [ { "Match": "eventType", "In": [ "INIT_START" ] } ], "Keys": [ "runtimeVersion", "runtimeVersionArn" ] }, "LogFormat": "CLF", "LogGroupNames": [ "/aws/lambda/*" ], "Fields": { "1": "eventType", "4": "runtimeVersion", "8": "runtimeVersionArn" } } ``` 다음 CloudWatch Contributor Insights 보고서는 이전 규칙에서 캡처한 런타임 버전 전환의 예를 보여줍니다. 주황색 선은 이전 런타임 버전(**python:3.13.v12**)의 실행 환경 초기화를 나타내며, 파란색 선은 새 런타임 버전(**python:3.13.v14**)의 실행 환경 초기화를 나타냅니다. ![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/runtime_version_graph.png) # Lambda 런타임 관리를 위한 공동 책임 모델의 이해 Lambda는 지원되는 모든 관리형 런타임과 컨테이너 이미지에 대한 보안 업데이트를 큐레이팅하고 게시하는 역할을 담당합니다. 최신 런타임 버전을 사용하도록 기존 함수를 업데이트할 책임의 여부는 사용하는 런타임 업데이트 모드에 따라 달라집니다. Lambda는 **자동** 런타임 업데이트 모드를 사용하도록 구성된 모든 함수에 런타임 업데이트를 적용하는 역할을 담당합니다. **함수 업데이트** 런타임 업데이트 모드로 구성된 함수의 경우 사용자가 함수를 정기적으로 업데이트해야 합니다. Lambda는 사용자가 해당 업데이트를 수행할 때 런타임 업데이트를 적용하는 역할을 담당합니다. 사용자가 함수를 업데이트하지 않으면 Lambda는 런타임을 업데이트하지 않습니다. 사용자가 함수를 정기적으로 업데이트하지 않을 경우 보안 업데이트를 계속 받을 수 있도록 자동 런타임 업데이트로 구성하는 것이 좋습니다. **수동** 런타임 업데이트 모드를 사용하도록 구성된 함수의 경우, 최신 런타임 버전을 사용하도록 사용자가 함수를 업데이트해야 합니다. 런타임 업데이트가 호환되지 않는 드문 경우를 대비하여 런타임 버전을 롤백하는 용도로만 이 모드를 사용하는 것이 좋습니다. 또한 함수가 패치되지 않는 시간을 최소화하려면 최대한 빨리 **자동** 모드로 변경하는 것이 좋습니다. [컨테이너 이미지를 사용하여 함수를 배포하는](images-create.md) 경우 Lambda는 업데이트된 기본 이미지를 게시하는 역할을 담당합니다. 이 경우 사용자는 최신 기본 이미지에서 함수의 컨테이너 이미지를 다시 빌드하고 컨테이너 이미지를 재배포해야 합니다. 이 내용은 다음 표에 요약되어 있습니다. **** | Deployment mode(배포 모드) | Lambda의 책임 | 고객의 책임 | | --- | --- | --- | | 관리형 런타임, 자동 모드 | 최신 패치가 포함된 새 런타임 버전을 게시합니다. 기존 함수에 런타임 패치를 적용합니다. | 드물게 런타임 업데이트 호환성 문제가 발생하는 경우 이전 런타임 버전으로 롤백합니다. [이전 버전과의 호환성](runtimes-update.md#runtime-update-compatibility)을 위한 모범 사례를 따릅니다. | | 관리형 런타임, 함수 업데이트 모드 | 최신 패치가 포함된 새 런타임 버전을 게시합니다. | 함수를 정기적으로 업데이트하여 최신 런타임 버전을 적용합니다. 함수를 정기적으로 업데이트하지 않을 경우 함수를 **자동** 모드로 전환합니다. 드물게 런타임 업데이트 호환성 문제가 발생하는 경우 이전 런타임 버전으로 롤백합니다. [이전 버전과의 호환성](runtimes-update.md#runtime-update-compatibility)을 위한 모범 사례를 따릅니다. | | 관리형 런타임, 수동 모드 | 최신 패치가 포함된 새 런타임 버전을 게시합니다. | 런타임 업데이트 호환성 문제가 발생하는 드문 경우에 임시 런타임 롤백을 수행하는 데에만 이 모드를 사용합니다. 함수를 **자동** 또는 **함수 업데이트** 모드로 전환하고 최대한 빨리 최신 런타임 버전으로 전환하합니다. | | 컨테이너 이미지 | 최신 패치가 포함된 새 컨테이너 이미지를 게시합니다. | 최신 컨테이너 기본 이미지를 사용하여 정기적으로 함수를 재배포함으로써 최신 패치를 적용합니다. | AWS와의 공동 책임에 대한 자세한 내용은 [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)을 참조하세요. # 규정 준수가 엄격한 애플리케이션의 Lambda 런타임 업데이트 권한 제어 Lambda 고객은 패치 요구 사항을 충족하기 위해 일반적으로 자동 런타임 업데이트를 사용합니다. 애플리케이션에 엄격한 패치 업데이트 요구 사항이 적용되는 경우 이전 런타임 버전의 사용을 제한해야 할 수 있습니다. AWS Identity and Access Management(IAM)를 사용하여 AWS 계정의 사용자가 [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html) API 작업에 액세스하는 것을 거부함으로써 Lambda의 런타임 관리 제어를 제한할 수 있습니다. 이 작업은 함수의 런타임 업데이트 모드를 선택하는 데 사용됩니다. 이 작업에 대한 액세스를 거부하면 모든 함수가 기본적으로 **자동** 모드로 설정됩니다. [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 사용하여 조직 전체에 이 제한을 적용할 수 있습니다. 함수를 이전 런타임 버전으로 롤백해야 하는 경우, 사례별로 정책 예외를 적용할 수 있습니다. # 지원 중단된 런타임을 사용하는 Lambda 함수에 대한 데이터 가져오기 Lambda 런타임이 지원 중단에 가까워지면 Lambda는 이메일을 통해 알림을 보내고 Health Dashboard 및 Trusted Advisor에서 알림을 제공합니다. 이러한 이메일과 알림에는 런타임을 사용하는 함수의 \$1LATEST 버전이 나열됩니다. AWS Command Line Interface(AWS CLI) 또는 AWS SDK 중 하나를 사용하여 특정 런타임을 사용하는 모든 함수 버전을 나열합니다. 지원 중단될 예정인 런타임을 사용하는 함수가 많은 경우 AWS CLI 또는 AWS SDK를 사용하여 가장 자주 간접 호출되는 함수의 업데이트 우선 순위를 지정할 수도 있습니다. AWS CLI 및 AWS SDK를 사용하여 특정 런타임을 사용하는 함수에 대한 데이터를 수집하는 방법을 알아보려면 다음 섹션을 참조하십시오. ## 특정 런타임을 사용하는 함수 버전 목록 AWS CLI(을)를 사용하여 특정 런타임을 사용하는 모든 함수 버전을 나열하려면 다음 명령을 실행합니다. `RUNTIME_IDENTIFIER`를 지원 중단되는 런타임 이름으로 바꾸고 AWS 리전을 선택합니다. \$1LATEST 함수 버전만 나열하려면 명령에서 `--function-version ALL`을 생략합니다. ``` aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='RUNTIME_IDENTIFIER'].FunctionArn" ``` **작은 정보** 명령 예제에서는 `us-east-1` 리전에서 특정 AWS 계정에 대한 함수를 나열합니다. 각 AWS 계정 및 계정이 함수를 보유한 각 기전에서 이 명령을 반복해야 합니다. AWS SDK 중 하나를 사용하여 특정 런타임을 사용하는 함수를 나열할 수도 있습니다. 다음 예제 코드는 V3 AWS SDK for JavaScript 및 AWS SDK for Python (Boto3)(을)를 사용하여 특정 런타임을 사용하는 함수의 함수 ARN 목록을 반환합니다. 예제 코드는 나열된 각 함수에 대한 CloudWatch 로그 그룹도 반환합니다. 이 로그 그룹을 사용하여 함수의 마지막 간접 호출 날짜를 찾을 수 있습니다. 자세한 내용은 다음 [가장 자주 간접 호출된 함수와 가장 최근에 간접 호출된 함수 식별하기](#runtimes-list-deprecated-statistics) 단원을 참조하십시오. ------ #### [ Node.js ] **Example 특정 런타임을 사용하여 함수를 나열하는 JavaScript 코드** ``` import { LambdaClient, ListFunctionsCommand } from "@aws-sdk/client-lambda"; const lambdaClient = new LambdaClient(); const command = new ListFunctionsCommand({ FunctionVersion: "ALL", MaxItems: 50 }); const response = await lambdaClient.send(command); for (const f of response.Functions){ if (f.Runtime == ''){ // Use the runtime id, e.g. 'nodejs24.x' or 'python3.14' console.log(f.FunctionArn); // get the CloudWatch log group of the function to // use later for finding the last invocation date console.log(f.LoggingConfig.LogGroup); } } // If your account has more functions than the specified // MaxItems, use the returned pagination token in the // next request with the 'Marker' parameter if ('NextMarker' in response){ let paginationToken = response.NextMarker; } ``` ------ #### [ Python ] **Example 특정 런타임을 사용하여 함수를 나열하는 Python 코드** ``` import boto3 from botocore.exceptions import ClientError def list_lambda_functions(target_runtime): lambda_client = boto3.client('lambda') response = lambda_client.list_functions( FunctionVersion='ALL', MaxItems=50 ) if not response['Functions']: print("No Lambda functions found") else: for function in response['Functions']: if function['PackageType']=='Zip' and function['Runtime'] == target_runtime: print(function['FunctionArn']) # Print the CloudWatch log group of the function # to use later for finding last invocation date print(function['LoggingConfig']['LogGroup']) if 'NextMarker' in response: pagination_token = response['NextMarker'] if __name__ == "__main__": # Replace python3.12 with the appropriate runtime ID for your Lambda functions list_lambda_functions('python3.12') ``` ------ AWS를 사용하여 [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html) 작업으로 함수를 나열하는 방법에 대해 자세히 알아보려면 원하는 프로그래밍 언어에 대한 [SDK 설명서](https://aws.amazon.com/developer/tools/)를 참조하세요. AWS Config 고급 쿼리 기능을 사용하여 영향을 받는 런타임을 사용하는 모든 함수를 나열할 수도 있습니다. 이 쿼리는 함수의 \$1LATEST 버전만 반환하지만, 단일 명령으로 모든 리전과 여러 AWS 계정에서 함수를 나열하도록 쿼리를 집계할 수 있습니다. 자세한 내용은 *AWS Config 개발자 안내서*에서 [Querying the Current Configuration State of AWS Auto Scaling Resources](https://docs.aws.amazon.com/config/latest/developerguide/querying-AWS-resources.html)를 참조하세요. ## 가장 자주 간접 호출된 함수와 가장 최근에 간접 호출된 함수 식별하기 지원이 중단될 예정인 런타임을 사용하는 함수가 AWS 계정에 포함된 경우 자주 간접 호출되는 함수나 최근에 간접 호출된 함수를 우선적으로 업데이트하는 것이 좋습니다. 함수가 적은 경우 CloudWatch Logs 콘솔을 사용하여 함수의 로그 스트림을 살펴봄으로써 이 정보를 수집할 수 있습니다. 자세한 내용은 [CloudWatch Logs로 전송된 로그 데이터 보기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)를 참조하세요. Lambda 콘솔에 표시된 CloudWatch 지표 정보를 사용하여 최근 함수 호출 수를 확인하기 이 정보를 보려면 다음을 수행합니다. 1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다. 1. 호출 통계를 보는 함수를 선택합니다. 1. **모니터링** 탭을 선택합니다. 1. 날짜 범위 선택기를 사용하여 통계를 보려는 기간을 설정합니다. 최근 호출은 **호출** 창에 표시됩니다. 함수 수가 많은 계정의 경우 [DescribeLogStreams](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DescribeLogStreams.html) 및 [GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html) API 작업을 사용하여 AWS CLI 또는 AWS SDK 중 하나를 사용하여 프로그래밍 방식으로 이 데이터를 수집하는 것이 더 효율적일 수 있습니다. 다음 예제에서는 V3 AWS SDK for JavaScript 및 AWS SDK for Python (Boto3)(을)를 사용하여 특정 함수의 마지막 간접 호출 날짜를 식별하고 최근 14일 동안 특정 함수에 대한 간접 호출 수를 확인하는 코드 스니펫을 제공합니다. ------ #### [ Node.js ] **Example 함수의 마지막 호출 시간을 찾는 JavaScript 코드** ``` import { CloudWatchLogsClient, DescribeLogStreamsCommand } from "@aws-sdk/client-cloudwatch-logs"; const cloudWatchLogsClient = new CloudWatchLogsClient(); const command = new DescribeLogStreamsCommand({ logGroupName: '', orderBy: 'LastEventTime', descending: true, limit: 1 }); try { const response = await cloudWatchLogsClient.send(command); const lastEventTimestamp = response.logStreams.length > 0 ? response.logStreams[0].lastEventTimestamp : null; // Convert the UNIX timestamp to a human-readable format for display const date = new Date(lastEventTimestamp).toLocaleDateString(); const time = new Date(lastEventTimestamp).toLocaleTimeString(); console.log(`${date} ${time}`); } catch (e){ console.error('Log group not found.') } ``` ------ #### [ Python ] **Example 함수의 마지막 호출 시간을 찾는 Python 코드** ``` import boto3 from datetime import datetime cloudwatch_logs_client = boto3.client('logs') response = cloudwatch_logs_client.describe_log_streams( logGroupName='', orderBy='LastEventTime', descending=True, limit=1 ) try: if len(response['logStreams']) > 0: last_event_timestamp = response['logStreams'][0]['lastEventTimestamp'] print(datetime.fromtimestamp(last_event_timestamp/1000)) # Convert timestamp from ms to seconds else: last_event_timestamp = None except: print('Log group not found') ``` ------ **작은 정보** [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html) API 작업을 사용하여 함수의 로그 그룹 이름을 찾을 수 있습니다. 이 작업을 수행하는 방법의 예는 [특정 런타임을 사용하는 함수 버전 목록](#runtimes-list-deprecated-versions)을(를) 참조하세요. ------ #### [ Node.js ] **Example 최근 14일간의 호출 횟수를 찾기 위한 JavaScript 코드** ``` import { CloudWatchClient, GetMetricStatisticsCommand } from "@aws-sdk/client-cloudwatch"; const cloudWatchClient = new CloudWatchClient(); const command = new GetMetricStatisticsCommand({ Namespace: 'AWS/Lambda', MetricName: 'Invocations', StartTime: new Date(Date.now()-86400*1000*14), // 14 days ago EndTime: new Date(Date.now()), Period: 86400 * 14, // 14 days. Statistics: ['Sum'], Dimensions: [{ Name: 'FunctionName', Value: '' }] }); const response = await cloudWatchClient.send(command); const invokesInLast14Days = response.Datapoints.length > 0 ? response.Datapoints[0].Sum : 0; console.log('Number of invocations: ' + invokesInLast14Days); ``` ------ #### [ Python ] **Example 최근 14일간의 호출 횟수를 찾기 위한 Python 코드** ``` import boto3 from datetime import datetime, timedelta cloudwatch_client = boto3.client('cloudwatch') response = cloudwatch_client.get_metric_statistics( Namespace='AWS/Lambda', MetricName='Invocations', Dimensions=[ { 'Name': 'FunctionName', 'Value': '' }, ], StartTime=datetime.now() - timedelta(days=14), EndTime=datetime.now(), Period=86400 * 14, # 14 days Statistics=[ 'Sum' ] ) if len(response['Datapoints']) > 0: invokes_in_last_14_days = int(response['Datapoints'][0]['Sum']) else: invokes_in_last_14_days = 0 print(f'Number of invocations: {invokes_in_last_14_days}') ``` ------ # 런타임 환경 수정 [내부 익스텐션](lambda-extensions.md)을 사용하여 런타임 프로세스를 수정할 수 있습니다. 내부 익스텐션은 별도의 프로세스가 아니라 런타임 프로세스의 일부로 실행됩니다. Lambda는 런타임에 옵션과 도구를 추가하도록 설정할 수 있는 언어별 [환경 변수](configuration-envvars.md)를 제공합니다. Lambda는 또한 Lambda가 런타임 시작 동작을 스크립트에 위임할 수 있도록 [래퍼 스크립트](#runtime-wrapper)를 제공합니다. 래퍼 스크립트를 생성하여 런타임 시작 동작을 사용자 지정할 수 있습니다. ## 언어별 환경 변수 Lambda는 다음 언어별 환경 변수를 통해 함수 초기화 중에 코드를 미리 로드할 수 있는 구성 전용 방법을 지원합니다. + `JAVA_TOOL_OPTIONS` – Java에서 Lambda는 Lambda에서 추가 명령줄 변수를 설정할 수 있도록 이 환경 변수를 지원합니다. 이 환경 변수를 사용하면 `agentlib` 또는 `javaagent` 옵션을 사용하여 네이티브 또는 Java 프로그래밍 언어 에이전트를 시작하는 것을 포함하여 도구의 초기화를 지정할 수 있습니다. 자세한 내용은 [`JAVA_TOOL_OPTIONS` 환경 변수](https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html#java-tool-options)를 참조하세요. + `NODE_OPTIONS` - [Node.js 런타임](lambda-nodejs.md)에서 사용할 수 있습니다. + `DOTNET_STARTUP_HOOKS` – .NET Core 3.1 이상에서 이 환경 변수는 Lambda가 사용할 수 있는 어셈블리(dll)에 대한 경로를 지정합니다. 언어별 환경 변수를 사용하는 것이 시작 속성을 설정하는 권장 방법입니다. ## 래퍼 스크립트 *래퍼 스크립트*를 생성하여 Lambda 함수의 런타임 시작 동작을 사용자 지정할 수 있습니다. 래퍼 스크립트를 사용하면 언어별 환경 변수를 통해 설정할 수 없는 구성 파라미터를 설정할 수 있습니다. **참고** 래퍼 스크립트가 런타임 프로세스를 성공적으로 시작하지 않으면 호출이 실패할 수 있습니다. 래퍼 스크립트는 모든 네이티브 [Lambda 런타임](lambda-runtimes.md)에서 지원됩니다. 래퍼 스크립트는 [OS 전용 런타임](runtimes-provided.md)(`provided` 런타임 제품군)에서 지원되지 않습니다. 함수에 래퍼 스크립트를 사용하면 Lambda Lambda는 스크립트를 사용하여 런타임을 시작합니다. Lambda는 표준 런타임 시작을 위해 인터프리터 경로와 모든 원본 인수를 스크립트에 보냅니다. 스크립트는 프로그램의 시작 동작을 확장하거나 변형할 수 있습니다. 예를 들어 스크립트는 인수를 삽입 및 변경하거나, 환경 변수를 설정하거나, 지표, 오류 및 기타 진단 정보를 캡처할 수 있습니다. 스크립트를 지정하려면 `AWS_LAMBDA_EXEC_WRAPPER` 환경 변수의 값을 실행 바이너리 또는 스크립트의 파일 시스템 경로로 설정합니다. ### 예제: 래퍼 스크립트를 생성하고 Lambda 계층으로 사용 다음 예제에서는 `-X importtime` 옵션을 사용하여 Python 인터프리터를 시작하는 래퍼 스크립트를 생성합니다. 함수를 실행하면 Lambda가 각 가져오기에 소요된 기간을 표시하는 로그 항목을 생성합니다. **래퍼 스크립트를 생성하여 계층으로 사용하는 방법** 1. 계층에 대한 디렉터리를 생성하세요. ``` mkdir -p python-wrapper-layer/bin cd python-wrapper-layer/bin ``` 1. `bin` 디렉터리에서 다음 코드를 `importtime_wrapper`라는 새 파일에 붙여넣으세요. 이는 래퍼 스크립트입니다. ``` #!/bin/bash # the path to the interpreter and all of the originally intended arguments args=("$@") # the extra options to pass to the interpreter extra_args=("-X" "importtime") # insert the extra options args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}") # start the runtime with the extra options exec "${args[@]}" ``` 1. 스크립트에 실행 권한을 제공하세요. ``` chmod +x importtime_wrapper ``` 1. 계층에 대한 .zip 파일을 생성하세요. ``` cd .. zip -r ../python-wrapper-layer.zip . ``` 1. .zip 파일에 다음 디렉터리 구조가 있는지 확인하세요. ``` python-wrapper-layer.zip └ bin └ importtime_wrapper ``` 1. .zip 패키지를 사용하여 [계층을 생성](creating-deleting-layers.md#layers-create)하세요. 1. Lambda 콘솔을 사용하여 함수를 생성합니다. 1. [Lambda 콘솔](https://console.aws.amazon.com/lambda)을 엽니다. 1. **함수 생성(Create function)**을 선택합니다. 1. **Function name**(함수 이름)을 입력합니다. 1. **런타임**에서 **지원되는 최신** Python 런타임을 선택하세요. 1. **함수 생성(Create function)**을 선택합니다. 1. 함수에 계층을 추가합니다. 1. 함수를 선택하고 **코드** 탭을 아직 선택하지 않은 경우 선택하세요. 1. 아래로 스크롤하여 **계층** 섹션으로 이동하고 **계층 추가**를 선택하세요. 1. **계층 소스**에서 **사용자 지정 계층**을 선택하고 **사용자 지정 계층** 드롭다운 목록에서 계층을 선택하세요. 1. **버전**에서 **1**을 선택합니다. 1. **추가**를 선택합니다. 1. 래퍼 환경 변수를 추가하세요. 1. **구성** 탭을 선택하고 **환경 변수**를 선택하세요. 1. **Environment variables(환경 변수)**에서 **편집**을 선택합니다. 1. **Add environment variable(환경 변수 추가)**을 선택합니다. 1. **키(Key)**에 `AWS_LAMBDA_EXEC_WRAPPER`를 입력합니다. 1. **값**에 `/opt/bin/importtime_wrapper`(`/opt/` \$1 .zip 계층의 폴더 구조)를 입력하세요. 1. **Save**(저장)를 선택합니다. 1. 래퍼 스크립트를 테스트하세요. 1. **테스트** 탭을 선택합니다. 1. **테스트 이벤트**에서 **테스트**를 선택하세요. 테스트 이벤트를 생성하지 않아도 됩니다. 기본 이벤트로도 충분합니다. 1. 아래로 스크롤하여 **로그 출력**으로 이동하세요. 래퍼 스크립트가 `-X importtime` 옵션을 사용하여 Python 인터프리터를 시작했기 때문에 로그에는 각 가져오기에 필요한 시간이 표시됩니다. 예: ``` 532 | collections import time: 63 | 63 | _functools import time: 1053 | 3646 | functools import time: 2163 | 7499 | enum import time: 100 | 100 | _sre import time: 446 | 446 | re._constants import time: 691 | 1136 | re._parser import time: 378 | 378 | re._casefix import time: 670 | 2283 | re._compiler import time: 416 | 416 | copyreg ``` # 사용자 지정 런타임을 위한 Lambda 런타임 API 사용 AWS Lambda은 [사용자 지정 런타임](runtimes-custom.md)에 HTTP API를 제공하여 Lambda에서 호출 이벤트를 수신하고 Lambda [실행 환경](lambda-runtimes.md) 내에서 응답 데이터를 다시 전송합니다. 이 섹션에서는 Lambda 런타임 API에 대한 API 참조에 대해 알아봅니다. **Lambda 관리형 인스턴스 동시 요청 지원** Lambda 관리형 인스턴스는 Lambda(기본값) 함수와 동일한 런타임 API를 사용합니다. 큰 차이점은 관리형 인스턴스가 구성된 `AWS_LAMBDA_MAX_CONCURRENCY` 제한까지 동시 `/next` 및 `/response` 요청을 수락할 수 있다는 것입니다. 이를 통해 단일 실행 환경 내에서 여러 개의 간접 호출을 동시에 처리할 수 있습니다. 관리형 인스턴스에 대한 자세한 내용은 [Lambda 관리형 인스턴스 실행 환경 이해](lambda-managed-instances-execution-environment.md) 항목을 참조하세요. ![\[실행 환경의 아키텍처 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/telemetry-api-concept-diagram.png) 런타임 API 버전 **2018-06-01**에 대한 OpenAPI 사양은 [runtime-api.zip](samples/runtime-api.zip)에서 사용할 수 있습니다. API 요청 URL을 만들려면 런타임에서 `AWS_LAMBDA_RUNTIME_API` 환경 변수에서 API 엔드포인트를 가져오고 API 버전을 추가한 다음 원하는 리소스 경로를 추가합니다. **Example 요청** ``` curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next" ``` **Topics** + [다음 호출](#runtimes-api-next) + [호출 응답](#runtimes-api-response) + [초기화 오류](#runtimes-api-initerror) + [호출 오류](#runtimes-api-invokeerror) ## 다음 호출 **경로** – `/runtime/invocation/next` **메서드** – **GET** 런타임에서는 호출 이벤트를 요청하기 위해 이 메시지를 Lambda로 보냅니다. 응답 본문에는 호출의 페이로드가 포함되어 있습니다. 이 페이로드는 함수 트리거의 이벤트 데이터를 포함하는 JSON 문서입니다. 응답 헤더에는 호출에 대한 추가 데이터가 포함되어 있습니다. **응답 헤더** + `Lambda-Runtime-Aws-Request-Id` – 함수 호출을 트리거한 요청을 식별하는 요청 ID입니다. 예를 들어 `8476a536-e9f4-11e8-9739-2dfe598c3fcd`입니다. + `Lambda-Runtime-Deadline-Ms` – 함수가 Unix 시간 형식에 따른 밀리초 단위의 시간 제한에 도달하는 날짜입니다. 예를 들어 `1542409706888`입니다. + `Lambda-Runtime-Invoked-Function-Arn` – 호출에 지정된 Lambda 함수, 버전 또는 별칭의 ARN입니다. 예를 들어 `arn:aws:lambda:us-east-2:123456789012:function:custom-runtime`입니다. + `Lambda-Runtime-Trace-Id` – [AWS X-Ray 추적 헤더](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader)입니다. 예를 들어 `Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1`입니다. + `Lambda-Runtime-Client-Context` – AWS Mobile SDK 호출에서 클라이언트 애플리케이션 및 디바이스에 관한 데이터입니다. + `Lambda-Runtime-Cognito-Identity` – AWS Mobile SDK 호출에서 Amazon Cognito 자격 증명 공급자에 관한 데이터입니다. 응답이 지연될 수 있으므로 `GET` 요청에 시간 제한을 설정하지 마세요. Lambda가 런타임을 부트스트랩하는 시점과 런타임에 반환할 이벤트가 있는 시점 사이에 런타임 프로세스가 몇 초 동안 동결될 수 있습니다. 요청 ID는 Lambda 내에서 호출을 추적합니다. 응답을 전송할 때에는 이 ID를 사용하여 호출을 지정합니다. 트레이스 헤더에는 추적 ID, 상위 ID 및 샘플링 결정이 포함되어 있습니다. 요청이 샘플링될 경우, 이 요청은 Lambda 또는 업스트림 서비스에 의해 샘플링된 것입니다. 런타임은 헤더의 값을 사용해 `_X_AMZN_TRACE_ID`을 설정해야 합니다. X-Ray SDK는 이 값을 판독하여 ID를 가져온 다음, 요청을 추적할지 여부를 결정합니다. ## 호출 응답 **경로** – `/runtime/invocation/AwsRequestId/response` **메서드** – **POST** 함수가 완료될 때까지 실행되면 런타임은 호출 응답을 Lambda로 보냅니다. 동기식 간접 호출의 경우, Lambda는 응답을 클라이언트로 보냅니다. **Example 성공 요청** ``` REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9 curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS" ``` ## 초기화 오류 함수가 오류를 반환하거나 런타임에서 초기화 중에 오류가 발생하면 런타임에서는 이 메서드를 사용하여 Lambda에 오류를 보고합니다. **경로** – `/runtime/init/error` **메서드** – **POST** **헤더** `Lambda-Runtime-Function-Error-Type` – 런타임에서 발생한 오류 유형입니다. 필수 항목 여부: 아니요 이 헤더는 문자열 값으로 구성됩니다. Lambda는 모든 문자열을 허용하지만 형식을 사용하는 것이 좋습니다. 예: + Runtime.NoSuchHandler + Runtime.APIKeyNotFound + Runtime.ConfigInvalid + Runtime.UnknownReason **본문 파라미터** `ErrorRequest` – 오류에 대한 정보입니다. 필수 항목 여부: 아니요 이 필드는 다음과 같은 구조의 JSON 객체입니다. ``` { errorMessage: string (text description of the error), errorType: string, stackTrace: array of strings } ``` Lambda는 `errorType`에 대한 모든 값을 허용합니다. 다음 예제에서는 Lambda 함수가 호출에 제공된 이벤트 데이터를 구문 분석할 수 없는 함수 오류 메시지를 보여 줍니다. **Example 함수 오류** ``` { "errorMessage" : "Error parsing event data.", "errorType" : "InvalidEventDataException", "stackTrace": [ ] } ``` **응답 본문 파라미터** + `StatusResponse` – 문자열. 상태 정보, 202 응답 코드와 함께 전송됨. + `ErrorResponse` – 오류 응답 코드와 함께 전송되는 추가 오류 정보입니다. ErrorResponse는 오류 유형과 오류 메시지가 포함되어 있습니다. **응답 코드** + 202 - 수락됨 + 403 - 금지됨 + 500 - 컨테이너 오류. 복구 불능 상태입니다. 런타임을 신속히 종료해야 합니다. **Example 초기화 오류 요청** ``` ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}" curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled" ``` ## 호출 오류 함수가 오류를 반환하거나 런타임에 오류가 발생하면 런타임에서는 이 메서드를 사용하여 오류를 Lambda에 보고합니다. **경로** – `/runtime/invocation/AwsRequestId/error` **메서드** – **POST** **헤더** `Lambda-Runtime-Function-Error-Type` – 런타임에서 발생한 오류 유형입니다. 필수 항목 여부: 아니요 이 헤더는 문자열 값으로 구성됩니다. Lambda는 모든 문자열을 허용하지만 형식을 사용하는 것이 좋습니다. 예: + Runtime.NoSuchHandler + Runtime.APIKeyNotFound + Runtime.ConfigInvalid + Runtime.UnknownReason **본문 파라미터** `ErrorRequest` – 오류에 대한 정보입니다. 필수 항목 여부: 아니요 이 필드는 다음과 같은 구조의 JSON 객체입니다. ``` { errorMessage: string (text description of the error), errorType: string, stackTrace: array of strings } ``` Lambda는 `errorType`에 대한 모든 값을 허용합니다. 다음 예제에서는 Lambda 함수가 호출에 제공된 이벤트 데이터를 구문 분석할 수 없는 함수 오류 메시지를 보여 줍니다. **Example 함수 오류** ``` { "errorMessage" : "Error parsing event data.", "errorType" : "InvalidEventDataException", "stackTrace": [ ] } ``` **응답 본문 파라미터** + `StatusResponse` – 문자열. 상태 정보, 202 응답 코드와 함께 전송됨. + `ErrorResponse` – 오류 응답 코드와 함께 전송되는 추가 오류 정보입니다. ErrorResponse는 오류 유형과 오류 메시지가 포함되어 있습니다. **응답 코드** + 202 - 수락됨 + 400 - 잘못된 요청 + 403 - 금지됨 + 500 - 컨테이너 오류. 복구 불능 상태입니다. 런타임을 신속히 종료해야 합니다. **Example 오류 요청** ``` REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9 ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}" curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled" ``` # Lambda의 OS 전용 런타임을 사용해야 하는 경우 Lambda는 Java, Python, Node.js, .NET 및 Ruby에 대한 [관리형 런타임](lambda-runtimes.md)을 제공합니다. 관리형 런타임으로 사용할 수 없는 프로그래밍 언어로 Lambda 함수를 생성하려면 OS 전용 런타임(`provided` 런타임 제품군)을 사용합니다. OS 전용 런타임에는 세 가지 기본 사용 사례가 있습니다. + **Native Ahead-of-Time(AOT) 컴파일**: Go, Rust, Swift, C\$1\$1와 같은 언어는 기본적으로 실행 가능한 바이너리로 컴파일되므로 전용 언어 런타임이 필요하지 않습니다. 이러한 언어에는 컴파일된 바이너리를 실행할 수 있는 OS 환경만 필요합니다. 또한 Lambda OS 전용 런타임을 사용하여 .NET Native AOT 및 Java GraalVM Native Image로 컴파일된 바이너리를 배포할 수 있습니다. 바이너리에 런타임 인터페이스 클라이언트를 포함해야 합니다. 런타임 인터페이스 클라이언트는 [사용자 지정 런타임을 위한 Lambda 런타임 API 사용](runtimes-api.md)를 직접 호출하여 함수 간접 호출을 검색한 후 함수 핸들러를 직접 호출합니다. Lambda는 [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime)(실험 단계), [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp)(실험 단계)에 대한 런타임 인터페이스 클라이언트를 제공합니다. Linux 환경 및 함수에 사용하려는 것과 동일한 명령 세트 아키텍처(x86\$164 또는 arm64)에 맞게 바이너리를 컴파일해야 합니다. + **타사 런타임**: PHP용 [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2)와 같은 상용 런타임을 사용하여 Lambda 함수를 실행할 수 있습니다. + **사용자 지정 런타임**: Lambda가 관리형 런타임을 제공하지 않는 언어 또는 언어 버전에 대한 자체 런타임을 구축할 수 있습니다(예: Node.js 19). 자세한 내용은 [AWS Lambda에 대한 사용자 지정 런타임 빌드](runtimes-custom.md) 섹션을 참조하세요. 이는 OS 전용 런타임의 경우 가장 흔하지 않은 사용 사례입니다. Lambda는 다음과 같은 OS 전용 런타임을 지원합니다. | 이름 | 식별자 | 운영 체제 | 사용 중단 날짜 | 블록 함수 생성 | 블록 함수 업데이트 | | --- | --- | --- | --- | --- | --- | | OS 전용 런타임 | `provided.al2023` | Amazon Linux 2023 | 2029년 6월 30일 | 2029년 7월 31일 | 2029년 8월 31일 | | OS 전용 런타임 | `provided.al2` | Amazon Linux 2 | 2026년 7월 31일 | 2026년 8월 31일 | 2026년 9월 30일 | Amazon Linux 2023(`provided.al2023`) 런타임은 작은 배포 공간과 `glibc`와 같이 업데이트된 라이브러리 버전을 포함하여 Amazon Linux 2에 비해 여러 가지 이점을 제공합니다. `provided.al2023` 런타임은 Amazon Linux 2의 기본 패키지 관리자인 `yum` 대신 `dnf`를 패키지 관리자로 사용합니다. `provided.al2023` 및 `provided.al2` 간의 차이점에 대한 자세한 내용은 [AWS Lambda을 위한 Amazon Linux 2023 런타임 소개](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/)를 AWS Compute 블로그에서 참조하십시오. # AWS Lambda에 대한 사용자 지정 런타임 빌드 AWS Lambda 런타임은 모든 프로그래밍 언어로 구현할 수 있습니다. 런타임은 함수가 간접 호출될 때 Lambda 함수의 핸들러 메서드를 실행하는 프로그램입니다. 런타임은 함수의 배포 패키지 또는 [계층](chapter-layers.md)에 포함될 수 있습니다. Lambda 함수를 생성할 때 [OS 전용 런타임](runtimes-provided.md)(`provided` 런타임 제품군)을 선택합니다. **참고** 사용자 지정 런타임을 생성하는 작업은 고급 사용 사례입니다. 네이티브 바이너리로 컴파일하거나 타사 상용 런타임을 사용하는 방법에 대한 자세한 내용은 [Lambda의 OS 전용 런타임을 사용해야 하는 경우](runtimes-provided.md) 섹션을 참조하세요. 사용자 지정 런타임 배포 프로세스에 대한 자세한 내용은 [자습서: 사용자 지정 런타임 빌드](runtimes-walkthrough.md) 섹션을 참조하세요. **Topics** + [요구 사항](#runtimes-custom-build) + [사용자 지정 런타임에서 응답 스트리밍 구현](#runtimes-custom-response-streaming) + [Lambda 관리형 인스턴스에 대한 사용자 지정 런타임 빌드](#runtimes-custom-managed-instances) ## 요구 사항 사용자 지정 런타임에서는 특정 초기화 및 처리 작업을 완료해야 합니다. 런타임은 함수의 설정 코드를 실행하고, 환경 변수에서 핸들러 이름을 읽고, Lambda 런타임 API에서 호출 이벤트를 읽습니다. 런타임은 이벤트 데이터를 함수 핸들러에 전달하고 핸들러의 응답을 Lambda에 다시 게시합니다. ### 초기화 작업 초기화 작업은 [함수의 인스턴스당](lambda-runtime-environment.md) 한 번씩 실행되어 호출을 처리할 수 있는 환경을 준비합니다. + **설정 검색** – 환경 변수를 읽어 함수 및 환경에 관한 세부 정보를 확인합니다. + `_HANDLER` – 함수의 구성에서 핸들러에 대한 위치입니다. 표준 형식은 `file.method`이며, 여기서 `file`은 확장명이 없는 파일의 이름이고 `method`는 파일에 정의된 메서드 또는 함수의 이름입니다. + `LAMBDA_TASK_ROOT` – 함수 코드가 포함된 디렉터리입니다. + `AWS_LAMBDA_RUNTIME_API` – 런타임 API의 호스트 및 포트입니다. 사용 가능한 변수의 전체 목록은 [정의된 런타임 환경 변수](configuration-envvars.md#configuration-envvars-runtime) 섹션을 참조하세요. + **함수 초기화** – 핸들러 파일을 로드하고 이 파일에 포함된 전역적 또는 정적 코드를 실행합니다. 함수는 SDK 클라이언트 및 데이터베이스 연결과 같은 정적 리소스를 한 번 생성해야 하며, 다중 호출 시 그러한 리소스를 다시 사용해야 합니다. + **오류 처리** – 오류가 발생하면 [초기화 오류](runtimes-api.md#runtimes-api-initerror) API를 호출하고 즉시 종료하세요. 초기화 횟수는 청구 대상인 실행 시간 및 시간 초과에 반영됩니다. 실행으로 인해 새 함수 인스턴스의 초기화가 트리거되면 로그 및 [AWS X-Ray 추적](services-xray.md)에서 초기화 시간을 볼 수 있습니다. **Example log** ``` REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB ``` ### 작업 처리 런타임은 실행 중에 [Lambda 런타임 인터페이스](runtimes-api.md)를 사용하여 수신 이벤트를 관리하고 오류를 보고합니다. 초기화 작업을 완료한 후, 런타임은 수신 이벤트를 루프에서 처리합니다. 런타임 코드에서 다음 단계를 순서대로 수행합니다. + **이벤트 가져오기** – 다음 이벤트를 가져오려면 다음 [호출](runtimes-api.md#runtimes-api-next) API를 호출합니다. 응답 본문에는 이벤트 데이터가 포함됩니다. 응답 헤더에는 요청 ID 및 기타 정보가 포함됩니다. + **트레이스 헤더 전파** – API 응답의 `Lambda-Runtime-Trace-Id` 헤더에서 X-Ray 트레이스 헤더를 가져옵니다. `_X_AMZN_TRACE_ID` 환경 변수를 동일한 값으로 로컬로 설정합니다. X-Ray SDK는 이 값을 사용하여 서비스 간에 추적 데이터를 연결합니다. + **컨텍스트 객체 생성** – API 응답에서 환경 변수 및 헤더의 컨텍스트 정보를 사용하여 객체를 생성합니다. + **함수 핸들러 간접 호출** – 이벤트 및 컨텍스트 객체를 핸들러에 전달합니다. + **응답 처리** – [호출 응답](runtimes-api.md#runtimes-api-response) API를 호출하여 핸들러의 응답을 게시합니다. + **오류 처리** – 오류가 발생하면 [호출 오류](runtimes-api.md#runtimes-api-invokeerror) API를 호출합니다. + **정리** – 사용하지 않은 리소스를 릴리스하거나 다른 서비스로 데이터를 전송하거나 혹은 다음 이벤트를 가져오기 전에 추가 작업을 수행하세요. ### 진입점 사용자 지정 런타임의 진입점은 `bootstrap`이라는 이름의 실행 파일입니다. 부트스트랩 파일은 런타임일 수 있으며 혹은 런타임을 생성하는 다른 파일을 간접 호출할 수도 있습니다. 배포 패키지의 루트에 `bootstrap` 파일이 없는 경우 Lambda는 함수 계층에서 파일을 찾습니다. `bootstrap` 파일이 없거나 실행할 수 없는 경우, 함수는 간접 호출 시 `Runtime.InvalidEntrypoint` 오류를 반환합니다. 다음은 번들 버전의 Node.js를 사용하여 별도의 `runtime.js` 파일에서 JavaScript 런타임을 실행하는 `bootstrap` 파일 예제입니다. **Example 부트스트랩** ``` #!/bin/sh cd $LAMBDA_TASK_ROOT ./node-v11.1.0-linux-x64/bin/node runtime.js ``` ## 사용자 지정 런타임에서 응답 스트리밍 구현 [응답 스트리밍 함수](configuration-response-streaming.md)의 경우, 런타임이 클라이언트에 부분 응답을 스트리밍하고 페이로드를 청크 단위로 반환할 수 있도록 `response` 및 `error` 엔드포인트의 동작이 약간 수정되었습니다. 특정 동작에 대한 자세한 내용은 다음 섹션을 참조하세요. + `/runtime/invocation/AwsRequestId/response` - 런타임에서 `Content-Type` 헤더를 전파하여 클라이언트로 전송합니다. Lambda는 HTTP/1.1 청크 분할 전송 인코딩을 통해 응답 페이로드를 청크로 반환합니다. Lambda로 응답을 스트리밍하려면 런타임에서 다음을 수행해야 합니다. + `Lambda-Runtime-Function-Response-Mode` HTTP 헤더를 `streaming`로 설정합니다. + `Transfer-Encoding` 헤더를 `chunked`로 설정합니다. + HTTP/1.1 청크 분할 전송 인코딩 사양을 준수하는 응답을 작성합니다. + 응답을 성공적으로 작성한 후 기본 연결을 닫습니다. + `/runtime/invocation/AwsRequestId/error` - 이 런타임은 이 엔드포인트를 사용하여 `Transfer-Encoding` 헤더도 허용하는 Lambda에 함수 또는 런타임 오류를 보고할 수 있습니다. 이 엔드포인트는 런타임이 호출 응답 전송을 시작하기 전에만 호출할 수 있습니다. + `/runtime/invocation/AwsRequestId/response`의 오류 트레일러를 사용하여 미드스트림 오류 보고 – 이 런타임은 호출 응답 작성을 시작한 후 발생하는 오류를 보고하기 위해 선택적으로 `Lambda-Runtime-Function-Error-Type` 및 `Lambda-Runtime-Function-Error-Body`라는 HTTP 후행 헤더를 연결할 수 있습니다. Lambda는 이를 성공적인 응답으로 간주하고 런타임이 클라이언트에 제공하는 오류 메타데이터를 전달합니다. **참고** 후행 헤더를 첨부하려면 런타임이 HTTP 요청 시작 시 `Trailer` 헤더 값을 설정해야 합니다. 이는 HTTP/1.1 청크 분할 전송 인코딩 사양의 요구 사항입니다. + `Lambda-Runtime-Function-Error-Type` – 런타임에서 발생한 오류 유형입니다. 이 헤더는 문자열 값으로 구성됩니다. Lambda는 모든 문자열을 허용하지만 ** 형식을 사용하는 것이 좋습니다. 예를 들어 `Runtime.APIKeyNotFound`입니다. + `Lambda-Runtime-Function-Error-Body` - 오류에 대한 base64로 인코딩된 정보입니다. ## Lambda 관리형 인스턴스에 대한 사용자 지정 런타임 빌드 Lambda 관리형 인스턴스는 Lambda(기본값) 함수와 동일한 런타임 API를 사용합니다. 하지만 관리형 인스턴스의 동시 실행 모델을 지원하기 위해 사용자 지정 런타임을 구현하는 방법에는 큰 차이점이 있습니다. ### 동시 요청 처리 관리형 인스턴스에 대한 사용자 지정 런타임을 빌드할 때의 주된 차이점은 동시 간접 호출 지원입니다. 런타임이 한 번에 하나의 간접 호출을 처리하는 Lambda(기본값) 함수와 달리 관리형 인스턴스는 단일 실행 환경 내에서 여러 개의 간접 호출을 동시에 처리할 수 있습니다. 사용자 지정 런타임은 다음 사항을 충족해야 합니다. + **동시 `/next` 요청 지원** - 런타임은 `AWS_LAMBDA_MAX_CONCURRENCY` 환경 변수에 지정된 제한까지 [다음 간접 호출](runtimes-api.md#runtimes-api-next) API를 여러 번 동시에 호출할 수 있습니다. + **동시 `/response` 요청 처리** - 여러 개의 간접 호출이 [간접 호출 응답](runtimes-api.md#runtimes-api-response) API를 동시에 호출할 수 있습니다. + **스레드 안전 요청 처리 구현** - 공유 리소스 및 상태를 적절하게 관리하여 동시 간접 호출이 서로 방해가 되지 않도록 해야 합니다. + **고유한 요청 ID 사용** - `Lambda-Runtime-Aws-Request-Id` 헤더를 사용하여 각 간접 호출을 개별적으로 추적하여 응답을 해당 요청과 일치시킵니다. ### 구현 패턴 관리형 인스턴스 런타임의 일반적인 구현 패턴에는 동시 간접 호출을 처리하기 위한 작업자 스레드 또는 프로세스 생성이 포함됩니다. 1. **동시성 제한 읽기** - 초기화 시 `AWS_LAMBDA_MAX_CONCURRENCY` 환경 변수를 읽고 지원할 동시 간접 호출 수를 결정합니다. 1. **작업자 풀 생성** - 동시성 제한과 같은 작업자 풀(스레드, 프로세스 또는 비동기식 태스크)을 초기화합니다. 1. **작업자 처리 루프** - 각 작업자가 독립적으로 수행하는 작업: + `/runtime/invocation/next` 직접 호출로 간접 호출 이벤트 가져오기 + 이벤트 데이터로 함수 핸들러 간접 호출 + `/runtime/invocation/AwsRequestId/response`에 응답 게시 + 루프 반복 ### 추가 고려 사항 + **로깅 형식** - 관리형 인스턴스는 JSON 로그 형식만 지원합니다. 런타임에서 `AWS_LAMBDA_LOG_FORMAT` 환경 변수를 준수하고 JSON 형식만 사용해야 합니다. 자세한 내용은 [JSON 및 일반 텍스트 로그 형식 구성](monitoring-cloudwatchlogs-logformat.md) 섹션을 참조하세요. + **공유 리소스** - `/tmp` 디렉터리와 같은 공유 리소스를 동시 간접 호출에서 사용할 때는 주의해야 합니다. 경합 상황을 방지하기 위해 적절한 잠금 메커니즘을 구현해야 합니다. Lambda 관리형 인스턴스 실행 환경에 대한 자세한 내용은 [Lambda 관리형 인스턴스 실행 환경 이해](lambda-managed-instances-execution-environment.md) 항목을 참조하세요. # 자습서: 사용자 지정 런타임 빌드 이 자습서에서는 사용자 지정 런타임이 있는 Lambda 함수를 생성합니다. 먼저 함수의 배포 패키지에 런타임을 포함시킵니다. 그런 다음, 이 런타임을 함수와는 별도로 관리하는 계층으로 마이그레이션합니다. 마지막으로 리소스 기반 권한 정책을 업데이트하여 런타임 계층을 다른 모든 사용자와 공유합니다. ## 사전 조건 이 자습서에서는 사용자가 기본 Lambda 작업과 Lambda 콘솔에 대해 어느 정도 알고 있다고 가정합니다. 그렇지 않은 경우 [콘솔로 Lambda 함수 생성](getting-started.md#getting-started-create-function)의 지침에 따라 첫 Lambda 함수를 생성합니다. 다음 단계를 완료하려면 [AWS CLI 버전 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)가 필요합니다. 명령과 예상 결과는 별도의 블록에 나열됩니다. ``` aws --version ``` 다음 결과가 표시됩니다. ``` aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2 ``` 긴 명령의 경우 이스케이프 문자(`\`)를 사용하여 명령을 여러 행으로 분할합니다. Linux 및 macOS는 선호 셸과 패키지 관리자를 사용합니다. **참고** Windows에서는 Lambda와 함께 일반적으로 사용하는 일부 Bash CLI 명령(예:`zip`)은 운영 체제의 기본 제공 터미널에서 지원되지 않습니다. Ubuntu와 Bash의 Windows 통합 버전을 가져오려면 [Linux용 Windows Subsystem을 설치](https://docs.microsoft.com/en-us/windows/wsl/install-win10)합니다. 이 안내서의 예제 CLI 명령은 Linux 형식을 사용합니다. Windows CLI를 사용하는 경우 인라인 JSON 문서를 포함하는 명령의 형식을 다시 지정해야 합니다. Lambda 함수를 생성하려면 IAM 역할이 필요합니다. 이 역할에는 로그를 CloudWatch Logs로 전송하는 권한과 함수에서 사용하는 AWS 서비스에 액세스하는 권한이 필요합니다. 함수 개발을 위한 역할이 없는 경우 이 역할을 하나 생성합니다. **실행 역할을 만들려면** 1. IAM 콘솔에서 [역할 페이지](https://console.aws.amazon.com/iam/home#/roles)를 엽니다. 1. **역할 생성**을 선택합니다. 1. 다음 속성을 사용하여 역할을 만듭니다. + **신뢰할 수 있는 엔터티** – **Lambda**. + **권한** – **AWSLambdaBasicExecutionRole**. + **역할 이름** – **lambda-role**. **AWSLambdaBasicExecutionRole** 정책은 함수가 CloudWatch Logs에 로그를 쓰는 데 필요한 권한을 가집니다. ## 함수 생성 사용자 지정 런타임이 있는 Lambda 함수를 생성합니다. 이 예제는 두 개의 파일 즉, 런타임 `bootstrap` 파일과 함수 핸들러를 포함합니다. 두 파일은 모두 Bash에서 구현됩니다. 1. 프로젝트에 대한 디렉터리를 생성하고 해당 디렉터리로 전환합니다. ``` mkdir runtime-tutorial cd runtime-tutorial ``` 1. `bootstrap`라는 파일을 새로 생성합니다. 사용자 지정 런타임입니다. **Example 부트스트랩** ``` #!/bin/sh set -euo pipefail # Initialization - load function handler source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh" # Processing while true do HEADERS="$(mktemp)" # Get an event. The HTTP request will block until one is received EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next") # Extract request ID by scraping response headers received above REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2) # Run the handler function from the script RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA") # Send the response curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE" done ``` 런타임은 배포 패키지에서 함수 스크립트를 로드합니다. 런타임은 두 변수를 사용하여 스크립트를 찾습니다. `LAMBDA_TASK_ROOT`는 패키지가 추출된 위치를 알려주며 `_HANDLER`에는 스크립트의 이름이 포함됩니다. 런타임은 함수 스크립트를 로딩한 후 런타임 API를 사용하여 Lambda에서 간접 호출 이벤트를 검색하고 이벤트를 핸들러로 전달하며 응답을 Lambda에 다시 게시합니다. 요청 ID를 가져오기 위해 런타임은 API 응답의 헤더를 임시 파일에 저장하고 이 파일에서 `Lambda-Runtime-Aws-Request-Id` 헤더를 읽습니다. **참고** 런타임은 오류 처리를 포함한 추가적인 책임이 있으며, 핸들러에 컨텍스트 정보를 제공합니다. 세부 정보는 [요구 사항](runtimes-custom.md#runtimes-custom-build)을 참조하세요. 1. 함수에 대해 스크립트를 생성합니다. 다음 스크립트 예는 이벤트 데이터를 취하여 이를 `stderr`에 기록한 후 반환하는 핸들러 함수를 정의합니다. **Example function.sh** ``` function handler () { EVENT_DATA=$1 echo "$EVENT_DATA" 1>&2; RESPONSE="Echoing request: '$EVENT_DATA'" echo $RESPONSE } ``` `runtime-tutorial` 디렉터리는 이제 다음과 같아야 합니다. ``` runtime-tutorial ├ bootstrap └ function.sh ``` 1. 실행 파일들을 생성하여 이를 .zip 파일 아카이브에 추가합니다. 이것이 배포 패키지입니다. ``` chmod 755 function.sh bootstrap zip function.zip function.sh bootstrap ``` 1. `bash-runtime`이라는 이름의 함수를 생성합니다. `--role`에 Lambda [실행 역할](lambda-intro-execution-role.md)의 ARN을 입력합니다. ``` aws lambda create-function --function-name bash-runtime \ --zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \ --role arn:aws:iam::123456789012:role/lambda-role ``` 1. 함수를 간접 호출합니다. ``` aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out ``` **cli-binary-format** 옵션은 AWS CLI 버전 2를 사용할 때 필요합니다. 이 설정을 기본 설정으로 지정하려면 `aws configure set cli-binary-format raw-in-base64-out`을(를) 실행하세요. 자세한 내용은 [AWS CLI 지원되는 글로벌 명령줄 옵션](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)을 AWS Command Line Interface 사용 설명서 버전 2에서 참조하세요. 다음과 같은 응답이 표시되어야 합니다. ``` { "StatusCode": 200, "ExecutedVersion": "$LATEST" } ``` 1. 응답을 확인합니다. ``` cat response.txt ``` 다음과 같은 응답이 표시되어야 합니다. ``` Echoing request: '{"text":"Hello"}' ``` ## 계층 생성 함수 코드에서 런타임 코드를 분리하려면 런타임만 포함하는 계층을 생성하세요. 계층을 사용하면 함수의 종속 항목들을 독립적으로 개발할 수 있으며, 여러 함수가 있는 동일한 계층을 사용할 때 스토리지 사용량을 줄일 수 있습니다. 자세한 내용은 [계층으로 Lambda 종속성 관리](chapter-layers.md) 단원을 참조하십시오. 1. `bootstrap` 파일을 포함하는 .zip 파일을 생성합니다. ``` zip runtime.zip bootstrap ``` 1. [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x) 명령을 사용하여 계층을 생성합니다. ``` aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip ``` 그러면 해당 계층의 첫 번째 버전이 생성됩니다. ## 함수 업데이트 함수에 런타임 계층을 사용하려면 이 계층을 사용하도록 함수를 구성하고 함수에서 런타임 코드를 제거하세요. 1. 계층을 가져 오도록 함수 구성을 업데이트하세요. ``` aws lambda update-function-configuration --function-name bash-runtime \ --layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1 ``` 이 작업으로 `/opt` 디렉터리의 함수에 런타임이 추가됩니다. Lambda가 계층의 런타임을 사용하도록 하려면 다음 두 단계에 표시된 것처럼 함수의 배포 패키지에서 `boostrap`을 제거해야 합니다. 1. 함수 코드를 포함하는 .zip 파일을 생성합니다. ``` zip function-only.zip function.sh ``` 1. 핸들러 스크립트만 포함하도록 함수 코드를 업데이트하세요. ``` aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip ``` 1. 함수를 간접 호출하여 런타임 계층에서 작동하는지 확인합니다. ``` aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out ``` **cli-binary-format** 옵션은 AWS CLI 버전 2를 사용할 때 필요합니다. 이 설정을 기본 설정으로 지정하려면 `aws configure set cli-binary-format raw-in-base64-out`을(를) 실행하세요. 자세한 내용은 [AWS CLI 지원되는 글로벌 명령줄 옵션](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)을 AWS Command Line Interface 사용 설명서 버전 2에서 참조하세요. 다음과 같은 응답이 표시되어야 합니다. ``` { "StatusCode": 200, "ExecutedVersion": "$LATEST" } ``` 1. 응답을 확인합니다. ``` cat response.txt ``` 다음과 같은 응답이 표시되어야 합니다. ``` Echoing request: '{"text":"Hello"}' ``` ## 런타임 업데이트 1. 실행 환경에 관한 정보를 기록하려면 환경 변수를 출력하도록 런타임 스크립트를 업데이트하세요. **Example 부트스트랩** ``` #!/bin/sh set -euo pipefail # Configure runtime to output environment variables echo "## Environment variables:" env # Load function handler source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh" # Processing while true do HEADERS="$(mktemp)" # Get an event. The HTTP request will block until one is received EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next") # Extract request ID by scraping response headers received above REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2) # Run the handler function from the script RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA") # Send the response curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE" done ``` 1. `bootstrap` 파일의 새 버전을 포함하는 .zip 파일을 생성합니다. ``` zip runtime.zip bootstrap ``` 1. `bash-runtime` 계층의 새로운 버전을 생성합니다. ``` aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip ``` 1. 새 버전의 계층을 사용하도록 함수를 구성합니다. ``` aws lambda update-function-configuration --function-name bash-runtime \ --layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2 ``` ## 계층 공유 계층을 다른 AWS 계정와 공유하려면 계층의 [리소스 기반 정책](access-control-resource-based.md)에 교차 계정 권한 문을 추가합니다. [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) 명령을 실행하고 계정 ID를 `principal`로 지정합니다. 각 문에서 단일 계정, 모든 계정 또는 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)의 조직을 대상으로 권한을 부여할 수 있습니다. 다음 예시에서는 111122223333 계정에 `bash-runtime` 계층의 버전 2에 대한 액세스 권한을 부여합니다. ``` aws lambda add-layer-version-permission \ --layer-name bash-runtime \ --version-number 2 \ --statement-id xaccount \ --action lambda:GetLayerVersion \ --principal 111122223333 \ --output text ``` 다음과 유사한 출력 화면이 표시되어야 합니다. ``` {"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"} ``` 권한은 하나의 계층 버전에만 적용됩니다. 새 계층 버전을 만들 때마다 해당 과정을 반복합니다. ## 정리 각 버전의 계층을 삭제합니다. ``` aws lambda delete-layer-version --layer-name bash-runtime --version-number 1 aws lambda delete-layer-version --layer-name bash-runtime --version-number 2 ``` 이 함수는 계층의 버전 2에 대한 참조가 있으므로 Lambda 내에 여전히 존재합니다. 함수는 계속 작동하며, 다만 삭제된 버전을 사용하도록 함수를 구성할 수는 없습니다. 함수의 계층 목록을 수정하려면 새 버전을 지정하거나 삭제된 계층을 생략해야 합니다. [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html) 명령으로 함수를 삭제합니다. ``` aws lambda delete-function --function-name bash-runtime ``` # 소스 리포지토리 열기 AWS Lambda는 서버리스 애플리케이션을 빌드, 사용자 지정 및 최적화하는 데 도움이 되는 다양한 오픈 소스 도구, 라이브러리 및 구성 요소를 제공합니다. 이러한 리소스에는 AWS에서 유지 관리하고 GitHub에서 사용할 수 있는 런타임 인터페이스 클라이언트, 이벤트 라이브러리, 컨테이너 기본 이미지, 개발 도구 및 샘플 프로젝트가 포함됩니다. 이러한 오픈 소스 리포지토리를 활용하여 Lambda의 기능을 확장하고, 사용자 지정 런타임을 생성하고, 다양한 AWS 서비스의 이벤트를 처리하고, 함수의 성능에 대한 심층적인 인사이트를 얻을 수 있습니다. 이 페이지에서는 Lambda 개발을 지원하는 주요 오픈 소스 프로젝트의 개요를 제공합니다. ## 런타임 인터페이스 클라이언트 Lambda 런타임 인터페이스 클라이언트(RIC)는 [런타임 API](runtimes-api.md)를 구현하고 함수 코드와 Lambda 서비스 간의 상호 작용을 관리하는 오픈 소스 라이브러리입니다. 이러한 클라이언트는 호출 이벤트 수신, 컨텍스트 정보 전달 및 오류 보고를 처리합니다. Lambda의 관리형 런타임 및 컨테이너 기본 이미지에서 사용하는 런타임 인터페이스 클라이언트는 오픈 소스로 게시됩니다. 사용자 지정 런타임을 빌드하거나 기존 런타임을 확장할 때 이러한 오픈 소스 라이브러리를 사용하여 구현을 간소화할 수 있습니다. 다음 오픈 소스 GitHub 리포지토리에는 Lambda의 RIC에 대한 소스 코드가 포함되어 있습니다. + [Node.js 런타임 인터페이스 클라이언트](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client) + [Python 런타임 인터페이스 클라이언트](https://github.com/aws/aws-lambda-python-runtime-interface-client) + [Java 런타임 인터페이스 클라이언트](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-runtime-interface-client) + [Ruby 런타임 인터페이스 클라이언트](https://github.com/aws/aws-lambda-ruby-runtime-interface-client) + [.NET 런타임 인터페이스 클라이언트](https://github.com/aws/aws-lambda-dotnet) + [Rust 런타임 인터페이스 클라이언트](https://github.com/aws/aws-lambda-rust-runtime) + [Go 런타임 인터페이스 클라이언트](https://github.com/aws/aws-lambda-go) + [Swift 런타임 인터페이스 클라이언트](https://github.com/awslabs/swift-aws-lambda-runtime)(실험 단계) + [C\$1\$1 런타임 인터페이스 클라이언트](https://github.com/awslabs/aws-lambda-cpp)(실험 단계) + [Lambda 기본 이미지](https://github.com/aws/aws-lambda-base-images) 이러한 클라이언트를 사용하여 사용자 지정 런타임을 빌드하는 방법에 대한 자세한 정보는 [AWS Lambda에 대한 사용자 지정 런타임 빌드](runtimes-custom.md) 섹션을 참조하세요. ## 이벤트 라이브러리 Lambda 이벤트 라이브러리는 다양한 AWS 서비스의 이벤트를 처리하기 위한 유형 정의 및 헬퍼 유틸리티를 제공합니다. 이러한 라이브러리를 사용하면 유형 안전 방식으로 이벤트 데이터를 구문 분석하고 처리할 수 있으므로 Amazon S3, Amazon DynamoDB 및 Amazon API Gateway와 같은 서비스의 이벤트를 더 쉽게 사용할 수 있습니다. 컴파일된 언어의 경우는 AWS가 다음 이벤트 라이브러리를 제공합니다. + [Java 이벤트 라이브러리](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events) + [.NET 이벤트 라이브러리](https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src) + [Go 이벤트 라이브러리](https://github.com/aws/aws-lambda-go/tree/main/events) + [Rust 이벤트 라이브러리](https://github.com/awslabs/aws-lambda-rust-runtime) Node.js, Python, Ruby와 같이 해석된 언어의 경우 별도의 라이브러리 없이 이벤트를 JSON 객체로 직접 구문 분석할 수 있습니다. 그러나 Node.js 및 Python을 사용하는 개발자는 컴파일된 언어 라이브러리가 제공하는 것과 유사한 유형 힌트, 데이터 검증 및 기능을 제공하는 AWS 이벤트에 내장 스키마를 제공하는 AWS Lambda용 powertools를 활용할 수 있습니다. + [TypeScript용 Powertools](https://docs.powertools.aws.dev/lambda/typescript/latest/features/parser/#built-in-schemas) + [Python용 Powertools](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/#built-in-models) ## 컨테이너 기본 이미지 AWS는 Lambda 함수의 컨테이너 이미지를 빌드하기 위한 시작점으로 사용할 수 있는 오픈 소스 컨테이너 기본 이미지를 제공합니다. 이러한 기본 이미지에는 Lambda 실행 환경에서 함수를 실행하는 데 필요한 런타임 인터페이스 클라이언트 및 기타 구성 요소가 포함됩니다. 사용 가능한 기본 이미지 및 사용 방법에 대한 자세한 내용은 [AWS Lambda 기본 이미지](https://github.com/aws/aws-lambda-base-images) 리포지토리 및 [컨테이너 이미지를 사용하여 Lambda 함수 생성](images-create.md) 섹션을 참조하세요. ## 개발 도구 AWS는 Lambda 함수를 빌드하고 최적화하는 데 도움이 되는 추가 오픈 소스 개발 도구를 제공합니다. ### AWS Lambda용 Powertools AWS Lambda용 Powertools는 필수 유틸리티를 통해 서버리스 개발을 간소화하여 다중 레코드 처리 및 Kafka 소비자 라이브러리에 대한 중복 처리 및 배치 처리를 방지합니다. 이러한 기능을 사용하면 코드 복잡성과 운영 오버헤드를 최소화할 수 있습니다. 또한 다음 AWS Well-Architected 모범 사례를 따르면서 프로덕션 환경에서 바로 사용할 수 있는 Lambda 함수 생성을 가속화하도록 설계된 기본 제공 이벤트 스키마 검증, 구조화된 로깅 및 추적, 파라미터 스토어 통합을 활용할 수 있습니다. GitHub 리포지토리: + [Python](https://github.com/aws-powertools/powertools-lambda-python) + [TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript) + [Java](https://github.com/aws-powertools/powertools-lambda-java) + [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet) ### Java 개발 도구 + [Java Profiler(실험용)](https://github.com/aws/aws-lambda-java-libs/tree/main/experimental/aws-lambda-java-profiler) - Java Lambda 함수를 프로파일링하기 위한 도구입니다. + [ Java 라이브러리](https://github.com/aws/aws-lambda-java-libs) - JUnit 테스트 유틸리티 및 프로파일링 도구와 같은 주요 프로젝트를 포함하여 Lambda 개발을 위한 포괄적인 Java 라이브러리 및 도구 모음이 포함된 리포지토리입니다. + [서버리스 Java 컨테이너](https://github.com/aws/serverless-java-container) - 변경 사항을 최소화하면서 Lambda에서 기존 Java 애플리케이션을 실행할 수 있는 라이브러리입니다. ### .NET 개발 도구 [AWS Lambda .NET ](https://github.com/aws/aws-lambda-dotnet)리포지토리는 .NET CLI용 AWS Lambda 도구 및 .NET Core 애플리케이션을 호스팅하기 위한 .NET Core 서버 등에 대한 주요 프로젝트를 포함하여 Lambda 개발을 위한 .NET 라이브러리 및 도구를 제공합니다. ## 샘플 프로젝트 [서버리스 랜드 리포지토리](https://serverlessland.com/repos)에서 샘플 Lambda 프로젝트 및 애플리케이션의 포괄적인 컬렉션을 살펴보세요. 이러한 샘플은 서버리스 애플리케이션을 시작하는 데 도움이 되는 다양한 Lambda 사용 사례, 통합 패턴 및 모범 사례를 보여 줍니다.