# Lambda가 스트림 및 대기열 기반 이벤트 소스의 레코드를 처리하는 방법
**이벤트 소스 매핑은 스트림 및 대기열 기반 서비스에서 항목을 읽고 레코드 배치로 함수를 간접적으로 간접 호출하는 Lambda 리소스입니다. 이벤트 소스 매핑 내에서 *이벤트 폴러*라고 하는 리소스는 새 메시지를 적극적으로 폴링하고 함수를 간접 호출합니다. 기본적으로 Lambda는 이벤트 폴러 크기를 자동으로 조정하지만 특정 이벤트 소스 유형의 경우 [프로비저닝된 모드](#invocation-eventsourcemapping-provisioned-mode)를 사용하여 이벤트 소스 매핑 전용 이벤트 폴러의 최소 및 최대 수를 제어할 수 있습니다.
다음 서비스는 이벤트 소스 매핑을 사용하여 Lambda 함수를 간접적으로 간접 호출합니다.
+ [Amazon DocumentDB(MongoDB 호환) (Amazon DocumentDB)](with-documentdb.md)
+ [Amazon DynamoDB](with-ddb.md)
+ [Amazon Kinesis](with-kinesis.md)
+ [Amazon MQ](with-mq.md)
+ [Amazon Managed Streaming for Apache Kafka(Amazon MSK)](with-msk.md)
+ [자체 관리형 Apache Kafka](with-kafka.md)
+ [Amazon Simple Queue Service(Amazon SQS)](with-sqs.md)
**주의**
Lambda 이벤트 소스 매핑은 각 이벤트를 한 번 이상 처리하므로 레코드가 중복될 수 있습니다. 중복 이벤트와 관련된 잠재적 문제를 방지하려면 함수 코드를 멱등성으로 만드는 것이 좋습니다. 자세한 내용은 AWS 지식 센터의 [함수를 멱등성 Lambda 함수로 만들려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/lambda-function-idempotent)를 참조하세요.
## 이벤트 소스 매핑과 직접 트리거의 차이점
일부 AWS 서비스에서는 *트리거*를 사용하여 바로 Lambda 함수를 간접 호출할 수 있습니다. 이러한 서비스는 Lambda로 이벤트를 푸시하고, 지정된 이벤트가 발생하면 함수가 즉시 간접적으로 간접 호출됩니다. 트리거는 개별 이벤트와 실시간 처리에 적합합니다. [Lambda 콘솔을 사용하여 트리거를 생성](lambda-services.md#lambda-invocation-trigger)하면 콘솔은 해당 AWS 서비스와 상호 작용하여 서비스에 대한 이벤트 알림을 구성합니다. 트리거는 실제로 Lambda가 아니라 이벤트를 생성하는 서비스에 의해 저장되고 관리됩니다. 다음은 트리거를 사용하여 Lambda 함수를 간접적으로 간접 호출하는 서비스의 몇 가지 예입니다.
+ **Amazon Simple Storage Service(Amazon S3)**: 버킷에서 객체가 생성, 삭제 또는 수정될 때 함수를 간접적으로 호출합니다. 자세한 내용은 [자습서: Amazon S3 트리거를 사용하여 Lambda 함수 간접 호출](with-s3-example.md) 섹션을 참조하세요.
+ **Amazon Simple Notification Service(Amazon SNS)**: SNS 주제에 메시지가 게시될 때 함수를 간접적으로 간접 호출합니다. 자세한 내용은 [자습서: Amazon Simple Notification Service에서 AWS Lambda 사용](with-sns-example.md) 섹션을 참조하세요.
+ **Amazon API Gateway:** 특정 엔드포인트에 대한 API 요청 시 함수를 간접적으로 간접 호출합니다. 자세한 내용은 [Amazon API Gateway 엔드포인트를 사용하여 간접적으로 Lambda 함수 호출](services-apigateway.md) 섹션을 참조하세요.
이벤트 소스 매핑은 Lambda 서비스 내에서 생성되고 관리되는 Lambda 리소스입니다. 이벤트 소스 매핑은 대기열의 대용량 스트리밍 데이터 또는 메시지를 처리하도록 설계되었습니다. 스트림이나 대기열의 레코드를 일괄적으로 처리하는 것이 레코드를 개별적으로 처리하는 것보다 더 효율적입니다.
## 일괄 처리 동작
기본적으로 이벤트 소스 매핑은 레코드를 일괄 처리하고 Lambda는 이를 단일 페이로드로 함수에 전송합니다. 일괄 처리 동작을 미세 조정하려면 배치 기간([MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds))과 배치 크기([BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BatchSize))를 구성합니다. 일괄 처리 기간은 레코드를 단일 페이로드로 수집할 최대 기간입니다. 배치 크기는 단일 배치의 최대 레코드 수입니다. Lambda는 다음 세 가지 기준 중 하나에 부합할 때 함수를 간접 호출합니다.
+ **일괄 처리 기간이 최댓값에 도달합니다.** 기본 일괄 처리 기간 동작은 특정 이벤트 소스에 따라 다릅니다.
+ **Kinesis, DynamoDB 및 Amazon SQS 이벤트 소스의 경우:** 기본 일괄 처리 기간은 0초입니다. 즉, Lambda는 레코드가 사용 가능하게 되는 즉시 함수를 간접 호출합니다. 배치 작업 기간을 설정하려면 `MaximumBatchingWindowInSeconds`를 구성합니다. 이 파라미터를 0\$1300초 범위에서 초 단위로 설정할 수 있습니다. 일괄 처리 기간을 구성하는 경우, 이전 함수 간접 호출이 완료되는 즉시 다음 기간이 시작됩니다.
+ **Amazon MSK, 자체 관리형 Apache Kafka 및 Amazon MQ, Amazon DocumentDB 이벤트 소스의 경우** 기본 일괄 처리 시간은 500ms입니다. `MaximumBatchingWindowInSeconds`는 0초에서 300초 사이의 값을 초 단위로 구성할 수 있습니다. Kafka 이벤트 소스 매핑에 대한 프로비저닝 모드에서 배치 기간을 구성하면 이전 배치가 완료되는 즉시 다음 기간이 시작됩니다. 프로비저닝되지 않은 Kafka 이벤트 소스 매핑에서 배치 기간을 구성하면 이전 함수 간접 호출이 완료되는 즉시 다음 기간이 시작됩니다. 프로비저닝 모드에서 Kafka 이벤트 소스 매핑을 사용할 때 지연 시간을 최소화하려면 `MaximumBatchingWindowInSeconds`를 0으로 설정합니다. 이 설정을 사용하면 Lambda가 현재 함수 간접 호출을 완료한 직후 다음 배치 처리를 시작할 수 있습니다. 저지연 처리에 대한 자세한 내용은 [지연 시간이 짧은 Apache Kafka](with-kafka-low-latency.md) 섹션을 참조하세요.
+ **Amazon MQ 및 Amazon DocumentDB 이벤트 소스의 경우** 기본 배치 시간은 500ms입니다. `MaximumBatchingWindowInSeconds`는 0초에서 300초 사이의 값을 초 단위로 구성할 수 있습니다. 일괄 처리 기간은 첫 번째 레코드가 도착하는 즉시 시작됩니다.
**참고**
`MaximumBatchingWindowInSeconds`는 초 단위로만 변경할 수 있기 때문에 변경한 후에는 500ms 기본 배치 기간으로 되돌릴 수 없습니다. 기본 일괄 처리 기간을 복원하려면 새 이벤트 소스 매핑을 생성해야 합니다.
+ **배치 크기가 충족됩니다.** 최소 배치 크기는 1입니다. 기본 및 최대 배치 크기는 이벤트 소스에 따라 다릅니다. 이러한 값에 대한 자세한 내용은 `CreateEventSourceMapping` API 작업에 대한 [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize) 사양을 참조하세요.
+ **페이로드 크기가 [6MB](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)에 도달합니다.** 이 한도는 수정할 수 없습니다.
다음 다이어그램은 이 세 가지 조건을 보여줍니다. 일괄 처리 기간이 `t = 7`초에서 시작한다고 가정합니다. 첫 번째 시나리오에서는 5개의 레코드를 누적한 후 일괄 처리 기간이 `t = 47`초로 2차 최댓값인 40에 도달합니다. 두 번째 시나리오에서는 일괄 처리 기간이 만료되기 전에 배치 크기가 10에 도달하므로 일괄 처리 기간이 일찍 종료됩니다. 세 번째 시나리오에서는 일괄 처리 기간이 만료되기 전에 최대 페이로드 크기에 도달하므로 일괄 처리 기간이 일찍 종료됩니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/batching-window.png)
각 이벤트 소스의 폴링 빈도를 함수가 작업을 완료할 수 있는 속도에 맞게 조정할 수 있도록 다양한 배치 및 레코드 크기로 테스트하는 것이 좋습니다. [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) `BatchSize` 파라미터는 각 간접 호출에서 함수로 보낼 수 있는 최대 레코드 수를 제어합니다. 배치 크기가 클수록 더 큰 레코드 세트에서 간접 호출 오버헤드를 더 효율적으로 수용하여 처리량을 늘릴 수 있습니다.
Lambda는 처리를 위해 다음 배치를 전송하기 전에 구성된 [확장](lambda-extensions.md)이 완료될 때까지 기다리지 않습니다. 즉, Lambda가 다음 레코드 배치를 처리할 때 확장이 계속 실행될 수 있습니다. 이로 인해 계정의 [동시성](lambda-concurrency.md) 설정 또는 스로틀링을 위반하는 경우 제한 문제가 발생할 수 있습니다. 이것이 잠재적인 문제인지 여부를 탐지하려면 함수를 모니터링하고 이벤트 소스 매핑에 대해 예상보다 높은 [동시성 지표](monitoring-concurrency.md#general-concurrency-metrics)가 표시되는지 확인하세요. 간접 호출 간격이 짧기 때문에 Lambda는 일시적으로 동시성 사용량을 샤드 수보다 더 높게 보고할 수 있습니다. 확장이 없는 Lambda 함수에서도 마찬가지입니다.
기본적으로, 함수가 오류를 반환하는 경우 이벤트 소스 매핑은 함수가 성공할 때까지 또는 배치에 있는 항목이 만료될 때까지 전체 배치를 다시 처리합니다. 순차적 처리를 위해 이벤트 소스 매핑은 오류가 해결될 때까지 영향을 받은 샤드에 대한 처리를 일시 중지합니다. 스트림 소스(DynamoDB 및 Kinesis)의 경우, 함수에서 오류가 반환될 때 Lambda가 재시도하는 최대 횟수를 구성할 수 있습니다. 배치가 함수에 도달하지 않는 서비스 오류 또는 제한은 재시도 횟수에 반영되지 않습니다. 이벤트 배치를 삭제할 때 간접 호출 레코드를 [대상](invocation-async-retain-records.md#invocation-async-destinations)으로 보내도록 이벤트 소스 매핑을 구성할 수도 있습니다.
## 프로비저닝된 모드
Lambda 이벤트 소스 매핑은 이벤트 폴러를 사용하여 새 메시지에 대해 이벤트 소스를 폴링합니다. 기본적으로 Lambda에서 메시지 볼륨에 따라 이러한 폴러의 자동 규모 조정을 관리합니다. 메시지 트래픽이 증가하면 Lambda는 로드를 처리할 이벤트 폴러 수를 자동으로 늘리고 트래픽이 감소하면 줄입니다.
프로비저닝 모드에서는 예상 트래픽 패턴의 처리 준비 상태가 유지되는 전용 폴링 리소스에 대한 최소 및 최대 제한을 정의하여 이벤트 소스 매핑의 처리량을 미세 조정할 수 있습니다. 이러한 리소스는 이벤트 트래픽의 갑작스러운 급증을 처리하기 위해 3배 더 빠른 속도로 자동 조정되며 수백만 개의 이벤트를 처리하기 위해 16배 더 많은 용량을 제공합니다. 이를 통해 엄격한 성능 요구 사항을 충족하는 응답성이 뛰어난 이벤트 기반 워크로드를 구축할 수 있습니다.
Lambda에서 이벤트 폴러는 이벤트 소스 유형에 따라 처리량 기능이 다른 컴퓨팅 유닛입니다. Amazon MSK 및 자체 관리형 Apache Kafka의 경우 각 이벤트 폴러는 최대 5MB/s의 처리량 또는 최대 5개의 동시 간접 호출을 처리할 수 있습니다. 예를 들어 이벤트 소스가 1MB의 평균 페이로드를 생성하고 함수의 평균 기간이 1초인 경우 단일 Kafka 이벤트 폴러는 5MB/초 처리량과 5개의 동시 Lambda 간접 호출을 지원할 수 있습니다(페이로드 변환은 없다고 가정). Amazon SQS의 경우 각 이벤트 폴러는 최대 1MB/s의 처리량 또는 최대 10개의 동시 간접 호출을 처리할 수 있습니다. 프로비저닝 모드를 사용하면 이벤트 폴러 사용량에 따라 추가 비용이 발생합니다. 요금에 대한 자세한 내용은 [AWS Lambda 요금](https://aws.amazon.com/lambda/pricing/)을 참조하세요.
프로비저닝 모드는 Amazon MSK, 자체 관리형 Apache Kafka 및 Amazon SQS 이벤트 소스에서만 이용할 수 있습니다. 동시성 설정을 통해 함수 규모 조정을 제어할 수 있지만 프로비저닝된 모드를 사용하면 이벤트 소스 매핑의 처리량을 제어할 수 있습니다. 성능을 극대화하기 위해 두 설정을 독립적으로 조정해야 할 수도 있습니다.
프로비저닝 모드는 시장 데이터 피드를 처리하는 금융 서비스 회사, 실시간 맞춤형 추천을 제공하는 전자 상거래 플랫폼, 라이브 플레이어 상호 작용을 관리하는 게임 회사 등 이벤트 처리 지연 시간이 일관적이어야 하는 실시간 애플리케이션에 적합합니다.
각 이벤트 폴러는 서로 다른 처리량 용량을 지원합니다.
+ Amazon MSK 및 자체 관리형 Apache Kafka: 최대 5MB/s의 처리량 또는 최대 5개의 동시 간접 호출
+ Amazon SQS: 초당 최대 1MB/s의 처리량 또는 최대 10개의 동시 간접 호출 또는 초당 최대 10개의 SQS 폴링 API 직접 호출.
Amazon SQS 이벤트 소스 매핑의 경우 최소 폴러 수를 2\$1200개로(기본값은 2개), 최대 폴러 수를 2\$12,000개(기본값은 200개)로 설정할 수 있습니다. Lambda는 구성된 최소 및 최대 이벤트 폴러 수를 조정하여 분당 최대 1,000개의 동시성을 빠르게 추가하면서 이벤트를 일관적이면서 지연 시간이 짧은 방식으로 처리합니다.
Kafka SQS 이벤트 소스 매핑의 경우 최소 폴러 수를 1\$1200개로(기본값은 1개), 최대 폴러 수를 1\$12,000개(기본값은 200개)로 설정할 수 있습니다. Lambda는 주제의 이벤트 백로그를 기반으로 구성된 최소 및 최대 설정 간에 이벤트 폴러 수를 조정하여 짧은 지연 시간으로 이벤트를 처리합니다.
Amazon SQS 이벤트 소스의 경우 프로비저닝 모드에서 최대 동시성 설정을 사용할 수 없습니다. 프로비저닝 모드를 사용하는 경우 최대 이벤트 폴러 설정을 통해 동시성을 제어합니다.
프로비저닝된 모드 구성에 대한 자세한 내용은 다음 섹션을 참조하세요.
+ [Amazon MSK 이벤트 소스 매핑에 대한 프로비저닝된 모드 구성](kafka-scaling-modes.md)
+ [자체 관리형 Apache Kafka 이벤트 소스 매핑에 대한 프로비저닝된 모드 구성](kafka-scaling-modes.md#kafka-provisioned-mode)
+ [Amazon SQS 이벤트 소스 매핑에서 프로비저닝 모드 사용](with-sqs.md#sqs-provisioned-mode)
프로비저닝 모드에서 지연 시간을 최소화하려면 `MaximumBatchingWindowInSeconds`를 0으로 설정합니다. 이 설정을 사용하면 Lambda가 현재 함수 간접 호출을 완료한 직후 다음 배치 처리를 시작할 수 있습니다. 저지연 처리에 대한 자세한 내용은 [지연 시간이 짧은 Apache Kafka](with-kafka-low-latency.md) 섹션을 참조하세요.
프로비저닝된 모드를 구성한 후 `ProvisionedPollers` 지표를 모니터링하여 워크로드에 대한 이벤트 폴러 사용량을 관찰할 수 있습니다. 자세한 내용은 [이벤트 소스 매핑 지표](monitoring-metrics-types.md#event-source-mapping-metrics) 섹션을 참조하세요.
## 이벤트 소스 매핑 API
[AWS Command Line Interface(AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 또는 [AWS SDK](https://aws.amazon.com/getting-started/tools-sdks/)를 사용하여 이벤트 소스를 관리하려면 다음 API 작업을 사용할 수 있습니다.
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)
# 이벤트 소스 매핑에 태그 사용
이벤트 소스 매핑에 태그를 지정하여 리소스를 구성하고 관리할 수 있습니다. 태그는 AWS 서비스 전반에서 지원되는 리소스와 연결된 자유 형식의 키-값 페어입니다. 태그 사용 사례에 대한 자세한 내용은 *AWS 리소스에 태그 지정 및 Tag Editor 사용 설명서*의 [일반적인 태그 지정 전략](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies)을 참조하세요.
이벤트 소스 매핑은 자체 태그를 가질 수 있는 함수와 연결됩니다. 이벤트 소스 매핑은 함수에서 태그를 자동으로 상속하지 않습니다. AWS Lambda API를 사용하여 태그를 보고 업데이트할 수 있습니다. Lambda 콘솔에서 특정 이벤트 소스 매핑을 관리하면서 태그를 보고 업데이트할 수도 있습니다(Amazon SQS에 프로비저닝 모드를 사용하는 태그 포함).
## 태그 작업에 필요한 권한
AWS Identity and Access Management(IAM) ID(사용자, 그룹 또는 역할)가 리소스의 태그를 읽거나 설정할 수 있도록 허용하려면 해당 권한을 부여합니다.
+ **lambda:ListTags** - 리소스에 태그가 있는 경우 리소스에서 `ListTags`를 직접적으로 호출해야 하는 모든 사람에게 이 권한을 부여합니다. 태그가 지정된 함수의 경우 `GetFunction`에도 이 권한이 필요합니다.
+ **lambda:TagResource** - `TagResource`를 직접적으로 호출하거나 생성 시 태그를 수행해야 하는 모든 사람에게 이 권한을 부여합니다.
선택적으로 리소스에 대한 `UntagResource` 직접 호출을 허용하도록 **lambda:UntagResource** 권한 부여를 고려하세요.
자세한 내용은 [Lambda에 대한 자격 증명 기반 IAM 정책](access-control-identity-based.md) 섹션을 참조하세요.
## Lambda 콘솔에서 태그 사용
Lambda 콘솔을 사용하여 태그가 있는 이벤트 소스 매핑을 생성하고, 기존 이벤트 소스 매핑에 태그를 추가하고, 태그로 이벤트 소스 매핑을 필터링할 수 있습니다(Amazon SQS에 프로비저닝 모드로 구성된 태그 포함).
Lambda 콘솔을 사용하여 지원되는 스트림 및 대기열 기반 서비스에 대한 트리거를 추가하면 Lambda가 자동으로 이벤트 소스 매핑을 생성합니다. 이러한 이벤트 소스에 대한 자세한 내용은 [Lambda가 스트림 및 대기열 기반 이벤트 소스의 레코드를 처리하는 방법](invocation-eventsourcemapping.md) 섹션을 참조하세요. 콘솔에서 이벤트 소스 매핑을 생성하려면 다음 사전 요구 사항이 필요합니다.
+ 함수.
+ 영향을 받는 서비스의 이벤트 소스.
트리거를 생성하거나 업데이트하는 데 사용하는 것과 동일한 사용자 인터페이스의 일부로 태그를 추가할 수 있습니다.
**이벤트 소스 매핑을 생성할 때 태그를 추가하려면 다음을 수행하세요.**
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 함수의 이름을 선택합니다.
1. **함수 개요(Function overview)**에서 **트리거 추가(Add trigger)**를 선택합니다.
1. **트리거 구성** 아래의 드롭다운 목록에서 이벤트 소스의 출처 서비스 이름을 선택합니다.
1. 이벤트 소스의 핵심 구성을 제공합니다. 이벤트 소스 구성에 대한 자세한 내용은 [다른 AWS 서비스의 이벤트로 Lambda 간접 호출](lambda-services.md)의 관련 서비스 섹션을 참조하세요.
1. **이벤트 소스 매핑 구성**에서 **추가 설정**을 선택합니다.
1. **태그** 아래에서 **새 태그 추가**를 선택합니다.
1. **키** 필드에 태그 키를 입력합니다. 태그 지정 제한에 대한 자세한 내용은 *AWS 리소스에 태그 지정 및 Tag Editor 사용 설명서*의 [태그 이름 지정 제한 및 요구 사항](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)을 참조하세요.
1. **추가**를 선택합니다.
**기존 이벤트 소스 매핑에 태그를 추가하려면 다음을 수행하세요.**
1. Lambda 콘솔에서 [이벤트 소스 매핑](https://console.aws.amazon.com/lambda/home#/event-source-mappings)을 엽니다.
1. 리소스 목록에서 **함수**와 **이벤트 소스 ARN**에 해당하는 이벤트 소스 매핑의 **UUID**를 선택합니다.
1. **일반 구성 창** 아래의 탭 목록에서 **태그**를 선택합니다.
1. **태그 관리**를 선택합니다.
1. **새 태그 추가**를 선택합니다.
1. **키** 필드에 태그 키를 입력합니다. 태그 지정 제한에 대한 자세한 내용은 *AWS 리소스에 태그 지정 및 Tag Editor 사용 설명서*의 [태그 이름 지정 제한 및 요구 사항](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)을 참조하세요.
1. **저장**을 선택합니다.
**태그로 이벤트 소스 매핑을 필터링하려면 다음을 수행하세요.**
1. Lambda 콘솔에서 [이벤트 소스 매핑](https://console.aws.amazon.com/lambda/home#/event-source-mappings)을 엽니다.
1. 검색 창을 선택합니다.
1. 드롭다운 목록에서 **태그** 부제목 아래에서 태그 키를 선택합니다.
1. **용도: “tag-name”**을 선택하여 이 키로 태그가 지정된 모든 이벤트 소스 매핑을 보거나 **연산자**를 선택하여 값으로 추가 필터링할 수 있습니다.
1. 태그 키와 값의 조합으로 필터링하려면 태그 값을 선택합니다.
검색 상자는 태그 키 검색도 지원합니다. 목록에서 찾을 키의 이름을 입력합니다.
## AWS CLI에서 태그 사용
이벤트 소스 매핑을 포함하여 기존 Lambda 리소스에 Lambda API로 태그를 추가하고 제거할 수 있습니다. 또한 이벤트 소스 매핑을 생성할 때 태그를 추가하여 리소스의 전체 수명 주기 동안 태그를 유지할 수 있습니다.
### Lambda 태그 API를 사용하여 태그 업데이트
[TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) 및 [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) API 작업을 통해 지원되는 Lambda 리소스에 대한 태그를 추가하고 제거할 수 있습니다.
AWS CLI를 사용하여 이러한 작업을 직접적으로 호출할 수 있습니다. 기존 리소스에 태그를 추가하려면 `tag-resource` 명령을 사용합니다. 이 예에서는 두 개의 태그를 추가합니다. 하나는 *Department*라는 키를 갖는 태그이고 다른 하나는 *CostCenter*라는 키를 갖는 태그입니다.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
태그를 제거하려면 `untag-resource` 명령을 사용합니다. 이 예에서는 *Department*라는 키가 있는 태그를 제거합니다.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### 이벤트 소스 매핑을 생성할 때 태그 추가
태그를 사용하여 새로운 Lambda 이벤트 소스 매핑을 생성하려면 [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) API 작업을 사용합니다. `Tags` 파라미터를 지정합니다. `create-event-source-mapping` AWS CLI 명령과 `--tags` 옵션을 사용하여 이 작업을 직접적으로 호출할 수 있습니다. CLI 명령에 대한 자세한 내용은 *AWS CLI Command Reference*의 [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)을 참조하세요.
`CreateEventSourceMapping`와 함께 `Tags` 파라미터를 사용하기 전에 역할에 이 작업에 필요한 일반적인 권한과 함께 리소스에 태그를 지정할 수 있는 권한이 있는지 확인하세요. 태그 지정 권한에 대한 자세한 내용은 [태그 작업에 필요한 권한](#esm-tags-required-permissions) 섹션을 참조하세요.
### Lambda 태그 API를 사용하여 태그 보기
특정 Lambda 리소스에 적용된 태그를 보려면 `ListTags` API 작업을 사용합니다. 자세한 내용은 [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)를 참조하세요.
Amazon 리소스 이름(ARN)을 제공하여 `list-tags` AWS CLI 명령으로 이 작업을 직접적으로 호출할 수 있습니다.
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### 태그로 리소스 필터링
AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) API 작업을 사용하여 태그를 기준으로 리소스를 필터링할 수 있습니다. `GetResources` 작업은 최대 10개의 필터를 수신하며 각 필터는 태그 키와 최대 10개의 태그 값을 포함합니다. `GetResources`에 `ResourceType`을 지정하면 특정 리소스 유형별로 필터링할 수 있습니다.
`get-resources` AWS CLI 명령을 사용하여 이 작업을 직접적으로 호출할 수 있습니다. `get-resources` 사용 예는 *AWS CLI Command Reference*의 [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples)를 참조하세요.