re:Invent 2025 - Debug Lambda functions deployed in cloud like never before

If you have ever spent 20 to 30 minutes tracking down a single bug in a Lambda function, you know how much that disrupts your development flow. Shridhar Pandey, Principal Product Manager for AWS Serverless Developer Experience, and Harold Sun, Senior Software Developer for AWS Serverless Developer Experience, presented session CNS367 at AWS re:Invent 2025 to address this problem directly. In this post, we'll walk through the three new capabilities they introduced, the real-world problems each one solves, and how to combine them for faster serverless development.

The session frames serverless development around two interconnected loops. The inner loop is where you spend most of your time: write code, test locally, debug, and repeat. The outer loop covers CI/CD (Continuous Integration/Continuous Delivery) pipelines, staging deployments, and production observability. The goal of all three new features is to accelerate the inner loop without sacrificing the production fidelity you need when debugging real issues.

Eliminating friction at every stage

The first pain point the team tackled is setup. Getting a local development environment ready for Lambda has historically taken 30 to 40 minutes. You need to install the right tools, copy function code, configure credentials, and wire up dependencies, and that cost repeats every time you start a new project or onboard a new team member.

The new console-to-IDE transition collapses that setup time to under 30 seconds. From the AWS Lambda console, a single click transfers your function's code and configuration directly to VS Code on your local machine. From there, you can use familiar package managers like npm and pip, add linters and formatters, and make code changes that sync back to the cloud automatically. For teams already using AWS SAM (Serverless Application Model), the integration fits naturally into existing workflows.

The second pain point is testing multi-service workflows locally. A typical serverless application might chain together Amazon SQS (Simple Queue Service), Lambda, Amazon DynamoDB, Amazon EventBridge, and Amazon SNS (Simple Notification Service). Testing that full chain locally requires correctly configured Identity and Access Management (IAM) roles, integration logic, and coordination across services. Most developers skip local testing entirely and deploy to the cloud just to validate each change, which introduces a 10 to 15 minute iteration cycle per change.

The new LocalStack integration in VS Code solves this by bringing a local cloud emulator directly into your IDE. With one click, you get access to emulated AWS services. You run sam build and sam deploy against your local stack profile instead of the cloud. The result is 75 to 80% faster local testing iterations. You can discover integration issues early in the development cycle, before any cloud deployment is needed.

Remote debugging for cloud-deployed functions

The third pain point is the class of bugs that only appear in the cloud. Virtual Private Cloud (VPC) configurations, IAM permission chains, service-specific throttling, and endpoint connectivity are difficult or impossible to replicate locally. Tracking down one of these bugs with traditional approaches means adding log statements, deploying, sending a test request, reviewing logs, and repeating the entire process. That cycle takes 20 to 30 minutes per bug.

Remote debugging addresses this directly. It lets you debug a Lambda function running in your AWS account directly from VS Code on your local machine, with full breakpoint support, step-through execution, and variable inspection. The AWS Toolkit for VS Code establishes a secure tunnel to AWS IoT Secure Tunneling. A Lambda layer is automatically attached to your function during the debugging session, intercepting invocations and connecting back through the tunnel to your local debugger. From your perspective, you set breakpoints and step through execution as you would with local code, while the function runs against real services, real VPC configurations, and real IAM roles.

The session demonstrated this with two examples. In the first, an API Gateway and Lambda authentication function was failing for all users. Remote debugging immediately exposed the cause: the request payload used an underscore in the field name (user_info) but the function code expected no underscore (userinfo). The fix took a few minutes, a task that would have required multiple log-and-deploy cycles without remote debugging.

The second example was more involved. An order processing application worked correctly in us-east-1 but failed after deployment to eu-west-1. The application used AWS Systems Manager Parameter Store to store payment API configuration, and the Lambda function ran inside a private VPC subnet with a VPC endpoint to reach Parameter Store. Setting a breakpoint and stepping through the code revealed that execution stalled at the Parameter Store read. Checking the VPC endpoint's security group inbound rules showed that the allowed CIDR range matched the us-east-1 Lambda VPC (10.10.x.x) but not the eu-west-1 Lambda VPC (10.2.x.x). The security group rule had not been updated during the eu-west-1 deployment. Fixing the CIDR range resolved the issue. That kind of investigation, spanning VPC configuration, security groups, and service connectivity, would have required considerably more time with log-based debugging alone. Overall, remote debugging reduces debugging time by 80 to 85%, bringing the average from 20 to 30 minutes per bug down to 3 to 5 minutes.

Best practices and security considerations

The team shared a clear recommendation: use remote debugging in development and testing environments, not in production. You can enforce this with an IAM policy that blocks the Lambda debugging APIs in your production account, or apply the restriction at the organizational level using AWS Organizations SCPs (Service Control Policies). For production accounts, you can also restrict function update permissions so only CI/CD roles can modify deployed functions.

When you start a remote debugging session, the AWS Toolkit attaches a layer, extends the function timeout to 15 minutes, and publishes a temporary function version. This design protects live traffic from being affected by the debug session. For functions configured with Lambda SnapStart or Provisioned Concurrency, publishing a version adds one to two minutes of setup time. If you are working in an isolated environment where you control all incoming traffic, you can disable the "publish version" option to skip that step and start debugging faster.

For end-to-end testing with real event sources, you can configure remote debugging to intercept events from sources like SQS directly. If your queue targets the function's latest version and you have disabled version publishing, sending a message to the queue will trigger the function and stop at your breakpoint as expected.

The team also recommends pairing remote debugging with SAM sync, which watches your local code for changes, compiles, and syncs updates to the cloud continuously. This way, you can apply a fix found during a debug session and immediately start a new session against the updated code without a manual deploy step.

Summary

These three capabilities work together to address the most time-consuming parts of the serverless development cycle. Console-to-IDE transition reduces environment setup from 30 to 40 minutes to under 30 seconds. LocalStack integration delivers 75 to 80% faster local testing iterations. Remote debugging cuts cloud debugging time by 80 to 85%. Combined, the team reports a 40% overall acceleration in development cycles.

To get started, open a function in the Lambda console and click "Open in VS Code." The AWS Toolkit handles the rest. The Lambda team has also published their roadmap on GitHub, where you can track upcoming features and submit feedback on what you would like to see built next.

Watch the full session: CNS367 - Debug Lambda functions deployed in cloud like never before