[{"data":1,"prerenderedAt":566},["ShallowReactive",2],{"content-svc-lambda-guides-aws-lambda-operator-guide-integration-errors":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":8,"menu":9,"menuType":563,"isCollapseableMenu":12,"nextDocItem":345,"previousDocItem":334,"contributorPaths":564,"contentName":565,"slug":344,"readingTime":341},"\u003Ch2>Running an unintended function version or alias\u003C\u002Fh2>\n\u003Cp>When you publish new Lambda functions in the console or using AWS SAM, the latest code version is represented by the $LATEST alias. Once deployed, any event invoking this alias automatically runs the latest version of the code.\u003C\u002Fp>\n\u003Cp>There are many situations when you may use other versions and aliases of Lambda functions. For example, you may use \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fimplementing-canary-deployments-of-aws-lambda-functions-with-alias-traffic-shifting\u002F\">canary deployments to shift traffic\u003C\u002Fa> between aliases as part of a deployment process. Or you may use Provisioned Concurrency, which can only be applied to a published version or alias of a function, not the $LATEST version. If you use Serverless Framework, \u003Ca href=\"https:\u002F\u002Fwww.serverless.com\u002Fframework\u002Fdocs\u002Fproviders\u002Faws\u002Fguide\u002Fdeploying\u002F\">deploying code\u003C\u002Fa> always results in publishing a new function version.\u003C\u002Fp>\n\u003Cp>In any of these cases, there are immutable published versions of a function in addition to the $LATEST version. When troubleshooting these functions, first determine that the caller has triggered the intended version or alias. Next, when checking the logs, verify the version of the function that has been invoked, which is always shown in the START log line:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-1.png\" alt=\"\">\u003C\u002Fp>\n\u003Ch2>Triggering infinite loops\u003C\u002Fh2>\n\u003Cp>There are two types of infinite loops in Lambda functions. The first is within the function itself, caused by a loop that never exits and the invocation only ends when the function times out. You can identify these by monitoring timeouts (see chapter 5) and the remediation steps should modify the looping behavior.\u003C\u002Fp>\n\u003Cp>The second type of loop is between Lambda functions and other AWS resources. These occur when an event from a resource like an S3 bucket invokes a Lambda function, which then interacts with the same source resource to trigger another event. This invokes the function again, which in turn creates another interaction with the same S3 bucket, and so on. These types of loops can be caused by a number of different AWS event sources, including SQS queues and DynamoDB tables.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-2.png\" alt=\"\">\u003C\u002Fp>\n\u003Col>\n\u003Cli>An SQS queue publishes messages to a Lambda function, which creates new messages for the same SQS queue.\u003C\u002Fli>\n\u003Cli>A DynamoDB table triggers a Lambda function via a stream, which writes new items back to the same DynamoDB table.\u003C\u002Fli>\n\u003Cli>An S3 bucket invokes Lambda function, which then interacts with the same S3 bucket to produce another invocation.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Unlike a typical in-process loop, the scaling behaviors of the services can cause such loops to consume considerable resources. Lambda quickly scales up functions as more traffic arrives, which causes more interaction with the triggering resource. This continues to grow rapidly until Lambda meets its concurrency limit or the resource producing event is throttled by a Service Quota.\u003C\u002Fp>\n\u003Cp>You can avoid these loops by ensuring that Lambda functions write to resources that are not the same as the consuming resource, and implementing \u003Ca href=\"https:\u002F\u002Fdev.to\u002Fcdkpatterns\u002Fadd-resiliency-to-your-lambda-with-a-circuit-breaker-1na6\">circuit breakers\u003C\u002Fa> for more complex loop patterns. If you must publish data back to the consuming resource, ensure that the new data does not trigger the same event, or the Lambda function can filter events. For example:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>If you write back to the same S3 bucket, use a different prefix or suffix from the event trigger, or use an object meta tag that the consuming function can filter on. For a detailed example, see \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fs3-to-lambda-patterns\u002Ftree\u002Fmaster\u002Ftranslation\">this repo\u003C\u002Fa>.\u003C\u002Fli>\n\u003Cli>If you write items to the same DynamoDB table, include an attribute that a consuming Lambda function can filter on, and exit if the attribute is found.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Downstream unavailability\u003C\u002Fh2>\n\u003Cp>For Lambda functions that call out to third-party endpoints or other downstream resources, you should ensure they can handle service errors and timeouts. These downstream resources may have variable response times or may become unavailable due to service disruptions. Depending upon the implementation, these downstream errors may appear as Lambda function timeouts or exceptions, if the service’s error response is not handled within the function’s custom code.\u003C\u002Fp>\n\u003Cp>Anytime a function depends on a downstream service, such as an API call, you should implement appropriate error handling and retry logic. For critical services, the Lambda function should publish metrics or logs to CloudWatch, and you can then create alarms. For example, if a third-party payment API becomes unavailable, a Lambda function can log this information, then CloudWatch alarms can send a notification to you.\u003C\u002Fp>\n\u003Cp>Since the Lambda service can scale invocations quickly, non-serverless downstream services may struggle to handle spikes in traffic. There are three common approaches to handling this:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Caching\u003C\u002Fstrong>: where data in the third-party service does not change frequently or may return the same values across many requests, consider caching the result in either a global object in your function, or another service. For example, the results for a product list query from an Amazon RDS instance could be saved for a period of time within the function to prevent redundant queries.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Queuing\u003C\u002Fstrong>: when saving or updating data, adding an SQS queue between the Lambda function and the resource can smooth out traffic. The queue durably persists data while the downstream service processes messages. For an example, see the \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fs3-to-lambda-patterns\u002Ftree\u002Fmaster\u002Fdocrepository\">Serverless Document Repository application\u003C\u002Fa>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Proxies\u003C\u002Fstrong>: where long-lived connections are typically used, such as for RDS instances, use a proxy layer to pool and reuse those connections. For relational databases, \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fs3-to-lambda-patterns\u002Ftree\u002Fmaster\u002Fdocrepository\">Amazon RDS Proxy\u003C\u002Fa> is a service designed to help improve scalability and resiliency in serverless applications.\u003C\u002Fli>\n\u003C\u002Ful>\n",{"title":6,"order":7},"Troubleshooting integration errors",54,"## Running an unintended function version or alias\n\nWhen you publish new Lambda functions in the console or using AWS SAM, the latest code version is represented by the $LATEST alias. Once deployed, any event invoking this alias automatically runs the latest version of the code.\n\nThere are many situations when you may use other versions and aliases of Lambda functions. For example, you may use [canary deployments to shift traffic](https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fimplementing-canary-deployments-of-aws-lambda-functions-with-alias-traffic-shifting\u002F) between aliases as part of a deployment process. Or you may use Provisioned Concurrency, which can only be applied to a published version or alias of a function, not the $LATEST version. If you use Serverless Framework, [deploying code](https:\u002F\u002Fwww.serverless.com\u002Fframework\u002Fdocs\u002Fproviders\u002Faws\u002Fguide\u002Fdeploying\u002F) always results in publishing a new function version.\n\nIn any of these cases, there are immutable published versions of a function in addition to the $LATEST version. When troubleshooting these functions, first determine that the caller has triggered the intended version or alias. Next, when checking the logs, verify the version of the function that has been invoked, which is always shown in the START log line:\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-1.png)\n\n## Triggering infinite loops\n\nThere are two types of infinite loops in Lambda functions. The first is within the function itself, caused by a loop that never exits and the invocation only ends when the function times out. You can identify these by monitoring timeouts (see chapter 5) and the remediation steps should modify the looping behavior.\n\nThe second type of loop is between Lambda functions and other AWS resources. These occur when an event from a resource like an S3 bucket invokes a Lambda function, which then interacts with the same source resource to trigger another event. This invokes the function again, which in turn creates another interaction with the same S3 bucket, and so on. These types of loops can be caused by a number of different AWS event sources, including SQS queues and DynamoDB tables.\n\n![](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fassets\u002Fimages\u002Fdebugging-ops-figure-2.png)\n\n1.  An SQS queue publishes messages to a Lambda function, which creates new messages for the same SQS queue.\n2.  A DynamoDB table triggers a Lambda function via a stream, which writes new items back to the same DynamoDB table.\n3.  An S3 bucket invokes Lambda function, which then interacts with the same S3 bucket to produce another invocation.\n\nUnlike a typical in-process loop, the scaling behaviors of the services can cause such loops to consume considerable resources. Lambda quickly scales up functions as more traffic arrives, which causes more interaction with the triggering resource. This continues to grow rapidly until Lambda meets its concurrency limit or the resource producing event is throttled by a Service Quota.\n\nYou can avoid these loops by ensuring that Lambda functions write to resources that are not the same as the consuming resource, and implementing [circuit breakers](https:\u002F\u002Fdev.to\u002Fcdkpatterns\u002Fadd-resiliency-to-your-lambda-with-a-circuit-breaker-1na6) for more complex loop patterns. If you must publish data back to the consuming resource, ensure that the new data does not trigger the same event, or the Lambda function can filter events. For example:\n\n* If you write back to the same S3 bucket, use a different prefix or suffix from the event trigger, or use an object meta tag that the consuming function can filter on. For a detailed example, see [this repo](https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fs3-to-lambda-patterns\u002Ftree\u002Fmaster\u002Ftranslation).\n* If you write items to the same DynamoDB table, include an attribute that a consuming Lambda function can filter on, and exit if the attribute is found.\n\n## Downstream unavailability\n\nFor Lambda functions that call out to third-party endpoints or other downstream resources, you should ensure they can handle service errors and timeouts. These downstream resources may have variable response times or may become unavailable due to service disruptions. Depending upon the implementation, these downstream errors may appear as Lambda function timeouts or exceptions, if the service’s error response is not handled within the function’s custom code.\n\nAnytime a function depends on a downstream service, such as an API call, you should implement appropriate error handling and retry logic. For critical services, the Lambda function should publish metrics or logs to CloudWatch, and you can then create alarms. For example, if a third-party payment API becomes unavailable, a Lambda function can log this information, then CloudWatch alarms can send a notification to you.\n\nSince the Lambda service can scale invocations quickly, non-serverless downstream services may struggle to handle spikes in traffic. There are three common approaches to handling this:\n\n* **Caching**: where data in the third-party service does not change frequently or may return the same values across many requests, consider caching the result in either a global object in your function, or another service. For example, the results for a product list query from an Amazon RDS instance could be saved for a period of time within the function to prevent redundant queries.\n* **Queuing**: when saving or updating data, adding an SQS queue between the Lambda function and the resource can smooth out traffic. The queue durably persists data while the downstream service processes messages. For an example, see the [Serverless Document Repository application](https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fs3-to-lambda-patterns\u002Ftree\u002Fmaster\u002Fdocrepository).\n* **Proxies**: where long-lived connections are typically used, such as for RDS instances, use a proxy layer to pool and reuse those connections. For relational databases, [Amazon RDS Proxy](https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fs3-to-lambda-patterns\u002Ftree\u002Fmaster\u002Fdocrepository) is a service designed to help improve scalability and resiliency in serverless applications.",[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,345,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":6,"order":7,"time":341,"path":342,"id":343,"link":344},"5 min","integration-errors","integration-errors.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fintegration-errors",{"title":346,"order":347,"time":348,"path":349,"id":350,"link":351},"Troubleshooting Lambda configurations",55,"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":341,"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",1792578868847]