- Newest
- Most votes
- Most comments
Yes, stage variables are not supported in Lambda authorizer ARNs for cross-account configurations. This is a known API Gateway limitation.
Stage variables in Lambda URIs are resolved at runtime, but API Gateway validates the cross-account Lambda authorizer ARN at configuration time — before stage variables can be substituted. This is why you see "Invalid function ARN or Invalid uri" specifically in the cross-account scenario.
Workaround options:
Option 1: Use the full ARN directly
Hardcode the cross-account Lambda ARN in the authorizer configuration instead of using a stage variable:
arn:aws:lambda:us-east-1:ACCOUNT_ID:function:my-authorizer-function
Option 2: Use aliases instead of stage variables
If you need to point different stages at different versions of the authorizer, use Lambda aliases (e.g. dev, prod) and hardcode the alias ARN:
arn:aws:lambda:us-east-1:ACCOUNT_ID:function:my-authorizer-function:prod
Option 3: Same-account wrapper Lambda
Deploy a thin Lambda in the same account as API Gateway that proxies the authorization call to the cross-account function. This keeps the authorizer same-account (stage variables work) while the actual logic lives cross-account.
Also ensure the cross-account Lambda has a resource-based policy granting lambda:InvokeFunction to the API Gateway principal from the source account.
Relevant content
- asked 3 years ago
Really appreciate the quick response and the workaround proposals are also helpful. But in option 2, I still need stage variable in ARN right? Otherwise I need to change the ARN then deploy to different stages instead of pointing to different functions dynamically.
You're correct — Option 2 only works if you're willing to configure each stage with its own hardcoded alias ARN as a static value, not dynamically. So stage
devwould have its authorizer pointing tofunction:dev-aliasand stageprodpointing tofunction:prod-alias— each configured separately, no stage variable involved. It removes the stage variable requirement but adds manual per-stage configuration.If you need truly dynamic routing across stages without reconfiguring per stage, Option 3 (same-account wrapper Lambda) is the only clean path. The wrapper Lambda in the same account can read the target cross-account ARN from an environment variable or SSM Parameter Store, keyed by stage context passed in the request. This gives you the dynamic behavior stage variables would have provided, while keeping the authorizer itself same-account where stage variables work normally.
Many thanks again, I'll consider option 3 because it's most close to what I want. I really hope AWS can support this use case, they can just delay the ARN validation until runtime when in a cross account case then there will be more flexible.