CloudWatch2S3-additional-account template deployment failure

[zaro0508]

We are able to deploy arn:aws:serverlessrepo:us-east-1:859319237877:applications/CloudWatch2S3 from the serverless repo without error. However when we attempt to deploy arn:aws:serverlessrepo:us-east-1:859319237877:applications/CloudWatch2S3-additional-account we get the following error..

Embedded stack arn:aws:cloudformation:us-east-1:XXXXXX7719:stack/sagebase-CloudWatch2S3-vpnlog-CloudWatch2S3additionalaccount-1HGNM31L57HXW/69e4db50-5a46-11ed-a21f-12c92c15d0df
was not successfully created: The following resource(s) failed to create: [Subscriber]

Our parameter inputs for CloudWatch2S3-additional-account template are:

LogDestination: "arn:aws:logs:us-east-1:XXXXXXXX6444:destination:BucketBackupLogDestination"  
LogGroupNamePrefix: "/aws/vpn"
SubscribeSchedule: "rate(1 hour)"

We are using SemanticVersion 1.0.5. The failure message makes it difficult to debug. Has anyone seen this problem before?

[kichik]

Subscriber is the custom resource used to subscribe the logs to Kinesis. The easiest way to debug it is to create the stack with the setting to not delete on failure. Then find the Lambda it created and check its logs. The log will probably also remain even without this setting. It's just easier to find with this setting.

[zaro0508]

thanks for the tip @kichik. i see the error in the logs..

Subscribe to all new log groups on resource Create
--
Finding all log groups with prefix '/aws/vpn'
Subscribe  /aws/vpn/sagebase-client-vpn
Caught exception but unable to print stack trace
An error occurred (AccessDeniedException) when calling the PutSubscriptionFilter
operation: User with accountId: XXXXXXX7719 is not authorized to perform: logs:PutSubscriptionFilter
on resource: arn:aws:logs:us-east-1:XXXXXXX6444:destination:BucketBackupLogDestination

it looks like the account (XXXXXXX7719) we deployed the CloudWatch2S3-additional-account template to does not have access to the kinesis stream in our central logging account ( XXXXXXX6444).

[kichik]

You should be able to give it access by setting the AllowedAccounts parameter on the main stack.

[zaro0508]

thanks @kichik. setting AllowedAccounts fixed the problem.