What : I am trying to implement Codepipline manual approval slack notification.
I was reading this implementation https://aws.amazon.com/blogs/devops/use-slack-chatops-to-deploy-your-code-how-to-integrate-your-pipeline-in-aws-codepipeline-with-your-slack-channel/
In this implementation:
Manual approval from codepipline will invoke lambda which will post manage to the slack channel for yes or no approval.
Now here is where I think I can implement in a better way, blog talks about sending the approval data to api gateway and then invoking lambda which will tell the codepiline to proceed with deploy stage or not.
Instead of api gateway I think we can use function url to invoke lambda.
I am wondering if someone has also faced a similar situation what pattern did they use?
Related
We are exposing a AWS Api Gateway which needs to act as proxy and push body as message to AWS SQS. Our API gateway body can be array of object which we need to parse and send each object to SQS as separate message. Is there any way to achieve this without using Lambda ?
To answer your question, for something as simple as parsing a message and posting to SQS, I don't believe you need Lambda, no. Lambdas are designed for serverless-architecture. That is, when you don't have a server and you still want to run code. In this case, you do have a server behind your API Gateway, so you don't need Lambda (unless you want fancy branching error handling). You can use your API Gateway directly, yep. Here's a code review I found:
https://dzone.com/articles/creating-aws-service-proxy-for-amazon-sqs
I'm attempting to subscribe an SNS topic to a HTTPS endpoint I own. I'm reading the docs on how to process incoming messages from SNS and how the subscription confirmation needs to be done. I see two methods of confirmation:
https://docs.aws.amazon.com/sns/latest/dg/sns-http-https-endpoint-as-subscriber.html - Using the subscribeURL. We can perform a HTTP get request on the "SubscribeURL" attribute value and that would confirm the subscription.
Calling the ConfirmSubscription API - We pass the SNS Topic ARN and the token received when SNS sends a confirm subscription message to the SNS endpoint.
I'm trying to understand what's the difference between the two methods. The most obvious one to me was this - The choice of using the API will require AWS credentials since the request needs to be signed. But seems like the same call will succeed with just the HTTP GET request?
What's the best practice out there (if any) and/or which method is the one being followed by other folks using AWS/SNS?
There isn't a difference -- these two alternatives are in fact the same thing.
The SubscribeURL attribute is a pre-constructed (by the service) link to the ConfirmSubscription action on the SNS API endpoint.
The API accepts GET or POST. No signature is required in this case.
This call requires an AWS signature only when the AuthenticateOnUnsubscribe flag is set to "true".
https://docs.aws.amazon.com/sns/latest/api/API_ConfirmSubscription.html
Before SNS will talk to an endpoint, you need to prove that you control that endpoint. So your options are to write some code that can do it automatically (most of the SDKs support this) or to capture the token, and by returning it via the API call prove that you control it.
This is a one-time procedure, so you do not need to deploy any AWS credentials to your API endpoint - you can do it from a different system.
We generally build the confirmation handler into the application.
I want to make a query to elastic and send a sns message without raising a lambda function, is this possible with appsync?
You can invoke AWS services using the Appsync HTTP Resolver as explained in the docs here under "Invoking AWS Services". The SNS server has a REST API you can point the HTTP Resolver at in order to publish a message (see docs here).
This would avoid starting up a Lambda function.
I have built that recently for one of my customers and it took me some time to get it working as there is no documented approach on how to integrate AppSync with legacy AWS APIs.
Here is a step by step implementation guide: https://medium.com/#dlozitskiy/publish-messages-to-sns-topic-using-appsync-resolvers-with-http-datasources-7291cb040dab
If you want to send a message that is going to be applied to a velocity template then you will need a Lambda to process it, otherwise your other option is using SES which has built in template support
There is instructions on how to integrate between API Gateway and SNS here but this is a bit of a toy example.
I want to know how I can subscribe to a topic via API Gateway -> SNS Integration.
And to this purpose what I'm looking is general documentation on doing this as I assume it is possible. If you can ListTopics (which the example indicates) surely you can do other things...
Edit: So I now know that when I do an integration into SNS it sends the following to SNS: https://sns.eu-west-1.amazonaws.com/?Action=CreateTopic
So that's a good start as that is how to call SNS to create a topic.
So now the question is how to I parameterise this?
I have also figured out that I can do from post to the SNS endpoint and thus include my parameters. However, the I get a signature not present error...
I have a lambda function i'd like to invoke from the client-side. I was going to use the API Gateway, but it occurred to me that the queuing SNS affords might be handy.
After researching, it appears the only way to publish to SNS thru the Javsacript SDK is auth thru google/facebook or AWS Cognito. I'd like users (more specifically, events) to be able to push w/o auth'ng, so that's not an option.
The last option is hard-coding an AWS key. This is pretty explicitly discouraged in the docs, but after looking into it, it looks like I can create security provisions for a specific key and limit it to publishing only to one topic.
In other words, it'd ostensibly mimic a REST API, wouldn't it?
The only drawback I can think of is malicious spamming of the SNS. I know AWS API allows for rate-throttling, but couldn't find something similar on SNS.
So, 2 related question:
Is there a way to prevent malicious spam to an SNS topic?
are there other drawbacks to using SNS instead of an AWS API for invoking lambdas?
What queueing are you wanting to get from an SNS topic? I think you may be confusing SNS with SQS.
I see no advantage to using SNS->Lambda in this instance versus API->Lambda. I do however see several drawbacks to using SNS in this instance as it adds an unnecessary complication, as well as opens up unnecessary security risks.
You literally get no advantage to using SNS here, while you get several advantages to using API Gateway such as rate limiting and API key support. Not to mention that API Gateway endpoints are much easier to access from the browser than SNS topics. This is API Gateway's intended use, why try to hack together some method using SNS and hard coded AWS keys?