[{"data":1,"prerenderedAt":566},["ShallowReactive",2],{"content-svc-lambda-guides-aws-lambda-operator-guide-execution-environments":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":8,"menu":9,"menuType":563,"isCollapseableMenu":12,"nextDocItem":501,"previousDocItem":491,"contributorPaths":564,"contentName":565,"slug":500,"readingTime":497},"\u003Cp>\u003Cstrong>Topics\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca href=\"#lambda-execution-environments\">Lambda execution environments\u003C\u002Fa>\u003Cul>\n\u003Cli>\u003Ca href=\"#cold-starts-and-latency\">Cold starts and latency\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#the-execution-environment-lifecycle\">The execution environment lifecycle\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#understanding-how-functions-warmers-work\">Understanding how functions warmers work\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#reducing-cold-starts-with-provisioned-concurrency\">Reducing cold starts with Provisioned Concurrency\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#understanding-invocation-patterns\">Understanding invocation patterns\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Cold starts and latency\u003C\u002Fh2>\n\u003Cp>When the Lambda service receives a request to run a function via the Lambda API, the service first prepares an execution environment. During this step, the service downloads the code for the function, which is stored in an internal S3 bucket (or in Amazon ECR if the function uses container packaging). It then creates an environment with the memory, runtime, and configuration specified. Once complete, Lambda runs any initialization code outside of the event handler before finally running the handler code.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-1.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>In this diagram, the first two steps of setting up the environment and the code are frequently referred to as a “cold start”. You are not charged for the time it takes for Lambda to prepare the function but it does add latency to the overall invocation duration.\u003C\u002Fp>\n\u003Cp>After the execution completes, the execution environment is frozen. To improve resource management and performance, the Lambda service retains the execution environment for a non-deterministic period of time. During this time, if another request arrives for the same function, the service may reuse the environment. This second request typically finishes more quickly, since the execution environment already exists and it’s not necessary to download the code and run the initialization code. This is called a “warm start”.\u003C\u002Fp>\n\u003Cp>According to an analysis of production Lambda workloads, cold starts typically occur in under 1% of invocations. The duration of a cold start varies from under 100 ms to over 1 second. Since the Lambda service optimizes internally based upon invocation patterns for functions, cold starts are typically more common in development and test functions than production workloads. This is because development and test functions are usually invoked less frequently. Overall, the Lambda service optimizes the execution of functions across all customers to reduce the number of cold starts.\u003C\u002Fp>\n\u003Ch2>The execution environment lifecycle\u003C\u002Fh2>\n\u003Cp>The Lambda service retains the execution environment instead of destroying it immediately after execution. There are also operational factors in the Lambda services that influence the retention time.\u003C\u002Fp>\n\u003Cp>While execution environment reuse is useful, you should not depend on this for performance optimization. Lambda is a high availability service that manages execution across multiple Availability Zones in an AWS Region. Depending upon aggregate customer traffic, the service may load balance a function at any time. As a result, it’s possible for a function to be invoked twice in a short period of time, and both executions experience a cold-start due to this load rebalancing activity.\u003C\u002Fp>\n\u003Cp>Additionally, in the event that a Lambda function scales up due to traffic, each additional concurrent invocation of the function requires a new execution environment. This means that each concurrent execution experiences a cold-start, even as existing concurrent functions may already be warm.\u003C\u002Fp>\n\u003Cp>Finally, anytime you update the code in a Lambda function or change the functional configuration, the next invocation results in a cold start. Any existing environments running a previous version of the “Latest” alias are reaped to ensure that only the new version of the code is used.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-2.png\" alt=\"\">\u003C\u002Fp>\n\u003Ch2>Understanding how functions warmers work\u003C\u002Fh2>\n\u003Cp>The broader serverless community provides open source libraries to “warm” Lambda functions via a pinging mechanism. This approach uses \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Feventbridge\u002Flatest\u002Fuserguide\u002Fscheduled-events.html\">EventBridge rules\u003C\u002Fa> to schedule invocations of the function every minute to help keep the execution environment active. As a result, this can increase the likelihood of using a warm environment when you invoke the function.\u003C\u002Fp>\n\u003Cp>However, this is not a guaranteed way to reduce cold starts. It does not help in production environments when functions scale up to meet traffic. It also does not work if the Lambda service runs your function in another Availability Zone as part of normal load balancing operations. Additionally, the Lambda service reaps execution environments regularly to keep these fresh, so it’s possible to invoke a function in between pings. In all of these cases, you experience cold starts despite using a warming library. This approach might be adequate for development and test environments, or low-traffic or low-priority workloads.\u003C\u002Fp>\n\u003Cp>Additionally, you cannot target a warm environment for an invocation. The Lambda service determines which execution environment receives a request based upon internal queueing and optimization factors. There is no affinity for repeat requests or any concept of “sticky sessions”, as may be set on traditional load balancers.\u003C\u002Fp>\n\u003Ch2>Reducing cold starts with Provisioned Concurrency\u003C\u002Fh2>\n\u003Cp>If you need predictable function start times for your workload, Provisioned Concurrency is the recommended solution to ensure the lowest possible latency. This feature keeps your functions initialized and warm, ready to respond in double-digit milliseconds at the scale you provision. Unlike on-demand Lambda, this means that all setup activities happen ahead of invocation, including running the initialization code.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-3.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>For example, a function with a Provisioned Concurrency of 6 has 6 execution environments prepared ahead of when the invocations occur. In the time between initialization and invocation, the execution environment is prepared and ready.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-4.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>Functions with Provisioned Concurrency differ from on-demand functions in some important ways:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Initialization code\u003C\u002Fstrong> does not need to be optimized. Since this happens long before the invocation, lengthy initialization does not impact the latency of invocations. If you are using runtimes that typically take longer to initialize, like Java, the performance of these can benefit from using Provisioned Concurrency.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Initialization code is run more frequently than the total number of invocations\u003C\u002Fstrong>. Since Lambda is highly available, for every one unit of Provisioned Concurrency, there are a minimum of two execution environments prepared in separate Availability Zones. This is to ensure that your code is available in the event of a service disruption. As environments are reaped and load balancing occurs, Lambda over-provisions environments to ensure availability. You are not charged for this activity. If your code initializer implements logging, you will see additional log files anytime that this code is run, even though the main handler is not invoked.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Provisioned Concurrency cannot be used with the $LATEST version\u003C\u002Fstrong>. This feature can only be used with published versions and aliases of a function. If you see cold starts for functions configured to use Provisioned Concurrency, you may be invoking the $LATEST version, instead of the version or alias with Provisioned Concurrency configured.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Understanding invocation patterns\u003C\u002Fh2>\n\u003Cp>Lambda execution environments handle one request at a time. After the invocation has ended, the execution environment is retained for a period of time. If another request arrives, the environment is reused to handle the subsequent request.\u003C\u002Fp>\n\u003Cp>If requests arrive simultaneously, the Lambda service scales up the Lambda function to provide multiple execution environments. Each environment has to be set up independently, so each invocation experiences a full cold start.\u003C\u002Fp>\n\u003Cp>For example, if API Gateway invokes Lambda six times simultaneously, this causes Lambda to create six execution environments. The total duration of each invocation includes a cold start:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-5.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>However, if API Gateway invokes Lambda 6 times sequentially with a delay between each invocation, the existing execution environments are reused if the previous invocation is complete. In this case, only the first two invocations experience a cold start, while invocations 3 through 6 use warm environments.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-6.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>For asynchronous invocations, an internal queue exists between the caller and the Lambda service. Lambda processes messages from this queue as quickly as possible and scales up automatically as needed. In the event that the function uses reserved concurrency, this acts as a maximum capacity, so the internal queue retains the messages until the function can process them.\u003C\u002Fp>\n\u003Cp>For example, an S3 bucket is configured to invoke a Lambda function when objects are written to the bucket:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-7.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>If the reserved concurrency of the Lambda function is set to 1 and 6 objects are written to the bucket simultaneously, the events are processed sequentially by a single execution environment. Pending events are maintained in the internal queue.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-8.png\" alt=\"\">\u003C\u002Fp>\n",{"title":6,"order":7},"Lambda execution environments",79,"**Topics**\n\n- [Lambda execution environments](#lambda-execution-environments)\n  - [Cold starts and latency](#cold-starts-and-latency)\n  - [The execution environment lifecycle](#the-execution-environment-lifecycle)\n  - [Understanding how functions warmers work](#understanding-how-functions-warmers-work)\n  - [Reducing cold starts with Provisioned Concurrency](#reducing-cold-starts-with-provisioned-concurrency)\n  - [Understanding invocation patterns](#understanding-invocation-patterns)\n\n## Cold starts and latency\n\nWhen the Lambda service receives a request to run a function via the Lambda API, the service first prepares an execution environment. During this step, the service downloads the code for the function, which is stored in an internal S3 bucket (or in Amazon ECR if the function uses container packaging). It then creates an environment with the memory, runtime, and configuration specified. Once complete, Lambda runs any initialization code outside of the event handler before finally running the handler code.\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-1.png)\n\nIn this diagram, the first two steps of setting up the environment and the code are frequently referred to as a “cold start”. You are not charged for the time it takes for Lambda to prepare the function but it does add latency to the overall invocation duration.\n\nAfter the execution completes, the execution environment is frozen. To improve resource management and performance, the Lambda service retains the execution environment for a non-deterministic period of time. During this time, if another request arrives for the same function, the service may reuse the environment. This second request typically finishes more quickly, since the execution environment already exists and it’s not necessary to download the code and run the initialization code. This is called a “warm start”.\n\nAccording to an analysis of production Lambda workloads, cold starts typically occur in under 1% of invocations. The duration of a cold start varies from under 100 ms to over 1 second. Since the Lambda service optimizes internally based upon invocation patterns for functions, cold starts are typically more common in development and test functions than production workloads. This is because development and test functions are usually invoked less frequently. Overall, the Lambda service optimizes the execution of functions across all customers to reduce the number of cold starts.\n\n## The execution environment lifecycle\n\nThe Lambda service retains the execution environment instead of destroying it immediately after execution. There are also operational factors in the Lambda services that influence the retention time.\n\nWhile execution environment reuse is useful, you should not depend on this for performance optimization. Lambda is a high availability service that manages execution across multiple Availability Zones in an AWS Region. Depending upon aggregate customer traffic, the service may load balance a function at any time. As a result, it’s possible for a function to be invoked twice in a short period of time, and both executions experience a cold-start due to this load rebalancing activity.\n\nAdditionally, in the event that a Lambda function scales up due to traffic, each additional concurrent invocation of the function requires a new execution environment. This means that each concurrent execution experiences a cold-start, even as existing concurrent functions may already be warm.\n\nFinally, anytime you update the code in a Lambda function or change the functional configuration, the next invocation results in a cold start. Any existing environments running a previous version of the “Latest” alias are reaped to ensure that only the new version of the code is used.\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-2.png)\n\n## Understanding how functions warmers work\n\nThe broader serverless community provides open source libraries to “warm” Lambda functions via a pinging mechanism. This approach uses [EventBridge rules](https:\u002F\u002Fdocs.aws.amazon.com\u002Feventbridge\u002Flatest\u002Fuserguide\u002Fscheduled-events.html) to schedule invocations of the function every minute to help keep the execution environment active. As a result, this can increase the likelihood of using a warm environment when you invoke the function.\n\nHowever, this is not a guaranteed way to reduce cold starts. It does not help in production environments when functions scale up to meet traffic. It also does not work if the Lambda service runs your function in another Availability Zone as part of normal load balancing operations. Additionally, the Lambda service reaps execution environments regularly to keep these fresh, so it’s possible to invoke a function in between pings. In all of these cases, you experience cold starts despite using a warming library. This approach might be adequate for development and test environments, or low-traffic or low-priority workloads.\n\nAdditionally, you cannot target a warm environment for an invocation. The Lambda service determines which execution environment receives a request based upon internal queueing and optimization factors. There is no affinity for repeat requests or any concept of “sticky sessions”, as may be set on traditional load balancers.\n\n## Reducing cold starts with Provisioned Concurrency\n\nIf you need predictable function start times for your workload, Provisioned Concurrency is the recommended solution to ensure the lowest possible latency. This feature keeps your functions initialized and warm, ready to respond in double-digit milliseconds at the scale you provision. Unlike on-demand Lambda, this means that all setup activities happen ahead of invocation, including running the initialization code.\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-3.png)\n\nFor example, a function with a Provisioned Concurrency of 6 has 6 execution environments prepared ahead of when the invocations occur. In the time between initialization and invocation, the execution environment is prepared and ready.\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-4.png)\n\nFunctions with Provisioned Concurrency differ from on-demand functions in some important ways:\n\n* **Initialization code** does not need to be optimized. Since this happens long before the invocation, lengthy initialization does not impact the latency of invocations. If you are using runtimes that typically take longer to initialize, like Java, the performance of these can benefit from using Provisioned Concurrency.\n* **Initialization code is run more frequently than the total number of invocations**. Since Lambda is highly available, for every one unit of Provisioned Concurrency, there are a minimum of two execution environments prepared in separate Availability Zones. This is to ensure that your code is available in the event of a service disruption. As environments are reaped and load balancing occurs, Lambda over-provisions environments to ensure availability. You are not charged for this activity. If your code initializer implements logging, you will see additional log files anytime that this code is run, even though the main handler is not invoked.\n* **Provisioned Concurrency cannot be used with the $LATEST version**. This feature can only be used with published versions and aliases of a function. If you see cold starts for functions configured to use Provisioned Concurrency, you may be invoking the $LATEST version, instead of the version or alias with Provisioned Concurrency configured.\n\n## Understanding invocation patterns\n\nLambda execution environments handle one request at a time. After the invocation has ended, the execution environment is retained for a period of time. If another request arrives, the environment is reused to handle the subsequent request.\n\nIf requests arrive simultaneously, the Lambda service scales up the Lambda function to provide multiple execution environments. Each environment has to be set up independently, so each invocation experiences a full cold start.\n\nFor example, if API Gateway invokes Lambda six times simultaneously, this causes Lambda to create six execution environments. The total duration of each invocation includes a cold start:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-5.png)\n\nHowever, if API Gateway invokes Lambda 6 times sequentially with a delay between each invocation, the existing execution environments are reused if the previous invocation is complete. In this case, only the first two invocations experience a cold start, while invocations 3 through 6 use warm environments.\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-6.png)\n\nFor asynchronous invocations, an internal queue exists between the caller and the Lambda service. Lambda processes messages from this queue as quickly as possible and scales up automatically as needed. In the event that the function uses reserved concurrency, this acts as a maximum capacity, so the internal queue retains the messages until the function can process them.\n\nFor example, an S3 bucket is configured to invoke a Lambda function when objects are written to the bucket:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-7.png)\n\nIf the reserved concurrency of the Lambda function is set to 1 and 6 objects are written to the bucket simultaneously, the events are processed sequentially by a single execution environment. Pending events are maintained in the internal queue.\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fperf-optimize-figure-8.png)",[10,21,139,247,314,384,488,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":12,"content":316},"Debugging",[317,322,328,334,340,347,354,360,366,372,378],{"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":348,"order":349,"time":350,"path":351,"id":352,"link":353},"Troubleshooting Lambda configurations",55,"9 min","configurations","configurations.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fconfigurations",{"title":355,"order":356,"time":58,"path":357,"id":358,"link":359},"Troubleshooting queue processing by Lambda functions",56,"queue-processing","queue-processing.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fqueue-processing",{"title":361,"order":362,"time":58,"path":363,"id":364,"link":365},"Identifying and managing throttling",57,"throttling","throttling.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fthrottling",{"title":367,"order":368,"time":26,"path":369,"id":370,"link":371},"Errors in the processing function",58,"processing-function","processing-function.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fprocessing-function",{"title":373,"order":374,"time":26,"path":375,"id":376,"link":377},"Identifying and handling backpressure",59,"backpressure","backpressure.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fbackpressure",{"title":379,"order":380,"time":33,"path":381,"id":382,"link":383},"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":385,"collapsible":12,"isCollapsed":12,"content":386},"Monitoring and observability",[387,392,398,404,410,416,422,428,434,440,446,452,458,464,470,476,482],{"title":385,"order":388,"time":26,"path":389,"id":390,"link":391},61,"monitoring-observability","monitoring-observability.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fmonitoring-observability",{"title":393,"order":394,"time":33,"path":395,"id":396,"link":397},"Monitoring concepts in Lambda-based applications",62,"monitoring-concepts","monitoring-concepts.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fmonitoring-concepts",{"title":399,"order":400,"time":26,"path":401,"id":402,"link":403},"Logging and metrics with Amazon CloudWatch",63,"logging-metrics","logging-metrics.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Flogging-metrics",{"title":405,"order":406,"time":58,"path":407,"id":408,"link":409},"How CloudWatch structures logs",64,"log-structure","log-structure.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Flog-structure",{"title":411,"order":412,"time":33,"path":413,"id":414,"link":415},"Important metrics for CloudWatch",65,"important-metrics","important-metrics.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fimportant-metrics",{"title":417,"order":418,"time":58,"path":419,"id":420,"link":421},"Custom metrics",66,"custom-metrics","custom-metrics.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fcustom-metrics",{"title":423,"order":424,"time":26,"path":425,"id":426,"link":427},"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":429,"order":430,"time":58,"path":431,"id":432,"link":433},"Searching across logs with CloudWatch Logs Insights",68,"search-logs","search-logs.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsearch-logs",{"title":435,"order":436,"time":33,"path":437,"id":438,"link":439},"Parsing logs and structured logging",69,"parse-logs","parse-logs.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fparse-logs",{"title":441,"order":442,"time":26,"path":443,"id":444,"link":445},"Querying AWS-generated events",70,"query-events","query-events.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fquery-events",{"title":447,"order":448,"time":26,"path":449,"id":450,"link":451},"Log visualization and dashboard",71,"visualization","visualization.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fvisualization",{"title":453,"order":454,"time":58,"path":455,"id":456,"link":457},"Useful Insights queries",72,"useful-queries","useful-queries.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fuseful-queries",{"title":459,"order":460,"time":58,"path":461,"id":462,"link":463},"Tracing requests with AWS X-Ray",73,"trace-requests","trace-requests.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ftrace-requests",{"title":465,"order":466,"time":343,"path":467,"id":468,"link":469},"Troubleshooting walkthrough: isolating and resolving issues",74,"troubleshooting-walkthrough","troubleshooting-walkthrough.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ftroubleshooting-walkthrough",{"title":471,"order":472,"time":58,"path":473,"id":474,"link":475},"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":477,"order":478,"time":26,"path":479,"id":480,"link":481},"Monitoring Lambda code storage",76,"code-storage","code-storage.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fcode-storage",{"title":483,"order":484,"time":33,"path":485,"id":486,"link":487},"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":489,"collapsible":12,"isCollapsed":11,"content":490},"Performance optimization",[491,496,501,507,513,519,525,531,537,543,549],{"title":489,"order":492,"time":26,"path":493,"id":494,"link":495},78,"perf-optimize","perf-optimize.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fperf-optimize",{"title":6,"order":7,"time":497,"path":498,"id":499,"link":500},"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",1792578871868]