You bring up a good point with the FIPS vs non-FIPS endpoints. If it simplifies things, many of the common/relevant services only have one or the other (S3 and Lambda are notable exceptions). I think I would default to the FIPS endpoint, since it should only affect the TLS session between the client and AWS endpoint (so, the set of cipher suites is strict, and the modules used to implement those endpoints are validated).
@Hunger_Artist_twitter I got it almost done... can you please check just one more thing for me. Do you have access to this policy:
aws iam get-policy --policy-arn 'arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole'if not, if there an equivalent policy in your partition?
@gojko This is pretty interesting. Running the command aws iam get-policy --policy-arn 'arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole' returns:
{
"Policy": {
"PolicyName": "AWSLambdaKinesisExecutionRole",
"PolicyId": "AN...",
"Arn": "arn:aws-us-gov:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole",
"Path": "/service-role/",
"DefaultVersionId": "v2",
"AttachmentCount": 0,
"IsAttachable": true,
"Description": "Provides list and ead access to Kinesis streams and write permissions to CloudWatch logs.",
"CreateDate": "2017-05-08T18:26:34Z",
"UpdateDate": "2018-11-19T20:09:32Z"
}
}Running the above with --debug outputs the following request line:
2019-08-28 00:36:43,518 - MainThread - botocore.endpoint - DEBUG - Making request for OperationModel(name=GetPolicy) (verify_ssl=True) with params: {'url_path': '/', 'query_string': '', 'method': 'POST', 'headers': {'Content-Type': 'application/x-www-form-urlencoded; charset=utf-8', 'User-Agent': 'aws-cli/1.14.44 Python/3.6.8 Linux/4.15.0-1044-aws botocore/1.8.48'}, 'body': {'Action': 'GetPolicy', 'Version': '2010-05-08', 'PolicyArn': 'arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole'}, 'url': 'https://iam.us-gov.amazonaws.com/', 'context': {'client_region': 'aws-us-gov-global', 'client_config': <botocore.config.Config object at 0x7f7cc158e860>, 'has_streaming_input': False, 'auth_type': None}}So when the request is made to a us-gov AWS endpoint, even though the request has the aws partition, the response arn has the aws-us-gov partition.
Also - there's a typo in the Description response field.... could report to AWS
@gojko - Thanks, will try out that version before the end of the day (I'm in the eastern US timezone).
Does this version address the discrepancy between the AWS_REGION envvar and the --region command-line parameter mentioned here? :
:point_up: August 23, 2019 12:18 AM
@/all claudia 5.8 is now on NPM, with support for SNS topic filters, dead letter queues, and hopefully working with other AWS partitions. Check out the news post for more info https://claudiajs.com/news/2019/08/29/claudia-5.8.html
almost like I'm starting up an express server and I can hit my API locally
I get that I can locally execute my function. What I was hoping to do is to fire up the api on my local machine for debugging
@pehaada I've wondered about combining Stackery with Claudia for this kind of use case but haven't had time to pursue it yet - https://www.stackery.io/
@pehaada there’s this package, but I never tried it and I am not sure if it is still maintained: https://www.npmjs.com/package/claudia-local-api.
Not sure if stackery requires CloudFormation.
Not sure if stackery requires CloudFormation.
nm, that guide is geared toward APIG
The aws-serverless-express library we use to bring express apps up also needs the apig proxy events, so it won’t work out of the box
@gojko would be good at some point to add some support and examples around this. For now, I am unable to get it working so will continue reading and playing around with it. I keep getting 502 bad gateway. FWIW, I fall in this category of users: https://serverless-training.com/articles/save-money-by-replacing-api-gateway-with-application-load-balancer/#how-to-choose-between-application-load-balancer-and-api-gateway
@gojko So I managed to get things running using aws-serverless-express (v4 ) via https://github.com/awslabs/aws-serverless-express/tree/v4/examples/alb) which made it super easy to wrap my express server using 4 lines. I am pushing the code with Claudia, so it's a good combo.
I am using Claudia API Builder.
The endpoint that I created when hit 20 times at the same time produces the following error.
ThrottlingException: Rate exceededI basically have a for loop that loops over 20 times and in each loop it calls the Claudia API Endpoint.
I do not have throttling enabled for API Gateway so it should be like the following.Your current account level throttling rate is 10000 requests per second with a burst of 5000 requests
So I don't get why I get this error
@chantlong_twitter check the throttling settings for your api in the aws web console - look for the deployed stage in the api gateway web page. if may be something that's set on your API implicitly, claudia does not set any throttling limits; if the AWS web console doesn't show any throttling for that endpoint, it's best to check with AWS support, they will then be able to figure out what is causing the issue
@sebastienfi claudia only uses the proxy integration, and passes things through to Lambda. If you want to enrich requests as they are passing through API Gateway, the typical solution for that with claudia would be to use stage variables in API Gateway, not custom headers. you can read those variables out from the request object in Lambda then
@gojko That does not seem like what I want to achieve. An external provider realizes a POST every minute to an endpoint of our API Gateway. This provider offers important information only as POST Headers. These information changes at every POST. I need to access these custom headers in the Lambda... Does this context precision changes what you think would be the way to answer to this matter?
so the headers are set on the request by the external client, not in the api gateway? you can just read those headers out directly from the request object from request.headers (or if you want them lowercase, request.normalizedHeaders) - see https://github.com/claudiajs/claudia-api-builder/blob/master/docs/request-object.md for more info
@gojko Sorry, what I will write will surely disappoint you, but this is not the case. Only a restricted set of headers are allowed to make it throught natively. https://aws.amazon.com/premiumsupport/knowledge-center/custom-headers-api-gateway-lambda/
that's the case if you use the model transformations, if you use the proxy integration (which claudia does) all headers should just pass through. if your header does not, please create a minimal example that demonstrates the problem and we can look at it to see if there is some particular naming issue there
Error: ENOTEMPTY: directory not empty, rmdir 'C:\Users\abc1\AppData\Local\Temp\IhIFxs\myapi-1.0.0-5ymemD\package\node_modules\xmlbuilder'
validating package removing optional dependencies
You can try just running
claudia pack instead of deploying to experiment faster
I have a question, I'm getting a lot of server error response in Amazon gateway and when I check what happened I got the error
errorMessage": "2019-09-18T02:13:13.370Z 7d4003d4-240c-450a-a6c6-45a6f63b5ecf Task timed out after 3.00 seconds"So, I look for the function result and it ran successfully and also checked to see any answers in stack overflow, I got a response telling me to return the success using the amazn context, so, how can I achieve this from a async await returned from a controller to the claudia routes?
@hackerunet the message means that lambda is not completing work in the allocated time. there are usually two reasons for that:
- you have a broken promise chain somewhere, so something is not resolving/rejecting after finishing work. if you are using async/await for your endpoint functions, this usually isn't a problem, so check if you are manually creating a
Promisesomewhere that doesn't resolve, or if you use some library that requires callbacks and is not turned into promises correctly. - the task you are executing just sometimes takes more than 3 seconds, because it's talking to a slow external resource (for example database) or performing some complex task. for slower resources, you can fix this by allowing the function more time to execute (update it with
--timeout). For complex tasks, you can give it a better CPU by increasing memory (CPU cores get allocated proportionally, giving your function 1.5G gives it a whole core). By default, your function only gets 128MB I think, check the lambda docs, so it will get only about 1/10 of a CPU core. You can increase available memory by updating using--memory. Check out https://github.com/claudiajs/claudia/blob/master/docs/update.md for more info on those options
the stack overflow answer about amazon context is outdated
