VSCode本地调试Serverless Lambda函数：指定输入与SSM密钥问题

Hey Greg, great job getting Lambda offline debugging up and running with SAM CLI, Docker, and VS Code—breakpoints and step-through debugging are total game-changers! Let’s work through your two questions one by one:

1. Fixing Empty Payload in Local Debugging #

It’s super frustrating when your test payload doesn’t show up in the function—here are the most common fixes to try:

• Validate your VS Code launch.json format
  Make sure your payload field matches the event source your Lambda expects. For a basic Lambda event (not tied to API Gateway), use a plain JSON object directly. If simulating an API Gateway request, you need to wrap your data in the full API Gateway event structure.
  Example of a basic payload in launch.json:

  "configurations": [
    {
      "type": "aws-sam",
      "request": "direct-invoke",
      "name": "Local Debug Lambda",
      "invokeTarget": {
        "target": "function:MyLambdaFunction"
      },
      "lambda": {
        "payload": {
          "user_id": "123",
          "action": "update_profile"
        },
        "environmentVariables": {}
      }
    }
  ]
  

  If you prefer using a separate event file, reference it with a path instead:

  "payload": "${workspaceFolder}/events/test-payload.json"
  

• Double-check your handler function’s parameter
  Confirm your code is accessing the right input parameter: in Python, it’s def handler(event, context): (use the event object), and in Node.js, it’s exports.handler = async (event) => { ... }. Typos here can easily make it look like the payload is empty.

• Test with SAM CLI directly first
  Rule out VS Code config issues by invoking the function from your terminal:

  sam local invoke MyLambdaFunction --event events/test-payload.json
  

  If this works, the problem is likely in your VS Code launch setup. If it doesn’t, check your template.yaml to ensure the function is defined correctly, and any event sources are configured properly.

2. Accessing SSM Parameters During Local Debugging #

By default, your locally running Lambda won’t automatically access SSM parameters stored in AWS—but setting this up is straightforward:

• Local AWS credentials are required
  The Docker container running your Lambda uses your machine’s AWS CLI credentials (from ~/.aws/credentials or environment variables) to make AWS API calls. Make sure your IAM user/role has the right permissions:

  • Add a policy that includes ssm:GetParameter (or ssm:GetParameters for multiple parameters)
  • If the parameter is a SecureString, you’ll also need kms:Decrypt permissions for the KMS key used to encrypt it.

• No extra SAM CLI configuration needed
  As long as your local credentials have the correct permissions, your Lambda code can call the SSM SDK just like it would in production. For example, in Python:

  import boto3
  
  def handler(event, context):
      ssm = boto3.client('ssm')
      response = ssm.get_parameter(Name='/my/app/secret-key', WithDecryption=True)
      secret_value = response['Parameter']['Value']
      # Use the secret value in your function
  

  The local container will use your credentials to fetch the parameter from AWS’s SSM service—no need for mocking unless you want to avoid hitting AWS during testing.

• Optional: Mock parameters for offline testing
  If you don’t want to call AWS during debugging, set temporary environment variables in your launch.json or template.yaml to override the SSM parameter value.

Hope these solutions get you sorted out! Let me know if you hit any snags along the way.

内容的提问来源于stack exchange，提问作者Greg Cawthorne