AWS Lambda FAQ

AWS Lambda에서 실행하는 코드는 'Lambda 함수'로 업로드됩니다. 각 함수에는 이름과 설명, 진입점, 리소스 요구 사항 등 연관된 구성 정보가 포함되어 있습니다. 코드는 '상태 비저장' 스타일로 작성되어야 합니다. 즉, 기본 컴퓨팅 인프라에 대한 선호도가 없다고 가정해야 합니다. 로컬 파일 시스템 액세스, 하위 프로세스 및 유사한 아티팩트는 요청 수명 기간 이상 확장될 수 없으며 모든 지속 상태는 Amazon S3, Amazon DynamoDB, Amazon EFS 또는 다른 인터넷 사용 스토리지 서비스에 저장되어야 합니다. Lambda 함수는 기본 라이브러리를 비롯하여 라이브러리를 포함할 수 있습니다.

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 Lambda 콘솔, AWS Lambda API 또는 AWS CloudFormation 템플릿을 사용하여 1MB 단위로 512MB에서 10,240MB 사이의 자체 임시 스토리지로 각 Lambda 함수를 구성할 수 있습니다.

예. 임시 스토리지에 저장된 모든 데이터는 AWS에서 관리하는 키로 저장 중 암호화됩니다.

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 Lambda 콘솔, AWS Lambda API 또는 AWS CloudFormation 템플릿을 사용하여 1MB 단위로 512MB에서 10,240MB 사이의 자체 임시 스토리지로 각 Lambda 함수를 구성할 수 있습니다.

예. 임시 스토리지에 저장된 모든 데이터는 AWS에서 관리하는 키로 저장 중 암호화됩니다.

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

함수를 상태 비저장으로 유지하면 AWS Lambda에서 필요한 만큼 함수 사본을 빠르게 시작하여 수신 이벤트 비율에 따라 조정할 수 있습니다. AWS Lambda의 프로그래밍 모델은 상태 비저장이지만 코드에서 Amazon S3 또는 Amazon DynamoDB 등 다른 웹 서비스를 호출하면 상태 저장 데이터에 액세스할 수 있습니다.

예. AWS Lambda를 사용하면 일반 언어 및 추가 스레드와 프로세스 생성과 같은 운영 체제 기능을 사용할 수 있습니다. 메모리, 실행 시간, 디스크, 네트워크 사용을 비롯하여 Lambda 함수에 할당된 리소스는 함수가 사용하는 모든 스레드/프로세스 간에 공유되어야 합니다. 프로세스 실행에는 Amazon Linux에서 지원하는 모든 언어를 사용할 수 있습니다.

Lambda는 일반 언어와 운영 체제 활동에 최소한의 제한만 적용하려고 노력하지만, 비활성화되는 활동이 몇 가지 있습니다. 즉, 인바운드 네트워크 연결은 AWS Lambda에서 차단하고, 아웃바운드 연결 전용 TCP/IP 및 UDP/IP 소켓만 지원되며 ptrace(디버깅) 시스템 호출도 차단됩니다. TCP 포트 25 트래픽도 스팸 방지 조치로 차단됩니다.

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 로그 요금이 부과됩니다.

Lambda 함수를 확장할 필요가 없습니다. AWS Lambda가 함수를 자동으로 확장합니다. 함수에 대한 이벤트 알림을 받을 때마다 AWS Lambda는 신속하게 컴퓨팅 서버 내 무료 용량을 찾아내어 코드를 실행합니다. 코드 상태가 저장되지 않으므로 AWS Lambda는 너무 긴 배포와 구성 지연 없이 필요한 만큼 많은 함수 사본을 시작할 수 있습니다. 함수를 조정하는 데 기본 제한이 없습니다. AWS Lambda는 수신 이벤트 비율에 맞춰 동적으로 용량을 할당합니다.

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

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

고객은 이제 기능을 강화하기 위해 메모리 또는 컴퓨팅 집약적 워크로드를 실행할 수 있습니다. 대용량 메모리 기능은 다중 스레드 애플리케이션의 속도를 높여 기계 학습, 배치 및 ETL 작업, 재무 모델링, 유전체학, HPC, 그리고 미디어 처리 같은 데이터 및 컴퓨팅 집약적 애플리케이션에 적합합니다.

AWS Lambda 함수는 실행당 최대 15분 동안 실행하도록 구성될 수 있습니다. 1초에서 15분 사이의 값으로 제한 시간을 설정할 수 있습니다.

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

예. Amazon EC2 및 AWS Fargate에서 비용을 절감할 뿐만 아니라, AWS Lambda에서도 Compute Savings Plans을 사용하여 Amazon EC2 및 AWS Fargate 비용을 절감할 수도 있습니다. Compute Savings Plans는 기간, 프로비저닝된 동시성 및 기간(프로비저닝된 동시성)에서 최대 17% 할인을 제공합니다. Compute Savings Plans는 Lambda 청구서에서 요청에 대한 할인을 제공하지 않습니다. 그러나 Compute Savings Plans 약정은 일반 요금으로 요청에 적용할 수 있습니다.

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

배포 시간은 코드 크기에 따라 다를 수 있지만 AWS Lambda 함수는 대개 업로드 후 몇 초 이내에 호출 준비가 됩니다.

예. AWS Lambda에서 제공한 기본 버전 외에 다른 버전을 사용하도록, 고객의 라이브러리 사본(AWS SDK 포함)을 포함할 수 있습니다.

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 요금 및 할인으로 청구됩니다. 이 약정을 통해 제공되지 않는 나머지 사용량에는 월별 집계 함수 사용 기간이 포함되는 티어에 해당하는 요율이 적용되어 요금이 청구됩니다.

이벤트 소스는 AWS Lambda 함수를 실행하도록 트리거하는 이벤트를 생성하는 AWS 서비스나 개발자가 만든 애플리케이션입니다. 일부 서비스는 클라우드 함수를 직접 호출하여(예:Amazon S3) Lambda에 이러한 이벤트를 게시합니다. 또한, Lambda는 Lambda에 이벤트를 게시하지 않는 다른 서비스에서 리소스를 폴링할 수도 있습니다. 예를 들어 Lambda는 Amazon Kinesis 스트림 또는 Amazon SQS 대기열에서 레코드를 가져와서 가져온 각 메시지에 대해 Lambda 함수를 실행할 수 있습니다. Amazon S3에 로깅하고 S3 버킷 알림을 사용하여 AWS Lambda 함수를 트리거하기만 하면 AWS CloudTrail과 같은 다른 많은 서비스를 이벤트 소스로 사용할 수 있습니다.

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

이벤트는 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 S3 버킷의 알림과 연결할 수 있습니다. 또는 Amazon S3 콘솔을 사용하여 AWS Lambda 함수에 보내도록 버킷의 알림을 구성할 수도 있습니다. AWS SDK와 CLI를 통해서도 이와 같은 기능을 사용할 수 있습니다.

테이블과 연결된 DynamoDB 스트림으로 Lambda 함수를 구독하여 DynamoDB 테이블 업데이트에 대한 Lambda 함수를 트리거할 수 있습니다. Amazon DynamoDB 콘솔, AWS Lambda 콘솔 또는 Lambda의 registerEventSource API를 사용하여 DynamoDB 스트림과 Lambda 함수를 연결할 수 있습니다.

AWS Lambda 콘솔에서 Lambda 함수를 선택하고, 선택한 함수를 동일한 계정에서 소유하고 있는 Amazon Kinesis 스트림에 연결합니다. AWS SDK와 CLI를 통해서도 이와 같은 기능을 사용할 수 있습니다.

AWS Lambda 함수로 전송되는 Amazon Kinesis 및 DynamoDB 스트림 레코드는 엄격하게 샤드별로 순서가 정해집니다. 즉, 2개의 레코드를 하나의 샤드에 저장하면 Lambda는 Lambda 함수가 첫 번째 레코드를 성공적으로 호출한 후에 두 번째 레코드를 호출하도록 보장합니다. 하나의 레코드에 대한 호출이 제한 시간을 초과하거나, 제한되거나, 다른 오류가 발생하는 경우, Lambda는 다음 레코드를 호출하기 전에 첫 번째 레코드에 대한 호출이 성공할 때까지(또는 레코드가 만료 시간인 24시간이 될 때까지) 재시도합니다. 서로 다른 샤드에서의 레코드 순서는 보장되지 않으며 각 샤드 처리는 병렬로 진행됩니다.

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

	AWS Lambda	Amazon KDA
텀블링 윈도우	예	예
스태거 윈도우	아니요	예
슬라이딩 윈도우	아니요	예
세션 윈도우	아니요	예
데이터 보강	아니요	예
인풋 및 참조 표 결합	아니요	예
인풋 스트림 쪼개기	아니요	예
한 번에 정확하게 처리	아니요	예
최대 시간 창	15분	한계 없음
집계 범위	파티션/샤드	스트림
시간 시멘틱스	이벤트 시간	이벤트 시간, 처리 시간

AWS Lambda 콘솔에서 Lambda 함수를 선택하여 Amazon SNS 주제와 연결할 수 있습니다. AWS SDK와 CLI를 통해서도 이와 같은 기능을 사용할 수 있습니다.

Amazon SES 콘솔에서 Amazon SES가 AWS Lambda 함수에 메시지를 전송하도록 수신 규칙을 설정할 수 있습니다. AWS SDK와 CLI를 통해서도 같은 기능을 사용할 수 있습니다.

먼저 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는 밀리초 내에 이벤트를 처리하도록 설계되었습니다. 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 페이지를 참조하세요.

Amazon API Gateway를 사용해 사용자 지정 RESTful API를 정의하여 HTTPS를 통해 Lambda 함수를 호출할 수 있습니다. 이를 통해 GET, PUT, POST 같은 REST 호출에 응답할 수 있도록 사용자 함수에 대한 엔드포인트가 제공됩니다. Amazon API Gateway를 통한 AWS Lambda 사용에 대해 자세히 알아보십시오.

AWS Mobile SDK에서 호출을 하면, AWS Lambda 함수가 'context' 객체를 통해 호출을 요청한 디바이스와 애플리케이션에 대한 정보를 자동으로 확보합니다.

앱이 Amazon Cognito 자격 증명을 사용하는 경우, 최종 사용자는 Amazon, Facebook, Google, 및 기타 OpenID Connect 호환 서비스 등 다양한 퍼블릭 로그인 제공자를 통해 사용자 인증을 처리할 수 있습니다. 그런 다음, 사용자 자격 증명은 Amazon Cognito의 사용자 데이터에 액세스할 수 있도록 Amazon Cognito ID 형태로 Lambda 함수에 안전하게 자동 제공되거나 Amazon DynamoDB나 다른 웹 서비스에 데이터를 저장하고 검색할 수 있도록 키로 전달됩니다.

AWS Lambda는 Alexa의 음성 기반 기능(또는 ‘기술’)을 쉽게 생성하도록 지원하는 셀프 서비스 API 모음, 도구, 설명서 및 코드 샘플인 Alexa Skills Kit와 통합됩니다. 새로운 Alexa 기술을 위한 Lambda 함수를 생성하여 업로드하기만 하면 AWS Lambda에서 나머지를 알아서 수행하여, Alexa 음성 상호 작용에 대한 응답으로 코드를 실행하고 컴퓨팅 리소스를 자동으로 관리합니다. 자세한 내용은 Alexa Skills Kit 설명서를 참조하십시오.

Amazon S3 버킷 알림 및 사용자 지정 이벤트의 경우, 코드에 오류 조건이 발생하거나 서비스 또는 리소스 한도를 초과하면 AWS Lambda는 함수 실행을 세 번 시도합니다. Amazon DynamoDB Streams, Amazon Kinesis Streams 등 AWS Lambda에서 폴링하는 순차적인 이벤트 소스의 경우 개발자 코드 오류가 발생하면 데이터가 만료될 때까지 Lambda에서 계속 실행을 시도합니다. Amazon Kinesis 및 Amazon DynamoDB 콘솔을 통해, 그리고 AWS Lambda가 함수에 대해 생성하는 Amazon CloudWatch 지표를 통해 진행 상태를 모니터링할 수 있습니다. 또한, 오류 비율 또는 실행 정체 비율을 기준으로 Amazon CloudWatch 경보를 설정할 수도 있습니다.

Lambda 기반 애플리케이션(서버리스 애플리케이션이라고도 함)은 이벤트에 의해 트리거되는 함수로 구성됩니다. 일반적으로 서버리스 애플리케이션은 Amazon S3로 객체 업로드, Amazon SNS 알림 또는 API 작업과 같은 이벤트에 의해 트리거되는 하나 이상의 함수로 구성됩니다. 이러한 함수는 독립적으로 실행되거나 DynamoDB 테이블 또는 Amazon S3 버킷과 같이 다른 리소스를 활용할 수 있습니다. 가장 기본적인 서버 없는 애플리케이션은 바로 하나의 함수입니다.

서버리스 애플리케이션은 AWS Serverless Application Model(AWS SAM)을 사용해 배포하고 관리할 수 있습니다. AWS SAM은 AWS에서 서버리스 애플리케이션을 나타내는 규칙을 규정하는 사양입니다. 이 사양은 현재 AWS CloudFormation에서 사용하는 구문과 일치하며 AWS CloudFormation 내에서 "서버리스 리소스"라고 하는 리소스 유형 세트의 형태로 기본적으로 지원됩니다. 이러한 리소스를 사용하면 AWS 고객이 CloudFormation에서 기존 CloudFormation API를 사용하여 손쉽게 서버리스 애플리케이션을 구성하고 배포할 수 있습니다.

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 리포지토리에 액세스할 수 있습니다.

AWS Lambda는 이제 컨테이너 이미지와 같은 패키지 및 배포 기능을 구현합니다. 고객은 컨테이너 도구의 탄력성 및 친밀성, 그리고 AWS Lambda의 민첩성 및 운영 단순성을 활용하여 애플리케이션을 구축할 수 있습니다.

Lambda에 대한 AWS 제공 기본 이미지나 선호하는 커뮤니티 또는 프라이빗 기업 이미지를 사용하여 시작할 수 있습니다. 그리고 이미지를 구축하기 위해 단순히 Docker CLI를 사용하고 Amazon ECR에 업로드하며, 그 다음 모든 익숙한 Lambda 인터페이스 및 도구(AWS 관리 콘솔, AWS CLI, AWS SDK, AWS SAM 및 AWS CloudFormation)를 사용해 기능을 생성합니다.

Lambda 제공 이미지 외에도 서드 파티 Linux 기반 이미지(예: Alpine 또는 Debian)를 Lambda에 배포할 수 있습니다. AWS Lambda는 다음 이미지 매니페스트 형식에 기반한 모든 이미지를 지원합니다. 도커 이미지 매니페스트 V2 스키마 2(Docker 버전 1.10 이상과 사용) 또는 Open Container Initiative(OCI) 사양(v1.0 이상). Lambda는 10GB 이상 크기의 이미지를 지원합니다.

AWS Lambda는 고객이 연장할 수 있는 다양한 기반 이미지를 제공하며, 고객은 또한 선호하는 Linux 기반 이미지를 최대 10GB 크기까지 사용할 수 있습니다.

다음 컨테이너 이미지 매니페스트 포맷 중 하나를 지원하는 모든 컨테이너 도구를 사용할 수 있습니다: Docker Image Manifest V2 Schema 2 (Docker 버전 1.10 이상과 사용) 또는 Open Container Initiative (OCI) Specifications (v1.0 이상). 예를 들어 자연 컨테이너 도구 (예: docker run, docker compose, Buildah and Packer)를 사용하여 컨테이너 이미지로서의 기능을 정의하고 Lambda에 배포할 수 있습니다.

모든 기존 AWS Lambda 기능은 Lambda 레이어 및 코드 서명을 제외하면 컨테이너 이미지로 배포한 기능으로 사용할 수 있습니다. 한 번 배포하면 AWS Lambda는 이미지를 변경할 수 없게 취급합니다. 고객은 컨테이너 레이어를 프로세서를 구축할 때 사용하여 의존성을 포함시킵니다.

현재는 지원되지 않습니다. AWS Lambda에 배포한 사용자의 이미지는 변경할 수 없게 됩니다. 이 서비스는 해당 이미지를 패치하거나 업데이트하지 않습니다. 하지만 AWS Lambda는 Lambda 관리 환경에 기반한 모든 지원 런타임용 큐레이팅한 기반 이미지를 게시할 것입니다. 이 게시 이미지는 AWS Lambda 관리 런타임에 대한 업데이트와 함께 패치 및 업데이트될 것입니다. 최신 기반 이미지를 DockerHub 또는 Amazon ECR Public에서 끌어다 사용하고, 컨테이너 이미지를 재구축하며 AWS Lambda에 Amazon ECR을 통해 배포할 수 있습니다. 이를 통해 이미지를 프로덕션에 배포하기에 앞서 업데이트된 이미지와 실행 시간을 구축 및 테스트할 수 있습니다.

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

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

아니요, AWS Lambda는 컨테이너 이미지로 패키징한 기능용 성능 프로파일을 ZIP 아카이브로 패키징한 것과 일반적으로 초 이하 시작 시간을 포함하여 동일하게 보장합니다.

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 상의 오픈 소스입니다. 로컬 기계에 다운로드 및 설치하여 시작할 수 있습니다.

실행 중인 Lambda 서비스 내 Lambda Runtime API는 JSON 이벤트를 수락하고 반응을 돌려보냅니다. Lambda Runtime Interface Emulator는 컨테이너 이미지로 패키징된 기능을 허용하여 cURL 등의 도구를 사용하는 로컬 테스팅 중 HTTP 요청을 수락하고, 기능에 로컬적으로 동일한 인터페이스를 통해 이러한 요청을 표면화합니다. 도커 런 또는 도커 구성 업 커맨드를 사용하여 Lambda 애플리케이션을 로컬 테스트할 수 있게 합니다.

함수 코드가 Lambda 환경에서 호환되고, 성공적으로 실행되며 예상되는 출력을 제공할 수 있다면 에뮬레이터를 사용할 수 있습니다. 예를 들어, 테스트 이벤트를 다른 이벤트 소스에서 모방할 수 있습니다. 또한 이를 사용해 컨테이너 이미지 속에 구축된 익스텐션 및 에이전트를 Lambda Extensions API에 대하여 테스트할 수 있습니다.

고객은 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 Lambda SnapStart for Java는 함수 시작 성능을 최대 10배 높여줍니다. 온디맨드 함수의 경우 초기화 단계(AWS Lambda가 함수 코드를 로드하고 외부 종속성을 초기화하는 단계)는 시작 지연 시간을 늘리는 가장 큰 요인이며 첫 번째 호출 시 발생합니다. Lambda SnapStart를 사용하면 함수를 처음 호출할 때가 아니라 함수 버전을 로드할 때 Lambda가 미리 일회성 초기화 함수 코드를 초기화합니다. 그런 다음 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)을 사용하여 신규 및 기존 Java 함수에 대해 구성할 수 있는 단순한 함수 수준 구성입니다. Lambda SnapStart를 구성하면 후에 게시되는 모든 함수 버전에 Lambda SnapStart가 제공하는 개선된 시작 성능이 적용됩니다. Lambda SnapStart에 대해 자세히 알아보려면 설명서를 참조하세요.

Lambda SnapStart는 일회성 초기화 코드의 실행 중에 발생하는 가변 지연 시간을 줄여 Java 함수의 시작 시간을 최대 10배 빠르게 하는 데 도움이 되는 성능 최적화입니다. Lambda SnapStart는 추가 비용 없이 애플리케이션 또는 계정의 모든 함수에 광범위하게 사용할 수 있습니다. Lambda SnapStart를 사용하여 함수 버전을 게시하면 함수의 코드가 첫 호출 시 초기화되는 것이 아니라 미리 초기화됩니다. Lambda는 초기화된 실행 환경의 스냅샷을 생성하고 계층화된 개시로 이를 유지하여 액세스 지연 시간을 줄여줍니다. 함수가 처음 호출된 후 크기 조정될 때 Lambda는 처음부터 초기화를 시작하는 대신 캐시된 스냅샷에서 함수를 다시 시작하여 시작 지연 시간을 줄여줍니다. Lambda SnapStart는 시작 지연 시간을 줄여주지만 가능한 범위 내에서만 최적화하며 콜드 스타트를 완전히 없애주지는 않습니다. 애플리케이션의 지연 시간 요구 사항이 엄격하고 시작 시간이 99밀리초 이내여야 하는 경우 PC를 사용하는 것이 좋습니다.

Lambda SnapStart는 Java 11 런타임을 지원합니다. 향후 버전의 Java는 버전이 릴리스된 후 지원될 것입니다. Lambda가 지원하는 모든 런타임은 Lambda 런타임 설명서를 참조하세요.

아니요. Lambda SnapStart와 PC를 동일한 함수에 동시에 사용할 수는 없습니다.

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

아니요. 지금은 x86 아키텍처에서 실행되는 함수에만 Lambda SnapStart를 구성할 수 있습니다.

아니요. 지금은 Amazon EFS에서 Lambda SnapStart를 사용할 수 없습니다.

아니요. 지금은 512MB를 초과하는 대형 임시 스토리지(/tmp)에 Lambda SnapStart를 사용할 수 없습니다.

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

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

아니요. Lambda SnapStart 사용에 대한 추가 요금은 없습니다. 현재 Lambda 요금을 기준으로 함수 요청 수와 코드 실행 기간에 따른 요금이 청구됩니다. 기간 요금은 함수의 핸들러 및 런타임 후크에서 실행되는 코드와 핸들러 외부에 선언된 초기화 코드에 적용됩니다. 참고로 AWS Lambda는 보안 패치로 실행 환경을 주기적으로 재순환하며 초기화 코드를 다시 실행합니다. 자세한 내용은 Lambda 프로그래밍 모델 설명서를 참조하세요.

Lambda SnapStart를 사용할 때 초기화된 실행 환경의 스냅샷은 마지막으로 게시된 함수 버전 3개에 대해 게시된 버전이 호출을 수신하는 동안 유지됩니다. 게시된 함수 버전에 연결된 스냅샷은 14일 이상 비활성 상태로 유지되는 경우 만료됩니다.

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

Lambda SnapStart에서 허용되는 최대 초기화 기간은 함수에 구성된 실행 시간 초과 기간과 일치합니다. 함수에 구성할 수 있는 최대 실행 시간 초과 제한은 15분입니다.

프로비저닝된 동시성을 통해 서버리스 애플리케이션 성능을 보다 강력하게 제어할 수 있습니다. 프로비저닝된 동시성을 활성화하면 두 자리 수 밀리초로 응답하기 위해 기능을 초기화하고 극도의 준비 상태를 유지합니다.

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

프로비저닝된 동시성을 사용하기 위해 코드를 변경할 필요가 없습니다. 기존의 모든 기능 및 런타임과 완벽하게 작동합니다. 프로비저닝된 동시성을 사용할 때 Lambda 호출 및 실행 모델이 변경되지 않습니다.

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

프로비저닝된 동시성은 웹 또는 모바일 백엔드, 동기식으로 호출되는 API, 대화식 마이크로서비스와 같이 대기 시간에 민감한 애플리케이션을 구축하는 데 안성맞춤입니다. 애플리케이션의 고유한 요구를 기반으로 알맞은 동시성 크기를 쉽게 구성할 수 있습니다. 요구가 많은 시간에는 동시성 크기를 늘리고 요구가 적어지면 크기를 줄이거나 완전히 끌 수 있습니다.

함수 동시성이 구성된 수준에 도달하면 이후의 함수 호출은 일반 Lambda 함수의 지연 시간 및 확장 특성을 갖게 됩니다. 구성된 수준까지만 확장되도록 함수를 제한할 수 있습니다. 이렇게 하면 함수는 프로비저닝된 동시성의 구성된 수준을 초과하지 않습니다. 이는 요구가 예상 크기를 초과할 때 애플리케이션에서 원하지 않는 변동을 방지하는 메커니즘입니다.

AWS Lambda를 사용하면 x86 기반 또는 Arm 기반 프로세서에서 기능을 실행할 수 있습니다. AWS Graviton2 프로세서는 64비트 Arm Neoverse 코어를 사용하여 Amazon Web Services에서 맞춤형으로 구축하여 클라우드 워크로드에 대해 향상된 가격 대비 성능을 제공합니다. 고객은 AWS Lambda와 동일한 이점, 즉 서버를 프로비저닝하거나 관리하지 않고 코드를 실행하고, 자동 크기 조정, 고가용성, 사용한 리소스에 대해서만 비용을 지불하는 이점을 누릴 수 있습니다.

AWS가 설계한 Arm 기반 프로세서 아키텍처를 사용하는 Graviton2 기반의 AWS Lambda 함수는 웹 및 모바일 백엔드, 데이터 및 스트림 처리와 같은 다양한 서버리스 워크로드에 대해 x86 프로세서에서 실행되는 기능에 비해 최대 34% 더 나은 가격 대비 성능을 제공하도록 설계되었습니다. 더 짧은 대기 시간, 최대 19% 더 나은 성능, 20% 더 낮은 비용 및 현재 AWS에서 사용할 수 있는 최고의 전력 효율성을 갖춘 Graviton2 기능은 미션 크리티컬 서버리스 애플리케이션을 지원할 수 있습니다. 고객은 Graviton2 프로세서를 대상으로 기존 기능과 새 기능을 모두 구성할 수 있습니다. 또한 Graviton2에서 실행되는 기능을 zip 파일 또는 컨테이너 이미지로 배포할 수 있습니다.

기능에 대해 아키텍처 플래그를 'arm64'로 설정해 AWS 관리 콘솔, AWS Lambda API, AWS CLI 및 AWS CloudFormation을 통해 Graviton2에서 실행되도록 기능을 구성할 수 있습니다.

x86 기반 기능과 Arm 기반 기능 간에는 변경 사항이 없습니다. AWS 관리 콘솔, zip 파일 또는 컨테이너 이미지를 통해 코드를 업로드하기만 하면 인프라를 프로비저닝하거나 관리할 필요 없이 AWS Lambda가 트리거될 때 자동으로 코드를 실행합니다.

애플리케이션은 두 아키텍처에서 실행되는 기능을 포함할 수 있습니다. AWS Lambda를 사용하면 함수의 현재 버전의 아키텍처('x86_64' 또는 'arm64')를 변경할 수 있습니다. 함수의 특정 버전을 만든 후에는 아키텍처를 변경할 수 없습니다.

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

아니요. 각 기능 버전은 단일 컨테이너 이미지만 사용할 수 있습니다.

예. 레이어 및 확장은 'x86_64' 또는 'arm64' 호환 아키텍처를 대상으로 할 수 있습니다. 기능 및 계층의 기본 아키텍처는 'x86_64'입니다.

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

AWS Graviton2 프로세서로 구동되는 AWS Lambda 함수는 x86 기반 Lambda 함수에 비해 20% 저렴합니다. Lambda 프리 티어는 x86 및 Arm 기반 아키텍처로 구동되는 AWS Lambda 함수에 적용됩니다.

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

AWS Lambda용 Amazon Elastic File System(Amazon EFS)을 사용하는 고객은 온디맨드로 확장할 수 있는 탄력적인 완전관리형 NFS 시스템을 사용하여 대용량 데이터를 거의 모든 규모로 안전하게 읽고, 쓰고, 유지할 수 있으며, 이를 위해 프로비저닝하거나 용량을 관리할 필요가 없습니다. 이전에는 개발자가 S3 또는 데이터베이스의 데이터를 로컬 임시 스토리지로 다운로드하기 위한 코드를 함수에 추가했으며, 용량도 512MB로 제한되었습니다. Lambda용 EFS를 사용함에 따라 개발자는 처리할 데이터를 임시 스토리지로 다운로드하기 위한 코드를 작성할 필요가 없습니다.

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

예. Amazon EFS에 대한 탑재 대상은 VPC의 서브넷과 연결됩니다. 따라서 이 VPC에 액세스하도록 AWS Lambda 함수를 구성해야 합니다.

Lambda용 EFS는 기계 학습 애플리케이션 구축이나 대규모 참조 파일 또는 모델 로드, 대용량 데이터 처리 또는 백업, 웹 콘텐츠 호스팅 또는 내부 구축 시스템 개발 시 사용하기에 적합합니다. 또한 고객은 Lambda용 EFS를 사용하여 Step Functions 워크플로에서 상태 저장 마이크로서비스 아키텍처 내의 호출 간 상태를 유지하거나, 서버리스 애플리케이션과 인스턴스 또는 컨테이너 기반 애플리케이션 간에 파일을 공유할 수 있습니다.

예. 전송 데이터 암호화에서는 업계 표준 Transport Layer Security(TLS) 1.2를 사용하여 AWS Lambda 함수와 Amazon EFS 파일 시스템 간에 전송되는 데이터를 암호화합니다.

고객은 Amazon EFS를 사용하여 저장 데이터를 암호화할 수 있습니다. 암호화된 저장 데이터는 작성되면서 투명하게 암호화되고 읽어 들이면서 투명하게 복호화되므로, 애플리케이션을 수정할 필요가 없습니다. 암호화 키는 AWS Key Management Service(KMS)에서 관리하므로 보안 키 관리 인프라를 구축하고 유지 관리할 필요가 없습니다.

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

아니요. 각 Lambda 함수는 하나의 EFS 파일 시스템에만 연결할 수 있습니다.

예. Amazon EFS에서는 Lambda 함수, ECS 및 Fargate 컨테이너, EC2 인스턴스를 지원합니다. 동일한 파일 시스템을 공유하고 IAM 정책 및 액세스 포인트를 사용하여 액세스할 수 있는 각각의 함수, 컨테이너 또는 인스턴스의 액세스를 제어할 수 있습니다.  

예. 함수 URL, 브라우저를 사용하여 호출할 수 있는 기본 제공 HTTPS 엔드포인트, curl 및 모든 HTTP 클라이언트로 Lambda 함수를 구성할 수 있습니다. 함수 URL은 HTTPS로 액세스 가능한 함수를 쉽게 작성할 수 있는 방법입니다.

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

Lambda 함수 URL은 기본적으로 IAM 권한 부여로 보호됩니다. IAM 권한 부여를 사용 중지하여 퍼블릭 엔드포인트를 생성하거나 함수의 비즈니스 로직의 일부로 사용자 정의 권한 부여를 구현하도록 선택할 수 있습니다.

Lambda URL로 이동하여 웹 브라우저에서 함수를 호출하거나, HTTP 라이브러리를 사용하여 클라이언트 애플리케이션의 코드에서 함수를 호출하거나, curl을 사용하여 명령줄에서 함수를 간편하게 호출할 수 있습니다.

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

함수 URL은 현재 사용자 정의 도메인 이름을 지원하지 않습니다. Amazon CloudFront 배포와 CNAME을 생성하여 사용자 정의 도메인을 CloudFront 배포 이름에 매핑하는 방법으로 함수 URL에 사용자 지정 도메인을 사용할 수 있습니다. 그런 다음 함수 URL로 라우팅되도록 CloudFront 배포 도메인 이름을 원본으로 매핑합니다.

예. 함수 URL을 사용하여 VPC에서 Lambda 함수를 호출할 수 있습니다.

함수 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는 복제 및 중복성을 사용하여 서비스 자체와 서비스가 실행하는 Lambda 함수 모두에 뛰어난 가용성을 제공하도록 설계되었습니다. 유지 관리 기간이나 예약된 가동 중지 시간이 없습니다.

예. Lambda 함수 업데이트 시, 일반적으로 1분 이내로 약간의 시간이 생깁니다. 이 시간 동안 함수의 이전 버전 또는 신규 버전으로 요청이 실행됩니다.

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의 규모 조정 속도를 사용하면 추가 구성이나 도구 없이 이러한 사용 사례를 더 편리하게 수행할 수 있습니다. 또한, 동시성 조정 제한은 함수 수준 제한으로, 계정의 각 함수가 다른 함수와 독립적으로 규모 조정됩니다.

오류 발생 시, 동기적으로 호출된 Lambda 함수는 예외와 함께 응답합니다. 비동기식으로 호출된 Lambda 함수는 최소한 3번 재시도됩니다. Amazon Kinesis Streams와 Amazon DynamoDB Streams의 이벤트는 Lambda 함수가 성공하거나 데이터가 만료될 때까지 재시도됩니다. Kinesis 및 DynamoDB Streams는 최소한 24시간 동안 데이터를 유지합니다.

Amazon SQS 대기열 또는 Amazon SNS 주제를 데드레터큐로 구성할 수 있습니다.

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

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

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

Lambda 함수 역할을 통해 액세스 제어를 관리합니다. Lambda 함수에 지정한 역할에서 AWS Lambda가 폴링할 수 있는 리소스도 대신 결정하게 됩니다. 자세한 내용은 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 Management Console, Lambda API, AWS CLI, AWS CloudFormation 및 AWS SAM을 통해 코드 서명 구성을 생성하여 코드 서명을 구현할 수 있습니다. 코드 서명 구성은 승인된 서명 프로파일을 명시하고 서명 확인에 실패하면 배포를 경고 또는 거절하도록 구성하게 지원합니다. 코드 서명 구성은 개별 Lambda 기능에 추가하여 코드 서명 기능을 구현할 수 있습니다. 이제 배포에서 해당 기능이 서명 확인을 시작합니다.

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

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

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

네, 기존 기능에 대한 코드 서명을 코드 서명 구성을 해당 기능에 추가하여 활성화할 수 있습니다. 이 과정을 AWS Lambda console, Lambda API, AWS CLI, AWS CloudFormation 및 AWS SAM을 사용하여 수행할 수 있습니다.

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 요금 페이지를 참조하세요.

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

Lambda는 Amazon Linux openjdk 1.8 빌드를 제공합니다.

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

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

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

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

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

예. PIP를 사용해 필요한 모든 Python 패키지를 설치할 수 있습니다.

Visual Studio IDE를 사용하여 Solution Explorer에서 [AWS Lambda에 게시]를 선택하여 C# Lambda 함수를 생성할 수 있습니다. 또는 [# Lambda CLI 도구 패치]가 설치된 dotnet CLI에서 "dotnet lambda publish" 명령을 직접 실행할 수 있습니다. 이렇게 하면 게시된 DLL 어셈블리뿐만 아니라 모든 NuGet 종속성과 함께 C# 소스 코드의 ZIP 파일을 생성하고 런타임 파라미터인 "dotnetcore1.0"을 사용하여 AWS Lambda로 자동 업로드할 수 있습니다.

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

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

Ruby로 작성된 Lambda 함수를 배포하려면 Ruby 코드와 젬을 ZIP 파일로 패키징합니다. 로컬 환경에서 ZIP 파일을 업로드하거나 ZIP 파일이 있는 Amazon S3 위치를 지정할 수 있습니다.

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

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

AWS Lambda는 AWS CloudTrail과 통합되어 있습니다. AWS CloudTrail은 계정의 API 사용을 설명하는 로그 파일을 기록하고 Amazon S3 버킷에 전송할 수 있습니다.

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

네, AWS Lambda는 Advanced Vector Extensions 2 (AVX2) 지침 세트를 지원합니다. 향상된 성능용으로 설정한 이 지침을 목표로 하는 애플리케이션 코드를 컴파일하는 방법에 대해 자세히 알아보려면 AWS Lambda 개발자 설명서를 참조하세요.