AWS lambda documentation change
Summary
Editorial improvements including rephrasing for clarity, consistency in terminology (e.g., 'SQS queue' to 'Amazon SQS queue'), added links to durable functions documentation, and minor grammatical corrections. No functional changes to Lambda behavior.
Security assessment
Changes are purely editorial with no references to security vulnerabilities, patches, or security configurations. The diff shows no evidence of addressing security weaknesses (e.g., no mentions of authentication, permissions, or vulnerabilities). Updates like 'might' replacing 'may' or adding internal links don't impact security.
Diff
diff --git a/lambda/latest/dg/concepts-event-driven-architectures.md b/lambda/latest/dg/concepts-event-driven-architectures.md index 766e62ab8..7e72409b0 100644 --- a//lambda/latest/dg/concepts-event-driven-architectures.md +++ b//lambda/latest/dg/concepts-event-driven-architectures.md @@ -9 +9 @@ Benefits of event-driven architecturesTrade-offs of event-driven architecturesAn -An event is anything that triggers a Lambda function to run. There are two fundamental ways that events can trigger Lambda: through direct invocation (push) and event source mappings (pull). +An event is anything that triggers a Lambda function to run. Events can trigger a Lambda function in two ways: through direct invocation (push) and event source mappings (pull). @@ -11 +11 @@ An event is anything that triggers a Lambda function to run. There are two funda -Many AWS services can directly invoke your Lambda functions. These services _push_ events to your Lambda function. Events that trigger a function can be almost anything, from an HTTP request through API Gateway, a schedule managed by an EventBridge rule, an AWS IoT event, or an Amazon S3 event. With event source mapping, Lambda actively fetches (or _pulls_) events from a queue or stream. You configure Lambda to check for events from a supported service, and Lambda handles the polling and invocation of your function. +Many AWS services can directly invoke your Lambda functions. These services _push_ events to your Lambda function. Events that trigger functions can be almost anything, from an HTTP request through API Gateway, a schedule managed by an EventBridge rule, an AWS IoT event, or an Amazon S3 event. With event source mapping, Lambda actively fetches (or _pulls_) events from a queue or stream. You configure Lambda to check for events from a supported service, and Lambda handles the polling and invocation of your function. @@ -13 +13 @@ Many AWS services can directly invoke your Lambda functions. These services _pus -When passed to your function, events are structured in JSON format. The JSON structure varies depending on the service that generates it and the event type. While standard Lambda function invocations can last up to 15 minutes (or up to one year with Durable Functions), Lambda is best-suited for short invocations that last one second or less. This is particularly true of event-driven architectures, where each Lambda function is treated as a microservice responsible for performing a narrow set of specific instructions. +When passed to your function, events are structured in JSON format. The JSON structure varies depending on the service that generates it and the event type. While standard Lambda function invocations can last up to 15 minutes (or up to one year with [durable functions](./durable-functions.html)), Lambda is best-suited for short invocations that last one second or less. This is particularly true of event-driven architectures, where each Lambda function is treated as a microservice responsible for performing a narrow set of specific instructions. @@ -17 +17 @@ When passed to your function, events are structured in JSON format. The JSON str -Event-driven architectures communicate across different systems using networks, which introduce variable latency. For workloads that require very low latency, such as real-time trading systems, this design may not be the best choice. However, for highly scalable and available workloads, or those with unpredictable traffic patterns, event-driven architectures can provide an effective way to meet these demands. +Event-driven architectures communicate across different systems using networks, which introduce variable latency. For workloads that require very low latency, such as real-time trading systems, this design might not be the best choice. However, for highly scalable and available workloads, or those with unpredictable traffic patterns, event-driven architectures can provide an effective way to meet these demands. @@ -53 +53 @@ Both methods contribute to the benefits of event-driven architectures, as descri -Many traditional architectures use polling and webhook mechanisms to communicate state between different components. Polling can be highly inefficient for fetching updates since there is a lag between new data becoming available and synchronization with downstream services. Webhooks are not always supported by other microservices that you want to integrate with. They may also require custom authorization and authentication configurations. In both cases, these integration methods are challenging to scale on-demand without additional work by development teams. +Many traditional architectures use polling and webhook mechanisms to communicate state between different components. Polling can be highly inefficient for fetching updates since there is a lag between new data becoming available and synchronization with downstream services. Webhooks are not always supported by other microservices that you want to integrate with. They might also require custom authorization and authentication configurations. In both cases, these integration methods are challenging to scale on-demand without additional work by development teams. @@ -65 +65 @@ Event-driven architectures can also make it easier to design near-real-time syst -Microservices enable developers and architects to decompose complex workflows. For example, an ecommerce monolith may be broken down into order acceptance and payment processes with separate inventory, fulfillment and accounting services. What may be complex to manage and orchestrate in a monolith becomes a series of decoupled services that communicate asynchronously with events. +Microservices enable developers and architects to simplify complex workflows. For example, an ecommerce monolith can be broken down into order acceptance and payment processes with separate inventory, fulfillment and accounting services. What might be complex to manage and orchestrate in a monolith becomes a series of decoupled services that communicate asynchronously with events. @@ -69 +69 @@ Microservices enable developers and architects to decompose complex workflows. F -This approach also makes it possible to assemble services that process data at different rates. In this case, an order acceptance microservice can store high volumes of incoming orders by buffering the messages in an SQS queue. +This approach also makes it possible to assemble services that process data at different rates. In this case, an order acceptance microservice can store high volumes of incoming orders by buffering the messages in an Amazon SQS queue. @@ -71 +71 @@ This approach also makes it possible to assemble services that process data at d -A payment processing service, which is typically slower due to the complexity of handling payments, can take a steady stream of messages from the SQS queue. It can orchestrate complex retry and error handling logic using AWS Step Functions, and coordinate active payment workflows for hundreds of thousands of orders. +A payment processing service, which is typically slower due to the complexity of handling payments, can take a steady stream of messages from the Amazon SQS queue. It can orchestrate complex retry and error handling logic using AWS Step Functions, and coordinate active payment workflows for hundreds of thousands of orders. @@ -83 +83 @@ This system is also highly extensible, allowing other teams to extend features a -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. +Unlike monolithic applications, which might 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. @@ -118 +118 @@ Finally, it’s highly recommended to automate the parsing and analysis of logs -When building event-driven architectures with Lambda, be careful of anti-patterns that are technically functional, but may be suboptimal from an architecture and cost perspective. This section provides general guidance about these anti-patterns, but is not prescriptive. +When building event-driven architectures with Lambda, avoid the following common anti-patterns. These patterns work but can increase costs and complexity. @@ -128 +128 @@ This approach has several drawbacks: - * **Package size** – The Lambda function may be much larger because it contains all possible code for all paths, which makes it slower for the Lambda service to run. + * **Package size** – The Lambda function might be much larger because it contains all possible code for all paths, which makes it slower for the Lambda service to run. @@ -143 +143 @@ This approach has several drawbacks: -The preferred alternative is to decompose the monolithic Lambda function into individual microservices, mapping a single Lambda function to a single, well-defined task. In this simple web application with a few API endpoints, the resulting microservice-based architecture can be based upon the API Gateway routes. +The preferred alternative is to break down the monolithic Lambda function into individual microservices, mapping a single Lambda function to a single, well-defined task. In this simple web application with a few API endpoints, the resulting microservice-based architecture can be based upon the API Gateway routes. @@ -147 +147 @@ The preferred alternative is to decompose the monolithic Lambda function into in -### Recursive patterns that cause run-away Lambda functions +### Recursive patterns that cause runaway Lambda functions @@ -155 +155 @@ For example, a Lambda function writes an object to an Amazon S3 object, which in -While the potential for infinite loops exists in most programming languages, this anti-pattern has the potential to consume more resources in serverless applications. Both Lambda and Amazon S3 automatically scale based upon traffic, so the loop may cause Lambda to scale to consume all available concurrency and Amazon S3 will continue to write objects and generate more events for Lambda. +While the potential for infinite loops exists in most programming languages, this anti-pattern has the potential to consume more resources in serverless applications. Both Lambda and Amazon S3 automatically scale based upon traffic, so the loop can cause Lambda to scale to consume all available concurrency and Amazon S3 will continue to write objects and generate more events for Lambda. @@ -165 +165 @@ Functions enable encapsulation and code re-use. Most programming languages suppo -While Lambda functions directly calling other Lambda functions is generally an anti-pattern due to cost and complexity concerns, this doesn't apply to Durable Functions where this pattern is supported and cost-optimized due to the built-in state management. +While Lambda functions directly calling other Lambda functions is generally an anti-pattern due to cost and complexity concerns, this doesn't apply to [durable functions](./durable-functions.html), which are specifically designed to orchestrate multi-step workflows by invoking other functions. @@ -173 +173 @@ This model often does not adapt well to serverless development. For example, con -In this case, the _Create order_ function calls the _Process payment_ function, which in turn calls the _Create invoice_ function. While this synchronous flow may work within a single application on a server, it introduces several avoidable problems in a distributed serverless architecture: +In this case, the _Create order_ function calls the _Process payment_ function, which in turn calls the _Create invoice_ function. While this synchronous flow might work within a single application on a server, it introduces several avoidable problems in a distributed serverless architecture: @@ -177 +177 @@ In this case, the _Create order_ function calls the _Process payment_ function, - * **Error handling** – In nested invocations, error handling can become much more complex. For example, an error in _Create invoice_ might require the _Process payment_ function to reverse the charge, or it may instead retry the _Create invoice_ process. + * **Error handling** – In nested invocations, error handling can become much more complex. For example, an error in _Create invoice_ might require the _Process payment_ function to reverse the charge, or it might instead retry the _Create invoice_ process. @@ -186 +186 @@ In this case, the _Create order_ function calls the _Process payment_ function, -In serverless applications, there are two common approaches to avoid this pattern. First, use an Amazon SQS queue between Lambda functions. If a downstream process is slower than an upstream process, the queue durably persists messages and decouples the two functions. In this example, the _Create order_ function would publish a message to an SQS queue, and the _Process payment_ function consumes messages from the queue. +In serverless applications, there are two common approaches to avoid this pattern. First, use an Amazon SQS queue between Lambda functions. If a downstream process is slower than an upstream process, the queue durably persists messages and decouples the two functions. In this example, the _Create order_ function would publish a message to an Amazon SQS queue, and the _Process payment_ function consumes messages from the queue. @@ -192 +192 @@ The second approach is to use AWS Step Functions. For complex processes with mul -Within a single Lambda, ensure that any potentially concurrent activities are not scheduled synchronously. For example, a Lambda function might write to an S3 bucket and then write to a DynamoDB table: +Make sure that any potentially concurrent activities are not scheduled synchronously within a single Lambda function. For example, a Lambda function might write to an S3 bucket and then write to a DynamoDB table: