AWS Lambda FAQ

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

AWS Lambda는 기본적으로 Java, Go, PowerShell, Node.js, C#, Python 및 Ruby 코드를 지원하며, 그 밖에 프로그래밍 언어를 사용해 함수를 작성할 수 있도록 Runtime API도 제공합니다. Node.js, Python, Java, Ruby, C#, Go 및 PowerShell 사용에 대한 설명서를 참조하세요.

각 AWS Lambda 함수는 격리된 자체 환경에서 자체 리소스와 파일 시스템 보기로 실행됩니다. AWS Lambda는 Amazon EC2와 동일한 기술을 사용하여 인프라와 실행 수준에서 보안과 분리를 제공합니다. 자세한 내용은 설명서에서 확인하세요.

AWS Lambda는 Amazon S3에 코드를 저장하고 저장된 데이터를 암호화하고, 코드를 사용하는 동안 추가 무결성 검사를 수행합니다. 데이터베이스 암호와 같은 민감한 정보는 AWS Key Management Service를 사용하여 클라이언트 측 암호화를 수행한 후 환경 변수에 결과 값을 사이퍼텍스트로 저장하는 것이 좋습니다. 이러한 값을 복호화하는 로직을 AWS Lambda 함수 코드에 추가해야 합니다. 자세한 내용은 설명서에서 확인하세요.

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

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

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

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

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

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

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

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

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

AWS Lambda는 유연한 배포 옵션을 제공합니다. 콘솔, CLI 또는 SDK를 통해 직접 업로드하거나 컨테이너 이미지로 업로드할 수 있는 .zip 파일 아카이브로 함수를 패키징하고 배포할 수 있습니다. 두 방법 모두 동일한 실행 환경, 확장성 및 운영 단순성을 제공하므로 워크플로에 가장 적합한 접근 방식을 선택할 수 있는 유연성을 보장합니다.

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

AWS Lambda 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 설명서를 참조하세요.

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

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

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

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

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

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

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

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

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

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 함수와 해당 종속성 간의 상호 작용을 보여주는 사전 구축되고 표준화된 대시보드를 제공합니다. 이 모든 작업은 개발자의 수동 계측이나 코드 변경이 필요하지 않습니다.

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

Lambda의 익숙한 프로그래밍 모델 내에서 로컬 테스트, IDE 통합, 선호하는 프로그래밍 언어를 사용하여 로직을 구축하려는 경우 Lambda 내구성 함수를 사용하세요. 시각적 워크플로 디자인, 팀 간 가시성, 220개 이상의 기본 서비스 통합 또는 유지 관리 없는 인프라가 필요한 경우 AWS Step Functions를 사용하세요. 이 2가지를 함께 사용하면 많은 경우에 유용합니다.

AWS Lambda 내구성 함수는 현재 JavaScript, TypeScript, Python, Java를 지원합니다. 지원되는 런타임에 대해 자세히 알아보세요.

최신 업데이트된 가용성은 리전별 AWS 기능 페이지에서 확인하세요.

예. 호출당 제한 시간은 15분으로 유지되지만, Lambda 내구성 함수는 타이머, 콜백, 폴링 조건과 같은 대기 기능을 사용하여 여러 간접 호출을 일시 중단하고 재개할 수 있습니다. 내구성 함수를 비동기식으로 간접 호출하면 내구성 실행 제한 시간이 최대 1년까지 연장되어 인간-승인 워크플로, 예약된 알림, 며칠이 걸리는 처리 파이프라인과 같은 사용 사례가 가능해집니다. 온디맨드 함수의 경우 일시 정지 기간 동안에는 컴퓨팅 요금이 부과되지 않습니다.

실행 제한 시간(최대 1년)은 실행 가능 기간을 결정합니다. 보존 기간(최대 90일)은 실행이 최종 상태에 도달한 후 기록 및 체크포인트 데이터를 보존하는 기간을 결정합니다. 보존은 실행 중인 실행에 영향을 주지 않습니다. 내구성 함수 구성을 참조하세요.

아니요. 온디맨드 함수의 경우, 내구성 실행 SDK의 대기 기능을 사용하면 일시 중단 중에 컴퓨팅 비용이 발생하지 않습니다. 자세한 내용은 요금 페이지 및 개발자 안내서를 참조하세요.

각 작업 단위를 자동 재시도가 적용되는 한 단계로 래핑할 수 있습니다. 재시도 후 단계가 실패하면 핸들러 코드가 오류를 포착하고 결제 환불 또는 예약 취소와 같은 보상 단계를 실행할 수 있습니다. 보상을 포함하여 완료된 각 단계가 체크포인트로 처리되기 때문에 성공적으로 완료된 작업은 재시도 시 반복되지 않습니다. 이 패턴을 사용하면 사용자 지정 재시도 및 상태 추적 로직을 작성하지 않고도 주문 처리 또는 결제 워크플로와 같은 신뢰할 수 있는 다단계 프로세스를 구축할 수 있습니다.

실행 상태는 완전 관리형 내부 상태 저장소에 저장됩니다. 각 체크포인트 작업(예: 단계 또는 콜백)은 최대 256KB의 데이터를 저장할 수 있습니다. 이 제한은 작업에서 반환되는 데이터에 적용됩니다. 대규모 S3 객체 읽기와 쓰기 등, 작업 내에서 작업한 데이터는 이 제한에 포함되지 않습니다. 작업에서 대용량 결과를 반환해야 하는 경우 SDK에서 사용자 지정 직렬화 항목을 구성하여 페이로드를 Amazon S3 또는 Amazon DynamoDB로 오프로드하고 체크포인트를 통해 참조만 전달할 수 있습니다.

Lambda 내구성 함수는 표준 Lambda 함수와 동일한 계정 수준 동시성 풀을 사용합니다. 동시 실행 슬롯은 대기 중에 해제되므로 동시 실행 시간을 소비하지 않고도 수천 건의 실행이 대기할 수 있습니다. AWS Lambda 할당량에 대해 자세히 알아보세요.

지원되는 프로그래밍 언어의 내구성 실행 SDK를 사용하여 AWS 자격 증명 없이 로컬에서 내구성 함수를 테스트할 수 있습니다. 또한 AWS SAM CLI는 로컬 간접 호출, 콜백, 내구성 실행 관리를 지원하므로 배포 전에 쉽게 개발하고 디버깅할 수 있습니다. 내구성 함수 테스트에 대해 자세히 알아보세요.