[{"data":1,"prerenderedAt":566},["ShallowReactive",2],{"content-svc-lambda-guides-aws-lambda-operator-guide-configurations":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":8,"menu":9,"menuType":563,"isCollapseableMenu":12,"nextDocItem":352,"previousDocItem":340,"contributorPaths":564,"contentName":565,"slug":351,"readingTime":348},"\u003Cp>\u003Cstrong>Topics\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca href=\"#troubleshooting-lambda-configurations\">Troubleshooting Lambda configurations\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#memory-configurations\">Memory configurations\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#cpu-bound-configurations\">CPU-bound configurations\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#timeouts\">Timeouts\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#memory-leakage-between-invocations\">Memory leakage between invocations\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#asynchronous-results-returned-to-a-later-invocation\">Asynchronous results returned to a later invocation\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Memory configurations\u003C\u002Fh2>\n\u003Cp>You can configure a Lambda function to use between 128 MB and 10,240 MB. By default, any function created in the console is assigned the smallest amount of memory. While many Lambda functions are performant at this lowest setting, if you are importing large code libraries or completing memory intensive tasks, 128 MB is not sufficient.\u003C\u002Fp>\n\u003Cp>If functions are running much slower than expected, the first step is to increase the memory setting. For memory-bound functions, this will resolve the bottleneck and may improve the performance of your function.\u003C\u002Fp>\n\u003Ch2>CPU-bound configurations\u003C\u002Fh2>\n\u003Cp>For compute-intensive operations, if you experience slower-than-expected performance of your Lambda function, this may be due to your function being CPU-bound. In this case, the computational capacity of the function cannot keep pace with the work.\u003C\u002Fp>\n\u003Cp>While there is no CPU configuration directly exposed in Lambda configurations, this is indirectly controlled via the memory settings. The Lambda service proportionally allocates more virtual CPU as you allocate more memory. At 1.8 GB of the memory, a Lambda function has an entire vCPU allocated, and above this level it has access to more than one vCPU core. At 10,240MB it has 6 vCPUs available.\u003C\u002Fp>\n\u003Cp>In these cases, you can improve performance by increasing the memory allocation, even if the function doesn’t use all of the memory.\u003C\u002Fp>\n\u003Ch2>Timeouts\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Fconfiguration-console.html\">Timeouts\u003C\u002Fa> for Lambda functions can be set between 1 and 900 seconds (15 minutes), with the Lambda console defaulting to 3 seconds. The timeout value is a safety buffer that ends functions that never exit to continue to run indefinitely. Once the timeout value is reached, the function is stopped by the Lambda services.\u003C\u002Fp>\n\u003Cp>If a timeout value is set close to the average duration of a function, this increases the risk that the function will time out unexpectedly. The duration of a function can vary based on the amount of data transfer and processing, and the latency of any services the function interacts with. Some common causes of timeout include:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>When downloading data from S3 buckets or other data stores, the download is larger or takes longer than average.\u003C\u002Fli>\n\u003Cli>A function makes a request to another service, which takes longer to respond.\u003C\u002Fli>\n\u003Cli>The parameters provided to a function require more computational complexity in the function, which causes the invocation to take longer.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>In the \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fs3-to-lambda-patterns\u002Ftree\u002Fmaster\u002Fdocrepository\">Document Repository example\u003C\u002Fa>, the Lambda functions that process objects from the document bucket have 3-second timeout values. These functions may time out for all of these reasons:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-3.png\" alt=\"\">\u003C\u002Fp>\n\u003Col>\n\u003Cli>As the size of a PDF file grows, the npm library that processes this format takes longer. There is an upper bound after which the processing of the PDF takes longer than 3 seconds.\u003C\u002Fli>\n\u003Cli>Media binaries such as JPG files can be very large. There is an upper bound after which the size of the file takes longer than 3 seconds to download from the S3 bucket.\u003C\u002Fli>\n\u003Cli>In processing the JPG file, Amazon Rekognition takes longer for larger objects and objects with more complexity. This service may take more than 3 seconds to respond.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Timeouts are a safety mechanism and in normal operation do not have a negative impact on cost, since the Lambda service charges by duration. Ensure that your timeout values are not set too close to the average duration of a function to avoid unexpected timeouts.\u003C\u002Fp>\n\u003Cp>In testing your application, ensure that your tests accurately reflect the size and quantity of data, and realistic parameter values. Tests often use small samples for convenience but you should use datasets at the upper bounds of what is reasonably expected for your workload.\u003C\u002Fp>\n\u003Cp>Implement upper-bound limits in your workload wherever practical. In this example, the application could use a maximum size limit for each file type. You can then test the performance of your application for a range of expected file sizes, up to and including the maximum limits.\u003C\u002Fp>\n\u003Ch2>Memory leakage between invocations\u003C\u002Fh2>\n\u003Cp>Global variables and objects stored in the INIT phase of a Lambda invocation retain their state between warm invocations. They are completely reset only when the execution environment is run for the first time (also known as a “cold start”). Any variables stored in the handler are destroyed when the handler exits. It’s best practice to use the INIT phase to set up database connections, load libraries, create caches, and load immutable assets.\u003C\u002Fp>\n\u003Cp>When you use third-party libraries across multiple invocations in the same execution environment, be sure to check their documentation for usage in a serverless compute environment. Some database connection and logging libraries may save intermediate invocation results and other data. This causes the memory usage of these libraries to grow with subsequent warm invocations. In cases where memory grows rapidly, you may find the Lambda function runs out of memory, even if your custom code is disposing of variables correctly.\u003C\u002Fp>\n\u003Cp>This issue affects invocations occurring in warm execution environments. For example, the following code creates a memory leak between invocations. The Lambda function consumes additional memory with each invocation by increasing the size of a global array:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-js\">let a = []\n\nexports.handler = async (event) => {\n    a.push(Array(100000).fill(1))\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Configured with 128 MB of memory, after invoking this function 1000 times, the Monitoring tab of the Lambda function shows the typical changes in invocations, duration, and error counts when a memory leak occurs:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-4.png\" alt=\"\">\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Invocations\u003C\u002Fstrong>: a steady transaction rate is interrupted periodically as the invocations take longer to complete. During the steady state, the memory leak is not consuming all of the function’s allocated memory. As performance degrades, the operating system is paging local storage to accommodate the growing memory required by the function, which results in fewer transactions being completed.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Duration\u003C\u002Fstrong>: before the function runs out of memory, it finishes invocations at a steady double-digit millisecond rate. As paging occurs, the duration takes an order of magnitude longer.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Error count\u003C\u002Fstrong>: as the memory leak exceeds allocated memory, eventually the function errors due to the computation exceeding the timeout, or the execution environment stops the function.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>After the error, the Lambda service restarts the execution environment, which explains why in all three graphs the metrics return to the original state. Expanding the CloudWatch metrics for duration provides more detail for the minimum, maximum and average duration statistics:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-5.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>To find the errors generated across the 1000 invocations, you can use the CloudWatch Insights query language. To following query excludes informational logs to report only the errors:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">fields @timestamp, @message\n| sort @timestamp desc\n| filter @message not like 'EXTENSION'\n| filter @message not like 'Lambda Insights'\n| filter @message not like 'INFO' \n| filter @message not like 'REPORT'\n| filter @message not like 'END'\n| filter @message not like 'START'\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>When run against the log group for this function, this shows that timeouts were responsible for the periodic errors:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-6.png\" alt=\"\">\u003C\u002Fp>\n\u003Ch2>Asynchronous results returned to a later invocation\u003C\u002Fh2>\n\u003Cp>For function code that uses asynchronous patterns, it’s possible for the callback results from one invocation to be returned in a future invocation. This example uses Node.js but the same logic can apply to other runtimes using asynchronous patterns. The function uses the traditional callback syntax in JavaScript. It calls an asynchronous function with an incremental counter that tracks the number of invocations:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-js\">let seqId = 0\n\nexports.handler = async (event, context) => {\n    console.log(`Starting: sequence Id=${++seqId}`)\n    doWork(seqId, function(id) {\n        console.log(`Work done: sequence Id=${id}`)\n    })\n}\n\nfunction doWork(id, callback) {\n    setTimeout(() => callback(id), 3000)\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>When invoked several times in succession, the results of the callbacks occur in subsequent invocations:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-7.png\" alt=\"\">\u003C\u002Fp>\n\u003Col>\n\u003Cli>The code calls the \u003Cem>doWork\u003C\u002Fem> function, providing a callback function as the last parameter.\u003C\u002Fli>\n\u003Cli>The \u003Cem>doWork\u003C\u002Fem> function takes some period of time to complete before invoking the callback.\u003C\u002Fli>\n\u003Cli>The function’s logging indicates that the invocation is ending before the \u003Cem>doWork\u003C\u002Fem> function finishes execution. Additionally, after starting an iteration, callbacks from previous iterations are being processed, as shown in the logs.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>In JavaScript, asynchronous callbacks are handled with an \u003Ca href=\"https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FJavaScript\u002FEventLoop\">event loop\u003C\u002Fa>. Other runtimes use different mechanisms to handle concurrency. When the function’s execution environment ends, the Lambda service freezes the environment until the next invocation. After it is resumed, JavaScript continues processing the event loop, which in this case includes an asynchronous callback from a previous invocation. Without this context, it can appear that the function is running code for no reason, and returning arbitrary data. In fact, it is really an artifact of how runtime concurrency and the execution environments interact.\u003C\u002Fp>\n\u003Cp>This creates the potential for private data from a previous invocation to appear in a subsequent invocation. There are two ways to prevent or detect this behavior. First, JavaScript provides the \u003Ca href=\"https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FJavaScript\u002FReference\u002FStatements\u002Fasync_function\">async and await keywords\u003C\u002Fa> to simplify asynchronous development and also force code execution to wait for an asynchronous call to complete. The function above can be rewritten using this approach as follows:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-js\">let seqId = 0\nexports.handler = async (event) => {\n    console.log(`Starting: sequence Id=${++seqId}`)\n    const result = await doWork(seqId)\n    console.log(`Work done: sequence Id=${result}`)\n}\n\nfunction doWork(id) {\n  return new Promise(resolve => {\n    setTimeout(() => resolve(id), 4000)\n  })\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Using this syntax prevents the handler from exiting before the asynchronous function is finished. In this case, if the callback takes longer than the Lambda function’s timeout, the function will throw an error, instead of returning the callback result in a later invocation:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-8.png\" alt=\"\">\u003C\u002Fp>\n\u003Col>\n\u003Cli>The code calls the asynchronous \u003Cem>doWork\u003C\u002Fem> function using the await keyword in the handler.\u003C\u002Fli>\n\u003Cli>The \u003Cem>doWork\u003C\u002Fem> function takes some period of time to complete before resolving the promise.\u003C\u002Fli>\n\u003Cli>The function times out because \u003Cem>doWork\u003C\u002Fem> takes longer than the timeout limit allows and the callback result is not returned in a later invocation.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Generally, you should make sure any background processes or callbacks in the code are complete before the code exits. If this is not possible in your use case, you can use an identifier to ensure that the callback belongs to the current invocation. To do this, you can use the \u003Cem>awsRequestId\u003C\u002Fem> provided by the context object. By passing this value to the asynchronous callback, you can compare the passed value with the current value to detect if the callback originated from another invocation:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-js\">let currentContext\n\nexports.handler = async (event, context) => {\n    console.log(`Starting: request id=$\\{context.awsRequestId}`)\n    currentContext = context\n\n    doWork(context.awsRequestId, function(id) {\n        if (id != currentContext.awsRequestId) {\n            console.info(`This callback is from another invocation.`)\n        }\n    })\n}\n\nfunction doWork(id, callback) {\n    setTimeout(() => callback(id), 3000)\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-9.png\" alt=\"\">\u003C\u002Fp>\n\u003Col>\n\u003Cli>The Lambda function handler takes the context parameter, which provides access to a unique invocation request ID.\u003C\u002Fli>\n\u003Cli>The awsRequestId is passed to the doWork function. In the callback, the ID is compared with the awsRequestId of the current invocation. If these values are different, the code can take action accordingly.\u003C\u002Fli>\n\u003C\u002Fol>\n",{"title":6,"order":7},"Troubleshooting Lambda configurations",55,"**Topics**\n\n- [Troubleshooting Lambda configurations](#troubleshooting-lambda-configurations)\n - [Memory configurations](#memory-configurations)\n - [CPU-bound configurations](#cpu-bound-configurations)\n - [Timeouts](#timeouts)\n - [Memory leakage between invocations](#memory-leakage-between-invocations)\n - [Asynchronous results returned to a later invocation](#asynchronous-results-returned-to-a-later-invocation)\n\n## Memory configurations\n\nYou can configure a Lambda function to use between 128 MB and 10,240 MB. By default, any function created in the console is assigned the smallest amount of memory. While many Lambda functions are performant at this lowest setting, if you are importing large code libraries or completing memory intensive tasks, 128 MB is not sufficient.\n\nIf functions are running much slower than expected, the first step is to increase the memory setting. For memory-bound functions, this will resolve the bottleneck and may improve the performance of your function.\n\n## CPU-bound configurations\n\nFor compute-intensive operations, if you experience slower-than-expected performance of your Lambda function, this may be due to your function being CPU-bound. In this case, the computational capacity of the function cannot keep pace with the work.\n\nWhile there is no CPU configuration directly exposed in Lambda configurations, this is indirectly controlled via the memory settings. The Lambda service proportionally allocates more virtual CPU as you allocate more memory. At 1.8 GB of the memory, a Lambda function has an entire vCPU allocated, and above this level it has access to more than one vCPU core. At 10,240MB it has 6 vCPUs available.\n\nIn these cases, you can improve performance by increasing the memory allocation, even if the function doesn’t use all of the memory.\n\n## Timeouts\n\n[Timeouts](https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Fconfiguration-console.html) for Lambda functions can be set between 1 and 900 seconds (15 minutes), with the Lambda console defaulting to 3 seconds. The timeout value is a safety buffer that ends functions that never exit to continue to run indefinitely. Once the timeout value is reached, the function is stopped by the Lambda services.\n\nIf a timeout value is set close to the average duration of a function, this increases the risk that the function will time out unexpectedly. The duration of a function can vary based on the amount of data transfer and processing, and the latency of any services the function interacts with. Some common causes of timeout include:\n\n* When downloading data from S3 buckets or other data stores, the download is larger or takes longer than average.\n* A function makes a request to another service, which takes longer to respond.\n* The parameters provided to a function require more computational complexity in the function, which causes the invocation to take longer.\n\nIn the [Document Repository example](https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fs3-to-lambda-patterns\u002Ftree\u002Fmaster\u002Fdocrepository), the Lambda functions that process objects from the document bucket have 3-second timeout values. These functions may time out for all of these reasons:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-3.png)\n\n1.  As the size of a PDF file grows, the npm library that processes this format takes longer. There is an upper bound after which the processing of the PDF takes longer than 3 seconds.\n2.  Media binaries such as JPG files can be very large. There is an upper bound after which the size of the file takes longer than 3 seconds to download from the S3 bucket.\n3.  In processing the JPG file, Amazon Rekognition takes longer for larger objects and objects with more complexity. This service may take more than 3 seconds to respond.\n\nTimeouts are a safety mechanism and in normal operation do not have a negative impact on cost, since the Lambda service charges by duration. Ensure that your timeout values are not set too close to the average duration of a function to avoid unexpected timeouts.\n\nIn testing your application, ensure that your tests accurately reflect the size and quantity of data, and realistic parameter values. Tests often use small samples for convenience but you should use datasets at the upper bounds of what is reasonably expected for your workload.\n\nImplement upper-bound limits in your workload wherever practical. In this example, the application could use a maximum size limit for each file type. You can then test the performance of your application for a range of expected file sizes, up to and including the maximum limits.\n\n## Memory leakage between invocations\n\nGlobal variables and objects stored in the INIT phase of a Lambda invocation retain their state between warm invocations. They are completely reset only when the execution environment is run for the first time (also known as a “cold start”). Any variables stored in the handler are destroyed when the handler exits. It’s best practice to use the INIT phase to set up database connections, load libraries, create caches, and load immutable assets.\n\nWhen you use third-party libraries across multiple invocations in the same execution environment, be sure to check their documentation for usage in a serverless compute environment. Some database connection and logging libraries may save intermediate invocation results and other data. This causes the memory usage of these libraries to grow with subsequent warm invocations. In cases where memory grows rapidly, you may find the Lambda function runs out of memory, even if your custom code is disposing of variables correctly.\n\nThis issue affects invocations occurring in warm execution environments. For example, the following code creates a memory leak between invocations. The Lambda function consumes additional memory with each invocation by increasing the size of a global array:\n\n```js\nlet a = []\n\nexports.handler = async (event) => {\n    a.push(Array(100000).fill(1))\n}\n```\n\nConfigured with 128 MB of memory, after invoking this function 1000 times, the Monitoring tab of the Lambda function shows the typical changes in invocations, duration, and error counts when a memory leak occurs:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-4.png)\n\n1.  **Invocations**: a steady transaction rate is interrupted periodically as the invocations take longer to complete. During the steady state, the memory leak is not consuming all of the function’s allocated memory. As performance degrades, the operating system is paging local storage to accommodate the growing memory required by the function, which results in fewer transactions being completed.\n2.  **Duration**: before the function runs out of memory, it finishes invocations at a steady double-digit millisecond rate. As paging occurs, the duration takes an order of magnitude longer.\n3.  **Error count**: as the memory leak exceeds allocated memory, eventually the function errors due to the computation exceeding the timeout, or the execution environment stops the function.\n\nAfter the error, the Lambda service restarts the execution environment, which explains why in all three graphs the metrics return to the original state. Expanding the CloudWatch metrics for duration provides more detail for the minimum, maximum and average duration statistics:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-5.png)\n\nTo find the errors generated across the 1000 invocations, you can use the CloudWatch Insights query language. To following query excludes informational logs to report only the errors:\n\n```sql\nfields @timestamp, @message\n| sort @timestamp desc\n| filter @message not like 'EXTENSION'\n| filter @message not like 'Lambda Insights'\n| filter @message not like 'INFO' \n| filter @message not like 'REPORT'\n| filter @message not like 'END'\n| filter @message not like 'START'\n```\n\nWhen run against the log group for this function, this shows that timeouts were responsible for the periodic errors:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-6.png)\n\n## Asynchronous results returned to a later invocation\n\nFor function code that uses asynchronous patterns, it’s possible for the callback results from one invocation to be returned in a future invocation. This example uses Node.js but the same logic can apply to other runtimes using asynchronous patterns. The function uses the traditional callback syntax in JavaScript. It calls an asynchronous function with an incremental counter that tracks the number of invocations:\n\n```js\nlet seqId = 0\n\nexports.handler = async (event, context) => {\n    console.log(`Starting: sequence Id=${++seqId}`)\n    doWork(seqId, function(id) {\n        console.log(`Work done: sequence Id=${id}`)\n    })\n}\n\nfunction doWork(id, callback) {\n    setTimeout(() => callback(id), 3000)\n}\n```\n\nWhen invoked several times in succession, the results of the callbacks occur in subsequent invocations:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-7.png)\n\n1.  The code calls the _doWork_ function, providing a callback function as the last parameter.\n2.  The _doWork_ function takes some period of time to complete before invoking the callback.\n3.  The function’s logging indicates that the invocation is ending before the _doWork_ function finishes execution. Additionally, after starting an iteration, callbacks from previous iterations are being processed, as shown in the logs.\n\nIn JavaScript, asynchronous callbacks are handled with an [event loop](https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FJavaScript\u002FEventLoop). Other runtimes use different mechanisms to handle concurrency. When the function’s execution environment ends, the Lambda service freezes the environment until the next invocation. After it is resumed, JavaScript continues processing the event loop, which in this case includes an asynchronous callback from a previous invocation. Without this context, it can appear that the function is running code for no reason, and returning arbitrary data. In fact, it is really an artifact of how runtime concurrency and the execution environments interact.\n\nThis creates the potential for private data from a previous invocation to appear in a subsequent invocation. There are two ways to prevent or detect this behavior. First, JavaScript provides the [async and await keywords](https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FJavaScript\u002FReference\u002FStatements\u002Fasync_function) to simplify asynchronous development and also force code execution to wait for an asynchronous call to complete. The function above can be rewritten using this approach as follows:\n\n```js\nlet seqId = 0\nexports.handler = async (event) => {\n    console.log(`Starting: sequence Id=${++seqId}`)\n    const result = await doWork(seqId)\n    console.log(`Work done: sequence Id=${result}`)\n}\n\nfunction doWork(id) {\n  return new Promise(resolve => {\n    setTimeout(() => resolve(id), 4000)\n  })\n}\n```\n\nUsing this syntax prevents the handler from exiting before the asynchronous function is finished. In this case, if the callback takes longer than the Lambda function’s timeout, the function will throw an error, instead of returning the callback result in a later invocation:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-8.png)\n\n1.  The code calls the asynchronous _doWork_ function using the await keyword in the handler.\n2.  The _doWork_ function takes some period of time to complete before resolving the promise.\n3.  The function times out because _doWork_ takes longer than the timeout limit allows and the callback result is not returned in a later invocation.\n\nGenerally, you should make sure any background processes or callbacks in the code are complete before the code exits. If this is not possible in your use case, you can use an identifier to ensure that the callback belongs to the current invocation. To do this, you can use the _awsRequestId_ provided by the context object. By passing this value to the asynchronous callback, you can compare the passed value with the current value to detect if the callback originated from another invocation:\n\n```js\nlet currentContext\n\nexports.handler = async (event, context) => {\n    console.log(`Starting: request id=$\\{context.awsRequestId}`)\n    currentContext = context\n\n    doWork(context.awsRequestId, function(id) {\n        if (id != currentContext.awsRequestId) {\n            console.info(`This callback is from another invocation.`)\n        }\n    })\n}\n\nfunction doWork(id, callback) {\n    setTimeout(() => callback(id), 3000)\n}\n```\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-9.png)\n\n1.  The Lambda function handler takes the context parameter, which provides access to a unique invocation request ID.\n2.  The awsRequestId is passed to the doWork function. In the callback, the ID is compared with the awsRequestId of the current invocation. If these values are different, the code can take action accordingly.",[10,21,139,247,314,382,486,555],{"title":-1,"collapsible":11,"isCollapsed":12,"content":13},false,true,[14],{"title":15,"order":16,"time":17,"path":18,"id":19,"link":20},"Introduction",1,"4 min","intro","intro.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fintro",{"title":22,"collapsible":12,"isCollapsed":12,"content":23},"Event-driven architectures",[24,30,37,43,49,55,62,68,74,80,86,92,98,104,110,116,122,128,133],{"title":22,"order":25,"time":26,"path":27,"id":28,"link":29},2,"1 min","event-driven-architectures","event-driven-architectures.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fevent-driven-architectures",{"title":31,"order":32,"time":33,"path":34,"id":35,"link":36},"How Lambda fits into the event-driven paradigm",3,"3 min","lambda-event-driven-paradigm","lambda-event-driven-paradigm.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Flambda-event-driven-paradigm",{"title":38,"order":39,"time":33,"path":40,"id":41,"link":42},"The benefits of event-driven architectures",4,"event-driven-benefits","event-driven-benefits.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fevent-driven-benefits",{"title":44,"order":45,"time":17,"path":46,"id":47,"link":48},"Trade-offs of event-driven architectures",5,"tradeoffs-event-driven","tradeoffs-event-driven.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ftradeoffs-event-driven",{"title":50,"order":51,"time":26,"path":52,"id":53,"link":54},"Design principles",6,"design-principles","design-principles.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fdesign-principles",{"title":56,"order":57,"time":58,"path":59,"id":60,"link":61},"Use services instead of custom code",7,"2 min","services-custom-code","services-custom-code.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fservices-custom-code",{"title":63,"order":64,"time":26,"path":65,"id":66,"link":67},"Understanding the level of abstraction",8,"level-abstraction","level-abstraction.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Flevel-abstraction",{"title":69,"order":70,"time":26,"path":71,"id":72,"link":73},"Implementing statelessness in functions",9,"statelessness-functions","statelessness-functions.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fstatelessness-functions",{"title":75,"order":76,"time":26,"path":77,"id":78,"link":79},"Lambda function design",10,"function-design","function-design.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ffunction-design",{"title":81,"order":82,"time":58,"path":83,"id":84,"link":85},"Building for on-demand data instead of batches",11,"on-demand-batches","on-demand-batches.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fon-demand-batches",{"title":87,"order":88,"time":26,"path":89,"id":90,"link":91},"Orchestration",12,"orchestration","orchestration.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Forchestration",{"title":93,"order":94,"time":58,"path":95,"id":96,"link":97},"Developing for retries and failures",13,"retries-failure","retries-failure.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fretries-failure",{"title":99,"order":100,"time":26,"path":101,"id":102,"link":103},"Anti-patterns in Lambda-based applications",14,"anti-patterns","anti-patterns.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fanti-patterns",{"title":105,"order":106,"time":17,"path":107,"id":108,"link":109},"The Lambda monolith",15,"monolith","monolith.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fmonolith",{"title":111,"order":112,"time":58,"path":113,"id":114,"link":115},"Lambda as orchestrator",16,"orchestrator","orchestrator.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Forchestrator",{"title":117,"order":118,"time":58,"path":119,"id":120,"link":121},"Recursive patterns that cause run-away Lambda functions",17,"recursive-runaway","recursive-runaway.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Frecursive-runaway",{"title":123,"order":124,"time":33,"path":125,"id":126,"link":127},"Lambda functions calling Lambda functions",19,"functions-calling-functions","functions-calling-functions.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ffunctions-calling-functions",{"title":129,"order":124,"time":26,"path":130,"id":131,"link":132},"Synchronous waiting within a single Lambda function","synchronous-waiting","synchronous-waiting.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsynchronous-waiting",{"title":134,"order":135,"time":33,"path":136,"id":137,"link":138},"Frequently asked questions",20,"event-driven-faq","event-driven-faq.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fevent-driven-faq",{"title":140,"collapsible":12,"isCollapsed":12,"content":141},"Application design",[142,147,153,159,165,171,177,182,188,194,200,206,212,218,224,230,236,242],{"title":140,"order":143,"time":26,"path":144,"id":145,"link":146},21,"application-design","application-design.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fapplication-design",{"title":148,"order":149,"time":33,"path":150,"id":151,"link":152},"Understanding quotas",22,"quotas","quotas.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fquotas",{"title":154,"order":155,"time":58,"path":156,"id":157,"link":158},"Architecting with Service Quotas",23,"service-quotas","service-quotas.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fservice-quotas",{"title":160,"order":161,"time":58,"path":162,"id":163,"link":164},"Using multiple AWS accounts for managing quotas",24,"multiple-accounts","multiple-accounts.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fmultiple-accounts",{"title":166,"order":167,"time":26,"path":168,"id":169,"link":170},"Scaling and concurrency in Lambda",25,"scaling-concurrency","scaling-concurrency.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fscaling-concurrency",{"title":172,"order":173,"time":58,"path":174,"id":175,"link":176},"On-demand scaling example",26,"on-demand-scaling","on-demand-scaling.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fon-demand-scaling",{"title":178,"order":173,"time":58,"path":179,"id":180,"link":181},"Provisioned Concurrency scaling example","provisioned-scaling","provisioned-scaling.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fprovisioned-scaling",{"title":183,"order":184,"time":58,"path":185,"id":186,"link":187},"Using service integrations and asynchronous processing",28,"integrations-asynchronous","integrations-asynchronous.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fintegrations-asynchronous",{"title":189,"order":190,"time":58,"path":191,"id":192,"link":193},"Reserved concurrency",29,"reserved-concurrency","reserved-concurrency.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Freserved-concurrency",{"title":195,"order":196,"time":26,"path":197,"id":198,"link":199},"Choosing and managing runtimes in Lambda functions",30,"runtimes-functions","runtimes-functions.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fruntimes-functions",{"title":201,"order":202,"time":26,"path":203,"id":204,"link":205},"Runtimes and performance",31,"runtimes-performance","runtimes-performance.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fruntimes-performance",{"title":207,"order":208,"time":26,"path":209,"id":210,"link":211},"Multiple runtimes in single applications",32,"runtimes-multiple","runtimes-multiple.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fruntimes-multiple",{"title":213,"order":214,"time":26,"path":215,"id":216,"link":217},"Managing AWS SDKs in Lambda functions",33,"sdks-functions","sdks-functions.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsdks-functions",{"title":219,"order":220,"time":33,"path":221,"id":222,"link":223},"Networking and VPC configurations",34,"networking-vpc","networking-vpc.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fnetworking-vpc",{"title":225,"order":226,"time":33,"path":227,"id":228,"link":229},"Comparing Lambda invocation modes",35,"invocation-modes","invocation-modes.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Finvocation-modes",{"title":231,"order":232,"time":58,"path":233,"id":234,"link":235},"Understanding SQS retries",36,"sqs-retries","sqs-retries.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsqs-retries",{"title":237,"order":238,"time":58,"path":239,"id":240,"link":241},"Controlling traffic flow for server-based resources",37,"traffic-server-based","traffic-server-based.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ftraffic-server-based",{"title":134,"order":243,"time":33,"path":244,"id":245,"link":246},38,"application-design-faq","application-design-faq.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fapplication-design-faq",{"title":248,"collapsible":12,"isCollapsed":12,"content":249},"Security",[250,255,261,267,273,279,285,291,297,303,309],{"title":248,"order":251,"time":58,"path":252,"id":253,"link":254},39,"security-ops","security-ops.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsecurity-ops",{"title":256,"order":257,"time":33,"path":258,"id":259,"link":260},"Understanding the Lambda execution environment",40,"execution-environment","execution-environment.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fexecution-environment",{"title":262,"order":263,"time":58,"path":264,"id":265,"link":266},"Applying the principles of least privilege",41,"least-privilege","least-privilege.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fleast-privilege",{"title":268,"order":269,"time":58,"path":270,"id":271,"link":272},"Developing least privilege IAM roles",42,"least-privilege-iam","least-privilege-iam.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fleast-privilege-iam",{"title":274,"order":275,"time":26,"path":276,"id":277,"link":278},"Access to CloudWatch Logs",43,"access-logs","access-logs.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Faccess-logs",{"title":280,"order":281,"time":58,"path":282,"id":283,"link":284},"Avoiding granting wildcard permissions in IAM policies",44,"wildcard-permissions-iam","wildcard-permissions-iam.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fwildcard-permissions-iam",{"title":286,"order":287,"time":26,"path":288,"id":289,"link":290},"Specialized Lambda functions compared with all-purpose functions",45,"specialized-all-purpose","specialized-all-purpose.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fspecialized-all-purpose",{"title":292,"order":293,"time":17,"path":294,"id":295,"link":296},"Securing workloads with public endpoints",46,"public-endpoints","public-endpoints.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fpublic-endpoints",{"title":298,"order":299,"time":58,"path":300,"id":301,"link":302},"Encrypting data in Lambda-based applications",47,"data-in-applications","data-in-applications.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fdata-in-applications",{"title":304,"order":305,"time":33,"path":306,"id":307,"link":308},"Security governance controls",48,"governance-controls","governance-controls.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fgovernance-controls",{"title":134,"order":310,"time":58,"path":311,"id":312,"link":313},49,"security-ops-faq","security-ops-faq.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsecurity-ops-faq",{"title":315,"collapsible":12,"isCollapsed":11,"content":316},"Debugging",[317,322,328,334,340,347,352,358,364,370,376],{"title":315,"order":318,"time":26,"path":319,"id":320,"link":321},50,"debugging-ops","debugging-ops.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fdebugging-ops",{"title":323,"order":324,"time":33,"path":325,"id":326,"link":327},"Standardizing a debugging approach",51,"debugging-approach","debugging-approach.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fdebugging-approach",{"title":329,"order":330,"time":58,"path":331,"id":332,"link":333},"General types of error",52,"general-types","general-types.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fgeneral-types",{"title":335,"order":336,"time":17,"path":337,"id":338,"link":339},"Troubleshooting payloads",53,"payload","payload.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fpayload",{"title":341,"order":342,"time":343,"path":344,"id":345,"link":346},"Troubleshooting integration errors",54,"5 min","integration-errors","integration-errors.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fintegration-errors",{"title":6,"order":7,"time":348,"path":349,"id":350,"link":351},"9 min","configurations","configurations.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fconfigurations",{"title":353,"order":354,"time":58,"path":355,"id":356,"link":357},"Troubleshooting queue processing by Lambda functions",56,"queue-processing","queue-processing.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fqueue-processing",{"title":359,"order":360,"time":58,"path":361,"id":362,"link":363},"Identifying and managing throttling",57,"throttling","throttling.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fthrottling",{"title":365,"order":366,"time":26,"path":367,"id":368,"link":369},"Errors in the processing function",58,"processing-function","processing-function.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fprocessing-function",{"title":371,"order":372,"time":26,"path":373,"id":374,"link":375},"Identifying and handling backpressure",59,"backpressure","backpressure.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fbackpressure",{"title":377,"order":378,"time":33,"path":379,"id":380,"link":381},"Best practices for your debugging environment",60,"best-practices-debugging","best-practices-debugging.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fbest-practices-debugging",{"title":383,"collapsible":12,"isCollapsed":12,"content":384},"Monitoring and observability",[385,390,396,402,408,414,420,426,432,438,444,450,456,462,468,474,480],{"title":383,"order":386,"time":26,"path":387,"id":388,"link":389},61,"monitoring-observability","monitoring-observability.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fmonitoring-observability",{"title":391,"order":392,"time":33,"path":393,"id":394,"link":395},"Monitoring concepts in Lambda-based applications",62,"monitoring-concepts","monitoring-concepts.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fmonitoring-concepts",{"title":397,"order":398,"time":26,"path":399,"id":400,"link":401},"Logging and metrics with Amazon CloudWatch",63,"logging-metrics","logging-metrics.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Flogging-metrics",{"title":403,"order":404,"time":58,"path":405,"id":406,"link":407},"How CloudWatch structures logs",64,"log-structure","log-structure.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Flog-structure",{"title":409,"order":410,"time":33,"path":411,"id":412,"link":413},"Important metrics for CloudWatch",65,"important-metrics","important-metrics.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fimportant-metrics",{"title":415,"order":416,"time":58,"path":417,"id":418,"link":419},"Custom metrics",66,"custom-metrics","custom-metrics.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fcustom-metrics",{"title":421,"order":422,"time":26,"path":423,"id":424,"link":425},"Using AWS Resource Groups to organize your workload",67,"organize-workload","organize-workload.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Forganize-workload",{"title":427,"order":428,"time":58,"path":429,"id":430,"link":431},"Searching across logs with CloudWatch Logs Insights",68,"search-logs","search-logs.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsearch-logs",{"title":433,"order":434,"time":33,"path":435,"id":436,"link":437},"Parsing logs and structured logging",69,"parse-logs","parse-logs.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fparse-logs",{"title":439,"order":440,"time":26,"path":441,"id":442,"link":443},"Querying AWS-generated events",70,"query-events","query-events.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fquery-events",{"title":445,"order":446,"time":26,"path":447,"id":448,"link":449},"Log visualization and dashboard",71,"visualization","visualization.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fvisualization",{"title":451,"order":452,"time":58,"path":453,"id":454,"link":455},"Useful Insights queries",72,"useful-queries","useful-queries.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fuseful-queries",{"title":457,"order":458,"time":58,"path":459,"id":460,"link":461},"Tracing requests with AWS X-Ray",73,"trace-requests","trace-requests.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ftrace-requests",{"title":463,"order":464,"time":343,"path":465,"id":466,"link":467},"Troubleshooting walkthrough: isolating and resolving issues",74,"troubleshooting-walkthrough","troubleshooting-walkthrough.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ftroubleshooting-walkthrough",{"title":469,"order":470,"time":58,"path":471,"id":472,"link":473},"A general approach to debugging Lambda performance issues and errors",75,"general-approach","general-approach.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fgeneral-approach",{"title":475,"order":476,"time":26,"path":477,"id":478,"link":479},"Monitoring Lambda code storage",76,"code-storage","code-storage.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fcode-storage",{"title":481,"order":482,"time":33,"path":483,"id":484,"link":485},"Best practices for managing code storage",77,"code-storage-best-practice","code-storage-best-practice.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fcode-storage-best-practice",{"title":487,"collapsible":12,"isCollapsed":12,"content":488},"Performance optimization",[489,494,501,507,513,519,525,531,537,543,549],{"title":487,"order":490,"time":26,"path":491,"id":492,"link":493},78,"perf-optimize","perf-optimize.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fperf-optimize",{"title":495,"order":496,"time":497,"path":498,"id":499,"link":500},"Lambda execution environments",79,"7 min","execution-environments","execution-environments.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fexecution-environments",{"title":502,"order":503,"time":58,"path":504,"id":505,"link":506},"Memory and computing power",80,"computing-power","computing-power.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fcomputing-power",{"title":508,"order":509,"time":58,"path":510,"id":511,"link":512},"Profiling functions with AWS Lambda Power Tuning",81,"profile-functions","profile-functions.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fprofile-functions",{"title":514,"order":515,"time":33,"path":516,"id":517,"link":518},"Optimizing static initialization",82,"static-initialization","static-initialization.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fstatic-initialization",{"title":520,"order":521,"time":58,"path":522,"id":523,"link":524},"Comparing the effect of global scope",83,"global-scope","global-scope.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fglobal-scope",{"title":526,"order":527,"time":26,"path":528,"id":529,"link":530},"Static initialization and Provisioned Concurrency",84,"initialization-pc","initialization-pc.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Finitialization-pc",{"title":532,"order":533,"time":26,"path":534,"id":535,"link":536},"Architecture and Best Practices",85,"architecture-best-practice","architecture-best-practice.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Farchitecture-best-practice",{"title":538,"order":539,"time":58,"path":540,"id":541,"link":542},"Comparing performance of interactive and asynchronous workloads",86,"interactive-asynchronous","interactive-asynchronous.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Finteractive-asynchronous",{"title":544,"order":545,"time":58,"path":546,"id":547,"link":548},"When not to use a Lambda function",87,"no-function","no-function.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fno-function",{"title":550,"order":551,"time":58,"path":552,"id":553,"link":554},"Cost optimization",88,"cost-optimize","cost-optimize.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fcost-optimize",{"title":-1,"collapsible":11,"isCollapsed":12,"content":556},[557],{"title":558,"order":559,"time":26,"path":560,"id":561,"link":562},"Document history",89,"doc-history","doc-history.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fdoc-history","LIST",[],"AWS Lambda Operator Guide",1790505302537]