SNS

Question 1

SNS

Answer 1

you want to send one message and have many, many different receivers

a buying service application could send an email notification, then send a message to your fraud service, send a message to your shipping service and maybe even send a message into an SQS queue.

Question 2

pub sub pattern

Answer 2

publish subscribe

The idea is that the buying service will send the message into an SNS topic, which is publishing a message into a topic.

And that topic will have many subscribers. And each of the subscriber will be able to receive that message from the SNS, SNS topic and have it for their own.

Question 3

protocols

Answer 3

HTTP
HTTPS
Email
Email-JSON
Amazon SOS
AWS Lambda

Question 4

events producer only sends a message

Answer 4

to one SNS topic, and you can have as many events receivers also also called subscriptions as you want to listen to these SNS topic notifications

You can have up to 10 million subscriptions per topic.
up to 100,000 topics in Amazon SNS.

Question 5

each subscriber will get

Answer 5

all the messages from the topic, even though now I know there’s a feature to filter messages, but still by default, each subscriber will receive all the messages
sent to the topic.

Question 6

Your subscribers of messages in Amazon SNS can be

Answer 6

SQS,
HTTP or HTTPS back end

and you can say how many times the retry should happen in case it fails.

Lambda functions.

email notification,

SMS messages,

and even mobile notifications.

Question 7

many different services can send data or notifications

directly into SNS.

Answer 7

CloudWatch Alarms can send notifications into SNS topics,

but also auto scaling group notifications.

Question 8

To publish a message into SNS

Answer 8

You use the topic publish SDK.

Question 9

In terms of security,

Answer 9

Amazon SNS has the same kind of security as SQS.

1. in-flight encryption by default,
2. at-rest encryption using KMS keys
3. client site encryption: if your clients wants to send some encrypted message into SNS, but again, it’s up to your client responsibility to do the encryption and the decryption.
4. IAM policies are going to be at the center of security
   because all the SNS APIs will be regulated by IAM policies.
5. And you can define SNS access policies,
   which are very similar to S3 bucket policies.
   And they’re very helpful when you want to have cross-accounts access to SNS topics,

or to allow other services such as your S3 events to rights

into your SNS topics.

Question 10

SNS + SQS: Fan Out

Answer 10

The idea is that you want to send the same message
into many different SQS queues but to do so, you’re going to use SNS.

you will push once the message into SNS, and all the SQS queues that are subscribers for that message will receive it.

the buying service wants to send a message to many different SQS queues because you have many different applications reading from SQS, and therefore, you will send it first to an SNS topic.

Fan-Out because we send once, and we have multiple receives into SQS queues.

fully decoupled, there are no data loss: you can add more SQS subscribers over time and the Buying Service won’t even know about it,

by having the message into SQS queues, then we have data persistence, we can get delayed processing and retries of work.

Question 11

SNS + SQS: Fan Out

to make sure that this works, your SQS queue needs to have

Answer 11

an access policy that allows the SNS service to write to it

otherwise the message will not be accepted.

Question 12

SNS cannot send messages to

Answer 12

SQS FIFO queues which is a limitation by AWS.

So if in the exam, you see that SNS sends message
to SQS FIFO queue, you can rule out that answer
because that is simply not possible today.

Question 13

use case for SQS and SNS Fan-Out

Answer 13

S3 Events cannot send by default one event type to many different destinations.

So you can have many, many different rules into your S3 Events, but for one specific type of event, for example, objects being created, and the specific prefix for example, images slash or just star, you can only have one S3 Event rule.

for example, you want to have an application that reads events from an SQS queue for all the objects created into your S3 bucket, then you can only have one rule, that will send messages into only one SQS queue.

But if you want to have many SQS queues, having these events or a copy of this events, then you cannot use just S3 event. You have to use the fan-out pattern

You have your objects-created rule into your Amazon S3 event notification. And instead of having SQS queue as destination, you will have an SNS topic as a destination for this events. And the SNS topic will use the fan-out pattern to send this message to as many SQS queues as you need, so that different applications
can read the same events coming out of the S3.