기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Step Functions 모범 사례 **상태 관리 및 데이터 트랜스포밍** [변수를 사용하여 상태 간 데이터 전달](workflow-variables.md)과 [JSONata를 사용하여 데이터 트랜스포밍](transforming-data.md)에 대해 알아봅니다. 다음 주제는 Step Functions 워크플로를 관리하고 최적화하는 데 도움이 되는 모범 사례입니다. **Topics** + [Express 워크플로를 사용하여 비용 최적화](#cost-opt-exp-workflows) + [Step Functions에서 상태 머신 및 활동에 태그 지정](#concepts-tagging) + [제한 시간을 사용하여 Step Functions 워크플로 실행 멈춤 방지](#sfn-stuck-execution) + [Step Functions에서 대용량 페이로드를 전달하는 대신 Amazon S3 ARN 사용](#avoid-exec-failures) + [Step Functions에서 내역 할당량에 도달하지 않도록 새 실행 시작](#bp-history-limit) + [임시 Lambda 서비스 예외 처리](#bp-lambda-serviceexception) + [활동 작업을 폴링할 때 지연 시간 방지](#bp-activity-pollers) + [CloudWatch 리소스 정책 크기 제한 방지](#bp-cwl) ## Express 워크플로를 사용하여 비용 최적화 Step Functions는 상태 머신을 빌드하는 데 사용하는 워크플로 유형에 따라 표준 및 Express 워크플로의 요금을 결정합니다. 서버리스 워크플로 비용을 최적화하려면 다음 권장 사항 중 하나 또는 둘 다 따르면 됩니다. 표준 또는 Express 워크플로 유형 선택이 결제에 미치는 영향은 [AWS Step Functions 요금](https://aws.amazon.com/step-functions/pricing/)을 참조하세요. ### 표준 워크플로 내에서 Express 워크플로 중첩 Step Functions는 기간과 단계 수가 한정적인 워크플로를 실행합니다. 일부 워크플로는 짧은 시간 내에 실행을 완료할 수 있습니다. 다른 워크플로에서는 장기간 실행되는 워크플로와 이벤트 속도가 빠른 워크플로를 함께 사용해야 할 수도 있습니다. Step Functions를 사용하면 여러 단순한 소규모 워크플로에서 복잡한 대규모 워크플로를 빌드할 수 있습니다. 예를 들어 주문 처리 워크플로를 빌드하려면 멱등성이 없는 모든 작업을 표준 워크플로에 포함하면 됩니다. 여기에는 인적 상호 작용을 통한 주문 승인 및 결제 처리와 같은 작업이 포함될 수 있습니다. 그런 다음 결제 알림 전송 및 제품 인벤토리 업데이트와 같은 일련의 멱등성이 있는 작업을 Express 워크플로에 결합할 수 있습니다. 표준 워크플로 내에서 이 Express 워크플로를 중첩할 수 있습니다. 이 예제에서는 Standard 워크플로를 *상위 상태 머신*이라고 합니다. 중첩된 Express 워크플로를 *하위 상태 머신*이라고 합니다. ### Standard 워크플로와 비교할 때 Express 워크플로의 특징은 다음과 같습니다. 다음 요구 사항을 충족하는 경우 기존 Standard 워크플로를 Express 워크플로로 마이그레이션하는 것을 고려해야 합니다. + 워크플로는 5분 이내에 실행을 완료해야 합니다. + 워크플로는 *at-least-once* 실행 모델을 준수합니다. 즉, 워크플로의 각 단계가 정확히 1회 이상 실행될 수 있습니다. + 워크플로는 `.waitForTaskToken` 또는 `.sync` 서비스 통합 패턴을 사용하지 **않습니다**. **중요** Express 워크플로는 Amazon CloudWatch Logs를 사용하여 실행 내역을 기록합니다. CloudWatch Logs를 사용하면 추가 비용이 발생합니다. **콘솔을 사용하여 Standard 워크플로를 Express 워크플로로 마이그레이션** 1. [Step Functions 콘솔](https://console.aws.amazon.com/states/home?region=us-east-1#/)을 엽니다. 1. **상태 머신** 페이지에서 표준 유형 상태 머신을 선택하여 엽니다. **작은 정보** 상태 머신 목록을 필터링하고 Standard 워크플로만 보려면 **모든 유형** 드롭다운 목록에서 **표준**을 선택하세요. 1. **신규로 복사**를 선택합니다. Workflow Studio가 [디자인 모드](workflow-studio.md#wfs-interface-design-mode)에서 열리고 선택한 상태 머신의 워크플로가 표시됩니다. 1. (선택 사항) 워크플로 설계를 업데이트합니다. 1. 상태 머신 이름을 지정합니다. 이렇게 하려면 기본 상태 머신 이름인 **MyStateMachine** 옆에 있는 편집 아이콘을 선택합니다. 그런 다음 **상태 머신 구성**에서 **상태 머신 이름** 상자에 이름을 지정합니다. 1. (선택 사항) **상태 머신 구성**에서 상태 머신 유형 및 실행 역할과 같은 기타 워크플로 설정을 지정합니다. **유형**에 **Express**를 선택했는지 확인합니다. **상태 머신 설정**의 다른 모든 기본 선택을 그대로 둡니다. **참고** [AWS CDK](https://docs.aws.amazon.com/cdk/api/latest/docs/aws-stepfunctions-readme.html) 또는에 이전에 정의된 표준 워크플로를 마이그레이션AWS SAM하는 경우 `Type` 및 `Resource` 이름의 값을 변경해야 합니다. 1. **역할 생성 확인** 대화 상자에서 **확인**을 선택하여 계속합니다. **역할 설정 보기**를 선택하여 **상태 머신 구성**으로 돌아갈 수도 있습니다. **참고** Step Functions에서 만드는 IAM 역할을 삭제하면 나중에 Step Functions에서 이 역할을 다시 만들 수 없습니다. 마찬가지로, 역할을 수정하면(예: IAM 정책의 주요에서 Step Functions 제거) 나중에 Step Functions에서 해당 원본 설정을 복원할 수 없습니다. 워크플로의 비용 최적화를 관리할 때의 모범 사례 및 지침에 대한 자세한 내용은 [비용 효율적인 AWS Step Functions워크플로 구축](https://aws.amazon.com/blogs/compute/building-cost-effective-aws-step-functions-workflows/)을 참조하세요. ## Step Functions에서 상태 머신 및 활동에 태그 지정 AWS Step Functions는 상태 시스템(Standard 및 Express 모두) 및 활동에 태그 지정을 지원합니다. 태그를 사용하면 리소스를 추적 및 관리하고 AWS Identity and Access Management(IAM) 정책에서 보안을 강화할 수 있습니다. Step Functions 리소스에 태그를 지정한 후를 사용하여 관리할 수 있습니다AWS Resource Groups. 자세한 방법은 [AWS Resource Groups 사용 설명서](https://docs.aws.amazon.com/ARG/latest/userguide/)를 참조하세요. 태그 기반 권한 부여의 경우 다음 예제와 같은 상태 머신 실행 리소스는 상태 머신과 연결된 태그를 상속합니다. ``` arn:{{partition}}:states:{{region}}:{{account-id}}:execution:{{:}} ``` [DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html) 또는 실행 리소스 ARN을 지정하는 다른 API를 직접적으로 호출하면 태그 기반 권한 부여를 수행하는 동안 Step Functions에서 상태 머신과 연결된 태그를 사용하여 요청을 수락하거나 거부합니다. 이렇게 하면 상태 머신 수준에서 상태 머신 실행에 대한 액세스를 허용하거나 거부할 수 있습니다. 리소스 태그 지정에 관련된 제한을 검토하려면 [태그 지정과 관련된 제한](service-quotas.md#sfn-limits-tagging) 단원을 참조하십시오. ### 비용 할당을 위한 태그 지정 비용 할당 태그를 사용하여 상태 시스템의 목적을 식별하고 해당 조직을 AWS청구서에 반영할 수 있습니다. 가입하여 태그 키와 값을 포함하는 AWS계정 청구서를 받습니다. 보고서 설정에 대한 자세한 내용은 *AWS Billing 사용 설명서*에서 [월간 비용 할당 보고서 설정](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html#allocation-report) 참조하세요. 예를 들어 다음과 같이 Step Functions 리소스의 비용 센터와 목적을 나타내는 태그를 추가할 수 있습니다. - **`StateMachine1`** - **Key(키):** Cost Center / **값:** 34567 - **Key(키):** Application / **값:** Image processing - **`StateMachine2`** - **Key(키):** Cost Center / **값:** 34567 - **Key(키):** Application / **값:** Rekognition processing ### 보안을 위한 태그 지정 IAM은 태그를 기반으로 리소스에 대한 액세스를 제어할 수 있습니다. 태그를 기반으로 액세스를 제어하려면 IAM 정책의 조건 요소에 리소스 태그에 대한 정보를 제공합니다. 예를 들어 `environment` 키 및 `production` 값과 함께 태그가 포함된 모든 Step Functions 리소스에 대한 액세스를 제한할 수 있습니다. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "states:TagResource", "states:DeleteActivity", "states:DeleteStateMachine", "states:StopExecution" ], "Resource": "*", "Condition": { "StringEquals": {"aws:ResourceTag/environment": "production"} } } ] } ``` 자세한 내용은 IAM 사용 설명서의 [태그를 사용한 액세스 제어](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)를 참조하세요. ### Step Functions 콘솔에서 태그 관리 Step Functions 콘솔에서 상태 머신의 태그를 보고 관리할 수 있습니다. 상태 머신의 **세부 정보** 페이지에서 **태그**를 선택합니다. ### Step Functions API 작업으로 태그 관리 Step Functions API를 사용하여 태그를 관리하려면 다음 API 작업을 사용합니다. + [https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListTagsForResource.html](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListTagsForResource.html) + [https://docs.aws.amazon.com/step-functions/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TagResource.html) + [https://docs.aws.amazon.com/step-functions/latest/apireference/API_UntagResource.html](https://docs.aws.amazon.com/step-functions/latest/apireference/API_UntagResource.html) ## 제한 시간을 사용하여 Step Functions 워크플로 실행 멈춤 방지 기본적으로 Amazon States Language는 상태 머신 정의 제한 시간을 지정하지 않습니다. 명시적 제한 시간 없이 Step Functions는 활동 작업자의 응답만 사용하여 작업이 완료되었는지를 확인합니다. 문제가 발생하고 `Activity` 및 `Task` 상태에 `TimeoutSeconds` 필드가 지정되지 않으면 돌아오지 않는 응답을 기다리기 위해 실행이 멈춥니다. 이를 방지하려면 상태 머신에 `Task`를 만들 때 적절한 제한 시간을 지정합니다. 예제: ``` "ActivityState": { "Type": "Task", "Resource": "arn:aws:states:{{region}}:{{account-id}}:activity:HelloWorld", "TimeoutSeconds": 300, "Next": "NextState" } ``` [작업 토큰(.waitForTaskToken)과 함께 콜백](connect-to-resource.md#connect-wait-token)을 사용하는 경우 하트비트를 사용하고 `Task` 상태 정의에 `HeartbeatSeconds` 필드를 추가하는 것이 좋습니다. `HeartbeatSeconds`를 작업 제한 시간보다 작게 설정할 수 있으므로 하트비트 오류로 인해 워크플로가 실패하는 경우 작업이 완료되는 데 오랜 시간이 걸리는 것이 아니라 작업 실패가 원인이라는 것을 알 수 있습니다. ``` { "StartAt": "Push to SQS", "States": { "Push to SQS": { "Type": "Task", "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken", "HeartbeatSeconds": 600, "Parameters": { "MessageBody": { "myTaskToken.$": "$$.Task.Token" }, "QueueUrl": "https://sqs.us-east-1.amazonaws.com/{{account-id}}/push-based-queue" }, "ResultPath": "$.SQS", "End": true } } } ``` 자세한 내용은 Amazon States Language 문서의 [Task 워크플로 상태](state-task.md) 섹션을 참조하세요. **참고** Amazon States Language 정의의 `TimeoutSeconds` 필드를 사용하여 상태 머신 제한 시간을 설정할 수 있습니다. 자세한 내용은 [Step Functions 워크플로를 위한 Amazon States Language의 상태 머신 구조](statemachine-structure.md) 단원을 참조하십시오. ## Step Functions에서 대용량 페이로드를 전달하는 대신 Amazon S3 ARN 사용 상태 사이에 대용량 데이터 페이로드를 전달하는 실행은 종료될 수 있습니다. 상태 간에 전달하는 데이터가 256KiB를 초과할 수 있는 경우 Amazon Simple Storage Service(Amazon S3)를 사용하여 데이터를 저장하고 `Payload` 파라미터에서 버킷의 Amazon 리소스 이름(ARN)을 구문 분석하여 버킷 이름과 키 값을 가져옵니다. 또는 실행에서 더 작은 용량의 페이로드를 전달하도록 구현을 조정합니다. 다음 예제에서 상태 시스템은 Amazon S3 버킷의 JSON 파일을 처리하는 AWS Lambda함수에 입력을 전달합니다. 이 상태 머신을 실행하면 Lambda 함수에서 JSON 파일 콘텐츠를 읽고 파일 콘텐츠를 출력으로 반환합니다. **Lambda 함수 생성** `{{pass-large-payload}}`라는 다음 Lambda 함수는 특정 Amazon S3 버킷에 저장된 JSON 파일의 콘텐츠를 읽습니다. **참고** 이 Lambda 함수를 만든 후에는 해당 IAM 역할에 Amazon S3 버킷에서 읽을 수 있는 적절한 권한을 제공해야 합니다. 예를 들어 **AmazonS3ReadOnlyAccess** 권한을 Lambda 함수 역할에 연결합니다. ``` import json import boto3 import io import os s3 = boto3.client('s3') def lambda_handler(event, context): event = event['Input'] final_json = str() s3 = boto3.resource('s3') bucket = event['bucket'].split(':')[-1] filename = event['key'] directory = "/tmp/{}".format(filename) s3.Bucket(bucket).download_file(filename, directory) with open(directory, "r") as jsonfile: final_json = json.load(jsonfile) os.popen("rm -rf /tmp") return final_json ``` **상태 머신 만들기** 다음 상태 머신은 이전에 만든 Lambda 함수를 간접적으로 호출합니다. ``` { "StartAt":"Invoke Lambda function", "States":{ "Invoke Lambda function":{ "Type":"Task", "Resource":"arn:aws:states:::lambda:invoke", "Parameters":{ "FunctionName":"arn:aws:lambda:us-east-2:123456789012:function:{{pass-large-payload}}", "Payload":{ "Input.$":"$" } }, "OutputPath": "$.Payload", "End":true } } } ``` 대량의 데이터를 입력에 전달하는 대신 해당 데이터를 Amazon S3 버킷에 저장하고 버킷의 Amazon 리소스 이름(ARN)을 `Payload` 파라미터에 전달하여 버킷 이름과 키 값을 가져올 수 있습니다. 그러면 Lambda 함수에서 해당 ARN을 사용하여 데이터에 직접 액세스할 수 있습니다. 다음은 상태 머신 실행을 위한 입력의 예제입니다. 여기서 데이터는 `data.json`이라는 Amazon S3 버킷의 `{{amzn-s3-demo-large-payload-json}}`에 저장됩니다. ``` { "key": "data.json", "bucket": "{{arn:aws:s3:::amzn-s3-demo-large-payload-json}}" } ``` ## Step Functions에서 내역 할당량에 도달하지 않도록 새 실행 시작 AWS Step Functions는 실행 이벤트 기록에서 25,000개 항목의 하드 할당량을 갖습니다. 실행이 이벤트 24,999개에 도달하면 다음 이벤트가 발생할 때까지 대기합니다. + 이벤트 번호 25,000이 `ExecutionSucceeded`이면 실행이 성공적으로 완료됩니다. + 이벤트 번호 25,000이 `ExecutionSucceeded`가 아니면 `ExecutionFailed` 이벤트가 로깅되고 내역 한도에 도달하여 상태 머신 실행이 실패합니다. 이 장기 실행 할당량에 도달하지 않게 하려면 다음 해결 방법 중 하나를 시도하면 됩니다. + [분산 모드에서 Map 상태를 사용합니다](state-map-distributed.md). 이 모드에서 `Map` 상태는 각 반복을 하위 워크플로 실행으로 실행하므로 병렬 하위 워크플로를 동시에 최대 10,000개까지 실행할 수 있습니다. 각 하위 워크플로 실행에는 상위 워크플로와 별개인 자체 실행 내역이 있습니다. + 실행 중인 `Task` 상태에서 직접 새 상태 머신 실행을 시작합니다. 이러한 중첩된 워크플로 실행을 시작하려면 필요한 파라미터와 함께 상위 상태 머신에서 Step Functions의 `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` API 작업을 사용합니다. 중첩된 워크플로 사용에 대한 자세한 내용은 [Step Functions의 작업 상태에서 워크플로 실행 시작](concepts-nested-workflows.md) 또는 [Step Functions API 작업을 사용하여 새 실행 계속하기](tutorial-continue-new.md) 자습서를 참조하세요. **작은 정보** 중첩된 워크플로 예제를 배포하려면 *AWS Step Functions워크숍*의 [비용 최적화](https://catalog.workshops.aws/stepfunctions/nested-workflow)를 참조하세요. + 상태 시스템의 새 실행을 시작하여 진행 중인 작업을 여러 워크플로 실행으로 분할할 수 있는 AWS Lambda함수를 사용하는 패턴을 구현합니다. 자세한 내용은 [Step Functions에서 Lambda 함수를 사용하여 새 실행 계속하기](tutorial-use-lambda-cont-exec.md) 자습서를 참조하세요. ## 임시 Lambda 서비스 예외 처리 AWS Lambda에서 일시적인 서비스 오류가 발생할 수 있습니다. 이 경우 Lambda를 간접적으로 호출하면 `ClientExecutionTimeoutException`, `ServiceException`, `AWSLambdaException` 또는 `SdkClientException`과 같은 500 오류가 발생합니다. 모범 사례로서, 상태 머신에서 이러한 예외를 사전에 처리하여 Lambda 함수 간접 호출을 `Retry`하거나 오류를 `Catch`하는 것이 좋습니다. Lambda 오류가 `Lambda.{{ErrorName}}`으로 보고됩니다. Lambda 서비스 예외 오류를 다시 시도하려면 다음 `Retry` 코드를 사용하면 됩니다. ``` "Retry": [ { "ErrorEquals": [ "Lambda.ClientExecutionTimeoutException", "Lambda.ServiceException", "Lambda.AWSLambdaException", "Lambda.SdkClientException"], "IntervalSeconds": 2, "MaxAttempts": 6, "BackoffRate": 2 } ] ``` **참고** Lambda 런타임에서 처리되지 않은 오류는 과거에 `Lambda.Unknown`으로만 보고되었습니다. 최신 런타임에서는 제한 시간이 오류 출력에 `Sandbox.Timedout`으로 보고됩니다. Lambda에서 최대 간접 호출 수를 초과하면 보고되는 오류는 `Lambda.TooManyRequestsException`입니다. 가능한 오류를 처리하려면 `Lambda.Unknown`, `Sandbox.Timedout`, 및 `States.TaskFailed`에서 일치시킵니다. `States.ALL`을 사용할 수도 있지만, 반드시 단독으로만 있고 목록 끝에 있어야 합니다. Lambda `Handled` 및 `Unhandled` 오류에 대한 자세한 내용은 [AWS Lambda 개발자 안내서](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseSyntax)의 `FunctionError` 섹션을 참조하세요. 자세한 내용은 다음을 참조하세요. + [오류 후 재시도](concepts-error-handling.md#error-handling-retrying-after-an-error) + [Step Functions 상태 머신을 사용하여 오류 조건 처리](tutorial-handling-error-conditions.md) + [Lambda 간접 호출 오류](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_Errors) ## 활동 작업을 폴링할 때 지연 시간 방지 `[GetActivityTask](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html)` API는 [https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html#StepFunctions-GetActivityTask-response-taskToken](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html#StepFunctions-GetActivityTask-response-taskToken)을 *정확히 한 번만* 제공하도록 설계되어 있습니다. 활동 작업자와 의사 소통 중 `taskToken`이 삭제되면`GetActivityTask` 시간이 초과될 때까지 응답을 기다리는 60초 동안 많은 `GetActivityTask` 요청이 차단될 수 있습니다. 응답을 기다리는 폴링 수가 적은 경우에만 모든 요청을 차단된 요청 뒤쪽의 대기열에 넣고 정지합니다. 그러나 활동 Amazon 리소스 이름(ARN)마다 미해결 폴링이 상당수 있고 요청 일부가 대기 상태에 머물러 있으면 계속 `taskToken`을 가져와 작업을 처리할 수 있는 경우가 많습니다. 프러덕션 시스템의 경우 각 시점에서 활동 ARN당 100개 이상의 공개 폴링을 추천합니다. 하나의 폴링이 차단되고 이 폴링의 일부를 뒤쪽의 대기열에 넣으면 `taskToken`를 받아 작업을 처리할 수 있는 요청이 여전히 많은 반면 `GetActivityTask` 요청은 차단됩니다. 작업에 대한 폴링 시 이러한 종류의 지연 시간 문제를 피하려면: + 활동 작업자 구현 시 작업에서 별도의 스레드로 poller를 구현하십시오. + 각 시점에서 활동 ARN당 100개 이상의 공개 폴링을 하십시오. **참고** ARN당 100개의 공개 폴링으로 확장하는 것은 비용이 많이 들 수 있습니다. 예를 들어 ARN당 Lambda 함수 폴링 100개 보유 비용이 폴링 스레드가 100개 있는 단일 Lambda 함수 보유에 비해 100배 이상 높습니다. 지연 시간 단축 *및* 비용 최적화를 모두 달성하려면 비동기 I/O가 있는 언어를 사용하고 작업자마다 여러 개의 폴링 스레드를 구현합니다. Poller 스레드가 작업 스레드와 분리되어 있는 경우 활동 작업자의 예제는 [예제: Ruby 활동 작업자](concepts-activities.md#example-ruby-activity-worker)를 참조하십시오. 활동 및 활동 작업자에 대한 자세한 내용은 [Step Functions의 활동에 대해 알아보기](concepts-activities.md)을 참조하십시오. ## CloudWatch 리소스 정책 크기 제한 방지 로깅이 있는 상태 머신을 만들거나 로깅을 활성화하도록 기존 상태 머신을 업데이트하는 경우, Step Functions에서 지정된 로그 그룹으로 CloudWatch Logs 리소스 정책을 업데이트해야 합니다. CloudWatch Logs 리소스 정책은 5,120자로 제한됩니다. CloudWatch Logs에서 정책이 크기 제한에 도달하는 것을 감지하면 CloudWatch Logs는 `/aws/vendedlogs/`로 시작하는 로그 그룹에 대해 자동으로 로깅을 활성화합니다. CloudWatch Logs 리소스 정책 크기 한도에 도달하지 않도록 CloudWatch Logs 로그 그룹 이름에 접두사 `/aws/vendedlogs/`를 추가할 수 있습니다. Step Functions 콘솔에서 로그 그룹을 만들면 제안된 로그 그룹 이름에 접두사 `/aws/vendedlogs/states`가 이미 추가되어 있습니다. 또한 CloudWatch Logs는 계정당, 리전당 리소스 정책 10개의 할당량을 가집니다. 계정에 대한 리전에 이미 10개의 CloudWatch Logs 리소스 정책이 있는 상태 머신에 로깅을 활성화하려고 하면 상태 머신이 생성되지 않거나 업데이트되지 않습니다. 로깅 할당량에 대한 자세한 정보는 [CloudWatch Logs 할당량](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) 섹션을 참조하세요. CloudWatch Logs로 로그를 전송하는 데 문제가 있는 경우 [Troubleshooting state machine logging to CloudWatch Logs](cw-logs.md#troubleshooting-logging-to-cloudwatch) 섹션을 참조하세요.