Update AWS SNS README.md (#11946)

* Update README.md

I mainly made changes to the structure and the copy to improve legibility. 

However, I still need some input for these sections: 

### line 18: Q: How is Netdata better than SNS?

### line 31: 
 -   While not mandatory, it is highly recommended to create a dedicated IAM user on your account for Netdata to send notifications. This user needs to have programmatic access, and should only allow access to SNS. If you're really paranoid, you can create one for each system or group of systems.

Q: Can someone clarify what this means and how we can say the same thing without calling our users paranoid? 

### line 43
* Q: I need to know which config file the user needs to change. 
* Q: I need clarification on this sentence: This variable supports all the same variables you can use in custom notifications.

I've also found a [configuration script of a community member](http://pkg.cs.ovgu.de/LNF/linux/ubuntu/18.04/LNFnetdata/reloc/share/netdata/conf.d/health_alarm_notify.conf) containing an AWS SNS section. Is the information relevant to only this community member or a wider audience? Can we possibly use some of it as an example?  

------------------------------------------------------------------------------
# Amazon SNS notifications
#
# This method requires potentially complex manual configuration.  See the
# netdata wiki for information on what is needed.

# enable/disable sending Amazon SNS notifications
SEND_AWSSNS="YES"

# Specify a template for the Amazon SNS notifications.  This supports
# the same set of variables that are usable in the `custom_sender()`
# function in the custom notification configuration below.
#
AWSSNS_MESSAGE_FORMAT="${status} on ${host} at ${date}: ${chart} ${value_string}"

# If a role's recipients are not configured, use the following.
# (empty = do not send a notification for unconfigured roles)
#
# Recipients for AWS SNS notifications are specified as topic ARN's.
#
DEFAULT_RECIPIENT_AWSSNS=""

Thank you!

PS.: I kept Google analytics, as we will sweep out these links in a different initiative.

* Applied comments from code review

* Removed Typo

1 files changed, 28 insertions, 18 deletions

diff --git a/health/notifications/awssns/README.md b/health/notifications/awssns/README.md
index f5368ab2ca..fc4a665e90 100644
--- a/health/notifications/awssns/README.md
+++ b/health/notifications/awssns/README.md
@@ -6,7 +6,8 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/health/notificat
 
 # Amazon SNS
 
-As part of it's AWS suite, Amazon provides a notification broker service called 'Simple Notification Service' or SNS.  Amazon SNS works kind of similarly to Netdata's own notification system, allowing dispatch of a single notification to multiple subscribers of different types.  Among other things, SNS supports sending notifications to:
+As part of its AWS suite, Amazon provides a notification broker service called 'Simple Notification Service' (SNS). Amazon SNS works similarly to Netdata's own notification system, allowing to dispatch a single notification to multiple subscribers of different types. While Amazon SNS supports sending differently formatted messages for different delivery methods, Netdata does not currently support this functionality.
+Among other things, SNS supports sending notifications to:
 
 -   Email addresses.
 -   Mobile Phones via SMS.
@@ -15,29 +16,38 @@ As part of it's AWS suite, Amazon provides a notification broker service called
 -   AWS SQS queues.
 -   Mobile applications via push notifications.
 
-To get this working, you will need:
+For email notification support, we recommend using Netdata's email notifications, as it is has the following benefits:
 
--   The Amazon Web Services CLI tools.  Most distributions provide these with the package name `awscli`.
--   An actual home directory for the user you run Netdata as, instead of just using `/` as a home directory.  Setup of this is distribution specific.  `/var/lib/netdata` is the recommended directory (because the permissions will already be correct) if you are using a dedicated user (which is how most distributions work).
--   An Amazon SNS topic to send notifications to with one or more subscribers.  The [Getting
-    Started](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) section of the Amazon SNS documentation
-    covers the basics of how to set this up.  Make note of the Topic ARN when you create the topic.
--   While not mandatory, it is highly recommended to create a dedicated IAM user on your account for Netdata to send notifications.  This user needs to have programmatic access, and should only allow access to SNS.  If you're really paranoid, you can create one for each system or group of systems.
+- In most cases, it requires less configuration.
+- Netdata's emails are nicely pre-formatted and support features like threading, which requires a lot of manual effort in SNS.
+- It is less resource intensive and more cost-efficient than SNS. 
 
-Once you have all the above, run the following command as the user Netdata runs under:
+Read on to learn how to set up Amazon SNS in Netdata.
 
-```
-aws configure
-```
+## Prerequisites
 
-THis will prompt you for the access key and secret key for accessing Amazon SNS (as well as the default region and output format, but you can leave those blank because we don't use them).
+Before you can enable SNS, you need:
 
-Once that's done, you're ready to go and can specify the desired topic ARN as a recipient.
+-   The [Amazon Web Services CLI tools](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) (`awscli`).
+-   An actual home directory for the user you run Netdata as, instead of just using `/` as a home directory. The setup depends on the distribution, but `/var/lib/netdata` is the recommended directory. If you are using Netdata as a dedicated user, the permissions will already be correct.
+-   An Amazon SNS topic to send notifications to with one or more subscribers. The [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) section of the Amazon SNS documentation covers the basics of how to set this up. Make note of the **Topic ARN** when you create the topic.
+-   While not mandatory, it is highly recommended to create a dedicated IAM user on your account for Netdata to send notifications. This user needs to have programmatic access, and should only allow access to SNS. For an additional layer of security, you can create one for each system or group of systems.
 
-Notes:
+## Enabling Amazon SNS
 
--   Netdata's native email notification support is far better in almost all respects than it's support through Amazon SNS.  If you want email notifications, use the native support, not SNS.
-    -   If you need to change the notification format for SNS notifications, you can do so by specifying the format in `AWSSNS_MESSAGE_FORMAT` in the configuration.  This variable supports all the same variables you can use in custom notifications.
-    -   While Amazon SNS supports sending differently formatted messages for different delivery methods, Netdata does not currently support this functionality.
+To enable SNS:
+1. Run the following command as the user Netdata runs under:
+   ```
+   aws configure
+   ```
+2. Enter the access key and secret key for accessing Amazon SNS. The system also prompts you to enter the default region and output format, but you can leave those blank because Netdata doesn't use them.
 
+3. Specify the desired topic ARN as a recipient, see [SNS documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html#set-up-sns-topic-cli).
+4. Optional: To change the notification format for SNS notifications, change the `AWSSNS_MESSAGE_FORMAT` variable in `health_alarm_notify.conf`. 
+This variable supports all the same variables you can use in custom notifications.
 
+   The default format looks like this: 
+   ```bash
+   AWSSNS_MESSAGE_FORMAT="${status} on ${host} at ${date}: ${chart} ${value_string}"
+   ```
+