Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Unable to find IntegrationTarget when using VPC Link V2 Proxy integration

1

Hi, we are testing a possible migration from the old-gen architecture with VPC Link v1 and api gateway REST VPC proxy integration to the new VPC Link V2.

We have multiple elastic beanstalk environments all in private subnets and we use the API gateway to have a common url to contact all of them (one having the /develop suffix, another /staging suffix, and so on). All behind dedicated NLB internal facing in the same private subnets. We previously used one vpc link for each NLB with API gateway stage variables to assign vpcLinkId dinamically based on API gateway stages.

With VPC link v2 we are testing a clone of the elastic beanstalk environments with ALB, and we created, for testing, a vpc link v2 in the private subnets with the security group of the ALB. However, we get as error: "integration Execution failed due to configuration error: Unable to find IntegrationTarget".

We tried to specify the ALB in the targetIntegration field and in that case it works correctly. But this solution is not suitable for us as we want a dedicated ALB for each elastic beanstalk environment.

A solution would be to specify the integration target as a new stage variable, but in that case we get: "${stageVariables.albArn} is not a valid ALB or NLB arn"

Is this a limitation of the current implementation of the VPC link v2 or we are missing something?

Thanks

EDIT: in other AWS account the "same" configuration works correctly. The difference could be that in this account there are multiple NLB / ALB, while in the other account there is just a single ALB?

Topics
ServerlessFront-End Web & MobileComputeNetworking & Content Delivery
Tags
Amazon VPCAmazon API GatewayAWS Elastic Beanstalk
Language
English
asked 12 days ago62 views
2 Answers
2

Confirming the agent's answer: HTTP APIs (VPC Link V2) strictly validate the ARN format at configuration time, which blocks runtime resolution via stage variables.

Since you explicitly require dedicated ALBs per environment, the single-ALB workaround is not an option for you.

The cleanest way to solve this is shifting the environment isolation from API Gateway stages to Infrastructure as Code (IaC):

  • Separate APIs per Environment: Use Terraform or AWS CDK to deploy an entirely independent API Gateway instance for each stage (develop, staging, etc.).
  • Setup: Your IaC pipeline passes the specific ALB listener ARN as a static input parameter directly into that environment's API definition.
  • Benefit: This avoids bloated routing configurations and isolates your blast radius - a deployment mistake in develop cannot affect your staging or production API Gateway.
EXPERT
answered 12 days ago
  • Marco
    12 days ago

    Thanks for the answer. However, VPC Link V2 should support both REST APIs and HTTP APIs? Also to be noted, in another AWS account this is working correctly.

  • Florian Turnwald EXPERT
    12 days ago

    you are right: VPC Link V2 now supports both HTTP APIs and REST APIs (since the update in late 2025). However, the strict validation of the integrationTarget / integrationUri applies to both API types. API Gateway requires a hardcoded, valid ARN at configuration time and will reject stage variables (like ${stageVariables.albArn}) for this specific field. Regarding the other account: Your EDIT identifies the reason. If there is only a single ALB in the other account, you aren't forced to dynamically swap the ALB ARN per environment. The ARN is likely hardcoded in the integration, and the single ALB might be using path-based routing to distribute traffic to the different Elastic Beanstalk environments. But since your strict requirement in this account is to route to dedicated ALBs per environment, you hit the stage variable limitation. That's why shifting the isolation to IaC (deploying a separate API Gateway per environment and injecting the specific ALB ARN during deployment) remains the most robust solution to achieve what you want.

  • Marco
    11 days ago

    In the other account the ALB is not hardcoded in the integration, that's the problem. The API gateway seems to use it anyway, while in the main account where there are multiple NLB / ALB we get "Unable to find IntegrationTarget" error

0

Based on the VPC Link V2 implementation, the integrationTarget property is specifically designed to specify the ALB or NLB listener ARN for private integrations. However, this property does not support stage variables in the same way that VPC Link V1 allowed for dynamic vpcLinkId assignment.

When creating a private integration with VPC Link V2, you need to explicitly provide the listener ARN of your load balancer in the integration configuration. The error you're encountering - "Unable to find IntegrationTarget" - occurs when the integration cannot locate the specified target resource.

The current implementation requires you to specify the actual ARN of the load balancer listener rather than using a stage variable reference. This means that for your use case with multiple Elastic Beanstalk environments (develop, staging, etc.), each with its own dedicated ALB, you would need to create separate integrations for each environment rather than using a single integration with dynamic stage variable substitution.

This represents a change in approach from VPC Link V1. With VPC Link V2, the architecture is designed around having the VPC link connect to multiple load balancers within the same VPC, but the specific target (ALB/NLB listener ARN) must be defined at the integration level rather than being dynamically resolved through stage variables.

To accommodate your multi-environment setup with VPC Link V2, you would need to either:

  1. Create separate API Gateway resources/routes for each environment with their respective ALB listener ARNs hardcoded in the integration
  2. Use separate APIs for each environment
  3. Consider restructuring your architecture to use a single ALB with path-based routing to different target groups

This is a limitation of how VPC Link V2 currently handles the integrationTarget parameter and its interaction with stage variables.
Sources
x-amazon-apigateway-integration object - Amazon API Gateway
Set up a private integration - Amazon API Gateway
Create private integrations for HTTP APIs in API Gateway - Amazon API Gateway

answered 12 days ago
EXPERT
reviewed 12 days ago
  • Marco
    12 days ago

    Added information about another account where the "same" configuration seems to be working.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content