I have some CloudWatch alarms that I need to set up and I only want alerts from a composite alarm (more than one of the components making up the composite alarm are set to ALARM)
I do not want to receive alarms from the individual components of this composite alarm because this would only inform us of a transitory condition that usually self-resolves.
My quesstion is, If a create an SNS Topic called "Unmonitored" for example and have those component alarms get sent to that topic do these alarms start to accumulate over time and how does AWS handle this?
I couldn't find any information on SNS lifespan or what happens to messages sent to an SNS topic when there are no subscriptions to that topic set up.
Edit: as a test I created a CloudWatch alarm with an SNS Topic that has no subscriptions and I get this message in the console:
Warning: "This action sends a message to an SNS topic with no endpoints or the endpoints are in a different account."
Which is to be expected.
I had used amazon pinpoint and enable two way sms
I had used amazon lex for chat
I had lambda which trigger with SNS and it will send store message to dynamoDB
When user send response to pinpoint original number at that time user get smpp delivery receipt.
I want to disable that smpp delivery report
Is it possible to send different message to different email endpoints having different subscription ARN.If possible suggest some way using message filtering.
All emails subscribed to same Topic .But requirement is to send rewards points balance based on email which is being fetched from a query either rest or dynamodb query.
It is not possible to customize Amazon SNS messages per-user. All recipients will receive the same message.
Yes, you can use Amazon SNS filtering to control which recipients get each message, but that isn't really a good idea for sending single messages.
I would recommend that you investigate Amazon Pinpoint:
Amazon Pinpoint is an AWS service that you can use to engage with your customers across multiple messaging channels. You can use Amazon Pinpoint to send push notifications, emails, SMS text messages, and voice messages.
It might be a better way to engage with your customers.
I need to get custom data as part of email events (open, click, etc) sent from AWS SES.
For sendgrid I do (Java)
Personalization personalization = new Personalization();
personalization.addCustomArg("event_type", "SubscriptionDeliveryEmailEvent");
personalization.addCustomArg("event_source_type", "SubscriptionDelivery");
mail.addPersonalization(personalization);
How can I do the same for AWS SES? I couldn't even find a mention to it. (Java preferred pls :D)
AWS SES doesn’t provide any type of webhook out of the box for any type of event (open, click...)
Basically I have created a cloud function(written a Node.js code) which will trigger on the message of cloud pubsub topic and will load that data to Bigquery table.
A message in a topic gets deleted after reading it by cloud function. I understand that subscriber internally sends acknowledgement and result of that, message gets deleted from topic.
I want to control the acknowledgement sent to publisher. How can it be achieved, didn't find any document on this.
Google Cloud Functions does not allow you to control the acknowledgement of the Cloud Pub/Sub message. Upon completion of the function, the message is acknowledged for the subscription. If you want finer-grained control over acknowledgements, then you will need to use Google Cloud Pub/Sub directly. There is a Node.js client library.
Just some clarifying notes on acknowledgements: Acknowledging a message for a single subscription doesn't mean the message is deleted for the topic, only for the subscription. Other independent subscriptions will still receive the message and have to acknowledge it. This is also independent of the acknowledgement sent to the publisher. When a Google Cloud Pub/Sub message is published, the publish call is acknowledged (i.e., a response is sent to the publisher) once Google Cloud Pub/Sub has saved the message and guarantees it will be delivered to subscriptions. This is one of the main advantages of an asynchronous message delivery system: receiving the message from the publisher (and acknowledging the publish) is independent of delivering the message via a subscription (which is separately acknowledged by the subscriber).
If I understand correctly; you made a pub/sub topic and placed a cloud function within the same project as this topic. The cloud function is deployed with a google.pubsub.topic.publish trigger for the specified topic.
Since using a queue/topic, producer and consumer operate independently of each other. This enables a loosely coupled architecture, which has its own advantages and disadvantages.
If the publisher publishes a message to the topic, it gets confirmation that the message is sent to the topic successfully. Otherwise your code will give an exception (connection refused, forbidden, etc). For Node.js and other languages, there are pub/sub client sdk's which you can use to publish messages fairly easy.
When the message is on the topic, it will go to the subscribers, which can be push or pull subscriptions. At this point, acknowledgement is getting important. Google pub/sub, as do other queues/topics, are designed with guaranteed delivery. This means if a message could not be delivered, it will try again after some (configurable) time, until the total lifetime is exceeded (default is 7 days)
When using a pull subscription and want to let the topic know that you successfully received the message you would need something like this in Node.js:
message.ack();
When using a push subscription to an API or a HTTP cloud function, you would need to return a custom http code. Pub/sub expects a succes status code (e.g. 200 or 204):
res.status(204);
res.send('OK');
The only way I have found to reliably control what messages get acknowledged and don't in a cloud function is by using the REST Service APIs.
This is because the node.js pubsub client services acknowledgements and manages connections in the background. This is clearly forbidden in a cloud function.
However, the REST API's are fairly easy to use, and give fine grain control over what messages get acknowledged.