I configured AWS EventBridge to post events to an SNS target. When an event is received, the SNS target is never triggered and none of the SNS subscribers get the event.
If I add other targets to EventBridge it works (eg, Lambda) but the SNS does not. Adding a dead-letter queue to SQS show there's a permissions issue:
However, changing the Access Policy of SNS does not work.
If encryption is enabled for SNS, disabling it is not the solution. Rather give events service the required access policy to encrypted SNS topic.
More details on following link here:
https://aws.amazon.com/premiumsupport/knowledge-center/cloudwatch-receive-sns-for-alarm-trigger/#:~:text=If%20the%20SNS%20topic%20must,messages%20to%20encrypted%20SNS%20topics.
Replace cloudwatch.amazonaws.com to events.amazonaws.com
Update:
It seems encryption is not supported if using the default AWS Key Management Service (KMS). It can be configured using customer managed keys as explained in this other answer.
Old answer:
The problem seems to be a configuration issue or even a bug in AWS. If the SNS Topic has Encryption At-Rest enabled, then it fails.
The solution is to disable Encryption under the SNS Topic settings:
This issue was with using the AWS-managed keys(aws/sns).
Changing to Customer managed keys worked for me.
You can also add multiple targets to check if logs are generating. The easiest would be log-group.
Related
I have a scenario where I publish a message in a SNS topic and this message then is sent to SQS queue. What I want is to have logs in SNS everytime a message is sent to a subscriber (like my sqs queue). SNS being a passive component of AWS, logs are not generated automatically and must be set up through the feature "Delivery status logging". I have accomplished the set up through the AWS console but I would like to do it through the AWS CDK. I did not find anything in the documentation and either in examples through the web. Anyone already did that ?
Regards,
I am afraid it can be done currently only via AWS SDK or management console: https://docs.aws.amazon.com/sns/latest/dg/sns-topic-attributes.html
To configure topic attributes for message delivery status, you can use the AWS Management Console, AWS software development kits (SDKs), or query API.
I see no option to set it via CloudFormation: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sns-topic.html
I am working on AWS Codepipeline, How to set up e-mail notifications for developer did last commit and build was failed. Now identify the user and send automatic email for the developer along with manager. Can anyone please help on this
Thanks in Advance
You can use notification rules to notify users of important changes, such as when a pipeline starts execution. Notification rules specify both the events and the Amazon SNS topic that is used to send notifications. On the SNS topic, a subscription could be a User/Manager email address. Details here: [0]
Currently the notification message that is sent in case of, for example, pipeline success, does not include the Commit id or the Committer information [1].
As a work-around I suggest to implement additional stages within the pipeline that would Invoke a Lambda Function. The Lambda Function can then be programmed to publish the detailed event message [2] to the SNS using AWS SDKs. Detailed instructions for this set-up are documented at [3].
References:
[0] https://docs.aws.amazon.com/codebuild/latest/userguide/notification-rule-create.html
[1] https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#codepipeline_event_type
[2] Example JSON Event - https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html#actions-invoke-lambda-function-json-event-example
[3] Invoke an AWS Lambda Function in a Pipeline in AWS CodePipeline - https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html
When attaching a topic to a SNS application's "Endpoint updated" configurable topic I'm experiencing some unexpected behavior. Per AWS's documentation on SNS Application Events, I should receive an event on my configured topic when a platform endpoint has been updated to disabled or it's token changed.
In my case I have a lambda function subscribed to this topic that then retrieves the platform endpoint's attributes via a call to AWS's javascript sdk SNS.getEndpointAttributes so that I can check what attribute have changed to either delete the endpoint or update the associated token in my persistent storage. This call however is returning the endpoints as Enabled = true which then prevents me from taking the corrective actions. However if I look in the AWS SNS console I can see the endpoint has been disabled as Enabled = false.
Have others experienced similar inconsistencies and if so what's the best practice to get around them? Thanks for any input!
I was also facing the similar problem when amazon notified me sns application events via http. To work around this problem i actually delayed the execution of code that sync these endpoint updates with my database. To achieve this i scheduled a job for my background queue worker and delayed its execution after 30 seconds from the time amazon notified via http. I don't know whether it is a best practice or not but it is working in my scenario.
I've recently started using application insights with a web api.
It will be really helpful to configure app insights to post error messages in a slack channel.
I've seen there is a slack connector but I am not sure how to use it, my guess is that this can be solved with the slack connector and a azure logic app, any tips? tutorials?
You may have a look at this link: https://github.com/Azure/azure-quickstart-templates/tree/master/demos/alert-to-slack-with-logic-app. I followed the instruction and it worked for me.
The tricky part is you need to click the "Deploy to Azure" button on this link page. It would redirect you to Azure Portal, and you will need to specify which channel you want the alert message to be sent e.g. #somechannel. Don't use direct message like #yourname, it has some problem with that and the logic app couldn't deploy for me.
Then you just follow the instruction to find the deployed logic app and authenticate it by logging into slack. And you also need get the logic app URI from the deployment output as in the instruction. Once you put the URI into the alert webhook, you are ready to go!
It's relatively easy to set up a slack webhook.
There's a pretty good C# nuget package for this at https://github.com/nerdfury/Slack.Webhooks
Although you'd need to set up a seperate service to poll and route the app insights data.
There's also commercial options.
getcloudbot.com allows you to hook your Azure Application Insights bundle directly into your slack channel. It's good at staying on top of your services.
Disclaimer : I run it.
You can configure an alert for your error messages https://azure.microsoft.com/en-us/documentation/articles/app-insights-alerts
And then configure sending to Slack using web hooks: https://code.msdn.microsoft.com/Create-Azure-Alerts-with-b938077a
Another quick solution to this, which doesn't involve additional code or a logic app, is to set up a Slack email integration, which provides you an inbound email address for a given channel. You can use that in Application Insights in the "Additional administrator email(s)" field.
This isn't perfect, as you don't really get a lot of details in the post to slack, but it will notify you and provide the name of the alert.
The most easiest path that I found to integrate was using an app named Slack Email which sends email alerts to slack. Once you subscribe this email id to alerts in Application Insights it will start sending the messages on the specific channel you have linked the email to.
https://teamesub.slack.com/apps/A0F81496D-email
We are using Elastic Beanstalk to serve a REST API. Now, I want to develop an endpoint that serves notifications from an SNS-topic in an asynchronous way.
In order to receive those notifications, I need to subscribe the API-servers to the SNS-topic. How could I do this, with the scenario in mind that the EBS application can scale up to multiple servers and scale down again? I don't want a lot of dead links subscribed to the SNS-topic...
In spring world we have a #PostConstruct which gets called on server startup, where you can subscribe "this.server" url to a given topic (you may need to build a proper working subscription url --using InetAddress et el).
Hence there is the working subscribe url using #RestController which confirms such an subscription instantaneously causes sns endpoint to be registered. Any new servers will do the same aka getting registered themselves (when new stack is created). We also need additional code for the consumption of notification messages subsequently and do something when confirmed subscription endpoints receive one.
The way AWS wants you to use SNS is not by directly subscribing to it. Any notification which need to trigger something in a component should buffer notifications with an SQS queue. For this reason we chose to do Pub-Sub with a variable/scalable group of Subs using the Amazon managed Redis distribution.