Howdy. I'm having an issue specifying an authorize...
# general
Howdy. I'm having an issue specifying an authorizer for an
. If I pass in
authorization: 'NONE'
to the constructor, everything works fine. If I pass
authorization: 'COGNITO_USER_POOLS'
(where authorizer is a successfully created
), then I receive this error: "NotFoundException: Invalid parameter name specified".
Two pieces of data make me wonder if this is a pulumi issue: 1.) The error is "Invalid parameter name", and 2.) all other
properties are named identically to AWS SDK equivalents, but it looks like pulumi's
maps to AWS SDK's
User error is always a possibility, but one thing I've done to double check that I'm doing things correctly is as follows. I can successfully configure the authorizer for the method manually in the AWS Console. Using the AWS CLI to look at the method's JSON before and after the manual config change, the only differences are the change in
and the presence of
authorizerId: 'xxx123'
. This leads me to think that I am assigning the necessary properties to the
Robert, first, sorry for the delay!
Do you have a complete repro program? If not, no worries, I'm trying to construct one right now.
Thanks for looking into it, Joe. The code with which I discovered this issue is too big and gnarly to share. Any luck reproducing the problem yourself? Otherwise I can make an isolated test program, which is the next thing I should try anyway. Let me know.
@modern-diamond-82589 i tried to repro this myself as well - but can't seem to hit the error you mention. Here's the code I tried that reproduces as much of what you describe above as I can gather - anything else you could suggest trying to better match your code?
Copy code
import * as aws from "@pulumi/aws";

const pool = new aws.cognito.UserPool("pool");
const api = new aws.apigateway.RestApi("api");
const auth = new aws.apigateway.Authorizer("auth", {
    restApi: api,
    providerArns: [pool.arn],
const res = new aws.apigateway.Resource("res", {
    restApi: api,
    parentId: api.rootResourceId,
    pathPart: "{proxy+}",
const method = new aws.apigateway.Method("meth", {
    restApi: api,
    httpMethod: "ANY",
    authorization: "COGNITO_USER_POOLS",    
I am appreciative of both of your efforts. I don't have a repro program for you yet, but here's a new piece of info: If I apply an authorizer to a Method on an unparameterized path (like
POST /foo
), it works fine. But If I try to add an authorizer to a Method of a parameterized path (like
GET /foo/{bar}
), it fails with the aforementioned "NotFoundException: Invalid parameter name specified". So the error message is pertaining to the path parameter, not the
property I previously suspected, which means I'm dealing with API Gateway configuration issues, not a pulumi problem per se. I am perplexed, though, as I'm defining path parameters as I believe I should by setting
Method.requestParameters:  {"":true}
Integration.requestParameters: {"":""}
. I'm also experiencing the issue without an authorizer if I try to define a method with multiple path parameters (like
GET /foo/{bar}/baz/{qux}
). Although this is no longer your problem, if you have any insight I'd be grateful.
Interesting - good to hear this doesn't seem to be a Pulumi issue - I tried a couple more things but wasn't able to recreate, so sounds like there's some other element here that I'm not capturing. Certainly the API Gateway API is somewhat arcane - I've spent more hours than I'd like to admit fighting with it myself 🙂. In part, this is why we created
to make the common cases of using this manageable. Sounds like you are building things that are outside the current support that higher-level library provides - but once you have things working here, it would be interesting to think about what we could add in that helper library to make what you are doing easier for users who have similar needs in the future.
One last update. The error doesn't occur when creating a new Method with an authorizer. But it does occur when attempting to update an existing Method with an authorizer when the Method didn't have one previously. I suspect the same is true of adding path parameters to an existing Method. So my incremental approach shot me in the foot on this particular aspect.