AWS Lambda FAQ

AWS Lambda는 성능 향상을 위해 함수의 인스턴스를 보존하고 새로 사본을 만드는 대신 이를 재사용하여 후속 요청에 사용합니다. Lambda가 함수 인스턴스를 재사용하는 방법을 자세히 알아보려면 AWS 설명서를 참조하세요. 하지만 코드 재사용이 항상 가능할 것으로 가정해서는 안 됩니다.

512MB에서 10,240MB 사이에서 1MB 단위로 자체 임시 스토리지로 각 Lambda 함수를 구성할 수 있습니다. 임시 스토리지는 각 함수의 /tmp 디렉터리에서 사용할 수 있습니다.

각 함수는 추가 비용 없이 512MB의 스토리지에 액세스할 수 있습니다. 512MB 이상의 임시 스토리지로 기능을 구성하는 경우 구성한 스토리지의 양과 함수 실행 시간에 따라 1밀리초 단위로 요금이 청구됩니다. 비교를 위해 미국 동부(오하이오) 리전에서 AWS Fargate 임시 스토리지 가격은 기가비트-시간당 0.000111 USD 또는 기가비트-월당 0.08 USD입니다. 미국 동부(오하이오)의 Amazon EBS gp3 스토리지 볼륨 요금은 기가비트-월당 0.08 USD입니다. AWS Lambda 임시 스토리지 요금은 기가비트-초당 0.0000000309 USD 또는 기가비트-시간당 0.000111 USD 및 기가비트-월당 0.08 USD입니다. 자세히 알아보려면 AWS Lambda 요금을 참조하세요.

AWS CloudWatch Lambda Insight 지표를 사용하여 임시 스토리지 사용량을 모니터링할 수 있습니다. 자세한 내용은 AWS CloudWatch Lambda Insights 설명서를 참조하세요.

애플리케이션에 내구성 있는 영구 스토리지가 필요한 경우 Amazon S3 또는 Amazon EFS 사용을 고려하세요. 애플리케이션에서 단일 함수 호출의 코드에 필요한 데이터를 저장해야 하는 경우 AWS Lambda 임시 스토리지를 임시 캐시로 사용하는 것이 좋습니다. 자세히 알아보려면 Choosing between AWS Lambda data storage options in web apps(웹 앱에서 AWS Lambda 데이터 스토리지 옵션 선택)를 참조하세요.

예. 그러나 애플리케이션에 영구 스토리지가 필요한 경우 Amazon EFS 또는 Amazon S3 사용을 고려하세요. 함수에 대해 프로비저닝된 동시성을 활성화하면 함수의 초기화 코드가 할당 중에 실행되고 함수의 실행 중인 인스턴스가 재활용되므로 몇 시간마다 실행됩니다. 인스턴스가 요청을 처리한 후 로그 및 추적에서 초기화 시간을 확인할 수 있습니다. 그러나 인스턴스가 요청을 처리하지 않는 경우에도 초기화 비용이 청구됩니다. 이 프로비저닝된 동시성 초기화 동작은 함수가 요청을 처리하지 않는 경우에도 임시 스토리지에 저장한 데이터와 함수가 상호 작용하는 방식에 영향을 미칠 수 있습니다. 프로비저닝된 동시성에 대한 자세한 내용은 관련 설명서를 참조하세요.

AWS CloudWatch Lambda Insight 지표를 사용하여 임시 스토리지 사용량을 모니터링할 수 있습니다. 자세한 내용은 AWS CloudWatch Lambda Insights 설명서를 참조하세요.

Node.js 또는 Python을 사용하는 경우 AWS Lambda 콘솔의 코드 편집기를 사용하여 함수 코드를 작성하고 테스트할 수 있습니다. 이렇게 함수를 작성하고 테스트하여 IDE와 유사한 환경에서 함수 실행 결과를 볼 수 있습니다. 시작하려면 콘솔로 이동하세요.

또한, 코드(및 모든 종속 라이브러리)를 ZIP으로 패키징하고 AWS Lambda 콘솔을 사용하여 로컬 환경에서 업로드하거나 ZIP 파일이 있는 Amazon S3 위치를 지정할 수 있습니다. 업로드 파일은 50MB(압축)보다 작아야 합니다. AWS Eclipse 플러그 인을 사용하여 Java로 Lambda 함수를 작성하고 배포할 수 있습니다. Visual Studio 플러그 인을 사용하여 C# 및 Node.js로 Lambda 함수를 작성하고 배포할 수 있습니다.

또한, 코드(및 모든 종속 라이브러리)를 ZIP으로 패키징하고 AWS CLI를 사용하여 로컬 환경에서 업로드하거나 ZIP 파일이 있는 Amazon S3 위치를 지정할 수 있습니다. 업로드 파일은 50MB(압축)보다 작아야 합니다. 시작하려면 Lambda 시작 가이드를 참조하세요.

예. AWS Lambda 콘솔, CLI 또는 SDK를 통해 환경 변수를 손쉽게 생성하고 변경할 수 있습니다. 환경 변수에 대해 자세히 알아보려면 설명서를 참조하세요.

데이터베이스 암호와 같은 민감한 정보는 AWS Key Management Service를 사용하여 클라이언트 측 암호화를 수행한 후 환경 변수에 결과 값을 사이퍼텍스트로 저장하는 것이 좋습니다. 이러한 값을 복호화하는 로직을 AWS Lambda 함수 코드에 추가해야 합니다.

Lambda API 또는 콘솔을 사용하여 Lambda 함수와 관련된 리소스를 조정하고 보호할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

예, 모든 코드(프레임워크, SDK, 라이브러리 등)를 Lambda Layer로 패키지를 만들어 관리하면서 여러 함수에서 쉽게 공유할 수 있습니다.

AWS Lambda에서 사용자 대신 Lambda 함수를 자동으로 모니터링하여 총 요청 수, 계정 수준 및 함수 수준 동시성 사용, 지연 시간, 오류 비율, 제한된 요청 등을 비롯한 실시간 지표를 Amazon CloudWatch를 통해 보고합니다. Amazon CloudWatch 콘솔 또는 AWS Lambda 콘솔에서 각 Lambda 함수에 대한 통계를 확인할 수 있습니다. 또한, Lambda 함수에서 타사 모니터링 API를 호출할 수도 있습니다.
 

자세히 알아보려면 CloudWatch 지표 문제 해결을 참조하세요. Lambda의 내장된 측정치를 사용하는 경우, AWS Lambda 표준 요금이 부과됩니다.

AWS Lambda는 자동으로 Amazon CloudWatch Logs와 통합하여, 각 Lambda 함수에 대한 로그 그룹을 생성하고 기본 애플리케이션 수명 주기 이벤트 로그 항목을 제공합니다. 로그 항목에는 해당 함수의 각 용도에 따라 사용된 리소스 로깅도 포함됩니다. 로깅 문을 코드에 쉽게 추가로 삽입할 수 있습니다. 또한, Lambda 함수에서 타사 로깅 API를 호출할 수도 있습니다. 자세히 알아보려면 Lambda 함수 문제 해결을 참조하세요. Amazon CloudWatch 로그 요금이 부과됩니다.

AWS Lambda 리소스 모델에서 함수에 사용할 메모리 양을 선택하면 이에 비례하여 CPU 용량과 기타 리소스가 할당됩니다. 예를 들어, 256MB 메모리를 선택하면 Lambda 함수에 128MB 메모리를 요청할 때 CPU 용량의 약 두 배가 할당되고 512MB 메모리를 선택할 때 CPU 용량의 절반이 할당됩니다. 자세히 알아보려면 AWS의 함수 구성 설명서를 참조하십시오.

128MB부터 10,240MB까지 메모리를 설정할 수 있습니다.

AWS Lambda는 사용량에 따라 요금이 부과됩니다. 자세한 내용은 AWS Lambda 요금 페이지를 참조하세요.

예. 기본값으로 각 AWS Lambda 함수에는 코드의 현 단일 버전이 있습니다. Lambda 함수의 클라이언트가 특정 버전을 호출하거나 최근 구현을 가져올 수 있습니다. Lambda 함수 버전 관리에 대한 설명서를 참조하세요.

AWS Lambda는 특정 임계값 위의 월별 온디맨드 함수 기간에 대해 할인된 요금 구간을 제공합니다. x86 및 Arm 아키텍처 모두에서 실행되는 함수에 대해 구간형 요금제를 사용할 수 있습니다. Lambda 요금 구간은 계정 내의 동일한 아키텍처(각각 x86 또는 Arm)와 동일한 리전에서 실행되는 함수의 월별 총 온디맨드 기간에 적용됩니다. AWS Organizations에서 통합 결제를 사용하는 경우 요금 구간은 조직의 계정 내에서 동일한 아키텍처와 동일한 리전에서 실행되는 함수의 월별 총 기간에 적용됩니다. 예를 들어 미국 동부(오하이오) 리전에서 x86 Lambda 함수를 실행하는 경우 해당 리전에서 매월 첫 60억GB-초에 대해 GB-초마다 0.0000166667 USD를, 매월 다음 90억GB-초에 대해 GB-초마다 0.0000150000 USD를 그리고 매월 150억GB-초를 초과하는 사용량에 대해 GB-초마다 0.0000133334 USD를 지불하게 됩니다. 요청, 프로비저닝된 동시성 및 프로비저닝된 동시성 기간에 대한 요금은 그대로 유지됩니다. 자세한 내용은 AWS Lambda 요금을 참조하세요.

예. 시간당 절감형 플랜 약정이 적용되는 Lambda 사용량에 대한 요금은 해당하는 CSP 요금 및 할인으로 청구됩니다. 이 약정을 통해 제공되지 않는 나머지 사용량에는 월별 집계 함수 사용 기간이 포함되는 티어에 해당하는 요율이 적용되어 요금이 청구됩니다.

이벤트 소스의 전체 목록은 설명서를 참조하세요.

이벤트는 Lambda 함수에 이벤트 입력 파라미터로 전달됩니다. Amazon SQS, Amazon Kinesis 및 Amazon DynamoDB Streams와 이벤트가 배치로 도착하는 이벤트 소스의 경우 이벤트 파라미터는 요청한 배치 크기에 따라 단일 호출에 여러 이벤트를 포함할 수 있습니다. Amazon S3 이벤트 알림에 대해 자세히 알아보려면 Amazon S3 이벤트에 대한 알림 구성을 참조하세요. Amazon DynamoDB Streams에 대해 자세히 알아보려면 DynamoDB 스트림 개발자 안내서를 참조하세요. Amazon SNS를 사용한 Lambda 함수 호출에 대해 자세히 알아보려면 Amazon SNS 개발자 안내서를 참조하세요. Amazon Cognito 이벤트에 대한 자세한 내용은 Amazon Cognito를 참조하세요. AWS 서비스 전반에 걸친 AWS CloudTrail 로그 및 API 직접 호출 감사에 대한 자세한 내용은 AWS CloudTrail을 참조하세요.

AWS Lambda는 샤드 등의 단일 로직 파티션을 통해 Amazon Kinesis 또는 Amazon DynamoDB Streams에 있는 데이터에서 최대 15분의 짧은 시간 동안 시간 기반 집계(수, 최대, 총합, 평균 등)를 수행할 수 있도록 지원합니다. 따라서 비즈니스 및 분석 논리가 동일 기능에 위치할 수 있으므로 아키텍처 복합성을 추가하지 않고도 이벤트 기반 애플리케이션에 대한 단순 분석을 쉽게 설정할 수 있습니다. Lambda는 이벤트 타임스탬프 기반 15분 텀블링 윈도우의 최대치를 넘는 집계를 허용합니다. Amazon Kinesis Data Analytics를 사용하면 중복 없는 정확한 한 번의 처리로 유연한 처리 옵션 및 강력한 장애 복구를 지원하며, 여러 논리 파티션을 오가는 전체 데이터 스트림에서 분석을 수행할 수 있는 보다 복잡한 분석 애플리케이션을 구축할 수 있습니다. KDA를 통해 이벤트 시간 또는 프로세싱 시간을 사용하는 여러 유형의 집합 윈도우 (텀블링 윈도우, 스태거 윈도우, 슬라이딩 윈도우 및 세션 윈도우)의 데이터를 분석할 수 있습니다.
 

먼저 Amazon SNS 알림에 전송할 경보를 구성합니다. 그런 다음 AWS Lambda 콘솔에서 Lambda 함수를 선택하여 Amazon SNS 주제와 연결합니다. Amazon CloudWatch 경보 설정에 대한 자세한 내용은 Amazon CloudWatch 개발자 안내서를 참조하세요.

AWS Lambda 콘솔에서 Amazon Cognito 자격 증명 풀과 연결된 데이터 세트가 동기화될 때 트리거할 함수를 선택합니다. AWS SDK와 CLI를 통해서도 이와 같은 기능을 사용할 수 있습니다. 사용자 디바이스 전체에 데이터를 공유 및 동기화하도록 Amazon Cognito를 사용하는 것에 대한 자세한 정보는 Amazon Cognito를 참조하십시오.

AWS Lambda의 invoke API를 통해 사용자 지정 이벤트로 Lambda 함수를 호출할 수 있습니다. 함수 소유자나 소유자가 권한을 부여한 다른 AWS 계정에서만 함수를 호출할 수 있습니다. 자세히 알아보려면 Lambda 개발자 안내서를 참조하세요.

AWS Lambda가 실행할 코드를 업로드하고, AWS Mobile SDK에 포함된 AWS Lambda SDK를 사용하여 모바일 앱에서 해당 코드를 호출합니다. 실시간으로 데이터를 검색하고 확인하는 데 비동기식 호출뿐 아니라 직접(동기식) 호출도 사용할 수 있습니다. 또한, Amazon API Gateway를 사용하여 사용자 지정 API를 정의하고 원하는 REST 호환 클라이언트를 통해 Lambda 함수를 호출할 수 있습니다. AWS Mobile SDK에 대해 자세히 알아보려면 AWS Mobile SDK 페이지를 참조하세요. Amazon API Gateway에 대해 자세히 알아보려면 Amazon API Gateway 페이지를 참조하세요.

AWS Serverless Application Repository를 사용하면 AWS 커뮤니티의 개발자, 회사 및 파트너가 게시한 서버리스 애플리케이션 컬렉션에서 선택할 수 있습니다. 애플리케이션을 찾은 후에는 Lambda 콘솔에서 바로 구성하고 배포할 수 있습니다.

AWS CodePipeline 및 AWS CodeDeploy를 사용하여 서버리스 애플리케이션의 릴리스 프로세스를 자동화할 수 있습니다. CodePipeline은 서버리스 애플리케이션을 릴리스하는 데 필요한 단계를 모델링, 시각화, 자동화할 수 있게 해주는 지속적 전달 서비스입니다. CodeDeploy는 Lambda 기반 애플리케이션을 위해 배포 자동화 엔진을 제공합니다. CodeDeploy를 사용하면 카나리아 및 선형 배포와 같은 최상의 모범 사례 방법론에 따라 배포를 오케스트레이션할 수 있으며 새롭게 배포된 코드가 안전하고 안정적이며 생산에 완벽하게 릴리스할 준비가 되었는지 확인하는 데 필요한 안전 장치를 설정할 수 있습니다.
 

서버리스 CI/CD에 대해 자세히 알아보려면 AWS 설명서를 참조하세요.

시작하려면 AWS Lambda 콘솔로 이동하여 블루프린트 중 하나를 다운로드합니다. 다운로드하는 파일에는 AWS SAM 파일(애플리케이션에서 AWS 리소스 정의)과 .ZIP 파일(함수의 코드 포함)이 포함되어 있습니다. 그런 다음, AWS CloudFormation 명령을 사용하여 방금 다운로드한 서버리스 애플리케이션을 패키징하고 배포할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

AWS Step Functions를 사용하면 일련의 AWS Lambda 함수를 특정 순서로 조정할 수 있습니다. 여러 Lambda 함수를 순서대로 호출하여 한 함수의 결과를 다음 함수로 전달하거나 병렬로 호출할 수 있으며 Step Functions는 사용자가 실행하는 동안 상태를 유지합니다.

Lambda 함수의 실행 역할에 X-Ray 권한을 추가하고 함수의 ‘추적 모드’를 ‘활성’으로 변경하여 Lambda 함수에서 AWS X-Ray의 추적 기능을 사용하면 됩니다. Lambda 함수에 대한 X-Ray가 사용되면, AWS Lambda가 함수를 호출할 때 발생한 Lambda 서비스 오버헤드에 관한 추적 정보를 X-Ray로 내보냅니다. 이는 Lambda 서비스 오버헤드, 함수 초기 시간, 함수 실행 시간 등과 같은 통찰력을 제공합니다. 또한, Lambda 배포 패키지에 X-Ray SDK를 추가하여 자체 추적 세그먼트를 생성하고, 추적에 주석을 달거나 Lambda 함수에서 수행된 다운스트림 호출에 대한 추적 세그먼트를 볼 수 있습니다. 현재 X-Ray SDK는 Node.js와 Java로 제공됩니다. 자세히 알아보려면 Lambda 기반 애플리케이션 문제 해결을 참조하세요. AWS X-Ray 요금이 적용됩니다.

예. 관계형 데이터베이스에 대한 동시 연결 수천 개를 관리하는 고가용성 데이터베이스 프록시인 Amazon RDS 프록시를 사용하여 관계형 데이터베이스에 연결되는 확장성이 높고 안전한 Lambda 기반 서버리스 애플리케이션을 구축할 수 있습니다. 현재 RDS 프록시는 MySQL 및 Aurora 데이터베이스를 지원합니다. Amazon RDS 콘솔 또는 AWS Lambda 콘솔을 통해 RDS 프록시 사용을 시작할 수 있습니다. RDS 프록시에서 완전관리형 연결 풀을 사용하는 서버리스 애플리케이션의 경우 RDS 프록시 요금에 따라 비용이 청구됩니다.

이 사양은 Apache 2.0의 오픈 소스를 사용하므로 상업적 목적으로 사용할 수 있는 라이선스를 통해 AWS SAM을 구축, 배포, 모니터링 및 관리 도구에 도입 및 통합할 수 있습니다. 여기에서 GitHub의 AWS SAM 리포지토리에 액세스할 수 있습니다.

ZIP 아카이브와 컨테이너 이미지를 사용하여 생성한 기능 간에는 세 가지 주요 차이점이 있습니다.

1. ZIP 아카이브를 사용하여 생성한 기능은 최대 250MB의 압축하지 않은 코드 패키지 사이즈로, 최대 이미지 크기가 10GB인 컨테이너 이미지를 생성합니다. 
2. Lambda는 Amazon ECR을 컨테이너 이미지로 정의한 기능용 기초 코드 저장소로 사용하며, 따라서 ECR에서 기본 이미지를 제거하면 기능을 호출할 수 없을 수 있습니다. 
3. ZIP 기능은 최신 런타임 보안 및 버그 해결을 위해 자동으로 패치됩니다. 컨테이너 이미지로 정의된 기능은 수정할 수 없으며 고객은 해당 기능에 담긴 구성 요소에 대하여 책임을 집니다. 고객은 AWS가 보안 및 버그 해결을 위해 주기적으로 업데이트하는 AWS 기반 기본 이미지를 최신 패치를 사용하여 활용할 수 있습니다.

AWS Lambda에 대한 컨테이너 이미지로서의 패키징 및 배포 기능에 추가 비용이 들지 않습니다. 컨테이너 이미지로 배포한 기능을 호출하면 요청 및 실행 기간 동안 일정 요금을 내야합니다. 자세한 내용은 AWS Lambda 요금 페이지를 참조하세요. Amazon ECR에 컨테이너 이미지를 저장하면 표준 ECR 요금이 청구됩니다. 자세한 내용은 Amazon ECR 요금 페이지를 참조하세요.

Lambda Runtime Interface Emulator는 Lambda Runtime API용 프록시로, 이 프록시를 사용하면 컨테이너 이미지로 패키징된 Lambda 함수를 로컬로 테스트할 수 있습니다. 경량 웹 서버로, HTTP 요청을 JSON 이벤트로 변환하며, Lambda Runtime API를 모방합니다. cURL 및 Docker CLI 등의 익숙한 도구를 사용하여 기능을 로컬 테스트하도록 지원합니다 (테스트 기능이 컨테이너 이미지로 패키징되어 있는 경우). 또한 추가 컴퓨팅 서비스 상 애플리케이션 실행을 단순화합니다. Lambda Runtime Interface Emulator를 컨테이너 이미지에 포함시켜 HTTP 요청을 Lambda 배포에 필요한 JSON 이벤트 대신 자연적으로 수용할 수 있습니다. 이 구성 요소는 Lambda의 오케스트레이터, 또는 보안 및 인증 구성을 모방하지 않습니다. Runtime Interface Emulator는 GitHub 상의 오픈 소스입니다. 로컬 기계에 다운로드 및 설치하여 시작할 수 있습니다.

고객은 Runtime Interface Emulator (RIE)를 컨테이너 이미지에 진입점으로 추가하거나, 이를 사이드카로 패키징해 컨테이너 이미지가 이제 JSON 이벤트 대신 HTTP 요청을 수락하도록 할 수 있습니다. 이러한 작업은 컨테이너 이미지를 추가 컴퓨팅 서비스에서 실행하는데 필요한 변화를 단순화합니다. 고객은 선택한 환경에 대한 모든 보안, 성능 및 병행 모범 사례를 보장할 책임을 지게 됩니다. RIE는 AWS Lambda 제공 이미지에 사전 패키징되어 있으며, AWS SAM CLI에서 기본적으로 사용할 수 있습니다. 기본 이미지 제공자는 설명서를 사용하여 기본 이미지에 대한 동일한 경험을 제공할 수 있습니다.

컨테이너화한 애플리케이션이 다음 요건을 충족하면 AWS Lambda에 배포할 수 있습니다.

1. 컨테이너 이미지는 반드시 Lambda Runtime API를 구현해야 합니다. Lambda Runtime API를 구현하는 소프트웨어 패키지 세트인 RIC(Runtime Interface Client)를 오픈 소스로 제공하므로 선호하는 기본 이미지를 Lambda와 호환되도록 원활하게 확장할 수 있습니다.
2. 컨테이너 이미지는 읽기 전용 파일시스템에서 실행할 수 있어야 합니다. 사용자의 기능 코드는 512MB의 쓰기 가능 /tmp 디렉토리 저장소에 액세스할 수 있습니다. 쓰기 가능 루트 디렉토리가 필요한 이미지를 사용한다면, /tmp 디렉토리에 쓰도록 구성합니다.
3. 기본 Lambda 사용자는 함수 코드 실행에 필요한 파일을 읽을 수 있습니다. Lambda는 보안 모범 사례를 따르는 최소 권한 승인을 보유한 기본 Linux 사용자를 정의합니다. 다른 Linux 사용자의 실행이 제한되는 파일에 의존하지 않는 애플리케이션 코드를 증명해야 합니다.
4. Linux 기반 컨테이너 이미지입니다.

AWS SnapStart는 지연 시간에 민감한 애플리케이션의 시작 성능을 몇 초에서 1초 미만으로 개선할 수 있습니다. SnapStart는 함수의 초기화된 메모리(및 디스크) 상태를 스냅샷으로 생성하고 이 스냅샷을 캐싱하여 액세스 지연 시간을 줄이는 방식으로 작동합니다. 이후에 함수가 간접적으로 호출되면 Lambda는 실행 환경을 처음부터 다시 초기화하는 것이 아니라, 사전에 초기화된 스냅샷에서 실행 환경을 재개하여 시작 지연 시간을 개선합니다. 복원력을 위해 Lambda는 스냅샷의 캐싱된 사본을 유지하고 런타임 업그레이드 및 보안 패치와 같은 소프트웨어 업데이트를 자동으로 적용합니다.

Lambda SnapStart는 Lambda API, AWS Management Console, AWS Command Line Interface(CLI), AWS SDK, AWS Cloud Development Kit(CDK), AWS CloudFormation 및 AWS Serverless Application Model(SAM)을 사용하여 신규 및 기존 함수에 대해 구성할 수 있는 단순한 함수 수준 구성입니다. Lambda SnapStart를 구성하면 후에 게시되는 모든 함수 버전에 Lambda SnapStart가 제공하는 개선된 시작 성능이 적용됩니다. Lambda SnapStart에 대해 자세히 알아보려면 설명서를 참조하세요.

Lambda SnapStart는 일회성 초기화 코드의 실행 중에 발생하는 가변 지연 시간을 줄여 함수의 시작 시간을 단축하는 데 도움이 되는 성능 최적화입니다. Lambda SnapStart는 시작 지연 시간을 줄여주지만 가능한 범위 내에서만 최적화하며 콜드 스타트를 완전히 없애주지는 않습니다. 애플리케이션의 지연 시간 요구 사항이 엄격하고 시작 시간이 99밀리초 이내여야 하는 경우 PC를 사용하는 것이 좋습니다.

Lambda SnapStart는 Java 11(이상), Python 3.12(이상), .NET 8(이상)을 비롯한 여러 런타임을 지원합니다. 향후 버전의 런타임은 버전이 릴리스된 후 지원될 것입니다. Lambda가 지원하는 모든 런타임은 Lambda 런타임 설명서를 참조하세요.

예. Virtual Private Cloud(VPC)의 리소스에 액세스하도록 Lambda SnapStart 함수를 구성할 수 있습니다. VPC로 함수를 구성하는 방법에 대한 자세한 내용은 Lambda 설명서를 참조하세요.

예. x86 및 Arm 아키텍처 모두에서 실행되는 함수에 대해 Lambda SnapStart를 구성할 수 있습니다.

예. 코드에서 상태의 고유성을 가정하는 경우 스냅샷 작업(예: 복제 및 다시 시작)에 대한 코드의 복원력을 평가해야 합니다. Lambda SnapStart의 고유성 고려 사항에 대해 자세히 알아보려면 설명서와 블로그에서 Lambda SnapStart 사용 시 VM 스냅샷의 고유성에 대한 내용을 참조하세요.

예. 스냅샷을 생성(체크포인트 지정)하기 전과 런타임 후크를 사용하여 스냅샷을 복원한 후에 소프트웨어 로직을 구현할 수 있습니다. 자세히 알아보려면 Lambda SnapStart 설명서를 참조하세요.

예. 함수 버전이 활성화된 기간(최소 3시간)에 대해 스냅샷 캐싱 요금이 부과되고, 이후에는 밀리초당 스냅샷 캐싱 요금이 부과됩니다. 요금은 함수에 할당한 메모리 양에 따라 결정됩니다. 또한 Lambda가 스냅샷을 복원하여 실행 환경을 재개할 때마다 요금이 부과되며, 이 요금은 함수에 할당한 메모리 양에 따라 달라집니다. SnapStart의 요금에 대해 자세히 알아보려면 AWS Lambda 요금을 참조하세요.

최대 14일 동안만 스냅샷을 캐싱할 수 있는, 지원되는 Java 관리형 런타임에는 SnapStart 요금이 적용되지 않습니다.

여타의 Lambda 함수와 마찬가지로 SnapStart 함수에도 기간별 요금이 적용됩니다. SnapStart를 사용하는 함수의 경우 런타임을 로드하는 데 걸리는 시간, 런타임 후크에서 실행되는 코드, 복구를 위해 스냅샷 복사본을 생성할 때 실행되는 초기화 코드가 기간에 포함됩니다.

Python 및 .NET용 Lambda SnapStart를 사용할 경우 함수가 활성 상태이면 함수 스냅샷도 활성 상태로 유지됩니다. Java 함수의 경우 게시된 함수에 연결된 스냅샷은 14일 이상 비활성 상태로 유지되는 경우 만료됩니다.

스냅샷은 Lambda 서비스가 소유하고 관리하는 고객 고유의 AWS Key Management Service(KMS) 키를 사용하여 기본적으로 암호화됩니다. 고객도 고객이 소유하고 관리하는 KMS 키를 사용하여 스냅샷을 암호화할 수 있습니다.

AWS Management Console, Lambda API, AWS CLI 및 AWS CloudFormation을 통해 기능에서 동시성을 구성할 수 있습니다. 프로비저닝된 동시성의 이점을 활용하는 가장 간단한 방법은 AWS Auto Scaling을 사용하는 것입니다. Application Auto Scaling으로 일정을 구성하거나 요구 사항이 변경될 때 Auto Scaling에서 프로비저닝된 동시성 수준을 실시간으로 자동 조정되도록 할 수 있습니다. 프로비저닝된 동시성에 대해 자세히 알아보려면 설명서를 참조하세요.

프로비저닝된 동시성은 기능이 초기화된 상태를 유지하기 위해 ‘프로비저닝된 동시성’의 요금 차원을 추가합니다. 활성화되면 구성된 동시성 크기와 구성 기간에 대한 비용을 지불합니다. 프로비저닝된 동시성이 구성되어 있는 동안 함수가 실행되면 요청 및 실행 기간에 대한 비용도 지불합니다. 프로비저닝된 동시성 요금에 대해 자세히 알아보려면 AWS Lambda 요금을 참조하세요.

Python, Java 및 Node와 같은 해석된 언어는 일반적으로 코드가 아키텍처별 구성 요소를 사용하는 라이브러리를 참조하지 않는 한 재컴파일이 필요하지 않습니다. 그러한 경우 arm64를 대상으로 하는 라이브러리를 제공해야 합니다. 자세한 내용은 AWS Graviton 시작페이지를 참조하세요. 해석되지 않는 언어는 arm64를 대상으로 코드를 컴파일해야 합니다. 최신 컴파일러는 arm64용으로 컴파일된 코드를 생성하지만 테스트하려면 이를 arm 기반 환경에 배포해야 합니다. Graviton2에서 Lambda 함수를 사용하는 방법에 대한 자세한 내용은 설명서를 참조하세요.

시작 시 고객은 Python, Node.js, Java, Ruby, .Net Core, Custom Runtime(provided.al2) 및 OCI Base 이미지를 사용할 수 있습니다. 자세히 알아보려면 AWS Lambda 런타임을 참조하세요.

각 워크로드는 고유하므로 고객이 기능을 테스트하여 가격 대비 성능 개선을 확인할 것을 권장합니다. 이를 위해서는 AWS Lambda Power Tuning 도구를 사용하는 것이 좋습니다. 잠재적인 가격 대비 성능 향상에 대해 워크로드를 테스트할 때 웹 및 모바일 백엔드, 데이터 및 스트림 처리로 시작하는 것이 좋습니다.

개발자는 콘솔, CLI 또는 SDK를 사용하여 EFS 액세스 포인트를 통해 기존 EFS 파일 시스템을 Lambda 함수에 손쉽게 연결할 수 있습니다. 함수를 처음 호출하면 파일 시스템이 자동으로 탑재되어 함수 코드에서 사용할 수 있게 됩니다. 자세한 내용은 설명서에서 확인할 수 있습니다.

AWS Lambda용 Amazon EFS 사용에 대한 추가 비용은 없습니다. 고객은 AWS Lambda와 Amazon EFS에 대한 표준 요금만 지불하면 됩니다. Lambda와 EFS를 동일한 가용 영역에서 사용하는 고객은 데이터 전송 요금이 청구되지 않습니다. 하지만 교차 계정 액세스를 위해 VPC 피어링을 사용하는 경우에는 데이터 전송 요금이 청구됩니다. 자세히 알아보려면 요금을 참조하세요.

AWS 관리 콘솔, AWS Lambda API, AWS CLI, AWS CloudFormation 및 AWS Serverless Application Model을 통해 함수 URL을 구성할 수 있습니다. 함수의 정규화되지 않은 $LATEST 버전이나 함수 별칭을 함수 URL에 사용할 수 있습니다. 함수 URL 구성에 대해 자세히 알아보려면 설명서를 참조하세요.

예. Lambda 함수 URL에 함수 또는 함수 별칭을 사용할 수 있습니다. 별칭을 지정하지 않으면 URL은 기본적으로 $LATEST를 가리킵니다. 함수 URL은 개별 함수 버전을 대상으로 할 수 없습니다.

함수 URL 사용에 따르는 추가 요금은 없습니다. AWS Lambda용 표준 요금을 지불합니다. 자세한 내용은 AWS Lambda 요금을 참조하세요.

Lambda@Edge를 사용하면 서버를 프로비저닝하거나 관리하지 않고 글로벌 AWS 로케이션에서 코드를 실행할 수 있으므로 가장 짧은 네트워크 지연 시간으로 최종 사용자에게 응답할 수 있습니다. Node.js 또는 Python 코드를 AWS Lambda에 업로드하고 Amazon CloudFront 요청에 대한 응답으로 함수가 트리거되도록 구성하기만 하면 됩니다(즉, 뷰어 요청이 도착하면, 요청이 오리진으로 전달되거나 오리진에서 다시 수신되면, 최종 사용자에게 응답하기 바로 직전). 그러면 콘텐츠에 대한 요청이 수신되는대로 코드가 글로벌 AWS 로케이션에서 바로 실행되고 CloudFront 요청 볼륨에 맞춰 전 세계로 확장됩니다. 자세한 내용은 설명서를 참조하십시오.

Lambda@Edge를 사용하려면, 코드를 AWS Lambda에 업로드하고 Amazon CloudFront 요청에 대한 응답으로 트리거되도록 함수 버전을 연결하기만 하면 됩니다. 코드는 Lambda@Edge Service Limits을 충족해야 합니다. 현재 Lambda@Edge에서는 CloudFront 이벤트로 글로벌 호출을 수행하도록 코드를 작성할 때 Node.js와 Python을 지원합니다. 자세한 내용은 설명서를 참조하십시오.

Lambda@Edge는 뷰어가 전 세계에 분산되어 있고 지연 시간에 민감한 사용 사례에 최적화되어 있습니다. 의사 결정에 필요한 모든 정보는 함수와 요청을 통해 CloudFront 엣지에서 제공할 수 있어야 합니다. 다시 말해 사용자 특성(위치, 클라이언트 디바이스 등)을 바탕으로 콘텐츠를 제공하는 방법을 결정하려는 사용 사례의 경우, 중앙 서버로 다시 경로 지정할 필요 없이 이제 사용자와 가까운 위치에서 바로 실행하고 지원할 수 있습니다.

기존 Lambda 함수가 Lambda@Edge 서비스 요구 사항 및 한도를 충족하는 경우 해당 함수를 CloudFront 이벤트와 연결하여 글로벌 호출에 사용할 수 있습니다. 함수 속성을 업데이트하는 방법은 여기를 참조하세요.

다음 Amazon CloudFront 이벤트에 대한 응답으로 기능이 자동으로 트리거됩니다.

• 뷰어 요청 – 최종 사용자나 인터넷 상의 디바이스가 CloudFront에 HTTP(S) 요청을 하고 해당 사용자에게 가장 가까운 엣지 로케이션에 요청이 도착할 때 이 이벤트가 발생합니다.
• 뷰어 응답 – 엣지에 있는 CloudFront 서버가 요청한 최종 사용자나 디바이스에 응답할 준비가 될 때 이 이벤트가 발생합니다.
• 오리진 요청 – CloudFront 엣지 서버에 캐시에서 요청된 객체가 아직 없고 백엔드 원본 웹 서버(예: Amazon EC2, Application Load Balancer 또는 Amazon S3)로 뷰어 요청을 보낼 준비가 되어 있을 때 이 이벤트가 발생합니다.
• 오리진 응답 – 엣지에 있는 CloudFront 서버가 백엔드 원본 웹 서버에서 응답을 수신할 때 이 이벤트가 발생합니다.

다른 점은 API Gateway와 Lambda가 리전별 서비스라는 것입니다. Lambda@Edge 및 Amazon CloudFront를 사용하면 최종 사용자의 위치에 따라 여러 AWS 위치에서 로직을 실행할 수 있습니다.

AWS Lambda는 대량의 함수 인스턴스를 병렬로 실행할 수 있도록 설계되었습니다. 하지만 AWS Lambda에는 리전별로 계정당 동시 실행 인스턴스 수에 대한 기본 안전 스로틀 값이 있습니다(기본 안전 스로틀 한도에 대한 정보는 여기 참조). 중요한 함수에 대한 계정 동시성 제한의 하위 집합을 예약하거나 다운스트림 리소스에 대한 트래픽 속도를 제한하는 데 사용할 수 있는 개별 AWS Lambda 함수의 최대 동시 실행을 제어할 수 있습니다.

동시 실행 한도 증가 요청을 제출하려면 Service Quotas를 사용하여 한도 증가 요청을 요청할 수 있습니다.

최대 동시 실행 한도를 초과하면 동시에 호출되는 AWS Lambda 함수는 제한 오류(429 오류 코드)를 반환합니다. 비동기적으로 호출된 Lambda 함수는 약 15~30분 정도 일정량의 순간 트래픽을 처리할 수 있으나 그 후 들어오는 이벤트는 제한 처리되어 거부됩니다. Amazon S3 이벤트에 대한 응답으로 Lambda 함수가 호출된 경우, AWS Lambda가 거부한 이벤트는 24시간 동안 S3에서 보유 및 재시도할 수 있습니다. Amazon Kinesis Streams와 Amazon DynamoDB Streams의 이벤트는 Lambda 함수가 성공하거나 데이터가 만료될 때까지 재시도됩니다. Amazon Kinesis와 Amazon DynamoDB Streams에서 24시간 동안 데이터를 유지합니다.

기본 최대 동시 실행 한도는 계정 수준에서 적용됩니다. 하지만 개별 함수에도 제한을 설정할 수 있습니다(예약된 동시성에 대한 자세한 내용은 여기에서 확인).

동기식으로 간접 호출되는 각 Lambda 함수는 10초마다 최대 1,000개의 동시 실행 속도로 규모를 조정할 수 있습니다. Lambda의 규모 조정 속도는 대부분의 사용 사례에 적합하며 특히 트래픽이 예측 가능하거나 예측할 수 없이 폭증하는 경우에 이상적입니다. 예를 들어, SLA 기반 데이터 처리에는 처리 수요를 충족하기 위해 예측 가능하면서도 빠른 규모 조정이 필요합니다. 마찬가지로 속보 기사를 제공하거나 깜짝 세일을 하는 경우에도 단기간에 예측할 수 없는 수준의 트래픽이 발생할 수 있습니다. Lambda의 규모 조정 속도를 사용하면 추가 구성이나 도구 없이 이러한 사용 사례를 더 편리하게 수행할 수 있습니다. 또한, 동시성 조정 제한은 함수 수준 제한으로, 계정의 각 함수가 다른 함수와 독립적으로 규모 조정됩니다.

비동기식 호출에 대한 재시도 정책을 초과하는 경우, 이벤트가 배치될 "데드레터큐"(DLQ)를 구성할 수 있습니다. 구성된 DLQ가 없는 경우 이벤트가 거부될 수 있습니다. 스트림 기반 간접 호출에 대한 재시도 정책을 초과하는 경우, 데이터가 이미 만료되었을 것이므로 거부됩니다.

IAM 역할을 사용하여, Lambda 함수가 다른 리소스에 액세스하도록 권한을 줄 수 있습니다. AWS Lambda는 Lambda 함수를 실행하는 동안 IAM 역할을 맡으므로, 함수가 사용할 수 있는 AWS 리소스를 정확하고 완벽하게 제어할 수 있습니다. 역할에 대해 자세히 알아보려면 AWS Lambda 설정을 참조하세요.

AWS Lambda 함수에 메시지를 전송하기 위해 Amazon S3 버킷을 구성할 때, 액세스를 허용하는 리소스 정책 규칙이 생성됩니다. Lambda 함수에 대한 리소스 정책과 액세스 제어에 대한 자세한 내용은 Lambda 개발자 안내서를 참조하세요.

Lambda 함수 역할을 통해 액세스 제어를 관리합니다. Lambda 함수에 지정한 역할에서 AWS Lambda가 폴링할 수 있는 리소스도 대신 결정하게 됩니다. 자세한 내용은 Lambda 개발자 안내서를 참조하세요.

함수 구성의 일부로 서브넷과 보안 그룹을 지정하면 Lambda 함수를 사용하여 VPC의 리소스에 액세스할 수 있습니다. 특정 VPC에 있는 리소스에 액세스하도록 구성된 Lambda 함수는 기본적으로 인터넷에 액세스할 수 없습니다. 이러한 함수에 인터넷을 허용하려면 인터넷 게이트웨이를 사용하세요. 기본적으로 Lambda 함수는 IPv4를 통해 이중 스택 VPC의 리소스와 통신합니다. IPv6를 통해 이중 스택 VPC의 리소스에 액세스하도록 함수를 구성할 수 있습니다. VPC로 구성된 Lambda 함수에 대한 자세한 내용은 VPC를 사용한 Lambda 프라이빗 네트워킹을 참조하세요.

AWS Lambda의 코드 서명을 사용하면 승인된 개발자가 게시한 변경하지 않은 코드만 Lambda 기능에 배포되는지 확인할 수 있는 신뢰 및 무결성 통제 기능을 제공합니다. 완전관리형 코드 서명 서비스인 AWS Signer를 사용하여 코드 아티팩트에 디지털로 서명하고 배포 시 서명을 확인하도록 Lambda 함수를 구성할 수 있습니다. AWS Lambda의 코드 서명은 ZIP 아카이브로 패키징한 기능에 현재 유일하게 사용할 수 있습니다.

AWS Signer 콘솔, Signer API, SAM CLI 또는 AWS CLI를 통해 서명 프로필을 사용하여 디지털로 서명된 코드 아티팩트를 생성할 수 있습니다. 자세히 알아보려면 AWS Signer 설명서를 참조하세요.

AWS Lambda는 배포 시 다음 서명 확인을 수행할 수 있습니다.

• 부정 서명 - 코드 아티팩트가 서명 후 교체되면 발생합니다.
• 불일치 서명 - 아티팩트에 승인되지 않은 서명 프로파일이 서명하면 발생합니다.
• 만료된 서명 - 서명이 구성 만료 날짜를 지나면 발생합니다.
• 취소 서명 - 서명 프로파일 소유자가 서명 작업을 취소하면 발생합니다.

자세히 알아보려면 AWS Lambda 설명서를 참조하세요.

AWS Lambda용 코드 서명을 사용할 때 추가 비용이 들지 않습니다. AWS Lambda용 표준 요금을 지불합니다. 자세히 알아보려면 요금을 참조하세요.

기본적으로 단순화되고 향상된 로깅 환경을 제공하기 위해 AWS Lambda는 Lambda 함수 로그를 JSON 구조 형식으로 기본적으로 캡처하고, 코드를 변경하지 않고 Lambda 함수 로그의 수준 필터링을 제어하고, Lambda가 로그를 전송하는 Amazon CloudWatch 로그 그룹을 사용자 지정하는 기능 등 고급 로깅 제어 기능을 제공합니다.

자체 로깅 라이브러리를 사용하지 않고도 Lambda 함수 로그를 JSON 구조 형식으로 캡처할 수 있습니다. JSON 구조 로그를 사용하면 대량의 로그 항목을 쉽게 검색, 필터링 및 분석할 수 있습니다. 코드를 변경하지 않고도 Lambda 함수 로그의 로그 수준 필터링을 제어할 수 있으므로 오류를 디버깅하고 문제를 해결할 때 대량의 로그를 선별하지 않고도 Lambda 함수에 필요한 로깅 세분성 수준을 선택할 수 있습니다. 또한 Lambda에서 로그를 전송할 Amazon CloudWatch 로그 그룹을 설정하여 애플리케이션 내 여러 함수의 로그를 한 곳에서 쉽게 집계할 수 있습니다. 그런 다음 보안, 거버넌스 및 보존 정책을 모든 기능에 개별적으로 적용하는 대신 애플리케이션 수준에서 로그에 적용할 수 있습니다.

AWS Lambda API, AWS Lambda 콘솔, AWS CLI, AWS 서버리스 애플리케이션 모델(SAM) 및 AWS CloudFormation을 사용하여 Lambda 함수에 대한 고급 로깅 제어를 지정할 수 있습니다. 자세히 알아보려면 고급 로깅 제어에 대한 출시 블로그 게시물 또는 Lambda 개발자 안내서를 참조하세요.

예. 자체 로깅 라이브러리를 사용하여 JSON 구조 형식으로 Lambda 로그를 생성할 수 있습니다. 로깅 라이브러리가 Lambda의 기본 JSON 구조 로깅 기능과 원활하게 작동하도록 하기 위해 Lambda는 함수에서 생성된 로그 중 이미 JSON으로 인코딩된 로그를 이중 인코딩하지 않습니다. 또한 Powertools for AWS Lambda 라이브러리를 사용하여 Lambda 로그를 JSON 구조 형식으로 캡처할 수 있습니다.

Lambda에서 고급 로깅 제어를 사용하는 데 따른 추가 비용은 없습니다. Amazon CloudWatch Logs에서 Lambda 로그를 수집하고 저장하는 요금은 계속 청구됩니다. 로그 요금에 대한 세부 정보는 CloudWatch 요금 페이지를 참조하세요.

CloudWatch Application Signals는 개발자와 운영자가 Lambda를 사용하여 구축한 서버리스 애플리케이션의 상태와 성능을 쉽게 모니터링할 수 있도록 하는 애플리케이션 성능 모니터링(APM) 솔루션입니다. Application Signals는 중요한 애플리케이션 지표, 상관 관계 추적, Lambda 함수와 해당 종속성 간의 상호 작용을 보여주는 사전 구축되고 표준화된 대시보드를 제공합니다. 이 모든 작업은 개발자의 수동 계측이나 코드 변경이 필요하지 않습니다.

Lambda 콘솔의 구성 탭에 있는 ‘모니터링 및 운영 도구’ 섹션에서 클릭 한 번으로 함수에 대해 Application Signals를 활성화할 수 있습니다. Application Signals를 활성화한 후 CloudWatch 콘솔에서 사전 구축된 대시보드, 서비스 맵 등을 보고 서버리스 애플리케이션의 성능 및 상태를 분석할 수 있습니다. 자세히 알아보려면 Lambda 개발자 안내서 및 Application Signals 개발자 안내서를 참조하세요. CloudWatch 요금 페이지를 방문하여 Lambda 함수와 함께 Application Signals를 사용할 때 요금이 부과되는 방식에 대해 자세히 알아보세요.

CloudWatch Logs Live Tail은 대화형 로그 스트리밍 및 분석 기능이며 로그에 대한 실시간 가시성을 제공하므로 Lambda 함수를 더 쉽게 개발하고 문제를 해결할 수 있습니다. 이를 통해 개발자는 코드나 구성의 변경을 실시간으로 신속하게 테스트하고 검증할 수 있으므로 Lambda를 통해 애플리케이션을 구축할 때 작성자-테스트-배포 주기(‘내부 개발 루프’라고도 함)가 단축됩니다. 뿐만 아니라 운영자와 DevOps 팀은 Live Tail 경험을 통해 Lambda 함수 코드의 장애 및 중대한 오류를 더 효율적으로 탐지하고 디버그할 수 있으므로 Lambda 함수 오류를 해결할 때 평균 복구 시간(MTTR)이 단축됩니다.

Lambda 함수에 Live Tail을 사용하려면 Lambda 콘솔로 이동하여 코드 편집기에서 ‘CloudWatch Live Tail 열기’ 버튼을 클릭하세요. 자세한 내용은 Lambda 개발자 안내서를 참조하세요. CloudWatch 요금 페이지를 방문하여 Lambda 함수와 함께 Live Tail을 사용할 때 요금이 부과되는 방식에 대해 자세히 알아보세요.

Maven 또는 Gradle 같은 표준 도구를 사용하여 Lambda 함수를 컴파일할 수 있습니다. 빌드 프로세스는 AWS SDK를 사용하는 Java 코드를 컴파일할 때와 같은 빌드 프로세스를 모방해야 합니다. 소스 파일을 Java 컴파일러 도구로 실행할 때 AWS SDK 1.9 이상과 추이 종속성을 클래스 경로에 포함합니다. 자세한 내용은 설명서를 참조하세요.

예. 사용자 정의 패키지뿐만 아니라 NPM 패키지도 사용할 수 있습니다. 여기에서 자세히 알아보세요.

예. Lambda의 내장 샌드박스를 사용하여 배치("셸)" 스크립트, 기타 언어 런타임, 유틸리티 루틴, 실행 파일을 실행할 수 있습니다. 여기에서 자세히 알아보세요.

예. 모든 정적 링크 네이티브 모듈뿐만 아니라 Lambda 함수 루트 디렉토리를 가리키는 rpath로 컴파일된 동적 링크 모듈도 업로드하는 ZIP 파일에 포함될 수 있습니다. 여기에서 자세히 알아보세요.

예. Node.js의 child_process 명령을 사용하면 함수에 포함한 바이너리 또는 함수에 표시할 수 있는 Amazon Linux 실행 파일을 실행할 수 있습니다. 또한, node-ffmpeg 같은 명령줄 바이너리를 래핑하는 여러 NPM 패키지가 존재합니다. 여기에서 자세히 알아보세요.

Node.js로 작성된 Lambda 함수를 배포하려면, Javascript 코드와 종속 라이브러리를 ZIP 파일로 패키징하면 됩니다. 로컬 환경에서 ZIP 파일을 업로드하거나 ZIP 파일이 있는 Amazon S3 위치를 지정할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

PowerShell Lambda 배포 패키지는 PowerShell 스크립트, PowerShell 스크립트에서 필요로 하는 PowerShell 모듈, PowerShell Core 호스팅에 필요한 어셈블리를 포함한 ZIP 파일입니다. 이후 PowerShell Gallery에 설치하는 AWSLambdaPSCore PowerShell을 사용하여 PowerShell Lambda 배포 패키지를 생성할 수 있습니다.

AWS CLI 또는 Lambda 콘솔을 통해 Go 실행 파일 아티팩트를 ZIP 파일로 업로드하고 go1.x 런타임을 선택합니다. Lambda에서는 Go의 기본 도구를 사용하여 코드를 구축하고 패키징할 수 있습니다. 자세한 내용은 설명서를 참조하십시오.  

여기에서 지원되는 버전 목록을 볼 수 있습니다.

아니요. AWS Lambda는 서비스의 모든 사용자에게 단일 버전의 운영 체제와 관리형 언어 런타임을 제공합니다. Lambda에서 사용할 자체 언어 런타임을 가져올 수 있습니다.

Amazon Step Functions를 사용하여 여러 Lambda 함수 호출을 조정할 수 있습니다. 여러 Lambda 함수를 순차적으로 호출하여 한 함수의 결과를 다른 함수에 전달하거나 병렬로 호출할 수 있습니다. 자세한 내용은 설명서를 참조하세요.