APIs created via APIG's REST API are slower than apis created in AWS Web Console (not an issue with this importer) about aws-apigateway-importer HOT 21 CLOSED

Hey Austen,

There should be no difference in performance between an API created using the client vs the console.

I just tried the 2 endpoints and got the same results from both. However, there's definitely a lot of variation in the latency and > 500ms is much higher than we would expect. Is the API under test making a cross region lambda call?

Have you been able to verify this yourself? Do you see the same pattern in other regions?

Do the integrations created using JAWS specify a role ARN for credentials or are they using resource-based permissions (no role specified)? The console uses resource-based permissions which is the biggest potential difference I can think of.

Sadly I will be in Seattle holding down the fort during Re:invent :)

Cheers,
Ryan

from aws-apigateway-importer.

I've reproduced the issue. I believe this is related to specifying credentials to invoke the lambda function. You can get around this by leaving the integration credentials out of swagger/client, and making a call using the lambda cli/api to add a permission for API Gateway to call the lambda function. We're looking into it.

from aws-apigateway-importer.

Ryan,

You rock for figuring this out. I'll implement the fix you suggested while you guys work on the core issue.

It's a shame you aren't going to re:invent. Seems odd since you're working on the "cool stuff". The Lambda team has been super helpful with JAWS. Steffano also has chimed in with some helpful input. But I'd still really enjoy a chat with you. After all of the re:invent craziness is over, I'll drop an issue in here to see if you you're available. Otherwise, you can reach me at austen [at] servant.co

Again, thanks for the great work Ryan :)

Take care,
Austen

from aws-apigateway-importer.

Ryan,

Shoot, another bug is blocking me from implementing your workaround. Details here.

Do you have any other suggestions?

Best regards,
Austen

from aws-apigateway-importer.

Answered in the forum. I don't think this is a bug, unless you can't stop the Node SDK from calling "get policy"

from aws-apigateway-importer.

You are the man Ryan. Seriously, thank you. I have been pouring my life into this JAWS project and as a consequence I get overly worried about issues like these.

Ok, so I can manually update the permissions now. My only worry now is that JAWS has to programmatically manage people's Lambda access policies. Using the credentials property is a lot cleaner. Hopefully you guys can squash that latency soon.

Thanks again Ryan :) You are doing really awesome work. I wouldn't have made it this far without you.

Cheers,
Austen

from aws-apigateway-importer.

No problem. This is the way the API Gateway console works too. It's a better workflow since the user doesn't have to worry about managing another IAM role/policy. As long as the credentials used to make the call to Lambda are the users own credentials, it shouldn't be a concern.

from aws-apigateway-importer.

Hi Austen,

We have a solution for the latency issue which should be deployed early next week.

In order to take advantage of this, you'll need to instruct your users to opt-in for regionalized STS for the region where their API is located. It's quick step in the IAM web console.

Instructions are here: http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html

from aws-apigateway-importer.

Ryan,

Since you have domain expertise in this, I'm wondering if you could recommend a single implementation that would help JAWS accomplish the following goals:

• User-friendliness: JAWS is mostly a usability layer on top of the groundbreaking stuff you're making.
• Best possible performance: What's going to offer the best response times for JAWS users? Will STS be faster than specifying lambda permissions?
• One size fits all: JAWS introduces the aws-module (AWSM) format for modularizing pre-written lambda code, but soon I also want to use aws-modules to modularize API Gateway configurations, which would include proxies to more resources than just lambda. My feeling is that STS may be the silver bullet that will allow aws-modules to include all types of APIG configurations. Is my thinking accurate?

I've already implemented the workaround you suggested to great success. Response times are down by ~300ms. But, I'm open to rewriting it if there is a better option. Just not sure what that is at the moment.

Thanks,
Austen

from aws-apigateway-importer.

For the first 2 points, when it comes to invoking lambda functions, resource-based permissions are definitely the way to go.

As you mentioned API Gateway can be used to proxy to most of the AWS services/operations and it would be awesome to have some canned configurations for popular use-cases. We have seen Kinesis and S3 come up a lot. Your thinking is accurate in that the key to handling all of these use-cases is the users IAM role with properly configured policy. STS is the mechanism we use internally to execute on behalf of the user.

Can you point me to the code where you're adding the lambda permissions?

from aws-apigateway-importer.

Ryan,

Between lines 829 - 963 is where the Lambda permissions are managed by JAWS. The flow is like this when the endpoint is being deployed and the lambda permissions are being managed:

• Fetch the Lambda's Access Policy (AP)
• Check if there is a statement in the AP with a statement ID of 'jaws-apigateway-access'
• If statement exists, remove it
• Add new statement to Lambda's AP with ID 'jaws-apigateway-access'

Sounds like there isn't a one-size-fits-all implementation, and perhaps the way to go is to mix them?

from aws-apigateway-importer.

Looks great! Yeah I think you may want to go with a combination unless you're ok with the tradeoffs of using STS with lambda invocations

from aws-apigateway-importer.

Ok thank you :)

Sorry to keep bugging you, but could you take a look at the statement I'm making to update Lambda's Access Policy. I'm getting reports that people are getting this error: "Execution failed due to configuration error: Invalid permissions on Lambda function."

The code that updates the policy is here

from aws-apigateway-importer.

The policy should look something like this:

...
"AWS:SourceArn":"arn:aws:execute-api:[REGION]:[ACCOUNT_ID]:[API_ID]/*/[HTTP_VERB]/[RESOURCE_PATH]"}},
"Action":"lambda:InvokeFunction",
"Resource":"arn:aws:lambda:[REGION]:[ACCOUNT_ID]:function:[FUNCTION_NAME]",
"Effect":"Allow",
"Principal":{"Service":"apigateway.amazonaws.com"}
...

from aws-apigateway-importer.

May be better to keep stage as a wildcard to keep the permissions stage-independent. Also test invokes from the console aren't tied to a stage.

from aws-apigateway-importer.

Ryan,

Thanks for your help. Everything is working well now and fast :)

I just did an impromptu talk on JAWS @ the AWS Pop-up Loft in SF w/ Tim Wagner and Simon. They said you were in town too. Too bad we didn't get to meet!

However, since you have been so awesome helping me out, I had already included your name in my JAWS slides a few days ago, in the "Special Thanks" section, which prompted a brief chat about you. Then I went and hyped you up further to Simon because you are that awesome.

Hopefully there is a raise coming your way soon 👍

Best,
Austen

from aws-apigateway-importer.

Awesome - I would have made an effort to get up there had I known! I heard the JAWS presentation went really well. Thanks for the shout out, always helps :)

from aws-apigateway-importer.

Closing this issue - please reopen if there's anything outstanding

from aws-apigateway-importer.

Hi Ryan,

Just checking in on this issue. Have you guys been able to remove the extra latency when specifying credentials, or should we continue adding the policy to the Lambda function?

I hope you are well. Happy holidays too!

Austen

from aws-apigateway-importer.

Hi Austen,

Happy holidays to you as well!

It will be impossible to remove all the latency when using STS credentials - however, if regional endpoints are enabled for STS, the latency difference should be very small. We have also implemented credential caching which will greatly improve performance for APIs receiving steady traffic. I wouldn't expect any significant average latency difference between role-based and resource-based at this point but I would encourage you to do some benchmarking. If you notice any big differences please let us know.

We are also looking into automating the addition of resource-based permissions to make setting up APIs with lambda functions/resource-based permissions easier.

Cheers,
Ryan

from aws-apigateway-importer.

Ryan,

All of this sounds great. Thank you for your hard work, as always.

Cheers,
Austen

from aws-apigateway-importer.