This guide will show you steps to create SNS topics and access them from your service running within environments.

​
Declarative & Automatic using ops.json:

For your service, if you need one or more SNS topics, you can add ops.json in the root directory of Github repo you’ve connected for the service.
Learn more about configuring dependencies using ops.json here.
And add SNS topics as a dependency, like below. 
{
  "dependencies": {
    "sns": {
      "topics": [
        {
          "id": "test123",
          "prefix": "testdep123",
          "exports": {
            "MY_SNS_TOPIC_NAME1": "$name",
            "MY_SNS_TOPIC_ARN1": "$arn"
          }
        }
      ]
    }
  }
}
You can add as many topics as you want. Arguments you can add in each topic object above:
  1. id - Alphanumeric string. Must be unique amongst the Topics you’ve declared above. Changing this string will replace the original topic with new one.
  2. prefix - Alphanumeric string. Will be used as a prefix in the name of your topic. Changing this string will replace the original topic with new topic.
  3. exports - Set of key value pairs. Keys are the ENVIRONMENT VARS we will pass to your code / containers. Values are the properties of the Topic provisioned. See below for available properties.
Changing id or prefix string will delete & replace the original topic with new one.
Available properties of the topic to use in exports:
  1. $name - Name of the topic
  2. $arn - Amazon resource name of the topic. Eg., arn:sns:..

​
Lifecycle:

If you have provided ops.json at the root of the git repository, it will be processed if a corresponding service in any of your active environment points at the same repository as source and when a deployment is triggered.
  • When the service is spinned up first time or when a new deployment is triggered, ops.json is parsed for processing. Resources declared in the dependencies object will be provisioned before your code starts to run.
  • Resources with same id are provisioned only once for the life of the service. And updated when there is a change in one of the properties above.
  • Keys in exports object will be passed as enviroment variables to your service.
  • When the service is deleted, the provisioned resources (topics, here) are deleted from the cloud account immediately & automatically.

​
Access with no keys:

Topics can be accessed from your code using AWS SDK. You don’t have to pass any AWS secret key to authenticate. Your containers automatically authenticate to have access to all the topics you’ve declared in the above JSON. LocalOps arranges Role based access by attaching an IAM role for all the services run within your environment. We provision a policy like below on that IAM role for every Topic provisioned. 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sns:Publish",
        "sns:Subscribe",
        "sns:Unsubscribe",
        "sns:Receive",
        "sns:GetTopicAttributes",
        "sns:SetTopicAttributes",
        "sns:ListSubscriptionsByTopic"
      ],
      "Resource": "your-sns-topic"
    }
  ]
}
Curious to know the IAM role that is used? Visit your environment’s main dashboard in LocalOps console to see the role.

​
Manual provisioning of new SNS topics:

To proceed with this guide, you would need access to:
  1. AWS console with permissions to access SNS console and add policies to an existing IAM role.
  2. LocalOps console

​
1. Create SNS topic

Login to AWS console and create new SNS topic in the region you want, and with appopriate unique name. You can follow this official AWS guide to create SNS topic(s).

​
2. Add permission to access SNS topic

LocalOps creates a new IAM role in your AWS account, for each environment, so that your services/containers can access them. So that your code/containers can access any AWS resource without passing AWS_ACCESS_KEY or AWS_SECRET_KEY. Navigate to LocalOps console and the corresponding environment. In overview section, you can find the APP ROLE whose name ends with app-role and that which you can copy and search in AWS IAM console > Roles section. Once you find the IAM role in IAM console, next step is to add a policy to the IAM role to give permissions for the role to access the SNS topic(s) your created.

​
Create a new IAM policy for the SNS topic:

  1. Navigate to Policies in AWS IAM console
  2. Create a new IAM policy and give it a specific name
  3. Add the JSON below, as policy statement:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sns:Publish",
        "sns:Subscribe",
        "sns:Unsubscribe",
        "sns:Receive",
        "sns:GetTopicAttributes",
        "sns:SetTopicAttributes",
        "sns:ListSubscriptionsByTopic"
      ],
      "Resource": "<sns-topic-arn>"
    }
  ]
}
Replace <sns-topic-arn> with your SNS topic’s ARN. If you create more than one topic, expand the Resource attribute above to an array of ARN strings.
  1. Press save.

​
Add the new IAM policy to the IAM role

Navigate back to the IAM role you saw earlier. In its Permissions tab, pick the option to “Add Policy”. In the policy picker, pick the one you created above and add it.

​
3. Add topic details as secret

Last step is to give service access to the new SNS topic. In LocalOps console, navigate to the Service settings within the corresponding environment. In secrets section, add a new key value pair like 
- Key: `topic-var-name`
- Value: `topic-name`
Repeat this for each topic you created. Learn more about secrets here. You can name the key in any way you want. In your code, you can access topic-var-name environment variable to get the name of the topic you created. This can be passed to the AWS SDK used in your code to read/write data. There is no need to provide credentials like access key since we are having role based access control here. That’s it! 🎉