使用Lambda Destinations时是否需配置私有链接？同VPC调用异常咨询

Got it, let’s work through your Lambda Destinations issue together. First, let’s clear up whether you need VPC endpoints (private links) for your two scenarios, then dive into the most likely reasons Lambda B isn’t triggering in Scenario 1.

Do You Need Private Links (VPC Endpoints)? #

Let’s break this down per scenario:

Scenario 1: Both Lambdas in the Same VPC Subnet #

• For SQS (failure destination): The fact that Lambda A doesn’t time out calling SQS means you’ve got this covered—either you have a valid SQS VPC endpoint (com.amazonaws.<region>.sqs) set up, or your subnet has a NAT/internet gateway allowing outbound public access to SQS. No issues here.
• For Lambda B (success destination): You don’t need a Lambda VPC endpoint when invoking another Lambda in the same VPC. AWS handles internal service-to-service calls within the same VPC via private networking by default—no public internet required. So missing private links isn’t the problem here.

Scenario 2: Lambda B Not in a VPC #

• When a VPC-based Lambda (A) uses Destinations to invoke a non-VPC Lambda (B), you also don’t need a Lambda VPC endpoint. AWS’s internal network automatically handles the private invocation between the two, as long as Lambda A has the right permissions to call Lambda B.

Troubleshooting Why Lambda B Isn’t Triggered in Scenario 1 #

Since private links aren’t the culprit, let’s go through the most common fixes:

• Double-check Lambda A’s IAM Permissions
  Even with the destination configured, Lambda A’s execution role needs explicit lambda:InvokeFunction permission for Lambda B. Typos in the ARN are super common here, so verify your policy looks like this (fill in your region, account ID, and Lambda B name):

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": "lambda:InvokeFunction",
              "Resource": "arn:aws:lambda:<your-region>:<your-account-id>:function:<lambda-b-name>"
          }
      ]
  }
  

• Verify Lambda A’s Destination Configuration
  Pop into Lambda A’s console, head to Configuration > Destinations, and confirm:

  • The success destination is definitely pointing to Lambda B (no typos in the function name or ARN).
  • The destination is attached to the correct trigger (e.g., if you’re using async invocations, make sure it’s linked to the async event source, not a synchronous trigger).
  • The condition is set to On success for Lambda B (and On failure for SQS, which you know works).

• Check Lambda B’s CloudWatch Logs
  Even if Lambda A tries to invoke Lambda B, Lambda B might fail immediately—and that failure won’t show up in Lambda A’s logs. Jump into CloudWatch Logs for Lambda B and look for errors like missing permissions, runtime crashes, or dependency issues that stop it from running.

• Inspect Lambda A’s Async Metrics in CloudWatch
  Look at Lambda A’s metrics:

  • DestinationDeliveryFailures: If this number is going up, AWS couldn’t deliver the success event to Lambda B. This could be due to Lambda B being throttled, or a misconfiguration in the destination setup.
  • Invocations and Errors: Confirm Lambda A is actually succeeding (since the failure path to SQS works, but double-check anyway).

• Ensure Lambda B Is Active and Configured Correctly
  Quick sanity checks:

  • Is Lambda B disabled? Unlikely, but worth confirming.
  • Is its deployment package valid? Corrupted code or missing dependencies can cause invocations to fail silently.

Quick Recap #

For both your scenarios, you don’t need a Lambda VPC endpoint to use Destinations between Lambdas—whether they’re in the same VPC or one is outside. The issue in Scenario 1 is almost certainly a permission misstep, a typo in the destination setup, or a problem with Lambda B itself that’s preventing successful invocation.

内容的提问来源于stack exchange，提问作者Richard Chester