- Newest
- Most votes
- Most comments
The issue you're experiencing is related to cross-account and cross-region SNS to SQS subscription permissions when using CloudFormation versus the console.
When you subscribe to an SNS topic in another account via the AWS console, the console handles some of the permission requirements behind the scenes. However, when using CloudFormation, you need to ensure all the necessary permissions are explicitly configured.
For cross-account SNS to SQS subscriptions to work properly, two sets of permissions are required:
- The SNS topic owner (the other team's account) must modify their topic's access policy to allow your account to subscribe. This policy should include a statement like:
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam:[YOUR-ACCOUNT-ID]:root" },
"Action": "sns:Subscribe",
"Resource": "arn:aws:sns:ap-southeast-1:[THEIR-ACCOUNT-ID]:TopicName"
}
- Your SQS queue's access policy must allow the SNS topic to send messages to it.
The cross-region aspect adds another layer of complexity. Make sure that:
- The SNS topic's access policy allows cross-region subscriptions
- Your queue's access policy permits the SNS topic to send messages across regions
Since it works via the console but not via CloudFormation, it's likely that the CloudFormation service role doesn't have the necessary permissions to create the subscription on your behalf, or there might be a specific formatting issue with how the cross-region ARN is specified in your template.
I recommend checking that your CloudFormation template includes both the subscription resource and the proper queue policy that allows the specific SNS topic ARN from the other region to publish to your queue.
Sources
Subscribing a queue to an Amazon SNS topic using the Amazon SQS console - Amazon Simple Queue Service
Sending Amazon SNS messages to an Amazon SQS queue in a different account - Amazon Simple Notification Service
Enforce resource configuration to control access to new features with AWS | AWS Security Blog

Thank you for the response, I've verified that the SNS topic owner has modified their topic's access policy (especially as subscribing works from the console). From my own template, our team has a policy like the below. Does any of it indicate that it would not work for a cross region use case?
SQS Queue permitting SNS to send message
RefreshSpiceEventQueuePolicy: Type: AWS::SQS::QueuePolicy Properties: PolicyDocument: Version: '2012-10-17' Statement: - Sid: allow-sns-publish-access-to-sqs Effect: Allow Principal: AWS: '' Action: - sqs:SendMessage Resource: '' Condition: ArnEquals: aws:SourceArn: Fn::FindInMap: - S3EventSNSTopicARNMap - Ref: 'AWS::Region' - Fn::FindInMap: ['StageMapping', {Ref: 'Stage'}, 'value'] Queues: - Ref: EventQueue