[{"data":1,"prerenderedAt":566},["ShallowReactive",2],{"content-svc-lambda-guides-aws-lambda-operator-guide-tradeoffs-event-driven":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":8,"menu":9,"menuType":563,"isCollapseableMenu":12,"nextDocItem":47,"previousDocItem":37,"contributorPaths":564,"contentName":565,"slug":46,"readingTime":17},"\u003Ch2>Variable latency\u003C\u002Fh2>\n\u003Cp>Unlike monolithic applications, which may process everything within the same memory space on a single device, event-driven applications communicate across networks. This design introduces variable latency. While it’s possible to engineer applications to minimize latency, monolithic applications can almost always be optimized for lower latency at the expense of scalability and availability.\u003C\u002Fp>\n\u003Cp>The serverless services in AWS are highly available, meaning that they operate in more than one Availability Zone in a Region. In the event of a service disruption, services automatically fail over to alternative Availability Zones and retry transactions. As a result, instead of a transaction failing, it may be completed successfully but with higher latency.\u003C\u002Fp>\n\u003Cp>Workloads that require consistent low-latency performance, such as high-frequency trading applications in banks or submillisecond robotics automation in warehouses, are not good candidates for event-driven architecture.\u003C\u002Fp>\n\u003Ch2>Eventual consistency\u003C\u002Fh2>\n\u003Cp>An event represents a change in state, and with many events flowing through different services in an architecture at any given point of time, such workloads are often \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEventual_consistency\">eventually consistent\u003C\u002Fa>. This makes it more complex to process transactions, handle duplicates, or determine the exact overall state of a system.\u003C\u002Fp>\n\u003Cp>Some workloads are not well suited for event-driven architecture, due to the need for \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FACID\">ACID properties\u003C\u002Fa>. However, many workloads contain a combination of requirements that are eventually consistent (for example, total orders in the current hour) or strongly consistent (for example, current inventory). For those features needing strong data consistency, there are architecture patterns to support this. For example:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>DynamoDB can provide \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002FHowItWorks.ReadConsistency.html\">strongly consistent reads\u003C\u002Fa>, sometimes at a higher latency, consuming a greater throughput than the default mode. DynamoDB can also \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002Ftransactions.html\">support transactions\u003C\u002Fa> to help main data consistency.\u003C\u002Fli>\n\u003Cli>You can use Amazon RDS for features needing \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FACID\">ACID properties\u003C\u002Fa>, though any relational database is less scalable than a NoSQL data store like DynamoDB. \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Frds\u002Fproxy\u002F\">Amazon RDS Proxy\u003C\u002Fa> can help manage connection pooling and scaling from ephemeral consumers like Lambda functions.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Event-based architectures are usually designed around individual events instead of large batches of data. Generally, workflows are designed to manage the steps of an individual event or execution flow instead of operating on multiple events simultaneously. In serverless, real-time event processing is preferred to batch processing in event-driven systems, replacing a batch with many smaller incremental updates. While this can make workloads significantly more available and scalable, it also makes it more challenging for events to have awareness of other events.\u003C\u002Fp>\n\u003Ch2>Returning values to callers\u003C\u002Fh2>\n\u003Cp>In many cases, event-based applications are asynchronous. This means that caller services do not wait for requests from other services before continuing with other work. This is a fundamental characteristic of event-driven architectures that enables scalability and flexibility. This means that passing return values or the result of a workflow is often more complex than in synchronous execution flows.\u003C\u002Fp>\n\u003Cp>Most Lambda invocations in production systems are asynchronous, responding to events from services like Amazon S3 or Amazon SQS. In these cases, the success or failure of processing an event is often more important than returning a value. Features such as \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Finvocation-async.html\">dead letter queues\u003C\u002Fa> (DLQs) in Lambda are provided to ensure you can identify and retry failed events, without needing to notify the caller.\u003C\u002Fp>\n\u003Cp>For interactive workloads, such as web and mobile applications, the end user usually expects to receive a return value or a current status of a transaction. For these workloads, there are \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fmanaging-backend-requests-and-frontend-notifications-in-serverless-web-apps\u002F\">several design patterns\u003C\u002Fa> that can provide rich eventing back to the caller, but these implementations are more complex than using a traditional asynchronous return value.\u003C\u002Fp>\n\u003Ch2>Debugging across services and functions\u003C\u002Fh2>\n\u003Cp>Debugging event-driven systems is also different to solving problems with a monolithic application. With different systems and services passing events, it is often not possible to record and reproduce the exact state of multiple services when an error occurs. Since each service and function invocation has separate log files, it can be more complicated to determine what happened to a specific event that caused an error.\u003C\u002Fp>\n\u003Cp>There are three important requirements for building a successful debugging approach in event-driven systems. First, a robust logging system is critical, and this is provided across AWS services and embedded in Lambda functions by Amazon CloudWatch. Second, in these systems, it’s important to ensure that every event has a transaction identifier that is logged at each step throughout a transaction, to help when searching for logs.\u003C\u002Fp>\n\u003Cp>Finally, it’s highly recommended to automate the parsing and analysis of logs by using a debugging and monitoring service like AWS X-Ray. This can consume logs across multiple Lambda invocations and services, making it much easier to pinpoint the root cause of issues. See \u003Ca href=\"troubleshooting-walkthrough\">troubleshooting-walkthrough\u003C\u002Fa> for in-depth coverage of using X-Ray for troubleshooting.\u003C\u002Fp>\n\u003Cp>To learn more, read \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fbuilders-library\u002Fchallenges-with-distributed-systems\u002F\">Challenges with distributed systems\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fd1.awsstatic.com\u002Fwhitepapers\u002Fmicroservices-on-aws.pdf\">Implementing Microservices on AWS\u003C\u002Fa>.\u003C\u002Fp>\n",{"title":6,"order":7},"Trade-offs of event-driven architectures",5,"## Variable latency\n\nUnlike monolithic applications, which may process everything within the same memory space on a single device, event-driven applications communicate across networks. This design introduces variable latency. While it’s possible to engineer applications to minimize latency, monolithic applications can almost always be optimized for lower latency at the expense of scalability and availability.\n\nThe serverless services in AWS are highly available, meaning that they operate in more than one Availability Zone in a Region. In the event of a service disruption, services automatically fail over to alternative Availability Zones and retry transactions. As a result, instead of a transaction failing, it may be completed successfully but with higher latency.\n\nWorkloads that require consistent low-latency performance, such as high-frequency trading applications in banks or submillisecond robotics automation in warehouses, are not good candidates for event-driven architecture.\n\n## Eventual consistency\n\nAn event represents a change in state, and with many events flowing through different services in an architecture at any given point of time, such workloads are often [eventually consistent](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEventual_consistency). This makes it more complex to process transactions, handle duplicates, or determine the exact overall state of a system.\n\nSome workloads are not well suited for event-driven architecture, due to the need for [ACID properties](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FACID). However, many workloads contain a combination of requirements that are eventually consistent (for example, total orders in the current hour) or strongly consistent (for example, current inventory). For those features needing strong data consistency, there are architecture patterns to support this. For example:\n\n* DynamoDB can provide [strongly consistent reads](https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002FHowItWorks.ReadConsistency.html), sometimes at a higher latency, consuming a greater throughput than the default mode. DynamoDB can also [support transactions](https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002Ftransactions.html) to help main data consistency.\n* You can use Amazon RDS for features needing [ACID properties](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FACID), though any relational database is less scalable than a NoSQL data store like DynamoDB. [Amazon RDS Proxy](https:\u002F\u002Faws.amazon.com\u002Frds\u002Fproxy\u002F) can help manage connection pooling and scaling from ephemeral consumers like Lambda functions.\n\nEvent-based architectures are usually designed around individual events instead of large batches of data. Generally, workflows are designed to manage the steps of an individual event or execution flow instead of operating on multiple events simultaneously. In serverless, real-time event processing is preferred to batch processing in event-driven systems, replacing a batch with many smaller incremental updates. While this can make workloads significantly more available and scalable, it also makes it more challenging for events to have awareness of other events.\n\n## Returning values to callers\n\nIn many cases, event-based applications are asynchronous. This means that caller services do not wait for requests from other services before continuing with other work. This is a fundamental characteristic of event-driven architectures that enables scalability and flexibility. This means that passing return values or the result of a workflow is often more complex than in synchronous execution flows.\n\nMost Lambda invocations in production systems are asynchronous, responding to events from services like Amazon S3 or Amazon SQS. In these cases, the success or failure of processing an event is often more important than returning a value. Features such as [dead letter queues](https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Finvocation-async.html) (DLQs) in Lambda are provided to ensure you can identify and retry failed events, without needing to notify the caller.\n\nFor interactive workloads, such as web and mobile applications, the end user usually expects to receive a return value or a current status of a transaction. For these workloads, there are [several design patterns](https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fmanaging-backend-requests-and-frontend-notifications-in-serverless-web-apps\u002F) that can provide rich eventing back to the caller, but these implementations are more complex than using a traditional asynchronous return value.\n\n## Debugging across services and functions\n\nDebugging event-driven systems is also different to solving problems with a monolithic application. With different systems and services passing events, it is often not possible to record and reproduce the exact state of multiple services when an error occurs. Since each service and function invocation has separate log files, it can be more complicated to determine what happened to a specific event that caused an error.\n\nThere are three important requirements for building a successful debugging approach in event-driven systems. First, a robust logging system is critical, and this is provided across AWS services and embedded in Lambda functions by Amazon CloudWatch. Second, in these systems, it’s important to ensure that every event has a transaction identifier that is logged at each step throughout a transaction, to help when searching for logs.\n\nFinally, it’s highly recommended to automate the parsing and analysis of logs by using a debugging and monitoring service like AWS X-Ray. This can consume logs across multiple Lambda invocations and services, making it much easier to pinpoint the root cause of issues. See [troubleshooting-walkthrough](troubleshooting-walkthrough) for in-depth coverage of using X-Ray for troubleshooting.\n\nTo learn more, read [Challenges with distributed systems](https:\u002F\u002Faws.amazon.com\u002Fbuilders-library\u002Fchallenges-with-distributed-systems\u002F) and [Implementing Microservices on AWS](https:\u002F\u002Fd1.awsstatic.com\u002Fwhitepapers\u002Fmicroservices-on-aws.pdf).\n",[10,21,137,245,312,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":11,"content":23},"Event-driven architectures",[24,30,37,43,47,53,60,66,72,78,84,90,96,102,108,114,120,126,131],{"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":6,"order":7,"time":17,"path":44,"id":45,"link":46},"tradeoffs-event-driven","tradeoffs-event-driven.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ftradeoffs-event-driven",{"title":48,"order":49,"time":26,"path":50,"id":51,"link":52},"Design principles",6,"design-principles","design-principles.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fdesign-principles",{"title":54,"order":55,"time":56,"path":57,"id":58,"link":59},"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":61,"order":62,"time":26,"path":63,"id":64,"link":65},"Understanding the level of abstraction",8,"level-abstraction","level-abstraction.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Flevel-abstraction",{"title":67,"order":68,"time":26,"path":69,"id":70,"link":71},"Implementing statelessness in functions",9,"statelessness-functions","statelessness-functions.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fstatelessness-functions",{"title":73,"order":74,"time":26,"path":75,"id":76,"link":77},"Lambda function design",10,"function-design","function-design.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Ffunction-design",{"title":79,"order":80,"time":56,"path":81,"id":82,"link":83},"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":85,"order":86,"time":26,"path":87,"id":88,"link":89},"Orchestration",12,"orchestration","orchestration.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Forchestration",{"title":91,"order":92,"time":56,"path":93,"id":94,"link":95},"Developing for retries and failures",13,"retries-failure","retries-failure.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fretries-failure",{"title":97,"order":98,"time":26,"path":99,"id":100,"link":101},"Anti-patterns in Lambda-based applications",14,"anti-patterns","anti-patterns.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fanti-patterns",{"title":103,"order":104,"time":17,"path":105,"id":106,"link":107},"The Lambda monolith",15,"monolith","monolith.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fmonolith",{"title":109,"order":110,"time":56,"path":111,"id":112,"link":113},"Lambda as orchestrator",16,"orchestrator","orchestrator.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Forchestrator",{"title":115,"order":116,"time":56,"path":117,"id":118,"link":119},"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":121,"order":122,"time":33,"path":123,"id":124,"link":125},"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":127,"order":122,"time":26,"path":128,"id":129,"link":130},"Synchronous waiting within a single Lambda function","synchronous-waiting","synchronous-waiting.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsynchronous-waiting",{"title":132,"order":133,"time":33,"path":134,"id":135,"link":136},"Frequently asked questions",20,"event-driven-faq","event-driven-faq.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fevent-driven-faq",{"title":138,"collapsible":12,"isCollapsed":12,"content":139},"Application design",[140,145,151,157,163,169,175,180,186,192,198,204,210,216,222,228,234,240],{"title":138,"order":141,"time":26,"path":142,"id":143,"link":144},21,"application-design","application-design.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fapplication-design",{"title":146,"order":147,"time":33,"path":148,"id":149,"link":150},"Understanding quotas",22,"quotas","quotas.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fquotas",{"title":152,"order":153,"time":56,"path":154,"id":155,"link":156},"Architecting with Service Quotas",23,"service-quotas","service-quotas.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fservice-quotas",{"title":158,"order":159,"time":56,"path":160,"id":161,"link":162},"Using multiple AWS accounts for managing quotas",24,"multiple-accounts","multiple-accounts.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fmultiple-accounts",{"title":164,"order":165,"time":26,"path":166,"id":167,"link":168},"Scaling and concurrency in Lambda",25,"scaling-concurrency","scaling-concurrency.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fscaling-concurrency",{"title":170,"order":171,"time":56,"path":172,"id":173,"link":174},"On-demand scaling example",26,"on-demand-scaling","on-demand-scaling.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fon-demand-scaling",{"title":176,"order":171,"time":56,"path":177,"id":178,"link":179},"Provisioned Concurrency scaling example","provisioned-scaling","provisioned-scaling.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fprovisioned-scaling",{"title":181,"order":182,"time":56,"path":183,"id":184,"link":185},"Using service integrations and asynchronous processing",28,"integrations-asynchronous","integrations-asynchronous.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fintegrations-asynchronous",{"title":187,"order":188,"time":56,"path":189,"id":190,"link":191},"Reserved concurrency",29,"reserved-concurrency","reserved-concurrency.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Freserved-concurrency",{"title":193,"order":194,"time":26,"path":195,"id":196,"link":197},"Choosing and managing runtimes in Lambda functions",30,"runtimes-functions","runtimes-functions.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fruntimes-functions",{"title":199,"order":200,"time":26,"path":201,"id":202,"link":203},"Runtimes and performance",31,"runtimes-performance","runtimes-performance.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fruntimes-performance",{"title":205,"order":206,"time":26,"path":207,"id":208,"link":209},"Multiple runtimes in single applications",32,"runtimes-multiple","runtimes-multiple.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fruntimes-multiple",{"title":211,"order":212,"time":26,"path":213,"id":214,"link":215},"Managing AWS SDKs in Lambda functions",33,"sdks-functions","sdks-functions.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsdks-functions",{"title":217,"order":218,"time":33,"path":219,"id":220,"link":221},"Networking and VPC configurations",34,"networking-vpc","networking-vpc.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fnetworking-vpc",{"title":223,"order":224,"time":33,"path":225,"id":226,"link":227},"Comparing Lambda invocation modes",35,"invocation-modes","invocation-modes.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Finvocation-modes",{"title":229,"order":230,"time":56,"path":231,"id":232,"link":233},"Understanding SQS retries",36,"sqs-retries","sqs-retries.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsqs-retries",{"title":235,"order":236,"time":56,"path":237,"id":238,"link":239},"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":132,"order":241,"time":33,"path":242,"id":243,"link":244},38,"application-design-faq","application-design-faq.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fapplication-design-faq",{"title":246,"collapsible":12,"isCollapsed":12,"content":247},"Security",[248,253,259,265,271,277,283,289,295,301,307],{"title":246,"order":249,"time":56,"path":250,"id":251,"link":252},39,"security-ops","security-ops.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsecurity-ops",{"title":254,"order":255,"time":33,"path":256,"id":257,"link":258},"Understanding the Lambda execution environment",40,"execution-environment","execution-environment.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fexecution-environment",{"title":260,"order":261,"time":56,"path":262,"id":263,"link":264},"Applying the principles of least privilege",41,"least-privilege","least-privilege.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fleast-privilege",{"title":266,"order":267,"time":56,"path":268,"id":269,"link":270},"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":272,"order":273,"time":26,"path":274,"id":275,"link":276},"Access to CloudWatch Logs",43,"access-logs","access-logs.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Faccess-logs",{"title":278,"order":279,"time":56,"path":280,"id":281,"link":282},"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":284,"order":285,"time":26,"path":286,"id":287,"link":288},"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":290,"order":291,"time":17,"path":292,"id":293,"link":294},"Securing workloads with public endpoints",46,"public-endpoints","public-endpoints.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fpublic-endpoints",{"title":296,"order":297,"time":56,"path":298,"id":299,"link":300},"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":302,"order":303,"time":33,"path":304,"id":305,"link":306},"Security governance controls",48,"governance-controls","governance-controls.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fgovernance-controls",{"title":132,"order":308,"time":56,"path":309,"id":310,"link":311},49,"security-ops-faq","security-ops-faq.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fsecurity-ops-faq",{"title":313,"collapsible":12,"isCollapsed":12,"content":314},"Debugging",[315,320,326,332,338,345,352,358,364,370,376],{"title":313,"order":316,"time":26,"path":317,"id":318,"link":319},50,"debugging-ops","debugging-ops.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fdebugging-ops",{"title":321,"order":322,"time":33,"path":323,"id":324,"link":325},"Standardizing a debugging approach",51,"debugging-approach","debugging-approach.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fdebugging-approach",{"title":327,"order":328,"time":56,"path":329,"id":330,"link":331},"General types of error",52,"general-types","general-types.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fgeneral-types",{"title":333,"order":334,"time":17,"path":335,"id":336,"link":337},"Troubleshooting payloads",53,"payload","payload.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Faws-lambda-operator-guide\u002Fpayload",{"title":339,"order":340,"time":341,"path":342,"id":343,"link":344},"Troubleshooting integration errors",54,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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":56,"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",1792578870420]