So, I have an application which invokes a URL from API gateway due to which a Lambda function gets triggered which writes to SQS queue and the queue is polled by another lambda function which send the transformed message to SNS topic (This has been configured via code base of lambda).
Something like this
So if i want to do A/B deployment on those lambdas function it doesn't seem to work.
So what I tried was with creating another stage variable in API gateway and creating different lambda unction and SQS but at the end I was not able to point the application to new version without redeploying my code (What I want is to send traffic to newly deployed changes after testing)
Also tried with creating different version of lambda function and alias record to shift with weight but that way we won't be able to test new version without effecting the older one.
Is there any way we can do A/B on this?
Related
While I understand EventBridge will retry sending an event - through a rule - to a target, such as an API Destination, is there any way to read the receiving API's response code and any returned messages for the respective invocation (i.e., the original invocation and any subsequent retries)?
What I have: an event triggered from a Step Function, which is sent to EventBridge. The Event is filtered by an "app ID" rule, and invokes an external API (note: note one of the pre-integrated API's available via AWS). I am able to receive the API call using webhook.site, however, I would like to use the response data inside the sending web app. As such, I need to be able to call the latest API response on demand - and would like to keep trying failed attempts periodically for a pre-set period of approx 14 days.
No there is no such way, unless you implement a custom solution for that yourself. For example, have EB rule trigger a lambda function, which is going to save event and its metadata in a dynamodb. Then you can manage invocations of your other target yourself.
I have two lambda functions in my AWS. One acts as a custom authorizer and the other acts as a notification service which calls the firebase FCM notification service.
When a request is made first time in a day to the notification lambda there is no response. The lambda does not work and hence does not call the firebase service.
It seemed like a cold start problem to me so I added the provisioned concurrency for both auth and notification lambda to 1 in the hope that it will work. But the problem persists.
Cloudwatch logs are of no help at all since nothing gets printed to it which I can use to figure out the issue. Either the authorizer lambda goes cold and does not response or the primary notification lambda goes cold and does not response or even both of them have issues.
After the first call to lambda fails any subsequent calls then work smoothly like a charm.
I do not want to install any plugin which will keep the lambda warm (not an option from the client) so is there some other way I can diagnose this problem and fix it?
I have been researching AWS Documentation on how to invoke lambda functions, and I've come across different ways to do that. Mainly, Lambda invocation is done by calling Invoke() function which can be used to invoke lambda functions synchronously or asynchronously.
Currently I am invoking my Lambda functions via HTTP Request (as REST API), but, HTTP Request times out after 30 seconds, while asynchronous calls as far as I know times out after 15min.
What are the advantages, besides time that I have already mentioned, of asynchronous lambda invocation compared to invoking lambda with HTTP Request. Also, what are best (recommended) ways to invoke lambdas in production? On AWS docs (SDK for Go - https://docs.aws.amazon.com/sdk-for-go/api/service/lambda/#InvokeAsyncInput) I see that InvokeAsyncInput and InvokeAsyncOutput have been depricated. So I am wondering how async implementation would actually look like.
Lambda really is about event-driven-computing. This means Lambda always gets triggered in response to an event. This event can originate from a wide range of AWS Services as well as the AWS CLI and SDK.
All of these events invoke the Lambda function and pass some kind of information in the form of an event and context object. How this event looks like depends on the service that triggered lambda. You can find more information about the context in this documentation.
There is no real "best" way to invoke Lambda - this mostly depends on your use case - if you're building a webservice, let API Gateway invoke Lambda for you. If you want to process new files on S3 - let S3 trigger Lambda. If you're just testing the Lambda function you can invoke it via the CLI. If you have custom software that needs to trigger a Lambda function you can use the SDK. If you want to run Lambda on a schedule, configure CloudWatch events...
Please provide more information about your use case if you require a more detailed evaluation of the available options - right now this is very broad.
I am creating a serverless infrastructure with multiple functions. So far I have managed to publish a new function on AWS lambda using the aws-sam-cli.
One of the last functions is my firebase listener which is supposed to trigger certain aws lambda functions.
Intially, I thought to create a new function and add the listener as follows:
import firebase_admin
cred = firebase_admin.credentials.Certificate(cert_json)
app = firebase_admin.initialize_app(cred, config)
bucket = storage.bucket(app=app)
node_to_listen = '/alerts/'
firebase_admin.db.reference(node_to_listen).listen(listener)
However, the issue is that AWS lambda seems to be designed not to run functions continuously but only be triggered by events. This is true as well for the Firebase listen() function, which means that we get a chicken or egg problem, who triggers who?
How can I therefore publish the firebase listener function and where? Should it be deployed somewhere else (e.g. Heroku?) in order to continuously listen and send the event requests to aws lambda? Or is there a way to connect those two?
There's no way to keep an active listener in any Functions-as-a-Service environment that I know of. The whole purpose of such environments is to run (short) workloads in response to events. You are trying to actually to trigger an event by keeping a listener, which simply doesn't fit the FaaS model.
The two solutions I can see:
Implement your listener on an environment that keeps an active process.
Implement your listener on a FaaS environment that can itself listen to Firebase Realtime Database events. The only environment that can current do so it Cloud Functions, which has Firebase Realtime Database as an event source. So you'd then trigger your Lambda function from Cloud Functions.
The second solution is the only one that really feels fully serverless, but it seems a bit weird to trigger Amazon Lambda from Google Cloud Functions.
There is work under way to allow interop between FaaS providers. But I'm not sure of the current status (link to spec/working group welcome), nor if your scenario would be covered in there.
I am using AWS Lambda to check the health status and then send out an email. If the health is down I want it to send an email only once.
This Lambda function runs every 20minutes or so and I would like to prevent it from sending out multiple emails in interval if things have broken. Is there a way store environment variables or something in the AWS eco system so that it knows the state between each lambda function runs. (that way it doesnt send out an email and knows it has sent an email already).
I have looked into creating an alarm and sending out notifications but the email sent out through alarm wont do and I would like to have a custom email sent out, so I am using AWS SES through lambda. There is a cloud watch alarm that turns on when there is an error but I cant seem to fetch the state of alarm through the aws-sdk (its apparently not there).
I have written the function in NodeJS
Any suggestions ?
I've implemented something like this a little differently. I too do not care for getting an email for each error, since the errors I receive from my AWS Lambdas do not require immediate attention. I prefer to get them once an hour.
So I write all the errors I receive to an SQS queue. I configure the AWS Lambdas, which are throwing the errors, to send certain errors (configurable via environment variables) to certain SQS queues. Cloudwatch rules (running whenever), configured to pull from specific SQS queues in the Cloudwatch rule definition, then execute an AWS Lambda passing in the rule definition containing the SQS queue to pull from. The Lambda called by the CloudWatch rule handles reading from the SQS queue then emailing the results.
For your case you could modify that process to read all the errors from SQS, then filter that data down to the results you want to send. I use SQS because the "errors" I get don't need to be persisted.
I could see two quick ways to store something like a "last_email_sent" value. The first would be in DynamoDB. This is part of the AWS "serverless" environment that doesn't require you to do much more than interact with it. You didn't indicate your development environment but there are multiple development environments that are supported.
The second would be with the SSM Parameter Store. You can store any number of parameters there too.
There are likely other ways to do this too. Both of these are a bit of overkill but they would work to store what you need.
Alright, I found a better way that is simpler without dealing with other constraints. The NodeJS sdk is limited as it is. When the service is down create an alarm through the sdk and the next time the lambda gets triggered check if the alarm exists and send an email. That way if you want to do some notification through alarm it is possible too.
I think in my question I said this was not possible (last part), which I will retract.
Here is the link for the sdk reference: https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CloudWatch.html