AWS Security ChangesHomeSearch

AWS lambda documentation change

Service: lambda · 2025-10-16 · Documentation low

File: lambda/latest/dg/golang-handler.md

Summary

Reformatted best practices section by removing nested bullet points and converting them to standalone bolded recommendations. Content remains largely unchanged but restructured for clarity.

Security assessment

The changes are structural/formatting adjustments rather than substantive security updates. While some recommendations (e.g., avoiding recursive invocations, not using non-public APIs) have security implications, these were already present in the documentation. The diff does not introduce new security guidance or address a specific vulnerability.

Diff

diff --git a/lambda/latest/dg/golang-handler.md b/lambda/latest/dg/golang-handler.md
index 983d53d8c..86c3f6e30 100644
--- a//lambda/latest/dg/golang-handler.md
+++ b//lambda/latest/dg/golang-handler.md
@@ -352 +352 @@ Adhere to the guidelines in the following list to use best coding practices when
-  * **Take advantage of execution environment reuse to improve the performance of your function.** Initialize SDK clients and database connections outside of the function handler, and cache static assets locally in the `/tmp` directory. Subsequent invocations processed by the same instance of your function can reuse these resources. This saves cost by reducing function run time.
+**Take advantage of execution environment reuse to improve the performance of your function.** Initialize SDK clients and database connections outside of the function handler, and cache static assets locally in the `/tmp` directory. Subsequent invocations processed by the same instance of your function can reuse these resources. This saves cost by reducing function run time.
@@ -356 +356 @@ To avoid potential data leaks across invocations, don’t use the execution envi
-  * **Use a keep-alive directive to maintain persistent connections.** Lambda purges idle connections over time. Attempting to reuse an idle connection when invoking a function will result in a connection error. To maintain your persistent connection, use the keep-alive directive associated with your runtime. For an example, see [Reusing Connections with Keep-Alive in Node.js](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html).
+**Use a keep-alive directive to maintain persistent connections.** Lambda purges idle connections over time. Attempting to reuse an idle connection when invoking a function will result in a connection error. To maintain your persistent connection, use the keep-alive directive associated with your runtime. For an example, see [Reusing Connections with Keep-Alive in Node.js](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html).
@@ -358,7 +358 @@ To avoid potential data leaks across invocations, don’t use the execution envi
-  * **Use[environment variables](./configuration-envvars.html) to pass operational parameters to your function.** For example, if you are writing to an Amazon S3 bucket, instead of hard-coding the bucket name you are writing to, configure the bucket name as an environment variable.
-
-  * **Avoid using recursive invocations** in your Lambda function, where the function invokes itself or initiates a process that may invoke the function again. This could lead to unintended volume of function invocations and escalated costs. If you see an unintended volume of invocations, set the function reserved concurrency to `0` immediately to throttle all invocations to the function, while you update the code.
-
-  * **Do not use non-documented, non-public APIs** in your Lambda function code. For AWS Lambda managed runtimes, Lambda periodically applies security and functional updates to Lambda's internal APIs. These internal API updates may be backwards-incompatible, leading to unintended consequences such as invocation failures if your function has a dependency on these non-public APIs. See [the API reference](https://docs.aws.amazon.com/lambda/latest/api/welcome.html) for a list of publicly available APIs.
-
-  * **Write idempotent code.** Writing idempotent code for your functions ensures that duplicate events are handled the same way. Your code should properly validate events and gracefully handle duplicate events. For more information, see [How do I make my Lambda function idempotent?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/).
+**Use[environment variables](./configuration-envvars.html) to pass operational parameters to your function.** For example, if you are writing to an Amazon S3 bucket, instead of hard-coding the bucket name you are writing to, configure the bucket name as an environment variable.
@@ -365,0 +360 @@ To avoid potential data leaks across invocations, don’t use the execution envi
+**Avoid using recursive invocations** in your Lambda function, where the function invokes itself or initiates a process that may invoke the function again. This could lead to unintended volume of function invocations and escalated costs. If you see an unintended volume of invocations, set the function reserved concurrency to `0` immediately to throttle all invocations to the function, while you update the code.
@@ -366,0 +362 @@ To avoid potential data leaks across invocations, don’t use the execution envi
+**Do not use non-documented, non-public APIs** in your Lambda function code. For AWS Lambda managed runtimes, Lambda periodically applies security and functional updates to Lambda's internal APIs. These internal API updates may be backwards-incompatible, leading to unintended consequences such as invocation failures if your function has a dependency on these non-public APIs. See [the API reference](https://docs.aws.amazon.com/lambda/latest/api/welcome.html) for a list of publicly available APIs.
@@ -367,0 +364 @@ To avoid potential data leaks across invocations, don’t use the execution envi
+**Write idempotent code.** Writing idempotent code for your functions ensures that duplicate events are handled the same way. Your code should properly validate events and gracefully handle duplicate events. For more information, see [How do I make my Lambda function idempotent?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/).