Now let's talk about Amazon SNS.
So what if this time you want to send one message
and have many, many different receivers?
So you could have a direct integration where for example
a buying service application could send an email
notification, then send a message to a fraud service
send a message to a shipping service and maybe
even send a message into an SQS Queue.
This is cumbersome because every time
you have to add a new receiving service.
You need to create and write that integration.
Instead, what you may want to do
is called a Pub/Sub or Publish-subscribe.
The idea is that the buying service
will send a 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 topic
and have it for their own.
And so this is another type of pattern
called the Pub/Sub pattern.
So in Amazon SNS,
the event producer only sends messages
to one specific SNS topic.
And the event receivers or the subscriptions,
they want to listen to the SNS topic notifications.
And so therefore each subscriber in your SNS topic
will get all the messages sent to the topic
except if you're using a feature to
filter messages and it is possible as well.
So how many subscribers can you get per topic?
Well you can have up to 12,000,000 plus subscriptions
per topic, so quite a lot.
And the number can change over time.
It will not update this slide.
It's just to give you a overview
of how many subscribers you can get.
And in your account, you can get up to 100,000 topics
and you can increase that limit as well.
And this can change, but again,
just to give you an idea of what the limit may be,
but you're never tested on limits themselves for SNS.
So for SNS, you're going to publish your subscribers
and what can they be?
Well you can directly send emails from SNS.
You can send SMS and mobile notifications.
You can also send data directly into specified HTTP
or HTTP(S) endpoints,
but SNS also has integrations with specific AWS services,
such as SQS,
to send your message directly into a Queue, to Lambda,
to have a function do some code
after the message is received,
or to Kinesis Data Firehose to send data into,
for example, as Amazons free or Redshift.
On top of it, SNS receives data
from a lot of AWS services.
So they directly send it into SNS,
so it could be CloudWatch Alarms,
Auto Scaling Group notifications,
CloudFormation state changes, Budgets
S3 buckets, DMS, Lambda, DynamoDB,
RDS events, and so on.
So you don't have to remember them.
But as soon as there is some sort
of notification that happens within AWS,
services will send a notification
into a specified SNS topic.
Now, SNS, how does that work?
to publish a message into SNS,
you use the topic, publish SDK.
And so you create a topic.
Then you create subscriptions or many
one or many subscriptions you publish
to the SNS topic and that's it.
All the subscribers will automatically
retrieve that message.
Or there is something called direct publish
for mobile apps, SDK,
and you need to create a platform application,
a platform endpoint
and you publish into the platform endpoint,
and it works in terms of subscribers for Google GCM,
Apple APNS, or Amazon ADM, which are different ways
for your mobile application to receive notifications.
In terms of security,
Amazon SNS has the same kind of security as SQS,
so it has In-flight encryption by defaults
At-rest encryption using KMS keys,
and Client-side encryption
if your client wants to send some encrypted message
into SNS, but again,
it's up to your client responsibility to do the encryption
and the decryption.
In terms of of access controls,
IAM policies are going to be at the center
of security because all the SNS APIs will be regulated
by IAM policies.
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 account access to SNS topics
or to allow other services
such as your S3 events
to write into your SNS topics.
So that's it, I hope you liked it
and I will see you in the next lecture.