Amazon Simple Notification Service (Amazon SNS) is a web service that makes it easy to set up, operate, and send notifications from the cloud. It provides developers with a highly scalable, flexible, and cost-effective capability to publish messages from an application and immediately deliver them to subscribers or other applications. It is designed to make web-scale computing easier for developers. Amazon SNS follows the “publish-subscribe” (pub-sub) messaging paradigm, with notifications being delivered to clients using a “push” mechanism that eliminates the need to periodically check or “poll” for new information and updates. With simple APIs requiring minimal up-front development effort, no maintenance or management overhead and pay-as-you-go pricing, Amazon SNS gives developers an easy mechanism to incorporate a powerful notification system with their applications.
The Amazon SNS service can support a wide variety of needs including monitoring applications, workflow systems, time-sensitive information updates, mobile applications, and any other application that generates or consumes notifications. For example, Amazon SNS can be used in workflow systems to relay events among distributed computer applications, move data between data stores or update records in business systems. Event updates and notifications concerning validation, approval, inventory changes and shipment status are immediately delivered to relevant system components as well as end-users. Another example use for Amazon SNS is to relay time-critical events to mobile applications and devices. Since Amazon SNS is both highly reliable and scalable, it provides significant advantages to developers who build applications that rely on real-time events.
Amazon SNS offers several benefits making it a versatile option for building and integrating loosely-coupled, distributed applications.
It is very easy to get started with Amazon SNS. Developers must first create a “topic” which is an “access point” – identifying a specific subject or event type – for publishing messages and allowing clients to subscribe for notifications. Once a topic is created, the topic owner can set policies for it such as limiting who can publish messages or subscribe to notifications, or specifying which notification protocols will be supported (i.e. Mobile Push, HTTP/HTTPS, email, SMS). Subscribers are clients interested in receiving notifications from topics of interest; they can subscribe to a topic or be subscribed by the topic owner. Subscribers specify the protocol and end-point (URL, email address, etc.) for notifications to be delivered. When publishers have information or updates to notify their subscribers about, they can publish a message to the topic – which immediately triggers Amazon SNS to deliver the message to all applicable subscribers.
Amazon Simple Queue Service (SQS) and Amazon SNS are both messaging services within AWS, which provide different benefits for developers. Amazon SNS allows applications to send time-critical messages to multiple subscribers through a “push” mechanism, eliminating the need to periodically check or “poll” for updates. Amazon SQS is a message queue service used by distributed applications to exchange messages through a polling model, and can be used to decouple sending and receiving components. Amazon SQS provides flexibility for distributed components of applications to send and receive messages without requiring each component to be concurrently available.
To sign up for Amazon SNS, click the “Sign up for Amazon SNS” button on the Amazon SNS detail page. You must have an Amazon Web Services account to access this service; if you do not already have one, you will be prompted to create one when you begin the Amazon SNS sign-up process. After signing up, please refer to the Amazon SNS documentation and Getting Started Guide to begin using Amazon SNS. Using the AWS Management Console, you can easily create topics, add subscribers, send notifications, and edit topic policies – all from your browser.
Amazon SNS is supported in the AWS Management Console which provides a point-and-click, web-based interface to access and manage Amazon SNS. Using the AWS Management Console, you can create topics, add subscribers, and send notifications – all from your browser. In addition, the AWS Management Console makes it easy to publish messages over your protocol of choice (HTTP, email, SQS protocol, etc.) and edit topic policies to control publisher and subscriber access. The AWS Management Console is provided free of charge at: http://aws.amazon.com/console
Amazon SNS is a web service designed to enable applications to send notifications from the cloud. AWS does not provide telephony service or Internet access of any kind. Both the message publisher and notification subscriber are responsible for purchasing telephony services or Internet access from the third party carrier of their choice.
With Amazon SNS, there is no minimum fee and you pay only for what you use. Please refer to the Amazon SNS Details page for details on pricing and data transfer costs.
There are no set-up fees to begin using the service. At the end of the month, your credit card will automatically be charged for that month’s usage. You can view your charges for the current billing period at any time on the Amazon Web Services web site by logging into your Amazon Web Services account and clicking “Account Activity” under “Your Web Services Account”.
Your Amazon SNS billing cycle begins on the first day of each month and ends on the last day of each month. Your monthly charges will be totaled at the end of each month.
Except as otherwise noted, our prices are exclusive of applicable taxes and duties, such as VAT and applicable sales tax. Our prices for the Asia Pacific (Tokyo) Region are inclusive of Japan consumption tax.
Topic names are limited to 256 characters. Alphanumeric characters plus hyphens (-) and underscores (_) are allowed. Topic names must be unique within an AWS account. After you delete a topic, you can reuse the topic name. When a topic is created, Amazon SNS will assign a unique ARN (Amazon Resource Name) to the topic, which will include the service name (SNS), region, AWS ID of the user and the topic name. The ARN will be returned as part of the API call to create the topic. Whenever a publisher or subscriber needs to perform any action on the topic, they should reference the unique topic ARN. The following is the ARN for a topic named “mytopic” created by a user with the AWS account ID “123456789012” and hosted in the US East region:
Note: Users should NOT attempt to build the topic ARN from its separate components – they should always use the name returned from the API call to create the topic.
Amazon SNS provides a set of simple APIs to enable event notifications for topic owners, subscribers and publishers.
The two APIs to list subscriptions perform different functions and return different results:
In order for customers to have broad flexibility of delivery mechanisms, Amazon SNS supports notifications over multiple transport protocols. Customers can select one the following transports as part of the subscription requests:
Topic owners can configure specific transports on their topics by setting the appropriate permissions through access control policies.
Please refer to the Amazon SNS Getting Started Guide for an overview of setting access control policies.
Subscribers to an Amazon SNS topic can receive notifications on any transport supported by the topic. A topic can support subscriptions and notification deliveries over multiple transports.
Amazon SNS can be used with other AWS services such as Amazon SQS, Amazon EC2 and Amazon S3. Here is an example of how an order processing workflow system uses Amazon SNS with Amazon EC2, SQS, and SimpleDB. In this workflow system, messages are sent between application components whenever a transaction occurs or an order advances through the order processing pipeline. When a customer initially places an order, the transaction is first recorded in Amazon SimpleDB and an application running on Amazon EC2 forwards the order request to a payment processor which debits the customer’s credit card or bank account. Once approved, an order confirmation message is published to an Amazon SNS topic. In this case, the topic has various subscribers over Email/HTTP – merchant, customer and supply chain partners – and notifications sent by Amazon SNS for that topic can instantly update all of them that payment processing was successful. Notifications can also be used to orchestrate an order processing system running on EC2, where notifications sent over HTTP can trigger real-time processing in related components such as an inventory system or a shipping service. By integrating Amazon SNS with Amazon SQS, all notifications delivered are also persisted in an Amazon SQS queue where they are processed by an auditing application at a future time.
Amazon SNS is available in the US East (Northern Virginia), US West (Oregon), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney) and South America (Sao Paulo) regions.
Topic names should typically be available for reuse approximately 30-60 seconds after the previous topic with the same name has been deleted. The exact time will depend on the number of subscriptions which were active on the topic – topics with a few subscribers will be available instantly for reuse, topics with larger subscriber lists may take longer.
To receive email notifications for a particular topic, a subscriber should specify “Email” or “Email-JSON” as the protocol and provide a valid email address as the end-point. This can be done using the AWS Management Console or by calling the Amazon SNS API directly. Amazon SNS will then send an email with a confirmation link to the specified email address, and require the user monitoring the email address to explicitly opt-in for receiving email notifications from that particular topic. Once the user confirms the subscription by clicking the provided link, all messages published to the topic will be delivered to that email address. The AWS Management Console is available at: http://aws.amazon.com/console
The two email transports are provided for two distinct types of customers/end-users. “Email-JSON” sends notifications as a JSON object, and is meant for applications to programmatically process emails. The ”Email” transport is meant for end-users/consumers and notifications are regular, text-based messages which are easily readable.
Amazon SNS allows users to specify the Subject field for emails as a parameter passed in to the Publish API call and can be different for every message published. The Display name for topics can be set using the SetTopicAttributes API – this name applies to all emails sent from this topic.
In most cases, users should be able to receive subscription confirmations and notifications from Amazon SNS without doing anything specific. However, there could be cases where the email provider’s default settings or other user-specific configurations mistakenly redirect the emails to the junk/spam folder. To ensure that users see confirmation messages and notifications sent from Amazon SNS, users can add “firstname.lastname@example.org” to their contact lists and check their junk/spam folders for messages from Amazon SNS.
Using the SQS console, users should create the SQS queue prior to subscribing it to a Topic. Select this queue on the console, and from the ‘Queue Actions’ in the menu bar, select ‘Subscribe Queue to SNS Topic’ from the drop-down list. In the subscribe dialog box, select the topic from the ‘Choose a Topic’ drop-down list, and click the ‘Subscribe’ button. For complete step-by-step instructions, please refer to the Amazon SNS documentation.
To have Amazon SNS deliver notifications to an SQS queue, a developer should subscribe to a topic specifying “SQS” as the transport and a valid SQS queue as the end-point. In order to allow the SQS queue to receive notifications from Amazon SNS, the SQS queue owner must subscribe the SQS queue to the Topic for Amazon SNS to successfully deliver messages to the queue. If the user owns both the Amazon SNS topic being subscribed to and the SQS queue receiving the notifications, nothing further is required. Any message published to the topic will automatically be delivered to the specified SQS queue. If the user owning the SQS queue is not the owner of the topic, Amazon SNS will require an explicit confirmation to the subscription request. Please refer to the Amazon SNS documentation for further details on subscribing an SQS queue to a topic and setting access control policies for SQS queues.
Create an SNS topic first using SNS. Then create and subscribe multiple SQS queues to the SNS topic. Now whenever a message is sent to the SNS topic, the message will be fanned out to the SQS queues, i.e. SNS will deliver the message to all the SQS queues that are subscribed to the topic.
Mobile Push notifications follow the structure built into whichever mobile platform is being targeted. For more information, see Using Amazon SNS Mobile Push Notifications.
The notification message sent by Amazon SNS for deliveries over HTTP, HTTPS, Email-JSON and SQS transport protocols will consist of a simple JSON object, which will include the following information:
Please refer to the 'SMS Related Question' section below.
All API calls made to Amazon SNS are validated for the user’s AWS Id and the signature. In addition, we recommend that users secure their data over the wire by connecting to our secure SSL end-points.
Topics can only be created by users with valid AWS IDs who have signed up for Amazon SNS. The easiest way to create a topic is to use the AWS Management Console. It can also be created through the CreateTopic API. The AWS Management Console is available at: http://aws.amazon.com/console
A topic owner can set explicit permissions to allow more than one user (with a valid AWS ID) to publish to a topic. By default, only topic owners have permissions to publish to a topic.
The AddPermission and RemovePermission APIs provide a simple interface for developers to add and remove permissions for a topic. However, for conditional access and more advanced use cases, users should use access control policies to manage permissions. The easiest way to manage permissions is to use the AWS Management Console. The AWS Management Console is available at: http://aws.amazon.com/console
Amazon SNS makes it easy for users with and without AWS IDs to receive notifications. The owner of the topic can grant/restrict access to subscribers by setting appropriate permissions for the topic using Access Control policies. Users can receive notifications from Amazon SNS in two ways: Users with AWS IDs: Subscribers with valid AWS IDs (please refer to this link for details on obtaining AWS IDs) can subscribe to any topic directly – as long as the topic owner has granted them permissions to do so. The AWS IDs will be validated as part of the subscription registration. Other users: Topic owners can subscribe and register end-points on behalf of users without AWS IDs. In both cases, the owner of the subscription endpoint needs to explicitly opt-in and confirm the subscription by replying to confirmation message sent by Amazon SNS.
All API calls made to Amazon SNS will validate authenticity by requiring that requests be signed with the secret key of the AWS ID account and verifying the signature included in the requests.
Mobile Push Notification subscribers do not require an explicit opt-in due to the nature of mobile push. End-users opt-in to receive push notifications when they first run an app, whether or not SNS delivers the push notifications.
As part of the subscription registration for other endpoint types, Amazon SNS will ensure that notifications are only sent to valid, registered subscribers/end-points. To prevent spam and ensure that a subscriber end-point is really interested in receiving notifications from a particular topic, Amazon SNS requires an explicit opt-in from subscribers using a 2-part handshake:
i. When a user first calls the Subscribe API and subscribes an end-point, Amazon SNS will send a confirmation message to the specified end-point.
ii. On receiving the confirmation message at the end-point, the subscriber should confirm the subscription request by sending a valid response. Only then will Amazon SNS consider the subscription request to be valid. If there is no response to the challenge, Amazon SNS will not send any notifications to that end-point. The exact mechanism of confirming the subscription varies by the transport protocol selected:
Token included in the confirmation message sent to end-points on a subscription request are valid for 3 days.
Only the owner of the topic can change permissions for that topic.
To ensure the authenticity of the notifications, Amazon SNS will sign all notification deliveries using a cryptographically secure, asymmetric mechanism (private-public key pair based on certificates). Amazon SNS will publish its certificate to a well-known location (e.g. http://sns.us-east-1.amazonaws.com/SimpleNotificationService.pem for the US East region) and sign messages with the private key of that certificate. Developers/applications can obtain the certificate and validate the signature in the notifications with the certificate’s public key, to ensure that the notification was indeed sent out by Amazon SNS. For further details on certificate locations, please refer to the Amazon SNS details page.
Amazon SNS requires publishers with AWS IDs to validate their messages by signing messages with their secret AWS key; the signature is then validated by Amazon SNS.
Yes, both publishers and subscribers can use SSL to help secure the channel to send and receive messages. Publishers can connect to Amazon SNS over HTTPS and publish messages over the SSL channel. Subscribers should register an SSL-enabled end-point as part of the subscription registration, and notifications will be delivered over a SSL channel to that end-point.
The owner of the end-point receiving the notifications has to grant permissions for Amazon SNS to send messages to that end-point.
Subscribers can be unsubscribed either by the topic owner, the subscription owner or others – depending on the mechanism used for confirming the subscription request.
Amazon SNS stores all topic and message information within Amazon’s proven network infrastructure and datacenters. All messages are stored redundantly on multiple servers and in multiple data centers, which means that no single computer or network failure renders Amazon SNS inaccessible.
No, all notification messages will contain a single published message.
Although most of the time each message will be delivered to your application exactly once, the distributed nature of Amazon SNS and transient network conditions could result in occasional, duplicate messages at the subscriber end. Developers should design their applications such that processing a message more than once does not create any errors or inconsistencies.
The Amazon SNS service will attempt to deliver messages from the publisher in the order they were published into the topic. However, network issues could potentially result in out-of-order messages at the subscriber end.
No, once a message has been successfully published to a topic, it cannot be recalled.
When a message is published to a topic, Amazon SNS will attempt to deliver notifications to all subscribers registered for that topic. Due to potential Internet issues or Email delivery restrictions, sometimes the notification may not successfully reach an HTTP or Email end-point. In the case of HTTP, an SNS Delivery Policy can be used to control the retry pattern (linear, geometric, exponential backoff), maximum and minimum retry delays, and other parameters. If it is critical that all published messages be successfully processed, developers should have notifications delivered to an SQS queue (in addition to notifications over other transports).
The easiest way to subscribe a phone to receive SMS messages is to use the AWS Management Console. First, select the SNS topic you’d like to subscribe to (or create a new topic), click the ‘Create New Subscription’ button, select ‘SMS’ from the ‘Protocol’ drop down, and then enter your phone number as the ‘Endpoint’. Alternatively you can call the Amazon SNS API directly and specify ‘SMS’ as the delivery protocol, providing a valid phone number as the end- point. Amazon SNS will then send an SMS to the provided phone number, and require the user to explicitly opt-in for receiving SMS notifications from a particular topic. This confirmation has to be in the form of an SMS sent directly from the phone. Once the user confirms the subscription, all messages published to the topic will be delivered to that phone number as SMS messages. The AWS Management Console is available at: http://aws.amazon.com/console
Currently Amazon SNS only accepts US phone numbers as valid subscriptions. These can be entered in the format ‘1-333-555-7777’ (i.e. 1 followed by the area code and the 7 digit phone number, with spaces, parentheses, hyphens, etc.).
Users should use existing mechanisms such as the AWS Management Console or the CreateTopic API call to create a new topic. In addition, for topics which will support SMS, developers must identify the topic by setting a Display name. This name will be included in all SMS messages sent from this topic.
SNS will include the topic DisplayName set by the topic owner in the initial part of the SMS message being delivered. So, for example, if the topic DisplayName is set to ‘Foo’, the message delivered will be as follows: "Foo > This is the payload of the published message."
Yes, for topics which will have SMS subscriptions, users need to set a valid topic DisplayName. Note: For topics without SMS subscriptions, the DisplayName field can be left empty.
In addition to being included as a topic identifier in SMS messages, the DisplayName is also used for the ‘From’ field in Email notification deliveries. So, while the maximum length of the DisplayName is 100 characters, due to the constrained format of SMS messaging, only the first 10 characters of the DisplayName will be included in SMS delivered. It is therefore recommended that for topics with SMS subscriptions, users set the DisplayName to have a maximum length of 10 characters or ensure that the first 10 characters of the DisplayName distinctly identify the topic.
There are several ways to stop SMS notification deliveries from reaching a user’s phone. The easiest way is to reply ‘STOP’ or ‘QUIT’ to short code 30304 to unsubscribe from all topics and stop SMS deliveries. Users can also remove SMS subscriptions using the AWS Management console or by calling the Amazon SNS API directly.
Amazon SNS notifications will be sent from short code 30304 in the US.
Yes- all SMS subscriptions are associated with Amazon SNS topics. There is no way to create an SMS subscription without associating it with a topic.
The following carriers in the US are supported: Alltel, AT&T, Sprint, Nextel, Boost, Cellcom, Cellular South, Cincinnati Bell, Cricket/Leap, nTelos, T- Mobile, US Cellular, Verizon Wireless, Virgin Mobile, ACS Wireless, Cellular One of East Central IL, Golden State Cellular, Bluegrass, Centennial, Rural Cellular, GCI, EKN/Appalachian, South Canaan, Illinois Valley Cellular, Viaero Wireless, Immix/Keystone, Inland Cellular, United Wireless, WCC, Cox Communications, Plateau Wireless, Element Mobile, iWireless, Nex-Tech Wireless, and Thumb Cellular.
Initially, SMS messages can only be sent from topics created in the US East Region. However, an application can publish to the SNS service in US East from any other region.
SNS does not support MMS messaging at this time.
Yes – there are an increasing number of AWS services that use Amazon SNS to send service notifications including CloudWatch and S3 Reduced Redundancy. In addition to configuring and receiving email notifications for events of interest, you can also configure and receive SMS notifications for those same services. For example, you can easily setup a topic for CloudWatch Alarms which will receive alarm events. To this topic, you can subscribe an email address or a phone number (or both) as end-points for notifications to be delivered. Whenever CloudWatch detects a configured condition for an alarm to fire, it will publish a message to the SNS topic which will then delivered as an email or SMS to the appropriate end-point.
SMS notifications are limited by protocol specification to no more than 140 characters per message for ASCII (or 70 characters for Unicode). Since all SMS messages sent out include the topic DisplayName, the sum of the topic DisplayName and the published message payload can at most be 140 characters (or 70 characters for Unicode). Any published message which exceeds this size will be truncated in the SMS sent out.
Yes – Amazon SNS can deliver notifications via different protocols at the same time. However, SMS messages are restricted in size to 140 total characters. For email, the maximum limit is 8K characters. Since messages must be kept short and abbreviations are often used with SMS, content that is formatted for email delivery may not display well when delivered via SMS.
Yes – we plan to add functionality over time to improve SMS support and broaden the range of needs that can be addressed with SMS using Amazon SNS.
When a phone number for an SMS end-point is subscribed to a topic, Amazon SNS will send out an SMS message to the specified phone requesting that the subscription be confirmed. The format of this message is as follows: "Would you like to receive messages from Foo. Reply Yes Foo to receive messages. Reply Help or Stop. Msg. Msg&data rates may apply." In this case ‘Foo’ is the DisplayName set for this topic. To confirm the subscription, users must respond with a confirmation SMS message: Yes Foo That confirms this subscription. If such a message is not received by SNS, no further messages from Foo will be sent to this phone number.
"Foo> This is the payload the published message." where Foo is the DisplayName set for the topic.
In response to receiving a Help message, SNS will respond with the following message: "Visit http://aws.amazon.com/sns or call 1-800-xxx-xxxx for help. Reply STOP to cancel. Msg&data rates may apply."
SMS messages sent from Amazon SNS cost $0.75 per 100 notifications sent.
There is a monthly free tier allowance for SMS messages. The first 100 SMS messages sent each month are free. Additional SMS messages cost $0.75 per 100 messages sent. For additional information on SMS pricing, please visit: http://aws.amazon.com/sns/pricing
Pricing for SMS message delivery to mobile devices is based on your text message plan with your wireless carrier.
Currently Amazon SNS will only accept US phone numbers as valid subscription end-points.
Currently, we enforce a limit of 3,000 topics per AWS account. Should you need to exceed this limit, please contact email@example.com.
Amazon SNS messages can contain up to 256 KB of text data, including XML, JSON and unformatted text. In order to maximize the contents of your payload, you can set the optional “RawMessageDelivery” property to exclude SNS-generated JSON that provides metadata about the message and topic. The following Unicode characters are accepted:
#x9 | #xA | #xD | [#x20 to #xD7FF] | [#xE000 to #xFFFD] | [#x10000 to #x10FFFF]
(according to http://www.w3.org/TR/REC-xml/#charsets).
Note: For SMS subscriptions, only 140 characters will be included in the payload of the message delivered. This will include the DisplayName of the topic and as many characters of the published message as can be accomodated.
Large payloads of up to 256KB are supported only for authentication based on SigV4. Earlier signature versions support payload sizes up to 64KB. The latest SDK automatically uses SigV4 for authentication.
You can now opt-in to get your messages delivered in raw form, i.e. exactly as you published them. By default, messages are delivered encoded in JSON that provides metadata about the message and topic. Raw message delivery can be enabled by setting the “RawMessageDelivery” property on the subscriptions. This property can be set by using the AWS Management Console, or by using the API SetSubscriptionAttributes.
By default, if this property is not set, messages will be delivered in JSON format, which is the current behavior. This ensures existing applications will continue to operate as expected.
New raw message delivery support is added to endpoints of type SQS Queue and HTTP(S). Deliveries to Email and SMS endpoints will behave the same independent of the “RawMessageDelivery” property.
When raw-formatted messages are delivered to HTTP/s endpoints, the message body will be included in the body of the HTTP POST.
SNS Mobile Push lets you use Simple Notification Service (SNS) to deliver push notifications to Apple, Google, and Kindle Fire devices. With push notifications, an installed mobile application can notify its users immediately by popping a notification about an event, without opening the application. For example, if you install a sports app and enable push notifications, the app can send you the latest score of your favorite team even if the app isn’t running. The notification appears on your device, and when you acknowledge it, the app launches to display more information. Users’ experiences are similar to receiving an SMS, but with enhanced functionality and at a fraction of the cost.
Push notifications can only be sent to devices that have your app installed, and whose users have opted in to receive them. SNS Mobile Push does not require explicit opt-in for sending push notifications, but iOS, Android and Kindle Fire operating systems do require it. In order to send push notifications with SNS, you must also register your app and each installed device with SNS. For more information, see Using Amazon SNS Mobile Push Notifications.
Currently, the following push notifications platforms are supported:
Currently you can send push notifications to any devices supported by Apple APNS (including iPhone and iPad), Google GCM (including Android devices such as Samsung Galaxy) or Amazon ADM (including Kindle Fire devices).
The SNS free tier includes 1 million publishes, plus 1 million mobile push deliveries. So you can send 1 million free push notifications every month. Notifications to Apple, Google and Kindle Fire devices are all counted together toward your 1 million free mobile push deliveries.
No, they do not. End-users opt-in to receive push notifications when they first run an app, whether or not SNS delivers the push notifications.
SNS topics can have subscribers from any supported push notifications platform, as well as any other endpoint type such as SMS or email. When you publish a notification to a topic, SNS will send identical copies of that message to each endpoint subscribed to the topic. If you use platform-specific payloads to define the exact payload sent to each push platform, the publish will fail if it exceeds the maximum payload size imposed by the relevant push notifications platform.
SNS will support maximum payload size that is supported by the underlying native platform. Customers can use a JSON object to send platform specific messages. See Using SNS Mobile Push API for additional details.
When you publish to a topic and want to have customized messages sent to endpoints for the different push notification platforms then you need to select “Use different message body for different protocols” option on the Publish dialog box and then update the messages. You can use platform-specific payloads to specify the exact API string that is relayed to each push notifications service. For example, you can use platform-specific payloads to manipulate the badge count of your iOS application via APNS. For more information, see Using Amazon SNS Mobile Push Notifications.
Yes. Each token can be subscribed to an unlimited number of SNS topics.
SNS currently supports up to 10,000 subscribers to any single topic. You can use SNS to notify an unlimited number of recipients. In order to reach more than 10,000 recipients, consider using direct addressing or multiple SNS topics.
Direct addressing is a new delivery model for SNS that allows you to deliver notifications directly to a single endpoint, rather than sending identical messages to all subscribers of a topic. This is useful if you want to deliver precisely targeted messages to each recipient. When you register device tokens with SNS, SNS creates an endpoint that corresponds to the token. You can publish to the token endpoint just as you would publish to a topic. You can direct publish either the text of your notification, or a platform-specific payload that takes advantage of platform-specific features such as updating the badge count of your app. Direct addressing is currently only available for push notifications endpoints.
No. At this time, direct addressing is only supported for push notifications to iOS, Kindle, and Android endpoints.
SNS Mobile Push automatically handles token feedback services on your behalf, and exposes the feedback information via events published to a topic you may choose to consume. This approach reduces the operational burden of sending push notifications, and maximizes the speed and reliability with which your notifications are delivered. Push notifications services such as APNS and GCM provide feedback about tokens which may have expired or been replaced by new tokens. When a particular token is replaced by a new token, SNS automatically updates the associated endpoint, and notifies you via an event. When a particular token expires, perhaps because a user deleted your app, SNS marks the endpoint as disabled and notifies you via an event. You don’t strictly need to consume the feedback notifications in order to send push notifications with SNS, but may choose to do so based on your broader use case.
Yes. You can perform a bulk upload of existing device tokens to Amazon SNS, either via the console interface or API. You would also register your app with SNS by uploading your credentials for the relevant push notifications services, and configure your proxy or app to register future new tokens with SNS.
Yes. SNS publishes Cloudwatch metrics for number of messages published, number of successful notifications, number of failed notifications and size of data published. Metrics are available on per application basis. You can access Cloudwatch metrics via AWS Management Console or CloudWatch APIs.